admin/accounting_report
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add Tradon development backlog workflow

Browse Source
This commit is contained in:
GiorgioCALLIGARO
2026-05-07 18:01:33 +02:00
parent 0be69bc92a
commit 9c791e394d
7 changed files with 577 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
AGENT.md
View File

@@ -26,6 +26,7 @@ When documents conflict, use this order of authority:
5. Catalog scope in `Docs/reporting_catalog.md`.
6. Conceptual background in `Docs/CTRM_ACCOUNTING_REPORTING_ARCHITECTURE.md`.
7. Source workbook `Docs/Trad On - Rapports Comptables et Financiers.xlsx`.
8. Incoming GAP analysis files in `Tradon/`, after they have been copied into the relevant assessment `source_documents/` folder.
If a conflict remains unclear, document it as an open question instead of silently choosing a business rule.
@@ -137,6 +138,26 @@ When asked to review existing specifications:
4. Identify duplicated or conflicting concepts.
5. Propose or apply focused corrections.
When asked to create or refresh a Tradon assessment:
1. Identify the incoming GAP analysis file in `Tradon/`.
2. Copy the relevant source file into `Assessments/Tradon/<REPORT_CODE>/source_documents/`.
3. Record the intake source and retained assessment copy in `source_material.md`.
4. Keep the target report specification in `Reports/` as the functional reference.
5. Capture exposure notes, gap mapping, open points and decisions in the assessment folder.
6. Do not rewrite the target report silently from the GAP analysis; explicit decisions are required.
7. Write new framing questions in the relevant document using `Q: `, optional `C: ` comments, optional `PROPOSITION: ` proposals and `R: ` user responses.
When asked to prepare development backlog items from gaps:
1. Start from the relevant `Assessments/Tradon/<REPORT_CODE>/gap_mapping.md`.
2. Link each backlog item to stable gap themes, open points and pending decisions.
3. Keep items atomic enough to be implemented and tested.
4. Include acceptance criteria and expected validation controls.
5. Mark items blocked when a business or mapping decision is still open.
6. Do not invent source tables, joins or implementation design beyond what the assessment evidence supports.
7. Prefer linking backlog dependencies to pending decisions (`PD`) rather than directly to open questions (`Q`) once a decision wrapper exists.
## Boundaries
The assistant should not:

155
Assessments/Tradon/GL_001/decisions.md
View File

@@ -2,6 +2,18 @@
This file records decisions taken after reviewing the GL-001 exposure to Tryton / Tradon.
## Development readiness rule
A development backlog item can move from `Blocked` to `Ready` only when all linked pending decisions are `Confirmed`.
A decision is `Confirmed` when it has:
- a selected option or explicit arbitration;
- a rationale;
- an impact statement;
- linked backlog items;
- a validation or review expectation.
## Decision log
| Date | ID | Decision | Rationale | Impact | Status |
@@ -18,3 +30,146 @@ This file records decisions taken after reviewing the GL-001 exposure to Tryton
| GL001-PD004 | Decide which source origin models feed `document_date`, `document_type` and supplier invoice references. | GL001-Q006, GL001-Q012 | Open |
| GL001-PD005 | Decide whether commodity fields `payable_qty` and `uom` are required in the first implementation. | GL001-Q007, GL001-Q013 | Open |
| GL001-PD006 | Decide whether GL-001 requires a new flat reporting dataset. | GL001-Q008 | Open |
| GL001-PD007 | Decide whether audit and source reference mappings are generic across accounting reports or specific to GL-001 first. | GL001-Q010 | Open |
## Decision details
### GL001-PD001 Document reference mapping
Status: Open
Linked open points: GL001-Q001, GL001-Q002, GL001-Q003
Impacted backlog items: DEV-GL001-004
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD
### GL001-PD002 Transaction-currency fallback
Status: Open
Linked open points: GL001-Q004
Impacted backlog items: DEV-GL001-002, DEV-GL001-006
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD
### GL001-PD003 GL sign convention transformation
Status: Open
Linked open points: GL001-Q005
Impacted backlog items: DEV-GL001-007
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD
### GL001-PD004 Source document metadata
Status: Open
Linked open points: GL001-Q006, GL001-Q012
Impacted backlog items: DEV-GL001-005
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD
### GL001-PD005 Commodity quantity fields
Status: Open
Linked open points: GL001-Q007, GL001-Q013
Impacted backlog items: DEV-GL001-010
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD
### GL001-PD006 Flat GL-001 dataset
Status: Open
Linked open points: GL001-Q008
Impacted backlog items: DEV-GL001-001, DEV-GL001-003, DEV-GL001-009
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD
### GL001-PD007 Shared audit and reference mapping scope
Status: Open
Linked open points: GL001-Q010
Impacted backlog items: DEV-GL001-008
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD

