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

Consolidate GL-001 TradOn assessment decisions

Browse Source
This commit is contained in:
GiorgioCALLIGARO
2026-05-08 12:31:28 +02:00
parent 4ce9711c3f
commit c344be9dff
13 changed files with 918 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files

696
Assessments/Tradon/GL_001/decision_register.md Normal file
View File

@@ -0,0 +1,696 @@
# GL-001 Decision Register
This file is the single source of truth for GL-001 questions, decisions and development readiness.
Previous separate open-point and decision files have been replaced by this register. New answers and arbitrations should be recorded here.
## Readiness Rule
A development backlog item can move from `Blocked` to `Ready` only when all linked questions are `Confirmed` or explicitly marked `Not blocking`.
A question is `Confirmed` when it has:
- a selected answer or explicit arbitration;
- a rationale;
- an impact statement;
- linked backlog items;
- a validation or review expectation.
## Quick Answer Board
| ID | Topic | Question | Recommended answer | Blocks | Status |
| --- | --- | --- | --- | --- | --- |
| GL001-Q001 | Document references | Should `document_number` be `account.move.number`, `account.move.post_number`, invoice `number`, or context-dependent? | Use a context-dependent mapping and document it by origin. | DEV-GL001-004 | Open |
| GL001-Q002 | Document references | Should `journal_entry_number` be `move.number` and `document_number` be the business document number? | Likely yes, if TradOn exposes both internal journal entry and business document identifiers. | DEV-GL001-004 | Open |
| GL001-Q003 | Document references | Is `voucher_number` distinct in TradOn, or should it remain blank? | Keep blank unless a distinct voucher/workflow reference exists. | DEV-GL001-004 | Open |
| GL001-Q004 | Currency | Should `transaction_currency` default to company currency when `second_currency` is empty? | Yes, use company currency for base-currency lines. | DEV-GL001-002, DEV-GL001-006 | Closed |
| GL001-Q005 | Sign convention | Should credit columns be exported as positive values following Tryton? | Yes, export credits as positive values and calculate ending balances as initial plus debit minus credit. | DEV-GL001-007 | Closed |
| GL001-Q006 | Source document metadata | Which origin models feed `document_date` and `document_type` first? | Start with AP invoice origins, then manual journal fallback. | DEV-GL001-005 | Open |
| GL001-Q007 | Commodity fields | Can `payable_qty` and `uom` be derived reliably for all commodity postings? | Treat as optional until source reliability is proven. | DEV-GL001-010 | Open |
| GL001-Q008 | Dataset design | Should GL-001 use a new flat reporting dataset? | Yes, expose one export-ready dataset and use AG Grid integrated into TradOn for presentation, subject to final tool confirmation. | DEV-GL001-001, DEV-GL001-003, DEV-GL001-009 | Open |
| GL001-Q009 | Currency balances | Should transaction-currency initial and ending balances be calculated in the reporting layer or stored in an intermediate model? | Calculate in the reporting layer first, unless performance requires persistence. | DEV-GL001-002, DEV-GL001-003 | Open |
| GL001-Q010 | Shared mappings | Should document and source reference mappings be generic across accounting reports or specific to GL-001 first? | Define GL-001 first, then promote stable rules to shared standards. | DEV-GL001-008 | Closed |
| GL001-Q011 | Entity | Is multi-entity selection required for first implementation? | Use current company context first. | Not blocking | Closed |
| GL001-Q012 | Audit trail | Should AP-specific fields be mandatory only for AP invoice sources? | Yes, mandatory when source is AP invoice, blank otherwise. | DEV-GL001-005 | Closed |
| GL001-Q013 | Scope | Are `payable_qty` and `uom` mandatory for launch? | No, keep them as low-priority commodity extensions unless required by users. | DEV-GL001-010 | Open |
| GL001-Q014 | FX rate | Which source, rate date, convention and precision should be used for `currency_rate`? | Use the stored accounting move line rate, reversed when the stored convention is inverse to the report display. | DEV-GL001-011 | Closed |
| GL001-Q015 | Field naming | Should `Currency_Rate` keep capitalization or become `currency_rate`? | Rename to `currency_rate` to match the wider field naming convention. | DEV-GL001-011 | Closed |
| GL001-Q016 | Account classification | Which ERP classification drives balance sheet versus P&L initial balance logic? | Use ERP account type / financial statement classification. | DEV-GL001-003 | Closed |
| GL001-Q017 | Balance presentation | Should `initial_balance_*` repeat the balance before `date_from` on every transaction line, or should a rolling line-opening balance be required later? | Use rolling line balances: initial balance before the line and ending balance after the line. | DEV-GL001-003 | Closed |
| GL001-Q018 | Currency filter | Should the `currency` filter apply to transaction currency, base currency, or both? | Filter by transaction currency only. | DEV-GL001-002 | Closed |
| GL001-Q019 | Reference search | Which reference fields should the document or voucher number filter search? | Search `document_number`, `voucher_number`, `journal_entry_number`, `reference` and `supplier_invoice_number` if available. | DEV-GL001-004 | Open |
| GL001-Q020 | PDF export scope | Should PDF include every detail column, or should full detail be limited to CSV/XLSX? | PDF is out of scope for the first implementation. | DEV-GL001-009 | Closed |
## Confirmed Decisions
| Date | ID | Decision | Rationale | Impact | Status |
| --- | --- | --- | --- | --- | --- |
| 2026-05-07 | GL001-D001 | Create a dedicated assessment folder for the GL-001 exposure to Tryton / TradOn. | The gap analysis contains exposure notes, mappings, open points and priorities that should not be mixed into the target report specification. | `Reports/GL/GL_001_general_ledger.md` remains the target specification; assessment material lives under `Assessments/Tradon/GL_001/`. | Confirmed |
| 2026-05-08 | GL001-D002 | Replace GL-001 running balance output columns with initial and ending balance columns per transaction line. | The report must show, for each account and transaction currency, the starting balance before `date_from` and the line ending balance after applying the movement. | `balance_transaction_currency` and `balance_base_currency` are replaced by `initial_balance_*` and `ending_balance_*` fields in the GL-001 output structure. | Confirmed |
## Decision Details
### GL001-Q001 Document number mapping
Status: Open
Area: Document references
Blocks: DEV-GL001-004
Question:
In Tryton / TradOn mapping, should `document_number` be `account.move.number`, `account.move.post_number`, invoice `number`, or a context-dependent value?
Recommended answer:
Use a context-dependent mapping and document it by origin.
Options:
- Use `account.move.number` for all rows.
- Use `account.move.post_number` for all posted rows.
- Use invoice or source document number when the origin is an invoice.
- Use a context-dependent mapping by origin model.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Review manual journal, AP invoice and any available source-origin examples.
### GL001-Q002 Journal entry versus document number
Status: Open
Area: Document references
Blocks: DEV-GL001-004
Question:
Should `journal_entry_number` be `move.number` and `document_number` be the business document number?
Recommended answer:
Likely yes, if TradOn exposes both internal journal entry and business document identifiers.
Options:
- Use `move.number` as `journal_entry_number` and source business number as `document_number`.
- Use `move.post_number` as `journal_entry_number`.
- Use the same value in both fields only when no distinct source exists.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Compare exported references against accounting move and source document screens.
### GL001-Q003 Voucher number usage
Status: Open
Area: Document references
Blocks: DEV-GL001-004
Question:
Is `voucher_number` distinct in TradOn, or should it remain blank?
Recommended answer:
Keep blank unless a distinct voucher or workflow reference exists.
Options:
- Map a distinct voucher/workflow reference.
- Leave blank.
- Reuse another reference only if business users explicitly confirm the meaning.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Confirm against a sample of posted accounting entries and user terminology.
### GL001-Q004 Transaction-currency fallback
Status: Closed
Area: Currency
Blocks: DEV-GL001-002, DEV-GL001-006
Question:
Should `transaction_currency` default to company currency when `second_currency` is empty?
Recommended answer:
Yes, use company currency for base-currency lines, with a documented blank-source rule.
Options:
- Default to company currency.
- Leave transaction currency blank when `second_currency` is empty.
- Exclude base-currency-only rows from transaction-currency grouping.
Decision:
Default to company currency when `second_currency` is empty.
Rationale:
This keeps base-currency accounting lines in an explicit currency group instead of a blank group.
Impact:
`transaction_currency` is always populated in GL-001 output rows.
Validation:
Test base-currency-only rows and foreign-currency rows in the same account.
### GL001-Q005 Credit sign convention
Status: Closed
Area: Sign convention
Blocks: DEV-GL001-007
Question:
Should credit columns be exported as positive values following the current Tryton convention?
Recommended answer:
Yes, export credit columns as positive values following the current Tryton convention.
Options:
- Export credits as positive values.
- Export credits as negative values.
- Add separate sign-normalized movement fields.
Decision:
Export credits as positive values following the current Tryton convention.
Rationale:
This avoids unnecessary sign transformation in the report layer.
Impact:
Ending balance formula is `initial_balance + debit - credit`.
Validation:
Debit, credit, initial balance and ending balance signs must reconcile under the selected convention.
### GL001-Q006 Source document metadata
Status: Open
Area: Source document metadata
Blocks: DEV-GL001-005
Question:
Which origin models should feed `document_date` and `document_type` in the first implementation?
Recommended answer:
Start with AP invoice origins, then manual journal fallback.
Options:
- AP invoice origins only for first implementation.
- AP invoice plus AR/customer invoice origins.
- All known source origins with a fallback to accounting move date/type.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Review sample rows by origin type and confirm blank/fallback behavior.
### GL001-Q007 Commodity quantity derivation
Status: Open
Area: Commodity fields
Blocks: DEV-GL001-010
Question:
Can `payable_qty` and `uom` be derived reliably from `account.move.line.lot`, fees or invoice line origin for all commodity postings?
Recommended answer:
Treat as optional until source reliability is proven.
Options:
- Include for all commodity postings.
- Include only when directly traceable.
- Defer from first implementation.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Review commodity AP postings against source invoice, lot or fee evidence.
### GL001-Q008 Flat GL-001 dataset
Status: Open
Area: Dataset design
Blocks: DEV-GL001-001, DEV-GL001-003, DEV-GL001-009
Question:
Should GL-001 be implemented as a new flat reporting dataset rather than extending the standard Tryton / TradOn General Ledger views?
Recommended answer:
Yes, expose one export-ready dataset and use AG Grid integrated into TradOn for presentation, subject to final tool confirmation.
Options:
- New flat reporting dataset.
- Extend standard Tryton / TradOn General Ledger views.
- Hybrid: backend dataset plus AG Grid integrated into TradOn for interactive presentation.
Decision:
The open-source tool currently being selected for GL-001 presentation is AG Grid integrated into TradOn, with customization to allow interactive groupings, drilldowns, filtering and computed balance columns.
Rationale:
Using AG Grid inside TradOn should ease presentation, computation and usage of the GL while keeping the report execution inside the selected CTRM / ERP platform.
Impact:
Requires a GL-001 flat dataset and a TradOn-integrated grid presentation layer.
Validation:
- Memorise filters, multi-grouping.
- Allow drill downs on source entries.
- Allow showing subtotals and totals for grouped lines.
- Allow computing initial and ending balances in columns.
### GL001-Q009 Balance calculation layer
Status: Open
Area: Currency balances
Blocks: DEV-GL001-002, DEV-GL001-003
Question:
Should transaction-currency initial and ending balances be calculated in the reporting layer or stored in an intermediate model?
Recommended answer:
Calculate in the reporting layer first, unless performance requires persistence.
Options:
- Calculate in the reporting layer.
- Store in an intermediate reporting model.
- Precompute only for exported periods.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Initial balance plus period movements reconciles to ending balance for each account and transaction currency.
### GL001-Q010 Shared audit and reference mapping scope
Status: Closed
Area: Shared mappings
Blocks: DEV-GL001-008
Question:
Should document and source reference mappings be generic across all accounting reports or specific to GL-001 first?
Recommended answer:
Define GL-001 first, then promote stable rules to shared standards.
Options:
- GL-001-specific mapping first.
- Shared accounting-report mapping first.
- Shared mapping for stable fields only.
Decision:
Define GL-001 first, then promote stable rules to shared standards.
Rationale:
Simplification
Impact:
None
Validation:
Check whether GL-001 mappings can be reused by GL-002, AR and AP reports without changing their meaning.
### GL001-Q011 Multi-entity scope
Status: Closed
Area: Entity
Blocks: Not blocking
Question:
Is multi-entity selection required, or is the current company context sufficient for the first GL-001 implementation?
Recommended answer:
Use current company context first unless multi-entity reporting is confirmed.
Options:
- Current company context only.
- Explicit entity selector.
- Multi-entity consolidation scope.
Decision:
Use current company context first
Rationale:
Multi-entity reporting is not in the scope
Impact:
None
Validation:
Confirm target users and expected legal-entity scope.
### GL001-Q012 AP-specific fields
Status: Closed
Area: Audit trail
Blocks: DEV-GL001-005
Question:
Should AP-specific fields such as `supplier_invoice_number` be mandatory only when the source is an AP invoice?
Recommended answer:
Yes, mandatory when source is AP invoice, blank otherwise.
Options:
- Mandatory for AP invoice origins only.
- Always required.
- Optional for all rows.
Decision:
Yes, mandatory when source is AP invoice, blank otherwise.
Rationale:
Transactions may not be originated by AP movements
Impact:
None
Validation:
AP-origin rows expose supplier invoice number; non-AP rows follow a documented blank rule.
### GL001-Q013 Commodity field launch scope
Status: Open
Area: Scope
Blocks: DEV-GL001-010
Question:
Are `payable_qty` and `uom` mandatory for GL-001 launch, or can they remain low-priority commodity extensions?
Recommended answer:
No, keep them as low-priority commodity extensions unless required by users.
Options:
- Mandatory for launch.
- Optional when source data is reliable.
- Deferred from launch.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Confirm launch scope with commodity accounting users.
### GL001-Q014 Currency rate source and convention
Status: Closed
Area: FX rate
Blocks: DEV-GL001-011
Question:
Which source, rate date, direct/inverse convention and precision should be used for `currency_rate`?
Recommended answer:
Use the stored accounting move line rate, reversed when the stored convention is inverse to the report display.
Options:
- Stored accounting move line rate.
- Company currency rate effective on posting date.
- Derived rate from base and transaction amounts.
Decision:
Use the stored accounting move line rate. If the stored rate means `1 accounting currency = x transaction currency`, display that rate. If the stored rate means `x accounting currency = 1 transaction currency`, display the reverse stored rate.
Rationale:
Show the currency rate used to convert the transaction amount is the best practice
Impact:
None
Validation:
Foreign-currency transaction amounts, base amounts and `currency_rate` reconcile within agreed precision.
### GL001-Q015 Currency rate field naming
Status: Closed
Area: Field naming
Blocks: DEV-GL001-011
Question:
Should `Currency_Rate` keep its current report-specific capitalization or be harmonized to `currency_rate` with the wider field naming convention?
Recommended answer:
Rename to `currency_rate` to match the wider field naming convention.
Options:
- Keep `Currency_Rate`.
- Rename to `currency_rate`.
- Export both temporarily.
Decision:
Rename to `currency_rate` to match the wider field naming convention.
Rationale:
Harmonisation
Impact:
Ease the readiness of the specifications
Validation:
Column order and naming match the confirmed GL-001 output contract.
### GL001-Q016 Initial balance account classification
Status: Closed
Area: Account classification
Blocks: DEV-GL001-003
Question:
Which ERP account classification should drive the balance sheet versus profit and loss initial-balance rule?
Recommended answer:
Use ERP account type / financial statement classification.
Options:
- Use ERP account type or financial statement classification.
- Use account code ranges.
- Maintain a GL-001-specific mapping table.
Decision:
Use ERP account type or financial statement classification.
Rationale:
TradOn already manages such classification.
Impact:
None
Validation:
Test one balance sheet account and one profit and loss account around `date_from`.
### GL001-Q017 Initial balance repetition versus rolling line balance
Status: Closed
Area: Balance presentation
Blocks: DEV-GL001-003
Question:
Should the `initial_balance_*` fields repeat the balance before `date_from` on every transaction line, or should a separate rolling line-opening balance be required later?
Recommended answer:
Use rolling line balances: `initial_balance_*` is the balance immediately before the line and `ending_balance_*` is the balance immediately after the line.
Options:
- Use rolling line balances with `initial_balance_*` before the line and `ending_balance_*` after the line.
- Repeat the period initial balance on every transaction line.
- Add separate rolling line-opening and line-ending balance fields.
Decision:
Use rolling line balances: `initial_balance_*` shows the balance immediately before each transaction line and `ending_balance_*` shows the balance immediately after it.
Rationale:
This matches ledger review expectations and makes each transaction line explain the movement from opening position to closing position.
Impact:
The first line starts from the balance before `date_from`; each next line starts from the previous line's ending balance.
Validation:
Review a multi-line account and transaction-currency group to confirm that the displayed balances match user expectations.
### GL001-Q018 Currency filter meaning
Status: Closed
Area: Filters
Blocks: DEV-GL001-002
Question:
Should the `currency` filter mean transaction currency only, base currency only, or both depending on the selected field?
Recommended answer:
Use transaction currency as the default meaning; base currency is already implied by entity/company context.
Options:
- Filter by transaction currency only.
- Filter by base currency only.
- Provide separate filters for transaction currency and base currency.
Decision:
Filter by transaction currency only.
Rationale:
base currency is already implied by entity/company/context
Impact:
None
Validation:
Review a sample with company-currency and foreign-currency lines to confirm the filter behavior.
### GL001-Q019 Document and voucher filter search scope
Status: Open
Area: Filters
Blocks: DEV-GL001-004
Question:
Should the document or voucher number filter search only `document_number` and `voucher_number`, or also `journal_entry_number`, `reference` and `supplier_invoice_number`?
Recommended answer:
Search `document_number`, `voucher_number`, `journal_entry_number`, `reference` and `supplier_invoice_number` if available.
Options:
- Search only `document_number` and `voucher_number`.
- Search all accounting and source reference fields.
- Provide separate filters by reference type.
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation:
Test searches using accounting document number, journal entry number, voucher/reference and supplier invoice number.
### GL001-Q020 PDF export scope
Status: Closed
Area: Export
Blocks: DEV-GL001-009
Question:
Should the PDF export include every detail column even when the output is very wide, or should PDF be limited to a printable audit summary while CSV/XLSX remain the full-detail formats?
Recommended answer:
Keep CSV/XLSX as full-detail exports; use PDF full detail only if layout remains readable.
Options:
- PDF includes every detail column.
- PDF includes a printable audit summary only.
- Provide both full-detail and summary PDF variants.
Decision:
Consider PDF as out of scope in first implementation
Rationale:
Simplification
Impact:
None
Validation:
Reassess export needs only if PDF is prioritized after the first implementation.

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

