Skip to content

Fix Norwegian SAF-T 1.30 export issues - #11629

Open
Aleksandr Gladkov (AleksanderGladkov) wants to merge 1 commit into
mainfrom
bugs/650030-master-NO-SAFT-Issues
Open

Aleksandr Gladkov (AleksanderGladkov) wants to merge 1 commit into
mainfrom
bugs/650030-master-NO-SAFT-Issues

Conversation

@AleksanderGladkov

@AleksanderGladkov Aleksandr Gladkov (AleksanderGladkov) commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

ISSUE:
Norwegian SAF-T 1.30 exports can contain wrong header versions, negative credit amounts, unwanted dimensions and inconsistent transaction totals.

CAUSE:
The header versions were hardcoded. Credit currency amounts retained their sign, excluded dimensions could produce XML nodes, and the transaction count used G/L transaction numbers instead of exported transaction groups.

SOLUTION:

  • Export 1.30 and the current application version in the header.
  • Export credit amounts as non-negative values.
  • Omit analysis data for dimensions not selected for export.
  • Count transaction groups across journals and repeat the total in every split file.
  • Keep SAF-T 1.20 unchanged.

TESTS:
Added XML regression coverage for header versions, customer/vendor/bank currencies, dimension selection and transaction totals in single and split files.

Fixes AB#650030

@alexei-dobriansky

Copy link
Copy Markdown
Contributor

Good Sense Reviewer - Round 1

Recommendation: Request Changes

What this PR does

This updates the Norwegian SAF-T 1.30 exporter to write the 1.30 header version, use the running application version, export foreign-currency credit amounts as positive values, suppress unselected dimensions, and count exported transaction groups. The header, currency, and dimension changes are targeted, and the version branch keeps the 1.20 count path unchanged. The transaction-count change still calculates one count from the full export header period, so split G/L files can still write a value that does not match the Transaction nodes in that XML file.

Problem-solution fit

Fit: Partial

The change addresses the header, amount, and analysis parts of the reported problem. It only partly addresses the split-file entry-count problem because the count is still stored once for the whole selected period and then repeated in each G/L file.

Suggestions

S1 (🔴 High): Count split files per exported period
The 1.30 counter still uses the export header date range, and the G/L files still emit the same header-level value. When the export is split by month or date, one XML file can contain only part of the Transaction nodes but still say the total count for the whole selection. Please count the transactions for the current export line, and update the split tests to assert each file's own count.

Risk assessment and necessity

Risk: This is a tax/audit XML export, so a wrong NumberOfEntries value can make split SAF-T 1.30 files internally inconsistent. The change is otherwise narrow: it touches the Norwegian SAF-T exporter and tests, keeps the 1.20 count path behind the existing version branch, and does not depend on a BaseApp event publisher.

Necessity: The fix is needed because the affected export can publish wrong header, amount, analysis, and transaction-count data. The scope is appropriate for a bug fix, but the split-file count must match the contents of each generated file before the change is safe to merge.


[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11629 round=1 by=alexei-dobriansky at=2026-09-18T19:11:59.3630106Z lastSha=9ae3cf7f84080152a0ad03fff51a29c353ba65e7 reviewKey=d265994a7dd4fe8188fc34b447461812f070223078a4c54f30ec5253856f1707 suggestions=S1@f760c363

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Team: Finance GitHub request for Finance area

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants