[DRAFT] Coresuite 8.60 - Changelog

Introduction

We are pleased to announce the release of Coresuite version 8.60. Below is a brief overview of the key updates introduced in this version.

For a full list of changes and enhancements, please refer to our Release Notes.

Important:

If you have not yet upgraded to Coresuite versions 7.90 through 8.20, please be aware that you will need to update the full Coresuite add-on due to significant changes and performance improvements introduced in version 7.90. This update is crucial to ensure compatibility with version 8.35 and future releases.

Coresuite Add-On Installation Folder Change

As we announced in Coresuite 8.30 - changelog, there are key changes to the Coresuite add-on installation process with Coresuite 8.35.
For more details about the change, please see the article Important Notice: Coresuite Add-On Installation Folder Change.

ZUGFeRD Implementation

For more details about the whole ZUGFeRD implementation in Coresuite-related products, please see the article Implementation of ZUGFeRD in Coresuite Designer.

Major Changes Delivered in Coresuite 8.60

Designer: ZUGFeRD - GLN, Location Identifier and Legal Organization Handling

We changed how GLN, location and legal organization data is written in the ZUGFeRD XML file:

• Billing GLN: The billing GLN is no longer used when the shipping GLN is missing.

• Shipping location identifier: The identifier now has its own UDF, U_SWA_LD_ZUGFERD_LocationId. It is written without a schemeID, under the ShipToTradeParty node, for example <ram:ID>RYV-3221</ram:ID>.

• Legal organization: The SpecifiedLegalOrganization node now uses its own UDFs in the Address section, for each billing and shipping information: U_SWA_ZUGFERD_LegalOrgScheme and U_SWA_ZUGFERD_LegalOrgName.

• URIUniversalCommunication: This element can now receive the value NONE. In this case, the element is not included in the XML, and the usual determination logic (PEPPOL -> GLN -> EM) is skipped. This UDF is found at the BP level (ZugFerd EAS Scheme and ZugFerd EAS Value fields).

Note: The electronic address is mandatory for PEPPOL and XRechnung CIUS. Please decide carefully before you use the value NONE.

Note: In the EN 16931 (Comfort) profile, the legal organization name is not shown. Only the XRechnung and Extended profiles show it.

Designer: ZUGFeRD - BT-21 & BT-22 - Handling of translations

We created a new table SWA_LD_ZUGFERDSTR, which maps values used internally by Coresuite to the matching translation stored in the SWA_LD_TEXT table. The mapping is done using the Code field from SWA_LD_TEXT. For example, the internal value for "Managing Director" (ManagingDirector) is mapped to code T0000106 in SWA_LD_TEXT.

This allows translations to be added where available, and also lets customers update the text values themselves.

The following keys are currently in use and can be updated with customer preferences:

• ManagingDirector -> T0000106
• RegisteredOffice -> T0050004

Designer: ZUGFeRD - Customizable Note for Applied Down Payments

The note for applied down payments in the ZUGFeRD XML file can now be customized, also for different languages. The note is built from two translation keys. You can maintain their texts in the SWA_LD_TEXT table (Zugferd Static Translations), as described in the section about the handling of translations.

• DownPaymentNoteHeader: The header text of the note. If the key is empty, the default text "Angewandte Anzahlung(en):" is used.
• DownPaymentNoteDescription: The text for each down payment. You can use the following parameters in curly braces: {DocNum}, {PostingDate}, {NetAmount}, {VatPercent}, {VatAmount} and {GrossAmount}. Only the parameters you use are written to the XML. If the key is empty, all parameters are written.

For example, the following text uses all parameters:

Belegnummer = {DocNum}; Buchungsdatum = {PostingDate}; Nettobetrag = {NetAmount}; USt.-Prozent = {VatPercent}; Steuerbetrag = {VatAmount}; Gesamtbetrag = {GrossAmount}

Zugferd Static Translations - SWA_LD_TEXT configuration:

Example 1: The description uses only {DocNum} and {GrossAmount}. The invoice has one down payment:

<ram:IncludedNote>
  <ram:Content>Anzahlungen
Belegnummer = 6; Gesamtbetrag = 216,00</ram:Content>
  <ram:SubjectCode>AAI</ram:SubjectCode>
</ram:IncludedNote>

Example 2: The description key is empty. The invoice has two down payments:

<ram:IncludedNote>
  <ram:Content>Anzahlungen
Belegnummer = 7; Buchungsdatum = 13.10.2026; Nettobetrag = 439,11; USt.-Prozent = 8; Steuerbetrag = 35,13; Gesamtbetrag = 474,24
Belegnummer = 8; Buchungsdatum = 13.10.2026; Nettobetrag = 878,22; USt.-Prozent = 8; Steuerbetrag = 70,26; Gesamtbetrag = 948,48</ram:Content>
  <ram:SubjectCode>AAI</ram:SubjectCode>
</ram:IncludedNote>

Designer: ZUGFeRD - Adding VAT ExemptionReason

We added the column Allowed VATEX codes to the table SWA_LD_ZUGFERDTAX to hold the appropriate exemption reason code. We also updated the logic to map internally allowed VATEX codes, as not every VATEX code is valid for every ZUGFeRD Tax Category:

When a specific exemption reason is written in the ExemptionReasonCode column, it is checked against the allowed VATEX codes in the table above and inserted into the appropriate reason code XML node. If the value is not among the allowed ones, the default value is used.

Designer: ZUGFeRD - BT-29 - Seller Identifier Mapping

BT-29 is a free text identifier assigned to the seller, for example a vendor number used by the buyer. It is output as ram:SellerTradeParty/ram:ID in the XML without any scheme identifier, meaning any value can be used - it is not restricted to a GLN or any other standardized identifier scheme.

The mapping is:

This is separate from BT-29-0 and BT-29-1, which carry a global identifier with a scheme. Those are output as ram:SellerTradeParty/ram:GlobalID with a schemeID attribute, where BT-29-0 is the identifier value and BT-29-1 is the scheme (for example 0088 for GLN).

Designer: ZUGFeRD - BT-3 - Configurability of Invoice Type Code

BT-3 defines the type of document being issued (e.g. invoice, credit note). Previously this value was fixed. It can now be driven by the Peppol protocol configured on the business partner, making it possible to output the correct document type code per partner automatically.

To support this, we added a new datasource called Document_Peppol (available for both SQL and HANA), which reads the Peppol protocol settings from the business partner master data and the electronic document configuration. The relevant field is ECM6.ETypeDesc, which holds the document type description as defined by the Peppol protocol.

The Peppol mapping is:

For edge cases where neither the fixed document type nor the Peppol protocol covers the required UNTDID 1001 code, the value can also be set via a document-level UDF:

The value for BT-3 is determined using the following priority order:

1. The default Invoice Type Code is set based on SAP's Document Object Type.
2. If a value is present in ECM6.ETypeDesc, it overwrites the value from step 1.
3. If a value is present in the business partner UDF, it overwrites the value from step 2.

Designer: ZUGFeRD - Markant Payment Processor Support

Markant is a payment processor with specific ZUGFeRD invoice requirements. Because Markant acts as both the payment processor and the payment receiver, their GLN is used as the recipient identifier. When Markant's GLN is present, the ZUGFeRD standard requires a DeliveryNote reference to be included in the invoice.

This creates a problem for A/R Credit Notes issued to Markant: credit notes in this scenario are always created without a preceding document chain, so there is no delivery note to reference.

To resolve this, we added a custom mapping Header.Custom.DeliveryNoteRef. It reads from the U_SWA_LD_ZUGFERD_DELNOTEREF field on the Document datasource, allowing the DeliveryNote reference to be set manually on the document. This mapping is only applied when the document type is an A/R Credit Note.

Designer: ZUGFeRD - Configurability of Delivery Address

We added the possibility to configure the delivery address. The same approach was applied to billing data. The mapping table used for shipping and billing addresses differs based on the document datasource:

• Document_88 - SWA_LD_ZUGFERDMAP
• Document_90 - SWA_LD_ZUGFERDMAP90

Designer: ZUGFeRD - Hiding Freight Lines per Document

Freight and expense costs are always exported as a separate line in the ZUGFeRD XML, regardless of the number of invoice lines. Previously there was no reliable way to suppress this: hiding the related mapping fields produced an invalid ZUGFeRD file, and setting the values to zero still generated the additional line with a zero amount.

We moved the freight hiding option to document level, allowing it to be controlled per document rather than globally. A new UDF U_ZF_HideFreightLines has been added at document level and is used via the mapping key Header.HideFreightLines.

