SAP Document Compliance solution for Greek myDATA e-books, Part 2 – central objects in customization

[former_member430552]

Mikhail Smirnov – CSL Behring, Pradyumna Kumar Mishra – SAP SE

 

Overview

The first part of this blog post series gave an overview of Greek Electronic Books (e-books) requirements, and architecture of SAP Document Compliance solution to fulfill these requirements. This part will proceed with two central customization objects (Invoice Type and eDocument Type) and logic behind them in SAP Document Compliance solution.

 

MyDATA Invoice Type mapping

Invoice Type is the main parameter introduced by AADE for myDATA e-books reporting and it is included in e-book XML structures. Invoice Type defines process or type of posting presented in e-book. Different examples of such type of postings are domestic, EU or third country sales, EU or third country purchase, respective debit or credit notes, retail bills and receipts, payroll or depreciation postings and many other kinds of postings. It means that Invoice Types defined by AADE have broader meaning than just invoices. Invoice Types are defined for every income and expense transaction subject to myDATA reporting.

A single e-book is called as eDocument (eDoc) in SAP Document Compliance solution. Every eDoc is presented with respective XML file. My DATA parameters like Invoice Type are assigned in every eDoc accordingly mapping rules predefined in SAP customization. These rules are extensive and covering every income and expense transaction, hence we have complicated logic realized in SAP. Several standard mapping tables for Invoice Types are created in SAP and they are checked in different sequence order depending on source of posting (FI, MM or SD).

 

Invoice Type (INVOICE_TYPE) determination logic in SAP follows:

2. At-first, BAdi EDOC_MAP_GR method DETERMINE_INVOICE_TYPE is called. If you don’t fill up the Invoice Type in this method, then determination happens based on next steps.


3. Reason Code (BSEG-RSTGR) is checked for all source documents in vendor and customer items:

Image 1 from CSL Behring Internal system.

If Reason Code is populated and mapped to invoice type in /N/AIF/VMAP t-code for INV_DOCUMENT_TYPE – Value Mapping parameter,  then Invoice Type is defined for eDoc in this step:

Image 2 from CSL Behring Internal system.

Originally Reason Code is used by SAP for handling payment differences, however in case of e-books it is not relevant.

If Reason Code is not populated in the posting, then SAP goes to the next step.

3. For MM invoices and FI vendor and customer invoices GL Account mapping table (EDOGRINVTYPEACC) is checked:

Image 3 from CSL Behring Internal system.

Country/Region Type stands here for the origin of the customer or vendor. Origin is checked by Country assigned in the Business Partner master record and indicator European Union Member XEGLD in the Countries master data table T005. When you post retail purchase invoice types from 13.1 to 13.31 without vendor for retail bill or receipt, then Country/Region Type should be “- Domestic” in the mapping.

For SD invoice Print Task Code (PTC) mapping table (EDOGRINVTYPEPTC) is checked:

Image 4 from CSL Behring Internal system.

PTCs are used by Greek country specific printing programs for SD and FI sales invoice.

If Invoice Type is still not determined, then SAP goes to the next step.

4. For FI customer invoices Print Task Code mapping table (EDOGRINVTYPEPTC) is checked. For SD invoice GL Account mapping table (EDOGRINVTYPEACC) is checked.

 

If SAP finds multiple GL Account mapping lines in EDOGRINVTYPEACC table in case of incoming vendor invoice, then SAP sorts selected GL Account mapping lines and first line is selected for Invoice Type determination.

If Invoice Type determination couldn´t happen during these steps, then you will get the error: “Invoice type not found for CoCd/Doc Type/Business Partner Origin Type/GL Account”.

In our Greece e-books implementation project, based on our business requirement, we decided to create additional custom mapping tables checked in between standard steps. Hence, we had to reproduce the SAP´s standard logic in the BAdi in the first step including checks of the new tables in between.

 

SAP eDocument Type mapping and eDoc creation

