* feat(invoices): disclose invoice-register coverage gaps + amount search After a SIE migration or verifikat backfill, customer invoices exist only as journal entries: the invoice list, kundreskontran, /api/invoices, v1 invoices.list, and MCP list_invoices all looked complete while silently omitting everything before the register's first invoice (user report: two invoiced fees nearly re-invoiced as "uninvoiced"). - lib/invoices/invoice-register-coverage.ts: coverage boundary = earliest register invoice; flags posted non-invoice-engine AR verifikat (1510/1513) before it. AR-keyed, not source_type='import'-keyed, so manual/API backfills are caught too. - Invoice list page: one attn line disclosing the boundary (sv+en). - Kundreskontra: register_coverage in the report payload, rendered in the summary card and as an explanation under "Ej avstamd". - /api/invoices GET: invoice_register_coverage in the response. - v1 invoices.list: meta.coverage + registry pitfall documenting it. - MCP gnubok_list_invoices: invoice_register_coverage + coverage_note on the first page, pointing agents at gnubok_query_journal. - Search: lib/invoices/invoice-search.ts matches net (subtotal) and gross amounts with sv-SE formatting, alongside number/customer matching; a known net amount like 14 000 now finds the 17 500 kr row. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VcW5BU6mU1vNbWpkMKHbHF * fix(invoices): harden register-coverage probe, period-gate reconciliation note, regen api skill Skeptic + CI findings folded into one pass: - Coverage probe: a failed AR lookup now degrades to UNKNOWN (NO_INVOICE_REGISTER_COVERAGE), never to a confident "complete". - Probe driven from journal_entries (company-indexed) with the AR line condition as an inner embed, instead of the lines-table-with-embed-filters shape that lateral-scans every tenant (lib/bookkeeping/entry-lines.ts). - DEBIT-only 1510/1513 lines; excludes every invoice-engine source type (invoice_created, invoice_paid, invoice_cash_payment, credit_note, reminder_fee, rot_rut_payout, storno, correction): an advance payment crediting 1510 or a re-dated rattelse of an engine entry no longer flags. - covers_from ignores drafts so a backdated draft cannot move the boundary. - Kundreskontra "Ej avstamd" explanation is now gated on pre-register AR debits existing IN the reconciled period (new ARReconciliationResult.pre_register_ar_in_period): prior-period migration history cannot explain this period's difference and must not excuse a real felbokning. Wording no longer says "snarare an felbokning". - MCP coverage_note states the earliest register invoice date rather than claiming the register "covers" from it. - Amount search compares magnitudes so credit notes (negative totals) are findable; "-17500" parses; null amounts never match "0". - skills/accounted-api regenerated from the registry (apiskill:check). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VcW5BU6mU1vNbWpkMKHbHF * chore(api-skill): regenerate accounted-api skill after merging origin/main Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VcW5BU6mU1vNbWpkMKHbHF * fix(invoices): round-2 review fixes for register-coverage disclosure - covers_from now anchors on real invoices only (document_type='invoice', non-draft): proformas/delivery notes cannot move the boundary. - INVOICE_ENGINE_SOURCE_TYPES exported + a test scans the engine writers (invoice-entries, reminder-fee, rot-rut, storno-service) so a future source_type cannot silently become false pre-register evidence. - Kundreskontra guidance names both 1510 and 1513. - MCP gnubok_list_invoices outputSchema declares invoice_register_coverage and coverage_note. - v1 reports.ar-ledger documents data.register_coverage; invoices.list example made internally consistent; api skill regenerated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VcW5BU6mU1vNbWpkMKHbHF * fix(mcp): keep gnubok_list_invoices outputSchema minimal to hold the tools/list token budget The expanded schema from the round-2 review pushed tools/list to 61 726 tokens against the held 61 600 ceiling (payload-size.bench.test.ts). The ceiling is policy, not a baseline to bump: the description already tells agents to read invoice_register_coverage/coverage_note, and paginatedSchema has no additionalProperties:false, so the fields stay schema-valid. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VcW5BU6mU1vNbWpkMKHbHF --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
153 lines
6.6 KiB
TypeScript
153 lines
6.6 KiB
TypeScript
import type { SupabaseClient } from '@supabase/supabase-js'
|
|
import { resolveSekAmount } from '@/lib/bookkeeping/currency-utils'
|
|
import { fetchAllRows } from '@/lib/supabase/fetch-all'
|
|
import { fetchEntryLines, type EntryLinesQuery } from '@/lib/bookkeeping/entry-lines'
|
|
import { hasPreRegisterArInPeriod } from '@/lib/invoices/invoice-register-coverage'
|
|
|
|
export interface ARReconciliationResult {
|
|
ar_ledger_total: number
|
|
/**
|
|
* Sum of posted balances on accounts 1510 (Kundfordringar) and 1513
|
|
* (Kundfordringar: delad faktura). 1513 covers the Skatteverket portion
|
|
* of ROT/RUT fakturamodellen invoices and is zero today (no fakturamodellen
|
|
* postings yet): included for forward compatibility.
|
|
*/
|
|
account_1510_balance: number
|
|
difference: number
|
|
is_reconciled: boolean
|
|
/**
|
|
* Number of foreign-currency invoices that lacked an exchange_rate, so their
|
|
* outstanding amount could not be converted to SEK. When > 0 the difference
|
|
* field may be misleading: any reported gap could be missing-data rather
|
|
* than a true reconciliation break.
|
|
*/
|
|
unconverted_fx_count: number
|
|
/**
|
|
* True when posted non-invoice-engine AR debit verifikat dated before the
|
|
* register's first invoice exist IN THIS PERIOD (migrated/backfilled
|
|
* invoice history). Only then may a renderer offer "migration" as an
|
|
* explanation for the difference: pre-boundary activity settled in an
|
|
* earlier period contributes nothing to this period's balance, and
|
|
* offering it anyway would cushion a genuine felbokning.
|
|
* Optional so report fixtures elsewhere stay valid; generateARReconciliation
|
|
* always sets it.
|
|
*/
|
|
pre_register_ar_in_period?: boolean
|
|
}
|
|
|
|
/**
|
|
* Compare sum of open customer invoices against account 1510 balance.
|
|
* Account 1510 is debit-normal (asset): balance = debits - credits.
|
|
*
|
|
* Conversion uses each invoice's stored exchange_rate (the invoice-date rate),
|
|
* which matches what was originally posted to 1510. This means the report will
|
|
* diverge from the GL once partial payments settle at a different rate (the
|
|
* delta is correctly booked as valutakursvinst/-förlust to 3960/7960 per
|
|
* ML 8 kap 21-23 §). A subledger-derived total would reconcile through that
|
|
* difference; deferred to a follow-up.
|
|
*/
|
|
export async function generateARReconciliation(
|
|
supabase: SupabaseClient,
|
|
companyId: string,
|
|
periodId: string
|
|
): Promise<ARReconciliationResult> {
|
|
|
|
// total/paid_amount are stored in invoice currency; account 1510 is in SEK
|
|
// (booked at invoice-date rate), so convert each row before summing.
|
|
// Paginated: a company with >1000 open invoices would otherwise be silently
|
|
// truncated, manufacturing a phantom reconciliation gap.
|
|
const invoices = await fetchAllRows<{
|
|
id: string
|
|
total: number | null
|
|
paid_amount: number | null
|
|
currency: string | null
|
|
exchange_rate: number | null
|
|
}>(({ from, to }) =>
|
|
supabase
|
|
.from('invoices')
|
|
.select('id, total, paid_amount, currency, exchange_rate')
|
|
.eq('company_id', companyId)
|
|
// Proformas, delivery notes and quotes are never receivables.
|
|
.eq('document_type', 'invoice')
|
|
.in('status', ['sent', 'overdue'])
|
|
.order('id', { ascending: true })
|
|
.range(from, to)
|
|
)
|
|
|
|
let unconvertedFxCount = 0
|
|
const arLedgerTotal = (invoices || [])
|
|
.reduce((sum, inv) => {
|
|
const isFx = inv.currency && inv.currency !== 'SEK'
|
|
const hasRate = inv.exchange_rate != null && Number(inv.exchange_rate) > 0
|
|
// Skip unconvertible FX rows from the sum: adding raw foreign amounts
|
|
// to a SEK total is arithmetically unsound. Counted instead.
|
|
if (isFx && !hasRate) {
|
|
unconvertedFxCount += 1
|
|
return sum
|
|
}
|
|
const outstanding = (Number(inv.total) || 0) - (Number(inv.paid_amount) || 0)
|
|
const sek = resolveSekAmount(outstanding, null, inv.currency, inv.exchange_rate)
|
|
return Math.round((sum + sek) * 100) / 100
|
|
}, 0)
|
|
|
|
// Get AR receivable balance from the ledger in this period. We sum 1510
|
|
// (Kundfordringar) AND 1513 (Kundfordringar: delad faktura) so the comparison
|
|
// stays correct under ROT/RUT fakturamodellen, where the customer portion sits
|
|
// on 1510 and the Skatteverket claim on 1513: both are open AR receivable
|
|
// from the company's perspective. 1513 is zero today (no fakturamodellen
|
|
// postings yet) so this is a forward-looking defense.
|
|
//
|
|
// We count posted AND reversed entries together: the SAME inclusion rule the
|
|
// trial balance / balance sheet use. A corrected invoice flips its original to
|
|
// status='reversed'; that reversed leg is cancelled by the posted storno, so
|
|
// both must be summed or a corrected invoice manufactures a phantom gap.
|
|
// Fetched via the two-step entry-lines helper (entries first, then lines
|
|
// chunked by entry id, both paginated): see lib/bookkeeping/entry-lines.ts.
|
|
const journalLines = await fetchEntryLines<{
|
|
id: string
|
|
debit_amount: number | null
|
|
credit_amount: number | null
|
|
}>({
|
|
supabase,
|
|
lineColumns: 'id, debit_amount, credit_amount',
|
|
filterEntries: (q: EntryLinesQuery) =>
|
|
q
|
|
.eq('company_id', companyId)
|
|
.eq('fiscal_period_id', periodId)
|
|
.in('status', ['posted', 'reversed']),
|
|
filterLines: (q: EntryLinesQuery) => q.in('account_number', ['1510', '1513']),
|
|
attachEntriesAs: null,
|
|
})
|
|
|
|
// Both 1510 and 1513 are debit-normal assets: balance = debits - credits
|
|
let account1510Balance = 0
|
|
for (const line of journalLines) {
|
|
account1510Balance = Math.round((account1510Balance + (Number(line.debit_amount) || 0) - (Number(line.credit_amount) || 0)) * 100) / 100
|
|
}
|
|
|
|
const difference = Math.round((arLedgerTotal - account1510Balance) * 100) / 100
|
|
|
|
// Coverage context for the difference. Non-fatal: a failed lookup degrades
|
|
// to "no explanation offered" (the helper returns false on failure), which
|
|
// leaves the red badge standing unqualified rather than excused.
|
|
let preRegisterArInPeriod = false
|
|
try {
|
|
preRegisterArInPeriod = await hasPreRegisterArInPeriod(supabase, companyId, periodId)
|
|
} catch {
|
|
// keep false
|
|
}
|
|
|
|
return {
|
|
ar_ledger_total: Math.round(arLedgerTotal * 100) / 100,
|
|
account_1510_balance: Math.round(account1510Balance * 100) / 100,
|
|
difference,
|
|
// BFL 5 kap requires the reconciliation to cover all affärshändelser. If
|
|
// any row was excluded for a missing exchange rate, the calculation is
|
|
// incomplete by construction and we cannot honestly stamp the period
|
|
// Avstämd: the user must fix the underlying data first.
|
|
is_reconciled: Math.abs(difference) < 0.01 && unconvertedFxCount === 0,
|
|
unconverted_fx_count: unconvertedFxCount,
|
|
pre_register_ar_in_period: preRegisterArInPeriod,
|
|
}
|
|
}
|