Central Finance (CFIN) – Document Splitting & Approach to Document Dedirection

In this blog I’ll talk about one of the important sought out topic during finance transformation journey – Document Splitting function in Central finance.  The scope is limited to ‘Document split active in target system but not in source system’.

Background

In general SAP recommends to  work with a scenario in which document splitting is configured the same way in both source and target system, somehow this is not always possible. From S/4HANA 1909, because of different reasons or use cases, SAP has started supporting the scenario of document splitting as inactive in the source system and active in the Central Finance system.

The bigger question is what SAP has actually started supporting that were not there until 1809 and if  these are sufficient for a CFIN consultant to build the solution without getting into custom development. Let’s check out the challenges or reasons that trigger the flurry of replication errors, recent progress in this area and then talk about approach to custom solution.

Challenges/ Reasons for Document split replication errors

Splitting logic & configured rules are processed when documents are reposted in target from source. This leads to inbuilt validation check and subsequent error in case of non-fulfillment, few of the major reasons are:

1. When Central Finance transfers the initial balances and open items, the document splitting characteristics are not included
2. If user posts document in the source system that mixes several business transactions in one single posting, the splitter will not find an appropriate rule to apply. Although the posting was successful in the source system, it will not be posted successfully in the Central Finance system
3. If a splitting characteristic (e.g. profit center) is configured as mandatory (and balancing to zero), it needs to be supplied in the posting. However, if this characteristic is not used in the source system, the posting will not be successful.
4. Cross-company transactions between company codes with document splitting activated and company codes with document splitting not activated will lead to an error in Central Finance

SAP Enhanced Validation

1. Consistency check

From 1909, SAP has provided in its configuration consistency checks to verify the consistency of document splitting activation between the source system and Central Finance system. The following checks in the consistency check report for document splitting settings have been extended:

• Classification of G/L Accounts for Document Splitting – The item category is determined by the account number.
• Classification for Document Types for Document Splitting – Assigning business transaction variant to document types
• Document Splitting Characteristics for General Ledger Accounting – Assign account objects for splitting (e.g. profit center, segment)

2. Doc split check in Source System

In order to avoid documents being posted in the source system which would lead to potential document splitting errors in the target system, Central Finance from 2020 supports the same pre-checks in the source system as in the target system. These are processed directly during the posting of FI documents in the source system, when the split process check is activated for company code.

These are run time checks during the posting of FI documents in the source system and Consultant has an option either to define Warning or Error against those document which breach the split rule in source system. However, activating this check does not change postings on the source side.

3. Simulation of Doc split

When posting fails due to an error in the document split, you can trigger a simulation of document splitting for the document in question, by choosing Simulate Document Splitting in the error message. The fields in the Simulate Document Splitting function are then automatically filled with the values from the error message, allowing you to trigger the simulation for the document in question, without having to enter any additional information. You can access the simulation from error message either at SAP AIF or from the monitor Initial Load Data.

Custom Solution

While the above enhancements facilitate the Document split validation of records or simulation, it does not provide any standard solution to overcome split errors and ensure seamless replication in target. This leave behind the necessity for essential Custom alignment between source & target for document split augmentation.

Broadly the Custom approach can be classified into:

A. Document Redirection to deal with Document types rebelling Split rules

B. Enrichment of missing Characteristics through Badi or standard default

A. Document Redirection – Document splitting works with configured rules. These configured rules are based on the document type used for a business transaction, which requires certain level of posting discipline. Source systems that do not have document splitting active or does not have the characteristics mandatory, business users / interfaces have full freedom on how to create postings. However, the source freedom are not applicable anymore in the central system. Therefore, there are two options theoretically:

• Either introduce more discipline in the source systems which may not be possible at short span and required progressive adoption
• Based on the typology, redirect the original document type to another one in target that fits better to the posting pattern

Thus, Re-direction of document type(s) can be used during transactional data replication (in case Transanctional data was used differently in a source system and do not comply to configured split rule in target).