26
Assessments/Tradon/GL_001/open_points.md
View File

@@ -4,26 +4,26 @@
| ID | Question | Area | Status |
| --- | --- | --- | --- |
| GL001-Q001 | In Tryton / Tradon mapping, should `document_number` be `account.move.number`, `account.move.post_number`, invoice `number`, or a context-dependent value? | Document references | Open |
| GL001-Q002 | Should `journal_entry_number` be `move.number` and `document_number` be the business document number? | Document references | Open |
| GL001-Q003 | Is `voucher_number` distinct in Tradon, or should it remain blank? | Document references | Open |
| GL001-Q004 | Should `transaction_currency` default to company currency when `second_currency` is empty? | Currency | Open |
| GL001-Q005 | Should credit columns be exported as negative values to match the target GL, even though Tryton UI displays credit as positive? | Sign convention | Open |
| GL001-Q006 | Which origin models should feed `document_date` and `document_type` in the first implementation? | Source document metadata | Open |
| GL001-Q007 | Can `payable_qty` and `uom` be derived reliably from `account.move.line.lot`, fees or invoice line origin for all commodity postings? | Commodity fields | Open |
| GL001-Q001 | Q: In Tryton / Tradon mapping, should `document_number` be `account.move.number`, `account.move.post_number`, invoice `number`, or a context-dependent value? | Document references | Open |
| GL001-Q002 | Q: Should `journal_entry_number` be `move.number` and `document_number` be the business document number? | Document references | Open |
| GL001-Q003 | Q: Is `voucher_number` distinct in Tradon, or should it remain blank? | Document references | Open |
| GL001-Q004 | Q: Should `transaction_currency` default to company currency when `second_currency` is empty? | Currency | Open |
| GL001-Q005 | Q: Should credit columns be exported as negative values to match the target GL, even though Tryton UI displays credit as positive? | Sign convention | Open |
| GL001-Q006 | Q: Which origin models should feed `document_date` and `document_type` in the first implementation? | Source document metadata | Open |
| GL001-Q007 | Q: Can `payable_qty` and `uom` be derived reliably from `account.move.line.lot`, fees or invoice line origin for all commodity postings? | Commodity fields | Open |
## Implementation questions
| ID | Question | Area | Status |
| --- | --- | --- | --- |
| GL001-Q008 | Should GL-001 be implemented as a new flat reporting dataset rather than extending the standard Tryton General Ledger views? | Dataset design | Open |
| GL001-Q009 | Should transaction-currency opening and closing balances be calculated in the reporting layer or stored in an intermediate model? | Currency balances | Open |
| GL001-Q010 | Should document and source reference mappings be generic across all accounting reports or specific to GL-001 first? | Shared mappings | Open |
| GL001-Q008 | Q: Should GL-001 be implemented as a new flat reporting dataset rather than extending the standard Tryton General Ledger views? | Dataset design | Open |
| GL001-Q009 | Q: Should transaction-currency opening and closing balances be calculated in the reporting layer or stored in an intermediate model? | Currency balances | Open |
| GL001-Q010 | Q: Should document and source reference mappings be generic across all accounting reports or specific to GL-001 first? | Shared mappings | Open |
## Business arbitration points
| ID | Question | Area | Status |
| --- | --- | --- | --- |
| GL001-Q011 | Is multi-entity selection required, or is the current company context sufficient for the first GL-001 implementation? | Entity | Open |
| GL001-Q012 | Should AP-specific fields such as `supplier_invoice_number` be mandatory only when the source is an AP invoice? | Audit trail | Open |
| GL001-Q013 | Are `payable_qty` and `uom` mandatory for GL-001 launch, or can they remain low-priority commodity extensions? | Scope | Open |
| GL001-Q011 | Q: Is multi-entity selection required, or is the current company context sufficient for the first GL-001 implementation? | Entity | Open |
| GL001-Q012 | Q: Should AP-specific fields such as `supplier_invoice_number` be mandatory only when the source is an AP invoice? | Audit trail | Open |
| GL001-Q013 | Q: Are `payable_qty` and `uom` mandatory for GL-001 launch, or can they remain low-priority commodity extensions? | Scope | Open |

