fix(minor): set tax values for item variants

[GursheenK]

Bug
When get_mapped_doc is used to create say a Sales Invoice from a Sales Order and the Order has the Variant of an Item present in it, the system tries to update the taxes for that variant. However, this takes place even if the Variant already has some rows in the taxes table.

Fix

• Only update the taxes for Variant if the child table is empty.
• Set all values for the child table and not just the item tax template value, since either the valid_from or maximum_net_rate is required for sorting the taxes.

no-docs

[codecov]

Codecov Report

Merging #37674 (d436a40) into develop (74a0d64) will increase coverage by 0.00%.
Report is 27 commits behind head on develop.
The diff coverage is 85.26%.

@@           Coverage Diff            @@
##           develop   #37674   +/-   ##
========================================
  Coverage    67.32%   67.32%           
========================================
  Files          757      757           
  Lines        60144    60144           
========================================
+ Hits         40491    40492    +1     
+ Misses       19653    19652    -1     

Files	Coverage Δ
erpnext/accounts/utils.py	73.12% <100.00%> (ø)
...xt/buying/doctype/purchase_order/purchase_order.py	78.99% <ø> (ø)
erpnext/controllers/stock_controller.py	82.02% <ø> (ø)
erpnext/selling/doctype/sales_order/sales_order.py	79.09% <100.00%> (ø)
erpnext/stock/get_item_details.py	83.06% <100.00%> (ø)
...next/stock/report/reserved_stock/reserved_stock.py	46.66% <ø> (ø)
erpnext/stock/doctype/item/item.py	85.01% <0.00%> (ø)
erpnext/stock/doctype/pick_list/pick_list.py	78.77% <85.71%> (ø)
...stock/doctype/purchase_receipt/purchase_receipt.py	91.47% <93.75%> (ø)
erpnext/stock/doctype/stock_entry/stock_entry.py	82.30% <94.73%> (ø)
... and 1 more

... and 1 file with indirect coverage changes

[bosue]

Particularly the days around a change in tax rate, either of the two or even both tax rates may be correct depending on the (respective) Delivery date.

There are circumstances where you‘ll need the pre-1 July tax rate even if you‘re in July already, and there are circumstances where you need the post-1 July tax rate ahead of 1 July. This may all be tied to the actual Delivery or Service date, which may only be finalized later in the process.

I therefore think the proper fix is versioning tax rates, tax accounts etc. in a timeline that doesn‘t live in the transaction, so there‘s no need to update individual transactions. Or updating taxes only upon saving resp. submission of the new transaction and then coupled with a notice or warning.

There may be an expectation that the system doesn‘t automatically change any data enclosed in a DocType when duplicating or mapping ad doc to another doc.

“Only update if…“ seems a bit arbitrary, thus hard to match any expectation, so that‘s why I‘m weighing in. Optimally it should be either always or never, and in the case of taxes, where consistency is needed, it should be always, the open questions only being when, on which data basis and silently or with a warning? We already have too many subtle exceptions in place.

But I may be misunderstanding / misinterpreting something, sry in this case. 😏

[bosue]

Hm, okay, even better if I was wrong.