* fix(stock): distribute additional costs when incoming items have no value
when every incoming row has zero basic amount, for example a raw material
purchased at zero rate, distribute_additional_costs returned early and left
additional_cost at 0 on the finished item. the charges were never capitalised
into valuation and the balancing debit stayed in stock adjustment instead of
reaching stock in hand.
the gl composer had its own quantity fallback for the same case, but it divided
by the qty of every row rather than the incoming ones, so a manufacture entry
booked only a fraction of the cost to the expense account, and it apportioned
by qty while valuation apportions by stock qty, which split rows of differing
conversion factors two different ways.
both sides now take the rows, the basis and its total from a single
get_additional_cost_allocation, falling back to transfer_qty so valuation and gl
cannot disagree. the basis is unchanged whenever the incoming rows carry value.
* test(stock): cover additional cost distribution for zero valued items
adds qty based distribution cases for manufacture and material receipt, a
manufacture entry asserting the whole cost reaches its expense account, and a
conversion factor case asserting the gl split matches the valuation split.
updates test_total_basic_amount_zero, which asserted the cost landing in stock
adjustment rather than being capitalised.
* fix(manufacturing): share transfer stock across Production Plan rows
Fetch available stock once per item for the total demand and consume it across rows. Combine batch splits into one transfer row per source warehouse and demand. Round transfer quantities to the plan item precision so the shared balance never leaves a float residue as an extra row.
* test(manufacturing): cover shared transfer stock across Production Plan rows
* fix(manufacturing): apply MOQ once across Production Plan rows
Apply Minimum Order Qty after stock and transfer allocation, grouped by item, warehouse, request type, supplier and Sales Order. Material Requests and Purchase Orders are raised per Sales Order and a Purchase Order rejects an item below its minimum, so each Sales Order buys at least the minimum or is covered by the surplus of an earlier one. The surplus is the quantity actually purchased beyond demand, so purchase UOM and whole-number rounding carry forward.
* test(manufacturing): cover MOQ once across Production Plan rows
* fix(banking): reset scroll on searching accounts
* fix(banking): show only past dates in date filter
* fix(banking): clean up line heights and remove beta badge
* fix(banking): show accurate count of import progress
fix(banking): show latest 20 imports instead of 10
* fix(banking): layout sizing needs to be preserved on page change
* fix(banking): cleaner bank balance UI
* fix(banking): correctly parse Cr/Dr values in statement importer
* Update banking/src/components/features/BankReconciliation/BankBalance.tsx
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
* fix: user not able to set valuation rate zero in stock reco
* fix: wrong difference amount when valuation rate is zero
* fix: blank valuation rate should not be treated as a change
* fix(bank reconciliation): match Payment Entries on the bank-side amount
get_pe_matching_query() ranked and filtered on pe.paid_amount while the
match card displayed pe.base_paid_amount_after_tax, so the amount used for
the exact match never matched the amount shown.
Both now use the amount that actually hits the bank account, in that
account's currency: received_amount_after_tax when the bank account is
paid_to (deposit) and paid_amount_after_tax when it is paid_from
(withdrawal). This is the same convention as the Bank Reconciliation
Statement report and matches the bank GL entry that reconciliation
allocates against.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(bank reconciliation): cover bank-side amount matching
Two cases the previous behaviour got wrong or could regress on:
- A deposit from an internal transfer where the paid and received sides
differ by a charge. The match must show, and compare against, the
amount that reached this bank account.
- A withdrawal, which still matches on the paid side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