Designer: ZUGFeRD - HRB Legal Registration Scheme ID Option

In certain validation scenarios, including specific commercial register number formats, e-invoices could not be processed because the commercial register number specified in the ZUGFeRD mapping was exported in the XML with an explicit scheme ID (e.g., schemeID="0204").

To resolve this issue, a new setting, Use HRB Legal Registration, has been added to the ZUGFeRD tab in the Designer Configuration window.

When this option is enabled, the schemeID attribute is omitted from the ram:SpecifiedLegalOrganization/ram:ID XML node, allowing invoices to pass validation seamlessly.

Designer: ZUGFeRD - Business Address Handling Configuration

We implemented an alternative method for generating company addresses in ZUGFeRD outputs, specifically for cases where the business address differs from the registered office or requires different company detail representations.

A new configuration option Use Alternative Business Address is available under the ZUGFeRD tab in the Designer Configuration window.

When enabled, the system uses the details specified in the designated Business Address fields. If disabled, it defaults to standard SAP company details (City, Company Name, and Company Address).

SwissPayment: Support for ISO 2019 Version of CAMT Messages

Since November 2022, the new ISO 2019 version is used on the Swiss financial market for CAMT notifications. This mainly affects the account statements and notifications received from PostFinance. As of 14 November 2026, systems must fully support the ISO 2019 standard for CAMT messages. For more details, please see the PostFinance page Changes to payment transactions in Switzerland as of 14 November 2026.

The support in SwissPayment is as follows:

• camt.054 in ISO version 2019 is supported by all SwissPayment versions since 8.10 (version 8.10, October 2023).
• camt.053 in ISO version 2019 is supported from SwissPayment 8.60.
• camt.052 is not used by SwissPayment.

The switch to ISO 2019 is done by the customer in e-finance. If you import camt.053, switch only after you have updated to version 8.60. No PostFinance order and no SwissPayment setting are needed.

SwissPayment already creates pain.001 payment files in ISO version 2019 (pain.001.001.09.ch.03) since version 8.15, so no action is needed for payment files. Direct debit files (pain.008, LSV+/BDD) stay on ISO version 2009. SIX has announced no switch for them, and LSV+/BDD need no address change until they end in September 2028.

SwissPayment: Swiss Payment Standards (SPS) 2026 - Further Changes to pain.001 Files

To meet the Swiss Payment Standards (SPS) 2026, which are valid from 14 November 2026, SwissPayment includes the following changes. They are in addition to the address handling changes described in this article. For details about the standard, please see the SIX document Delta Document for the Adjustments made from SPS 2025 to SPS 2026.

Behavior changes

• More <PmtInf> blocks per file: The file now contains one block for each due date, payment type (instant payments separate from non-instant), currency and debtor account. When collective advice is used, each block has one debit.

• Instant payments: A QR-IBAN is no longer required. Two new settings are available: Instant payments: fallback to normal payment (ITP) and Instant payment limit in CHF (0 = no check).

• Schema validation: pain.001 files that are not valid against the schema are no longer written.

• ISR payments: These payments are refused before posting, because ISR has been discontinued since 30 September 2022. Use the QR-IBAN and QR reference of the creditor.

• Bank data: A foreign-currency payment to a Swiss account without IBAN needs the bank code (IID) or BIC. A cross-border payment without BIC needs the bank name, city and country from the bank master data. If this data is missing, the bank element is left out and a warning names the document. The file is still written.

• Wider character set: Characters such as ø, å, Œ, Š, ł and € are now kept in the file. Before, they were replaced with a space or with the entry from your replacement table (@SWA_PY_SPECCHARS).

• Several payment methods: If the file of one payment method cannot be created, the files of the other payment methods are still written. The errors are shown together.

We recommend updating to version 8.60 before 14 November 2026.

SwissPayment: Address Handling in pain.001 Payment Files

To meet the Swiss Payment Standards (SPS) 2026 address requirement, SwissPayment changes how addresses are written in pain.001 payment files.

Behavior changes

• The country of the default pay-to address is now checked before posting. The check starts on 14 November 2026 (see below).

• The debtor now gets a structured address, taken from the company details.

• If an address cannot be written, it is left out. Previously, an empty <PstlAdr/> element could be created.

• Address values that are too long are cropped, and a warning is shown.

