You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Jonathon -- Improov <jo...@improov.com> on 2007/01/13 08:03:48 UTC
Can SOs and POs be edited, and if so, any change histories for edits
of SOs and POs?
I have a few small questions related to the bigger question in email subject. I hope someone can
answer those offhand. I hit a problem while testing (infinite loop), so I can't explore this
aspect of OFBiz beyond the show-stopper.
How does ofbiz handle revisions to SOs and POs? Any change histories kept?
I see that shipping information can be changed. Again, any change histories kept? Is the
"splitting preference" change reversible? I changed an SO to allow for split but couldn't reverse
that decision.
Any change histories for "Contact Information"?
Ok, I'm done with my questions. And now, to share what I found about the infinite loop.
Before I investigate further and post to JIRA, I'm wondering if someone can tell me quickly
whether cancellation of order items for SO is supposed to work?
To reproduce infinite loop, try ordering a PC001, then go to Order module and bring up SO, then
try canceling an order item.
Here's what I see as the contents of the loop (though I could be wrong and those calls could be
correctly repeated SO MANY TIMES, unlikely?):
SECA: cancelOrderInventoryReservation, triggered by rule on Service: changeOrderItemStatus
SECA: recalcShippingTotal, triggered by rule on Service: changeOrderItemStatus
SECA: recalcTaxTotal, triggered by rule on Service: changeOrderItemStatus
SECA: resetGrandTotal, triggered by rule on Service: changeOrderItemStatus
SECA: checkOrderItemStatus, triggered by rule on Service: changeOrderItemStatus
SECA: sendOrderChangeNotification, triggered by rule on Service: changeOrderItemStatus
SECA: recreateOrderAdjustments, triggered by rule on Service: cancelOrderItem
Jonathon
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Jonathon -- Improov <jo...@improov.com>.
Scott,
Thanks. The issue is at http://issues.apache.org/jira/browse/OFBIZ-431 , if anyone wants to know.
What about my questions on "Edits of SO/PO and edit history"? Anybody knows how it worked before
it broke?
I'll try to look into OFBIZ-431. Thanks for your pointers.
Jonathon
Scott Gray wrote:
> There's already a couple of jira issues in there, just filter by
> Critical and you should find most of them. From memory the loop is the
> last seca you mentioned, recreateOrderAdjustments which also happens to
> call cancelOrderItem so the seca gets fires again.
>
> Jonathon -- Improov wrote:
>> I have a few small questions related to the bigger question in email
>> subject. I hope someone can answer those offhand. I hit a problem
>> while testing (infinite loop), so I can't explore this aspect of OFBiz
>> beyond the show-stopper.
>>
>> How does ofbiz handle revisions to SOs and POs? Any change histories
>> kept?
>>
>> I see that shipping information can be changed. Again, any change
>> histories kept? Is the "splitting preference" change reversible? I
>> changed an SO to allow for split but couldn't reverse that decision.
>>
>> Any change histories for "Contact Information"?
>>
>> Ok, I'm done with my questions. And now, to share what I found about
>> the infinite loop.
>>
>> Before I investigate further and post to JIRA, I'm wondering if
>> someone can tell me quickly whether cancellation of order items for SO
>> is supposed to work?
>>
>> To reproduce infinite loop, try ordering a PC001, then go to Order
>> module and bring up SO, then try canceling an order item.
>>
>> Here's what I see as the contents of the loop (though I could be wrong
>> and those calls could be correctly repeated SO MANY TIMES, unlikely?):
>>
>> SECA: cancelOrderInventoryReservation, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: recalcShippingTotal, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: recalcTaxTotal, triggered by rule on Service: changeOrderItemStatus
>>
>> SECA: resetGrandTotal, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: checkOrderItemStatus, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: sendOrderChangeNotification, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: recreateOrderAdjustments, triggered by rule on Service:
>> cancelOrderItem
>>
>> Jonathon
>>
>
>
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Scott Gray <le...@gmail.com>.
There's already a couple of jira issues in there, just filter by
Critical and you should find most of them. From memory the loop is the
last seca you mentioned, recreateOrderAdjustments which also happens to
call cancelOrderItem so the seca gets fires again.
Jonathon -- Improov wrote:
> I have a few small questions related to the bigger question in email
> subject. I hope someone can answer those offhand. I hit a problem
> while testing (infinite loop), so I can't explore this aspect of OFBiz
> beyond the show-stopper.
>
> How does ofbiz handle revisions to SOs and POs? Any change histories
> kept?
>
> I see that shipping information can be changed. Again, any change
> histories kept? Is the "splitting preference" change reversible? I
> changed an SO to allow for split but couldn't reverse that decision.
>
> Any change histories for "Contact Information"?
>
> Ok, I'm done with my questions. And now, to share what I found about
> the infinite loop.
>
> Before I investigate further and post to JIRA, I'm wondering if
> someone can tell me quickly whether cancellation of order items for SO
> is supposed to work?
>
> To reproduce infinite loop, try ordering a PC001, then go to Order
> module and bring up SO, then try canceling an order item.
>
> Here's what I see as the contents of the loop (though I could be wrong
> and those calls could be correctly repeated SO MANY TIMES, unlikely?):
>
> SECA: cancelOrderInventoryReservation, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: recalcShippingTotal, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: recalcTaxTotal, triggered by rule on Service: changeOrderItemStatus
>
> SECA: resetGrandTotal, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: checkOrderItemStatus, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: sendOrderChangeNotification, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: recreateOrderAdjustments, triggered by rule on Service:
> cancelOrderItem
>
> Jonathon
>
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Scott Gray <le...@gmail.com>.
I'm saying your suggested fix of for the recursion won't work because
the current logic requires that the promo items be cancelled completely
(inventory reservations etc.) in case the promo is not reapplied to the
order. I guess you could do everything that cancelOrderItem does, but
i'm sure it won't work because I tried using a new service def to call
the cancelOrderItem method and the result was a mess of order items. I
think the whole process needs a review.
Regards
Scott
Chris Howe wrote:
> My eyes are getting tired and I'm not positive I'm
> reading that right.
>
> Are you suggesting that there are two issues going on?
> One of recursion and one of inefficiency? Or are you
> suggesting that even if the recursion is handled, the
> logic bringing you to the end result is still wrong?
>
> If it's two separate issues, can we address the
> critical of recursion now and save the minor issue of
> efficiency for later?
>
> If the end result is inaccurate, I think I'm in your
> boat with the limited time.
>
>
>
> --- Scott Gray <le...@gmail.com> wrote:
>
>
>> But that wouldn't that only work if the promo line
>> is to be reapplied?
>> If the promo no longer applies to the order
>> cancelOrderItem and
>> everything that goes with it needs to be used. I
>> can't see why the cart
>> is reloaded when you already have a cart in hand,
>> why not compare the
>> updated cart to the order and update items as
>> necessary rather than
>> rebuilding the adjustments from scratch?
>>
>> Chris Howe wrote:
>>
>>> Ahh...I see now. recreateOrderAdjustments is
>>>
>> doing a
>>
>>> sort of fake cancellation but using the big boy
>>> services to accomplish it.
>>>
>>> Perhaps it would be better to have the
>>>
>> simple-method
>>
>>> update the OrderItem and create the
>>>
>> OrderItemStatus on
>>
>>> it's own in that iteration section and not bother
>>>
>> with
>>
>>> the service calls (with a comment as to why it's
>>>
>> being
>>
>>> done this way)?
>>>
>>> Sound good?
>>>
>>> --- Scott Gray <le...@gmail.com> wrote:
>>>
>>>
>>>
>>>> I did try option 3 a while back but there are
>>>>
>> still
>>
>>>> other problems with
>>>> the code, for example I think an order
>>>>
>> notification
>>
>>>> is triggered as a
>>>> seca on cancelOrderItem and also on
>>>> changeOrderItemStatus which results
>>>> in a ton of emails being generated.
>>>>
>>>>
>>>>> There ;-) that's a loop. There should be two
>>>>>
>> ways
>>
>>>>>
>>>>>
>>>> to
>>>>
>>>>
>>>>> at least put a bandaid on it (and it may
>>>>>
>> actually
>>
>>>>>
>>>>>
>>>> fix
>>>>
>>>>
>>>>> it entirely).
>>>>>
>>>>> You can either check that the order item isn't
>>>>> currently canceled or you can call the java
>>>>>
>> method
>>
>>>>> directly so that the SECA won't trigger.
>>>>>
>>>>> both solutions are attached.
>>>>>
>>>>> A third way is to make a second cancel order
>>>>>
>> item
>>
>>>>>
>>>>>
>>>> that
>>>>
>>>>
>>>>> does the exact same thing but by a different
>>>>>
>> name.
>>
>>>>>
>>>>>
>>>> I
>>>>
>>>>
>>>>> would think this redundancy is less desirable
>>>>>
>> than
>>
>>>>>
>>>>>
>>>> the
>>>>
>>>>
>>>>> other two.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Posted by Chris Howe <cj...@yahoo.com>.
My eyes are getting tired and I'm not positive I'm
reading that right.
Are you suggesting that there are two issues going on?
One of recursion and one of inefficiency? Or are you
suggesting that even if the recursion is handled, the
logic bringing you to the end result is still wrong?
If it's two separate issues, can we address the
critical of recursion now and save the minor issue of
efficiency for later?
If the end result is inaccurate, I think I'm in your
boat with the limited time.
--- Scott Gray <le...@gmail.com> wrote:
> But that wouldn't that only work if the promo line
> is to be reapplied?
> If the promo no longer applies to the order
> cancelOrderItem and
> everything that goes with it needs to be used. I
> can't see why the cart
> is reloaded when you already have a cart in hand,
> why not compare the
> updated cart to the order and update items as
> necessary rather than
> rebuilding the adjustments from scratch?
>
> Chris Howe wrote:
> > Ahh...I see now. recreateOrderAdjustments is
> doing a
> > sort of fake cancellation but using the big boy
> > services to accomplish it.
> >
> > Perhaps it would be better to have the
> simple-method
> > update the OrderItem and create the
> OrderItemStatus on
> > it's own in that iteration section and not bother
> with
> > the service calls (with a comment as to why it's
> being
> > done this way)?
> >
> > Sound good?
> >
> > --- Scott Gray <le...@gmail.com> wrote:
> >
> >
> >> I did try option 3 a while back but there are
> still
> >> other problems with
> >> the code, for example I think an order
> notification
> >> is triggered as a
> >> seca on cancelOrderItem and also on
> >> changeOrderItemStatus which results
> >> in a ton of emails being generated.
> >>
> >>> There ;-) that's a loop. There should be two
> ways
> >>>
> >> to
> >>
> >>> at least put a bandaid on it (and it may
> actually
> >>>
> >> fix
> >>
> >>> it entirely).
> >>>
> >>> You can either check that the order item isn't
> >>> currently canceled or you can call the java
> method
> >>> directly so that the SECA won't trigger.
> >>>
> >>> both solutions are attached.
> >>>
> >>> A third way is to make a second cancel order
> item
> >>>
> >> that
> >>
> >>> does the exact same thing but by a different
> name.
> >>>
> >> I
> >>
> >>> would think this redundancy is less desirable
> than
> >>>
> >> the
> >>
> >>> other two.
> >>>
> >>>
> >>
> >
> >
> >
>
>
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Scott Gray <le...@gmail.com>.
But that wouldn't that only work if the promo line is to be reapplied?
If the promo no longer applies to the order cancelOrderItem and
everything that goes with it needs to be used. I can't see why the cart
is reloaded when you already have a cart in hand, why not compare the
updated cart to the order and update items as necessary rather than
rebuilding the adjustments from scratch?
Chris Howe wrote:
> Ahh...I see now. recreateOrderAdjustments is doing a
> sort of fake cancellation but using the big boy
> services to accomplish it.
>
> Perhaps it would be better to have the simple-method
> update the OrderItem and create the OrderItemStatus on
> it's own in that iteration section and not bother with
> the service calls (with a comment as to why it's being
> done this way)?
>
> Sound good?
>
> --- Scott Gray <le...@gmail.com> wrote:
>
>
>> I did try option 3 a while back but there are still
>> other problems with
>> the code, for example I think an order notification
>> is triggered as a
>> seca on cancelOrderItem and also on
>> changeOrderItemStatus which results
>> in a ton of emails being generated.
>>
>>> There ;-) that's a loop. There should be two ways
>>>
>> to
>>
>>> at least put a bandaid on it (and it may actually
>>>
>> fix
>>
>>> it entirely).
>>>
>>> You can either check that the order item isn't
>>> currently canceled or you can call the java method
>>> directly so that the SECA won't trigger.
>>>
>>> both solutions are attached.
>>>
>>> A third way is to make a second cancel order item
>>>
>> that
>>
>>> does the exact same thing but by a different name.
>>>
>> I
>>
>>> would think this redundancy is less desirable than
>>>
>> the
>>
>>> other two.
>>>
>>>
>>
>
>
>
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Posted by Chris Howe <cj...@yahoo.com>.
Ahh...I see now. recreateOrderAdjustments is doing a
sort of fake cancellation but using the big boy
services to accomplish it.
Perhaps it would be better to have the simple-method
update the OrderItem and create the OrderItemStatus on
it's own in that iteration section and not bother with
the service calls (with a comment as to why it's being
done this way)?
Sound good?
--- Scott Gray <le...@gmail.com> wrote:
> I did try option 3 a while back but there are still
> other problems with
> the code, for example I think an order notification
> is triggered as a
> seca on cancelOrderItem and also on
> changeOrderItemStatus which results
> in a ton of emails being generated.
> > There ;-) that's a loop. There should be two ways
> to
> > at least put a bandaid on it (and it may actually
> fix
> > it entirely).
> >
> > You can either check that the order item isn't
> > currently canceled or you can call the java method
> > directly so that the SECA won't trigger.
> >
> > both solutions are attached.
> >
> > A third way is to make a second cancel order item
> that
> > does the exact same thing but by a different name.
> I
> > would think this redundancy is less desirable than
> the
> > other two.
> >
>
>
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Scott Gray <le...@gmail.com>.
I did try option 3 a while back but there are still other problems with
the code, for example I think an order notification is triggered as a
seca on cancelOrderItem and also on changeOrderItemStatus which results
in a ton of emails being generated.
> There ;-) that's a loop. There should be two ways to
> at least put a bandaid on it (and it may actually fix
> it entirely).
>
> You can either check that the order item isn't
> currently canceled or you can call the java method
> directly so that the SECA won't trigger.
>
> both solutions are attached.
>
> A third way is to make a second cancel order item that
> does the exact same thing but by a different name. I
> would think this redundancy is less desirable than the
> other two.
>
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Posted by Chris Howe <cj...@yahoo.com>.
--- Jonathon -- Improov <jo...@improov.com> wrote:
> I suppose I should've included a final line like
> this:
>
> SimpleMethod.call-service: recreateOrderAdjustments
> (OrderServices.xml line 473) calls Service
> cancelOrderItem
>
> ?
>
There ;-) that's a loop. There should be two ways to
at least put a bandaid on it (and it may actually fix
it entirely).
You can either check that the order item isn't
currently canceled or you can call the java method
directly so that the SECA won't trigger.
both solutions are attached.
A third way is to make a second cancel order item that
does the exact same thing but by a different name. I
would think this redundancy is less desirable than the
other two.
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Jonathon -- Improov <jo...@improov.com>.
Chris,
This is what Scott wrote on OFBIZ-431:
"The infinite loop occurs when the cancelOrderItem service is called on an order containing promo
order items. There is a seca on the service which calls recreateOrderAdjustments, which in turn
iterates through all the promo items and calls cancelOrderItem on them, and on we go into the loop."
I'd guess that Scott meant there's "a seca on the service [cancelOrderItem] which calls [service]
recreateOrderAdjustments".
I'd further guess (no, Scott stated this, actually) that the service recreateOrderAdjustments
calls (aka trigger?) cancelOrderItem. So, if recreateOrderAdjustments is event A and
cancelOrderItem is event B, I'd say A triggers B, which in turn triggers A.
Let's see, here's what I wrote:
SECA: cancelOrderInventoryReservation, triggered by rule on Service: changeOrderItemStatus
SECA: recalcShippingTotal, triggered by rule on Service: changeOrderItemStatus
SECA: recalcTaxTotal, triggered by rule on Service: changeOrderItemStatus
SECA: resetGrandTotal, triggered by rule on Service: changeOrderItemStatus
SECA: checkOrderItemStatus, triggered by rule on Service: changeOrderItemStatus
SECA: sendOrderChangeNotification, triggered by rule on Service: changeOrderItemStatus
SECA: recreateOrderAdjustments, triggered by rule on Service: cancelOrderItem
I suppose I should've included a final line like this:
SimpleMethod.call-service: recreateOrderAdjustments (OrderServices.xml line 473) calls Service
cancelOrderItem
?
Sorry? :P Please? I must be tired when I wrote the above "contents of the loop". So it's not
exactly a loop.
Jonathon
Chris Howe wrote:
> Jonathon,
>
> What I just repeated back to you is linear. Would you
> care to share the service call that is showing it
> looping? It doesn't appear to be listed there.
>
> --- Jonathon -- Improov <jo...@improov.com> wrote:
>
>> Chris,
>>
>> Erm. Yeah, it looks incomplete to me. Sorry!
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> What you explained was this though...
>>>
>>> A=changeOrderItemStatus
>>> B=cancelOrderInventoryReservation
>>> C=recalcShippingTotal
>>> D=recalcTaxTotal
>>> E=resetGrandTotal
>>> F=checkOrderItemStatus
>>> G=sendOrderChangeNotification
>>> H=recreateOrderAdjustments
>>> I=cancelOrderItem
>>>
>>> A triggers B & C & D & E & F & G
>>> H triggers I
>>>
>>> is this incomplete?
>>>
>>>>>> SECA: cancelOrderInventoryReservation,
>> triggered
>>>> by
>>>>>> rule on Service: changeOrderItemStatus
>>>>>>
>>>>>> SECA: recalcShippingTotal, triggered by rule on
>>>>>> Service: changeOrderItemStatus
>>>>>>
>>>>>> SECA: recalcTaxTotal, triggered by rule on
>>>> Service:
>>>>>> changeOrderItemStatus
>>>>>>
>>>>>> SECA: resetGrandTotal, triggered by rule on
>>>> Service:
>>>>>> changeOrderItemStatus
>>>>>>
>>>>>> SECA: checkOrderItemStatus, triggered by rule
>> on
>>>>>> Service: changeOrderItemStatus
>>>>>>
>>>>>> SECA: sendOrderChangeNotification, triggered by
>>>> rule
>>>>>> on Service: changeOrderItemStatus
>>>>>>
>>>>>> SECA: recreateOrderAdjustments, triggered by
>> rule
>>>> on
>>>>>> Service: cancelOrderItem
>>>
>>
>
>
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Posted by Chris Howe <cj...@yahoo.com>.
Jonathon,
What I just repeated back to you is linear. Would you
care to share the service call that is showing it
looping? It doesn't appear to be listed there.
--- Jonathon -- Improov <jo...@improov.com> wrote:
> Chris,
>
> Erm. Yeah, it looks incomplete to me. Sorry!
>
> Jonathon
>
> Chris Howe wrote:
> > What you explained was this though...
> >
> > A=changeOrderItemStatus
> > B=cancelOrderInventoryReservation
> > C=recalcShippingTotal
> > D=recalcTaxTotal
> > E=resetGrandTotal
> > F=checkOrderItemStatus
> > G=sendOrderChangeNotification
> > H=recreateOrderAdjustments
> > I=cancelOrderItem
> >
> > A triggers B & C & D & E & F & G
> > H triggers I
> >
> > is this incomplete?
> >
> >>>> SECA: cancelOrderInventoryReservation,
> triggered
> >> by
> >>>> rule on Service: changeOrderItemStatus
> >>>>
> >>>> SECA: recalcShippingTotal, triggered by rule on
> >>>> Service: changeOrderItemStatus
> >>>>
> >>>> SECA: recalcTaxTotal, triggered by rule on
> >> Service:
> >>>> changeOrderItemStatus
> >>>>
> >>>> SECA: resetGrandTotal, triggered by rule on
> >> Service:
> >>>> changeOrderItemStatus
> >>>>
> >>>> SECA: checkOrderItemStatus, triggered by rule
> on
> >>>> Service: changeOrderItemStatus
> >>>>
> >>>> SECA: sendOrderChangeNotification, triggered by
> >> rule
> >>>> on Service: changeOrderItemStatus
> >>>>
> >>>> SECA: recreateOrderAdjustments, triggered by
> rule
> >> on
> >>>> Service: cancelOrderItem
> >
> >
>
>
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Jonathon -- Improov <jo...@improov.com>.
Chris,
Erm. Yeah, it looks incomplete to me. Sorry!
Jonathon
Chris Howe wrote:
> What you explained was this though...
>
> A=changeOrderItemStatus
> B=cancelOrderInventoryReservation
> C=recalcShippingTotal
> D=recalcTaxTotal
> E=resetGrandTotal
> F=checkOrderItemStatus
> G=sendOrderChangeNotification
> H=recreateOrderAdjustments
> I=cancelOrderItem
>
> A triggers B & C & D & E & F & G
> H triggers I
>
> is this incomplete?
>
>>>> SECA: cancelOrderInventoryReservation, triggered
>> by
>>>> rule on Service: changeOrderItemStatus
>>>>
>>>> SECA: recalcShippingTotal, triggered by rule on
>>>> Service: changeOrderItemStatus
>>>>
>>>> SECA: recalcTaxTotal, triggered by rule on
>> Service:
>>>> changeOrderItemStatus
>>>>
>>>> SECA: resetGrandTotal, triggered by rule on
>> Service:
>>>> changeOrderItemStatus
>>>>
>>>> SECA: checkOrderItemStatus, triggered by rule on
>>>> Service: changeOrderItemStatus
>>>>
>>>> SECA: sendOrderChangeNotification, triggered by
>> rule
>>>> on Service: changeOrderItemStatus
>>>>
>>>> SECA: recreateOrderAdjustments, triggered by rule
>> on
>>>> Service: cancelOrderItem
>
>
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Posted by Chris Howe <cj...@yahoo.com>.
What you explained was this though...
A=changeOrderItemStatus
B=cancelOrderInventoryReservation
C=recalcShippingTotal
D=recalcTaxTotal
E=resetGrandTotal
F=checkOrderItemStatus
G=sendOrderChangeNotification
H=recreateOrderAdjustments
I=cancelOrderItem
A triggers B & C & D & E & F & G
H triggers I
is this incomplete?
> >> SECA: cancelOrderInventoryReservation, triggered
> by
> >> rule on Service: changeOrderItemStatus
> >>
> >> SECA: recalcShippingTotal, triggered by rule on
> >> Service: changeOrderItemStatus
> >>
> >> SECA: recalcTaxTotal, triggered by rule on
> Service:
> >> changeOrderItemStatus
> >>
> >> SECA: resetGrandTotal, triggered by rule on
> Service:
> >> changeOrderItemStatus
> >>
> >> SECA: checkOrderItemStatus, triggered by rule on
> >> Service: changeOrderItemStatus
> >>
> >> SECA: sendOrderChangeNotification, triggered by
> rule
> >> on Service: changeOrderItemStatus
> >>
> >> SECA: recreateOrderAdjustments, triggered by rule
> on
> >> Service: cancelOrderItem
>
Re: Can SOs and POs be edited, and if so, any change histories for
edits of SOs and POs?
Posted by Jonathon -- Improov <jo...@improov.com>.
Chris,
Er, ok, to correct myself, I meant to say that there's an infinite loop possibly caused by cyclic
dependencies in the SECAs. So suppose we have these events:
A. Postman rings my doorbell
B. I answer the front door
C. My dog growls
D. Postman leaves my front door
E. I close front door and get back to my chores
F. My dog goes back to his toys
Then consider these SECAs:
1. A triggers B and C
2. C triggers D
3. D triggers E and F
4. E and F triggers A
You don't encounter this infinite... erm... execution of this set of services? This... "loop"
thing? I pretty sure cancellation of order items in an SO doesn't complete execution.
Jonathon
Chris Howe wrote:
> Regarding your "infinite loop", there is no loop.
> Each of those services are being called because the
> service changeOrderItemStatus ran (and certain
> conditions for each of the SECAs were met)
> --- Jonathon -- Improov <jo...@improov.com> wrote:
>
>> I have a few small questions related to the bigger
>> question in email subject. I hope someone can
>> answer those offhand. I hit a problem while testing
>> (infinite loop), so I can't explore this
>> aspect of OFBiz beyond the show-stopper.
>>
>> How does ofbiz handle revisions to SOs and POs? Any
>> change histories kept?
>>
>> I see that shipping information can be changed.
>> Again, any change histories kept? Is the
>> "splitting preference" change reversible? I changed
>> an SO to allow for split but couldn't reverse
>> that decision.
>>
>> Any change histories for "Contact Information"?
>>
>> Ok, I'm done with my questions. And now, to share
>> what I found about the infinite loop.
>>
>> Before I investigate further and post to JIRA, I'm
>> wondering if someone can tell me quickly
>> whether cancellation of order items for SO is
>> supposed to work?
>>
>> To reproduce infinite loop, try ordering a PC001,
>> then go to Order module and bring up SO, then
>> try canceling an order item.
>>
>> Here's what I see as the contents of the loop
>> (though I could be wrong and those calls could be
>> correctly repeated SO MANY TIMES, unlikely?):
>>
>> SECA: cancelOrderInventoryReservation, triggered by
>> rule on Service: changeOrderItemStatus
>>
>> SECA: recalcShippingTotal, triggered by rule on
>> Service: changeOrderItemStatus
>>
>> SECA: recalcTaxTotal, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: resetGrandTotal, triggered by rule on Service:
>> changeOrderItemStatus
>>
>> SECA: checkOrderItemStatus, triggered by rule on
>> Service: changeOrderItemStatus
>>
>> SECA: sendOrderChangeNotification, triggered by rule
>> on Service: changeOrderItemStatus
>>
>> SECA: recreateOrderAdjustments, triggered by rule on
>> Service: cancelOrderItem
>>
>> Jonathon
>>
>
>
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Posted by Chris Howe <cj...@yahoo.com>.
Regarding your "infinite loop", there is no loop.
Each of those services are being called because the
service changeOrderItemStatus ran (and certain
conditions for each of the SECAs were met)
--- Jonathon -- Improov <jo...@improov.com> wrote:
> I have a few small questions related to the bigger
> question in email subject. I hope someone can
> answer those offhand. I hit a problem while testing
> (infinite loop), so I can't explore this
> aspect of OFBiz beyond the show-stopper.
>
> How does ofbiz handle revisions to SOs and POs? Any
> change histories kept?
>
> I see that shipping information can be changed.
> Again, any change histories kept? Is the
> "splitting preference" change reversible? I changed
> an SO to allow for split but couldn't reverse
> that decision.
>
> Any change histories for "Contact Information"?
>
> Ok, I'm done with my questions. And now, to share
> what I found about the infinite loop.
>
> Before I investigate further and post to JIRA, I'm
> wondering if someone can tell me quickly
> whether cancellation of order items for SO is
> supposed to work?
>
> To reproduce infinite loop, try ordering a PC001,
> then go to Order module and bring up SO, then
> try canceling an order item.
>
> Here's what I see as the contents of the loop
> (though I could be wrong and those calls could be
> correctly repeated SO MANY TIMES, unlikely?):
>
> SECA: cancelOrderInventoryReservation, triggered by
> rule on Service: changeOrderItemStatus
>
> SECA: recalcShippingTotal, triggered by rule on
> Service: changeOrderItemStatus
>
> SECA: recalcTaxTotal, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: resetGrandTotal, triggered by rule on Service:
> changeOrderItemStatus
>
> SECA: checkOrderItemStatus, triggered by rule on
> Service: changeOrderItemStatus
>
> SECA: sendOrderChangeNotification, triggered by rule
> on Service: changeOrderItemStatus
>
> SECA: recreateOrderAdjustments, triggered by rule on
> Service: cancelOrderItem
>
> Jonathon
>