The shelf is always right. The stock figure is not.
"The stock figure is never right anyway." I have heard that sentence in so many warehouses that it started to feel like a law of nature.
It is never meant as a complaint. It is a work instruction: people in the warehouse do not look at the system, they look at the shelf. People in purchasing look at the system — and order against numbers nobody in the warehouse trusts.
Both are right. And the gap between them is not a data problem. It is the sum of every movement that happened without becoming a posting.
The note on the forklift
Relocations are the classic case. Goods are put in a different place because the day demands it. In the system they still sit where they sat the day before yesterday. At some point somebody cannot find them, searches for twenty minutes, and then creates an adjustment — or does not.
The adjustments that do get created are the second half of the problem: they arrive bundled, often days later, and they carry no reason. An inventory adjustment without a cause is, in accounting terms, a change in value nobody can explain. At year end it becomes a discussion.
The warehouse system knows all of it. It has the scan, the location, the timestamp. What is missing is the path into Dynamics 365 — and the rule for what may happen there.
Five journals, not one interface
The warehouse module of FlexxLink accepts exactly the journals a warehouse actually produces, rather than a universal interface for "inventory data":
All of these arrive in one workspace — interface type "Inventory journal". That is more than tidiness: validation rules can differ per journal type, and a count may be treated more strictly than a relocation.
Creating is not posting
The most important switch in this module is the least conspicuous one. An inbound message is validated, approved — and then created as a journal in Dynamics 365. It is only posted if that is explicitly configured.
That gives you both options, per journal type: relocations run straight through because they do not change value; adjustments and counts stay as a journal until somebody looks at them. Configure it the other way round and two weeks later you have an inventory difference nobody can attribute.
A warehouse movement is not a status message. It is a posting — and for adjustments the same rule applies as anywhere else: validate, approve, then post.
License plates and batches — the part that stalls projects
Storage dimensions are where integrations fail. A warehouse system reports a license plate that does not exist in D365 yet; a batch arrives that was never created there. Classically that means: message fails, somebody creates master data, message is sent again.
So the module validates required license plate values on import and can create missing ones when the setup allows it — the same for batch numbers. The search runs inside the site and warehouse that were passed in.
Two limits belong to that, and I would rather name them up front: parent license plates are not created automatically, and if the same plate number exists anywhere else in the tenant, creation runs into an error. That is not a shortcoming — it is the point at which a project has to agree on a numbering scheme.
Counting as a loop
A stock count is the case that shows whether a connection thinks in both directions. A counting journal is exported from D365 to the warehouse system — triggered by hand from the journal, with all lines, storage dimensions, line numbers and item details.
The counting happens where the shelves are. The results come back through the inbound counting interface and write into the existing journal rather than creating a new one. What you end up with is a count that D365 started and D365 closed — and in between the warehouse worked, not the finance department.
How to tell the movements are missing
You do not need to look at the technology for this. Four questions are enough:
The second question is the uncomfortable one. Adjustments without a reason are the price of every movement that was never posted — and they surface at the close, not in the warehouse.
What a connection does not solve
It does not fix a location structure that looks different on the shelf than in the system. It does not replace a decision about who may count and who may adjust. And it does not replace a numbering scheme for license plates — that has to be agreed once, or it catches up with you at the first duplicate.
What it does is narrower and more important: every movement the warehouse system knows about becomes a journal in D365, with an origin, a validation and a timestamp. The rest is organisation.
A stock figure nobody trusts costs more than one that is wrong. With a wrong figure you correct a number. With a distrusted one, somebody walks over and looks. Every day.
This is the overview. The individual pieces — validation rules per journal type, plate logic, batches, counting in detail — follow as their own posts. If the sentence "the stock figure is never right anyway" gets said in your company, tell me about your warehouse. The module itself, with trial access, is at soluvine.com — built by the development team I have worked with since the Damgaard days.
This post is also available in German. Auf Deutsch lesen
All posts