@@ -1,196 +0,0 @@
# GL-001 Decisions
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 |
| --- | --- | --- | --- | --- | --- |
| 2026-05-07 | GL001-D001 | Create a dedicated assessment folder for the GL-001 exposure to Tryton / Tradon. | The GAP analysis contains exposure notes, mappings, open points and priorities that should not be mixed into the target report specification. | `Reports/GL/GL_001_general_ledger.md` remains the target specification; assessment material lives under `Assessments/Tradon/GL_001/`. | Confirmed |
## Pending decisions
| ID | Decision needed | Linked open point | Status |
| --- | --- | --- | --- |
| GL001-PD001 | Decide final mapping of `document_number`, `journal_entry_number`, `voucher_number` and `reference`. | GL001-Q001, GL001-Q002, GL001-Q003 | Open |
| GL001-PD002 | Decide transaction-currency fallback when `second_currency` is empty. | GL001-Q004 | Open |
| GL001-PD003 | Decide whether GL-001 exports transform credit amounts to negative values. | GL001-Q005 | Open |
| 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 |
| GL001-PD008 | Decide the `Currency_Rate` source, rate date, direct/inverse convention, precision and field naming convention. | GL001-Q014, GL001-Q015 | 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
### GL001-PD008 Currency rate mapping and naming
Status: Open
Linked open points: GL001-Q014, GL001-Q015
Impacted backlog items: DEV-GL001-002, DEV-GL001-011
Decision:
TBD
Rationale:
TBD
Impact:
TBD
Validation expectation:
TBD

