Files
accounted/lib/pending-operations/schemas/update-invoice.ts
T
MattssonandClaude Fable 5 f216a60bf8 feat(invoices): per-line percentage discount and separate fakturamarkning (#2084)
* 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>
2026-08-31 15:34:06 +02:00

50 lines
1.8 KiB
TypeScript

import { z } from 'zod'
import { CreateInvoiceItemSchema } from '@/lib/api/schemas'
import { DimensionsBagSchema } from '@/lib/bookkeeping/dimension-resolver'
const isoDate = z.string().regex(/^\d{4}-\d{2}-\d{2}$/, 'Expected YYYY-MM-DD')
/**
* Staged update_invoice params: { invoice_id, changes }.
*
* Deliberately excludes customer_id, currency, document_type, invoice_number,
* and status: those are structural or server-controlled, and a draft that
* needs a different customer or currency is recreated instead. `items` is a
* FULL REPLACE: when present, every existing invoice_items row is deleted and
* the array becomes the new line set. The item shape reuses the web API's
* CreateInvoiceItemSchema so accrual, ROT/RUT, and posting-account rules
* cannot drift between the surfaces.
*/
const InvoiceChangesSchema = z
.object({
notes: z.string().optional(),
invoice_date: isoDate.optional(),
due_date: isoDate.optional(),
delivery_date: isoDate.nullable().optional(),
your_reference: z.string().optional(),
our_reference: z.string().optional(),
// Fakturamärkning: buyer-required marking, separate from your_reference.
invoice_marking: z.string().max(200).optional(),
items: z.array(CreateInvoiceItemSchema).min(1, 'At least one item is required').optional(),
// Replaces the whole bag; {} clears all tags.
default_dimensions: DimensionsBagSchema.optional(),
})
.strict()
.superRefine((changes, ctx) => {
if (Object.keys(changes).length === 0) {
ctx.addIssue({
code: 'custom',
message: 'At least one invoice field must be supplied',
})
}
})
export const UpdateInvoiceParamsSchema = z
.object({
invoice_id: z.string().uuid(),
changes: InvoiceChangesSchema,
})
.strict()
export type UpdateInvoiceParams = z.infer<typeof UpdateInvoiceParamsSchema>