Initial import: 10 Radix skills across 3 categories

Kategoriserer danske regnskabs-/ERP-skills, ERP-data-afstemnings- skill og to devops-workflows (gitea-issue-agent, kanban-workflows) som Radix-medlemmers AI-agenter kan dele. Struktur: skills/<kategori>/<skill-navn>/SKILL.md skills/<kategori>/<skill-navn>/{references,templates,scripts}/ Indekseret af index.json (genereret af scripts/rebuild_index.py). Kør `python3 scripts/rebuild_index.py --check` i CI for at fange synkroniseringsfejl.
2026-06-15 14:41:04 +02:00
commit 236053cd7f
30 changed files with 4460 additions and 0 deletions
@@ -0,0 +1,109 @@
+# Coop fakturaliste + Uniconta betalingsfordeling workflow
+
+Session-derived pattern from the Coop-Uniconta project: simplify reconciliation by using three forward-looking sources instead of many historical exports.
+
+## Target workflow
+
+Use these files as the primary operational import set:
+1. Coop invoice list (`Coop Fakturaer YYYY.xlsx`) — all invoices/credits issued to Coop.
+2. Uniconta payment allocation / debtor ledger (`Coop Debitor YYYY.xlsx`) — invoice and settlement/payment lines.
+3. Coop `Payment_advice` — later bridge source for explicit settlement detail.
+
+This supports the user question: “Mangler Coop at betale nogle fakturaer?”
+
+## Models / concepts
+
+Recommended separate models, not generic postings only:
+
+### `CoopInvoice`
+- source file, fiscal year/accounting year
+- date
+- account number/name
+- customer reference (`Deres ref`)
+- order number
+- invoice number
+- requisition
+- total, net, VAT amounts
+- payment terms / sent dates if present
+- raw row JSON + sheet/row reference
+
+### `PaymentAllocationLine`
+- source file, fiscal/accounting year
+- date
+- account
+- invoice number
+- voucher/document number
+- posting number
+- text
+- debit, credit, VAT
+- physical voucher/origin/account type/debtor-creditor/name
+- `is_payment_line` boolean
+- raw row JSON + sheet/row reference
+
+## Payment-line detection
+
+In Uniconta debtor/payment allocation files, not every line is a payment. They may contain both original invoice postings and later settlement lines.
+
+Observed signals for payment/settlement lines:
+- `Bilag != Faktura`
+- text contains `Coop  0010014808`
+- text contains `Omp. Coop`
+
+Do not infer paid status from invoice existence alone; calculate it from settlement/payment lines linked by invoice number.
+
+## Invoice payment status algorithm
+
+For each `CoopInvoice.invoice_number`:
+1. Find `PaymentAllocationLine` rows with same invoice number.
+2. Sum payment/settlement effect from rows marked `is_payment_line`.
+3. Compare against `CoopInvoice.total_amount`.
+4. Emit status:
+   - `paid`: residual within tolerance
+   - `partial`: some payment but residual remains
+   - `open`: no settlement/payment lines found
+5. Keep explanatory fields: payment vouchers, dates, amount paid, residual, source rows.
+
+Use Danish accounting display, but ISO dates and Decimal internally.
+
+## Bank reconciliation with allocation groups
+
+Use the payment allocation as an explanation layer between bank deposits and invoices:
+
+`Bank payment → allocation group/voucher → multiple invoice lines → Coop invoices`
+
+This is especially useful when one bank deposit equals many invoices/credits. Build groups by voucher/payment text/date and compare the group total to the bank payment.
+
+## Employee expense exception
+
+Negative bank postings whose text indicates purchases at Coop/Kvickly may be employee expenses, not Coop customer payments. Treat them as ignored/out-of-scope only when the user confirms the business meaning. In the Coop-Uniconta project, two negative bank lines with Coop/Kvickly text were confirmed as employee outlays and excluded from relevant bank coverage.
+
+Implementation pattern:
+- keep ignored bank payments visible in reports
+- do not count them as unmatched customer-payment differences
+- report both total bank count and relevant bank coverage percentage
+
+## UI/reporting shape
+
+Add a dedicated invoice-payment view or dashboard section:
+- paid invoices
+- open/different invoices
+- total invoices
+- open residual amount
+- status badges: `BETALT`, `ÅBEN`, `DIFFERENCE`, `FAKTURAER`
+- filters for year, customer/account, amount, residual, status
+- export of open/difference invoices to Excel/CSV
+
+## Minimum tests
+
+Add tests for:
+1. A Coop invoice is marked paid via matching Uniconta payment allocation lines.
+2. Partial/open invoices calculate residual correctly.
+3. Confirmed Coop/Kvickly employee expense bank lines are ignored but still reported.
+4. Relevant bank coverage is 100% when all customer-payment bank lines are explained and only confirmed out-of-scope lines remain.
+
+## Pitfalls
+
+- Do not hardcode confidential file paths or sample data into committed code.
+- Keep raw Excel/source folders gitignored.
+- Do not collapse invoice list, payment allocation, and payment advice into one generic parser; their semantics differ.
+- Payment advice parser can be added later, but wire the import type early so UI/workflow is ready.