JD Edwards developer on retainer: custom UBE R5542001 writes F4111 inventory adjustments but does not detect F0911Z1 interoperability posting errors — 193 G/L entries stuck in error status, $128,000 month-end discrepancy — JD Edwards EnterpriseOne developer on monthly retainer

JD Edwards EnterpriseOne 9.2 • Oracle 19c • UBE R5542001 • F4111 • F0911Z1 • EDSP=E • R0911P • business unit not in account master • retainer billing

At Pacific Northwest Distribution, the March month-end close revealed a $128,000 discrepancy in the inventory general ledger account 1410-001-00. The cost accountant had balanced the trial balance for every other account before finding the gap: inventory ledger entries in F4111 for a set of warehouse adjustments had no matching entries in F0911 (the Account Ledger). The JD Edwards EnterpriseOne developer retainer was engaged to trace why the G/L side of those transactions had not posted.

The distribution center ran JD Edwards EnterpriseOne 9.2 on Oracle 19c. Warehouse inventory adjustments were processed nightly by a custom UBE, R5542001_InventoryAdjust, written 18 months earlier when the company moved a satellite warehouse to a new facility. The UBE read a daily CSV file of manual inventory corrections — shrinkage, damage writeoffs, quantity reclassifications — and wrote each adjustment as an F4111 record and a corresponding F0911Z1 row for G/L posting.

JDE G/L interoperability: F0911Z1 and the EDSP field

JD Edwards EnterpriseOne’s G/L interoperability mechanism is a two-stage pattern for third-party or custom processes that need to write journal entries to the general ledger. The stages are:

1. Write to F0911Z1. The custom program inserts rows into F0911Z1 (General Ledger Interoperability — Unedited Transactions). Each row contains the account number, business unit, cost center, ledger type, amount, fiscal date, and an identifying batch number from the originating UBE. The EDSP (Edit Status) field is left blank, indicating the row has not yet been processed.
2. R0911P processes F0911Z1. The standard JDE batch job R0911P (Post G/L Interoperability Transactions) runs on a schedule (typically nightly after the custom UBE). R0911P reads F0911Z1 rows with EDSP = blank, validates each entry against the chart of accounts (F0901), the fiscal date calendar, and the business unit table, then either posts the row to F0911 (setting EDSP = ‘P’ for posted) or rejects it with an error (setting EDSP = ‘E’ and writing an error description to the row’s remark field).

The critical design requirement for any custom UBE that uses this pattern: after R0911P runs, the custom UBE (or a companion monitoring process) must check for F0911Z1 rows with EDSP = ‘E’ that originated from its batch numbers. An EDSP = ‘E’ row means the G/L entry was not posted. The F4111 inventory ledger record exists (the warehouse adjustment was logged), but there is no matching F0911 entry (the G/L account was not debited or credited). Without this monitoring, G/L rejections are invisible until month-end reconciliation.

How R5542001 missed the posting failures

The custom UBE R5542001_InventoryAdjust had three phases:

1. Read each row from the daily CSV adjustment file.
2. Write an F4111 record for the inventory movement (item, branch plant, quantity, unit cost, document number, batch number).
3. Write an F0911Z1 row for the corresponding G/L entry (account 1410-001-00, business unit, amount, fiscal date, the same batch number as F4111).

After the F0911Z1 write, the UBE moved immediately to the next CSV row. There was no step 4 — no check of EDSP after R0911P ran, no query of F0911Z1 for error rows, no alert or exception report. R5542001_InventoryAdjust completed with return code 0 after successfully writing F4111 and F0911Z1 rows. R0911P ran overnight, accepted most of those rows, and rejected the rest. The custom UBE was never told about the rejections.

The January 8th configuration gap

The 193 rejected F0911Z1 rows shared a common rejection reason: Business Unit 003 Not in Account Master. On January 8th, the distribution center had activated a new cost center — Business Unit 003 — to track the inventory movements of a newly reclassified product category. The operations team configured the business unit in the JDE organization structure and updated the CSV export from the warehouse management system to include Business Unit 003 in the adjustment records. However, they did not set up the corresponding account master record in F0901 (Account Master) for the combination of account 1410-001-00 + Business Unit 003. Without an F0901 record for that account/business unit combination, R0911P cannot validate the G/L entry and rejects it.

Each day from January 8th through March 12th (the last business day before March month-end close), R5542001_InventoryAdjust wrote 3–7 F0911Z1 rows with Business Unit 003. R0911P rejected them all. EDSP was set to ‘E’ on all 193 rows. The remark field on each row contained: Business Unit 003 Not in Account Master for Account 1410-001-00. This information was present in F0911Z1 for 64 business days before the month-end close. No one saw it because no one was looking at F0911Z1 EDSP=E rows for the R5542001 batch numbers.

Diagnosis: querying F0911Z1 for EDSP=E rows

The JDE EnterpriseOne developer retainer began with a targeted SQL query against F0911Z1, filtering on the batch number prefix assigned to R5542001 runs and EDSP = ‘E’:

SELECT COUNT(*), SUM(GLAG),
       MIN(GLDGJ) AS earliest_date,
       MAX(GLDGJ) AS latest_date,
       GLICU      AS batch_number,
       GLRM       AS rejection_reason
FROM   PRODDTA.F0911Z1
WHERE  GLEDSP = 'E'
  AND  GLICU  LIKE 'R554%'
