SAP Assurance and Compliance Software Release 1.2 SP04

Transcription

1 Extensibility Guide Document Version: SAP Assurance and Compliance Software Release 1.2 SP04 SAP Tax Compliance

2 Typographic Conventions Type Style Example Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Textual cross-references to other documents. Example EXAMPLE Example Example <Example> Emphasized words or expressions. Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. EXAM PLE Keys on the keyboard, for example, F2 or EN TER SAP SE or an SAP affiliate company. All rights reserved. Typographic Conventions

3 Document History Version Date Change Initial version Document History 2016 SAP SE or an SAP affiliate company. All rights reserved. 3

4 Contents 1 Introduction Overview of SAP Tax Compliance and SAP Tax Compliance for S/4HANA Purpose of This Document Prerequisites Overview of Required Steps Data Modeling and Replication Options for Data Replication Identifying Tables to Replicate to SAP Tax Compliance SAP HANA Privileges for Schema Access Multiple Source Systems Worklist Types Field Settings Definition of Source Domains Compliance Check Views Compliance Checks Compliance Scenarios Navigation Targets Investigation Object Types and Alert Settings Authorizations SAP Fiori Launchpad Settings Appendix Support for Multiple Source Systems Data Storage and SAP HANA Modeling Business System in SAP Tax Compliance Additional Information About Worklist Types SAP SE or an SAP affiliate company. All rights reserved. Contents

5 1 Introduction 1.1 Overview of SAP Tax Compliance and SAP Tax Compliance for S/4HANA SAP Tax Compliance is a solution delivered as part of SAP Assurance and Compliance Software (software components SAPFRA and UIACS). It offers an end-to-end process to support tax compliance, including the following: A central repository for compliance checks. A compliance check is a rule for identifying compliance issues. Definition of compliance scenarios, for running compliance checks. Scenarios can be scheduled for automatic detection of compliance issues Support for mitigating identified issues and logging and reporting of actions taken. Note SAP Tax Compliance for S/4HANA has the same functional scope and is designed for installation as an add-on to an on-premise SAP S/4HANA system. Within this document, all statements are valid for both solutions unless differences are mentioned. 1.2 Purpose of This Document SAP Tax Compliance is designed to work with different data models and source applications. Data from both SAP applications and non-sap applications can be analyzed. Also the compliance check rules to identify tax compliance issues are freely definable. Several development and configuration steps are necessary to enable SAP Tax Compliance to work with a given set of source applications and to introduce the customer specific rules. This document provides a detailed explanation of the required steps. 1.3 Prerequisites The following prerequisites need to be fulfilled: You have developed a business concept for the tax compliance check rules to be created. You have identified and made available in the system the data basis for the compliance checks. You have defined what is be checked and where the necessary data comes from (at least for an initial set of rules). In addition to the logical level of source applications (for instance, SAP ERP Financials), you have also defined the physical origin of the data (source systems). This means that the target system landscape is defined. Introduction 2016 SAP SE or an SAP affiliate company. All rights reserved. 5

6 The installation and post-installation activities have been executed successfully. See the installation guide for SAP Assurance and Compliance Software or SAP assurance and compliance for S/4HANA for a detailed description of these steps. The following additional software product is available, and you have the required knowledge to use the product: SAP HANA Studio 1.4 Overview of Required Steps The following table gives an overview of the steps which are required to configure SAP Tax Compliance. The details for each step are explained in the subsequent sections. Nr. Step Comment See Chapter 1 Identify required data and configure data replication Data replication is required if the source applications do not run on the same SAP HANA database. Not required for SAP assurance and compliance software for SAP S/4HANA. 2 2 Create worklist types This includes creating views in SAP HANA Studio. 3 Maintain field settings Field settings support a user-friendly presentation of date, time, and currency values Define semantic rules and create the corresponding SAP HANA compliance check views Check views implement the business rules. They are created in SAP HANA Studio. 5 5 Create compliance checks Compliance checks are used to make the check views available for detecting compliance problems. 6 Create compliance scenarios Compliance scenarios make collections of compliance checks runnable for detecting compliance problems. 7 Define navigation targets Implement links by which users of the application can jump to source business systems. There, the users can see the original documents that are involved in a compliance problem. 8 Configure alert processing Alerts support and document the mitigation actions for identified tax compliance issues. 9 Maintain authorizations Configure who can see and do what in the system SAP SE or an SAP affiliate company. All rights reserved. Introduction

7 10 Configure the SAP Fiori Launchpad The layout of the SAP Fiori Launchpad can be configured both globally and for individual users. 11 Introduction 2016 SAP SE or an SAP affiliate company. All rights reserved. 7

