Factory stock reconciliation

The factory warehouses run two systems that both claim to know what stock is in every bin: the warehouse system on the floor, and the ERP. This reconciliation checks that they agree, and when they don't, tells you which bin to go and look at.

It covers all three factory warehouses.

Start here: "Where the problem is"

This is the screen to open first. It answers one question — where is the problem, and whose is it — in a handful of rows, and every other screen in this article is a way of working one of those rows.

Each row is a lane: a distinct kind of problem with a distinct owner. Lanes are ordered by how directly you can act on them, not by size.

1. Failed to post. The warehouse system sent the movement and the ERP rejected it. Somebody must fix the rejection. Owner: IT / warehouse-system support.
2. In flight — abandoned in the queue. The movement was never sent and now never will be: it is older than the stock count that has already absorbed it. These appear on no failure screen anywhere, which is exactly why they went unnoticed. Every one needs a decision — drain the queue or cancel it. Owner: IT / warehouse-system support.
3. In flight — genuinely moving. Queued, young, and normal. Owner: nobody, until it passes seven days.
4. Impossible on either side. A bin holding negative stock. That cannot be true in either system, so it is a counting problem, not a difference between systems. Most of these report a perfectly clean tie, so no variance report will ever find them. Owner: warehouse — go and count the bin.
5. Absorbed by hand-posting. Somebody keyed the movement straight into the ERP and the warehouse system never saw it. Owner: finance.
6. True residual — unexplained. What is left once everything above is accounted for. It is deliberately the smallest lane and deliberately last. Owner: finance and the warehouse together.

Two things this screen will not do

It has no total, and it never will. The lanes are counted in different units — the first three count movements, the last three count bin rows — so they cannot be added. Worse, the last three overlap each other: a bin can hold negative stock, carry a hand-posting, and still leave something unexplained, and it is counted once in each lane it belongs to. Every row shows what it is counted in, so read down the column, not across to a total.

"Oldest (days)" can be a floor, not a fact. The activity history is kept for a fixed window. When a lane's oldest item lands exactly on the edge of that window, the true age is older than the number shown and unknown — the screen says so in plain words on the row.

Judge the size by the day, not by the total

Each warehouse rolls forward from its own stock count, taken on its own date, so they have had different amounts of time to drift apart and their raw totals are not comparable. Divide by the days since that warehouse's count before you compare them. This routinely reverses the ranking: the warehouse with the smaller total difference can be the one drifting fastest, and it is the one to look at first.

The other screens, and the order to use them

Summary is the health check. One row per warehouse: how many bin-and-stock-code combinations the two systems agree on, and how far apart they are in total. Start here.

By product range answers the next question: is this a mattress problem or a raw-material problem? One row per product range, ranked by the size of the disagreement. Use it to decide where to spend the morning before you open a list of individual lines.

Where the problem is is the working screen. Every bin, worst first, with a sentence explaining what that bin's difference means. This is the one to keep open.

Line detail is the drill-down: every individual stock code where the two systems disagree, showing exactly what each one holds. It lists only the lines that need explanation, so its row count is far smaller than the number of lines compared on the summary — that is the screen working, not data missing. Its difference total still matches the summary's exactly, because the lines that agree contribute nothing to it.

Did not post to SYSPRO lists warehouse activity the ERP rejected on its way in. This is the most common single cause of a difference, so check it before investigating a bin by hand.

Still waiting to post lists activity the ERP has neither accepted nor rejected. It is sitting in the queue. Nothing has gone wrong loudly enough to appear as a failure, which is exactly why these get missed — some have been waiting weeks.

These screens carry a totals row at the bottom. It totals the whole result, not the rows left after you filter the grid, so treat it as the total for the screen rather than for your current view. "Where the problem is" is the exception: it has no totals row, for the reason given above.

Working "By product range"

Rank by Size of difference, not by Lines to explain. They point at different things and the gap between them is the whole reason this screen exists: one range can carry the single largest disagreement off only thirty lines, while another spreads a smaller total across five times as many. Sorting by row count would put that range near the bottom of the screen.

Size of difference adds up how far apart the two systems are, ignoring direction. Net difference lets the overs and unders cancel. Read them together. A range whose size of difference is large but whose net is close to zero is not a clean range — it means errors in both directions are cancelling each other out, and that is usually two separate problems, not none.

Ranges are labelled in your own words rather than in the ERP's product codes. That mapping is yours to set: it is configuration, not something built into the report, so a range can be renamed or regrouped without a change to the software. Until you have confirmed a label, the row is marked Needs confirming — take it as a suggestion the system worked out from the product master, not as your own vocabulary.

Two rows deserve their own mention because they exist to stop things disappearing quietly: Unmapped — needs classification means a product class was created in the ERP that nobody has named yet, and No product master means a stock code was found in a bin with no product record behind it at all. Both still carry their difference into the totals.

Reading the difference

The headline number is simply what the ERP holds today minus what the warehouse system holds today. Nothing is estimated or rolled forward to produce it, which is why it is the number to trust and to act on.

• A positive difference — the ERP holds more. Something was posted directly in the ERP that the warehouse floor never saw. Look for manual postings against that bin.
• A negative difference — the warehouse holds more. Movement happened on the floor and never reached the ERP. Check Did not post to SYSPRO first.

A difference is never, on its own, evidence that stock has gone missing. It means the two records disagree. The stock itself is a separate question, and a physical count is the only thing that answers it.

The second column: when the ERP disagrees with itself

Each bin also carries a journal check. This is a different question from the one above, and it has a different owner.

The reconciliation compares the ERP's own movement history against the ERP's own bin balance. Those should tell the same story. When they don't, the message says so — and that is a problem inside the ERP, not a difference between the two systems. It goes to whoever administers the ERP, not to the warehouse.

The strongest version of this reads "Contradiction inside SYSPRO": the movement history records stock going into a bin while the balance for that bin sits below what the warehouse system holds. Those two things cannot both be right. Treat it as a question to raise, not a variance to write off, and don't adjust anything on the strength of it.

Working "Did not post to SYSPRO"

Most of what fails on this screen never cost you any stock, so read the Stock impact column before you read the row count.

A single warehouse event sends the ERP several separate messages — the stock receipt, the label print, the component issue, the variance — and any one of them can fail on its own. When the label print fails but the receipt posted, the ERP has the stock and the operator simply has no label. Those rows are marked Label only — stock posted and count zero towards the total.

The Stock affected column is the one that matters, and the totals row at the bottom adds it up for you. That figure is the number of messages where the movement happened in the warehouse and did not happen in the ERP. It is typically a small fraction of the rows on screen.

Three kinds of row count zero. Label only — stock posted is the case above. Not factory stock is a sales-order message — an invoice or a back order — that failed for its own reasons and has nothing to do with the factory bins this screen explains. The third is Marked failed, but SYSPRO accepted it: the message carries a failure label while the ERP records the posting as accepted. The two disagree, the ERP's own record is the one to believe, and the row is shown rather than hidden so nobody rediscovers it later as a fresh crisis. All three stay visible; none is added to the total.

Failures are grouped by fault, and the screen deliberately puts the ones somebody can act on at the top.

• Bin transfer rejected — same source and destination. The largest genuine fault. The ERP refused the transfer because it read the two bins as the same one. The stock moved on the floor and did not move in the ERP, so it drives a real difference.
• Bin not set up in SYSPRO / Stock code not stocked in this warehouse. Configuration. The movement is valid; the ERP has nowhere to put it.
• Label print share and SYSPRO connection. Infrastructure faults that IT owns. These are ranked last on purpose — they are the loudest by volume and they do not move stock.

Counts on this screen are messages, not movements. One movement can appear more than once — when the warehouse system retries a rejected message it sends a brand new one, and it does not carry a reference that ties the retry back to the original. So the count is an upper bound on the number of distinct problems, and the true number of movements to fix is somewhere at or below it. Use it to see which fault dominates and whether the backlog is growing, rather than as a to-do count.

Post count is the ERP's own attempt marker on a single message. It is almost always 0 or 1, so it does not tell you how many times a movement has been retried and should not be added up.

Days stuck is how long ago the message last failed. The totals row shows the worst one on the screen, which is the quickest way to see whether anything has been sitting unresolved for a long time.

Working "Still waiting to post"

This screen is kept separate from the failures on purpose. A rejected movement has an error message and usually an owner; a waiting one has neither. Mixing them into a single list buries the waiting ones, and they are the easier problem to miss.

Most rows here are stock that moved in the warehouse and has not moved in the ERP. There is no equivalent of the label-only case on this screen, but the Stock impact column still matters: a handful of the waiting messages are sales-order traffic rather than factory movements, and those cannot explain a factory bin difference. They read Not factory stock, stay on the screen so nothing disappears, and count zero in the total.

Sort by Days waiting: anything more than a day old has stopped being normal queue traffic and is stuck. Most of what collects here are the component-issue messages that accompany a production receipt.

There is a harder version of "stuck" on this screen, and it is the bulk of it. A movement older than the stock count it belongs to will never post — the count has already taken account of whatever it represented, so sending it now would double-count. Those rows read Stalled — older than the stock count, will never post, and on the lane screen they are pulled out as their own row with their own owner, because they need a decision rather than patience. Waiting will not clear them.

The same caution applies as on the failure screen: these are messages, not movements.

How current the numbers are

The feeds refresh every morning before the working day. Each screen shows the date the underlying movement data runs through, and the date of the stock count both systems are measured from, so you can always see how fresh the answer is. You can also re-run any screen on demand for the current position.

What this will not tell you

• It does not value the difference. Everything here is quantities. Costing is a separate question.
• It does not tell you where physical stock actually is. Only that two systems disagree.
• It does not cover the third factory warehouse while that is under test.