eDocument Type (EDOC_TYPE) is the main technical parameter defined by SAP in Greece e-books customization. It is used for creation of eDocs with different XML structures. It also defines under which folder (Process) eDoc is created in eDocument Cockpit EDOC_COCKPIT and enables correct eDoc treatment in different processes.

Main customization for eDocument Types is SM30 view T003EDOCV, where you assign Source FI Document Type to eDocument Type.

Image 5 from CSL Behring Internal system.

 

eDocument Types are determined at-first by your customization in this view, but then they can be substituted by the standard system logic. SAP has realized flexible and complex logic for eDocument Type determination, where directly assigned by you eDocument Types can be changed by SAP depending on other customizations (mapped Invoice Type, activation/deactivation of the Invoice Type for eDocument Type determination, Business Partner master record). This logic is soundly explained in PDF attachment in SAP Greece e-book master note 2930400 - SAP Document Compliance Greece: Tax Register Books (e-Books). Also, PDF contains an example how to maintain T003EDOCV view, but still there is a lot to explain about this customization. In this blog I would like to shed more light on T003EDOCV view dependencies with other processes and how it works.

Source documents are posted in different SAP modules (FI, MM, SD), but in this customization you assign only related FI document type. It means, that SD and MM documents can create eDoc, only when related FI document is created. This customization works as an activation of automatic eDoc creation during posting of assigned here FI Document. Otherwise, eDocuments can't be created. Every Source FI Document Type can be assigned in this table only one time to one eDocument Type.

However, depending on the business scenarios of your company, you still may need to use the same source FI Document Type for two different eDocument types. In this case, you can change the standard eDocument determination for the FI Document Types by implementing BAdi EDOC_ADAPTOR, method CHANGE_EDOCUMENT_TYPE. SAP suggest using ideally different FI Document Types for different types of business scenarios (eDocument Types) to avoid developments.

In T003EDOCV view you do assignment of FI Document Types used only for e-book Invoice Types from 1.1 to 16.1. These are operational postings like invoices, credit and debit memos, bills, and receipts posted always in 0L Leading Ledger. Hence, all operational postings are reported to myDATA by default from 0L Leading Ledger only and it is not changeable.

17.* Invoice Types used for expenses like Payroll and Depreciation (quite often posted also to non-leading ledger) has separate processing logic, where non-leading ledger selection is allowed during eDoc creation. Their functionality and customization is delivered in SAP Note 3003692 - GR: eBooks – eDocument Category C Types 17.1 - 17.6 Handling. FI Document Types of 17.* Invoice Types don´t need assignment in T003EDOCV view. Hence, your processes may need a rework to have a distinct split of FI Document Types between 1.1 – 16.1 and 17.* myDATA Invoice Types. Otherwise, you will have two eDocs for one posting.

However, you can implement Badi EDOC_ADAPTOR method IS_RELEVANT, if you don’t want to create eDoc activated in T003EDOCV view at certain conditions. This will prevent eDoc creation for the conditions defined in this method.

Standard solution will allow eDocument creation only for normal documents (BKPF-BSTAT = ' '). This is only valid for FI and SD sourced documents. With this SAP is restricting creation of eDocs for Parked, Recurring, Noted, etc. documents with BKPF-BSTAT <> ' '.

Not all eDocument Types need assignment in T003EDOCV view, because some of them are created not by source FI, MM or SD documents, but by other processes and programs (like Payroll 17.1 or Classification List eDoc for domestic purchase). All eDocument Types provided by SAP and their related processes and customizations is the topic for the next part of this Blog.

 

Conclusion

In this article we focused on two core objects in SAP Document Compliance customization: Invoice Type and eDocument Type. We summarized here our practical experience with pieces of information from the SAP notes mentioned above and subsequent notes with improvements. We hope it is helpful for your understanding of big picture and end-to-end process in SAP Document Compliance Greek e-books solution. Don’t hesitate to comment and share your experience and thoughts on this topic. The whole list of eDocument types for Greece and related processes and customizations are present in the Part 3