[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 - 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 - 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 - Adding Header.Custom.CompanyIdentifier Mapping

BT-29 carries an identifier assigned to the seller by a third party, such as a trade registry or industry body. We implemented this as a custom mapping field under Header.Custom.CompanyIdentifier in the ZUGFeRD Mapping table (SWA_LD_ZUGFERDMAP).

The field is blank by default and must be filled in manually, as BT-29 is not mandatory. When used, it should be combined with a GLN (Global Location Number) to ensure the identifier can be correctly resolved by the receiving system.

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 mapping is:

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.