JDE kit costs did not update after a same-day rerun

Customer name withheld. This example describes the work and results recorded for one engagement.

The problem behind the request

A consumer-products business needed to revise the way its JD Edwards custom processes calculated landed costs for kits. The work concerned freight and overhead components, the relationship between component costs and kit costs, and the rules used to select the correct values. For a delivery manager, the concern is whether a correction to source data will produce the expected result when the process runs again. The team was working toward reliable cost processing after corrections, so business users could move forward with figures they could check.

Understand the existing process before changing the calculation

The delivery record starts with analysis of three existing custom applications: the landed-cost component process, its work-file processing and the kit-component rollup. The specialist reviewed current behavior and dependencies, then defined an approach for deriving kit-level components using lookup logic and hierarchy rules. This mattered because the request affected an established process. A change had to fit the existing data writes and preserve the surrounding workflow.

Bring development and business testing together

The development work changed the processing logic to exclude selected components from component-level rollup and derive kit-level values according to the agreed rules. Unit testing included standard scenarios, different component structures and exceptions. The notes record issues found during testing, code corrections and further testing. Business users then joined an integration and acceptance-testing session to review freight and overhead behavior. Testing was part of delivering the change, rather than an assumption made after code was written.

Find the defect that the original request did not describe

During that testing, the team found a lookup issue when freight or overhead costs were not defined at the specific category level. The record describes several rounds of code changes and testing to address it. The same work exposed an existing defect: after source-data corrections, rerunning a kit-cost rollup on the same day did not update landed costs. The specialist corrected that behavior as part of the testing work. This is a concrete example of following the business process through its exceptions instead of stopping at the first requested modification.

What was delivered and validated

The linked workstream records analysis, development, bug fixes, unit testing, integration testing and documentation/deployment as closed. The deployment entry states that the production package was built and deployed successfully. The strongest supported result is a delivered costing change, tested with business users, with the lookup exception and same-day rerun defect addressed. The records reviewed do not quantify reduced month-end effort, improved margins or a recurring dollar saving; those would require a separate operating comparison.

What a delivery manager can take from this

The customer team brought the costing rules, context and test scenarios. Allari brought application analysis and development, worked through the exceptions with users, and carried the agreed change into production. The permanent rerun fix addressed the underlying behavior instead of leaving the team with a repeated correction task. The record does not measure the amount of repeat work avoided. Allari’s broader model places that work within coordinated delivery, customer priorities and an approved budget. An included Client Solutions Manager connects the appropriate specialists and keeps the work visible. For a similar costing issue, start with the failing scenario, expected business rule and acceptance test—then agree the scope and evidence needed to call it complete.