Skip to main content

Release 26.5.46 on 14.07.2026

· 2 min read

This release fills the eDoc document number for incoming purchase invoices and makes posted purchase invoices distinguishable on the eDoc list, stops the XRechnung CII export from tripping EN16931 BR-G-01 with an orphan zero-value VAT breakdown group for export-outside-EU customers, and reads the OpenTRANS blob sent to Cegedim back as UTF-8 so umlauts are preserved.

Feature
  • The eDoc "Document No." is now filled for both directions: for incoming purchase invoices it is the external number carried in the xRechnung (Exchanged Document ID), for outgoing documents it is the linked sales document number, and existing records are populated too. Posted and unposted purchase invoices are now distinguishable — a subscriber on Purch.-Post.OnAfterPostPurchaseDoc stamps the posted invoice number and a "Purchase Invoice Posted" flag onto the linked xRechnung, and a new filterable "Posted" column (plus the posted invoice number) lets you filter posted invoices out. The "Created Invoice" drill-down, which opened a Sales Invoice for a Purchase Header number, was also fixed (CHN-325 / INC-1479)
Bugfix
  • XRechnung CII export no longer trips EN16931 BR-G-01 for export-outside-EU (e.g. CH) customers. When SITE preprocessing deletes a zero-amount sales line, its VAT category could survive as an orphan group (base 0, VAT 0) in the VAT breakdown (BG-23) with no matching invoice line, which the KoSIT validator rejected. The export now drops any breakdown group whose VAT base and VAT amount are both zero and whose tax category no longer appears on a surviving line; non-zero groups, and zero groups still backed by a surviving line, are untouched. Applied to both invoices and credit memos (CHN-327 / INC-1443)
  • The OpenTRANS document and mail body sent to Cegedim are now read back from the stored blob as UTF-8. The blobs are written as UTF-8 but were read with the default (MSDos) encoding, which mangled multi-byte characters such as German umlauts in the transmitted content. A shared GetContentAsText() helper centralises the correct UTF-8 read