SAP Note

3044558 - Configuration/customizing help for JVA on ACDOCA

Component: CA-JVA-JVA (Joint Venture Accounting), Version: 10, Released On: 06.04.2023

Symptom
Configuration/customizing help for JVA on ACDOCA

Other Terms
JVA, Joint Venture Accounting, JVA on ACDOCA, G4058

Reason and Prerequisites

When a greenfield implementation of an S4HANA system is made, and JVA is supposed to run on ACDOCA (rather than on
the classic SL ledgers), some specific configuration/customizing and master data settings need to be made so that the JVA
processes will run correctly.

Solution
When JVA should run on ACDOCA and not on the classic SL ledgers, some special settings are required. Below you will find
detailed instructions.
Note that these instructions do not cover the complete JVA customizing. They only contain extra steps or recommendations
that are important for JVA on ACDOCA, compared to the customizing of the classic JVA.
Please be aware of the restrictions of JVA on ACDOCA which are described in note 2993369.
Special restrictions also need to be taken into account when you intend to switch on JVA on ACDOCA in a Central Finance
system (cFin). These are described in note 3025738.
The below-mentioned steps should not be executed without preparation in a productive system that is running on the classic
JVA and has historic postings. For such a switch scenario special rules and steps apply that need to be properly planned. The
supported switch scenarios are described in note 2941622 (Migration to S4HANA with Joint Venture Accounting running on
ACDOCA).
Instructions how to activate JVA on ACDOCA in an S4HANA system ("greenfield" implementation):
(1) Update the code by implementing the latest support packages. Additionally, all implementable notes that are mentioned
in the following note should be implemented: 2927005 (Notes for JVA on ACDOCA) . Please check note 2927005 every
month. It will be updated on a regular basis.
(2) Switch on the "JVA_ON_ACDOCA" business function:
(a) Launch transaction SFW5, open the sub-node "ENTERPRISE_BUSINESS_FUNCTIONS" and look for the item
"JVA_ON_ACCOCA".
(b) Tick the checkbox in the "Planned State" column.
(c) Click the "Save" button, then click the "Activate Changes" button.
(3) The FI document split is not done by JVA logic, but by the GL splitter. It is very flexible and requires a lot of customizing
effort. (The special JVA needs are described in (4) and (5) below.) Therefore, there should be an inhouse expert for the GL
spliter configuration. For general help on the GL splitter, please read note 1085921 and/or go to this
wiki: https://wiki.scn.sap.com/wiki/x/F5woGg.
Some general GL splitter topics that need to be considered:
(a) When a new document type is created, it needs to be configured correctly in the GL splitter settings ("Classify
Document Types for Document Splitting") to ensure the right processing of the documents in the GL splitter. For
example, documents types that are configured as "Unspecified posting" will not be split; only inheritance will take place
(if the conditions are met).
 (b) Likewise, when a new account is created, it needs to be configured correctly in the GL splitter settings ("Classify G/L
Accounts for Document Splitting").
(c) Generally, you should not define default profit centers for accounts as these can lead to issues during the GL split
because the inheritance might not work (because the default profit center might differ from the profit center derived from
the cost object in the split basis line).
(d) When defining the posting rules for JVA processes (transaction GJ49), be aware that this can have an impact on the
split results. Here are some specific tips for cutback postings: For function 'CUTB' you need to define a document type in
the posting rules (transaction GJ49) that is configured as "Customer invoice" in the GL splitter settings. For function
'CUTI' a document type needs to be used that is configured as "Vendor invoice" in the GL splitter settings. Additionally, all
accounts that are used as expense accounts in cutback postings should be configured as "Expense" because if this is not
so, the inheritance will not work properly.

(4) In the GL splitter settings, define the venture fields as split criteria:
(a) Launch transaction SPRO, go to the IMG and to this node:
-> Financial Accounting
-> General Ledger Accounting
-> Business Transactions
-> Document Splitting
- Define Document Splitting Characteristics for General Ledger Accounting
(b) Add the venture field to the list of split criteria (VNAME Joint Venture) and set the value 'PVNAME' in the "Partner
Field" column.
(c) If each document should be balanced by venture, tick the checkbox in the "Zero Balance" column.
(d) If the venture field should be mandatory, tick the checkbox in the "Mandatory Field" column.
(5) In the GL splitter settings, define the cost objects as split criteria:
(a) Launch transaction SPRO, go to the IMG and to this node:
-> Financial Accounting
-> General Ledger Accounting
-> Business Transactions
-> Document Splitting
- Define Document Splitting Characteristics for Controlling
(b) Add all cost objects to the list of split criteria: KOSTL, AUFNR, NPLNR, AUFPL, APLZL, PS_PSP_PNR
Remark: As long as this is not done, the error message G4-058 will ge thrown every time you try to post an FI document.
(6) Activate the updating of cost objects for tax account lines:
(a) Launch transaction SM30 for the maintenance view 'V_FAGL_SPLIT_FL2' and click the "Maintain" button.
(b) In the "Assign to Tax" column tick the checkbox for all relevant cost objects (APLZL, AUFNR, AUFPL, KOSTL,
NPLNR, PS_PSP_PNR).
(c) Click the "Save" symbol (or press the Ctrl+S shortcut on the keyboard). When doing this, the settings will not only be
saved in the corresponding database table, but the generated code for the GL splitter will be re-generated by executing
report RGZZGLUX automatically in the background.

Important remark: You should not make these settings in the database table directly (e.g. via transaction SE16N) because
the generation report RGZZGLUX will not be automatically executed.
To make sure that the generated code is up-to-date, you can run the report RGZZGLUX manually via transaction SE38 or
SA38.
(7) If the inheritance logic for FI doc lines (that are not subject to splitting) should also cover the cost objects, execute the
following instructions (also see note 2826489):
(a) Launch transaction SM30 for the maintenance view 'FAGL_SETTINGS' and click the "Maintain" button.
(b) Add a new item with parameter name 'SAPLGLT0_INHERIT_CO' and value 'X'.
 The 'valid to' can be used to activate this feature temporarily until the defined date. This date is checked against the
posting date of all documents being posted. If you keep the 'valid to' value initial, the CO object inheritance will be active
permanently.
(8) Activate JVA in each company code where JVA will be used via transaction GJC1. Generally, while the data model for
saving the JVA data has changed compared to the classic JVA, the business processes have remained virtually the same. So,
almost all the settings have to be made in the usual way. For some special tipps and suggestions, see the items below.
(9) The settings for the NewGL-JVA integration (transaction GJGL) are not required when the JVA is running on ACDOCA.
(10) Regarding the JV ledger settings that were mandatory in classic JVA (transaction GJL2), there are some special rules.
Although the JV ledgers 4A to 4F are not used anymore for the actuals, ledgers 4A and 4C are still used for the classic KP06-
based CO planning. Additionally, if you intend to use the PSA solution (Production Sharing Accounting), the ledger settings
for ledgers 4A and 4C need to be made as the basis for the PSA ledgers 4P and 4Q. So, if you do not plan to use either PSA or
the classic CO planning, no settings need to be made in transaction GJL2. However, to be on the safe side, you can just
activate the ledgers 4A and 4C; it does not do any harm to activate them. If you activate the JV ledgers, use the same
currencies as in FI and in the same order.
(11) Complete the company code customizing for JVA via transactions GJZA, GJZC, and GJZD:
(a) As of OP2020, in transaction GJZA you can change the ledger that will be used by the JVA month-end transactions to
read the data from. By default, the leading ledger will be set automatically. In the most cases this will be the right settings.
Change to a non-leading ledger only when you are absolutely sure that this is correct.
(b) In transaction GJZC the default accounting data needs to be defined (corporate venture, corporate equity group,
corporate recovery indicator, corporate cost center).
(c) In transaction GJZD the new Funding functionality can be switched on (if required). The Funding functionality
replaces the classic VBA functionality (Venture Bank Account Switching).
(12) Although the FI document splitting is completely done by the GL splitter, all bank accounts that are relevant for JVA
need to be defined in transaction GJ35 ("JV Bank Accounts"). If this is not done, some recovery indicators will be set
incorrectly in FI postings.
(13) A substitute cost object needs to be defined for every venture (via transaction GJVV). To reduce the effort, just create
a substitute cost object for an empty recovery indicator. (If no substitute cost object is found for the given recovery indicator,
the substitute cost object without recovery indicator will be used as the default setting.)
(14) The JVA substitution is not available. In the special-ledger-based classic JVA the JVA substitution can be used to
manipulate the data in the JVA documents. This is possible although JVA substitutions cause inconsistencies between the
accounting data in the FI/CO and the JV ledger. When JVA is running on ACDOCA, such inconsistencies are not allowed and
not even possible anymore because the JV documents are (physically!) identical with the FI/CO documents. Therefore, there
is no replacement for the JVA substitution in JVA on ACDOCA that allows to tweak the data in documents posted to the
ACDOCA table just for JVA purposes. Additional restrictions apply because the GL splitter is active: no document must be
changed after the GL splitter has processed the document.
It is very important to take this into account when migrating to (or switching on) JVA on ACDOCA in an S4HANA system.
Business processes that are based on JVA substutions in classic JVA have to be designed and set up differently when JVA is
running on ACDOCA. So, for example, if a recovery indicator value should be substituted, this needs to be done via the
substititution functionality that is avaiable for FI and CO documents. (An alternative solution might be to define a recovery
indicator for the affected account, if this is appropriate; see also section (16) below).
General customizing rules:
(15) Generally, the JVA is based and designed on the relationship between cost object and venture. Several rules follow from
this:
(a) Venture data should be defined for each cost object that is used in JVA company codes. If no venture is defined for a
cost object, the corporate venture will be set (see point 11b above) - unless a venture is defined for the profit center (see
below).
(b) While it is possible to define ventures also for profit centers, these will only be used as a kind of default value: The
profit center ventures are set only if no cost object is available or if no (or the default) venture is assigned to the given cost
object. Moreover, there is the risk of conflicts between the ventures assigned to the cost objects and the ventures assigned
to the profit centers. The standard SAP logic does not issue warnings or error messages when the venture assigned to a
profit center does not match the venture assigned to a cost object from which the same profit center is derived. Therefore,
any reporting that is based on profit center and ventures needs to interpreted with care as there is no guarantee that the
venture assigned to the profit center will show up in the reporting. This means, the customers have to ensure consistent
master data when maintaining ventures for profit centers.
(16) Apart from the organizational accounting data (esp. venture and equity group), the recovery indicator settings are very
important because the recovery indicator determines which costs will be picked up by the cutback process and billed to the
venture partners. Some general rules should be followed:
(a) When developing a plan for the recovery indicator settings, always take into account the priorities of the recovery
inidcator derivation when documents are posted. These a described in detail in note 1165394.
(b) The cost objects should be regarded as the central source for the recovery indicators used in postings.
(c) While it is possible to define recoery indicators for accounts, this should be done in exceptional cases only. In
especially, postings to accounts that are cost elements will be posted with a cost object, and the recogery indicator will be
derived from the cost object. So, usually, no recovery indicator should be defined for cost elements. On the other hand, it
can make sense to define a recovery indicator for a balance sheet account, namely when it is required that all costs posted
to that account should have a special (non-billable) recovery indicator. (To set a billable recovery indocator for cost
elements does not make sense, however.)

Software Components
Software Component From To And subsequent

S4CORE 104 104 X

S4CORE 105 105 X

S4CORE 106 106 X

This document refers to

SAP Note/KBA Component Title

2941622 CA-JVA-JVA-IF Migration to S4HANA with Joint Venture Accounting running on ACDOCA

2927005 CA-JVA-JVA Notes for JVA on ACDOCA

1165394 CA-JVA-JVA-PP Derivation of the Recovery Indicator in JVA