How JD Edwards EnterpriseOne's Order Activity Rules and Line Types govern sales and purchase order behaviour, why the Sales Update (R42800) batch is a single revenue-recognition event that D365 splits into two postings, why Advanced Pricing is honestly more configurable than D365 trade agreements, and how receipt routing and voucher match compare to D365 arrival, quality, and invoice matching.
Sales Order Management and Procurement in JD Edwards EnterpriseOne share a common architecture: a header table, a detail table, and a generic rules engine — Order Activity Rules, working together with Line Types — that decides what each order line is allowed to do and which status it moves to next.
The Sales Order header (F4201) carries customer, ship-to, terms, and order-level defaults; the Sales Order Detail (F4211) carries one row per line, with item, quantity, unit price, and the line-level status that drives everything downstream — inventory commitment, pick slip generation, shipment confirmation, and invoicing.
Two JDE constructs do the real work of shaping how a sales order behaves, and neither is visible from the F4201/F4211 table structure alone. The Line Type, assigned to each order detail line, is a code that bundles several behavioural switches together: whether the line interfaces to inventory, whether it interfaces to the general…
The Sales Update (R42800) is the batch program that turns a shipped sales order into its full financial consequence: it relieves inventory, records cost of goods sold, recognises revenue, updates the customer's accounts receivable balance, and advances the order to history — all in one run, against every eligible order sitting at the…
Advanced Pricing is one of the areas where JD Edwards is genuinely more capable than D365 out of the box, and a migration programme does its stakeholders a disservice by pretending otherwise.
JDE credit checking is driven by the customer master's credit limit fields together with the Hold Order Constants, which decide, by order type, whether a credit check runs at all, what happens when the limit is exceeded (a hold that blocks further processing, or merely a warning), and who is authorised to release a held order.
The Purchase Order header (F4301) and detail (F4311) mirror the sales side's structure exactly, and map to D365's PurchTable and PurchLine with the same close fidelity as F4201/F4211 map to SalesTable and SalesLine. The interesting differences on the buy side begin at the receiving dock.
JD Edwards was built, from its earliest releases, around a single universal party master: the Address Book (F0101). Every person, company, customer, supplier, and employee the system knows about is, first and foremost, an Address Book number, and role-specific records — the Customer Master (F03012) and Supplier Master (F0401) — are…
Sales Order Management and Procurement in JD Edwards share one architecture — header, detail, Order Activity Rules, and Line Type — applied to two different order types, and that architecture's flexibility is both its strength and the source of most of the migration effort covered in this chapter.