415 lines
9.9 KiB
Markdown
415 lines
9.9 KiB
Markdown
# Trade Finance Backlog
|
|
|
|
This backlog tracks the next development phases for the `trade_finance`
|
|
module.
|
|
|
|
Status values:
|
|
|
|
```text
|
|
todo | in-progress | blocked | done
|
|
```
|
|
|
|
Priority values:
|
|
|
|
```text
|
|
low | medium | high
|
|
```
|
|
|
|
## Phase 1 - Core Ledger Foundation
|
|
|
|
Goal: stabilize the Trade Finance file, presentation, and movement ledger.
|
|
|
|
### TF-001 - Validate core model installation
|
|
|
|
Status: todo
|
|
Area: test
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Install/update the module in a real Tryton database with dependencies.
|
|
- Confirm the new models, views, sequence, menus, and access rules load.
|
|
|
|
Implementation notes:
|
|
- Run the targeted module test suite in an environment with `python-sql` and
|
|
the full Tryton dependency stack.
|
|
- Fix any XML/view/model registration issue found during module activation.
|
|
|
|
Validation:
|
|
- `python -m unittest modules.trade_finance.tests.test_module`
|
|
- Manual module activation/update in a development database.
|
|
|
|
### TF-002 - Harden posted movement immutability
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Ensure posted presentations and posted movement lines cannot be edited or
|
|
deleted through direct writes, nested One2Many writes, or UI actions.
|
|
|
|
Implementation notes:
|
|
- Review `write`, `delete`, and nested child update behavior.
|
|
- Keep reversal movements as the only correction path for posted exposure.
|
|
|
|
Validation:
|
|
- Add tests for direct line write/delete after posting.
|
|
- Add tests for nested line modification through presentation write.
|
|
|
|
### TF-003 - Add robust exposure helper methods
|
|
|
|
Status: todo
|
|
Area: model
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Provide reusable helpers for exposure by facility limit and by Trade Finance
|
|
file.
|
|
|
|
Implementation notes:
|
|
- Keep ledger lines as the source of truth.
|
|
- Start with Python helpers; SQL/materialized reporting can come later.
|
|
- Include `as_of_date` support for historical exposure.
|
|
|
|
Validation:
|
|
- Tests for current exposure by limit.
|
|
- Tests for historical exposure before/after transfer movements.
|
|
|
|
### TF-004 - Improve limit eligibility validation
|
|
|
|
Status: todo
|
|
Area: model
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Validate selected `trade_finance.facility_limit` against bank, currency,
|
|
validity dates, financing type, and expected operational status.
|
|
|
|
Implementation notes:
|
|
- Reuse `trade_finance.facility_limit_op_status`.
|
|
- Do not create a separate `bank.limit` model.
|
|
- Consider whether root global limits should be selectable or whether only
|
|
leaf sub-limits should receive movements.
|
|
|
|
Validation:
|
|
- Tests for rejected bank mismatch.
|
|
- Tests for rejected currency mismatch.
|
|
- Tests for rejected financing type mismatch.
|
|
- Tests for rejected operational status mismatch once connected.
|
|
|
|
## Phase 2 - Basic UX and Operational Entry Points
|
|
|
|
Goal: make the core usable from operational documents.
|
|
|
|
### TF-005 - Add contextual Start Financing wizard
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Let users start a Trade Finance presentation from an operational document.
|
|
|
|
Implementation notes:
|
|
- Start with stock shipment and stock move because `stock` is already a module
|
|
dependency.
|
|
- Use `fields.Reference` on presentation origin.
|
|
- Pre-fill date, origin, stage, company, currency, and suggested quantity where
|
|
available.
|
|
|
|
Validation:
|
|
- Wizard test from `stock.shipment.in`.
|
|
- Manual UI check from shipment form.
|
|
|
|
### TF-006 - Add purchase contract entry points
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Start financing from purchase contract and purchase contract line when the
|
|
relevant purchase contract module is available.
|
|
|
|
Implementation notes:
|
|
- First identify the actual local model names and module dependency impact.
|
|
- Avoid adding a hard dependency until confirmed necessary.
|
|
- Prefer optional extension module logic if purchase contract is not part of
|
|
the base dependency graph.
|
|
|
|
Validation:
|
|
- Tests only if the dependency is activated in the module test environment.
|
|
|
|
### TF-007 - Add invoice financing entry point
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Start or continue financing from receivable/invoice stage.
|
|
|
|
Implementation notes:
|
|
- Confirm whether dependency on `account_invoice` is acceptable.
|
|
- Origin should point to `account.invoice`.
|
|
- Presentation type should default to invoice financing.
|
|
|
|
Validation:
|
|
- Test default origin and stage from invoice when dependency is enabled.
|
|
|
|
### TF-008 - Add central exposure summary in the UI
|
|
|
|
Status: todo
|
|
Area: view
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Show current exposure by facility limit on the Trade Finance file.
|
|
|
|
Implementation notes:
|
|
- Use a read-only derived view/model or function fields first.
|
|
- Do not store manual exposure balances.
|
|
|
|
Validation:
|
|
- Manual UI check with multiple posted movements.
|
|
- Tests for summary values if implemented as model logic.
|
|
|
|
## Phase 3 - Transfer and Lifecycle Workflow
|
|
|
|
Goal: support movement between financing stages and limits.
|
|
|
|
### TF-009 - Add transfer proposal helper
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Generate two movement lines for transfers between facility limits.
|
|
|
|
Implementation notes:
|
|
- Negative line on the source facility limit.
|
|
- Positive line on the target facility limit.
|
|
- Preserve different haircuts/rates on each line.
|
|
|
|
Validation:
|
|
- Test PREFI to IN_TRANSIT transfer with liquidity gain.
|
|
|
|
### TF-010 - Track liquidity gain/loss
|
|
|
|
Status: todo
|
|
Area: model
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Calculate liquidity gain/loss when moving collateral between limits with
|
|
different haircuts.
|
|
|
|
Implementation notes:
|
|
- Keep this derived from movement lines.
|
|
- Store applied haircut on each line for audit.
|
|
|
|
Validation:
|
|
- Test gain when target haircut is lower.
|
|
- Test loss when target haircut is higher.
|
|
|
|
### TF-011 - Add repayment/release presentation support
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Allow users to release financed exposure partially or fully.
|
|
|
|
Implementation notes:
|
|
- Repayment/release should create negative movement lines.
|
|
- Avoid editing original posted movements.
|
|
|
|
Validation:
|
|
- Test partial repayment.
|
|
- Test full repayment reduces exposure to zero.
|
|
|
|
## Phase 4 - Funding Cost Engine
|
|
|
|
Goal: calculate funding costs from chronological exposure movements.
|
|
|
|
### TF-012 - Build exposure period calculation
|
|
|
|
Status: todo
|
|
Area: model
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Convert dated movement lines into running exposure periods per facility
|
|
limit.
|
|
|
|
Implementation notes:
|
|
- Sort by movement date.
|
|
- Calculate running balance.
|
|
- Build intervals until the next movement date or an explicit end date.
|
|
|
|
Validation:
|
|
- Test one movement.
|
|
- Test multiple movements on different dates.
|
|
- Test same-day movements.
|
|
|
|
### TF-013 - Calculate interest/funding cost
|
|
|
|
Status: todo
|
|
Area: model
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Calculate funding cost using exposure, applied rate, days, and day-count
|
|
basis.
|
|
|
|
Implementation notes:
|
|
- Use values copied onto movement lines at posting time.
|
|
- Support `360`, `365`, `ACT/360`, and `ACT/365`.
|
|
|
|
Validation:
|
|
- Tests for 360 and 365 bases.
|
|
- Test changing facility cost after posting does not alter historical cost.
|
|
|
|
### TF-014 - Add funding cost report screen
|
|
|
|
Status: todo
|
|
Area: report
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Provide a user-facing report of funding cost by Trade Finance file and by
|
|
facility limit.
|
|
|
|
Implementation notes:
|
|
- Start with a Tryton model/report view.
|
|
- Add export later only if needed.
|
|
|
|
Validation:
|
|
- Manual report check.
|
|
- Tests for report backing model if applicable.
|
|
|
|
## Phase 5 - Reporting and Controls
|
|
|
|
Goal: make exposure auditable and operationally controllable.
|
|
|
|
### TF-015 - Add current exposure by facility limit report
|
|
|
|
Status: todo
|
|
Area: report
|
|
Priority: high
|
|
|
|
Goal:
|
|
- Show exposure grouped by `trade_finance.facility_limit`.
|
|
|
|
Implementation notes:
|
|
- Source data must be posted movement lines.
|
|
- Include quantity and signed financed amount.
|
|
|
|
Validation:
|
|
- Test aggregation across multiple Trade Finance files.
|
|
|
|
### TF-016 - Add historical exposure as-of report
|
|
|
|
Status: todo
|
|
Area: report
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Show exposure at a selected historical date.
|
|
|
|
Implementation notes:
|
|
- Filter movement lines where `movement_date <= as_of_date`.
|
|
- Group by facility limit and optionally by Trade Finance file.
|
|
|
|
Validation:
|
|
- Tests around before/after transfer dates.
|
|
|
|
### TF-017 - Add over-limit checks and alerts
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Detect when posted exposure exceeds facility limit amount.
|
|
|
|
Implementation notes:
|
|
- Decide whether to block posting or warn first.
|
|
- Consider parent/global limit and child sub-limit behavior.
|
|
|
|
Validation:
|
|
- Test over child limit.
|
|
- Test over global limit if hierarchical aggregation is implemented.
|
|
|
|
### TF-018 - Add expired limit controls
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Highlight or block new exposure on expired limits.
|
|
|
|
Implementation notes:
|
|
- Posting already checks movement date validity.
|
|
- Add UI filtering and operational alerts.
|
|
|
|
Validation:
|
|
- Manual UI domain check.
|
|
- Tests for posting behavior already covered by core validation.
|
|
|
|
## Phase 6 - Advanced Operational Integration
|
|
|
|
Goal: connect financing to the broader commodity workflow.
|
|
|
|
### TF-019 - Add sale matching support
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Continue financing lifecycle when goods are matched with sales.
|
|
|
|
Implementation notes:
|
|
- Identify the actual local matching model.
|
|
- Add it to origin selection only after confirming dependency/model names.
|
|
|
|
Validation:
|
|
- Scenario test once model dependency is clear.
|
|
|
|
### TF-020 - Add automatic stage suggestions
|
|
|
|
Status: todo
|
|
Area: workflow
|
|
Priority: medium
|
|
|
|
Goal:
|
|
- Suggest finance stage from origin document status.
|
|
|
|
Implementation notes:
|
|
- Keep suggestions editable.
|
|
- Implement stage inference per origin model.
|
|
|
|
Validation:
|
|
- Tests per supported origin type.
|
|
|
|
### TF-021 - Add derived snapshot table if performance requires it
|
|
|
|
Status: todo
|
|
Area: report
|
|
Priority: low
|
|
|
|
Goal:
|
|
- Improve reporting performance for large ledgers.
|
|
|
|
Implementation notes:
|
|
- Snapshot must be derived from ledger lines.
|
|
- Ledger remains the source of truth.
|
|
- Do not implement until performance data justifies it.
|
|
|
|
Validation:
|
|
- Reconciliation test comparing snapshot totals with ledger totals.
|