The qty-sync fix corrects allocation going forward, but receipts billed
before it can keep understated billed_amt, per_billed, and status. The
earlier repair patch only selects over-billed PO items, so it never picks
these up.
Recompute every candidate PO item (multiple submitted receipts, PO-level
invoicing, no invoice-created receipts). update_billed_amount_based_on_po
only writes rows whose recomputed value differs, so already-correct items
are untouched and the patch stays idempotent. This also converges receipts
left with direct-only billed_amt by last-event-wins overwrites.
The amount-capped allocation branch reduced the remaining PO-invoiced
amount but left the invoiced qty untouched. A later receipt entering the
qty-proportional branch then divided by the stale qty and was under-billed:
PO 10 x 500, PO-level PI for 5 (2500), PR1 qty 3 with 500 billed directly
consumes 1000 (pool 2500 -> 1500, qty stuck at 5), PR2 qty 3 got
1500 * 3/5 = 900 instead of its full 1500. Scale the remaining qty by the
consumed fraction so both stay proportional.
Follow-up to #58021.
Move the insert-time check from before_insert to validate. before_insert
runs before set_new_name, so the validation message rendered the
warehouse name as None. validate runs after naming and only applies to
new documents via is_new().
Resolve inheritance through the parent's lft/rgt bounds instead of the
request-cached warehouse account map. The cached map can be stale within
a request (a parent created moments earlier is missing from it), which
made get_warehouse_account trigger a full nested-set rebuild_tree and
could falsely reject a child whose parent carries a valid account.
rebuild_tree enables auto_commit_on_many_writes, which must not run
inside a document insert.
A Purchase Receipt row created from a Purchase Invoice carries both
purchase_order_item and purchase_invoice_item, and its billed_amt is pinned
to the row amount by update_billing_status. Redistributing the PO-invoiced
pool over such rows zeroes the invoice-created receipt and flips it from
Completed to To Bill, so the repair leaves those PO Items untouched.
enable_auto_reserve_stock ran at the end of validate, after
make_packing_list. On a new Sales Order saved with auto_reserve_stock
enabled, packed item rows were built while the parent reserve_stock
flag was still unset, so they never inherited it. Since the stamping in
packed_item.py is gated on doc.is_new(), later saves could not repair
the rows either; only the client-side toggle could. Move the
auto-enable before packing list generation so packed rows are stamped
on first save.
sales invoice's update_current_stock ran one bin query per item row and one
per packed row. delivery note already batched the same work by warehouse, so
lift that into get_bin_qty_map in stock/utils.py and have both call it.
also batch the per-batch expiry_date lookup in get_batches_by_oldest, and drop
three now-unused per-row setters: delivery note's set_actual_qty (already dead
before this change), sales invoice item's set_actual_qty and packed item's
set_actual_and_projected_qty.
three cases: multiple warehouses get a column each plus the total qty
column, a selected group warehouse still expands to its children, and
multiple items report side by side while unselected items stay out.
the item and warehouse filters took one value at a time, so comparing a
few warehouses meant re-running the report for each one.
both are multiselectlist now, matching the stock balance report. the
warehouse column list unions the subtree of every selected warehouse,
and get_items passes a list through instead of wrapping it. plain string
values still work, so saved filters and existing callers are unaffected.
on_update reran toggle_hide_tax_id, toggle_editable_rate_for_bundle_items
and toggle_discount_accounting_fields on every save, rewriting 11
property setters and clearing the meta cache of five doctypes.
Gate each toggle on has_value_changed. Fresh installs save the settings
with pure defaults (set_single_defaults), so the gated-off state must
match the JSON schema: align sales_invoice.json and
sales_invoice_item.json with the values every saved site already has —
tax_id printed when hide_tax_id is off, discount accounts hidden while
discount accounting is disabled. Packed Item rate already matches.
When a Purchase Invoice is raised directly from a Purchase Order (po_detail
set, pr_detail null), update_billed_amount_based_on_po distributes the billed
amount across the PO's Purchase Receipts in FIFO order.
The proportional branch, taken when the invoiced qty exceeds a single
receipt's qty, computed each receipt's share but never deducted the consumed
amount/qty from the running po_billed_amt_details total. As a result every
subsequent receipt was billed against the same amount again, so the receipts
together showed more billed amount than was actually invoiced. A receipt with
no invoice truly against it could reach 100% billed and become Completed,
dropping out of pending-invoice reports.
Deduct the consumed billed_amt and billed_qty in the proportional branch,
mirroring the existing else branch, so each receipt only consumes what is
left. Add a regression test covering a PO invoice spanning two receipts.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Every Selling Settings save reran set_by_naming_series for Customer and
every Buying Settings save reran it for Supplier, rewriting the
naming_series property setters with their cache clears and running the
naming_series backfill UPDATE on the master table.
Gate both on has_value_changed, following Stock Settings. Naming
behaviour is unaffected: Customer.autoname and Supplier.autoname read
the master-name default, which is still set on every save.
Both sales partner summary suites created identical submitted, draft,
cancelled, and returned transactions per doctype. Run both reports
against one fixture set and receive stock only for Delivery Note and
POS Invoice, the doctypes that consume it.
Every Stock Settings save rewrote the Item naming property setters and
the barcode visibility property setters. make_property_setter without a
doctype fans out to every doctype that has the fieldname and clears each
doctype's cache, and set_by_naming_series also backfills tabItem.
Gate both on has_value_changed. Item naming behaviour is unaffected: it
reads the item_naming_by default, which is still set on every save.
* feat(accounts): add Bank Charges account for Payment Entry deductions
Add an optional Bank Charges Account field on Company. When a Payment
Entry has a difference between the paid and received amount (e.g. a
same-currency Internal Transfer where the bank deducted a fee), that
amount now books to the Bank Charges account in the deductions table
instead of always going to the Exchange Gain/Loss account. Left blank,
behavior is unchanged.
Mirrors the resolution on both the server (set_exchange_gain_loss) and
client (set_exchange_gain_loss_deduction) so the deduction row is
pre-filled consistently before and after save. A user's manual account
edit on an existing deduction row is preserved across recalculation,
same as before this change.
* fix(accounts): only route Payment Entry difference to Bank Charges for same-currency transfers
Cross-currency Payment Entries were also matching the unconditional
bank_charges_account precedence, misrouting a genuine exchange
gain/loss into the Bank Charges account. Only prefer Bank Charges
Account when paid_from and paid_to share a currency; cross-currency
differences continue to book to Exchange Gain/Loss Account.
* test(payment_entry): assert against actual exchange gain/loss account, not a hardcoded name
CI failed: _Test Company's exchange_gain_loss_account is auto-provisioned
as "Exchange Gain/Loss - _TC" by the standard chart of accounts, not the
"_Test Exchange Gain/Loss - _TC" account used only by a sibling test.
* fix(accounts): auto-set Bank Charges Account from chart of accounts default
The standard chart of accounts already ships a "Bank Charges" ledger
account, but set_default_accounts() never picked it up into the
Company's bank_charges_account field, unlike its write_off_account and
exchange_gain_loss_account siblings. New and existing companies now
get it auto-populated the same way.
---------
Co-authored-by: test <test@test.com>
Static filters with no doc-dependent values belong on the field
definition, not in JS. Matches the existing pattern used for
Warehouse/Item link_filters elsewhere (e.g. job_card_item.json,
product_bundle_item.json).