24
Assessments/Tradon/GL_001/exposure_notes.md
View File

@@ -9,10 +9,10 @@ Tryton already provides a strong General Ledger foundation:
- journal filtering;
- posted-only option;
- drill-down from accounts to detailed move lines;
- running balance at line level;
- base-currency balance information at line level;
- party drill-down for party-required accounts.
The main gap is that the target `GL-001` report is specified as a complete detailed report, grouped by account and transaction currency, with explicit opening and closing rows and a rich audit column set.
The main gap is that the target `GL-001` report is specified as a complete detailed report, grouped by account and transaction currency, with initial and ending balance columns on each transaction line and a rich audit column set.
Tryton's current General Ledger is split between:
@@ -25,7 +25,7 @@ It does not expose the target output as one flat, export-ready detailed report.
The target `GL-001` specification is broader than the current Tryton standard General Ledger output.
Tryton covers the accounting foundation and several filters, but the target report requires an additional reporting layer that flattens account summary and detailed lines into a single exportable dataset, with transaction-currency grouping, opening and closing rows, audit metadata and normalized document references.
Tryton covers the accounting foundation and several filters, but the target report requires an additional reporting layer that flattens account summary and detailed lines into a single exportable dataset, with transaction-currency grouping, initial and ending balance columns, audit metadata and normalized document references.
## Areas already covered or substantially supported
@@ -47,9 +47,9 @@ Tryton covers the accounting foundation and several filters, but the target repo
| Flat detailed report | Not exposed as a single export-ready dataset |
| Account and transaction-currency grouping | Missing or partial |
| Transaction-currency filter | Missing as an explicit GL parameter |
| Opening and closing rows by account and transaction currency | Missing |
| Transaction-currency running balance | Missing |
| FX rate exposure for `Currency_Rate` | Source, rate date, direct/inverse convention and precision not yet mapped |
| Initial and ending balances by account and transaction currency | Missing |
| Transaction-currency ending balance per line | Missing |
| FX rate exposure for `currency_rate` | Rate date and precision not yet mapped |
| Rich audit columns | Raw ingredients exist, but not exposed in normalized GL output |
| Document, voucher and reference mapping | Requires functional arbitration |
| Dedicated XLSX export | Not identified |
@@ -60,12 +60,12 @@ Tryton covers the accounting foundation and several filters, but the target repo
The target `GL-001` convention is:
- debit amounts displayed as positive amounts;
- credit amounts displayed as negative amounts;
- running balances calculated using debit-positive and credit-negative logic.
- credit amounts displayed as positive amounts, following the current Tryton convention;
- ending balances calculated using debit-positive and credit-positive logic: initial balance plus debit minus credit.
Tryton currently exposes base debit and credit as positive numeric columns and computes balance as `debit - credit`. For transaction currency, Tryton stores a signed `amount_second_currency`.
The export layer must therefore decide whether to preserve Tryton's UI convention or transform credit columns to the target `GL-001` convention.
The export layer should preserve Tryton's positive debit and positive credit convention for GL-001.
## Export exposure
@@ -85,6 +85,8 @@ Tryton supports important base-currency controls:
- account start, debit, credit and end balances support reconciliation;
- Trial Balance reuses the same account model, helping base-currency reconciliation.
The main remaining control gap is transaction-currency reconciliation by account and currency, including opening, movement and closing balances.
The main remaining control gap is transaction-currency reconciliation by account and currency, including initial balance, movement and ending balance.
The new GL-001 `Currency_Rate` field also requires a conversion-control rule: for non-base-currency lines, exported transaction-currency amounts, base-currency amounts and the displayed FX rate should reconcile within the agreed rounding precision.
Initial balances must follow the account type: balance sheet accounts use the account balance up to the day before `date_from`, while profit and loss accounts use only the movement balance from the start of the fiscal year through the day before `date_from`.
The new GL-001 `currency_rate` field also requires a conversion-control rule: for non-base-currency lines, exported transaction-currency amounts, base-currency amounts and the displayed FX rate should reconcile within the agreed rounding precision.

