Tracking Consignment Stock and Customer-Owned Inventory at Client Sites

Why does consignment stock at customer sites go wrong in a service business?

Because the stock sits in a place the business does not control, is consumed by people who are paid to fix things rather than count them, and is usually tracked as a single quantity in a spreadsheet that anyone can overwrite. The engineer takes three filters from the client's store room, fits two, leaves one on a shelf in the plant room and records nothing until the job sheet is typed up days later. The spreadsheet says eleven, the shelf says eight, and nobody can say which three movements are missing.

When the client runs its own audit and the numbers disagree, the conversation stops being about parts and becomes about trust. A client who cannot see what is held on its premises, what it has been charged for and what it still owes is a client who starts looking for another service provider.

The fix is not a better spreadsheet. It is a model in which the quantity on site is always the result of recorded events, so every number can be explained.

• One balance column that is edited directly, so a wrong number leaves no trace of how it became wrong.
• Parts consumed on site recorded after the visit, from memory, or not at all.
• Your consignment stock and the client's own spare parts mixed on the same shelf and the same sheet.
• Counts that overwrite the balance instead of producing a variance someone has to explain.
• No shared definition of what the client owes for, and when.

What is the boundary between the CRM and the ERP for consignment stock?

The CRM side answers where the stock is, who moved it, which job consumed it and whether the count agrees. The ERP answers what the stock is worth, who owns it on the balance sheet, what was purchased and what was invoiced. Keep that line sharp from the first workshop, because the competing advice on this subject usually comes from ERP vendors and assumes the whole problem is a warehouse module.

In practice the ERP stays the master of the item master, cost and valuation, purchasing and invoicing, and it receives consumption from Field Service as a posting when a work order closes. The pattern for that integration, with van stock as warehouses, one-way item master sync and idempotent consumption posting, is described on our Dynamics 365 Field Service implementation partner page, and the same approach applies to customer sites. Solzet does not implement Dynamics 365 Finance, Supply Chain Management, Business Central or any other ERP; we build the service-side visibility and integrate with the ERP you already run.

How should a stock location at a customer site be modelled in Dynamics 365?

As its own record, tied to the customer and the site, never as a text field on the account. Field Service already has warehouses, product inventory per warehouse and inventory journals, so the natural model is one warehouse per physical store: the client's store room at each site, and where it matters, each cabinet or cage within it. Add a lookup from the warehouse to the service account and, if you use them, to the functional location that represents the site, so work orders at that site can default to the right warehouse.

Keep your consignment stock and the client's own parts apart. Either use separate warehouses for each owner at the same site, or carry an ownership attribute on every movement, but decide once and never mix the two on one balance. Separate warehouses are simpler to report and harder to get wrong.

Products consumed from these warehouses must be set up as inventory products in Field Service so that used lines affect product inventory. Check current Microsoft documentation for the inventory behaviour in your Field Service version, because the inventory, purchase and return features have changed between releases.

• Warehouse: one per physical store at a site, with a lookup to the service account and functional location.
• Ownership: consignment stock and customer-owned stock in separate warehouses, or an explicit owner on every movement.
• Product: the same product records the ERP synchronises, flagged as inventory products, with serial numbers where the parts are serialised.
• Agreed levels: a minimum and target quantity per product per site warehouse, so replenishment is a view rather than a phone call.
• Customer asset: where a consumed part becomes installed equipment, the used line creates or updates the customer asset, which is covered on our asset history portal guide.

Why should stock movements be immutable events rather than an editable balance?

Because an editable balance can only tell you what someone last typed, and an event log can tell you how every unit got there. When the quantity on site is the sum of receipts, transfers in and out, consumptions and count adjustments, any disagreement can be traced to a specific movement, a date and a person.

In Field Service, inventory journals record changes to product inventory created by transfers, adjustments and used work order products, and product inventory holds the resulting quantities. Treat those quantities as derived. Nobody should update product inventory directly, and security roles should remove the privilege to do so from everyone except the integration.

