How does one handle goods like vegetables stored in a warehouse, that lose weight due to water loss over time. Is there any default setting for this in the stock module?
Hi Hari,
No there is no default setting in the Stock Module.
So you are saying that the primary UOM is Kg (or equivalent) and 50Kg of the stuff you bought is only 47.3kg. So, what to do about the 2.7 Kg?
You could do a stock reconciliation and write off the 2.7 Kg and load up the valuation of the 2.7 Kg onto the 47.3 Kg that is left.
The other option is to treat the primary UOM as Nos (Say a Box) and the secondary UOM as Kg. You can make these items batched (you have to use a separate batch for every Box) or serialized and then maintain the weights of the batches or serial numbers in the Batch / Serial Number DocTypes.
Hope this helps.
Thanks
Jay
Thanks for the prompt reply JayRam.
The second idea sounds promising. Let me evaluate both ideas and get back to you.
The second idea needs a bit of scripting. Be prepared to get your hands dirty with scripts.
Thanks
Jay
^This.
Even large, commercial ERP systems usually don’t handle this. I encountered a similar problem a long time ago, working on Microsoft Dynamics. My client purchased, stocked, and re-sold different kinds of sand, gravel, and rocks. It was often delivered wet and heavy. In the hot climate, the water in the material would evaporate. The 2000 kilograms you purchased might be only 1800 kilograms later.
The weight variation was handled manually, with periodic stock adjustments, and writing off the “lost” quantity.
Handling automatically with algorithms and automatic updates was possible…but there would always be real-world fluctuation. Employees had to manually adjust, no matter what. So we agreed it was not worth the Code Development effort.
1 Like
Locally here all of the yards are now using the measure of a “bucket” to represent a standard front end loader bucket full of material. This way it didn’t matter if the material was crush and run, river stone or styrofoam peanuts! The UOM is always set by a standard bucket on a front end loader.
So even is a multi-axle dump truck dropped off a load of material with a delivery ticket in lbs or tons, the yard entered it into their system is buckets. When a customer come in, they use the same measure to load the customers truck. Life became simple for them at that point. 
BKM
That’s a really great idea.
Back in the day, this issue caused my client and I a tonne of headaches (pun intended).
- Yard would receive a Sales Order for 2,000 kg of material. For sake of example, assume Unit Cost is $1/kg, and Sales Price is $2/kg.
- Yard would post a Packing Slip (Delivery Note) for 2,000 kg. This created an inventory movement in the ERP. Reducing on-hand quantity at that location by 2,000 kg.
- Yard would load the material on a truck, and bring to the end customer’s site.
- Truck would unload material at customer’s site.
- Client would weigh the material. They might weigh 1900 kg, and only pay for that much.
What do you do? The ERP already reduced stock by 2000 kg. You can accept that quantity. But you’re only getting paid $3,800. First, the driver must note this change upon return (they did not have 4g tablets for updating the ERP remotely) Likewise, the Margin is now different than expected. Instead of a 50% margin, your margin is 47%. This would really stress the Sales and Pricing Team, who were extremely margin-focused and concerned.
Alternately, you could reverse the original Delivery Note, returning the original 2000 kg to inventory. You could then post a new, replacement Delivery Note for the actual amount recorded of 1900 kg. That made generating an invoice trivial, because the prices lined up. 1900 units at $2k each is $3,800, with total cost $1,900, and 50% margin. Perfect.
The challenge? People very often forgot to make the Delivery Note adjustments, after the fact. So information was recorded incorrectly. This eventually trickled down to Month End Questions. Questions which were inevitably sent to the ERP Consultant. “Why is our margin wrong, Brian?”
This wasn’t limited to just bulk material. Sometimes a Sales Order would call for 20 packages of gloves. The truck would arrive on-site, but customer only wanted 18 packages. Driver would say “ok”, and sell them 18. They almost-always wrote this down. But sometimes the ERP was not updated.
Most of this was a procedural, human problem. The CEO and CFO didn’t see it that way. They saw this as a technology and ERP problem.
After many years of battling this, I ended up writing a massive add-on module called “Load Tickets”. It replaced the standard Delivery Notes. Initial posting created zero inventory movement or cost changes. All documents were barcoded. If 50 pieces of paper were printed, 50 barcodes were tracked. When the driver returned with paper, it was scanned, indexed by barcode, matched against a Sales Order, and attached to the ERP. Based on hand-written notes, Sales Orders were updated.
A Warehouse Manager could also see that 50 Load Tickets had been issued that day, but only 48 scanned. Then lead a search for the 2 missing pieces of barcoded paper.
From a technical perspective, it was a marvel of engineering. The link between documents and ERP was amazing. When used correctly, it was awesome. I was (am) quite proud of of the design and code.
However, it was also a nightmare to maintain. A constant headache. Something I perceived as a huge waste of my client’s budget, and my own time. I really wish I’d never been asked to create it.
And just done something like @bkm’s “buckets”
1 Like
I guess such businesses would need to work on trust. Because you never know what’s caused the difference in weights - Evaporation, Dehydration, waste, spillage or pilferage.
BKM’s bucket approach would help only if the client is willing to pay by the bucket. And even if the client is willing to pay by the bucket, what happens to items that vary in volume? So, what was a bucket is now only 0.92 of a bucket.
Such businesses have to turn on Batch/Serial Number and the easiest way is to record the weight at different points. Like you got a truckload of ItemA that weighed 1842 Kg. So, the primary UOM of ItemA is Lot is batched/serialized (batched is better, but ERPNext has to be customized to ensure that Batches are unique for every new inbound transaction). Let’s say this is assigned a Batch BatchX1. Now let’s say, you have to ship 500Kg of ItemA BatchX1 of which you received 1842 Kg. You build a Batch Splitter functionality on ERPNext and BatchX1 is Split into BatchX11 and BatchX12. BatchX11 now has 1842-500=1342Kg while BatchX12 has 500Kg. BatchX12 is loaded onto a truck (Stock Transfer - Truck as a virtual warehouse on ERPNext). Truck reaches client site. Client weighs and finds out s/he’s received 472Kg. Delivery is made for 472Kg and the stock is revalued to 500/472 and 28Kg is written off at 0 value (as the 472 Kg is revalued to the same rate as 500KG).
I think it’s not very intense to customize this on ERPNext. Just need a client with a budget. 
Thanks
Jay
I was in a meat business. And yes we have to do regular stock reconciliation with weight loss. That would be the most common practice.
1 Like