Skip to Content
Technical Articles

Swiss QR Bill – Simplified way of printing a Compliant QR Bill SD Invoice

Starting June 2020, it would be legally required in Switzerland to generate a QR Bill payment part for all outgoing invoices. SAP will be delivering a standard localization solution to generate via SAP note 2874819. The solution will enable you to generate a legally compliant print out adhering to the style guide published in the Swiss payment standard website

https://www.paymentstandards.ch/en/shared/news/2019/qrr-style.html

 

This blog post would be helpful if you are not directly using the SAP standard solution and doing a custom implementation for QR Bill Invoice printing.

 

As a part of the standard solution SAP has delivered certain templates and routines and I will explain the end to end process for handling the QR Bill invoice printing.  Based on your requirement, you can decide to simplify the custom implementation activities based on the recommendations below.

 

Step 1 : Creation of the Form Template.

 

A Form template should be created which would be used for printing the Billing Document. The Data provider(Interface/XFA2 Gateway Service) to the Form template should contain 2 primary parts

  • Invoice Information: This is the basic Billing Document header/Item information along with the associated Material and Customer Master Data information and certain pricing information. With QR Bill there wouldn’t be a change to this part compared to the prior ISR invoice and mechanism  to fetch the information from the Billing document could be reused from ISR invoice for  QR Invoice printing.

 

  • QR Bill Payment part: This consists of following components
    • Account / Payable to: In this section the account of the payee and its address is shown.
    • Reference: Here we can see either a 27 digit QR-Reference or a 25 digit ISO 11649 Creditor reference.
    •  Additional Information: Consists of unstructured information and structured information, the so-called SWICO tags.
    • Payable by: Contains the address of the payer
    • Swiss QR Code with  the embedded Swiss Cross at the center.
    • Control Data parameters from T049Q for dynamic layout adjustments
    • SAP has delivered routines to fetch the QR Bill payment information corresponding to the SD invoice. This could be directly reused(or Logic can be referred to) in the Form Data Provider

SAP has delivered a Form interface(details in Note 2874819) as well as OData Gateway Service as Form Data Providers, which could be copied/reused/referred to when creating your own Form Data Provider.

 

From a Layout point of view, QR Bill Style guide explains different ways/formats/languages in which the QR Bill could be printed.

  • Languages :SAP supports the printing of QR Bill Invoice in German/French/English/Italian, and mandatory headings in different languages are automatically adapted in the language you want to print the form. To achieve this, the headings in the layout should be made dynamic and SAP has delivered interface with legal headings in different languages “IF_CL_QRBILL_UTIL_XX” where XX is the language key and could be DE/FR/IT/EN

 

  • Formats :  In the SAP delivered configuration for QR Bill Control you can choose the following
    • PDF output form with scissors/separated lines: means that the payment part of the invoice is separated with the scissors icon or with a separation line from the actual invoice data in the PDF output.
    • Integrated QR-Bill A4: means that the QR-bill is part of the invoice.
    • Separated QR-Bill A5: means that the QR-bill is generated separately and is not part of the invoice.
    • Amount formatting is dynamically done based on the control data configuration

 

To achieve this, certain control parameters needs to be added in the Form Data Provider to dynamically adjust the layout. This logic for such dynamic adjustment based on configuration should be done at the layout script level. Reference can be taken from SAP delivered standard forms

 

 

Step 2 : Configuration Of Output Management

  • NAST Output Management

 

    • Prerequisite is have the form template as explained in the Step 1 ready. Additionally a print driver program would be required. Print program should perform the following
      1. Get the Invoice information to be mapped to in the interface. As explained in Step 1, the existing solution for ISR invoice print program can be reused for the QR Bill print program, as the changes are only related with the payment part.
      2. Get The QR Bill payment part to be mapped in the Form interface. QR Bill payment part should be structured in the same way as SAP standard form interface, then the routines explained in the note 2874819  can be reused for getting the QR Bill Payment part data.
      3. Perform the standard print processing technical flow, where you open the print jobs and finally call the Function module corresponding to your Form template sending the information extracted in point 1 and 2.
      4. To better understand the SAP print program, The invoice/ payment part information fetching have separate “GET” routines and print processing is done in separate routine.

 

    • A sample Output management config via transaction code NACE is shown below
      • Create a new output type for Billing Area (V3)

      • Assign the newly created Form Template and the print driver program in the Processing routine section of the output type

  • Maintain condition record for the newly created output type, for a Specific Business Partner/BillingType/Sales Org combination based on your requirement.

 

      • When creating a invoice, an output item is created as with the specified medium/language and Form template in the NACE configuration

  • New Output Management in S/4 HANA On-Prem

 

    • Unlike the legacy NAST based output management,  APOC based output management wouldn’t require a print program, if you have created a Gateway Service based form.
    • The Structure of your FDP (The skeleton) should be defined as Entity/Entity Sets in your gateway Service.
    • For the Invoice information, redefinition from the Core SD Service  “FDP_V3_BD_STANDARD” is recommended
    • For the QR Bill Payment part, you would need to create new Entity sets, as shown in the section above ( Highlighted part) and the logic to fetch the QR Bill payment part information should be written in the generated DPC extension class. Here you can reuse the SAP delivered routines explained in the note 2874819 to fetch the information
    • You would need to maintain the Output Control Configurations via IMG path “Cross-Application Components -> Output Control

    • You can create new Output Types under Application Object Type “Billing Document”

    • In the Business  Rule for Output Parameter determination (Tcode OPD) you can assign the newly created Form Template, to a Billing Type

 

    • In the configuration “Assign Form Templates”, you would need to assign the Form template to your newly created Billing Type. Please note, with the new output management, you can also use a interface based form explained in the “NAST output Management Section” for which you would need a Print driver program. If you want to use a interface based form, then all the steps in the earlier section needs to be followed.

 

    • When creating a invoice, an output item is created as with the specified medium/language and Form template in the Output Control configurations

 

When the Output is triggered,( i.e, the created output item is completely processed) can also be configured. Generally, this should be done when the SD Billing Document is release to FI.

 

This is an overview of the end to end process and development cycle to generate a compliant QR Bill Invoice.

 

2 Comments
You must be Logged on to comment or reply to a post.
  • Very nice and informative document. It’s good to know a legal requirement which I believe, I also would need to implement soon in my company. I also like SAP approach to provide standard solutions only applicable for new output management which was committed at the beginning for new output management.

    I would be interested to know about gateway based Adobe forms if we can use it for a custom adobe form.

    Do we always need to refer a standard form if we want to use odata based forms?

    • Hi Prabhjot,

       

      You could create custom adobe form (layout ) reusing the SAP delivered Gateway Service as form data provider. This is the approach, most customers use in S/4 HANA Cloud and On Premise.

      You could always refer to the standard form, just to reuse the same form layout elements, to avoid any issues when using the SAP delivered gateway Service.

       

      Kind Regards,

      Raghavendra