Where the client needs more than the standard journals record, such as the delivery note reference, the owner, or the count that triggered an adjustment, add a custom stock movement table that is append-only: users can create rows but not update or delete them, and a mistake is corrected by a reversing movement with a reason. Enable auditing on the tables involved so changes to reference data are visible too, as described in our audit trail and compliance guide.

How do you capture consumption on the work order at the moment of use?

On the engineer's device, during the visit, as part of closing the job rather than as a separate stock form. The engineer adds or confirms the work order product, sets its warehouse to the site store it was taken from, scans the part or serial where the parts are labelled, and marks the line Used. Estimated lines from the incident type show what the job was expected to need, so the engineer usually confirms rather than types.

Make the warehouse default from the site on the work order, so the engineer does not choose between similar names. Require a warehouse and a serial number on used lines for serialised inventory products, and block completing the work order while inventory lines are still Estimated or missing a warehouse. Why Estimated versus Used is also the audit evidence for what was fitted is covered in our Field Service proof of work guide, and the cost and price side of the same lines is in Field Service job costing.

Site store rooms are often basements and plant rooms without signal, so the offline profile must include the site warehouses and their products for the engineer's upcoming bookings. Designing that without losing data is covered in Power Apps offline field data loss.

How should periodic stock counts be reconciled against the event log?

A count is evidence, not an instruction to overwrite the balance. Record what was counted, compare it with what the event log says should be there, and only then create an adjustment that carries the variance and the explanation. The count record stays, so next quarter's count can show whether the same products keep drifting.

• Schedule counts per site warehouse, for example as a recurring work order with a count task, so counting is booked work rather than a favour.
• Freeze the expected quantity at the moment the count starts and record movements made during the count separately.
• Capture counted quantities and serials on the device, product by product, against a count record for that warehouse.
• Calculate the variance per product and require an explanation above an agreed tolerance: an unrecorded consumption found on a work order, a transfer booked to the wrong site, damage, or unexplained.
• Fix explained variances at the source, such as marking the missed work order product Used, rather than with a blind adjustment.
• Post the remaining variance as an inventory adjustment with a reason and approver, and send it to the ERP as the ERP expects.
• Share the count result with the client, including unexplained variances, before they find them in their own audit.

What stock report does the client actually want to see?

Three answers per site, on one page, with the ability to drill into the movements behind each number. Clients rarely want your data model; they want to know whether what they are paying for matches what is on their shelf.

Should the client see stock through Power Pages or Power BI?

Use Power BI when the client wants a periodic view and trend analysis for a few named people, and Power Pages when the client wants to look up current stock, see the movements behind it or confirm a delivery themselves. Many service businesses use both: a Power Pages portal where the client's site contacts see their own stores, and a Power BI report embedded in it or shared for management.

Either way, the client must only ever see its own sites. In Power Pages that means table permissions scoped to the contact's parent account, reaching warehouses and movements through that account, which is explained in our asset history customer portal guide and tested as described in Power Pages table permissions. In Power BI it means row-level security on the account. Power Pages is licensed by authenticated user capacity and Power BI by its own licensing, so check current Microsoft licensing before deciding which the client's users need.

Should consignment stock tracking run on Dynamics 365 or a custom-built system?

If you already run Dynamics 365 Field Service, the warehouses, product inventory, work order products and mobile app are there, and consignment tracking is configuration, a small append-only extension and a report. If you do not, buying Field Service only to track stock at client sites is rarely the right reason.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. For a service business that needs site stores, immutable movements, consumption against jobs and a client portal without per-user Microsoft licensing, the same model runs well as a custom-built CRM on React, Node.js, PostgreSQL or .NET, integrated with the same ERP. The model on this page is the part that matters; the platform is a licensing and ownership choice.

How does Solzet help a service business track consignment stock at customer sites?

We start with the account at risk: one client, its sites, its current spreadsheet and the last disagreement about numbers. From that we agree what the client needs to see, model the site warehouses and ownership, reconcile an opening position with a first count, and put consumption on the work order product for the engineers who visit those sites. The client report follows once the event log has a few weeks of trustworthy data, and the model then extends to other clients.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. We stay on the Customer Engagement side and integrate with your ERP rather than implementing it. The wider Field Service build is on our Field Service implementation partner page.