Order Detail Groups and Ordre Level Adjustments

Hi List,

Here`s another advanced pricing question (At least until Andy Klee's workbook arrives next week!! I can't wait)

Normaly OneWorld will NOT allow an 'Order Level' adjustment definition to include an Order Detail Group. It gives an error saying that the complex groups must be left blank for Basket or Order level repricing.

However, I have figured out a way to attach a Detail Group to an order level adjustment and it actually works as it would with line level adjustments!!!

This happened by fluke one day!!
1)Create a line level adjustment with an 'Order Detail Group' and adjustment code '2'.
2)Then return to the definition and change the adjustment code to 3 and make it an order level adjustment.
3)Voila your order level adjustment now works with an 'Order Detail Group'

I'm looking for any possible problems with this (Real or Imaginary)

Thanks
Sean Gilbert
PWC Consulting


XE SP17.1_H1, AIX, Oracle8.1.7, JAS(17.1_H1) AIX, WebSphere3.5

Sean, people are going to think I'm paying you if you keep pumping everyone
up about my books. For the record I am not! If what you are saying is

Re: RE: Order Detail Groups and Ordre Level Adjustments

Oh my gawd. . .they killed Andy!. . . . you bastards!!



Hehehehehe. . .ahem, pardon me.

Anyhow, Sean, what you've described isn't going to work and here's why:

Under the covers, Order Groups work by accumulating the sales detail line information by Order Key (DOCO DCTO KCOO LNID) and Order Group. So, if you have two groups on an order, the system will Sum those two groups into two 'virtual detail lines' that are then passed individually to the Advanced Pricing BSFN. In this case, the Adv Pric. BSFN will be called twice and the results spread back out to the real component lines.

Ok, so why can't what you described work? Consider this; you have a dynamic group defined as MOT (mode of transport). Oh yeah, let me point out that I'm making this example up off the top of my head. Back to the example: now, you enter two lines that you expect to be part of this 'dynamic order group', BUT (and there always is one) one line is going by Ship and the other by Truck! So, the system reads the first line and saves it, then reads the second and adds it to the first. Here's the rub, which MOT is going to be written to the 'summation' line? Will it be Truck, or will it be Ship? Which SHOULD it be? Ship and Truck have different prices entirely, by the way.

When the pricing BSFN gets that summation line it can have only one MOT in it.

The answer is this: It gets whatever was entered into SOE first. If the truck line is first, it gets priced as a Truck and vice-versa.

JDE can't know which is 'supposed' to be prefered, so they just prevent you from doing it. I hope that all makes sense.


"The preceding was made possible by a grant from the Chub Group and Whipping Boy Industries (an author of Advanced Pricing. . . .)"

Darren Ricciardi - OneWorld Whipping Boy

Looking for work WEST of DENVER

Home of OWTEK: http://www.cris.com/~grzero