GROUP BY GLICU, GLRM
ORDER BY MIN(GLDGJ);

The query returned 193 rows across 17 distinct batch numbers (one per day from January 8th to March 12th), all with the same rejection reason: “Business Unit 003 Not in Account Master for Account 1410-001-00.” The sum of GLAG (ledger amount) across all 193 rows was exactly $128,000 — matching the month-end discrepancy to the dollar.

The two-part fix: configuration correction and UBE monitoring

Part 1 — Configuration correction: The JDE system administrator set up the missing F0901 account master record: account 1410-001-00, Business Unit 003. Once the account master was in place, R0911P could post the rejected rows. The EDSP field was reset from ‘E’ to blank on all 193 F0911Z1 rows (using a JDE data selection on R0911P or a direct SQL update, depending on the installation’s change control procedures). R0911P was run immediately. All 193 rows were accepted and posted to F0911. The $128,000 appeared in account 1410-001-00. The trial balance reconciled.

Part 2 — UBE monitoring enhancement: R5542001_InventoryAdjust was enhanced with a post-run monitoring section that queries F0911Z1 for EDSP=E rows matching the current run’s batch number:

/* After all F0911Z1 rows have been written and R0911P has run: */

/* Query F0911Z1 for EDSP=E rows from this UBE run */
SELECT GLICU, GLDGJ, GLLT, GLAG, GLMCU, GLOBJ, GLRM
FROM   PRODDTA.F0911Z1
WHERE  GLEDSP = 'E'
  AND  GLICU  = :current_batch_number;

/* If any rows found:
   - Write each rejected row to custom error table F5542001E
     (batch number, date, account, business unit, amount, reason)
   - Set UBE completion status to Warning (amber)
   - Write error count to UBE print output
   - Generate JDE media object alert for GL Controller distribution list */

The enhancement added approximately 0.3 seconds to the UBE run time (the query returns quickly; the monitoring overhead is negligible). After deployment, the first test run with a simulated Business Unit 003 configuration gap produced an immediate warning in the UBE output and a row in F5542001E. The GL Controller receives an alert email within minutes of any F0911Z1 rejection — on the night it occurs, not at month-end close.

Why F0911Z1 errors go undetected so often

The F0911Z1 interoperability pattern is the correct design for custom G/L posting in JDE EnterpriseOne. It separates the inventory system’s responsibility (create the F4111 record, write the F0911Z1 staging row) from the G/L system’s responsibility (validate and post via R0911P). This separation is intentional and well-documented. The gap in practice is that the design documentation specifies the write path but not the monitoring obligation. Most custom UBEs that use F0911Z1 implement the write correctly and skip the monitoring entirely.

The EDSP = ‘E’ rows accumulate silently because: R0911P does not send an alert by default (it logs errors to a report, but only if someone runs and reviews that report); the custom UBE never queries F0911Z1 after the run; and the subledger-to-GL reconciliation that would catch the gap is typically done only at month-end. A 64-day gap (January 8th through March 12th) is typical — it represents the full first full quarter where the configuration error was active before a close-cycle check caught it.

How HourTab helps JD Edwards EnterpriseOne developer retainers

The Pacific Northwest Distribution engagement totaled 6.0 hours: GL account analysis (1.0h, reviewing the trial balance discrepancy, tracing F4111 records to their source UBE batch numbers), F0911Z1 diagnosis (0.5h, running the EDSP=E query, confirming 193 rows, reading rejection reasons, summing to $128,000), root cause investigation (1.0h, confirming the January 8th Business Unit 003 activation date against the F0901 account master gap), configuration fix (0.5h, setting up the F0901 account master record for account 1410-001-00 + Business Unit 003), repost verification (1.0h, resetting EDSP on 193 rows, running R0911P, verifying F0911 post and trial balance reconciliation), and UBE monitoring enhancement (1.5h, adding the post-run F0911Z1 EDSP=E query, writing to F5542001E, wiring the alert, testing with a simulated rejection). Ongoing retainer monitoring: 0.2h per month to review F5542001E for any new error rows and confirm the prior month’s GL posting was clean.

In a HourTab retainer log, the investigation session reads: “R5542001 F0911Z1 EDSP=E: $128,000 discrepancy in account 1410-001-00 at March close; F0911Z1 query (EDSP=E, batch prefix R554%): 193 rows, all with rejection reason ‘Business Unit 003 Not in Account Master for Account 1410-001-00’; dates January 8 through March 12; root cause: Business Unit 003 activated January 8 in organization structure but not set up in F0901 account master; F0901 record added for account 1410-001-00 + BU 003; EDSP reset to blank on 193 rows; R0911P rerun: 193 rows posted to F0911; trial balance reconciled: account 1410-001-00 correct; UBE enhanced with post-run EDSP=E check: F5542001E error table + GL Controller alert on same night as any rejection; tested with simulated BU gap: alert generated correctly; 6.0h.” Pacific Northwest Distribution’s GL Controller can see the 64-day gap, the root cause, and the same-night detection that now prevents a recurrence.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark — no login, no portal, no “how many hours do I have left?” emails. Free for one retainer. $9/mo for up to ten.

FAQ: JD Edwards EnterpriseOne developer retainers

See also: Baan developer retainer · SAP ABAP developer retainer · Oracle Forms developer retainer