SAP Assurance and Compliance Software Release … Assurance and Compliance Software Release 1.2 SP04 Typographic Conventions Typographic Conventions Type Style Description Example

Extensibility Guide

Document Version: 1.0 – 2016-11-21

CUSTOMER

SAP Assurance and Compliance Software Release 1.2 SP04 SAP Tax Compliance

2

CUSTOMER

© 2016 SAP SE or an SAP affiliate company. All rights reserved.

SAP Assurance and Compliance Software Release 1.2 SP04

Typographic Conventions

Typographic Conventions

Type Style Description

Example 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 Emphasized words or expressions.

EXAMPLE 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.

Example 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.

Example Exact user entry. These are words or characters that you enter in the system exactly as

they appear in the documentation.

<Example> Variable user entry. Angle brackets indicate that you replace these words and characters

with appropriate entries to make entries in the system.

EXAMPLE Keys on the keyboard, for example, F2 or ENTER .


Document History

CUSTOMER

© 2016 SAP SE or an SAP affiliate company. All rights reserved. 3

Document History

Version Date Change

1.0 2016-11-21 Initial version

4

CUSTOMER



Contents

Contents

1 Introduction ................................................................................................................................... 5 1.1 Overview of SAP Tax Compliance and SAP Tax Compliance for S/4HANA .................................... 5 1.2 Purpose of This Document ................................................................................................................... 5 1.3 Prerequisites .......................................................................................................................................... 5 1.4 Overview of Required Steps ................................................................................................................. 6

2 Data Modeling and Replication ................................................................................................... 8 2.1 Options for Data Replication ................................................................................................................ 9 2.2 .Identifying Tables to Replicate to SAP Tax Compliance ................................................................. 10 2.3 SAP HANA Privileges for Schema Access .......................................................................................... 12 2.4 Multiple Source Systems ..................................................................................................................... 12

3 Worklist Types ............................................................................................................................. 13

4 Field Settings ................................................................................................................................ 17 4.1 Definition of Source Domains ..............................................................................................................18

5 Compliance Check Views ........................................................................................................... 19

6 Compliance Checks ..................................................................................................................... 21

7 Compliance Scenarios ................................................................................................................24

8 Navigation Targets ...................................................................................................................... 25

9 Investigation Object Types and Alert Settings ....................................................................... 26

10 Authorizations ............................................................................................................................. 27

11 SAP Fiori Launchpad Settings .................................................................................................. 30

12 Appendix ....................................................................................................................................... 32 12.1 Support for Multiple Source Systems ............................................................................................... 32

12.1.1 Data Storage and SAP HANA Modeling ............................................................................ 32 12.1.2 Business System in SAP Tax Compliance ........................................................................ 33

12.2 Additional Information About Worklist Types ................................................................................... 34


Introduction

CUSTOMER


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.

6

CUSTOMER



Introduction

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

3 Maintain field settings Field settings support a user-friendly

presentation of date, time, and currency

values.

4

4 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

6 Create compliance scenarios Compliance scenarios make collections of

compliance checks runnable for detecting

compliance problems.

7

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

8 Configure alert processing Alerts support and document the mitigation

actions for identified tax compliance issues.

9

9 Maintain authorizations Configure who can see and do what in the

system.

10


Introduction

CUSTOMER


10 Configure the SAP Fiori Launchpad The layout of the SAP Fiori Launchpad can be

configured both globally and for individual

users.

11

8

CUSTOMER



Data Modeling and Replication

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.



CUSTOMER


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.

http://help.sap.com/hana/SAP_HANA_Master_Guide_en.pdf

http://help.sap.com/hana/SAP_HANA_Installation_Guide_Trigger_Based_Replication_SLT_en.pdf

10

CUSTOMER




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

http://help.sap.com/hana_options_eim



CUSTOMER


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

12

CUSTOMER




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 12.1 - Support for Multiple Source Systems.


Worklist Types

CUSTOMER


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.

Figure 4 - Overview: HANA, Customizing and Application Data

Ap

plic

atio

n D

ata

SA

P H

AN

AC

us

tom

izin

g

<Customizing>

Worklist Type

<Application Data>

Compliance Check

1

*

<HANA View>

Worklist Type View

<HANA View>

Compliance Check View

1

1

Possible AccessColums are

a subset

1

*

<Dictionary Table>

Data Table of Worklist Type

Writes into

1

1

14

CUSTOMER



Worklist Types

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 4.1 - 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:


Worklist Types

CUSTOMER


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 1000000 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.

16

CUSTOMER



Worklist Types

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.


Field Settings

CUSTOMER


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 “1.000” and “EUR”, but as a single column “1.000

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.

18

CUSTOMER



Field Settings

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.


Compliance Check Views

CUSTOMER


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.

20

CUSTOMER



Compliance Check Views

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.


Compliance Checks

CUSTOMER


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.

22

CUSTOMER



Compliance Checks

Figure 7 - Compliance Check - Field Control

SA

P H

AN

A

Fo

r On

e W

ork

list T

yp

e

Ap

plic

atio

n D

ata

<HANA View>

Worklist Type View

<HANA View>

Compliance Check View 1

<HANA View>

Compliance Check View 2

A

C

E

Columns

A

B

C

D

E

Columns

Has to be

