* chore: MCP intent-tools, BankID enrichment table, multi-tenant fixes MCP server gains six intent-shaped tools that collapse multi-call agent flows into one: vat_close_check, query_journal, auto_match_period, create_supplier_invoice_from_inbox, audit_package, year_end_readiness. Tools wired into TOOL_SCOPE_MAP and OPERATION_RISK_TIERS as appropriate (create_supplier_invoice_from_inbox at medium tier — reversible until approve, but stages a leverantörsskuld). BankID enrichment now persists to a dedicated bankid_enrichment table keyed by user_id. extension_data has been company-scoped (NOT NULL company_id) since the multi-tenant refactor, so every BankID signup has silently been failing the enrichment upsert. Select-company picker reads from the new table. delete_last_voucher (BFNAR 2013:2) needs to clear document_attachments.journal_entry_id before deleting the entry, but the new document immutability trigger blocks that UPDATE. Added the same gnubok.allow_delete transaction-scoped bypass pattern used by the journal-entry/line/retention triggers. pg-real tests cover the happy path, the unauthorized direct UPDATE, and the swap-to-different-entry attempt under the bypass flag. fiscal_periods.no_overlapping_fiscal_periods exclusion was scoped to user_id from before multi-tenant — rebound to company_id so the same user can have overlapping fiscal years across companies they own/are member of. Also adds scripts/seed-demo-account.ts for end-to-end demo seeding (two companies, full FY2025, active FY2026 with mixed state). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(pr-402): address review feedback Migrations - Drop 20260506140000_document_journal_entry_immutability_delete_bypass.sql: redundant with 20260506140000_document_journal_entry_immutability_bypass.sql that landed on main while this branch was open. Both share the same gnubok.allow_delete pattern; main's version is what the DB actually has. - Rename 20260506150000_bankid_enrichment_table.sql → 20260506160000_bankid_enrichment_table.sql to clear the timestamp clash with 20260506150000_protect_document_journal_link.sql on main (Supabase branch preview was failing on schema_migrations PK collision). Tests - Drop the swap-under-flag test from delete-last-voucher.pg.test.ts: main's bypass returns NEW unconditionally when gnubok.allow_delete='true', so the swap is permitted. Drop the duplicate happy-path test (already covered by 'clears journal_entry_id on attached documents and deletes the voucher'). Keep the unauthorized-direct-UPDATE test. - Add bankid-enrichment.pg.test.ts covering the SELECT RLS policy: user reads own row, cannot read another user's row, INSERT denied for authenticated. gnubok_query_journal - amount_min/amount_max is applied post-fetch (PostgREST can't OR abs(debit) and abs(credit) cleanly), but PostgREST's count is computed pre-filter. Reporting that as total_lines mislead agents into paginating a tail that was already filtered out. When the amount filter is applied, anchor total_lines and truncated to the filtered set and surface db_matched_pre_amount_filter + amount_filter_applied_post_fetch separately. - Escape `_` in the free-text LIKE filter so a search for "2_441" doesn't match "2X441". VAT close check - Reverse-charge blocker no longer fires on ruta 30 (seller-side domestic omvänd skattskyldighet) — the seller books no VAT, the buyer does, so missing ruta 48 is expected. Now scoped to ruta 31/32 (EU acquisition) where the buyer must book both calculated output (2615) and matching ingående moms (2645). - High-value receipt threshold no longer reads journal_entries.total_amount (column doesn't exist; check silently never fired). Sums debits across the entry's lines, which equals the gross for ordinary purchase entries — comparing a gross figure against the BFL/ML 4 000 SEK threshold per ML 17 kap 26–28 §. seed-demo-account.ts - Require an explicit email argument; refuse to run with the previously hardcoded fallback that would silently target a real user. Ensure email is non-undefined for downstream typing. - Type the supabase fiscal_periods insert result locally so tsc no longer reports 'fp implicitly any' from the loose untyped client. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): adjust fiscal-period-start-day pg test for per-company overlap The pg-real failure on PR #402 was a latent bug surfaced by this branch's fiscal_periods exclusion constraint flip from user_id to company_id (migration 20260506140100). The test was inserting periods that overlapped seedCompany's default 2026-01-01..2026-12-31 period; the previous constraint slipped past it because the test's INSERT didn't set user_id (NULL escapes the WITH = match), so two same-company overlapping periods silently coexisted. Now that the constraint correctly fires per company, pick years that don't overlap with the seeded 2026 period. The trigger's behavior under test (allow mid-month start when no earlier period exists, allow back-dated SIE imports, reject mid-month start when an earlier period exists) is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(vat-close-check): correct reverse-charge/import blocker rutor Rutor 30/31/32 are the buyer's calculated utgående moms on reverse- charge purchases (domestic byggtjänster/electronics → 2614 → ruta 30; EU goods → 2624 → ruta 31; EU services → 2634 → ruta 32). The buyer must also book matching ingående moms (2647 inhemskt / 2645 utlandet → ruta 48). The previous fix removed ruta 30 on the basis that it was seller-side; that's incorrect — domestic-RC sellers book no VAT at all (they report only beskattningsunderlag on ruta 41), so 2614 only sees buyer-side entries. Restore ruta 30. Also extend the check to import rutor 60/61/62 (non-EU import VAT declared via momsdeklaration since 2015 — 2615/2625/2635). Same mechanic: importer books output VAT on these rutor and deducts the input side via ruta 48. SaaS-from-AWS / OpenAI / Vercel companies hit this path; without including 60/61/62 the blocker would silently miss their misbookings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(mcp): expose ruta 60/61/62 (import VAT) on the local VatReportResult The vat-close-check fix referenced vatReport.rutor.ruta60/61/62 but the MCP server's local VatReportResult type only carries ruta 05-49. Build broke on tsc. Extend the MCP server's slim VAT report to also project import VAT — 2615 → ruta 60 (25%), 2625 → ruta 61 (12%), 2635 → ruta 62 (6%) — and fold those into ruta 49 (att betala/återfå). Mirrors the BAS-to-Ruta mapping in lib/reports/vat-declaration.ts. Output schema and required list updated accordingly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
149 lines
5.6 KiB
TypeScript
149 lines
5.6 KiB
TypeScript
/**
|
|
* Unit tests for gnubok_auto_match_period.
|
|
*
|
|
* Verifies registration, dry-run preview shape, confidence threshold filtering,
|
|
* and the no-match counters. Per-item staging fault isolation is covered by
|
|
* the existing stagePendingOperation tests.
|
|
*/
|
|
import { describe, it, expect, vi, beforeEach } from 'vitest'
|
|
import { tools } from '../server'
|
|
import { TOOL_SCOPE_MAP } from '@/lib/auth/api-keys'
|
|
|
|
vi.mock('@/lib/invoices/invoice-matching', () => ({
|
|
findMatchingInvoices: vi.fn(),
|
|
}))
|
|
|
|
import { findMatchingInvoices } from '@/lib/invoices/invoice-matching'
|
|
|
|
describe('gnubok_auto_match_period — registration', () => {
|
|
it('is registered', () => {
|
|
const tool = tools.find((t) => t.name === 'gnubok_auto_match_period')
|
|
expect(tool).toBeDefined()
|
|
// Stages writes when dry_run=false, so not read-only
|
|
expect(tool?.annotations.readOnlyHint).toBe(false)
|
|
expect(tool?.annotations.destructiveHint).toBe(false)
|
|
})
|
|
|
|
it('requires date_from and date_to', () => {
|
|
const tool = tools.find((t) => t.name === 'gnubok_auto_match_period')!
|
|
const schema = tool.inputSchema as { required?: string[] }
|
|
expect(schema.required).toContain('date_from')
|
|
expect(schema.required).toContain('date_to')
|
|
})
|
|
|
|
it('is mapped to transactions:write scope', () => {
|
|
expect(TOOL_SCOPE_MAP.gnubok_auto_match_period).toBe('transactions:write')
|
|
})
|
|
})
|
|
|
|
/**
|
|
* Build a mock that returns a fixed transactions array on the
|
|
* .from('transactions').select(...).eq(...).gte(...).lte(...).gt(...).is(...).is(...).order(...).limit(...)
|
|
* call chain.
|
|
*/
|
|
function makeTxMock(transactions: unknown[]) {
|
|
const result = { data: transactions, error: null }
|
|
const buildChain = (): unknown =>
|
|
new Proxy(
|
|
{},
|
|
{
|
|
get(_t, prop) {
|
|
if (prop === 'then') {
|
|
return (resolve: (v: unknown) => void) => resolve(result)
|
|
}
|
|
return () => buildChain()
|
|
},
|
|
},
|
|
)
|
|
return {
|
|
from: vi.fn().mockImplementation(() => buildChain()),
|
|
} as never
|
|
}
|
|
|
|
describe('gnubok_auto_match_period — dry run', () => {
|
|
beforeEach(() => {
|
|
vi.clearAllMocks()
|
|
})
|
|
|
|
it('returns proposals at and above the confidence threshold, classifies the rest', async () => {
|
|
const txs = [
|
|
{ id: 't1', date: '2026-03-01', amount: 1000, currency: 'SEK', description: 'Pay 1', merchant_name: null, reference: null, journal_entry_id: null, invoice_id: null },
|
|
{ id: 't2', date: '2026-03-02', amount: 500, currency: 'SEK', description: 'Pay 2', merchant_name: null, reference: null, journal_entry_id: null, invoice_id: null },
|
|
{ id: 't3', date: '2026-03-03', amount: 200, currency: 'SEK', description: 'Pay 3', merchant_name: null, reference: null, journal_entry_id: null, invoice_id: null },
|
|
]
|
|
const supabase = makeTxMock(txs)
|
|
|
|
vi.mocked(findMatchingInvoices)
|
|
// t1: high confidence — should propose
|
|
.mockResolvedValueOnce([
|
|
{ invoice: { id: 'i1', invoice_number: 'INV-1', total: 1000, customer: { name: 'Acme' } } as never, confidence: 0.95, matchReason: 'Exakt belopp + kund' },
|
|
])
|
|
// t2: below threshold (0.7 < 0.9)
|
|
.mockResolvedValueOnce([
|
|
{ invoice: { id: 'i2', invoice_number: 'INV-2', total: 500, customer: { name: 'Foo' } } as never, confidence: 0.7, matchReason: 'Belopp matchar' },
|
|
])
|
|
// t3: no match
|
|
.mockResolvedValueOnce([])
|
|
|
|
const tool = tools.find((t) => t.name === 'gnubok_auto_match_period')!
|
|
const result = (await tool.execute(
|
|
{
|
|
date_from: '2026-03-01',
|
|
date_to: '2026-03-31',
|
|
confidence_threshold: 0.9,
|
|
dry_run: true,
|
|
},
|
|
'company-1',
|
|
'user-1',
|
|
supabase,
|
|
)) as {
|
|
dry_run: boolean
|
|
scanned_transactions: number
|
|
proposed_matches: number
|
|
below_threshold: number
|
|
no_match_found: number
|
|
staged_count: number
|
|
proposals: { decision: string; transaction_id: string; confidence: number }[]
|
|
}
|
|
|
|
expect(result.dry_run).toBe(true)
|
|
expect(result.scanned_transactions).toBe(3)
|
|
expect(result.proposed_matches).toBe(1)
|
|
expect(result.below_threshold).toBe(1)
|
|
expect(result.no_match_found).toBe(1)
|
|
expect(result.staged_count).toBe(0)
|
|
|
|
const decisions = result.proposals.map((p) => p.decision)
|
|
expect(decisions).toContain('propose')
|
|
expect(decisions).toContain('below_threshold')
|
|
})
|
|
|
|
it('truncates when more transactions match than max_transactions', async () => {
|
|
// Return 3 transactions when max_transactions=2 → truncated should be true.
|
|
// The tool fetches max_transactions+1 to detect truncation.
|
|
const txs = [
|
|
{ id: 't1', date: '2026-03-01', amount: 100, currency: 'SEK', description: '', merchant_name: null, reference: null, journal_entry_id: null, invoice_id: null },
|
|
{ id: 't2', date: '2026-03-02', amount: 100, currency: 'SEK', description: '', merchant_name: null, reference: null, journal_entry_id: null, invoice_id: null },
|
|
{ id: 't3', date: '2026-03-03', amount: 100, currency: 'SEK', description: '', merchant_name: null, reference: null, journal_entry_id: null, invoice_id: null },
|
|
]
|
|
const supabase = makeTxMock(txs)
|
|
vi.mocked(findMatchingInvoices).mockResolvedValue([])
|
|
|
|
const tool = tools.find((t) => t.name === 'gnubok_auto_match_period')!
|
|
const result = (await tool.execute(
|
|
{
|
|
date_from: '2026-03-01',
|
|
date_to: '2026-03-31',
|
|
max_transactions: 2,
|
|
dry_run: true,
|
|
},
|
|
'company-1',
|
|
'user-1',
|
|
supabase,
|
|
)) as { truncated: boolean; scanned_transactions: number }
|
|
|
|
expect(result.truncated).toBe(true)
|
|
expect(result.scanned_transactions).toBe(2)
|
|
})
|
|
})
|