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