dennis
236053cd7f
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.
110 lines
4.3 KiB
Markdown
110 lines
4.3 KiB
Markdown
# 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.
|