# 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.