I have a strange situation and I don’t know how to handle it in Purchase.
I need to order Rebar from a vendor. When we need to order rebar, we calculate the required weight and order accordingly. But the problem is we can never receive exact order quantity. Rebars do not come in standard weights.
For ex. Lets say I need 1000 kg of 12mm diameter rebar. Each bundle of 12mm rebar is roughly 95 - 110 kg. Now, when I place a 1000 kg order, the vendor will send me 10 bundles which be roughly 1000 kg total but actually the sum of weights will be lets say 1010 kg.
It is no body’s fault. The rebar comes like that from the factory. I need to pay the vendor based on weight, not bundle. So, placing order by bundles is not an option. Also, each bundle will have a different weight.
Now, when I order 1000 kg 12mm rebar, I will enter the item as 12mm dia rebar, quantity will be 1000 kg and rate will be Rs. 100/kg. But when I receive, I will be receiving 1010kg or may be 998 kg. In ERPnext, when I enter 988 kg received and complete the transaction, pay the bill, the PO still says “To receive and bill”, becasue of course the transaction has not been complete yet for 998 kg receipt; and Material Request says “partially received”.
Over receipt seems to be solved by using “Over Delivery/Receipt Allowance (%)” and “Over Billing Allowance (%)” in item. I need ways to solve under delivery and payment.
Same issue here. As a workaround we go in Purchase Order, click button ‘Update Items’ and set the same qty we received. This will switch the status from ‘To receive and bill’ to ‘To bill’.
Any organization dealing with iron & steel has this problem. There are too many variabilities and it’s difficult to manage this. However, a robust way to manage this is the following:
The stock UOM of the item needs to be not Kg. It could be Sheets or Lengths or Running Meter. This ensures that you have control over the quantity you are ordering and the quantity that the supplier is sending you. Of course I hear that suppliers are totally tuned to loading your order in Kg and are not very supportive of counting quantities - that’s of course something that needs to be factored in
You don’t setup a standard conversion factor between the stock UOM and the Purchase UOM, so that you can add the conversion factor in the transaction
Now as you make transactions you add in the conversion factor to ensure that the Stock UOM is a whole number.
Why is this important at all?
Let’s say you have a +/- 2% variability in weight. Meaning a rebar that’s supposed to weigh 100Kg can weigh 98 - 102 Kg.
Let’s say you have to order 100 such rebars. Now it’s possible to conceive that if your supplier only goes by weight, he could, theoretically, send you 98 - 102 rebars. But you needed 100. Not 99. Or 101. Or 98. Or 102.
I know I’m complicating this, but I think organizations are better off ordering in the Primary UOM that’s suitable for the item and not in Kg. The PO can show both the quantity and weight range that’s acceptable.
This will ensure that weight variations in the shipment is because that’s intrinsic to the nature of item. And your supplier is not gaming the system by sending you more or less quantity (in Sheets, Lengths or Running Meters) than what you intend to receive from the supplier.
Ordering in meters could be a choice, but it is not aloof the problems I mentioned. Let me give you an example.
Lets say I am ordering a 12mm dia rebars - 1 bundle (approx 100 kg). In my place the standard length of each rebar is 12m. But it never is exact. There is variation in length too. So, in 1 bundle of the 12mm bars there are 10 pieces of bars totaling to approx. 120m but you can never be sure. There is variation in:
Weight of each bundle
Length of each bars in a bundle.
From what I understood by your suggestions, your suggestion would be appropriate when each rebar would be of exact same length. This way I could place rates in per m UOM and order in the same. But that’s not the case. Also, since length of each bar vary, weight of each bar vary.
The scenario you describe is true for metal, wood and a few other item categories. In fact one of the reason for the weight variability is because of size (length, width, thickness, etc.) variability. However, most organizations can work with (or rather factor in) those size variability.
You still could setup the Item saying Rebar 12 Meter Length with UOM as Nos (or Pieces, if you want to work with 0.5 of a Rebar) knowing fully well that the length could be from 11.9 Meter to 12.1. You do the PO with a conversion factor of 10 Kg per item. So, the PO will be for 10 Pieces (or lengths) Rebars 12+/-0.1 Meters Length with a Conversion Factor of 10 Kgs per Piece, so 100 Kg Unit rate of Rs. 50/Kg for a total PO Value of Rs. 5,000.00
Now let’s say the supplier sends you 10 Rebars but the weight is 101 Kg, you put in the appropriate conversion factor of 10.1 so that you end up with 10 Rebars. And you pay the Supplier 50 * 101 - 5,050.00
But now in your stock statement you know that you have 10 Rebar Pieces or Lengths rather than 101 Kg and as you issue out these 10, the stock gets down to 0 and you are all set.
If you ended up using Kg as the primary UOM, I can only guess that it’s messy to work with, once the item has been received from the supplier. And you need to keep dealing with leftover quantities.
I’ve also dealt with several types of metals with different shapes and different “standard UOMs”
Example:
Plates: usually sold by weight, consumed after nesting and cutting, remaining offcuts are often usable / have some value as scrap.
Bars: usually sold by weight. Consumed by length.
Pipes / Tubes: Sold by length but weight is not unheard of. Consumed by length.
Now you can have single material in 3 different forms. e.g. SS 304 (most widely used stainless steel)’
So what people will do is they’d create 3 different item codes for 3 “shapes” of metals they buy/sell.
An alternative is: for each shape and each configuration you need to create a separate item (or rather a. “variant”) So there will be item code for:
10mmx1250x6000 plate
10mmx1250x4000 plate
Notice that these two are almost identical except for length, sometimes width will be different too… how do you handle this if using UOM other than KG?
Also if you’re manufacturing then consumption will be even more complicated to set up if it’s not simple weight.
Weight vs length or area is quite debated in implementing metal UOMs in ERP. IDK if there is “one true answer” to this. It largely depends on the way you source/sell/consume in your organization.
I’ll give some more thought to this about the “best possible” implementation of metal sourcing and consumption.
Thank you so much for taking time into the discussion. I agree with your work around. But I find it more difficult to implement because I now will have to measure length of every rebar. It will get more cumbersome when I order 10 bundles of 12mm (10 pieces in each bundle), 5 bundles of 8mm (20 pieces in each bundle) and so on. Imagine how many pieces should be counted.
Any way, as @ ankush said, there might be no true answer.
I have tried to get very complicated with these and in most cases it gets way too complicated to manage on the shopfloor. Then I realize that whatever you might think about the shopfloor that you are working with for the ERP implementation (whether the shopfloor is your own, or a client’s), it (the shopfloor) is dealing with this complexity on a daily basis and doing a pretty darned good job of it.
So, in a lot of ways, without getting too analytical or prescriptive, it’s better to let the shopfloor deal with this complexity away from the ERP system.
It all boils down to what does the implementing organization want to do with it’s ERP system. A typical organization that deals with this would like to ensure that there is an end-bit warehouse and the production workers/planners should visit the end-bit warehouse and check what end-bits can be reused in the current project, so that the requirement of a new sheet being cut is delayed to the extent possible.
Recording all of the end bits on ERPNext is a very tedious process and it’s even more challenging for people to find the end-bits that ERPNext shows is available in the end-bit warehouse. Why? Because it’s lost with all the end-bits that the end-bit store is storing. Or somebody’s already taken that and perhaps missed making an entry.
My customers have found out for them it is optimal to record consumption in Pieces. Like if a particular fabrication requires 3/4 of a sheet, 10mm MS Plate, then the consumption is recorded at 0.75 Pieces of 10MSPL8x10. When you define it as Pcs, the item is defined by a dimension. Like the 10mm Thick Plate 10MSPL8x10 is 8’ in Width and 10’ in Length.
It’s possible that certain organizations have the sophistication to define each piece that’s the output of nesting and laser cutting, but anything that’s built, I suggest, be done with close collaboration with a user organization and the whole requirement is driven and funded by a user organization.
That will ensure that anything that’s built is used on the shopfloor by atleast one organization.
Unless I’m completely misunderstanding, this all seems way overcomplicated. If you ordered a 1000 kg, and then you received 950 kg, ERPNext is correctly saying that your requested quantity has not been delivered. If you judge 950 kg to be close enough, you can close the purchase order, just as @Manan_Shah said. This isn’t a workaround…it’s a literal representation of the actual business workflow, no?
A purchase invoice is automatically created from the order? Hmm…I’ve never encountered that before. Does the PI get created when the PO is submitted, or at some other time? Do you know if there’s a setting to trigger that behavior? I’m not able to recreate it on my system.
On a manual flow, you can always generate the invoice against the purchase receipt to have it generate values matching what was actually received. Or, you can generate it from the PO, and adjust the quantities in the invoice before submitting. I’d argue this is the right semantics. You ordered 1000 kg, and you got 900. I don’t like the idea of changing the documented order amount retroactively to accommodate what ultimately came.
Close the PO after you make the Purchase Invoice. Not before. Maybe a Custom Field with the status: To be Closed after Purchase Invoice will remind the user of it. Even better, maybe customisation will check as a Purchase Invoice is made, if the linked PO has the Status: To be Closed after Purchase Invoice .AND. will check if ALL Purchase Invoices have been made for the PO and will close the PO if these conditions are met.
