You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Giulio Speri - MpStyle Srl <gi...@mpstyle.it> on 2022/07/08 11:05:02 UTC
Possible issue in balanceInventoryItems/reassignInventoryReservation service
Hello devs,
I hope you're doing good!
I write because I think I found a possible issue in minilang service
*reassignInventoryReservation*.
This service is called as a SECA on createPhysicalInventoryAndVariance
service and at the end it deletes inventory reservation for an order items
that has quantityNotReserved .gt. 0 and then re-reserve the inventory
calling the service *reserveProductInventoryByFacility, *implemented by the
method *reserveProductInventory*
(applications/product/minilang/product/inventory/InventoryReserveServices.xml).
The *reserveProductInventoryByFacility has some parameters passed in and
among them there is requireInventory parameter, that is hardcoded to N, to
allow back-orders (negative ATP).*
In our ecommerce context this is not recommendable and the productStores
are all configured to requireInventory=Y, because we do not want
back-orders, but the hard-coded requireInventory "N", overrides the store
setting, making the order "available" even if stock is not present for an
order item.
I think that it is better to check the productStore setting of the
requireInventory parameter, and pass that value to the
*reserveProductInventoryByFacility,* instead of a hard-coded "N".
What do you think about it?
If you agree I could take care of it in a Jira Task and provide a patch.
Thanks in advance,
Giulio
--
Giulio Speri
*Mp Styl**e Srl*
via Antonio Meucci, 37
41019 Limidi di Soliera (MO)
T 059/684916
M 347/0965506
www.mpstyle.it
Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service
Posted by Scott Gray <sc...@hotwaxsystems.com>.
Hi Giulio,
It seems to me your problem isn't that you have a reservation containing a
quantityNotAvailable, the real problem is that you have an order you can't
fulfill. Cancelling the affected order line item would seem to be the best
solution, it removes the reservation and cleans up the order.
I would suggest using a custom SECA that runs after
reassignInventoryReservation completes, it would look for reservations
having a quantityNotAvailable greater than zero and then resolve them in
whatever manner you choose (e.g. sending an email to alert the customer
service team, auto-cancelling the order/order item and notifying the
customer, etc.).
Regards
Scott
On Mon, 11 Jul 2022 at 19:31, Giulio Speri - MpStyle Srl <
giulio.speri@mpstyle.it> wrote:
> Hi Scott,
>
> I'll explain a little in depth the context: the e-commerce sites in OFBiz
> use an ERP as the main source of data, both for products and their
> inventory.
> The ERP has different facilities and every night a scheduled procedure sync
> Inventory quantities between the ERP and the e-commerce.
> One of the ERP facilities, let's say facility A, is used not only for the
> e-commerce availabilities but also for wholesale order, retail orders,
> internal orders of the Company, so there could be more than one "party"
> that could use the same inventory on the facility A: here the rule is: the
> first order that comes in is served.
>
> The logistic service that ships the orders is the same for both ERP and
> ecommerce orders, but the e-commerce orders are not "real-time" synced with
> the ERP system (they are synced once in the evening), and the
> logistic service is notified only once a day (in the morning) for the
> e-commerce orders they have to prepare for shipping.
>
> This could lead to a scenario where an ecommerce order for a Product X
> comes in on OFBiz, and an "ERP" order comes in before the notification for
> the e-commerce order could arrive: since the logistic service is unaware of
> e-commerce orders until the email notification, happen that they ship the
> ERP order, sending the availability for Product X to 0; during the night
> ERP sync its inventory with OFBiz and at this point we have the problem I
> described.
> The ATP of the inventory item related to the orderItem reservation is no
> longer sufficient to fulfill that order row and the system creates a new
> reservation for quantityNotReserved quantity in a new InventoryItem: the
> problem is that, that item can not and will not be shipped because
> physically the logistic has no stock for the product.
>
> For this reason I suggested checking the store configuration, to have the
> same behaviour in case of an "out-of-stock" order.
>
> I got your point and it makes sense: there is a reservation for an order
> and after an inventory update that reservation disappears in silence.
> Could we think about a SECA notification (like the ones for the order
> status changes) for items that could not be re-reserved ?
>
> I know that inventory reservation is always a critical point and an
> "Out-of-stock" could always happen in some way, so this will not be an
> ultimate solution to this, but we could make the e-commerce
> managers/operators more aware of what is going on.
>
> What do you think about it?
>
> Thanks in advance,
> Giulio
>
>
> Il giorno ven 8 lug 2022 alle ore 17:34 Scott Gray <
> scott.gray@hotwaxsystems.com> ha scritto:
>
> > Hi Giulio,
> >
> > I think the hardcoded "N" is used there because a reservation is being
> > deleted and then recreated. The assumption there is that if a
> reservation
> > existed before the process, then it should also exist after the process
> and
> > should not simply disappear because a physical inventory was recorded.
> In
> > your situation (if I understand correctly), you require inventory for an
> > order to be created but if you then reduce inventory to the point there
> is
> > no longer enough to cover all orders then you want the reservations to
> > disappear? What happens to the order?
> >
> > Regards
> > Scott
> >
> > On Fri, 8 Jul 2022 at 12:05, Giulio Speri - MpStyle Srl <
> > giulio.speri@mpstyle.it> wrote:
> >
> > > Hello devs,
> > >
> > > I hope you're doing good!
> > > I write because I think I found a possible issue in minilang service
> > > *reassignInventoryReservation*.
> > >
> > > This service is called as a SECA on createPhysicalInventoryAndVariance
> > > service and at the end it deletes inventory reservation for an order
> > items
> > > that has quantityNotReserved .gt. 0 and then re-reserve the inventory
> > > calling the service *reserveProductInventoryByFacility, *implemented by
> > the
> > > method *reserveProductInventory*
> > >
> > >
> >
> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
> > >
> > > The *reserveProductInventoryByFacility has some parameters passed in
> and
> > > among them there is requireInventory parameter, that is hardcoded to N,
> > to
> > > allow back-orders (negative ATP).*
> > >
> > > In our ecommerce context this is not recommendable and the
> productStores
> > > are all configured to requireInventory=Y, because we do not want
> > > back-orders, but the hard-coded requireInventory "N", overrides the
> store
> > > setting, making the order "available" even if stock is not present for
> an
> > > order item.
> > >
> > > I think that it is better to check the productStore setting of the
> > > requireInventory parameter, and pass that value to the
> > > *reserveProductInventoryByFacility,* instead of a hard-coded "N".
> > >
> > > What do you think about it?
> > > If you agree I could take care of it in a Jira Task and provide a
> patch.
> > >
> > > Thanks in advance,
> > > Giulio
> > >
> > > --
> > > Giulio Speri
> > >
> > >
> > > *Mp Styl**e Srl*
> > > via Antonio Meucci, 37
> > > 41019 Limidi di Soliera (MO)
> > > T 059/684916
> > > M 347/0965506
> > >
> > > www.mpstyle.it
> > >
> >
>
>
> --
> Giulio Speri
>
>
> *Mp Styl**e Srl*
> via Antonio Meucci, 37
> 41019 Limidi di Soliera (MO)
> T 059/684916
> M 347/0965506
>
> www.mpstyle.it
>
Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service
Posted by Giulio Speri - MpStyle Srl <gi...@mpstyle.it>.
Hi Scott,
I'll explain a little in depth the context: the e-commerce sites in OFBiz
use an ERP as the main source of data, both for products and their
inventory.
The ERP has different facilities and every night a scheduled procedure sync
Inventory quantities between the ERP and the e-commerce.
One of the ERP facilities, let's say facility A, is used not only for the
e-commerce availabilities but also for wholesale order, retail orders,
internal orders of the Company, so there could be more than one "party"
that could use the same inventory on the facility A: here the rule is: the
first order that comes in is served.
The logistic service that ships the orders is the same for both ERP and
ecommerce orders, but the e-commerce orders are not "real-time" synced with
the ERP system (they are synced once in the evening), and the
logistic service is notified only once a day (in the morning) for the
e-commerce orders they have to prepare for shipping.
This could lead to a scenario where an ecommerce order for a Product X
comes in on OFBiz, and an "ERP" order comes in before the notification for
the e-commerce order could arrive: since the logistic service is unaware of
e-commerce orders until the email notification, happen that they ship the
ERP order, sending the availability for Product X to 0; during the night
ERP sync its inventory with OFBiz and at this point we have the problem I
described.
The ATP of the inventory item related to the orderItem reservation is no
longer sufficient to fulfill that order row and the system creates a new
reservation for quantityNotReserved quantity in a new InventoryItem: the
problem is that, that item can not and will not be shipped because
physically the logistic has no stock for the product.
For this reason I suggested checking the store configuration, to have the
same behaviour in case of an "out-of-stock" order.
I got your point and it makes sense: there is a reservation for an order
and after an inventory update that reservation disappears in silence.
Could we think about a SECA notification (like the ones for the order
status changes) for items that could not be re-reserved ?
I know that inventory reservation is always a critical point and an
"Out-of-stock" could always happen in some way, so this will not be an
ultimate solution to this, but we could make the e-commerce
managers/operators more aware of what is going on.
What do you think about it?
Thanks in advance,
Giulio
Il giorno ven 8 lug 2022 alle ore 17:34 Scott Gray <
scott.gray@hotwaxsystems.com> ha scritto:
> Hi Giulio,
>
> I think the hardcoded "N" is used there because a reservation is being
> deleted and then recreated. The assumption there is that if a reservation
> existed before the process, then it should also exist after the process and
> should not simply disappear because a physical inventory was recorded. In
> your situation (if I understand correctly), you require inventory for an
> order to be created but if you then reduce inventory to the point there is
> no longer enough to cover all orders then you want the reservations to
> disappear? What happens to the order?
>
> Regards
> Scott
>
> On Fri, 8 Jul 2022 at 12:05, Giulio Speri - MpStyle Srl <
> giulio.speri@mpstyle.it> wrote:
>
> > Hello devs,
> >
> > I hope you're doing good!
> > I write because I think I found a possible issue in minilang service
> > *reassignInventoryReservation*.
> >
> > This service is called as a SECA on createPhysicalInventoryAndVariance
> > service and at the end it deletes inventory reservation for an order
> items
> > that has quantityNotReserved .gt. 0 and then re-reserve the inventory
> > calling the service *reserveProductInventoryByFacility, *implemented by
> the
> > method *reserveProductInventory*
> >
> >
> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
> >
> > The *reserveProductInventoryByFacility has some parameters passed in and
> > among them there is requireInventory parameter, that is hardcoded to N,
> to
> > allow back-orders (negative ATP).*
> >
> > In our ecommerce context this is not recommendable and the productStores
> > are all configured to requireInventory=Y, because we do not want
> > back-orders, but the hard-coded requireInventory "N", overrides the store
> > setting, making the order "available" even if stock is not present for an
> > order item.
> >
> > I think that it is better to check the productStore setting of the
> > requireInventory parameter, and pass that value to the
> > *reserveProductInventoryByFacility,* instead of a hard-coded "N".
> >
> > What do you think about it?
> > If you agree I could take care of it in a Jira Task and provide a patch.
> >
> > Thanks in advance,
> > Giulio
> >
> > --
> > Giulio Speri
> >
> >
> > *Mp Styl**e Srl*
> > via Antonio Meucci, 37
> > 41019 Limidi di Soliera (MO)
> > T 059/684916
> > M 347/0965506
> >
> > www.mpstyle.it
> >
>
--
Giulio Speri
*Mp Styl**e Srl*
via Antonio Meucci, 37
41019 Limidi di Soliera (MO)
T 059/684916
M 347/0965506
www.mpstyle.it
Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service
Posted by Scott Gray <sc...@hotwaxsystems.com>.
Hi Giulio,
I think the hardcoded "N" is used there because a reservation is being
deleted and then recreated. The assumption there is that if a reservation
existed before the process, then it should also exist after the process and
should not simply disappear because a physical inventory was recorded. In
your situation (if I understand correctly), you require inventory for an
order to be created but if you then reduce inventory to the point there is
no longer enough to cover all orders then you want the reservations to
disappear? What happens to the order?
Regards
Scott
On Fri, 8 Jul 2022 at 12:05, Giulio Speri - MpStyle Srl <
giulio.speri@mpstyle.it> wrote:
> Hello devs,
>
> I hope you're doing good!
> I write because I think I found a possible issue in minilang service
> *reassignInventoryReservation*.
>
> This service is called as a SECA on createPhysicalInventoryAndVariance
> service and at the end it deletes inventory reservation for an order items
> that has quantityNotReserved .gt. 0 and then re-reserve the inventory
> calling the service *reserveProductInventoryByFacility, *implemented by the
> method *reserveProductInventory*
>
> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
>
> The *reserveProductInventoryByFacility has some parameters passed in and
> among them there is requireInventory parameter, that is hardcoded to N, to
> allow back-orders (negative ATP).*
>
> In our ecommerce context this is not recommendable and the productStores
> are all configured to requireInventory=Y, because we do not want
> back-orders, but the hard-coded requireInventory "N", overrides the store
> setting, making the order "available" even if stock is not present for an
> order item.
>
> I think that it is better to check the productStore setting of the
> requireInventory parameter, and pass that value to the
> *reserveProductInventoryByFacility,* instead of a hard-coded "N".
>
> What do you think about it?
> If you agree I could take care of it in a Jira Task and provide a patch.
>
> Thanks in advance,
> Giulio
>
> --
> Giulio Speri
>
>
> *Mp Styl**e Srl*
> via Antonio Meucci, 37
> 41019 Limidi di Soliera (MO)
> T 059/684916
> M 347/0965506
>
> www.mpstyle.it
>
Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service
Posted by Nicolas Malin <ni...@nereide.fr>.
Hello,
I will try soon to open a Jira with migration code on it, so if you take
a look, it would be nice :)
Tks a lot.
Nicolas
On 11/07/2022 20:33, Giulio Speri - MpStyle Srl wrote:
> Hi Nicolas,
>
> Thank you for your feedback and I will be happy to help you in the
> conversion process. :)
> How would you like to proceed?
>
> Giulio
>
> Il giorno ven 8 lug 2022 alle ore 15:33 Nicolas Malin <
> nicolas.malin@nereide.fr> ha scritto:
>
>> Hello Giulio,
>>
>> I thinks it's good to remove hard coded value and move it on the
>> productStore.
>>
>> Keep the N as default if you didn't found any value.
>>
>> I use your focus on this subject to know if you want to help me to
>> convert the minilang inventory service to groovy.
>> I can realize the conversion without problem, but I like to have some
>> production data to be ensure that I didn't introduce a regression not
>> cover by ofbiz test.
>>
>> My problem, our project don't use the inventory at a correct level, so
>> if you are available to help me on this testing task it would be great :)
>>
>> Nicolas
>>
>> On 08/07/2022 13:05, Giulio Speri - MpStyle Srl wrote:
>>> Hello devs,
>>>
>>> I hope you're doing good!
>>> I write because I think I found a possible issue in minilang service
>>> *reassignInventoryReservation*.
>>>
>>> This service is called as a SECA on createPhysicalInventoryAndVariance
>>> service and at the end it deletes inventory reservation for an order
>> items
>>> that has quantityNotReserved .gt. 0 and then re-reserve the inventory
>>> calling the service *reserveProductInventoryByFacility, *implemented by
>> the
>>> method *reserveProductInventory*
>>>
>> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
>>> The *reserveProductInventoryByFacility has some parameters passed in and
>>> among them there is requireInventory parameter, that is hardcoded to N,
>> to
>>> allow back-orders (negative ATP).*
>>>
>>> In our ecommerce context this is not recommendable and the productStores
>>> are all configured to requireInventory=Y, because we do not want
>>> back-orders, but the hard-coded requireInventory "N", overrides the store
>>> setting, making the order "available" even if stock is not present for an
>>> order item.
>>>
>>> I think that it is better to check the productStore setting of the
>>> requireInventory parameter, and pass that value to the
>>> *reserveProductInventoryByFacility,* instead of a hard-coded "N".
>>>
>>> What do you think about it?
>>> If you agree I could take care of it in a Jira Task and provide a patch.
>>>
>>> Thanks in advance,
>>> Giulio
>>>
>>
Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service
Posted by Giulio Speri - MpStyle Srl <gi...@mpstyle.it>.
Hi Nicolas,
Thank you for your feedback and I will be happy to help you in the
conversion process. :)
How would you like to proceed?
Giulio
Il giorno ven 8 lug 2022 alle ore 15:33 Nicolas Malin <
nicolas.malin@nereide.fr> ha scritto:
> Hello Giulio,
>
> I thinks it's good to remove hard coded value and move it on the
> productStore.
>
> Keep the N as default if you didn't found any value.
>
> I use your focus on this subject to know if you want to help me to
> convert the minilang inventory service to groovy.
> I can realize the conversion without problem, but I like to have some
> production data to be ensure that I didn't introduce a regression not
> cover by ofbiz test.
>
> My problem, our project don't use the inventory at a correct level, so
> if you are available to help me on this testing task it would be great :)
>
> Nicolas
>
> On 08/07/2022 13:05, Giulio Speri - MpStyle Srl wrote:
> > Hello devs,
> >
> > I hope you're doing good!
> > I write because I think I found a possible issue in minilang service
> > *reassignInventoryReservation*.
> >
> > This service is called as a SECA on createPhysicalInventoryAndVariance
> > service and at the end it deletes inventory reservation for an order
> items
> > that has quantityNotReserved .gt. 0 and then re-reserve the inventory
> > calling the service *reserveProductInventoryByFacility, *implemented by
> the
> > method *reserveProductInventory*
> >
> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
> >
> > The *reserveProductInventoryByFacility has some parameters passed in and
> > among them there is requireInventory parameter, that is hardcoded to N,
> to
> > allow back-orders (negative ATP).*
> >
> > In our ecommerce context this is not recommendable and the productStores
> > are all configured to requireInventory=Y, because we do not want
> > back-orders, but the hard-coded requireInventory "N", overrides the store
> > setting, making the order "available" even if stock is not present for an
> > order item.
> >
> > I think that it is better to check the productStore setting of the
> > requireInventory parameter, and pass that value to the
> > *reserveProductInventoryByFacility,* instead of a hard-coded "N".
> >
> > What do you think about it?
> > If you agree I could take care of it in a Jira Task and provide a patch.
> >
> > Thanks in advance,
> > Giulio
> >
>
>
--
Giulio Speri
*Mp Styl**e Srl*
via Antonio Meucci, 37
41019 Limidi di Soliera (MO)
T 059/684916
M 347/0965506
www.mpstyle.it
Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service
Posted by Nicolas Malin <ni...@nereide.fr>.
Hello Giulio,
I thinks it's good to remove hard coded value and move it on the
productStore.
Keep the N as default if you didn't found any value.
I use your focus on this subject to know if you want to help me to
convert the minilang inventory service to groovy.
I can realize the conversion without problem, but I like to have some
production data to be ensure that I didn't introduce a regression not
cover by ofbiz test.
My problem, our project don't use the inventory at a correct level, so
if you are available to help me on this testing task it would be great :)
Nicolas
On 08/07/2022 13:05, Giulio Speri - MpStyle Srl wrote:
> Hello devs,
>
> I hope you're doing good!
> I write because I think I found a possible issue in minilang service
> *reassignInventoryReservation*.
>
> This service is called as a SECA on createPhysicalInventoryAndVariance
> service and at the end it deletes inventory reservation for an order items
> that has quantityNotReserved .gt. 0 and then re-reserve the inventory
> calling the service *reserveProductInventoryByFacility, *implemented by the
> method *reserveProductInventory*
> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
>
> The *reserveProductInventoryByFacility has some parameters passed in and
> among them there is requireInventory parameter, that is hardcoded to N, to
> allow back-orders (negative ATP).*
>
> In our ecommerce context this is not recommendable and the productStores
> are all configured to requireInventory=Y, because we do not want
> back-orders, but the hard-coded requireInventory "N", overrides the store
> setting, making the order "available" even if stock is not present for an
> order item.
>
> I think that it is better to check the productStore setting of the
> requireInventory parameter, and pass that value to the
> *reserveProductInventoryByFacility,* instead of a hard-coded "N".
>
> What do you think about it?
> If you agree I could take care of it in a Jira Task and provide a patch.
>
> Thanks in advance,
> Giulio
>