E9.1 Base Pricing To Not Allow Overlapping Dates

[richchipper]

Is there any method (without customization) to prevent a user from creating duplicate prices in the F4106 for an item/branch/customer group combination? We don't use JDE for sales order processing, but we use the table for our customized sales order process. We'd like to prevent a situation where the user creates overlapping active prices. Simple example - if I set a widget price for Chicago for my retail customer at $1.00 with effective dates from 1/1/2023 to 12/31/2023, the user should not be able to go in and create a price for the same widget for Chicago for retail customers for $2.00 starting 2/1/2023 (unless my effective thru on the first line is updated to be 1/31/2023). Any suggestions would be helpful.

 

[DaveWagoner]

What version are you on? If you're on one of the more recent versions you could hack something together with a form extension tied to an event PRIOR to the record being saved/committed, orchestration, and sneaky form-disable by kicking off an orchestration exception.

If you're not on a more recent version, if you want to PREVENT overlapping effective dates, then you're talking about customization. If there's any vector into your pricing table outside of JDE, then you're talking table trigger customization on the database level, which is horrid as you probably know.

If all else fails, you could do a regular integrity to catch anything AFTER the fact.

And if every single other thing else fails, you could set up your customized SO process to handle overlapping effective prices the same way as JDE.

It's all very fun

(I just now saw that you tagged your post E91... you might be outta luck on going with a preventative, non-customized solution)

 

[richchipper]

Wow - thanks for the fast reply. We are upgrading to 9.2 the first half of this year (thank the glorious heavens). Good to know. I'll talk with my consultants on the possibility. Thanks!