8 2 Data Modeling and Replication The data that is to be analyzed for tax compliance issues needs to be available in the same SAP HANA database in which SAP Tax Compliance is installed. If the source application is not running on the same database, then the data need to be replicated (for SAP Tax Compliance) or imported via SAP S/4HANA APIs to the SAP HANA database in which SAP Tax Compliance for S/4HANA is installed. This means that data replication is not required in the following cases: SAP Tax Compliance is deployed on the same SAP HANA database as the source application. This option is supported for instance for SAP ERP, SAP CRM, SAP BW and SAP GRC. See the Installation Guide for Assurance and Compliance Software for further details. You are using SAP Tax Compliance for S/4HANA. This solution is always deployed on the same SAP HANA database and SAP NetWeaver instance as the SAP S/4HANA installation to which the source data belong. If your goal is to set up a sandbox example for the use of SAP Tax Compliance, then you can avoid the need for data replication by choosing tables from the ABAP Dictionary of the SAP Tax Compliance system itself as the basis for rules, for instance a Z table created for this purpose. You can also manually upload some data into your own schema in SAP HANA SAP SE or an SAP affiliate company. All rights reserved. Data Modeling and Replication

9 2.1 Options for Data Replication Several options exist for replicating data from different sources to SAP HANA. In principle, all of them can be used to provide data to SAP Tax Compliance. Note, however, that data replication is not supported for SAP Tax Compliance for SAP S/4HANA. You will find an overview of the available techniques in the SAP HANA Master Guide in section SAP HANA Data Provisioning (SAP HANA Master Guide). Although all of these techniques can be used, the following is recommended: The first choice to replicate data from other SAP applications (except SAP BW) to SAP Tax Compliance is the SAP Landscape Transformation Replication Server: Figure 1 - SAP Landscape Transformation Replication Server For more information see the installation guide and Trigger-Based Data Replication Using SAP Landscape Transformation Replication Server Note that the SAP LT Replication Server can be installed in the SAP Tax Compliance system, even for the deployment option "SAP LT Replication Server as a separate system", as described in the above document. Data Modeling and Replication 2016 SAP SE or an SAP affiliate company. All rights reserved. 9

10 The first choice to replicate data from non-sap applications is SAP HANA smart data integration: Figure 2 - SAP HANA Smart Data Integration For more information see: SAP HANA Smart Data Integration. 2.2.Identifying Tables to Replicate to SAP Tax Compliance When you set up data replication, you need to identify the tables from the source application that are to be replicated. This section provides some guidelines to help you identify the types of tables that you must replicate. These guidelines supplement the in-depth knowledge that you will need of the application that is the source of the data. Note The guidelines below are useful for identifying the data basis you need in SAP Tax Compliance for SAP S/4HANA as well. Note, however, that data replication is not supported for SAP Tax Compliance for SAP S/4HANA. Data Basis for Rules to Identify Tax Compliance Issues: Start with the business definitions of your tax compliance rules. Determine which tables and fields are required as the data basis for these rules. In addition to transaction data (for instance, accounting documents), also take into account master data, such as vendor and address data, customizing information like posting keys and factory calendars and auxiliary data such as currency exchange rates. Value Tables and Text Tables: The transaction data and master data used for rules frequently contain codes such as company code, account type, etc. for which value tables and text tables exist. The contents of these value tables and text tables may not be needed for rules, but they can be used for value helps and for SAP SE or an SAP affiliate company. All rights reserved. Data Modeling and Replication

11 displaying texts in object details. Therefore, also include value tables and text tables in replication if this information can improve usability (see also section 4 - Field Settings). Example A tax compliance rule is to analyze data from vendor invoices in SAP ERP. The transactional data are stored in tables BSEG and BKPF. Therefore, these tables need to be replicated. Additionally, the rule makes use of the vendor master data in table LFA1 and of the exact configuration of posting keys in table TBSL. These tables also need to be replicated. For display purposes, the invoice amounts are to be converted to a common currency. To enable this currency conversion, also replicate table TCURR. Users shall be able to define filters for the data to be analyzed based on company codes (T001) and document types (T003 with text table T003T). To support value helps for these filters, these value tables and text tables also need to be replicated. Figure 3 - Example for Tables to Replicate Data Modeling and Replication 2016 SAP SE or an SAP affiliate company. All rights reserved. 11

12 Note that it is not required to replicate all context information about the analyzed objects that a user may want to see to understand the results. This often can be replaced by navigation to the source application (see section 8 - Navigation Targets). To keep the replication process simple, by default tables are replicated with the same table names and field names as in the source application. Tables are also replicated completely (all fields, all records). Consider replicating only part of the data in a table only if replicating the whole table would lead to a large data volume of which only a small part is actually needed. We recommend that you create replicated tables in SAP HANA as column-based tables. Not all features of SAP HANA are available for row based tables. 2.3 SAP HANA Privileges for Schema Access If data are stored in a customer-defined schema, then the following privileges need to be granted in SAP HANA: Grant full privileges for the schema to user _SYS_REPO. Grant SELECT privileges for the schema to the SAP HANA user of the ABAP application server (usually called SAP<system>). See also the Installation Guide of SAP Assurance and Compliance Software. 2.4 Multiple Source Systems Special considerations are necessary if data are replicated from different source systems. These are explained in detail in section Support for Multiple Source Systems SAP SE or an SAP affiliate company. All rights reserved. Data Modeling and Replication