a subset ofHas to be

a subset of

<Application Data>

Compliance Check 1

A

C

FieldControl

<Application Data>

Compliance Check 2

A

E

C

FieldControl

<Application Data>

Compliance Check 3

A

C

D

B

FieldControl

A

B

C

D

Columns


Compliance Checks

CUSTOMER


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.

Figure 8 - Compliance Check - Selection Conditions

SA

P H

AN

A

Fo

r On

e W

ork

list T

yp

e

Cu

sto

miz

ing

Ap

plic

atio

n D

ata

<HANA View>

Worklist Type View

<HANA View>

Compliance Check View A

B

C

E

Columns

A

B

C

D

E

Columns

Has to be

a subset of

<Application Data>

Compliance CheckA is equal to XY

B starts with A

Selection

Conditions

<Customizing>

Worklist TypeA

B

Selection

Fields

1

1

1

*

24

CUSTOMER



Compliance Scenarios

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.


Navigation Targets

CUSTOMER


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.

26

CUSTOMER



Investigation Object Types and Alert Settings

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.


Authorizations

CUSTOMER


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

Object

Activity

FRA_WL_VAR FRA_COSCEN FRA_WLIST

Create Compliance

Check

01 + worklist type +

authorization group

Create Compliance

Scenario

01 + authorization group

Activate Compliance

Scenario

63 + authorization group

Run Compliance

Scenario

03 (read access to

compliance check

required) +

authorization group

03 (read access

required) +

authorization group;

16 (execute) +

authorization group

28

CUSTOMER



Authorizations

Display Compliance

Check Results (Runs)

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

Display Compliance

Check Results (Executed

Checks)

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

Display Compliance

Check Hits

28 + authorization group 03 + Worklist Type +

Access Group

Display Status and

Change Status on Level

of Compliance Scenario

Run

A3 + authorization

group

Display Status and

Change Status on Level

of Executed Compliance

Check

A3 + authorization

group

Change

Status/Conclusion of

Compliance Check Hit

02 + access group

The instance-based authority check for the compliance checks and compliance scenarios is depicted below.


Authorizations

CUSTOMER


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.

https://uacp2.hana.ondemand.com/doc/DRAFT/8dba6b573ccd4bd6a0f3510530db7f8a/1.2.4.0/en-US/loio51e2a3fbf9ba43e5a12330f8b3c9ad31_51e2a3fbf9ba43e5a12330f8b3c9ad31.pdf

https://uacp2.hana.ondemand.com/doc/DRAFT/8dba6b573ccd4bd6a0f3510530db7f8a/1.2.4.0/en-US/loio51e2a3fbf9ba43e5a12330f8b3c9ad31_51e2a3fbf9ba43e5a12330f8b3c9ad31.pdf

30

CUSTOMER



SAP Fiori Launchpad Settings

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 Fiori Launchpad Settings

CUSTOMER


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:

https://help.sap.com/saphelp_uiaddon10/helpdata/en/cb/0ae6a170754bb9bcfa66c4c4bdcc37/content.h

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:

http://help.sap.com/saphelp_uiaddon20/helpdata/en/6c/eb3b39e4af4241acde015fece66e26/content.ht

m

https://help.sap.com/saphelp_uiaddon10/helpdata/en/cb/0ae6a170754bb9bcfa66c4c4bdcc37/content.htm?original_fqdn=help.sap.de

https://help.sap.com/saphelp_uiaddon10/helpdata/en/cb/0ae6a170754bb9bcfa66c4c4bdcc37/content.htm?original_fqdn=help.sap.de

http://help.sap.com/saphelp_uiaddon20/helpdata/en/6c/eb3b39e4af4241acde015fece66e26/content.htm

http://help.sap.com/saphelp_uiaddon20/helpdata/en/6c/eb3b39e4af4241acde015fece66e26/content.htm

32

CUSTOMER



Appendix

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.

12.1.1 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.


Appendix

CUSTOMER


12.1.2 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.

Tax Compliance

HANA

Data Storage

System Specific Data Access Layer

Cross System Data Access Layer

Compliance Check Layer

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 100

CA_COMPANY_CODE_ERP1

Business Systems:

ERP1_001, ERP1_002

CA_COMPANY_CODE_ERP2

Business System: ERP2_100

CA_DOCUMENT_ITEM_ERP1

Business Systems:

ERP1_001, ERP1_002

CA_DOCUMENT_ITEM_ERP2

Business System: ERP2_100

CA_DOCUMENT_ITEM_ALL

Business Systems:

ERP1_001, ERP1_002, ERP2_100

CA_COMPANY_CODE_ALL

Business Systems:

ERP1_001, ERP1_002, ERP2_100

CA_DOCUMENT_ITEM_WITHOUT_TAX_CODE

Business Systems:

ERP1_001, ERP1_002, ERP2_100

Compliance Check ExecutionDirect Access e.g. for Value Help

34

CUSTOMER



Appendix

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.

www.sap.com/contactsap


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 http://www.

sap.com/corporate-en/legal/copyright/index.epx#trademark for

additional trademark information and notices.

Material Number:

http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

Documents

SAP Assurance and Compliance Software Release … Assurance and Compliance Software Release 1.2 SP04 Typographic Conventions Typographic Conventions Type Style Description Example