22
Assessments/Tradon/README.md
View File

@@ -54,6 +54,28 @@ The assessment process does not change after intake: use the copied repository s
| `decisions.md` | Decisions and arbitrations taken after review |
| `source_material.md` | Source documents, date, scope and traceability notes |
## Open question notation
Open questions must be written in the relevant assessment document, except when the user explicitly asks to handle them elsewhere.
Use these prefixes:
| Prefix | Meaning |
| --- | --- |
| `Q: ` | Open question requiring user, business or technical arbitration |
| `C: ` | Comment that clarifies the open question, context or constraint |
| `PROPOSITION: ` | Accounting-compatible proposal suggested for arbitration |
| `R: ` | User response or confirmed answer |
After a document review, any new framing question should be added to the document using the same notation, unless an explicit exception is requested.
Expected file usage:
- `open_points.md` is the register of open questions. It should contain the `Q: ` entries and, when useful, related `C: ` comments or `PROPOSITION: ` proposals.
- `decisions.md` is the register of answers and arbitrations. It should contain the user's `R: ` responses, the selected decision, rationale, impact and validation expectation.
- A question may remain `Open` in `open_points.md` until the linked decision in `decisions.md` is confirmed.
- When a decision is confirmed, update the linked backlog items according to the development readiness rule.
## Recommended statuses
| Status | Meaning |

321
DevelopmentBacklog/Tradon/GL_001_backlog.md Normal file
View File

@@ -0,0 +1,321 @@
# GL-001 Tradon Development Backlog
Disposable draft created from `Assessments/Tradon/GL_001/`.
This file is a working conversion layer between the documented GL-001 gaps and future development tickets. It is intentionally conservative: items remain `Blocked` where mapping, business or architecture decisions are still open.
## Traceability sources
| Type | Reference |
| --- | --- |
| Target report | `Reports/GL/GL_001_general_ledger.md` |
| Assessment | `Assessments/Tradon/GL_001/` |
| Gap mapping | `Assessments/Tradon/GL_001/gap_mapping.md` |
| Open points | `Assessments/Tradon/GL_001/open_points.md` |
| Decisions | `Assessments/Tradon/GL_001/decisions.md` |
| Retained source | `Assessments/Tradon/GL_001/source_documents/general_ledger_gap_analysis.md` |
## Summary
| ID | Priority | Status | Theme | Depends on |
| --- | --- | --- | --- | --- |
| DEV-GL001-001 | High | Blocked | Flat detailed GL dataset | GL001-PD006 |
| DEV-GL001-002 | High | Blocked | Transaction-currency grouping and balances | GL001-PD002, GL001-Q009 |
| DEV-GL001-003 | High | Blocked | Opening and closing rows | GL001-PD006, GL001-Q009 |
| DEV-GL001-004 | High | Blocked | Document and reference mapping | GL001-PD001 |
| DEV-GL001-005 | High | Blocked | Source document metadata | GL001-PD004 |
| DEV-GL001-006 | Medium | Blocked | Transaction-currency debit and credit split | GL001-PD002 |
| DEV-GL001-007 | Medium | Blocked | GL sign convention transformation | GL001-PD003 |
| DEV-GL001-008 | Medium | Blocked | Audit metadata columns | GL001-PD007 |
| DEV-GL001-009 | Medium | Blocked | CSV and XLSX export | DEV-GL001-001 |
| DEV-GL001-010 | Low | Blocked | Commodity quantity fields | GL001-PD005 |
## DEV-GL001-001 Flat detailed GL dataset
| Field | Value |
| --- | --- |
| Source gap | Build or expose a flat detailed GL dataset matching `GL-001`, not only account summary plus drill-down |
| Linked questions | GL001-Q008 |
| Linked decision | GL001-PD006 |
| Priority | High |
| Status | Blocked |
Development scope:
- Provide one export-ready GL-001 dataset that combines account context and detailed move lines.
- Include one row structure capable of representing opening rows, movement lines and closing rows.
- Support the target GL-001 ordering: account, transaction currency, posting date, document number.
Out of scope:
- Final source table or SQL design until GL001-PD006 is confirmed.
- Commodity-specific fields, handled by DEV-GL001-010.
Acceptance criteria:
- A consumer can retrieve all required GL-001 output columns from one logical dataset or service.
- Account summary and line drill-down no longer have to be manually combined outside the reporting layer.
- Dataset rows can be typed as opening, movement or closing without ambiguous interpretation.
Validation:
- Compare base-currency movement totals with existing Tryton general ledger totals for the same period and account selection.
## DEV-GL001-002 Transaction-currency grouping and balances
| Field | Value |
| --- | --- |
| Source gap | Add transaction-currency grouping, filtering and running balances |
| Linked questions | GL001-Q004, GL001-Q009 |
| Linked decisions | GL001-PD002 |
| Priority | High |
| Status | Blocked |
Development scope:
- Add transaction currency as a grouping key for GL-001.
- Add transaction-currency filtering where supported by the selected implementation design.
- Calculate or expose `balance_transaction_currency`.
Out of scope:
- Deciding whether empty `second_currency` means company currency; this is GL001-PD002.
Acceptance criteria:
- GL-001 can be grouped by account and transaction currency.
- Running transaction-currency balances are available for movement rows.
- Base-currency lines have a documented transaction-currency fallback or exclusion rule.
Validation:
- For each account and transaction currency, opening plus movements equals closing once DEV-GL001-003 is available.
## DEV-GL001-003 Opening and closing rows
| Field | Value |
| --- | --- |
| Source gap | Add opening and closing rows by account and transaction currency |
| Linked questions | GL001-Q009 |
| Linked decisions | GL001-PD006 |
| Priority | High |
| Status | Blocked |
Development scope:
- Add explicit opening balance rows by account and transaction currency.
- Add explicit closing balance rows by account and transaction currency.
- Ensure movement rows sit between opening and closing rows in the exported ordering.
Out of scope:
- Storage versus reporting-layer calculation decision for transaction-currency opening balances.
Acceptance criteria:
- Each account and transaction-currency group has an opening row when relevant.
- Each account and transaction-currency group has a closing row when relevant.
- Opening, movement and closing row types are machine-readable in the dataset or export.
Validation:
- Opening balance plus period movements reconciles to closing balance for each account and transaction currency.
## DEV-GL001-004 Document and reference mapping
| Field | Value |
| --- | --- |
| Source gap | Define mapping for `document_number`, `journal_entry_number`, `voucher_number` and `reference` |
| Linked questions | GL001-Q001, GL001-Q002, GL001-Q003 |
| Linked decision | GL001-PD001 |
| Priority | High |
| Status | Blocked |
Development scope:
- Implement confirmed mappings for the GL-001 document and reference fields.
- Preserve enough information to trace each line back to the accounting document and source document.
Out of scope:
- Choosing the final business meaning of each reference field.
Acceptance criteria:
- `document_number`, `journal_entry_number`, `voucher_number` and `reference` follow the confirmed decision.
- Fields are populated consistently for accounting moves and AP-originated entries.
- Empty optional values are intentionally blank, not silently overloaded.
Validation:
- Sample accounting entries can be traced from GL-001 output back to the accounting move and, where available, source invoice.
## DEV-GL001-005 Source document metadata
| Field | Value |
| --- | --- |
| Source gap | Normalize source document metadata: document type, document date and supplier invoice number |
| Linked questions | GL001-Q006, GL001-Q012 |
| Linked decision | GL001-PD004 |
| Priority | High |
| Status | Blocked |
Development scope:
- Populate `document_type`, `document_date` and `supplier_invoice_number` according to confirmed origin-model rules.
- Support AP-related entries where supplier invoice information is available.
Out of scope:
- Commodity quantity mapping, handled by DEV-GL001-010.
Acceptance criteria:
- GL-001 exposes normalized source document metadata for confirmed origin models.
- AP-related entries include `supplier_invoice_number` when available.
- Non-AP entries follow a documented fallback or blank rule.
Validation:
- Review a sample containing AP invoices, manual journal entries and other available origin types.
## DEV-GL001-006 Transaction-currency debit and credit split
| Field | Value |
| --- | --- |
| Source gap | Split `amount_second_currency` into debit and credit transaction-currency columns |
| Linked questions | GL001-Q004 |
| Linked decision | GL001-PD002 |
| Priority | Medium |
| Status | Blocked |
Development scope:
- Derive `debit_transaction_currency` and `credit_transaction_currency` from signed transaction-currency amounts.
- Apply the same transaction-currency fallback rule used by DEV-GL001-002.
Out of scope:
- GL credit sign convention, handled by DEV-GL001-007.
Acceptance criteria:
- Debit and credit transaction-currency columns are populated deterministically.
- Zero, blank and base-currency-only cases follow documented rules.
Validation:
- Transaction-currency debit and credit totals reconcile to movement totals by account and currency.
## DEV-GL001-007 GL sign convention transformation
| Field | Value |
| --- | --- |
| Source gap | Decide and implement GL sign convention transformation for credit columns |
| Linked questions | GL001-Q005 |
| Linked decision | GL001-PD003 |
| Priority | Medium |
| Status | Blocked |
Development scope:
- Apply the confirmed GL-001 display convention for debit, credit and balances.
- Ensure base-currency and transaction-currency amounts use consistent signs.
Out of scope:
- Changing Tryton accounting storage or standard UI conventions.
Acceptance criteria:
- `debit_*` amounts are positive.
- `credit_*` amounts follow the confirmed GL-001 convention.
- Running balances are consistent with the exported debit and credit signs.
Validation:
- Sample entries reconcile between source Tryton amounts and GL-001 export amounts after documented transformation.
## DEV-GL001-008 Audit metadata columns
| Field | Value |
| --- | --- |
| Source gap | Add audit columns `entered_by`, `entered_date`, `modified_by` and `modified_date` |
| Linked questions | GL001-Q010 |
| Linked decision | GL001-PD007 |
| Priority | Medium |
| Status | Blocked |
Development scope:
- Expose creation and modification metadata for GL-001 rows where available.
- Use consistent user and timestamp formatting across the report.
Out of scope:
- Defining shared audit mappings for all accounting reports unless GL001-Q010 is resolved that way.
Acceptance criteria:
- GL-001 includes `entered_by`, `entered_date`, `modified_by` and `modified_date`.
- Missing metadata is handled consistently and visibly.
Validation:
- Compare exported values against source record creation and modification metadata for a sample of move lines.
## DEV-GL001-009 CSV and XLSX export
| Field | Value |
| --- | --- |
| Source gap | Add dedicated CSV / XLSX export target |
| Linked dependency | DEV-GL001-001 |
| Priority | Medium |
| Status | Blocked |
Development scope:
- Provide CSV and XLSX exports for the GL-001 flat dataset.
- Preserve column order from `Reports/GL/GL_001_general_ledger.md`.
Out of scope:
- Wide PDF export unless separately prioritized.
Acceptance criteria:
- CSV export includes all required GL-001 columns.
- XLSX export includes all required GL-001 columns.
- Column names match the report specification.
Validation:
- Exported row counts and totals match the underlying GL-001 dataset for the same parameters.
## DEV-GL001-010 Commodity quantity fields
| Field | Value |
| --- | --- |
| Source gap | Add `payable_qty` and `uom` for commodity-related postings using Tradon lot, invoice or fee links |
| Linked questions | GL001-Q007, GL001-Q013 |
| Linked decision | GL001-PD005 |
| Priority | Low |
| Status | Blocked |
Development scope:
- Populate `payable_qty` and `uom` for commodity-related postings if retained for first implementation.
- Document blank behavior for non-commodity postings.
Out of scope:
- Making commodity fields mandatory for all GL-001 rows.
Acceptance criteria:
- Commodity-related GL rows expose payable quantity and unit of measure when source data is reliably available.
- Non-commodity rows remain blank or follow a documented rule.
Validation:
- Review a sample of commodity AP postings against source invoice, lot or fee evidence.