13 3 Worklist Types This section explains what a worklist type is and what it is used for. Additionally, we explain the objects and relationships that are shown in the following figure. This background should help you to model and to create worklist types and compliance checks. 1 <Application Data> Compliance Check * * <HANA View> Compliance Check View Colums are a subset Writes into <Dictionary Table> Data Table of Worklist Type 1 <Customizing> Worklist Type Possible Access <HANA View> Worklist Type View Application Data Customizing SAP HANA Figure 4 - Overview: HANA, Customizing and Application Data Worklist Types 2016 SAP SE or an SAP affiliate company. All rights reserved. 13

14 A worklist type consists of the following attributes: An SAP HANA view, referred to as worklist type view. The view must be either a calculation view (recommended) or an attribute view created in the SAP HANA Studio. It is used to count the number of analyzed objects. Selection fields, for selecting the data to be analyzed The source domain. The meaning and usage of a source domain is explained in section Definition of Source Domains. The source domain is optional. An optional access group. The access group is explained in section 10 - Authorizations. An investigation object type. This is needed if you want to create alerts for compliance check hits. Details are explained in section 9 - Investigation Object Types and Alert Settings. A navigation group. This is needed if you want to jump from compliance check hits to other objects, such as source documents. Details are explained in section 8 - Navigation Targets. All attributes, except the SAP HANA view and the selection fields, are optional. All are explained in different sections of this guide. The main focus here is to describe the meaning of the worklist type view. In the system, you must create a worklist type before you can create compliance checks because every compliance check uses exactly one worklist type. The worklist type and the compliance checks that use it share a common data basis. You should therefore try to model at least some of your compliance checks along with the worklist type. In this way, you can ensure that the worklist type view meets the data requirements of your compliance checks. It may help to think of the worklist type as a data object that you wish to examine for compliance problems. The compliance checks that use the worklist type examine the data that is provided by the worklist type. The compliance checks and the worklist type must fit together, the type defining a data model, the checks examining the model. The compliance checks are then small parts of the software which analyze special aspects of the underlying objects to find discrepancies and which return the data you want to see in SAP Tax Compliance. If you find that two of your compliance checks return different data and if the checks have little or no overlap in their data models, then this is a sure sign that you need to define an additional worklist type. The new worklist type provides the data basis needed by the divergent compliance check or checks. Example If you analyze accounting documents, you will probably also need to analyze data of vendors related to accounting documents. The compliance checks that you define cover two types of data, vendors and accounting documents. However, the compliance checks still belong to the worklist type for accounting documents, because what they return as a compliance problem is an accounting document and maybe some related attributes. If the starting point for the compliance checks is the vendor itself, however, and you are not involving the accounting documents, you will need a different worklist type for the vendor because these compliance checks will return data of a vendor and related attributes. Once you have modeled the worklist types that you need, and the compliance checks that are to use the worklist type, then you can start to create these objects in the system. The Worklist Type View The technical purpose of a worklist type is to provide a common basis for all compliance checks built on top. A SAP HANA view provides this common data basis. You assign this worklist type view to a worklist type. The view that you create must do the following: SAP SE or an SAP affiliate company. All rights reserved. Worklist Types

15 The worklist type view: Defines the superset of fields, Defines the field properties, Is used to count the number of analyzed objects, should provide the data basis for each compliance check view that references the worklist type. The worklist type view is not used directly by the compliance checks. Rather, it is shared by the checks that use worklist type. Each compliance check has its own SAP HANA view (referred to as a compliance check view). The worklist type view defines the superset of fields that compliance check views can examine and return as the information in a compliance check hit. Logically, compliance checks belong to a worklist type. For each field, the worklist type also defines the field properties, including the data type and possible length. If you don t overwrite this information in the field settings in Customizing, then field properties of the view are valid for the hits, too (see also section 4 Field Settings). Additionally, the worklist type view should be able to return the identifying fields of the data objects that are returned by the compliance checks. For example, if a worklist type represents accounting documents, then the worklist type view should return the key fields of the accounting documents. The view should also return all objects which are to be analyzed by compliance checks. The worklist type view is not required to fill all of the fields it has. But it should fill the values of the key fields so that the Tax Compliance application can count the documents to be analyzed. Each line (source business document) of a worklist type view is counted by SAP Tax Compliance for display and record-keeping. For example, if a compliance check returns 100 hits, then you would probably like to know how many data objects have been analyzed. Was it 100 hits from 1000 records, or 100 hits from records? This information cannot be returned by a compliance check view. The worklist type view, however, should be able to return this number, if the view applies same selection conditions as the compliance check. The worklist type view must contain all fields that you want to see when you take a look at the compliance check hits. The information that you see in the hits has to be sufficient to drive your further steps or to allow navigation to source documents or other data objects. Even though the worklist type view provides all of the necessary data fields, it is the responsibility of a compliance check actually to return the necessary field values, if they are needed to document compliance check hits. In summary, you can think of the worklist type view as providing the data basis for a set of compliance checks. You can imagine that this view is where you would actually start each compliance check. It is the data pool to which your compliance checks add associations, apply selection conditions and select required data of other objects to perform their search for compliance problems. Using the worklist type view in the compliance check view could be reasonable to achieve consistency between the number of objects which are analyzed (returned by the worklist type view) and the number of hits (returned by the compliance check view). Data Table of a Worklist Type The data table is the table in the ABAP Dictionary in which the hits of a compliance check are stored. Each worklist type has its own data table. All compliance checks of the same worklist type write their hits into this table. The system checks that the compliance check view is compatible with the worklist type view and with the data table. The structure of the data table has to be compatible with the worklist type view. You can check which data table is used by a worklist type using transaction FRA_WLT_MONITOR_CC. The system generates the data table automatically based on the information it has about the worklist type view. Worklist Types 2016 SAP SE or an SAP affiliate company. All rights reserved. 15

