Hello Everyone! I am new to ERPNext and the experience has been really great. I am currently learning its different functions and features so bear with me if my question has been already raised before. I have search through the forum but my keywords might not be correct. Anyway, I wanted to ask help on how to treat the following scenario in ERPNext.
This company sells meat carcass. From the whole meat (pig, beef, chicken), they have to cut parts and sell them with different prices. Is there a way in ERPNext to record the “cutting” part with correct recording of inventory from Whole meat to cuts by default? I am running in V8.
Hello @Pawan! Thanks for your response, really appreciate it! I look through this but has one issue. The company receive the meat in whole and do the cutting themselves. Does that mean I need to out the Whole Meat for a dummy warehouse for cutting and record Materials Receipts for the parts?
Hello @jof2jc! Thank you for your response, really appreciate it. I have also look into this feature. The problem is one whole meat has lots of parts and repack can only do 1:1 for specific item (though qty can be changed). Anyway, I’ll keep looking for other workarounds. Thanks alot!
I think in Repack you can specify 1 source material (eg 1 whole port carcass) and then specify multiple items (for the parts) repacked from that carcass. This is based on v7. Not so sure on v8.
The hard way would be creating a custom doctype that’s similar to repack. But that would take some time and lots of scripting.
Hello @Fred1! Thanks for your response, really appreciate it. This is correct but parts are sold in different prices. Also, the company wants to measure sales per parts (which are individual item). One workaround that I can think of is left out the receiving and cutting of the Whole Meat in ERPNext and receive it by parts instead. But if anyone out there have other ideas as well, it would be greatly appreciated. Thanks alot!
Hi @funtasho,
I’m working on the same thing with some help from @revant_one and the MN Technique team. My design (intention) is closest to what @littlehera described, but using the BOM as a template. This is a component in the chain of the whole farm-to-retail process I’m hoping to build, in this context, a Livestock app.
The challenge is reducing the amount of manual input, which is why (I think) I’d like to end up with a wizard format:
An animal is harvested/processed, with live weight captured.
{Very few companies I know process their own, this is almost always subcontracted to licensed facility in the US}
The cuts are returned from the sub, either as halves, quarters, “boxed” or “retail ready”. That’s four different BOMs to select from, each item of which needs a manual input of the weight into the wizard. The larger cuts can be repacked into retail cuts, as you suggest, so the wizard needs to accommodate multiple input formats.
I think integrating barcode/RFID variables throughout will allow this to scale a little more easily, but that’s not something I’ve put a ton of thought into.
-Tyler
Hey @littlehera and @funtasho - After digging in some more I think this should be a new workflow in the Stock Module, something like “BOM-Wise Stock Receipt” and approach it as a more generic process.
@adam26d Not in a concrete way, but I think there are some things that might make sense for the workflow. I haven’t totally organized my thoughts but would like to talk through it with you and then summarize our thoughts in this thread. Are you interested in a chat?
I’m very interested in this, I just have my hands full fit the another 14hrs or so, so I went be fully responsive. You may go ahead and start the thread and I’ll come in as much as I can until I’m fully available.
Disclaimers: For those that in some way ideologically or religiously opposed to eating animals, this post describes business challenges that highlight the difficulties of this industry; personally I believe that the humane treatment of these animals is a moral obligation; the content of this post is about post-mortem processes. For those that are squeamish, this post contains general descriptions of the insides of animals.
The abattoirs I work with typically take an order from the farmer delivering the animal(s) about any special cuts, with the balance going to ground (mutton, lamb, etc). This can probably be best understood as a percentage of the animals’ live weight. Percentage of “Percent of live animal” can be a valid UOM conversion in ERPNext. Using a quotation to populate a Sales Order with these percentages seems like a good starting place; maybe using a product bundle as a way to template these things. For example, a customer could specify that they want half of the ground meat turned into sausage, for which there’s an extra charge. Moving a sales order to a collection of work orders is a surmountable technical/ mapping problem but there are some industry-specific areas of concern.
Accounting in this industry is poorly defined for several reasons:
One does not typically manufacture many items from a single input item, so there aren’t other industries from which to draw convention
A decision needs to be made if the inventory remains owned by the customer
The abattoir’s service charge is typically priced based on the deliverable amounts yielded, which are returned to the customer, on a per-weight basis
Some percentage (35-45% in the US depending on the species) is considered waste and typically not returned to the customer. This includes things like bones, hooves and skin/hide; this is usually called ‘offal’ (though sometimes this is specific to the major organs), ‘byproduct’ or ‘coproduct’ (when there is meaningful value for some portion of these items, like for sale as pet food in the case of poultry or as liquid fertilizer in the case of pelagic fish)
This model of manufacturing is very clearly in the “process manufacturing” camp and isn’t a great fit for ERPNext’s ‘discrete’ manufacturing model/ perpetual inventory system. Though outbound items are weighed; often a regulatory requirement and the abattoir will often price their services based on these weights. The problem is that the intermediate states of inventory are not typically weighed.
For example:
In the case of most ungulates, there is a two week or more time that the carcass is hanging in refrigerated and sometimes humidity controlled space, which increases the quality of the meat due to dehydration (less water, more flavor). Because of the dehydration, the weight at the time of hanging and the weight at the time processing the carcass begins are quite different (6-15% loss).
In the case of processing fish, they are typically immediately placed on ice after they are killed and weighed. Because ice melts there is no way to calculate a tare on the batch, which are never weighed again until individual cuts are packaged. In poultry and fish processing much better automated control hardware exists that can weigh or size cuts is available, often with a tradeoff for traceability at the individual animal level. This hardware is not open source and there is no common interface or an exposed interface or sometimes any digital controls at all and is both adjacent and out of scope of this discussion.
In many processing paths there will be intermediate states that are stored, especially with larger animals. For example, all sausage making could take place on a certain day of the week. Or “we break down the heads on Thursdays”. In ERPNext’s typical workflow these need to be specific, inventory-able items, especially since there will be a case where the customer retains ownership of the item.
So, back to ERPNext. I don’t see a way where it makes sense to develop a generic tool for this industry: there are relatively few of these businesses worldwide (I would guess fewer than 100,000; there are fewer than 500 in the US that are USDA inspected) and each one likely has unique regulatory requirements, which in any food industry is non-negotiable. Back to what I said three years ago making a BOM that “unpacks”, I think the most reasonable approach for process manufacturing generally is to make stock entries directly. The process manufacturing app takes this approach, as well as other bespoke projects I am aware of.
For non-animal uses cases, I think making a “Repack” stock entry after receiving items makes the most sense but a “Manufacture” stock entry might also be appropriate. For things that are very firmly in the process manufacturing realm its likely a custom workflow is going to be required anyway.
@adam26d Let me know how I can help, I am happy to do so. @Tropicalrambler likely also has some input about this.
Quick reply before going to bed: I am using “repack” with a customer with fish livestock, it provides sufficiency. Will read post at length with more rest.