38
DevelopmentBacklog/Tradon/README.md Normal file
View File

@@ -0,0 +1,38 @@
# Tradon Development Backlog
This folder converts assessed Tradon gaps into development backlog items.
The backlog is downstream from:
1. target report specifications in `Reports/`;
2. incoming GAP analysis files retained in `Assessments/Tradon/<REPORT_CODE>/source_documents/`;
3. structured assessment files in `Assessments/Tradon/<REPORT_CODE>/`.
Backlog items should be precise enough to drive development, but they should not invent source tables, SQL joins or implementation architecture before the relevant decisions are confirmed.
## Item lifecycle
| Status | Meaning |
| --- | --- |
| `Draft` | Candidate item derived from an assessment gap |
| `Blocked` | Requires a pending business, mapping or architecture decision |
| `Ready` | Scope and acceptance criteria are clear enough for development |
| `In Progress` | Development work has started |
| `Ready for Review` | Implementation is available for functional or technical review |
| `Done` | Implemented, tested and accepted |
| `Deferred` | Valid gap, not retained for the current delivery scope |
## Required fields
Each item should include:
- backlog ID;
- source report;
- source gap or assessment reference;
- linked open point or decision;
- development scope;
- out of scope;
- acceptance criteria;
- validation or reconciliation checks;
- priority;
- status.

