In the second part of the Q&A: customer-specific and legal form requirements, electronic invoice formats and Adobe Forms.
On 31.03.2022, our expert talk on the topic “SAPscript and Smartforms are obsolete models and need to be modernized” took place together with Helge Sanden. During and after the expert talk, you as viewers had the opportunity to ask us your questions. As we unfortunately did not have time to answer all the questions in detail during the expert talk, you can read the second part of the most important questions and answers below.
Softway: With our SSP Forms product, you have the option of outputting differentiated content on forms down to customer number level, for example. Our customizing interface makes it possible to keep track of which determination logic for content and/or output applies to which customer. Various conditions can be combined, defined and checked (even without programming knowledge). We have a solution for labels, which are often required in the automotive industry (which is also embedded in our SSP Forms product).
Softway: We are and have been in contact with companies in the housing industry. To date, we have not yet used our product productively in this area. However, it is possible to implement the forms with our product. It is therefore possible to customize the forms and make them transparent. What makes us so confident here? Experience shows that almost all forms are subject to the same type of data procurement and design in Adobe and therefore do not cause any problems. There are only a few forms, such as the HCM remuneration statement, where it makes no sense to use the product.
Softway: Let’s assume that Poland or Switzerland are separate company codes or sales organizations. We would map this in our form customizing by defining the “For whom”. We would then use an area in the form for the totals table (“Where”) and place the totals table there. The associated data retrieval (“What”) would then only be called up and displayed for company code Poland. You can view our form customizing and an overview of how, where, for whom and what data SSP Forms outputs on a form view here. For QR codes or barcodes in general, it is done in a similar way: The QR code is also placed on the form and the associated data retrieval (“What”) is only called up for company code Switzerland. Everything is visible via our customizing, which ensures 100% transparency. But you probably mean the QR-bill in Switzerland. This topic is somewhat more complex than a normal barcode. Here you have to think about a separate form, because the layout is completely different from our template and normal invoices.
Softway: With the MSC product, we offer a solution for digital signatures by e-mail. We work together with the company secrypt. They are specialists in the field of digital signatures. You can find out more about our MSC product here.
Softway: If this question refers to adding (merging) additional PDF documents to an existing PDF document, this can be solved using our SSP Message Service Center solution. Further information can be found here.
Softway: We use the SSP MSC E-Invoicing solution for the creation of electronic invoices (ZUGFeRD, XRechnung, Factur-X). There you have the option of creating ZUGFeRD, XRechnung and Factur-X invoices. The determination of when which format is to be output and the mapping of SAP data to XML can be controlled here via customizing. You can find more information on our SSP MSC E-Invoicing product page.
Softway: In principle, you retrieve data in SAP (ABAP) from the underlying database and transfer this data to the ADS via XML exchange. In ABAP, you could of course also “tap into” other data sources, e.g. a web service, REST call or go to another system via RFC. The standard is to retrieve the data in SAP (e.g. from SE78 or the MIME repository). The graphic data is then transferred to the ADS in binary XML. However, you can also retrieve the image data from a web server and then transfer it to the ADS (also in ABAP). Another variant: store the graphic on the ADS and refer to it via URL. As a rule, traceability is more important. This is another reason why variant 1 is preferred. What can of course be a criterion: is a graphic output at header level, i.e. only once per document or, for example, as a product image per item? If we are at item level, the size of the image naturally plays an even greater role. It is important to ensure that the graphics are stored in the size in which they are required.
Softway: In response to your comment, we would like to mention that we also use our SSP Forms product and our solution at companies that already use Adobe Forms and notice that there is also a proliferation of forms here and that they would like to have more transparency. Here we would like to draw your attention to our customer presentation “Uncontrolled growth in forms despite Adobe Forms – does it have to be? You can access the presentation at vertrieb@softway.de free of charge.
Softway: This question is currently difficult to answer. In the public (real) cloud, there is only this solution. On-premise and in the private cloud, there are some new technical challenges. For example, the type of data procurement is changing and there is no longer a form context, i.e. you have to ensure that the address is resolved correctly in the data procurement (odata or gateway service), text content is determined and image data is procured. And all of this is hard-coded or you build your own customizing for it. With SSP Forms we have replaced the fragments with so-called layout containers. For example, the logo, header and footer texts are stored in a container. A container can be reused in several forms. This means that changes to content only have to be made in one place (in the container).
Did you miss the Expert Talk on “SAPscript and Smartforms are obsolete models and need to be modernized“?
No problem! You can easily and conveniently watch the talk here:
Stay informed: With practical insights, helpful tips and relevant developments relating to Softway AG, SAP and our output management solutions.