16 The data table might also help to clarify what a worklist type is: You want to create compliance checks which create hits and persist them in the database. If you need more than one table to store the hits, because different hits don t have much in common, then you have more than one worklist type. Definition of the Selection Fields The fields of the worklist type view can be defined as selection fields. These fields are then available in the definitions of compliance checks and can be filled with selection conditions. They are used as a template when a compliance check is assigned to a compliance scenario. You can set values for selection fields in a compliance scenario. These values are applied when the scenario and the compliance checks that it contains are executed. You must define at least one selection field for the temporal restriction of the compliance checks that use a worklist type. This also means that the worklist type view has to provide at least one date field or one field which represents a year (typically used to select by an organization's fiscal year). Compliance check views must support all selection fields of their worklist type SAP SE or an SAP affiliate company. All rights reserved. Worklist Types

17 4 Field Settings Optionally, you can use field settings to achieve a more user-friendly representation of data in customer-defined fields, especially in compliance check results. As described in the previous chapter, the structure of compliance results is defined by worklist types. A view in SAP HANA is assigned to each worklist type. The fields of this view are the maximum set of fields that can be shown in corresponding compliance check results. Basic field properties such as data type and length are already defined in the SAP HANA view of the worklist type. As a default, these field properties in SAP HANA are used to control the representation of field values. But you can define more detailed field properties in the Customizing activity Define Source Domain and Field Settings. The application checks for each field of the worklist type view to see whether properties have been defined for the field. Note that field names in SAP HANA are case-sensitive. Furthermore, the spelling of the field names in the database and in the field settings must match exactly. If this is not the case, the application falls back on the field properties from the worklist type view. The figure below shows how default field attributes (from the SAP HANA view) and field settings (from Customizing) are related. Figure 5 - Fields in Worklist Types (Only Most Important Properties Shown) Defining field settings will improve the representation and functionality of data fields in the following cases: Amount Fields: With the field settings, you can distinguish between amount fields and simple numerical fields You can also link an amount field to a currency field (reference field). As a result, the amount and the currency will not be displayed as two separate columns, for instance and EUR, but as a single column EUR. In addition, amounts in currencies without decimal digits or with more than two decimal digits will be represented correctly. Date and Time Fields: Date and time fields from ABAP-based applications are stored in SAP HANA as simple character fields. To achieve a representation as a date or time, it is necessary to assign the corresponding data type. Field Settings 2016 SAP SE or an SAP affiliate company. All rights reserved. 17

18 Fields With Input and Output Conversion: Many fields in ABAP-based applications are stored in the database with leading zeroes in their values. These fields are shown on the user interface and accepted as user input without leading zeroes. Suppressing leading zeroes can be achieved in compliance results by using the corresponding field settings. Either the data type Character String with only Digits or the conversion routine ALPHA can be used. Value Helps: You can assign a SAP HANA view to a field to provide value help for the field. The assignment is made in the field settings. The view reads the values and associated texts that are allowed for the field and presents them in the user interface. In the following cases explicit field settings are not necessary and would not change the appearance of values when they are presented in the user interface: Character strings without any conversion between database and user interface and without the need for a value help. Decimal fields that do not represent amounts, integer fields. The field properties that can be defined in the Customizing activity cited above are similar to the properties of fields in the ABAP Dictionary. If the source of your data is an ABAP-based application, then check the field properties in the ABAP Dictionary and transfer them to SAP Tax Compliance. For further details, please check the documentation of the Customizing activity Define Source Domain and Field Settings and the F1 documentation within this activity. Note If you maintain only a description for a field in the field settings, then this description will be shown in the user interface. However, the remaining field settings will be taken from the default SAP HANA properties, as described above. This option supports the translation of field descriptions. 4.1 Definition of Source Domains The settings for a given field name are valid within one source domain. In different source domains, the same field name can exist with different field properties. One source domain is assigned to each worklist type. The field settings of this source domain are then valid for the worklist type and the compliance checks that use the worklist type. By creating a smaller or larger number of source domains, you can balance between the constraints of avoiding redundant definitions and avoiding complex alignment of field properties: With a small number of source domains (in the extreme case, only one) the properties for each field need to be defined only once. However, in the extreme case, you have only one set of field names and properties. The same field name will always have the same attributes. To apply different attributes to, for example, an amount field, you must add a new definition under a different field name to the source domain. And, of course, the field names in SAP HANA and in the source domain must match. With a large number of source domains (in the extreme case, a different one for each worklist type) you achieve more independence between different worklist types. The same field names can be used in different worklist types independently of each other. However, you may have redundant definitions of the same field. Our recommendation is to use one source domain for each area of your business data in which field names and their attributes remain the same SAP SE or an SAP affiliate company. All rights reserved. Field Settings

19 5 Compliance Check Views Compliance check views are SAP HANA views that do the following: Apply business logic rules to your data to find particular compliance problems; and Return data items that exhibit a problem and that therefore need to be checked and corrected. As described in section 3, there are some requirements that compliance check views must fulfill. These requirements are determined by the view of the worklist type that is used by the compliance check. A compliance check view can return only fields that are also available in the worklist type view (the name and type of the field in the SAP HANA views must be identical). The following figure shows an example of a compliance check view: Figure 6 Compliance Check View (Example) The selection conditions (filters and joins) that a compliance check view applies determine the set of business data that the compliance check examines. The worklist type specifies the fields that are used as selection fields. A compliance check provides values for these selection fields in the form of selection conditions. The selection conditions restrict the data set on which the compliance check works and in turn, the number of hits (compliance problems) that the compliance check may return. Best Practices: Use the worklist type view in a compliance check view to select the set of data. Compliance Check Views 2016 SAP SE or an SAP affiliate company. All rights reserved. 19

20 Have the compliance check view return all fields of the worklist type view. Technically, the compliance check view must return only the selection fields of the worklist type. The selection fields must be returned because the compliance check can define selection conditions for them. The best practice, however, is to have your compliance check view return all fields. If the worklist type defines a selection field as the access group for content-based authorization checks, then the compliance check view should return values for this field. An empty value in this field removes authorization protection from a compliance check hit. Any user who has the authorization to display hits of a worklist type is able to see the hit. See section 10 - Authorizations for further details SAP SE or an SAP affiliate company. All rights reserved. Compliance Check Views

21 6 Compliance Checks A compliance check consists of several attributes: Check View: Responsible for finding and returning compliance check hits (compliance problems found in your business data). Already described in section 5 - Compliance Check Views. Field Control: Defines the order and the visibility of the fields of a compliance check hit when the hit is displayed. Selection Conditions: Expose the input parameters of the compliance check view. Allow setting of default values in the definition of a compliance check view and in a compliance scenario to which a check is added. Authorization Group: Can be used to control user access to and usage of compliance checks and check results. Start the SAP Fiori Launchpad and select the Manage Compliance Checks tile. Field Control The field control is applied whenever a compliance check hit is displayed, whether this is in simulation mode or in the compliance check results. You can change the order and the visibility of the fields. Note, however, that changing the order or visibility of some technical fields is restricted. Hiding a field has no influence on the running of the compliance check and the creation of the hit. If a compliance check view returns a hidden field, then the field is still persisted in the data table. The following figure shows how you can use field control to individualize the display of compliance check results by compliance check. You can individualize the display of results even if multiple compliance checks share the same compliance check view. The figure also repeats that the columns (fields) returned for display by a compliance check view must belong to the set of fields returned by the worklist type view. Compliance Checks 2016 SAP SE or an SAP affiliate company. All rights reserved. 21

22 A C <Application Data> Compliance Check 1 FieldControl <Application Data> Compliance Check 2 A E C FieldControl <Application Data> Compliance Check 3 A C D B FieldControl Application Data <HANA View> Compliance Check View 1 <HANA View> Compliance Check View 2 A C E Columns Has to be a subset of <HANA View> Worklist Type View Columns A B C D Has to be a subset of Columns For One Worklist Type SAP HANA A B C D E Figure 7 - Compliance Check - Field Control SAP SE or an SAP affiliate company. All rights reserved. Compliance Checks

23 Selection Conditions In the worklist type customizing, you specify which fields of the worklist type view can be used as selection fields. In the definition of a compliance check, you specify concrete selection conditions (input values) for these fields. This relation is depicted in the next figure. * <Application Data> Compliance Check Selection Conditions A is equal to XY B starts with A Application Data 1 <Customizing> Worklist Type A B Selection Fields Customizing 1 1 <HANA View> Compliance Check View <HANA View> Worklist Type View A B C E Has to be a subset of A B C D E Columns Columns For One Worklist Type SAP HANA Figure 8 - Compliance Check - Selection Conditions Compliance Checks 2016 SAP SE or an SAP affiliate company. All rights reserved. 23

24 7 Compliance Scenarios A compliance scenario is a collection of compliance checks. The purpose of a compliance scenario is to make the checks that it contains runnable, as a unit. The checks in a scenario can belong to any worklist type. For example, you can set up a scenario with a check for missing tax codes in an FI document together with a check for consistent VAT registration numbers in a purchase order and vendor master data. A compliance scenario executes all included checks and saves the result. Creating a Compliance Scenario Start the SAP Fiori Launchpad and select the Manage Compliance Scenarios tile. Create a scenario and assign compliance checks. For every check, selection conditions can be set, if available. Activate the scenario. Only activated scenarios can be executed. For every activated scenario an inactive version can be created. If you activate an inactive version, then the active version will become inactive. There can only be one active version of a scenario. Running a Compliance Scenario As mentioned before, only active scenarios can be executed. Start the Run Compliance Scenario tile. Alternatively, run transaction FRA_COMPL_SCEN_EXEC. In either case, enter a scenario ID to identify the scenario to run. Optionally, you can provide an external ID. This external ID is used as an ID for the application log of the scenario run. Display the log with transaction FRA_COMPL_SCEN_EXLOG. Deleting a Compliance Scenario You can delete compliance scenarios with transaction FRA_DEL_COSCEN. Note that scenarios that have been executed cannot be deleted. Deletion is not allowed even if a scenario did not produce any results when it ran. Compliance Scenario Results The results of a compliance scenario run can be analyzed using the My Compliance Check Results tile. This app displays all results of all scenario that runs the user is allowed to see. The results are grouped by scenario SAP SE or an SAP affiliate company. All rights reserved. Compliance Scenarios

25 8 Navigation Targets The navigation targets feature lets you define links from an item in the check results to your business data, whether the data is locally or remotely available. You can define a navigation target, for example, to let users jump from a check result item to the underlying invoice document to which the check item refers. The result of a compliance scenario run is basically a list of hits that represent for example compliance problems in accounting documents. It is possible to navigate from the hit list (as defined ultimately by the worklist type) to an application that shows you the details of a certain accounting document. Example You have run a validation on accounting documents that had been uploaded from a different system (not the one SAP Tax Compliance is running on). You can define a navigation target to let users navigate to that source system in order to display the accounting document. There are two ways to define a navigation target: You can use semantic objects to define a target. This is the preferred method for SAP Fiori targets. You can use application aliases to define a target. This is the method for non-sap Fiori targets. A navigation target can be defined in the Customizing under the following path: SAP Tax Compliance Basic Settings SAP Fiori Launchpad Designer (semantic object method) or using the transaction LPD_CUST (application alias method). After a navigation target has been created it must be assigned to a navigation group. Do this in Customizing activity: SAP Tax Compliance Basic Settings Assign Navigation Targets to Navigation Groups. The navigation group, in turn, must be assigned to a worklist type (which corresponds to the hit list of a compliance check). Do this in this Customizing activity: SAP Tax Compliance Basic Settings Maintain Worklist Types for Compliance Checks. For more information, see the documentation for the Customizing activities SAP Fiori Launchpad Designer and Assign Navigation Targets to Navigation Groups. This online documentation also offers links to additional documentation in the SAP Help Portal. For every navigation target, a mapping between the source and target fields must be established. Source fields are the fields from the corresponding worklist type view. Target fields are the fields, for example, key fields, in the source business system. Navigation Targets 2016 SAP SE or an SAP affiliate company. All rights reserved. 25

26 9 Investigation Object Types and Alert Settings In order to trace a compliance issue and to document actions and decisions, you can create a manual alert from an item in the results list. To create alerts, follow the steps below. Note that these steps are also documented in the configuration guide and may already have been performed for you: Define a number range for alerts. Maintain an application currency (all amounts of the alert will be converted to this currency). Define at least one investigation reason. Define at least one investigation-close reason and assign it to a context (see the documentation of the Customizing activity under this path: SAP Tax Compliance Alert Processing Alert Settings Assign Close Reasons to Context). Define an investigation object type (this is the basis of an alert). There is no need for a detection object type. Note that an investigation object type can only be assigned to a worklist type if the key fields of the investigation object type are also contained in the fields provided by the worklist type view. For more information see the Customizing documentation under SAP Tax Compliance Alert Settings SAP SE or an SAP affiliate company. All rights reserved. Investigation Object Types and Alert Settings

27 10 Authorizations The authorization concept for compliance checks and compliance scenarios is based on three authorization objects: FRA_WL_VAR Checked when compliance checks are accessed or results for them are created. FRA_COSCEN Checked when compliance scenarios or compliance check results are accessed. FRA_WLIST Checked when compliance check hits are accessed. Compliance checks are secured by the authorization object FRA_WL_VAR. You can set up different privileges depending on the worklist type which is assigned to compliance checks. Additionally, you can enter an authorization group for a compliance check and use its value to distinguish even further the privileges of the users. You can assign optional authorization group names to compliance scenarios. This group name is checked against user authorizations for FRA_COSCEN to govern access to scenarios. You define the authorization groups for compliance checks and compliance scenarios in Customizing under SAP Tax Compliance Define Authorization Groups. Compliance check hits belong to a worklist type. Access to compliance check hits (results) can be controlled by setting an access group for the worklist type. You can use the access group of a worklist type to set the privileges of the users using the authorization object FRA_WLIST and its field FRA_WL_GRP. Activity-Based View on Authorization Checks In addition to the straightforward authorization checks for creating, changing and displaying compliance checks or compliance scenarios, there are some special authorization activities (ACTVT field in authorization objects) that are not self-explanatory. These special activities are explained in the table below. Table 1 - Required Authorizations for Tax Compliance Activities Authorization FRA_WL_VAR FRA_COSCEN FRA_WLIST Object Activity Create Compliance Check 01 + worklist type + authorization group Create Compliance Scenario Activate Compliance Scenario Run Compliance Scenario 03 (read access to compliance check required) + authorization group 01 + authorization group 63 + authorization group 03 (read access required) + authorization group; 16 (execute) + authorization group Authorizations 2016 SAP SE or an SAP affiliate company. All rights reserved. 27

28 Display Compliance Check Results (Runs) Display Compliance Check Results (Executed Checks) Display Compliance Check Hits Display Status and Change Status on Level of Compliance Scenario Run Display Status and Change Status on Level of Executed Compliance Check Change Status/Conclusion of Compliance Check Hit 28 + authorization group 03 Depending on what the user is allowed to see, the hit completion and, if not already set explicitly, the status of the run is calculated 28 + authorization group 03 Depending on what the user is allowed to see, the hit completion and, if not already set explicitly, the status of the executed check is calculated 28 + authorization group 03 + Worklist Type + Access Group A3 + authorization group A3 + authorization group 02 + access group The instance-based authority check for the compliance checks and compliance scenarios is depicted below SAP SE or an SAP affiliate company. All rights reserved. Authorizations

29 The instance-based authorization check for the compliance check hits is depicted below. Best practice recommendation: Use the company code or similar business attribute as access groups for compliance check hits. The delivered roles for tax compliance are: SAP_TC_ADMIN - SAP Tax Compliance: Admin Role SAP_TC_BASIS - SAP Tax Compliance: Basis Role SAP_TC_RISK_MANAGER - SAP Tax Compliance: Risk Manager SAP_TC_VAT_MANAGER - SAP Tax Compliance: VAT Manager SAP_BR_ACS_TC_RISK_MANAGER - Tax Compliance Risk Manager SAP_BR_ACS_TC_VAT_MANAGER - Tax Compliance VAT Manager Other required settings regarding authorization which are necessary to use SAP Tax Compliance, but which don t explicitly correspond to the three mentioned authorization objects, can be found in the Security Guide for SAP Assurance and Compliance Software. Authorizations 2016 SAP SE or an SAP affiliate company. All rights reserved. 29

30 11 SAP Fiori Launchpad Settings The SAP Fiori Launchpad is configured for users on different levels: As a default, every user has those Fiori apps (tiles) available for which he or she has an entry of the type SAP Fiori Tile Catalog in the Menu section of the assigned role: Note Note: This assignment is not an authorization check. A user will still be able to start the Fiori app by entering the corresponding URL into the browser, even though it is not assigned to his or her role. Authorizations are managed in the backend of the application as described in chapter 10 - Authorizations. Also by default, the tiles are organized into groups. For these groups, there is an entry of the type SAP Fiori Tile Group in the Menu section of the assigned role: The groups themselves are configured in the SAP Fiori Launchpad Designer, which can be started from the Customizing under the following path: SAP Tax Compliance Basic Settings SAP Fiori Launchpad Designer (Cross-Client/Current Client) SAP delivers standard groups and the predefined roles SAP_BR_ACS_TC_RISK_MANAGER and SAP_BR_ACS_TC_VAT_MANAGER, which can be used as templates for custom roles SAP SE or an SAP affiliate company. All rights reserved. SAP Fiori Launchpad Settings

31 Each user can rearrange the SAP Fiori Launchpad, create additional groups, etc., by using the option Edit Home Page within the personal area of the SAP Fiori Launchpad: You can create additional tiles in the following ways: o Globally using the SAP Fiori Launchpad Designer. You can use this for example to start an SAP Fiori app with defined display or filter settings. o Individually using the option Save as Tile (if this option is supported by the corresponding application). Note Note: If you are using a separate frontend server on which the SAP Fiori Launchpad runs, these settings, including the user roles, have to be maintained for this frontend server. For more information, see the following documentation: To add tiles and groups to the SAP Fiori Launchpad, see Using the Launchpad Designer at this URL: tm?original_fqdn=help.sap.de For best practices about adding tiles and apps to the SAP Fiori Launchpad, see Best Practices for Setting Up Content at this URL: m SAP Fiori Launchpad Settings 2016 SAP SE or an SAP affiliate company. All rights reserved. 31

32 12 Appendix 12.1 Support for Multiple Source Systems If source data for SAP Tax Compliance come from different source systems, then first determine whether the source systems are providing the same or divergent types of business objects for checking: Different Applications/Business Objects in Different Systems: It is of course possible that SAP Tax Compliance uses data from different applications or business objects that run in different systems. For instance, accounting data could be replicated from one system and logistics data from another system. This case is uncritical, since the data are replicated separately. They are either used independently within SAP Tax Compliance, or any relations are evaluated within the SAP HANA content, for instance in compliance check views. Same Business Objects in Different Systems: In this case, data that describe the same type of business object are replicated from multiple source systems. For instance, each subsidiary runs a separate SAP ERP Financials system. The accounting documents (tables BKPF and BSEG) from all these systems are to be evaluated in SAP Tax Compliance. The expectation in such cases is that a rule (compliance check) needs to be created only once and can be used for data from all source systems. This case needs a special approach that is described in this section Data Storage and SAP HANA Modeling SAP recommends the following approach: Create a separate replication schema for each physical source system. Replicate the required tables from source systems 1:1 into tables in the corresponding replication schema. Create two layers of SAP HANA views for the data access: o System-Specific Layer: In this layer, one view reads from tables within one schema only. If necessary, these views can perform joins between different tables of the schema. Additionally, the views add a field that identifies the source of the data ( Business System, see below). o Cross-System Layer: The views of this layer mainly perform a union between all system specific views of the same semantics. They include the field to identify the source of the data, passing on the value provided by the system-specific views. The SAP HANA views that are assigned to worklist types should belong to the cross system layer. In this way, they provide a unique, harmonized access to all relevant data. The check logic within any compliance check views that use these worklist type views exists only once and is independent of the origin of the data. Either in the system-specific layer or latest in the cross-system layer, also any differences between the data models of the source systems can be harmonized (for instance, extensions that do not exist in all systems). The figure below shows how this cross-system organization of data and views might appear SAP SE or an SAP affiliate company. All rights reserved. Appendix

33 Tax Compliance Direct Access e.g. for Value Help Compliance Check Execution HANA Compliance Check Layer CA_DOCUMENT_ITEM_WITHOUT_TAX_CODE Business Systems: ERP1_001, ERP1_002, ERP2_100 Cross System Data Access Layer CA_COMPANY_CODE_ALL Business Systems: ERP1_001, ERP1_002, ERP2_100 CA_DOCUMENT_ITEM_ALL Business Systems: ERP1_001, ERP1_002, ERP2_100 System Specific Data Access Layer CA_COMPANY_CODE_ERP1 Business Systems: ERP1_001, ERP1_002 CA_DOCUMENT_ITEM_ERP1 Business Systems: ERP1_001, ERP1_002 CA_DOCUMENT_ITEM_ERP2 Business System: ERP2_100 CA_COMPANY_CODE_ERP2 Business System: ERP2_100 Data Storage Schema ERP System 1 Schema ERP System 2 T001 Clients: 001, 002 BSEG Clients: 001, 002 LFA1 Clients: 001, 002 BSEG Client 100 LFA1 Client 100 T001 Client Business System in SAP Tax Compliance Within SAP Tax Compliance, the business system is used to identify the source of data records. A business system should correspond to a logical source system. For instance, the different clients of SAP applications are identified with different business systems. You identify business systems to SAP Tax Compliance in the Customizing under this path: SAP Tax Compliance Basic Settings Define a Business System. Make sure that the name of the business system matches the value that is provided by the data access layer for the records that have their origin in the corresponding system or client. Example Data are replicated into SAP Tax Compliance from client 001 of system ERP. In the above Customizing activity, you create an entry for business system ERP_001. The views that read this data need to have an output field Business System and provide the value ERP_001 in this field for all records that belong to client 001. The business system is used in SAP Tax Compliance for the following purposes: To distinguish data records from different sources that otherwise have the same keys (for instance, the same document number). To identify the correct navigation target if a navigation to the source system is configured. Appendix 2016 SAP SE or an SAP affiliate company. All rights reserved. 33

34 12.2 Additional Information About Worklist Types Changes to the Worklist Type If you start with the definition of the SAP HANA view for the worklist type, then you should already planned for the data that compliance checks will analyze and which you want to see in the compliance check hits. Of course, new compliance check views for the same worklist type might return new required fields. These new fields have to be persisted in the database as well. In such a case, you have two options how to proceed: Add the new fields to the worklist type view. If it is easily possible to return values for these fields, then select them, too. As already mentioned, you don t have to return a value for each field. Even if the worklist type view will not return values for the new fields, you still must add them to the worklist type view. In the worklist type view, you fill these fields with initial values. Always check across all views that belong to the same worklist type, that each new field (with the same field name) uses the same data type. Otherwise, you will get errors in the application. Lifecycle One big difference between a worklist type and compliance checks is the fact that a worklist type is Customizing and compliance checks are application data. Usually, Customizing is not changed that often, once it has been used in the creation of application data, such as compliance checks. This holds true for worklist types and compliance checks. In a perfect scenario, you would create a worklist type once, leave it unchanged for the rest of the time. You would then create only compatible SAP HANA views for the compliance checks. Further, you would create compliance checks that use the check views over the course of time. Such a perfect scenario would require a very good worklist type design and very good anticipation of the compliance checks you would build in the future. Or you must freeze the worklist type and require that all compliance checks obey the constraints of the worklist type. As described above, there will be cases where you have to decide between the different options SAP SE or an SAP affiliate company. All rights reserved. Appendix

35

36 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. Please see sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. Material Number: