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

16
AGENT.md
View File

@@ -30,6 +30,12 @@ When documents conflict, use this order of authority:
If a conflict remains unclear, document it as an open question instead of silently choosing a business rule.
## Implementation platform context
The accounting reports are intended to run from TradOn, the project-specific customized version of Tryton. Treat TradOn as the selected CTRM / ERP implementation platform.
The baseline exposure is assessed against Tryton capabilities and known TradOn customizations. Report-specific choices such as open-source UI components, exports, calculations or additional TradOn customizations must be arbitrated per report in the relevant `decision_register.md`.
## Working principles
- Keep specifications functional and technology-neutral until a data model is provided.
@@ -144,19 +150,19 @@ When asked to create or refresh a Tradon assessment:
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.
5. Capture exposure notes, gap mapping and the unified decision register in the assessment folder.
6. Document TradOn-specific implementation choices in `decision_register.md`; do not rewrite the target report silently from the GAP analysis.
7. Write new framing questions in `decision_register.md` with a recommended answer, options, impact and validation expectation.
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.
2. Link each backlog item to stable gap themes and `decision_register.md` question IDs.
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.
7. Prefer linking backlog dependencies to the stable question IDs in `decision_register.md`; do not create separate pending-decision wrapper IDs unless explicitly requested.
## Boundaries

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

128
DevelopmentBacklog/Tradon/GL_001_backlog.md
View File

@@ -11,25 +11,24 @@ This file is a working conversion layer between the documented GL-001 gaps and f
| 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` |
| Decision register | `Assessments/Tradon/GL_001/decision_register.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-001 | High | Blocked | Flat detailed GL dataset | GL001-Q008 |
| DEV-GL001-002 | High | Blocked | Transaction-currency grouping and balances | GL001-Q009 |
| DEV-GL001-003 | High | Blocked | Initial and ending balance columns | GL001-Q008, GL001-Q009 |
| DEV-GL001-004 | High | Blocked | Document and reference mapping | GL001-Q001, GL001-Q002, GL001-Q003 |
| DEV-GL001-005 | High | Blocked | Source document metadata | GL001-Q006 |
| DEV-GL001-006 | Medium | Ready | Transaction-currency debit and credit split | None |
| DEV-GL001-007 | Medium | Ready | GL sign convention transformation | None |
| DEV-GL001-008 | Medium | Ready | Audit metadata columns | None |
| DEV-GL001-009 | Medium | Blocked | CSV and XLSX export | DEV-GL001-001 |
| DEV-GL001-010 | Low | Blocked | Commodity quantity fields | GL001-PD005 |
| DEV-GL001-011 | High | Blocked | Currency rate exposure | GL001-PD008 |
| DEV-GL001-010 | Low | Blocked | Commodity quantity fields | GL001-Q007, GL001-Q013 |
| DEV-GL001-011 | High | Ready | Currency rate exposure | None |
## DEV-GL001-001 Flat detailed GL dataset
@@ -37,26 +36,26 @@ This file is a working conversion layer between the documented GL-001 gaps and f
| --- | --- |
| 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 |
| Decision register | GL001-Q008 |
| 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.
- Include one row structure capable of representing movement lines with initial and ending balance columns.
- 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.
- Final source table or SQL design until GL001-Q008 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.
- Dataset rows can expose movement, initial balance and ending balance values without ambiguous interpretation.
Validation:
@@ -66,9 +65,9 @@ Validation:
| Field | Value |
| --- | --- |
| Source gap | Add transaction-currency grouping, filtering and running balances |
| Linked questions | GL001-Q004, GL001-Q009 |
| Linked decisions | GL001-PD002 |
| Source gap | Add transaction-currency grouping, filtering, initial balances and ending balances |
| Linked questions | GL001-Q009 |
| Decision register | GL001-Q009 |
| Priority | High |
| Status | Blocked |
@@ -76,54 +75,55 @@ 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`.
- Preserve the `Currency_Rate` value needed to explain conversion from transaction currency to base currency.
- Calculate or expose `initial_balance_transaction_currency` and `ending_balance_transaction_currency`.
- Preserve the `currency_rate` value needed to explain conversion from transaction currency to base currency.
Out of scope:
- Deciding whether empty `second_currency` means company currency; this is GL001-PD002.
- Deciding the `Currency_Rate` source, direction and precision; this is GL001-PD008.
- Deciding the `currency_rate` precision; this remains part of GL001-Q014 follow-up mapping.
Acceptance criteria:
- GL-001 can be grouped by account and transaction currency.
- Running transaction-currency balances are available for movement rows.
- Initial and ending transaction-currency balances are available for movement rows.
- Base-currency lines have a documented transaction-currency fallback or exclusion rule.
- Non-base-currency rows retain a rate value or documented blank rule through DEV-GL001-011.
Validation:
- For each account and transaction currency, opening plus movements equals closing once DEV-GL001-003 is available.
- For each account and transaction currency, initial balance plus movements equals ending balance once DEV-GL001-003 is available.
## DEV-GL001-003 Opening and closing rows
## DEV-GL001-003 Initial and ending balance columns
| Field | Value |
| --- | --- |
| Source gap | Add opening and closing rows by account and transaction currency |
| Source gap | Add initial and ending balance columns by account and transaction currency |
| Linked questions | GL001-Q009 |
| Linked decisions | GL001-PD006 |
| Decision register | GL001-Q008, GL001-Q009, GL001-Q016 |
| 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.
- Populate `initial_balance_transaction_currency` and `initial_balance_base_currency` on each movement row.
- Populate `ending_balance_transaction_currency` and `ending_balance_base_currency` on each movement row.
- Calculate ending balances as initial balance plus debit minus credit under the GL-001 positive-credit convention.
- Apply the balance sheet versus profit and loss initial-balance rule using the confirmed account classification source.
Out of scope:
- Storage versus reporting-layer calculation decision for transaction-currency opening balances.
- Storage versus reporting-layer calculation decision for transaction-currency initial and ending 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.
- Each account and transaction-currency movement row includes initial and ending balances in transaction currency.
- Each account and transaction-currency movement row includes initial and ending balances in base currency.
- Balance sheet accounts use the account balance through the day before `date_from` as initial balance.
- Profit and loss accounts use the fiscal-year-to-date movement balance through the day before `date_from` as initial balance.
Validation:
- Opening balance plus period movements reconciles to closing balance for each account and transaction currency.
- Initial balance plus period movements reconciles to ending balance for each account and transaction currency.
## DEV-GL001-004 Document and reference mapping
@@ -131,7 +131,7 @@ Validation:
| --- | --- |
| 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 |
| Decision register | GL001-Q001, GL001-Q002, GL001-Q003 |
| Priority | High |
| Status | Blocked |
@@ -159,8 +159,8 @@ Validation:
| 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 |
| Linked questions | GL001-Q006 |
| Decision register | GL001-Q006, GL001-Q012 |
| Priority | High |
| Status | Blocked |
@@ -188,15 +188,15 @@ Validation:
| Field | Value |
| --- | --- |
| Source gap | Split `amount_second_currency` into debit and credit transaction-currency columns |
| Linked questions | GL001-Q004 |
| Linked decision | GL001-PD002 |
| Linked questions | None |
| Decision register | GL001-Q004 |
| Priority | Medium |
| Status | Blocked |
| Status | Ready |
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.
- Apply the confirmed fallback rule: use `second_currency` when present, otherwise use company currency.
Out of scope:
@@ -216,10 +216,10 @@ Validation:
| Field | Value |
| --- | --- |
| Source gap | Decide and implement GL sign convention transformation for credit columns |
| Linked questions | GL001-Q005 |
| Linked decision | GL001-PD003 |
| Linked questions | None |
| Decision register | GL001-Q005 |
| Priority | Medium |
| Status | Blocked |
| Status | Ready |
Development scope:
@@ -233,8 +233,8 @@ Out of scope:
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.
- `credit_*` amounts are positive, following the current Tryton convention.
- Initial and ending balances are consistent with the exported debit and credit signs.
Validation:
@@ -245,20 +245,16 @@ Validation:
| Field | Value |
| --- | --- |
| Source gap | Add audit columns `entered_by`, `entered_date`, `modified_by` and `modified_date` |
| Linked questions | GL001-Q010 |
| Linked decision | GL001-PD007 |
| Linked questions | None |
| Decision register | GL001-Q010 |
| Priority | Medium |
| Status | Blocked |
| Status | Ready |
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`.
@@ -300,9 +296,9 @@ Validation:
| Field | Value |
| --- | --- |
| Source gap | Add `payable_qty` and `uom` for commodity-related postings using Tradon lot, invoice or fee links |
| 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 |
| Decision register | GL001-Q007, GL001-Q013 |
| Priority | Low |
| Status | Blocked |
@@ -328,30 +324,30 @@ Validation:
| Field | Value |
| --- | --- |
| Source gap | Expose and document `Currency_Rate` with confirmed source, rate date, direct/inverse convention and precision |
| Linked questions | GL001-Q014, GL001-Q015 |
| Linked decision | GL001-PD008 |
| Source gap | Expose and document `currency_rate` with confirmed source, rate date, direct/inverse convention and precision |
| Linked questions | None |
| Decision register | GL001-Q014, GL001-Q015 |
| Priority | High |
| Status | Blocked |
| Status | Ready |
Development scope:
- Populate `Currency_Rate` for GL-001 rows where transaction currency and base currency differ.
- Populate `currency_rate` for GL-001 rows where transaction currency and base currency differ.
- Define the blank or default rule for same-currency rows.
- Preserve enough information to reconcile transaction-currency amounts, base-currency amounts and the displayed FX rate.
- Keep the output column name aligned with `Reports/GL/GL_001_general_ledger.md` until naming is arbitrated.
- Keep the output column name aligned with `Reports/GL/GL_001_general_ledger.md`.
Out of scope:
- Creating a global FX-rate service or replacing source accounting conversion logic.
- Renaming `Currency_Rate` to `currency_rate` before GL001-PD008 is confirmed.
- Changing the confirmed `currency_rate` field name without a new decision.
Acceptance criteria:
- GL-001 output includes `Currency_Rate` in the required column order.
- GL-001 output includes `currency_rate` in the required column order.
- Rate source and direct/inverse convention are documented for each supported origin.
- Same-currency and missing-rate cases follow a documented rule.
- Exported transaction/base amounts reconcile to `Currency_Rate` within agreed rounding tolerance.
- Exported transaction/base amounts reconcile to `currency_rate` within agreed rounding tolerance.
Validation:

