Automate Serializing/Unserializing Products with Existing Inventory Movements
Answered
Our shipping and receiving department has been using Accounting Seed's Inventory Movement objects to record incoming and outgoing shipments, and we often run into issues where a Product that was set with Serialized = FALSE needs to be Serialized = TRUE. This requires me to delete all the pre-existing Inventory Movement records, which is especially difficult if there are Assets or shipped Sales Order movements, then restore the data from the Recycle Bin after I have changed the Serialized field.
I understand that this is because "serialized" movements are split up into qty 1 records with serial numbers, as opposed to "non-serialized" movements, which are bundled together on one record. Yet, I feel that the entire "delete, edit, and return" process could easily be an APEX-scripted operation achieved via a button on the Product detail page or something like that. It could include splitting up "non-serialized" movements into separate qty 1 "serialized" movements, and vice versa.
Are there any plans to implement a feature that automates the Serialize/Unserialize process without manual operations?
-
What is your use case where a formerly unserialized product becomes serialized? Is it just an error in the creation of new products?
I think as a systemic issue, the deleting and recreating of all past transactions is problematic if the transactions for a particular product goes back any distance of time into closed periods.
Have you considered just creating a new version of the (now serialized) product?
One client I work with uses the same product name, and then has a -A or -B in the product code to differentiate different versions of a product - like when there has been a change to the bill of materials, for instance.
-
Thank you for your input, Rebecca!
The use case is that our operations manager doesn't always know whether an item is serialized or not until it has been received. And even then, it might not be apparent that an item is serialized until we are scanning it when it is being packed for shipment. And being unable to scan an item properly holds up the shipment process and causes logistical issues.
The way I see it, the transactions themselves wouldn't be any different; they would just be separated or joined based on whether they are serialized or not, respectively. All other transactional data would remain the same.
I agree that making changes in Closed periods can be sketchy. But if the relevant periods were all Open, or could be reopened then closed just to handle this one operation that wouldn't result in a net difference in our ledger, I don't think it would be a long-term issue.
Creating an additional product could be an option, but then it would be separate from the previous product and the existing relationships wouldn't carry over, right? I think that would cause more of a headache in the long run.
-
Could the issue be solved - or at least mitigated - by training your purchaser (or Operations manager?) to ask whether a product is serialized before ordering it for the first time?
You could use the DLRS package (Declarative Lookup Rollup Summary) to put a field on the product that counts PO lines, and if that field = 0 and serialized = false, have some sort of workflow that notifies the owner of the PO that they need to make sure?
Please sign in to leave a comment.
Comments
4 comments