7
README.md
View File

@@ -22,6 +22,9 @@ L'objectif du dossier est de maintenir un referentiel clair des rapports a produ
| `-- Tradon/
| |-- README.md
| `-- GL_001/
|-- DevelopmentBacklog/
| `-- Tradon/
| `-- GL_001_backlog.md
|-- Reports/
| |-- GL/
| |-- STATUTORY/
@@ -32,6 +35,8 @@ L'objectif du dossier est de maintenir un referentiel clair des rapports a produ
| |-- TRADING/
| |-- ANALYTICS/
| `-- REPORTS_INDEX.md
|-- Tradon/
| `-- general_ledger_gap_analysis.md
|-- security.toml
`-- Open Squared Reporting.code-workspace
```
@@ -46,7 +51,9 @@ L'objectif du dossier est de maintenir un referentiel clair des rapports a produ
- `Docs/reporting_parameters.md` centralise les parametres communs.
- `Docs/reporting_standards.md` fixe les conventions de champs, montants, signes et tris.
- `Docs/Trad On - Rapports Comptables et Financiers.xlsx` est la source initiale de cadrage fonctionnel.
- `Tradon/` recoit les GAP analysis initiales par rapport, potentiellement poussees par un autre utilisateur Git.
- `Assessments/Tradon/` documente l'exposition des rapports cibles aux capacites Tryton / Tradon, les GAP, questions ouvertes et decisions.
- `DevelopmentBacklog/Tradon/` transforme les gaps cadres en items de developpement tracables, testables et priorisables.
## Rapports specifies