2
DevelopmentBacklog/Tradon/README.md
View File

@@ -29,7 +29,7 @@ Each item should include:
- backlog ID;
- source report;
- source gap or assessment reference;
- linked open point or decision;
- linked `decision_register.md` question or decision ID;
- development scope;
- out of scope;
- acceptance criteria;

16
Docs/reporting_fields_catalog.md
View File

@@ -24,19 +24,19 @@ It is intended to prepare the future mapping with the target CTRM / ERP. The map
| `ageing_basis_date` | Date used to calculate ageing. | `AR-002`, `AP-002` |
| `ageing_bucket` | Ageing bucket label. | `AR-002`, `AP-002` |
| `ageing_bucket_order` | Sort order of the ageing bucket. | `AR-002`, `AP-002` |
| `balance_base_currency` | Running balance in base currency. | `GL-001`, `AR-003`, `AP-003` |
| `balance_base_currency` | Running balance in base currency. | `AR-003`, `AP-003` |
| `balance_current_year_base_currency` | Balance at the selected closing date in base currency. | `FIN-001` |
| `balance_current_year_transaction_currency` | Balance at the selected closing date in transaction currency, when transaction currency presentation is enabled. | `FIN-001` |
| `balance_previous_year_base_currency` | Balance at the prior fiscal year comparison date in base currency. | `FIN-001` |
| `balance_previous_year_transaction_currency` | Balance at the prior fiscal year comparison date in transaction currency, when transaction currency presentation is enabled. | `FIN-001` |
| `balance_transaction_currency` | Running balance in transaction currency. | `GL-001`, `AR-003`, `AP-003` |
| `balance_transaction_currency` | Running balance in transaction currency. | `AR-003`, `AP-003` |
| `base_currency` | Functional or company base currency. | `GL-001`, `GL-002`, `FIN-001`, `FIN-002`, `FIN-003`, `AR-001`, `AR-002`, `AR-003`, `AP-001`, `AP-002`, `AP-003` |
| `closing_balance_base_currency` | Closing balance in base currency. | `FIN-003`, `AR-001`, `AP-001` |
| `closing_balance_transaction_currency` | Closing balance in transaction currency. | `FIN-003`, `AR-001`, `AP-001` |
| `counterparty` | Customer, supplier, broker or other party. | `GL-001`, `GL-002` |
| `credit_base_currency` | Credit amount or movement in base currency. | `GL-001`, `GL-002`, `FIN-003`, `AR-001`, `AR-003`, `AP-001`, `AP-003` |
| `credit_transaction_currency` | Credit amount or movement in transaction currency. | `GL-001`, `GL-002`, `FIN-003`, `AR-001`, `AR-003`, `AP-001`, `AP-003` |
| `Currency_Rate` | FX rate applied to convert the transaction-currency amount to base currency for the GL-001 line. | `GL-001` |
| `currency_rate` | FX rate applied to convert the transaction-currency amount to base currency for the GL-001 line. | `GL-001` |
| `customer` | Customer account code. | `AR-001`, `AR-002`, `AR-003` |
| `customer_name` | Customer legal or commercial name. | `AR-001`, `AR-002`, `AR-003` |
| `customer_reference` | Customer reference or external customer document reference, when available. | `AR-003` |
@@ -51,6 +51,10 @@ It is intended to prepare the future mapping with the target CTRM / ERP. The map
| `entered_by` | User who created the entry. | `GL-001`, `GL-002`, `AR-003`, `AP-003` |
| `entered_date` | Entry creation date. | `GL-001`, `GL-002`, `AR-003`, `AP-003` |
| `entity` | Legal entity or company code. | `GL-001`, `GL-002`, `AR-001`, `AR-002`, `AR-003`, `AP-001`, `AP-002`, `AP-003` |
| `ending_balance_base_currency` | Ending balance in base currency after applying the line movement to the initial balance. | `GL-001` |
| `ending_balance_transaction_currency` | Ending balance in transaction currency after applying the line movement to the initial balance. | `GL-001` |
| `initial_balance_base_currency` | Initial balance before `date_from`, expressed in base currency. For balance sheet accounts this is the cumulative balance through the previous day; for profit and loss accounts this is the fiscal-year-to-date movement through the previous day. | `GL-001` |
| `initial_balance_transaction_currency` | Initial balance before `date_from` for the account and transaction currency. For balance sheet accounts this is the cumulative balance through the previous day; for profit and loss accounts this is the fiscal-year-to-date movement through the previous day. | `GL-001` |
| `journal` | Accounting journal. | `GL-001`, `GL-002`, `AR-003`, `AP-003` |
| `journal_entry_number` | Journal entry sequence or identifier. | `GL-001`, `GL-002`, `AR-003`, `AP-003` |
| `journal_name` | Accounting journal name. | `GL-002` |
@@ -96,7 +100,11 @@ It is intended to prepare the future mapping with the target CTRM / ERP. The map
| `settlement_status` | Open, partially settled, settled and reversed logic depends on the ERP subledger. |
| `voucher_number` | Should be mapped only if it is distinct from `document_number`, `supplier_invoice_number`, customer references and payment references. |
| `supplier_invoice_number` | May map to a vendor invoice number, supplier reference or AP invoice field depending on ERP terminology. |
| `Currency_Rate` | GL-001-specific FX-rate field; mapping must confirm rate source, rate date, direct versus inverse convention, precision and naming convention. |
| `currency_rate` | GL-001 FX-rate field; mapping must use the stored accounting move line rate, reversing it when the stored accounting convention is inverse to the report display. |
| `initial_balance_base_currency` | GL-001 rolling balance immediately before the transaction line; the first line uses account type to distinguish balance sheet cumulative balances from profit and loss fiscal-year-to-date movement balances. |
| `initial_balance_transaction_currency` | GL-001 rolling transaction-currency balance immediately before the transaction line, calculated by account and transaction currency. |
| `ending_balance_base_currency` | Must equal `initial_balance_base_currency + debit_base_currency - credit_base_currency` under the GL-001 positive-credit convention. |
| `ending_balance_transaction_currency` | Must equal `initial_balance_transaction_currency + debit_transaction_currency - credit_transaction_currency` under the GL-001 positive-credit convention. |
| `purchase_invoice_number` | Should be mapped only if the ERP exposes a separate internal purchase invoice number. |
| `customer_reference` | Should be mapped only if the ERP exposes a distinct customer-facing reference. |
| `payment_reference` | Should be mapped only if payment references are stored separately from document references. |

13
Docs/reporting_standards.md
View File

@@ -26,7 +26,7 @@ When a report exposes an FX rate between transaction currency and base currency,
- whether the rate is direct or inverse;
- the number of decimal places preserved in the export.
`GL-001 General Ledger` currently defines the FX-rate field as `Currency_Rate`. This report-specific name should be preserved in GL-001 exports until the field naming convention is explicitly harmonized.
`GL-001 General Ledger` defines the FX-rate field as `currency_rate`, following the wider field naming convention.
---
@@ -50,6 +50,15 @@ Examples:
- `credit_base_currency`
- `balance_base_currency`
When a detailed report needs to show rolling balances on each movement line rather than a single running balance column, use:
- `initial_balance_transaction_currency`
- `ending_balance_transaction_currency`
- `initial_balance_base_currency`
- `ending_balance_base_currency`
For `GL-001 General Ledger`, these initial and ending balance fields replace `balance_transaction_currency` and `balance_base_currency`. The first line initial balance date is the day before `date_from`: balance sheet accounts use the account balance up to that date, while profit and loss accounts use the movement balance from the start of the fiscal year up to that date. Subsequent line initial balances roll forward from the previous line ending balance.
---
## Posting status
@@ -73,7 +82,7 @@ General financial statement sign conventions:
These sign conventions apply to financial statement presentation and summary reports. Detail ledger reports may define their own sign convention when required.
For `GL-001 General Ledger`, debit amounts are positive and credit amounts are negative, as specified in the report definition.
For `GL-001 General Ledger`, debit amounts and credit amounts are positive, following the current Tryton convention. Ending balances are calculated as initial balance plus debit minus credit.
---

70
Reports/GL/GL_001_general_ledger.md
View File

@@ -38,9 +38,9 @@ Standard parameters:
- `date_from`
- `date_to`
- `account`
- `currency`
- `currency` (transaction currency)
- `journal`
- `entity`
- `entity` (current TradOn company context for the first implementation)
Additional filter parameters out of scope for this report:
@@ -54,9 +54,9 @@ Additional filter parameters out of scope for this report:
- posting date between `date_from` and `date_to`;
- account or account range;
- currency;
- transaction currency;
- journal;
- entity;
- entity through the current TradOn company context;
- document number or voucher number, if available.
---
@@ -92,23 +92,20 @@ Totals should be displayed by:
- base currency;
- report total.
Optional grouping to confirm:
- entity.
Out of scope grouping:
- journal;
- entity;
- counterparty;
- analytic account;
- profit center.
Balance presentation:
- opening balance rows should be displayed by account and transaction currency;
- closing balance rows should be displayed by account and transaction currency;
- opening and closing balances should be shown in transaction currency and base currency;
- running balances should be calculated line by line between opening and closing balance rows.
- initial and ending balances should be displayed as rolling balances on each transaction line by account and transaction currency;
- initial and ending balances should be shown in transaction currency and base currency;
- transaction-line initial balances should represent the balance immediately before the transaction line;
- transaction-line ending balances should represent the balance immediately after the transaction line.
---
@@ -121,7 +118,7 @@ Required columns:
| `entity` | Legal entity or company code |
| `account` | General ledger account code |
| `account_name` | General ledger account name |
| `transaction_currency` | Original transaction currency |
| `transaction_currency` | Original transaction currency, defaulting to `base_currency` when no distinct transaction currency is stored |
| `base_currency` | Functional or company base currency |
| `posting_date` | Accounting posting date |
| `document_date` | Source document date |
@@ -137,13 +134,15 @@ Required columns:
| `reference` | External or source reference |
| `payable_qty` | Payable quantity for commodity-related postings only |
| `uom` | Unit of measure for payable quantity |
| `initial_balance_transaction_currency` | Rolling balance of the account and transaction currency immediately before the transaction line |
| `debit_transaction_currency` | Debit amount in transaction currency |
| `credit_transaction_currency` | Credit amount in transaction currency |
| `balance_transaction_currency` | Running balance in transaction currency |
| `Currency_Rate` | FX rate of the transaction |
| `ending_balance_transaction_currency` | Rolling balance in transaction currency immediately after the transaction line |
| `currency_rate` | FX rate of the transaction |
| `initial_balance_base_currency` | Rolling balance in base currency immediately before the transaction line |
| `debit_base_currency` | Debit amount in base currency |
| `credit_base_currency` | Credit amount in base currency |
| `balance_base_currency` | Running balance in base currency |
| `ending_balance_base_currency` | Rolling balance in base currency immediately after the transaction line |
| `entered_date` | Entry creation date |
| `entered_by` | User who created the entry |
| `modified_date` | Last modification date |
@@ -156,14 +155,26 @@ The report should display individual accounts only. Account hierarchy levels are
Amount sign convention for this report:
- debit amounts are displayed as positive amounts;
- credit amounts are displayed as negative amounts;
- running balances are calculated using this debit-positive and credit-negative convention.
- credit amounts are displayed as positive amounts, following the current Tryton convention;
- ending balances are calculated using this debit-positive and credit-positive convention;
- `ending_balance_transaction_currency` equals `initial_balance_transaction_currency` plus `debit_transaction_currency` minus `credit_transaction_currency`;
- `ending_balance_base_currency` equals `initial_balance_base_currency` plus `debit_base_currency` minus `credit_base_currency`.
Initial balance convention:
- for the first transaction line in each account and transaction-currency group, the initial balance date is the day before `date_from`;
- for balance sheet accounts, the first line initial balance should equal the account balance up to and including the day before `date_from`;
- for profit and loss accounts, the first line initial balance should equal the movement balance from the start of the fiscal year up to and including the day before `date_from`;
- balance sheet versus profit and loss classification should use the Tryton / TradOn account classification;
- for subsequent transaction lines, the initial balance should equal the previous transaction line's ending balance in the same account and transaction-currency group.
FX rate presentation for this report:
- `Currency_Rate` should display the FX rate used to convert transaction-currency amounts into base-currency amounts;
- for same-currency transactions, `Currency_Rate` should be either `1.000000` or blank according to the confirmed ERP export convention;
- the source of the rate, rate date, direct versus inverse convention and precision remain to be confirmed during mapping.
- `currency_rate` should display the stored accounting move line rate used to convert transaction-currency amounts into base-currency amounts;
- when the stored accounting rate is expressed as `1 accounting currency = x transaction currency`, `currency_rate` should display that rate;
- when the stored accounting rate is expressed as `x accounting currency = 1 transaction currency`, `currency_rate` should display the reverse stored accounting rate;
- for same-currency transactions, `currency_rate` should be either `1.000000` or blank according to the confirmed ERP export convention;
- the rate date and precision remain to be confirmed during mapping.
---
@@ -179,24 +190,29 @@ The report may contain a large number of accounting lines and should support exp
- CSV
- XLSX
- PDF, including all detail columns
Out of scope for the first implementation:
- PDF export
---
## 11 Controls / reconciliation rules
- Total debit and credit amounts should reconcile by selected period, account and transaction currency.
- For each account and transaction currency grouping, opening balance plus movements should reconcile to closing balance.
- For each account and transaction currency grouping, first-line initial balance plus cumulative movements should reconcile to the final line ending balance.
- The report total in base currency should reconcile with the trial balance for the same entity, period and account selection.
- For non-base-currency lines, transaction-currency amounts, `Currency_Rate` and base-currency amounts should reconcile within the agreed rounding tolerance.
- For non-base-currency lines, transaction-currency amounts, `currency_rate` and base-currency amounts should reconcile within the agreed rounding tolerance.
- Each line should retain enough audit references to trace back to the accounting document and source document where available.
- AP-related entries should be identifiable by both `document_number` and `supplier_invoice_number` when the supplier invoice number is available.
- Debit, credit and balance signs should follow the GL-specific convention defined in this report.
- Debit, credit, initial balance and ending balance signs should follow the GL-specific convention defined in this report.
---
## 12 Open questions
- Which source should be used for `document_number`, `journal_entry_number`, `voucher_number` and `reference` when several accounting or source-document references are available?
- Which source origin models should feed `document_date`, `document_type` and `supplier_invoice_number` in the first implementation?
- Should `posting_status` be displayed in the first implementation? This depends on the target ERP capabilities.
- Should `Currency_Rate` use the ERP stored accounting rate, a reporting FX rate, or a derived rate from transaction/base amounts?
- Should `Currency_Rate` remain capitalized as currently specified, or be renamed to `currency_rate` to match the wider field naming convention?
- Are `payable_qty` and `uom` mandatory for the GL-001 launch, or can they remain optional commodity extensions?
- Should the document or voucher number filter search only `document_number` and `voucher_number`, or also `journal_entry_number`, `reference` and `supplier_invoice_number`?