A JD Edwards EnterpriseOne object promotion checklist for DV, PY and PD environments is the single piece of process documentation that separates installations where production is calm from installations where every Tuesday morning is a fire drill. The difference is never the talent of the developers; the difference is whether everyone agrees on what has to be true before an object can move from one environment to the next, and whether someone checks each item before the OMW status changes.
I have walked into shops where the promotion process was "ask Marco if it's ready" and shops where it was a thirty-item checklist printed on the wall above the CNC's desk. The second kind has fewer outages, faster recoveries, and developers who do not dread Monday deployments. The checklist itself is not the magic — the magic is that everyone, including the developer, the lead, the CNC, and the business owner, knows what is going to be verified before the change reaches PD.
What DV, PY and PD actually exist for
The three-environment model in JDE E1 looks the same on every installation and means something slightly different on every installation. DV (development) is where unstable code lives — code that may not compile, may break the form it touches, may corrupt test data. The only contract DV makes is that whatever lives there is owned by a developer who can fix it. PYPrototype (or Pristine) environment — the JDE testing tier where promoted code is exercised against a near-production data copy before being moved to PD. The "Y" comes from the legacy Pristine/Pristine-Yes path code. is where stable code that has passed peer review lives, exercised against data that resembles production closely enough to find the bugs that DV never sees. PD (production) is where the business runs, where the contract is uptime and correctness.
The mistake I see most often is treating PY as "DV with better data". It is not. PY is a release candidate environment, and code in PY has already passed a gate. If three developers are checking unfinished work into PY because "it's just the test environment", the gate has been moved to between PY and PD, and PY no longer does its job. The functional test team starts finding bugs that should have been caught in DV, regression cycles balloon, and the promotion-to-PD cadence drops from weekly to monthly.
Each environment lives in its own path code — DV920, PY920, PD920 on a 9.2 installation, with corresponding business data tables in environments like DV920FA, PY920FA, PD920FA. The checklist below assumes that mapping; if your shop uses non-standard names, substitute, but the gates and ordering stay the same.
The DV-to-PY gate: what must be true before code leaves the developer's hands
The first promotion gate is where most of the value lives, because mistakes caught here cost minutes, whereas the same mistakes caught at the PY-to-PD gate cost days. Before any object moves from DV to PY through an OMWObject Management Workbench — the JDE tool that manages object check-in, check-out, project membership, and status transitions across DV, PY and PD path codes. status change, the checklist for this gate has roughly six items.
The object must compile cleanly in DV — for BSFNs and table conversions this is non-negotiable, and the build log must show zero errors and zero warnings (the warning bar matters; warnings in C BSFNs become runtime crashes far more often than developers admit). The spec merge against the latest standard ESU baseline must be reviewed — particularly for retrofit objects, where the standard might have shifted since the developer last refreshed. The data structure used by the function or application must be checked against the calling sites; a new field added to a DS will break every caller that has not been recompiled, and recompilation order is part of the promotion plan, not an afterthought.
The OMW project must contain every object touched, not just the headline object — the form that calls the new BSFN, the data structure the BSFN takes, the UDC table the new code reads, the F7900 error message rows added for the new error codes. A project that promotes the BSFN but forgets the new F7900 row will fail at runtime in PY with a blank error message that takes the on-call engineer an hour to trace.
Peer review is the human gate that catches what tooling cannot. A second developer reading the change, even for ten minutes, finds the assumption the original developer did not notice — the hardcoded company number, the date comparison that breaks across year-end, the lookup that returns the first row when it should aggregate. Status 25 in OMW is the convention for "peer-reviewed and ready to promote"; the convention only works if every developer respects it.
The PY-to-PD gate: where business risk is actually managed
The second gate is where the promotion checklist earns its weight. Code that has cleared DV-to-PY is technically correct in isolation; clearing PY-to-PD requires that it works alongside everything else in production and that the deployment itself will not break the business.
The first item on this gate is the testing sign-off. Whoever owns the affected business process — order entry, invoicing, payroll, inventory replenishment — must have personally signed that the PY behaviour matches what they expect. Not "the development team thinks it works"; the business owner who will absorb the support tickets if it goes wrong. Without this sign-off, the developer is the only person who has touched the code, and the only person who will be blamed when it breaks.
The package build plan must be explicit before the gate opens. Update package, foundation package, or full package? Update suffices for ER and form changes. Foundation is mandatory whenever compiled C BSFN code has changed — and "mandatory" means a server bounce, which means a coordinated downtime window. A full package is reserved for Tools Release changes and quarterly cumulative deployments. Picking the wrong package type either fails to deliver the change (update without foundation when C changed) or costs the business an unnecessary outage (full when update would have sufficed).
The rollback plan must be written before the change is promoted, not after the alarm goes off. For ER changes, rollback is an OMW restore of the previous object version. For C BSFN changes, rollback is a re-promotion of the previous foundation package, which can take the same 30–60 minutes the original install took. For data dictionary changes that affect many forms, there may be no clean rollback, which is the kind of fact that needs to be on the gate checklist, not discovered when something breaks at 02:00.
Co-existence checks: when the new object meets the rest of PD
The hidden risk in promotion is rarely in the new object itself; it is in the interaction between the new object and the dozens of standard and custom objects already in PD. The checklist needs an explicit pass for these interactions, because nothing else will catch them.
Spec merge state is the first co-existence check. If the new object inherits from a standard object that has shifted between when the developer started and when promotion is scheduled, the spec merge must be re-run, the diff reviewed, and any conflict resolved. Skipping this step is how a custom P4210 modification that worked perfectly on 9.2.6 stops working when the shop applies the 9.2.8 cumulative — the standard form moved underneath the customisation.
BSFN call dependencies are the second. A new BSFN that calls existing BSFNs needs those callees verified in PD at the version the new code was tested against. A new field added to an existing data structure means every caller in the OMW project needs to be in the same promotion — and any caller outside the project needs to be identified, regression-tested, and either bundled in or explicitly cleared as unaffected.
UDC and data dictionary additions are the third. New UDC values for an existing UDC type are usually safe; new UDC types referenced by code are not, because the type must exist in F0004 in PD before the code that reads it runs. The checklist item here is "verify every new F0004 and F0005 row required by the package exists in PD before the code that depends on it is promoted". Two minutes of pre-flight check, hours of avoided support work.
What happens at the moment of promotion to PD
The act of promotion itself is the most procedural step in the whole sequence, which is exactly why it is the step where ad-hoc decisions cause the most damage. Promotion to PD is a scheduled event, not a "let's do it now while it's quiet" event.
The window is announced in advance — to the operations team, to the business owners, to anyone whose batch jobs run during the window. The CNC team owns the actual OMW transfer and the package build; developers do not promote their own code to PD on any shop with proper segregation of duties, both because of audit requirements and because the person who wrote the code is the worst person to validate that it works in a clean environment.
The post-promotion verification is the last checklist item and the one most often skipped. Within the same maintenance window, a smoke test runs against the promoted change — one real-shape transaction through the affected path, end to end, against PD data with a flagged test account. The verification proves that the package built, deployed, and is callable. Without this step, the first time the new code runs in PD is when a real user hits it the next business morning, and any deployment problem becomes a production incident instead of a window-internal rollback.
For more on the operational side of JDE work, the related articles on Tools Release upgrade strategy, on retrofitting copies of standard, and on BSFN testing harnesses cover the surrounding territory. The technical project portfolio on this site documents two production deployments that produced the checklist patterns described here.