Business Unit.Object.Subsidiary: unlearning JD Edwards' concatenated account key

Why JD Edwards' GL account key is a literal concatenated string — Business Unit, Object and Subsidiary fused together — and how it decomposes into a D365 main account plus financial dimensions, including the structural fault line between F0902's independently maintained balances and F0911's transaction detail that has no D365 equivalent at all.

What you will be able to do

Introduction

If there is one chapter in this entire migration path that a JD Edwards practitioner needs to read slowly, it is this one. Every other object in the previous two chapters — Company, Business Unit, Address Book — has a reasonably legible D365 counterpart, even where the shape changes. The GL account key does not.

The account key: Business Unit.Object.Subsidiary as a literal string

Every JDE general ledger transaction posts to an account expressed as Business Unit.Object.Subsidiary — commonly written MCU.OBJ.SUB, for example 30.4110.000. This is not shorthand for "these three fields, considered together." It is the account: one positional value, parsed into its three segments by position and length, stored that way…

Object, Business Unit, Subsidiary: deciding what becomes what in D365

The decomposition is not symmetric across the three segments, and each deserves its own decision.

Account ID and the third account format

Two further wrinkles are worth knowing about, even though neither changes the core decomposition much.

Flex Accounting: why the decomposition gets harder

Flex Accounting lets JDE substitute the Object or Subsidiary segment of the account key automatically, at transaction time, based on a rule that can reference values from essentially any related table — resolving a manufacturing transaction's Subsidiary from the item number, for instance, or redirecting certain transaction types to a…

F0901, level of detail, and posting edit codes vs D365 rollups

The Account Master (F0901) carries two further mechanisms worth understanding on their own terms.

The structural fault line: F0902 balances vs F0911 detail

This is the single most important structural fact in this chapter, and it deserves to be stated plainly before the worked example: JDE maintains account balances and account transaction detail as two separate tables, and they can diverge.

Worked account-key decomposition

Take a representative account, 30.4220.EQ105, posted by a distribution company: Business Unit 30 (the West-region distribution Branch/Plant from the previous chapter's worked example), Object 4220 (equipment maintenance expense), and Subsidiary EQ105 identifying one specific piece of material-handling equipment, with a Posting Edit Code…

Knowledge check

Summary

The JDE account key is not three fields that travel together — it is one literal, concatenated value, and unlearning that is the precondition for everything else in this chapter. Object decomposes cleanly into the D365 main account;