How do I maintain prices for items with variants in version-15?

ERPNext
1

I have been using erpNext since 2021. Now I updated to version 15 and it is no longer possible to enter prices for the item templates.
How do I update the price for all variants?
When I create a new item, I make a workaround by first saving the template with has_variants=0, then entering the price and then setting it back to has_variants=1.

But how do I enter price changes for existing items with variants?

I have templates with multi-level variants. I can’t manually create the price for or these items by Hand.

How is the management of prices for articles with variants planned in version 15? Is there a new way to change the prices that I don’t know about?

Is it a bug or a feature? :wink: :beetle:

2

You mean you want to bulk update the item price, right?

Please check two videos:

1 Like
3

Thanks for the answer.

I’ll watch the videos in detail over the weekend.

I’ve only scanned them for now.

But considering that’s creating functionality which was already available with one click, it’s pretty cumbersome and actually requires programming knowledge.

And once all the buttons are there, all items still have to be selected manually.
It’s pretty inconvenient to create a functionality that was already there before.

In addition, the 42 lines of pull that deactivated this function force another 50 lines of code to restore the option in a less simple form.

I also don’t understand why it shouldn’t be possible to store a price for the master item. The fact that it cannot be sold means that everything has actually been achieved. It won’t be sold. Why then does entering the price have to be prevented?

The same applies to the tax rate, the warehouse, purchases, and sales. An item template is physically not available. According to this logic, cannot be purchased, has no tax rate and is not stored.
If you look at it that way, the templates would have to be moved to a separate table. If they are only used to create variants and there is no other way to manage them, they are useless.

Or instead, a function should be available that allows a new price to be assigned to all variants of a template item. However, this also means that 200 prices may have to be created and saved for articles with 200 variants. And another 200 lines of code. Although it was so simple and clean before. What about “Keep it simple stupid” (KISS principle)) and “Don’t repeat yourself” (DRY)??

I’m not a coder, but don’t you discuss such changes in the team beforehand? Surely this has far-reaching consequences for the teams of other sections and any paying customers of yours or service providers?

In addition, the complete code that retrieves the price from the template item can then actually be deleted again. Is that the plan?

PS:
For the interim, I’ve commented out the 42 lines of code changes from this pull:
fix: user shouldn't able to make item price for item template by rohitwaghchaure · Pull Request #34189 · frappe/erpnext · GitHub.

4

I agree with this - this was a very useful feature. We have 100s of variants with the same price, and updating the price for each variant is error prone.

5

I’m curious if the old method allowed unique prices on variants (in some cases we may want different prices ie: gold is more expensive than silver).

Import/export can be your friend (export current prices, modify .csv with new prices, import as modify records).

You can also select all variants in list view go to ‘Actions > edit > then select rate field and enter your new prices

If you are maintaining historical prices (have end date) then import/export will be two part process (export current, duplicate the .csv, add end date for current, upload as modify records, edit copy of .csv with new prices, and start date

6

I believe, even earlier, you could over-ride the prices for each of the variants, which is different than what it is set for the template.

Yes, we could import/export prices; however, this is a little error prone - the team could miss to update the price for a few variants, when they are in a hurry. Also, the price list becomes large when you have thousands of items - if we thought of them as templates, it could be as small as 20-30 items only in the price list - easy to monitor and modify.

7

I agree this modification was poorly thought out and implemented in a very restrictive manner.

Perhaps a better implementation would be to have a checkbox (is_template_item) in the item price docType which would change the filtered list to show only template items, rather than blindly resticting users from allowing template prices.

Is there code elsewhere that was changed for “fetching” prices to stop “looking” for template item prices (fetch variant price, then fallback to template variant price if none found)?