Error fixJD Edwards EnterpriseOneInventory Management / Item Balances

JD Edwards Inventory: On-Hand and Commitments Out of Sync

Error
JD Edwards on hand quantity wrong commitments out of sync

Also searched as

  • JDE item location F41021 does not match F4111
  • JD Edwards hard commit stuck
  • JDE inventory integrity report
  • JDE available quantity negative commitments

Short answer

When JD Edwards on-hand or committed quantities look wrong, compare the Item Location balance (F41021) with the sum of the Item Ledger (F4111) for on-hand, and with open sales and work order lines for commitments. Differences are normally fixed by running the inventory integrity reports in proof mode first, then final mode, never by editing balances with SQL.

Applies to: JD Edwards EnterpriseOne 9.x Inventory Management. Field names are standard; integrity report names and menu paths vary by release.

How to find and fix the mismatch

  1. 1Pick one item, branch and location and note what Inventory Availability or Item Availability (P41202) shows for on-hand, hard commit, soft commit and available.
  2. 2Sum the Item Ledger (F4111) for the same item, branch and location and compare to on-hand in the Item Location table (F41021).
  3. 3Compare hard and soft commitments to open sales order detail (F4211), work order parts (F3111) and transfer lines to see what should be committed.
  4. 4Check for stuck transactions: a sales order shipped but not sales updated, a work order issue partially posted, or a UBE that failed while updating F41021.
  5. 5On the Inventory Reports menu, find the integrity reports for item balances and commitments. Run them in proof (report-only) mode and review the proposed corrections.
  6. 6Take a backup or snapshot of F41021 and related tables in a test copy, rehearse the final-mode run there, and compare before and after.
  7. 7Run the integrity report in final mode in production during a quiet window, since users posting transactions during the run can cause new differences.
  8. 8Re-check the item on the availability screen and re-run the SQL comparison to confirm zero variance.

Where the numbers live

Quantity on hand by item, branch and location is held in the Item Location table (F41021) in the primary quantity field LIPQOH. The Item Ledger (F4111), often called the card file, records every inventory transaction with its quantity, so the sum of ledger quantities should equal on-hand. Commitments are separate fields in F41021: hard commitment (LIHCOM), soft commitment (LIPCOM), and quantity on work order (LIQOWO), among others.

Commitments should reconcile to open demand records. Sales order lines hold quantities and next status codes in F4211, and work order components live in F3111. A hard commit that does not tie to any open line is a ghost commitment, and it reduces available quantity until corrected.

-- read-only: on-hand vs card file for one item and branch
SELECT a.LIITM, a.LIMCU, a.LILOCN, a.LIPQOH,
       (SELECT SUM(b.ILTRQT) FROM F4111 b
         WHERE b.ILITM = a.LIITM AND b.ILMCU = a.LIMCU
           AND b.ILLOCN = a.LILOCN AND b.ILLOTN = a.LILOTN) AS LEDGER_QTY
FROM F41021 a
WHERE a.LIITM = 12345 AND a.LIMCU = '      M30';

Common causes of drift

Drift usually comes from interrupted processing: a sales update job that ended mid-run, a work order completion that failed after the ledger write but before the balance update, or an interface that loaded transactions with a custom program that skipped the standard business function. Direct SQL edits to F41021 or F4111 are another recurring cause, and they are hard to spot later because no audit trail records them.

Timing also matters. Soft commitments are created at order entry, hard commitments at pick release or ship confirmation depending on the configuration. A user comparing numbers across stages may see differences that are legitimate and not integrity errors. Confirm the commitment method and the order status before concluding anything is broken.

Safe correction practice

Always run integrity reports in proof mode first and review the output. In final mode they rewrite balances, and a mistake in scope, such as an unbounded data selection, can touch every item in a branch. Use data selection to limit to the affected items for the first run.

If balances are wrong because of a genuine count error rather than integrity drift, do not use integrity to fix it. Post an inventory adjustment or cycle count with the right reason code so the ledger and G/L both record the change.

Common pitfalls

  • !Editing LIPQOH or commitment fields directly with SQL, which breaks the link to the item ledger and the G/L.
  • !Running integrity reports in final mode with no data selection across the whole branch.
  • !Running the fix while the warehouse is processing shipments, creating fresh differences mid-run.
  • !Treating a legitimate soft commitment as an error without checking order status.
  • !Fixing a count error with integrity instead of an adjustment, leaving the G/L inventory account unchanged.

How an ERP-grounded AI assistant handles this

ERPray can run the comparison between item balances and the ledger as a read-only question, list the items where they disagree, and show the SQL used. It does not execute integrity reports or change balances. A planner or inventory control lead reviews the list and runs the supported JDE correction.

Frequently asked questions

Which table holds on-hand quantity?

F41021, the Item Location table, holds on-hand and commitment quantities by item, branch, location and lot. The Item Ledger F4111 holds the transaction history that should sum to the on-hand figure.

Why is available quantity negative?

Commitments plus other deductions exceed on-hand. Check whether the commitments are genuine against open orders or are stale, and check whether a receipt is awaiting posting.

Can I just update F41021 with SQL?

It is strongly discouraged. The change bypasses the ledger, G/L and audit trail, and the next integrity run or cycle count will expose the inconsistency. Use adjustments or integrity reports.

Should I run integrity reports regularly?

Some sites schedule proof-mode runs and review the exceptions. Frequent variances are a signal to find the underlying process failure, such as failing UBEs or custom interfaces.

Related

Error fix

JDE UBE failed (status E): how to read jde.log and jdedebug.log

A UBE (batch report/program) that ends with status E in Work With Submitted Jobs tells you almost nothing on its own. The real error is in jde.log on the enterprise server, in the job's own PDF/log subdirectory (jdedebug.log if you turned on debug), and in the work directory for that job number under PrintQueue or the OS temp path.

Error fix

JD Edwards: record is being used by another user (record reservation)

EnterpriseOne places a soft record reservation lock when a user opens a record for edit, tracked in the F00165 table, and releases it when the user saves, cancels, or the session ends cleanly. A stuck lock almost always means a session died abnormally (browser crash, network drop, kiosk timeout) without triggering the release, and it must be cleared by an admin, not by the original user retrying.

How-to

How to set data selection and processing options in JD Edwards

Data selection controls which rows a UBE's underlying business view reads (a filter, stored per version in F9210/F9211), while processing options control how the program behaves once it has that data (a settings template stored per version in F983051/F983052). They are configured from the same Version Detail screen but are separate, unrelated mechanisms that new users routinely confuse.

Error fix

JD Edwards business function (BSFN) errors: how to diagnose them

A BSFN error in EnterpriseOne means either the compiled function was not found for the current package build, or the function ran and threw an internal exception (often a null business view row, an unhandled C runtime error, or a failed table I/O). The fix path is different for each, so the first step is always determining which one you are facing from jde.log.

How-to

How to set up JD Edwards Orchestrator (step by step)

An EnterpriseOne orchestration chains one or more requests (form requests that drive an interactive application, or service requests that call a BSFN, business service, or SQL) plus optional rules and notifications, then exposes the whole thing as a callable REST endpoint via the AIS (Application Interface Services) server. The setup work happens in Orchestrator Studio, not the Fat Client.

Error fix

JDE package build failed: how to find the real cause

A package build (Full or Update) that ends in a failed or errored status on the deployment server does not explain itself in the Package Build Workbench screen. The real diagnostic detail is in the package's own log subdirectory on the deployment server, which holds a build log, a table conversion log, and per-object compile logs that pinpoint the actual failure.

AI for ERP

AI for JD Edwards EnterpriseOne Manufacturing, Without Leaving the F-Tables Exposed

Grounded AI over JD Edwards EnterpriseOne Manufacturing: work orders, routings, and Orchestrator data, answered on-prem without sending F-table data to a public model.

AI for ERP

AI for JD Edwards EnterpriseOne, Built on Orchestrator and AIS

Add AI to JD Edwards E1 9.2 using Orchestrator, AIS, and BSSV rather than screen-scraping. Ground a private LLM on F4211, F4111, and F0411 data.

Stuck on JD Edwards EnterpriseOne?

Talk to engineers who work inside JD Edwards EnterpriseOne every week, and who build private AI that answers these questions from your own ERP data.