Putting this workflow into practice? Explore Distribution Operations System for implementation scope, controls, and next steps.
A stock spreadsheet can be useful input to a distribution system, provided everyone agrees what its quantities mean. Ten units may mean ten newly received units, a physical count of ten or ten units to remove. A column called quantity does not resolve that difference.
In a distribution application we built, operators have a CSV preview and commit workflow alongside stock entry and upload history. This article uses that anonymised build to explain the decisions behind the workflow. Example rows are illustrative, and the behaviour described is limited to the reviewed implementation rather than a claim that every import risk has been eliminated in production.
Define the quantity contract first
The reviewed operator upload prepares additive stock entries. A valid quantity represents units to add through that upload. A physical stock count has a different meaning and needs an authorised reconciliation process before changing a recorded balance.
Write that contract beside the template and preview. Specify the unit, warehouse, product identifier and source of the file. Keep the original supplier or operational reference where the business needs it to explain the receipt later.
The distinction also belongs in training. A user who downloads an additive template and pastes the current stock balance into it can create a plausible-looking error. A successful file parse cannot establish that the business meaning is correct.
Use a preview to expose the proposed change
The build checks the CSV structure, identifies products by SKU, validates quantities and checks applicable brand scope. It prepares preview rows that show the product, current recorded stock, quantity and proposed delta. Errors are available for review rather than disappearing into a generic upload-success message.
| Preview information | Question the operator should answer |
|---|---|
| SKU and product name | Is this the intended item? |
| Current stock | Is the starting position plausible? |
| Quantity and delta | Is this the intended additive movement? |
| Invalid rows | What needs correcting before processing? |
| Warehouse and allowed scope | Is this user authorised for the destination? |
| File identity and summary | Which source file is being reviewed? |
The reviewed workflow also has a row limit. For another business, choose limits and file-handling behaviour that suit the expected volume, processing time and operator review capacity. A large import needs an operating plan, not just a higher upload-size setting.
Worked example: repeated SKUs and an unknown item
Illustrative file: two rows contain the same product SKU, with quantities 4 and 6. Another row contains an unrecognised SKU. A fourth contains a quantity that fails the positive-whole-number rule.
The reviewed implementation groups recognised rows by SKU and aggregates the valid additive quantities. The two valid rows therefore propose an addition of ten units for that product. The unknown SKU and invalid quantity appear in the error information for review.
This is a deliberate rule to agree with the business. Repeated rows might represent separate cartons, but they might also be an accidental duplicate. If source references or row-level quantities must remain distinct, the importer needs a different record contract. Do not assume aggregation preserves evidence that was never retained in the first place.
Apply permissions when committing the work
The operator works within an assigned warehouse and applicable brand scope. The commit path needs those checks as well as the preview. A user should not be able to review an authorised file and then submit changed identifiers that fall outside their permitted work.
The distribution build includes the preview/commit service, upload records and movement entries. Project feature tests cover a valid operator upload and related stock effects. For a new deployment, demonstrate a disallowed brand, an incorrect warehouse and a record that changes between preview and confirmation.
The distribution software offer includes imports as part of the wider operating workflow. The relevant acceptance decision is what the user may commit and how its stock effect is reconciled.
Decide how errors and repeated files are handled
A preview can contain both valid rows and errors. Agree whether the operation accepts reviewed valid rows or requires the whole file to be corrected first. The response and upload history should make the selected policy clear so operators can identify what was processed.
Repeated submission is a separate acceptance case. Upload history helps investigation, but file history alone is not proof that a second submission cannot add stock again. If the business requires replay prevention, scope a durable source or action identity, the permitted retry behaviour and the handling of uncertain results. Demonstrate that rule in the target release.
The same care applies to corrected files. A revised source may be a replacement for an earlier upload or a new receipt. The operator and reviewer need to know which event is intended before the system calculates the next stock movement.
Reconcile the result to the source
After confirmation, compare the intended product deltas with the resulting ledger entries and upload record. Retain enough information to answer who processed the file, which warehouse was affected, which rows failed and what action resolved them.
If an upload was wrong, preserve its history and use the authorised correction process. Editing the original spreadsheet on someone's laptop does not correct an already-recorded stock movement. The warehouse management build roadmap explains how these controls fit into a broader operational pilot.
Include exported files in acceptance as well. OWASP's CSV injection guidance explains how untrusted spreadsheet cells can be interpreted as formulas. Check the application's export handling with deliberately awkward text before distributing files that operators will open in spreadsheet software.
Acceptance cases for an upload workflow
- A valid additive receipt with a known SKU and unit.
- Repeated SKU rows with the agreed aggregation policy.
- An unknown SKU, invalid quantity and disallowed brand.
- A mixed file demonstrating the agreed error-processing policy.
- A repeated file and a corrected file with explicit retry expectations.
- A post-commit reconciliation and an authorised correction.
Review your stock upload process
Bring a redacted CSV, its template and an example of a recent upload problem. Explain whether the quantities describe receipts, counts or another event. We can scope the preview, permission checks and reconciliation around that meaning. Review the Distribution Operations System, or send us your stock-upload workflow.
Frequently asked questions
Does the reviewed upload replace the warehouse stock balance?
It prepares additive entries. If a file contains physical count observations, define a separate reconciliation and approved adjustment process. Make the quantity meaning visible in the template and preview before operators use it.
Does a preview automatically prevent the same file from adding stock twice?
No. Preview, upload history and replay prevention serve different purposes. Agree how repeated and corrected files are identified, then test the required retry behaviour in the target implementation before relying on it.
Distribution Operations System
A configurable distribution software build for wholesalers, distributors and stockist networks. Bring buyer ordering, warehouse operations and owner visibility into a shared workflow, with the permissions and commercial rules your business needs.