51
Assessments/Tradon/GL_001/gap_mapping.md
View File

@@ -2,7 +2,7 @@
## Parameters
| Target parameter | Tryton / Tradon exposure | Gap | Priority | Status |
| Target parameter | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| `date_from` | Supported as `from_date` | None identified | Covered | Confirmed |
| `date_to` | Supported as `to_date` | None identified | Covered | Confirmed |
@@ -17,7 +17,7 @@
## Filters
| Target filter | Tryton / Tradon exposure | Gap | Priority | Status |
| Target filter | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| Posting date between `date_from` and `date_to` | Covered through `from_date` and `to_date`; period range is also supported | None identified | Covered | Confirmed |
| Account or account range | Account range is not visible as a standard context parameter | Partial support only | Medium | Open |
@@ -29,7 +29,7 @@
## Sorting
| Target sorting requirement | Tryton / Tradon exposure | Gap | Priority | Status |
| Target sorting requirement | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| Sort by account | Account summary sorts by account | Covered at account level | Covered | Confirmed |
| Sort by transaction currency | No primary transaction-currency sort identified | Missing | High | Open |
@@ -40,15 +40,15 @@
## Grouping and balance presentation
| Target requirement | Tryton / Tradon exposure | Gap | Priority | Status |
| Target requirement | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| Group by account | Account summary is account-driven | Covered at summary level | Covered | Confirmed |
| Group by transaction currency | `second_currency` exists on lines | No account/currency grouped presentation | High | Open |
| Opening balance rows | Account summary has `start_balance` | No explicit opening rows in detailed line report | High | Open |
| Movement lines | Line drill-down exists | Not exposed together with opening and closing rows in one flat report | High | Open |
| Closing balance rows | Account summary has `end_balance` | No explicit closing rows in detailed line report | High | Open |
| Running balance in base currency | Available through line balance logic | Covered in base currency | Covered | Confirmed |
| Running balance in transaction currency | `amount_second_currency` is a signed amount | Missing transaction-currency running balance | High | Open |
| Initial balance columns | Account summary has `start_balance` in base currency | No transaction-currency initial balance column on each detailed line | High | Open |
| Movement lines | Line drill-down exists | Not exposed together with initial and ending balance columns in one flat report | High | Open |
| Ending balance columns | Account summary has `end_balance` in base currency | No transaction-currency ending balance column on each detailed line | High | Open |
| Initial and ending balance in base currency | Available through account summary and line balance logic | Must be exposed as GL-001 `initial_balance_base_currency` and `ending_balance_base_currency` columns | Medium | Open |
| Initial and ending balance in transaction currency | `amount_second_currency` is a signed amount | Missing transaction-currency initial and ending balance calculation | High | Open |
| Debit / credit split in transaction currency | Tryton stores signed `amount_second_currency` | Missing explicit debit and credit transaction-currency columns | Medium | Open |
| FX rate between transaction and base currency | Currency conversion data may exist on accounting moves or lines depending on origin | Source, rate date, direct/inverse convention and precision not mapped | High | Open |
| Transaction-currency totals | Not explicit | Missing | High | Open |
@@ -57,7 +57,7 @@
### Covered or mostly mappable
| Target column | Tryton / Tradon source candidate | Gap | Status |
| Target column | Tryton / TradOn source candidate | Gap | Status |
| --- | --- | --- | --- |
| `entity` | `company` | User-facing mapping to confirm | Open |
| `account` | `account.account.code` via ledger account | None identified | Confirmed |
@@ -72,17 +72,18 @@
| `description` | line `description_used` / move description | Mapping to confirm | Open |
| `reference` | move `origin`, `ext_ref`, invoice reference depending mapping | Mapping question | Open |
| `debit_base_currency` | line `debit` | Sign convention transformation may be required | Open |
| `credit_base_currency` | line `credit` | Target expects negative credits | Open |
| `balance_base_currency` | line `balance` | None identified | Confirmed |
| `Currency_Rate` | likely accounting move line currency conversion rate, company currency rate or derived base / transaction amount ratio | Mapping, naming convention and rate direction to confirm | Open |
| `credit_base_currency` | line `credit` | None identified; GL-001 preserves Tryton positive credit convention | Confirmed |
| `initial_balance_base_currency` | account `start_balance` or equivalent balance before `date_from`, then previous line ending balance | Must roll by account and transaction currency | Open |
| `ending_balance_base_currency` | initial balance plus debit minus credit | Calculation and ordering to implement in GL-001 export | Open |
| `currency_rate` | stored accounting move line currency conversion rate, reversed when the stored convention is inverse to the report display | Rate date and precision to confirm | Open |
| `entered_date` | line or move `create_date` | Exposure in GL output required | Open |
| `modified_date` | line or move `write_date` | Exposure in GL output required | Open |
### Gaps or mapping questions
| Target column | Tryton / Tradon exposure | Gap | Priority | Status |
| Target column | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| `transaction_currency` | Tryton has `second_currency`; base-currency lines may have no transaction currency | Convention required: use `second_currency` else company currency? | High | Open |
| `transaction_currency` | Tryton has `second_currency`; base-currency lines may have no transaction currency | Use `second_currency` else company currency | Covered | Confirmed |
| `document_date` | Not exposed in current GL line view | Map from invoice date for invoice origins, move date otherwise? | High | Open |
| `document_type` | Not exposed | Needs mapping from origin model or journal/type | High | Open |
| `supplier_invoice_number` | Not exposed | Could map to supplier invoice reference for AP invoice origins | High | Open |
@@ -91,24 +92,25 @@
| `uom` | Not in standard GL | Requires custom commodity logic | Low | Open |
| `debit_transaction_currency` | Signed `amount_second_currency` exists | Missing explicit debit split | Medium | Open |
| `credit_transaction_currency` | Signed `amount_second_currency` exists | Missing explicit credit split | Medium | Open |
| `balance_transaction_currency` | Not exposed | Missing running balance | High | Open |
| `initial_balance_transaction_currency` | Not exposed | Missing account and transaction-currency initial balance before `date_from` | High | Open |
| `ending_balance_transaction_currency` | Not exposed | Missing line ending balance calculated from initial balance plus debit minus credit | High | Open |
| `entered_by` | Can be mapped from `create_uid` | Not exposed in GL view | Medium | Open |
| `modified_by` | Can be mapped from `write_uid` | Not exposed in GL view | Medium | Open |
## Export
| Target export | Tryton / Tradon exposure | Gap | Priority | Status |
| Target export | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| CSV | Standard list export may cover CSV-like exports depending on client | Dedicated flat dataset still required | Medium | Open |
| XLSX | No dedicated XLSX export identified | Missing | Medium | Open |
| PDF with all detail columns | Standard printable GL is not designed for all ideal detail columns | Missing wide detailed output | Medium | Open |
| PDF with all detail columns | Standard printable GL is not designed for all ideal detail columns | Out of scope for first implementation | Low | Deferred |
## Controls and reconciliation
| Target control | Tryton / Tradon exposure | Gap | Priority | Status |
| Target control | Tryton / TradOn exposure | Gap | Priority | Status |
| --- | --- | --- | --- | --- |
| Debit / credit reconcile by period, account and transaction currency | Posting enforces balanced moves in company currency | Transaction-currency reconciliation is not explicit | High | Open |
| Opening + movements = closing by account and currency | Account start/debit/credit/end balances exist in base currency | Currency-level opening and closing missing | High | Open |
| Initial balance + movements = ending balance by account and currency | Account start/debit/credit/end balances exist in base currency | Currency-level initial and ending balances missing | High | Open |
| Base total reconciles with Trial Balance | Trial Balance reuses same account model | Covered for base currency | Covered | Confirmed |
| Audit references preserved | Raw ingredients exist through move, line origin, move origin and invoice origin | Normalized exposure missing | High | Open |
@@ -117,13 +119,12 @@
| Priority | Gap | Status |
| --- | --- | --- |
| High | Build or expose a flat detailed GL dataset matching `GL-001`, not only account summary plus drill-down | Open |
| High | Add transaction-currency grouping, filtering and running balances | Open |
| High | Expose and document `Currency_Rate` with confirmed source, rate date, direct/inverse convention and precision | Open |
| High | Add opening and closing rows by account and transaction currency | Open |
| High | Add transaction-currency grouping, filtering, initial balances and ending balances | Open |
| High | Expose and document `currency_rate` with confirmed source, direction, rate date and precision | Open |
| High | Add initial and ending balance columns by account and transaction currency | Open |
| High | Define mapping for `document_number`, `journal_entry_number`, `voucher_number` and `reference` | Open |
| High | Normalize source document metadata: document type, document date and supplier invoice number | Open |
| Medium | Split `amount_second_currency` into debit and credit transaction-currency columns | Open |
| Medium | Decide and implement GL sign convention transformation for credit columns | Open |
| Medium | Add audit columns `entered_by`, `entered_date`, `modified_by` and `modified_date` | Open |
| Medium | Add dedicated CSV / XLSX export target | Open |
| Low | Add `payable_qty` and `uom` for commodity-related postings using Tradon lot, invoice or fee links | Open |
| Low | Add `payable_qty` and `uom` for commodity-related postings using TradOn lot, invoice or fee links | Open |

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

@@ -1,31 +0,0 @@
# GL-001 Open Points
## Mapping questions
| ID | Question | Area | Status |
| --- | --- | --- | --- |
| 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 |
| GL001-Q014 | Q: Which source, rate date, direct/inverse convention and precision should be used for `Currency_Rate`? | FX rate | Open |
| GL001-Q015 | Q: Should `Currency_Rate` keep its current report-specific capitalization or be harmonized to `currency_rate` with the wider field naming convention? | Field naming | Open |
## Implementation questions
| ID | Question | Area | Status |
| --- | --- | --- | --- |
| 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 | 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 |

12
Assessments/Tradon/GL_001/source_material.md
View File

@@ -9,6 +9,7 @@
| Source analysis date | 2026-05-05 |
| Imported into assessment | 2026-05-07 |
| Target report | `Reports/GL/GL_001_general_ledger.md` |
| Implementation platform | TradOn, the project-specific customized version of Tryton |
## Comparison scope stated in the source
@@ -22,7 +23,7 @@ Standards:
- `Docs/reporting_parameters.md`
- `Docs/reporting_fields_catalog.md`
Current Tryton / Tradon source referenced by the GAP analysis:
Current Tryton / TradOn source referenced by the GAP analysis:
- `modules/account/account.py`
- `modules/account/account.xml`
@@ -32,7 +33,11 @@ Current Tryton / Tradon source referenced by the GAP analysis:
## Repository limitation
This repository does not contain the Tryton / Tradon source files listed above. The present assessment preserves the conclusions of the external GAP analysis and should be treated as documentation of the exposure, not as an independent code review of Tradon.
This repository does not contain the Tryton / TradOn source files listed above. The present assessment preserves the conclusions of the external GAP analysis and should be treated as documentation of the exposure, not as an independent code review of TradOn.
## Implementation context
The GL-001 report is intended to be executed from TradOn. Tryton standard behavior is the baseline for the assessment, while TradOn customizations and report-specific open-source components should be decided in `decision_register.md`.
## Traceability note
@@ -40,7 +45,6 @@ The content in this folder restructures the source analysis into reusable assess
- `exposure_notes.md`
- `gap_mapping.md`
- `open_points.md`
- `decisions.md`
- `decision_register.md`
The incoming source was copied from `Tradon/general_ledger_gap_analysis.md` into `source_documents/general_ledger_gap_analysis.md`. The assessment copy in `source_documents/` is the retained source reference for this assessment.