Step 1 – Evaluate all the FI transactions having document type not exclusively meant for posting pattern. Few Cases are discussed below:

• Document Type DR – allows for account types (ADKS – Assets, Customer, Vendor, GL) as per the document type configuration. But as per transaction/variant config for document splitting for doc type DR, customer line is mandatory.
• Doc type CC – allow for account types DS as per the document type configuration. But as per transaction/variant config for document splitting for doc type DR, customer line is mandatory.
• Doc Type RE created during MIRO transaction but does not have Vendor Line items, etc.

Doc type DR without Customer line Items

Doc type CE without Customer line items

As a result, based on the source transaction analysed, rules are to be identified to redirect transaction to a new document type.

Step 2 – Define additional document type(s) with  possible Account type to handle different CFIN business transactions/ scenarios supporting maximum redirection case. If required create New Transaction variant (copy of existing 0001) against Business Transaction say 0100 or 1010 with all the Lead Item categories to make it more permissive to handle all kind of Line item categories

Step 3 – Redirection Table Conditions:

Table Fields	Description
Pattern Prerequisite	3 Types of prerequisites for Account type pattern in next column available to be set: FA Few Applicable –  It means at least one line of the document should meet the criteria NA Not Applicable – it means none of line items contains criteria. AA All Applicable– it means all line times meets these criteria
Pattern	Account type to be specified. It can be also a combination of the account types like DK. It mean, the rule will apply for documents with Customer and Vendor line items. Pattern works based on Pattern Prerequisite. I.e. FA Contains any K would mean – document with at least 1 vendor line. DK would mean customer and vendor both should be present in the document
Pattern	Priority is always processed from the lowest to the highest. It is  advisable to set more concrete rule first.
Line Item Preq	This Represent Preq of Item category. There’re 2 possible options: FA Few Appliable– It means at least one line of the document should meet the criteria NA Not Applicable – means none of line items should contains Category specified.
Line Item Category	This Represent GL account item category. FA equal to  04000 would mean – if at least 1 line has account assigned to Cash item category. NA equal to 05100 would mean – if document has no Tax item category. Similarly you can have more Line item Preq and Category based on requirements.
New document type	Document type which should be assigned based on specified rules.

Example Condition for Document Type DR (should not be generalised):

Target Document Type	Priority	Pattern Preq	Pattern	Line Item Preq	Item Category	Linetype Condition	Item Category	New Document Type
DR	10	NA	D					Z1
DR	20	FA	D	NE	30000	FA	4000	DZ

Depending upon the identified records and Use case, you can also add more validation condition to redermine the Document type in Target. Few of the additional Validations are:

Table Fields	Description
TC Prerequisite	Represent prerequisite for next column which is Transaction code. There’re 2 possible options: EQ Equal and NE Not Equal.
Transaction Code	Transaction code to be specified. Transaction code works based on TC Prerequisite. I.e. EQ = FB01 would mean rule should be applied for documents posed with transaction code FB01. NE Not Equal FB05 would mean – Rule should be applied for documents which are posted not via FB05
Clearing Check	All documents should be checked to see if it is a clearing/ payment transaction. If it is clearing and flag is set, redirection should be allowed and vice-versa
Open Item Flag	This flag indicates if the rule is applicable for Open Items during initial Load.

Example Condition for Document Type SA (Should not be generalised; project specific):

Target Document Type

Priority

Pattern Preq

Pattern

TC Preq

Trans Code

Line Item Preq

Item Cat.

Line Item Preq

Item Cat

Line Item Preq

Item Cat

Line Item Preq

Item Cat

Line Item Preq

Item Category

Clearing Check Flag

New Document Type

SA

10

NA

DK

EQ

CJ88

AA

SA

20

NA

DK

EQ

CJ8G

AA

SA

30

NA

DK

FA

04000

FA

20000

NA

01000

NA

01100

NA

30000

BK

SA

40

FA

D

NA

04000

X

ZV

SA

50

FA

K

NA

