Recently in Business Central has been introduced a new feature called Inventory Shipments. These a new type of document with which we can ship our items with a shipment document.
As we can see in the picture, we prepare a document with the Location Code in the header, and the items to be shipped in the lines, then we can press Post. On the lines it’s even possible to specify a Reason Code, but this information is not transferred to the Value Entry table, as we should expect.
The posing procedure generates a posted document that we can print and give to the shipping agent, and Item Ledger Entries having Negative Adjustment as Entry Type.
We can also make the opposite, that is the Inventory Receipt
whose posting procedure generates Item Ledger Entries having Positive Adjustment as Entry Type.
Now, in particular here in Italy, inventory adjustments, no matter if we do them with the standard function (Item Journal) or with this new feature, are always operations that should done in limited cases.
When we move items in our warehouse, we should always think about the ownership of the items: if this changes, we should treat the operation as a sale, while if the ownership does not change, we should manage this operation by using Transfer Orders, with which we can move our items from one location to another (a location can be also “virtual” as for example a customer).
The Service module
A different topic are all the situations in which the items moved in the warehouse are not ours, because these should not generate item ledger entries, simply because the item moved should not appear in our Item table. All these operations are typical in companies repairing items, but are covered by the Service module by using Service and Loaner Items, managed in Service contracts and orders, that create shipment documents without creating item entries.
Inventory adjustments should finally be limited in case of differences between the physical inventory and the virtual one, due to thefts, damaging etc, but not for letting out items without a specific reason. The physical inventory functionality is used when we have to make a recounting with adjustments, but this generates specific entries (Physical Ledger Entries) that are a trace of the operation.
The value issue
When we do adjustments we have another problem to consider: the quantity and consequently the inventory value is marked as invoiced in the entries.
Conclusions
For all these reasons, I don’t personally suggest a massive usage of this feature, but just in few specific cases, for which in any case I cannot see a gap in the system without this functionality.