59
Assessments/Tradon/README.md
View File

@@ -1,20 +1,24 @@
# Tradon Exposure Assessments
This folder documents the exposure of target accounting reports to Tryton / Tradon capabilities.
This folder documents the exposure of target accounting reports to TradOn capabilities.
TradOn is the project-specific customized version of Tryton and is the selected CTRM / ERP platform from which these reports are intended to run.
The purpose is to keep report specifications in `Reports/` clean and stable, while documenting separately:
- coverage identified in Tryton / Tradon;
- coverage identified in Tryton and TradOn;
- functional or technical gaps;
- mapping assumptions;
- open questions;
- open questions and recommended answers;
- decisions taken after review.
## Scope and limits
The current assessments are based on external analysis documents and available documentation. They should not be read as direct validation of the live Tradon implementation unless this is explicitly stated in the relevant assessment.
The current assessments are based on external analysis documents and available documentation. They should not be read as direct validation of the live TradOn implementation unless this is explicitly stated in the relevant assessment.
For GL-001, the source analysis refers to Tryton / Tradon source files, but the current repository does not include that code. The assessment therefore preserves the evidence and conclusions as documented in the external GAP analysis.
For GL-001, the source analysis refers to Tryton / TradOn source files, but the current repository does not include that code. The assessment therefore preserves the evidence and conclusions as documented in the external GAP analysis.
Implementation choices are made per report. For example, a report may use a selected open-source component integrated into TradOn, or require a TradOn customization. These choices belong in the report's `decision_register.md`.
## Structure
@@ -27,8 +31,7 @@ Assessments/
source_documents/
exposure_notes.md
gap_mapping.md
open_points.md
decisions.md
decision_register.md
source_material.md
```
@@ -50,31 +53,39 @@ The assessment process does not change after intake: use the copied repository s
| --- | --- |
| `exposure_notes.md` | Narrative summary of the exposure and main conclusions |
| `gap_mapping.md` | Structured gap mapping by functional area |
| `open_points.md` | Questions, assumptions and confirmations still required |
| `decisions.md` | Decisions and arbitrations taken after review |
| `decision_register.md` | Single source of truth for open questions, recommended answers, decisions, backlog blockers and validation expectations |
| `source_material.md` | Source documents, date, scope and traceability notes |
## Open question notation
## Decision register
Open questions must be written in the relevant assessment document, except when the user explicitly asks to handle them elsewhere.
Open questions and answers must be written in `decision_register.md`, except when the user explicitly asks to handle them elsewhere.
Use these prefixes:
The register should contain:
| Prefix | Meaning |
- a quick answer board listing each question, recommended answer, blocking backlog item and status;
- confirmed decisions;
- a detailed section for each question with options, decision, rationale, impact and validation.
Recommended question detail format:
| Field | 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 |
| `Status` | `Open`, `Confirmed`, `Not blocking`, `Deferred` or another explicit assessment status |
| `Area` | Functional or technical area |
| `Blocks` | Backlog item IDs blocked by the question, or `Not blocking` |
| `Question` | The business, mapping or architecture question to answer |
| `Recommended answer` | Assistant or reviewer proposal for arbitration |
| `Options` | Practical choices available to the user |
| `Decision` | Confirmed answer once arbitrated |
| `Rationale` | Why the answer was selected |
| `Impact` | Documentation, reporting or implementation impact |
| `Validation` | Review, reconciliation or sample check expected |
After a document review, any new framing question should be added to the document using the same notation, unless an explicit exception is requested.
Use stable IDs in the form `<REPORT_CODE>-Q###`, for example `GL001-Q016`.
Expected file usage:
After a document review, any new framing question should be added to `decision_register.md`, unless an explicit exception is requested.
- `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.
When a decision is confirmed, update the linked backlog items according to the development readiness rule.
## Recommended statuses
@@ -90,4 +101,4 @@ Expected file usage:
`Reports/` remains the target functional specification.
`Assessments/Tradon/` documents the comparison with Tryton / Tradon and should not silently redefine the target report. Any change to a report specification should be made explicitly in the relevant `Reports/` file and, where useful, recorded in the assessment `decisions.md`.
`Assessments/Tradon/` documents the comparison with TradOn, including its Tryton baseline, and should not silently redefine the target report. Any change to a report specification should be made explicitly in the relevant `Reports/` file and, where useful, recorded in the assessment `decision_register.md`.