* feat(rot-rut): overview page, beslutsfil import, avslag reclaim, MCP list + settle Follow-up to #2239/#2360 for firms whose every invoice carries ROT/RUT. - /invoices/rot-rut: tiles (at Skatteverket on 1513, awaiting beslut, refused to book, ready to request) and one row per begaran with mark uploaded, cancel, download and "Bokfor nekat belopp"; the Fakturor button links here, ?rot-rut=1 still opens the file dialog. - Beslutsfil import from the UI through the existing import route. - Reclaim of the share Skatteverket refused: one voucher debit 1510 / credit 1513 per invoice (source_type rot_rut_reclaim), CAS-attached to the begaran and guarded by a partial unique index; the invoice reopens for the refused share via invoices.deduction_reclaimed_total, with the customer-share formula and its SQL twin gaining the same term. The payment dialog and bank match then settle the reopened remaining as a plain 1510 clearing; a booked kontantmetod invoice is proposed accrual- shaped so revenue is never recognised twice. Unknown per-invoice split of a partial beslut is refused, never allocated. - MCP: gnubok_list_rot_rut_payout_requests (search-only read) and gnubok_settle_rot_rut_payout (staged write, op settle_rot_rut_payout) sharing one pre-flight + settle with the dashboard match route. - Migrations 20260907140000 (reclaim state, source_type, INSERT guard), 20260907140100/140101 (pending_operations op type). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D9wvsGnvu5tHGqYnJnjnaB * chore(rot-rut): renumber migrations after merging main Main already carries 20260907143000 and 20260907150000, so the three rot-rut migrations move to 20260907160000/160100/160101 to keep the applied order monotonic (see memory: migration-version-collisions). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D9wvsGnvu5tHGqYnJnjnaB * fix(rot-rut): close the reclaim gaps found by skeptics, CI and review Skeptic refutations (#2397): - payment-sync recomputes remaining with deduction_reclaimed_total, so a storno of a payment on a reopened invoice no longer strands the refused share (R1). - Reclaim refused while an invoice sits in a later live begäran (ROT_RUT_RECLAIM_INVOICE_REREQUESTED); the overview and the MCP list hide the action for the same case (C2). - A reclaimed invoice is blocked from a new begäran (DEDUCTION_RECLAIMED) until the reclaim voucher is reversed (R2/C3). - Storno of the reclaim voucher syncs the invoices and the begäran back (rot-rut-reclaim-reversal.ts, hooked into reverseEntry) (R3). - A paid invoice with NULL paid_amount counts its customer share as paid (C4). Crediting an invoice with a reclaimed share is refused on the dashboard, v1 and MCP paths (R4). CI and review: - Build: custom-coded MCP errors via Object.assign, not codedError. - pg-real: column default for default_voucher_series_per_source_type re-stated with rot_rut_reclaim (20260907160200); the default test now re-applies the latest default migration. - Checks: accounted-api skill regenerated (journal-entries source types). - CodeRabbit/Superagent: per-item refused shares must reconcile with the request-level beslut; per-invoice reopen through the idempotent RPC apply_rot_rut_reclaim_invoice (20260907160300) with a resume path; update-stage settle failures keep the voucher id (failed_partial); Stockholm calendar date for the booking; existing-voucher tab uses the same proposal method; MCP stage checks bank_line junction rows. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D9wvsGnvu5tHGqYnJnjnaB * fix(rot-rut): carry the voucher id through the match outcome type; date the reclaim on the beslut - The shared match outcome now declares journalEntryId on update-stage errors, matching the settle service (Core Build TS2339 on 2d6cece1a). - The reclaim voucher is dated on the Swedish calendar day of Skatteverkets beslut (decided_at), today only when no decision date is recorded, and the confirm dialog states the date (Swedish accounting review: BFL 5 kap 6-7 §, datum for affarshandelsen). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D9wvsGnvu5tHGqYnJnjnaB * fix(rot-rut): reclaim RPCs validate the share and derive the invoice state; idempotent revert; v1 credit guard reads the column - apply_rot_rut_reclaim_invoice (20260907160400 replaces the 160300 signature) takes only the refused share, validates it against the locked item, request and invoice, and derives remaining_amount and status from the INSERT-guard formula (review: caller-supplied accounting values, CWE-862). revert_rot_rut_reclaim_invoice mirrors it for a reversed reclaim voucher; the request link is cleared only after every leg. - v1 credit route projection includes deduction_reclaimed_total so the reclaim guard actually fires there. - Overview keeps "Bokfor nekat belopp" available while legs are pending (resume after a partial failure). - Match and settle routes attach journal_entry_id on update-stage errors. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D9wvsGnvu5tHGqYnJnjnaB --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
79 lines
3.8 KiB
TypeScript
79 lines
3.8 KiB
TypeScript
/**
|
|
* The customer's share of an invoice: ONE definition.
|
|
*
|
|
* Under ROT/RUT fakturamodellen the company invoices the full amount and the
|
|
* customer pays the total minus the skattereduktion; the deduction is a
|
|
* fordran on Skatteverket carried on 1513, never on the customer
|
|
* (swedish-invoice-compliance, invoice-rules.md section 8). Every settlement
|
|
* path records the customer share as the payment row amount, so "what is
|
|
* still outstanding" must be measured against that share.
|
|
*
|
|
* This arithmetic used to be re-derived by hand at every reader and one copy
|
|
* drifted (#2248: the kontantmetod cut-off compared payments against the
|
|
* gross total). It now lives here and in exactly one SQL twin:
|
|
*
|
|
* invoices_derive_remaining_amount (migrations 20260817191708, 20260907160000)
|
|
* remaining_amount = GREATEST(0, ROUND(total - paid_amount - deduction_total
|
|
* + deduction_reclaimed_total, 2))
|
|
*
|
|
* deduction_reclaimed_total is the part of the deduction Skatteverket refused
|
|
* and that a rot_rut_reclaim voucher moved back onto the customer (debit 1510
|
|
* / credit 1513): from then on it IS the customer's to pay, while the invoice
|
|
* document keeps the deduction it was issued with.
|
|
*
|
|
* Change both or neither. The guard floors at zero because it persists the
|
|
* column; the functions here return the signed value and each writer applies
|
|
* the floor it needs (payment-sync mirrors GREATEST(0, ...), the kontantmetod
|
|
* cut-off floors on the invoice's own side so credit notes keep their sign).
|
|
*/
|
|
import { roundOre } from '@/lib/money'
|
|
|
|
/** The invoice header fields the customer-share arithmetic reads. */
|
|
export interface CustomerShareInvoice {
|
|
/** Invoice total including moms, in invoice currency. Negative on a credit note. */
|
|
total: number
|
|
/**
|
|
* ROT/RUT skattereduktion in invoice currency. Stored as a positive
|
|
* magnitude under CHECK (deduction_total >= 0), also on a credit note.
|
|
* Null, undefined and 0 all mean "no deduction".
|
|
*/
|
|
deduction_total?: number | null
|
|
/**
|
|
* The part of the deduction Skatteverket refused and that was booked back
|
|
* onto the customer (rot_rut_reclaim). Positive magnitude, never above the
|
|
* deduction (CHECK invoices_deduction_reclaimed_total_check). Null,
|
|
* undefined and 0 all mean "nothing reclaimed".
|
|
*/
|
|
deduction_reclaimed_total?: number | null
|
|
}
|
|
|
|
/**
|
|
* What the customer owes on the invoice: total minus the ROT/RUT deduction,
|
|
* plus whatever part of that deduction Skatteverket later refused.
|
|
*
|
|
* The deduction follows the sign of the total, so a credited ROT invoice
|
|
* (total -25 000, deduction_total 7 500) owes the customer -17 500 back and
|
|
* nets to zero against its original. An invoice without a deduction returns
|
|
* its total exactly as stored.
|
|
*/
|
|
export function invoiceCustomerShare(invoice: CustomerShareInvoice): number {
|
|
const deduction = Math.abs(invoice.deduction_total ?? 0)
|
|
// `!(x > 0)` also catches NaN: a non-numeric deduction reads as none rather
|
|
// than poisoning every downstream amount.
|
|
if (!(deduction > 0)) return invoice.total
|
|
const reclaimedRaw = Math.abs(invoice.deduction_reclaimed_total ?? 0)
|
|
const reclaimed = reclaimedRaw > 0 ? Math.min(reclaimedRaw, deduction) : 0
|
|
return roundOre(invoice.total - Math.sign(invoice.total) * (deduction - reclaimed))
|
|
}
|
|
|
|
/**
|
|
* The customer's share still unpaid after `paid`, signed and unfloored:
|
|
* positive is a fordran on the customer, negative means over-collected (or,
|
|
* on a credit note, still owed back). `paid` is the sum of the payment rows
|
|
* the caller considers settled (all of them, or only those on or before a
|
|
* cut-off date), in invoice currency.
|
|
*/
|
|
export function invoiceCustomerOutstanding(invoice: CustomerShareInvoice, paid: number): number {
|
|
return roundOre(invoiceCustomerShare(invoice) - paid)
|
|
}
|