• The creditor address can be written as a hybrid address (see below). By default, this is off.

ISO Country Code Check (from 14 November 2026)

From 14 November 2026, the Payment Wizard refuses pain.001 lines if the default (pay-to) address of the business partner has no ISO country code (2 letters). This check is in addition to the existing ZIP/city check.

Until that date, the address is written without the country element (as in 8.50), and a warning that names the document is shown when the file is created. From 14 November 2026, banks can reject such payments.

Before you upgrade, please complete the missing data for your vendors. You can find the affected vendors with one of these queries:

MSSQL

SELECT "CardCode", "CardName", "City", "Country" FROM "OCRD"
WHERE "CardType" = 'S' AND (COALESCE("City", '') = '' 
OR LEN(COALESCE("Country", '')) <> 2)

HANA

SELECT "CardCode", "CardName", "City", "Country" FROM "OCRD"
WHERE "CardType" = 'S' AND (COALESCE("City", '') = '' 
OR LENGTH(COALESCE("Country", '')) <> 2)

Note: A missing ZIP code also refuses the line. The queries above do not check the ZIP code.

Hybrid Creditor Address

The creditor address is structured (street, building number, ZIP, city, country). If the setting Hybrid creditor address (pain.001) is enabled in the Payment Wizard settings, and the default pay-to address has Address Name 2, Address Name 3 or Block filled, these fields are written as address lines. The supplement comes first, then street and number. The fields Building/Floor/Room are not used. By default, this setting is off.

SwissPayment: Import of Incoming Payments for Invoices with Instalments

Invoices with instalment payment terms are now handled correctly when incoming payments are imported:

• Assignment: The paid amount is spread over the open instalments, starting with the oldest due date. The import creates one payment line per instalment. Nothing is posted on account any more.

• Line colors: The color shows how the payment compares with the open balance of the invoice:

  • Green: The whole open balance is paid.

  • Orange: Less than the open balance is paid. If the amount covers only part of an instalment, it is a partial payment of the oldest open instalment.

  • Red: The amount is higher than the open balance. The message "Amount higher than the open instalments -> record manually!" is shown, and you must record the payment manually.

• Posting: The instalments are read again at posting. If a file contains several payments of the same invoice, they are assigned one after the other.

• Duplicate payment lines: A duplicate payment line is also spread over the instalments, so it is never posted without an instalment assignment. When the balance is already paid, the line is refused.

• Currency: The currency of the open instalment amounts comes from the instalment itself (the same rule as in the Payment Wizard). This way, the import and the posting always count the same.

• No tolerance: For documents with instalment terms, there is no tolerance for small differences. A full payment that is a few cents short is treated as an instalment payment. A payment that is a few cents too high must be recorded manually.

SwissPayment: Further Behavior Changes in the Payment Wizard

• File names: 
  The default file name is {PaymentMethod}_pain001_{yyyyMMdd}_{Currency}_{Run}.xml. 
  For direct debits, the name contains pain008 instead of pain001. EBICS clients pick up files by message type. If you use scripts or folder rules for the old names, please adjust them.

• QR-IBAN without QR reference: These lines are always refused before posting ("QR reference missing"). The setting Allow non-ISR QR payments is no longer used and was removed from the settings form.

• Creditor IBAN: An IBAN stored in the account number field of a business partner's bank account is now recognized. A Swiss or Liechtenstein account without an IBAN, paid in CHF or EUR, is refused ("Creditor IBAN missing").

• Debtor account currency: The debtor account currency in pain.001 now comes from the G/L account of the house bank account.

• Inactive business partners: Documents of inactive or on-hold business partners no longer appear in the Payment Wizard.

SwissPayment: New Payment Wizard Functions and Improvements

• Refund of credit notes: In an incoming run, credit notes that are higher than the invoices are paid back with an outgoing payment. 
  A new setting, Payment method for refunds (A/R credit notes) in the swissPayment configuration defines the payment method.
  

• Partial posting: The unpaid lines of a partly posted saved run can be moved into a new payment run.

• Refresh selected: The new button reads the ticked lines again from their documents. This is also done on Save, Book and Create File. Documents that were paid, cancelled or blocked in the meantime are removed.

• Collapse all / Expand all: A new button collapses or expands all groups in the grid.

• Performance improvements: The grid, Save and Create File are faster. The freeze when sorting or deleting lines is fixed.