E1: 32: Configurator with PMTH 4 - Adjustment Schedule Change Does Not Cascade To Configured Children (Doc ID 2129284.1)

Last updated on DECEMBER 14, 2016

Applies to:

JD Edwards EnterpriseOne Configurator - Version 9.0 and later
Information in this document applies to any platform.

Symptoms

EnterpriseOne 9.0
With a scenario in which configurator pricing is defined based on advanced pricing discounted values of configured component items, if the Advanced Pricing Schedule is changed for the configured parent sales detail line, the system is not cascading the change to the Price History of the components. Subsequently, the components prices are still based on the initial (or Sales Header) Adjustment Schedule instead of the overridden Adjustment Schedule which is done either via on the Sales Order Detail in Power Form P42101, or through the Sales Order Additional Info Row exit when using P4210.

Upon changing the Adjustment Schedule which is considered a "price-sensitive" field, the system is not considering it as a "configurator-sensitive" field, and not prompting the Configured Item Revisions (P3210). However, when intentionally prompting the P3210 form, and accepting the configuration and sales order change, the system is NOT updating the Adjustment Schedule of the components. This is a significant issue when defining the Kit/Configurator Pricing Method (alias PMTH) in the Item Master (P4101) as '4' for the parent configured item. With a '4' defined, the system is to calculate the configured parent's price based on the discounted price of the components. As the revised Adjustment Schedule is not being changed for the components, the desired price is not being returned.

Two issues are present with the scenario defined:
1. The system is not prompting the P3210 when the Adjustment Schedule is changed at the sales detail of the configured parent.
2. Even if the P3210 is manually prompted, the Adjustment Schedule change is not cascading to the component sales order detail lines.

Note - In this specific example, the issue is that pricing is dependent upon if the customer buys or leases the product which necessitates the need for two schedules. A potential option is to use X Rules based on a segment value to define pricing. This would require changing the PMTH from '4' to likely '3' to price only by X Rules.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms