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 <[EMAIL PROTECTED]> 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. > > > >
