I am pretty sure that the issue I’m about to discuss here, has already been discussed somewhere. I’m just unable to find it.
Now that I have somewhat mastered the installation of ERPNext, it’s time to move forward.
I have created a test company and populated information as required. I also can create items and the process is straightforward.
However, I am in need of creating an item with different packaging. There will be a base unit of measurement and base price per unit. All next packages will set their price based on the base price. I believe that I need to use “Item Variants” and “Pricing Rules”. But unfortunately, I can’t seem to find a starting point. Please check the image for an example of what I intend to achieve.
Any help will be greatly appreciated.
Thanks and regards,
Are you planning to have different selling prices for this parent item?
Thanks for your reply.
No. The Parent item will have a base unit and a base price. Please follow the below mentioned example.
Say, we have Tea. Now this tea can be from Darjeeling, Assam, Shimla etc.
Now the base unit of tea is kg and base price is 100.00 rupees per kg. Let’s assume the base product is called T-Base. What I want to achieve is create conditions based on which other prices will be determined automatically.
Assam Tea == (T-Base+20% of T-Base) => 120% of T-Base => Rs. 120.00 per kg
Darjeeling Tea == (T-Base+40% of T-Base) => 140% of T-Base => Rs. 140.00 per kg
Shimla Tea == (T-Base+15% of T-Base) => 115% of T-Base => Rs. 115.00 per kg
Above mentioned structure depicts the creation of per kg price of Tea based on their origin. Now comes the packaging.
250g pack of Assam Tea will be priced at (120/1000)250 => (122.5) == Rs. 30.00
300g pack of Assam Tea will be priced at (123) == Rs. 36.00
500g pack of Assam Tea will be priced at (125) == Rs. 60.00
In the same way,
500g pack of Darjeeling Tea will be priced at (145) == Rs. 70.00
125g pack of Shimla Tea will be priced at (15.51.25) == Rs. 19.375
I hope I could explain the situation to you.
As of now there is no automatic way to set the Selling Price based on price of other items.
To begin with you can refer to the BOM cost and get an estimate of you costing, based on valuation rate and selling rate. Then you can manually decide the selling rate.
I recommend you can consider customization of "Selling Price " at a later stage when you have working formula based on either the “Valuation rate” or “Last Purchase Rate.”.
@snv and @dhananjay
Thanks a lot for your reply. I’ll check the solutions you have provided and get back to you.
I have done some homework and still no go.
Let’s simplify the situation a little bit. Please see the following example.
I have created 3 UOM as Kg, 16k Box, 20k box.
And also created 1 item attribute as Box and within Box created Kg, 16k Box, 20k Box.
Finally, I have created an item as TST-ITEM-007.
Default UOM as Kg and standard selling price as 12.00.
I then created 2 variants of TST-ITEM-007 based on Box.
Say, they are
i. TST-ITEM-007 16
ii. TST-ITEM-007 20
Now the issue is,
a) I can’t set default unit for variants as the system would inherit it from the template and won’t allow me to change.
b) It should inherit its price from the template, but it doesn’t.
c) Since default UOM can’t be changed, I can’t use unit conversion factor.
Please assist me on this part as I’m badly stuck and can’t proceed any further without creating items.
to me this sounds like making things more complicated then necessary. What is the advantage of basing 3 different teas (3 different products of the same category Tea) on one “Motheritem”?
I’d say you can make live much easier by creating 3 items (Assam Tea, Darjeeling, ShimlaTea) and create the variants (and variant prices) on the package size. That takes out one level of complexity which (in my eyes) does not bring any advantage to the table.
Let us keep the origin aside. Only take an instance of Darjeeling tea.
Say, we purchase it in 20kg sack.
Then we make 100g, 250g, 500g and 1k pack of ours.
Not only we sell all these packs but also 20kg sacs at times.
They all have different bar codes for convenient selling through POS.
Price of all items vary through the base unit price which in this case is kg.
We are struggling to find a solution the create parent-child structure where children will inherit price from its parent item.
We can do that by creating different UOMs. But again it is inconvenient since bar code can’t be assigned to individual UOM. Hence, cant be scanned in POS.
I hope I could clear your doubts.
I think Pricing rule and Item Variant should solve your purpose…
here is one approach.
You use two items per Tea (Darjeeling in my example)
One item is the
raw Material (let’s call it DarjeelingRaw) which you purchase from a Supplier
the second item is the
product you manufacture from that Raw material Darjeeling and sell in 5 Variants (250g, 300g, 500g, 1kg, 20kg). The Attribute would be something like PACKAGE_WEIGHT.
The UOM of both is KG
create a Bill of Materials (BOM) for each Variant
1.) 250g will use 0.25 of the Master item Darjeeling
2.) 300g package set to 0.3 of the Master Item Darjeeling
3.) 500g package … etc.
create a price for each Item Variant (*)
some things to bear in mind:
- you need to have the manufacturing Module enabled and you need to be Manufacturing User (maybe Manager) in order to create BOM’s
- I guess the Purchase Method for the Sales item Darjeeling is “manufacture” while the Purchase for the Raw Material is “Purchase”
(*) maybe u can use Pricing Rules for that part as well as @joshiparthin has suggested
Thanks a lot @joshiparthin and @vrms for your reply and valuable suggestions.
I’ll give it a shot today and let you know about the outcome.
actually I just notes a flaw with my solution. Maybe it’s not a big problem.
@mand3v you actually buy in a big bag/sack with a weight of 20K. So maybe the UOM of purchase is “sack of 20KG” rather then KG?
Can you purchase 25 KG (then you’d only have an MOW of 20 and KG seems to be a fine UOM) or only 1 sack of 20KG, 2 sacks of 20 KG, … ?
This video almost shows what I intend to achieve.
Only 2 things are missing so far.
- Each variant should have its own bar code.
- Price of each variant should be calculated from its template using a multiplication factor.
Is there a way of doing this?
I am Of the opinion that the only viable solution to this is to use bundle products.
How exactly a product bundle is going resolve this issue? It’s an entirely different thing.
What I am asking here may sound complex but that is how it works with most of the grocery stores. It is a basic requirement for selling.
Here is an example of an item being used by one of my clients. The software they are using is proprietary. I want to achieve something like this.
So, as you can see, it is a feature widely used in grocery shops. But, I just simply can’t find a workaround in ERPNext.
You asked a question and I answered. You might not like the answer but it is the ONLY solution to this scenario in ERPNext
Variant will not work because the qty of the variants have no relationship with each other or the template.
Using Multiple UOM will not work because UOMs do not have different barcodes and also do not have unique pricing. The Selling price of a UOM is simply a multiple of the selling price of the base UOM, in retail it does not work like that because the package is usually cheaper per unit than the single unit.
Product Bundle is the only thing that works until ERPNext UOM functionality is extended.
You create the base product, and then create a bundle for each pack size and you can then give this bundle a separate price and barcode.
I hope this makes sense to you.
as far as I know it is not possible to calculate an item or variant price within ERPNext based on whatsoever existing data (like price of the template) by default at all. The only thing (if I am not mistaken) is to calculate the costs of an item through it’s BOM which (if I am not mistaken) only serves as a note and can’t be incorporated in any sort of calculation without additional programming involved.
how about the Variant/BOM way I have mentioned before? To me that seems a little more straight forward then bundles