04000

X

ZV

SA

60

FA

D

FA

04000

X

DZ

SA

70

FA

D

EQ

FB05

FA

04000

X

DZ

SA

80

FA

K

FA

04000

X

KZ

SA

90

FA

K

EQ

FB05

FA

04000

X

KZ

SA

100

AA

D

Z2

SA

110

AA

K

Z3

Few Guidelines:

• The document type mapping, maintained via value mapping, should be executed first and then the rules should be applied to the mapped CFIN document type.
• Badi – ‘BADI_FINS_CFIN_AC_INTERFACE’ Method – ‘MAP_VALUES’ can be used for above Logic.
• The document type redirection shouldn’t be performed in case of Balances (SALDO), it is always with BLART – SA. In case of reversal, the document type should be derived to the one of the reversed document.
• It is recommended to add one Z column in ACDOCA to hold original document type in ZBLART Column. Badi – ‘BADI_FINS_CFIN_AC_INTERFACE’ with Method ‘PREPARE_INPUT_DATA’ can be used to Save the original document type
• Use of Constant in Doc Split Activation – Constant can be used for few initial load simulation to suppress the missing characteristics errors and focus on document types. Once the redirection logic table covers all the scenario you can replace this setting with more realistic one.
• Make sure all company codes involved in cross company code transactions are part of same initial load group. Document splitting can have issues in case if leading document not there and therefore cannot provide needed information

B. Enrichment of missing Characteristics through Badi or standard default

Document Split Characteristics can be enriched in FI records through multiple ways depending upon business scenario and customer specifications. I have considered Profit center only for below explanation:

1. Dummy Profit center at controlling Area Level – Not a viable solution specifically when you are not using Profit center Accounting
2. Default Profit Center at company code Level – FAGL3KEH – Cases where we don’t receive any Account Assignment like Profit center information from source on document line items and the document splitting functionality can’t derive the information, use a default assignment of Profit center as provided by business to fulfill the requirement of Reporting dimensions fulfilment in CFIN.
3. OKB9 – Assign default profit center on the document lines where Characteristic is blank based on the GL account for the line item to be processed.
4. Use of Constant in Document Splitting Activation – As explained earlier, this can be used initially to suppress the Missing characteristics errors for focusing on Document Redirection. However not a a recommended approach from customer point of view as this could lead to multiple documents with Constant Characteristics
5. Substitution GGB1 – Profit Center Substitution by a constant value or series based on different conditions using Set ID/ Exit.
6. Badi – use BADI_FINS_CFIN_AC_INTERFACE to derive splitting characteristics based on relevant criteria from custom tables containing data such as Company codes, balance sheet and Revenue G/L Accounts, Profit center, etc.

Few POINTS to consider for Badi implementation:

• This logic should be executed after mapping and document type redirection. The Logic should check when a default assignment is required and then perform default profit center assignment.
• Check if Characteristic is assigned on all lines or few line items and if they are same or different. Save this check result in some variable as the logic will require this information.
• Determine Transaction variant for the Document type (Table – T8G12) & line item category of all the lines items of the document based on GL account from table T8G16/T8G17, this will be used in logic against lead item category and base category.
• The logics are dependent on the Business transaction variant (BTV) assigned to the document type along with item conditions.
• For example – In case of BTV = clearing (1010/0001) – Vendor Clearing with Forex differentce: Item 1 (Vendor) will have passive split, Item 2 being Forex Difference does not have any characteristics will need default. The condition could be : Line must not be clearing line, must be base line and must not be lead line.

Conclusion

While both the Characteristic Enrichment & Document Re-direction approach requires time & effort in custom development, it also need weeks of assessment & discussion with client before jumping into the solution. The logic building in both the solutions are Iterative and seeks bit of additions with every simulation run as and when you progress towards fixing the several layers of errors.

I hope this blog gave you some insight and idea to approach document split depending upon the customer Source Accounting doc assessment. Pls do share your experience as well and comments if any.

Happy Reading!