This feature allows not to settle Payment ID (variabilní symbol) while automatic settlement of transactions in GL journals.

tbd

Feature includes support for the PEPPOL BIS Billing 3.0 (Slovakia) format. The feature enables generation of compliant XML documents for Sales invoices, Free text invoices, Project invoices, and related credit notes for submission through the Electronic Invoicing Service to a configured Service Provider.

Feature includes an eInvoice journal that provides centralized management of electronic invoices. The solution supports generation of electronic invoice XML file, submission of invoices to a configured Service Provider, processing of inbound electronic invoices received from the Service Provider, and tracking of document processing status.

Aktivní TDD: TDD eInvoicing.EX v2 docx.docx

Three CZ VAT Electronic Reporting formats (VAT declaration, VAT Control Statement, Posted sales tax detail CSV export) were optimized for runtime performance using the same two levers proven on the SK branch. In addition, both optimizations were written into the configurations' <Delta> so they survive a future rebase onto a newer Microsoft base. Report output structure is unchanged.

"Balance control" is a feature that allows for the viewing of balances for General Ledger (GL) accounts (GL/CoA/Accounts/Balance control accounts), bank accounts, and cash accounts. For bank accounts, the standard Microsoft (MS) functionality only displays these balances in the accounting currency, even though transactions may be recorded in various other currencies. For cash accounts, the standard system allows for a view in a foreign currency directly via the "Cash Balance" function.

The "Balance control" feature can be accessed from the General Ledger journal (Inquiries/Balance control), from specific General Ledger journal lines, and from the bank account record itself (Balance control).

The AC modification extends this functionality by enabling the display of balances in a foreign currency whenever the transaction currency differs from the system's base currency.

This allows users, for example, to compare the balance on a bank statement (for an account held in a foreign currency) against the balance displayed within the system—all before the journal is actually posted. Once the journal has been posted, this feature is no longer available (as it would no longer serve a purpose).

SK VAT ER Configurations — Performance Optimization & Sign Defect Fix

Summary

Three SK VAT Electronic Reporting formats (VAT declaration, VAT Control Statement, Posted sales tax detail CSV export) were optimized for runtime performance, and a data-correctness defect inherited from the Microsoft/Asl base mapping was fixed. Report output structure is unchanged.

Deliverables

• Asl Tax declaration model (SK) — 171.4.9 → 171.4.10

• Asl Tax declaration model mapping LITE (SK) — new configuration → 171.344.7.1

• Asl VAT declaration XML (SK) — 171.4.9.8 → 171.4.9.9

• Asl VAT Posted sales tax detail export CSV (SK) — 171.4.9.8 → 171.4.9.9

• Asl VAT Control statement XML (SK) — 171.4.9.12 → 171.4.9.13

All three formats reference model revision 10 and mapping 171.344.7.1.

Change 1 — Lean data model roots (primary performance gain)

ER evaluates the entire model root at report execution, not only the nodes a format actually reads. The original TaxDeclarationModel root pulls 26 containers, many of which none of these formats consume.

Two new roots were added alongside the original, which remains bit-identical to 171.4.9:

• TaxDeclarationModelLite — 7 containers — used by VAT declaration and CSV export

• TaxDeclarationModelLiteKH — 6 containers — used by VAT Control Statement

Resulting reduction in evaluated model-to-datasource bindings (ERDataContainerPathBinding):

• MS 171.344.7.12 (original): 487 bindings

• New LITE, declaration / CSV: 235 bindings

• New LITE, Control Statement: 226 bindings

Roughly a 50% reduction in evaluated bindings.

Change 2 — Datasource path caching (PathsToCache)

The base formats defined no cached paths, causing repeated re-evaluation of the same queries per row/occurrence. Cached paths added:

• VAT declaration: 0 → 9 paths

• CSV export: 0 → 14 paths

• VAT Control Statement: 0 → 15 paths

Change 3 — Cross-group reference defect (base mapping 171.344.7.12)

In the $IsTaxBaseAmountReversed expression, records belonging to the voucher group ($TaxTransDetailsJoinGroupWVoucher) read the transaction classifier from a different, non-voucher group ($TaxTransDetailsJoinGroup):

IF(AND('$TaxTransDetailsJoinGroupWVoucher'.aggregated.TaxAmount<>0,

  OR('$TaxTransDetailsJoinGroup'.grouped.'$TransactionClassificator'=...SalesReverseChargeCreditNote,

     '$TaxTransDetailsJoinGroup'.grouped.'$TransactionClassificator'=...SalesReverseCharge)), -(1), 1)

Two consequences:

• Performance: forced a second GROUP BY over TaxTransDeclarationDetailsNoAdjustmentView.

• Correctness: because this is a reference into a foreign list, ER applied the classifier of the first record of that group to all rows — producing an incorrect amount sign on reverse-charge rows.

Affected bindings (6): TaxBaseAmount, TaxBaseAmountCur, DeductibleTaxBaseAmount, DeductibleTaxBaseAmountCur, TaxBaseInCost, TaxBaseInCostCur.

Exposure per format:

• Posted sales tax detail CSV export — evaluates all 6 defective bindings — affected

• VAT Control Statement — affected via its own mapping

• VAT declaration — evaluates 0 — not affected today

Fixed in both mappings (2 references each). The declaration mapping was fixed as well, so the defect cannot resurface if the declaration is ever switched to the voucher group.

Not changed

The ERFormatVersion node — the format tree that defines the output file — is bit-identical to the Microsoft/Asl source in all three formats. Only data retrieval was modified, not output definition.

Deployment notes

1. Import order: data model → model mapping → the three formats.

2. Delete and re-import the Asl Tax declaration model mapping LITE (SK) configuration in F&O. Versions 7.1–7.5 were previo

This feature allows you to post and subsequently report a reduction in the right to an input deduction for VAT transactions using a coefficient in accordance with § 50 of Act No. 222/2004 of the Collection of Laws.

The functionality differentiates between regular input tax credits and input tax credits for fixed assets for monthly reductions using a coefficient and yearly recalculations.

The feature enables user to record and afterwards allocate accrued costs or revenues, while letting the user sequentially process the postings in the upcoming periods.

There are some non-standard vendor accounts in ADIS, that are not imported into the D365FO right now using the Unreliable payer batch job.

VIES verification inconsistency solved. New notiication in D365 will occur if VIES is overload.