Mattsson
f216a60bf8
* feat(invoices): per-line percentage discount and separate fakturamarkning User request: rabatt i procent per artikelrad, and a marking field separate from Er referens. - invoice_items.discount_percent (0-100, default 0): line_total and vat_amount are stored NET of the discount. Shared exact-ore math in lib/invoices/line-amounts.ts (gross, discount, net) used by the web builder, staged-operation commit, editor preview, PDF, and Peppol. Undiscounted lines keep the legacy unrounded qty*price byte-identical. - ROT/RUT deduction computes on the discounted net line total. - invoices.invoice_marking: printed on the PDF next to the references and mapped to Peppol BT-10 BuyerReference (marking wins over your_reference; either satisfies the BT-10 requirement). - Peppol renders the discount as a BG-27 line AllowanceCharge (reason code 95, MultiplierFactorNumeric, Amount, BaseAmount). - Editor: "Lagg till rabatt" in the row menu (same reveal pattern as ROT/RUT), Markning row next to Er referens, forval chip, review dialog shows discounts and marking. - Plumbed through v1 REST projections, MCP create/get/update invoice tools, pending-operations update path, and copy-invoice (discount copied; marking deliberately not, it is recipient-specific). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JJAt9yM7tgZ69f1XnNnq52 * fix(invoices): carry discount_percent through every deduction, credit, convert and preview path Skeptic + CI findings on the discount/marking feature, one pass: - generateRotRutLines and propose-send-lines now pass discount_percent into computeDeduction: the send/credit/cash verifikat booked 1513 on the GROSS line while deduction_total, the PDF and the Skatteverket claim carried the net, stranding the difference on 1513 and pushing 1510 negative once the customer paid. Test pins 1513=3000/1510=7000 for a 20%-discounted 10 000 kr ROT line. - preview-pdf route accepts discount_percent (net totals + net-based deduction) and invoice_marking; the editor now sends the marking, so the preview equals the invoice it becomes. - Credit notes carry discount_percent (buildCreditNoteItem, v1 credit route select+insert, MCP credit executor) and invoice_marking, so the kreditfaktura face arithmetic multiplies out and shows the Rabatt column (ML 17 kap 24 §). - Proforma->invoice convert copies discount_percent + invoice_marking: the converted invoice previously failed Peppol LINE_TOTAL_MISMATCH and lost the rebate on the next builder pass. - Editor hides the discount menu in self-billed mode (the self-billed wire shape has no discount; previewed net would book gross). - MCP staging and commitCreateInvoice reject a non-number discount_percent (a string coerced past the range check but was ignored by the totals math and still stored). - Regenerated skills/accounted-api (apiskill:check CI failure). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JJAt9yM7tgZ69f1XnNnq52 --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
39 lines
2.8 KiB
TypeScript
39 lines
2.8 KiB
TypeScript
/**
|
|
* Shared v1 invoice response projections.
|
|
*
|
|
* The create (POST), detail (GET), and draft-update (PATCH) endpoints all
|
|
* return the same invoice shape; keeping the column lists in one module
|
|
* prevents response-shape drift between them (a PATCH caller must see the
|
|
* same fields a GET caller does). Explicit projection: excludes user_id,
|
|
* company_id (internal scoping) and the encrypted personnummer blob
|
|
* (deduction_personnummer_last4 is the display-safe representation).
|
|
* Schema migrations adding columns must update these lists before the
|
|
* field becomes visible on the public API.
|
|
*/
|
|
|
|
export const INVOICE_FULL_COLUMNS =
|
|
'id, invoice_number, customer_id, invoice_date, due_date, delivery_date, status, currency, exchange_rate, exchange_rate_date, subtotal, subtotal_sek, vat_amount, vat_amount_sek, total, total_sek, ore_rounding, vat_treatment, vat_rate, moms_ruta, your_reference, our_reference, invoice_marking, notes, payment_link_url, stripe_payment_link_id, payment_link_auto, reverse_charge_text, credited_invoice_id, document_type, converted_from_id, paid_at, paid_amount, remaining_amount, default_dimensions, deduction_total, deduction_personnummer_last4, created_at, updated_at'
|
|
|
|
/**
|
|
* Projection for the v1 PDF download route. Narrower than INVOICE_FULL_COLUMNS
|
|
* (no payment-link/dimension internals), but it MUST contain every column the
|
|
* render path reads to compute the customer-facing amount: getAmountToPay
|
|
* derives "Att betala" from total, ore_rounding, deduction_total and
|
|
* credited_invoice_id, and the same figure is locked into the Swish QR
|
|
* (editmask 0). A column missing here silently zeroes that part of the
|
|
* calculation for this surface only: the v1 PDF then disagrees with the
|
|
* dashboard PDF and the sent email for the same invoice, which is exactly
|
|
* the byte-equivalence this endpoint promises. delivery_date is statutory
|
|
* content on top of that: ML 17 kap 24 § requires leveransdatum on the
|
|
* invoice when it differs from the invoice date, and the template renders it
|
|
* exactly then. Pinned by __tests__/invoice-columns.test.ts.
|
|
*/
|
|
export const INVOICE_PDF_COLUMNS =
|
|
'id, invoice_number, customer_id, invoice_date, due_date, delivery_date, status, document_type, ' +
|
|
'currency, subtotal, vat_amount, total, ore_rounding, vat_treatment, vat_rate, moms_ruta, ' +
|
|
'reverse_charge_text, your_reference, our_reference, invoice_marking, notes, credited_invoice_id, ' +
|
|
'paid_amount, remaining_amount, deduction_total, deduction_personnummer_last4'
|
|
|
|
export const INVOICE_ITEM_FULL_COLUMNS =
|
|
'id, sort_order, line_type, description, quantity, unit, unit_price, discount_percent, line_total, vat_rate, vat_amount, article_id, revenue_account, deduction_type, deduction_amount, labor_hours, work_type, housing_designation, apartment_number, brf_org_number, dimensions, created_at'
|