Loading units and empty returns

Purpose

This page describes loading-unit processes in Automotive with a focus on account holders, empty-return movements, reconciliation, and VDA-4927-related communication. It complements the existing HUM documentation with the automotive ownership and settlement context.

Difference from Handling Unit Management

Automotive uses loading units not only as physical packaging structures, but also as objects relevant for settlement and ownership. The general definition of packaging means, alternatives, and packaging logic is already described in Handling Unit Management.

For Automotive-specific assignment of pack-structure definitions, alternatives, and registered process structures, also use Pack structure management.

This page therefore focuses on the Automotive-specific aspects:

• account-holder and ownership logic
• empty-return movements and returns
• history and account reconciliation
• reports and evidence for open balances

Business value

• You assign loading units not only physically, but also to a business-relevant account holder.
• You post receipts, returns, and corrections in a way that allows later reconciliation of open empty-return balances.
• You use history, loading-unit accounts, and movement reports for operational and commercial traceability.
• You avoid typical reconciliation errors between physical stock and chargeable empty-return balances.

How this fits into standard Business Central

For loading units, Automotive replaces neither the standard stock logic in Business Central nor the general packaging logic from Handling Unit Management. The solution adds a second view to those standards: who is functionally responsible for the empty-return balance and how is that open balance reconciled with partners?

For end users, two levels matter:

• Standard BC view for items, locations, physical stock, inventory, and normal goods movements.
• Automotive view for account holders, empty-return movements, loading-unit account, history, and partner-based reconciliation.

graph LR;

%% Nodes
A[Physical movement in BC warehouse]
B[Assign account holder]
C[Post empty-return movement]
D[History and LE account]
E[Partner reconciliation]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

Keep this in mind in daily work: even if the physical movement is posted correctly in standard BC, the open empty-return balance can still be wrong. Reconciliation therefore also depends on the correct LE movement.

Which work pages the code provides

The current code provides these pages in particular for daily work:

This means the loading-unit logic is a dedicated work area with maintenance, posting, and reconciliation pages.

Process overview

graph LR;

%% Nodes
A[Assign goods or packaging]
B[Set account holder]
C[Post empty-return movement]
D[Check history and movements]
E[Reconcile loading-unit account and reports]
F[Clarify deviations or returns]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

Account holder as the key control attribute

The account holder defines to whom a loading unit belongs from a business perspective. This is not only about the physical location, but also about whose balance or claim becomes relevant in later reconciliation.

For this, the LE Account Keeper page shows in code:

• the affected loading-unit item through Item No.
• the business relation through Relation Type
• the related business partner through Relation to Code
• the actual account-holder logic through Account Keeper Type and Account Keeper

In addition, the relation name and account-holder name are resolved automatically from customer, vendor, or shipping agent. Users therefore see the real partner, not only internal codes.

Check for each assignment:

• does the loading unit belong to the customer, vendor, shipper, or another partner?
• is the assignment defined already during packaging or only in a downstream process?
• is the account-holder change documented if responsibility changes?

An incorrect or missing account holder is often detected only during monthly reconciliation and then requires significant clarification effort.

Post empty-return movements correctly

For receipts and returns of empty packaging, the correct document type is critical. The public legacy documentation makes clear that only the dedicated empty-return movement carries the account holder correctly into the posting logic.

In code, the Loading Equipment Empties Movement page is implemented as a dedicated document with document type Return. There you maintain in particular:

• Account Keeper Type and Account Keeper
• Your Reference
• Posting Date
• Document No.
• Location Code and, where relevant, Bin Code
• the related movement lines in the subpage

For posting, one point is critical: before posting, the code explicitly checks the Location Code. Without a location, the document will not be processed.

Receipts

Use the intended document for empty-return receipts when loading units with account-holder relevance are brought into the system. Only then does the later reconciliation between movement, stock, and responsibility remain traceable.

Returns

Returns, especially for defective or excess loading units, are recorded as counter-movements. In each case, it must remain clear whether this is a normal return, a correction, or a special case related to a complaint.

Use negative quantities deliberately

When returns or counter-postings are represented with negative quantities, check especially carefully that direction, partner reference, and print output of the return document are correct.

In addition, the document provides a dedicated Print action for the movement voucher. Use that printout or resulting document deliberately as evidence during partner clarifications.

Addition from automotive training material: fixed-ID loading units

For reusable internal carriers (for example racks or fixtures), a loading unit with fixed ID can be used. The ID stays permanently assigned, even when the carrier changes between empty and filled.

Key guardrails from the training content:

• The process is designed for internal reusable loading units, not standard customer shipment.
• The common pattern is a master loading unit used as a reusable collector.
• Empty fixed-ID carriers remain on the global loading-unit bin and do not yet carry item content.

Mandatory fields on the loading-unit item

Practical sequence

1. Create the loading-unit item and maintain mandatory fields.
2. Provide inventory for that loading-unit item on the global loading-unit bin.
3. Run report Create LE entries with fixed ID.
4. Maintain prefix, starting number, quantity, digit length, and location.
5. After execution, verify that all loading-unit entries were created and are empty on the global bin.

Click to enlarge

If fewer IDs are created than expected, check available inventory of the loading-unit item first. Missing stock is the most common reason.

History and traceability

History helps review movements, account-holder changes, and posted empty-return transactions retrospectively. Use this view especially when:

• stock differences with a partner need clarification
• returns or rebookings must be traced afterward
• an account-holder change must be explained or verified

History is therefore not only an archive, but an active control instrument.

The empty-return movement also contains an EDI Information FactBox. It is useful when the movement originated in an EDI-related context and you need to trace the link back to the message or grouped message.

Loading-unit account and movement reports

The loading-unit account is used for period-based reconciliation of movements and open balances. In addition, movement reports help evaluate specific periods, partners, or loading-unit types.

In code, the LE Account page works with clear filters. For reconciliation you can narrow down specifically by:

• Item No. filter
• Account Keeper Type filter
• Account Keeper filter
• Period Type such as day, week, month, quarter, or year
• From Date and To Date

The results are built in the related subpage for stock-count or reconciliation lines. This means the loading-unit account is not a static display, but a controllable analysis tool for periodic partner reconciliation.

These analyses are especially important for:

• monthly or periodic reconciliation with partners
• proving open empty-return balances
• checking unclear ownership or responsibility changes
• preparing settlements or credit processes

Practical control steps

Special cases

Account-holder changes

When responsibility for a loading unit changes, this change must be documented cleanly and later remain traceable in history. Unclear account-holder changes are one of the most common causes of reconciliation errors.

Delayed assignment after production

In certain scenarios, loading units are assigned to a process only afterward, for example after production. In these cases it is particularly important that the later assignment still reflects the actual ownership and movement flow correctly.

VDA 4927 communication

The legacy documentation refers to VDA-4927-related message types for exchanging loading-unit information. Which variants are actually used in production has to be decided in the project context. For daily operations, the most important point is therefore that internal movements remain functionally correct and reconcilable.

Typical failure patterns

Result

• You understand the difference between physical packaging logic and settlement-relevant loading-unit logic in Automotive.
• You can use account-holder maintenance, empty-return movement, and loading-unit account safely on the intended work pages.
• You have a reliable basis for later reconciliation with customers, vendors, or logistics partners.