SAP FI-AA, basic configuration guide

It will be a very high level explanation. Basically there's only one SAP training for FI-AA configuration, which is AC305. Just attending this one single course should be enough for understanding the module. 

For sure, there should be new updates for S/4 HANA, because you might probably know that this new S/4 HANA Finance changed the concept of FI-AA module a lot, which I would like to cover a little bit later. But now there's no more ANLP, ANEK, ANEA, ANLC tables any longer (if you ever experienced writing a logic for calculating ,for instances, cumulative depreciation, then you'd probably know how complicated this can be with all those tables). Now there's only one table for line items, which is ACDOCA. Well, let me try to cover the topic later, when I feel more encouraged to do so.

So if you're about to start FI-AA implementation, then here is the list of steps you might need to accomplish: 

(1)  Assumption is that you’re done with As-Is part of the program;

(2)  Organization structure: Chart of Depreciation. It is maintained according to business needs, whether they want to have IFRS, local accounting standards, tax depreciation area, revaluation depreciation areas, and maybe they need depreciation areas in different currencies and with some business specific accounting rules and needs, all together. All that is getting maintained by copying some SAP standard depreciation area into your new, company code specific one, and then you simply add/delete/edit depreciation areas in newly created depreciation area. So you go to IMG/SPRO:

Financial Accounting (New) →Asset Accounting →Organizational Structures → Copy Reference Chart of Depreciation/Depreciation Areas → Copy Reference Chart of Depreciation or EC08 t-code.

In order to configure depreciation areas into newly created depreciation plan, go to:

Financial Accounting (New) →Asset Accounting →Organizational Structures → Copy Reference Chart of Depreciation/Depreciation Areas →Copy/Delete Depreciation Areas or OADB t-code.

What else.. you will have to define whether depreciation area posts APC to G/L in real time, or periodically (OABC t-code), how depreciation is getting posted to G/L, or maybe there’s no depreciation posting happening and it is just informative display of depreciation values (OABD t-code) and etc. and etc.

Next what you’re doing is, assigning newly created depreciation plan to company code. Depending on organization structure of the company, there can be lots of company codes, with their own accounting principles, due to geographical dimension, then you will be maintaining lots of depreciation plans for each company code, and assign them by the following menu path:

Financial Accounting (New)  →Asset Accounting  →Organizational Structures  →Assign Chart of Depreciation to Company Code or OAOB t-code.

Organization structure: Asset Classes. This one is pretty simple, normally accountants already have asset classes/groups they’re using in legacy system. So on As-Is part of the project, you already know how many classes/what are the names of asset classes and etc. When maintaining asset class, you will have to start from:

a)     Configuring account determination directory (based on which integration with General Ledger will be maintained next);

b)     Screen layout groups (suppose, different asset classes, have different requirements for statuses of fields on asset master data level);

c)     Number range of asset class (can be external/can be internal, depending on business requirements) via AS08 t-code;

Centralized t-code for maintaining asset classes is OAOA, which can be accessed by following SPRO menu path:

Financial Accounting (New) → Asset Accounting → Organizational Structures → Asset Classes→ Define Asset Classes

(3)  Master Data:

You’ve already created screen layouts for asset classes on step above. Then you probably are in need of configuring statuses of fields on tabs level and etc. (you might need to check for AOLA and AOLK t-codes in order to proceed). Also there’s separate screen layout that needs to be defined for depreciation... There are several so called blank fields, which can be used for whatever purposes you have. Check for ANLA-GDLGRP. Asset different dimensions, tax groups, and things like that can be stored here. These fields are informative, and good to have them for different reporting purposes. Besides, there’s nothing much to be said here.. So let’s continue with next step.

(4)  Business transactions: such as acquisitions, write- off, asset transfer. There’s a list of standard acquisition types that are already there, but if you need something specific, then you should go by the following menu path:

Financial Accounting → Asset Accounting→ Transactions → Acquisitions → Define Transaction Types for Acquisitions or AO73 t-code. Then there should be integration with G/L configured via AO90 t-code, or by the following menu path: Financial Accounting→  Asset Accounting → Integration with the General Ledger → Assign G/L Accounts. While maintaining Integration with G/L for each asset class, on step (2) of current guide, you might noticed that there is single field, where you should put precise G/L account for asset acquisitions. But, suppose, you want different G/Ls to be used for acquisition of same asset class, depending on transaction type (like, for instance, you want acquisition G/L 1000 to be used for transaction type 100, G/L 2000 for acquisition type 110 and etc.) This can be done via small user- exit in GGB1. Create some Z* table, write the logic of user exit so that, on line items level:

If ANLA- ANLKL= ‘A01’ and BWASL= ‘100’, then KTANSW= ‘1000’

Or something of a kind.

Same goes with write- offs- transaction types, integration with G/L. Nothing complicated.

Regarding transfer, there should always be two types of transaction types configured for asset transfer: for old assets and for newly acquired ones. Also I’ve highlighted one small thing about asset transfer Enjoy t-code by the following topic in my blog: http://autumnmoodpushkin.blogspot.com/2016/06/sap-fi-aa-asset-values-transfer-t-code.html

Capitalization of AUC- integration with CO, or Investment Management, depending on design of your ERP system, or you can also do it in FI-AA itself.

(5)  Period –End closing: Depreciation run (monthly, yearly and etc). Depreciation keys are specified by the following menu path:

Financial Accounting → Asset Accounting→ Depreciation→ Valuation Methods→ Depreciation Key→ Maintain Depreciation Key or AFAMA t-code. These keys are assigned to asset classes in OAYZ t-code. Depreciation run program is RAPERB2000. What else is here.. Depreciation posting is done in real time only in one single depreciation area, rest are getting updated in G/L periodically.

(6)  Data migration: master data is happening in both iterations, first is, you create new-old asset master data via AS91 t-code, and afterwards, you upload all of the asset values via AS92 t-code. This can be done via LSMW, via batch input with help of ABAP developer and etc. LSWM tool is quite easy to use here. I will be uploading LSMW guide a little bit later.

(7)  Finally, set the status of the company code as ‘Production’ and that’s pretty much about it.

SAP, Romanian Intrastat Declaration, legal requirement

Starting from 2015, according to legal requirement, following new fields were supposed to be added into Intrastat report for Romania for dispatches:

(1) VAT registration number of the customer;
(2) Country of origin

This legal requirement was released with OSS note 2119495.

Screen above is before OSS note implementation.
After implementing the note, VAT registration number gets updated with proper values from KNA1-STCEG.

But second part of legal requirement was missed from the OSS. Most probably it was added with further additions to 2119495, but back then, due to urgency, we had to manually add Country of origin field both in:

- screen layout of /CEECV/ROM;

- report structure,

by copying standard Intrastat report into Z* report. 

ps: we've added logic for fetching data from EIPO-HERKL, because on materials master data level, 'Country of origin' field is not mandatory, and was missing for most of the materials. 

SAP, FI-AA, asset values transfer t-code

Since release 4.6C, most of the transactions in FI-AA were replaced with Enjoy transactions, such as ABUMN, ABT1N, ABZON, AFABN and etc. and etc.
There's one small thing about Asset transfer t-code ABUMN. This Enjoy transaction doesn't allow to edit asset values on depreciation areas level.

Suppose you need to do following asset transfer transaction:

Asset A:
      Net Book Value   Cumulative depreciation  
01          100                          75
10           95                           70

You need to do partial transfer of asset value on another, newly created asset B.

What you want to do is:

Depreciation area 01:

Posting key                   Amount
      75           Asset A       60
      40           G/L             60
      70           Asset B       60
      50           G/L             60

Depreciation area 10:

Posting key                   Amount
      75           Asset A       55
      40           G/L             55
      70           Asset B       55
      50           G/L             55

This kind of operation is not possible with ABUMN.

This is due to design of Enjoy transactions, which is explained in OSS note 370530 - Functions in new Enjoy transactions.

Extract from the OSS 370530 on reasons:

Reason and Prerequisites:
1. This problem is caused by the program design: The Enjoy transactions are designed to cover the features required by a majority of users every day. Therefore, other functions are provided by the previous transactions to keep the Enjoy transactions as simple as possible in the application.
2. Release planning: We plan to enhance the Enjoy transactions step by step and add some of the previous functions. However, we do not yet know which functions will be available in the Enjoy transactions in which release.

So basically if your roles contain only access to Enjoy t-codes, you might need to add ABUM t-code in FI-AA roles, and proceed with executing transaction described above, separately for each depreciation area.

KE5T differences. Root causes, possible ways of resolving the issue

KE5T differences. Root causes, possible ways of resolving the issue
 

Case 1. Due to program error:

One of the possible cases of KE5T differences is that open items weren’t distributed during the balance sheet adjustment (transaction F.5D), and these items are, so to say, ‘stuck’ in RF048 table. After running F.5D, open items in RF048 table should be displayed in field BLGCHR with indicator ‘T’. But due to program error, there can be cases, when documents are stored with ‘S’ indicator, because of which you might be having differences in KE5T report.

Here is the list of such documents, that can be accessed via program, for instances, FIUT_180_APAR  in testing mode:

If you go to RF048 and fetch any of listed documents, you will see that they are having ‘S’ stored in BLGCHR:

In order to fix those ‘stuck’ items, you need to run corrective program FIUT_180_APAR . Or SAP released very recent version of corrective program with OSS note 2156474, which is FIUT_180_PP. By using any of those program, we’re fixing values of  BFO*_A/AB  tables after BSA posting.

So the procedure here is as following:

      (1)  Before running PEC programs, execute FIUT_180_APAR  or FIUT_180_PP;

      (2) Proceed with PEC programs F.05, F.5D, F.5E, 1KEK.

Suppose, you are having differences in May, which is already closed. And you don’t want to open the period, reverse BSA postings and re-execute F.5D and 1KEK for the period, then you just simply run corrective program in June, before running PEC programs. So that in cumulative May- June KE5T report, differences will be cleared. 

Case 1.1: Program error, cont’d 

There are cases when RF048-BLGHR=’S’ for open items, after BSA postings, is correct (explanation is in OSS 1617868).  Program FIUT_180_PP, released with OSS 2156474 is valid only for partial payments with invoice reference.

When checking RF048, you need to check if open items are having without invoice reference. If yes, then they will be fixed with FIUT_180_PP. If no, and they are profit center assigned, for this reason they get RF048-BLGCHR = S.

With quite recent OSS 2188136 SAP has released some small corrections to corrective FIUT_180_APAR  program.

So the procedure here will be as following:

     (1) Before running PEC programs, execute FIUT_180_APAR  AND FIUT_180_PP;

     (2) Proceed with PEC programs F.05, F.5D, F.5E, 1KEK. 

   

Case 2: Reconciliation accounts maintained in 3KEH/3KEI

Starting from Release 4.0, reconciliation accounts shouldn’t be maintained in 3KEH/3KEI tables, otherwise Transaction 1KEKdoes not transfer any values for these accounts. This creates differences between reconciliation and valuation account in KE5T report.

Suppose reconciliation accounts maintained in trx. 3KEH. Therefore the data are being updated online on this account in PCA -  with origin 35. Trx. 1KEK does not consider the accounts assigned in trx. 3KEH,
means no transfer into PCA is done for these accounts.  Let’s consider two scenarios:

(1)    difference is coming from previous fiscal year, which is already closed. In this case procedure should be as following:

-          first of all, delete reconciliation account from 3KEH and 3KEI;

-          delete all the data posted for reconciliation account with origin 35 from affected company code from PCA.

Delete the data by report RPCA_DEL_BUKRS using these selection criteria:
Controlling Area                XXXX
Company Code                  XXXX
Profit Center                                                 to
Account Number                  XXXXXX             to
Origin object                   35
Transaction
Record Type                     0
Depreciation area
                                Plan Version
Posting period                    XX, XX (firstly  XX, then XX)
Fiscal Year                     XXXX
- x test run (first in test run)
- x log
(OSS note  1174360 for more information).

-          In order to clear the difference in period 12 and balance carryforward, you have no to run trx. 1KEK for period 12;

-          Run 2KES for current fiscal year to correct the opening balance in PCA;

-          Then re-execute 1KEK for periods affected.

(2)    differences that occurred due to 3KEH/3KEI in current fiscal year:

-          delete reconciliation account from 3KEH and 3KEI;

-          delete all the data posted for reconciliation account with origin 35 from affected company code from PCA.

Delete the data by report RPCA_DEL_BUKRS using these selection criteria:
Controlling Area                XXXX
Company Code                  XXXX
Profit Center                                                 to
Account Number                  XXXXXX             to
Origin object                   35
Transaction
Record Type                     0
Depreciation area
                                Plan Version
Posting period                    XX, XX (firstly  XX, then XX)
Fiscal Year                     XXXX
- x test run (first in test run)
- x log
(OSS note  1174360 for more information).

-          Re-execute 1KEK for periods affected. 

SAP BSET and BSEG tables inconsistencies

There's a list of OSS notes for the issue between BSET and BSEG on marketplace.
There's even custom program developed by SAP in order to clear differences for already existing documents. From my understanding, this program is nothing but copying value from BSEG into BSET or the other way around, but not fixing the actual issue.
Differences appear in standard reports, such as EC Sales List RFASLM00, Tax return RFUMSV00 and etc. etc.
Difference can be also checked by comparing tax base amount in FB03 with BSET-LWBAS. There you will see that indeed BSET-LWBAS is having very minor difference with BSEG-DMBTR (or WRBTR, depending on the currency of posted invoice, where BSEG-BUZEI= 'T').
The difference is very insignificant, but it is valid from company code to company code. And it is valid only for RV documents, documents posted from SD.
Apparently, this is not even program issue, this is incorrect handling of VA01/VF01 postings from SD side. If you go on checking VF03, i.e. original invoice from FI document, you would notice that among all, there's condition type, having very small value assigned to it, because of which tax base amount is getting incorrectly updated in FI, when invoice released.
So, whenever you have BSET/BSEG inconsistencies, it is better not to rush fixing it on FI side with custom programs, or changing logics of standard RF* tax reports.
  

SAP BW, AP ageing report. Net Due Date calculation logic

Initial design of ageing report in BW built so that open items are analyzed based on due date field. 
And when partial clearing of invoice is happening, because of the due date of partial clearing document (BLART=SC normally), open items value periods- wise is getting incorrectly displayed, i.e. it is not getting decreased at all.
So idea here is to have equal due date both of SC typed document and of original invoice (KZ, KR, and etc. etc. typed documents).  
Net Due Date field (BSEG-ZFBDT) is not controlled with fields status group, it is controlled with APP configuration t-code, i.e. FBZP. 
In order to activate Net Due Date for AP clearing documents it is necessary to add spec. G/L indicator 'A' into vendors tab in FBZP (All company codes section). 
And then with explicit enhancement you will have to:

(1) block clearing documents for APP run (once you added spec. G/L indicator, partial payment documents ,having the indicator, will be selected to APP); 
(2) update BSEG-ZFBDT of clearing document, getting generated with F-44 t-code. 

Net Due Date logic is as below (if you tried dealing with Net Due Date, you might notice that this date is getting calculated from several fields, depending on payment terms): 

Net Due Date= BSEG-ZFBDT+ BSEG-ZBD1T
if else BSEG-ZBD2T>0 then Net Due Date= BSEG-ZFBDT+BSEG-ZBD2T

BTE for updating BSEG-ZFBDT from F-44 is 00001130.
Standard FM for BSEG-ZFBDT in F-44 is SAMPLE_PROCESS_00001130.

So after Net Due Date of clearing document is getting updated with Net Due Date of original invoice, then BW Ageing report will be displaying correct dynamic of open items periods- wise. Et voila! :)

SAP, GGB0 validations for parked invoices

Parked invoices information stored in BKPF table only.
Suppose, when parking invoice, you want to validate some of the assignment objects (cost center, profit center, alternative g/ls and etc.). These fields exist only in BSEG, so when creating validation for:

BSEG-LOKKT, for instances, you need to create another one, for parked documents.

I.e. for validating LOKKT (alternative G/L) you need to write two validations:

(1) one that is valid for posting of documents via FB60, FB01 and etc.
(2) another one for parked documents.

But here is one trick about this case:

If, line items don't exceed amount of displayed line items on the screen (say, for instance, your FV60 t-code displays only 7 line items at once), then, for some reason, BSEG validation is working perfectly fine, even though there's still nothing in BSEG for the document, that is getting posted via FV60. This has something to do with information that is fetched from FV60 from SAPMF05A (screen for FV60 to be checked via F1.. it should be 1000, if I am not wrong) itself. 

So, suppose, you create parked document via FV60, or creating WF item from SBWP t-code, then anyways you will be forwarded to FV60 itself, and your invoice contains 20 line items.
System keeps on entering those 20 line items, but when trying to save the document, you will start getting warnings/errors due to validation you created in GGB0 for validating LOKKT. When debugging, you will see that first line items, the ones that are visible in initial screen of FV60 are passing the validation perfectly fine, but on n+1  (n- amount of line items per screen) item, system starts giving warning/error from GGB0. 

First of all, this is, of course, design bug, BSEG validation shouldn't be working for parked documents at all. Technically, such things doesn't make sense at all.
Second, as already mentioned, for parked documents, validation of LOKKT should be done via user- exit. And whole logic needs to be coded in it. But here, again you need HKONT information in order to check if LOKKT is there for it. Here, I assume, it is necessary to apply same approach: fetch data going through SAPMF05A.. 

SAP Russian add-on, VAT return program, J3RFUM26

Standard J3RFUM26 logic is built so that, VAT return posting is happening, only when following condition is true:

BSEG-XREF1 is not blank

XREF1 is informative key that is getting filled by users manually when posting documents via FB01, for instances. 
Text informative fields such as XREF1, XREF3 are getting updated in Texts menu of document posting t-codes.
BSEG table is getting updated via FM RFIF_UPDATE_FICO_XREF1, which is getting triggered via standard BTE (say, for instances, 1120) assigned to document posting t-codes. 
So, assume, you're executing some enhancement for this same BTE. Suppose, you want to write new logic for updating some other BSEG field while document posting from FB01/FB60 and etc. Same BTE is getting modified. 
This is where FM RFIF_UPDATE_FICO_XREF1 fails to get triggered the way it should, according to add-on design. Same BTE, different programs/FMs/user exits are getting executed, and system fails to update all necessary fields. 
As a result standard program RFIR_AP_XREF1 eliminates VAT return documents. And amount of such documents can be quite huge: text fields are updated by users during postings, i.e. field is not blank when accessing document via FB02 t-code, but when checking BSEG table, XREF1 is blank. Hence, document is not getting processed with J3RFUM26.

Solution to such case can be as following:

FM RFIF_UPDATE_FICO_XREF1 may still remain in BTE, but on top of that, it should be included as additional step in program RFIR_AP_XREF1 itself.

I.e. what we're doing here is:

(1) we're picking all of the VAT return documents having BSEG-XREF1 is not blank;
(2) we're processing all of the rest documents (having text field updated in FB02, but not updated in BSEG). 

In order to proceed with step (2) we need to fetch all of the documents, having text field maintained in it. This can be done by executing FM READ_TEXT in following manner:

Client- 100

ID- Z002

Language- RU

Name- should fetch all of the documents posted in current posting period: RU10 + BELNR + GJAHR

Object- BELEG

Here is the example of mandatory parameters:

Text that is stored with mentioned above parameters:

So you can see '30.04.2015' is stored in text field of the document, which can also be accessed via FB02 t-code. 

So here we identified that document 2400539 is having text, and this document should be processed via J3RFUM26. Hence, we're transferring this document to FM RFIF_UPDATE_FICO_XREF1 in J3RFUM26 itsef. 

J3RFUM26 is standard report, so, whenever you decide to add FM RFIF_UPDATE_FICO_XREF1 into it, then no further updates from SAP will be valid for it, or, mentioned change will be simply overwritten whenever there's system upgrade, or release of J3RFUM26 related OSS note. So it is recommended to copy everything into Z* program and start from there.

This is not a program bug or something of a kind, this is initial design issue of XREF1 field update. 

CO table inconsistencies: GLPCA and GLPCT differences

GLPCT table contains PCA totals that are being generated based on GLPCA table entries.
But both tables has no common key fields:

GLPCT-ROBJNR/COBJNR/SOBJNR are not related to GLPCA_GL_SIRID.

Suppose, due to some issue, you had to update GLPCA table directly (along with FI tables, BSEG, for instances), but you didn't update GLPCT, then there will be mismatch between 2KEE and KE5Z reports. 

This can be resolved by utilizing program that was released with OSS 2090912
COPCA_REBUILD_GLPCT_BY_GLPCA2, which is aimed to re-build GLPCT table values. 

DMEE problems, ADRC table inconsistency

In your DMEE output file, text might missing, in specified text node.
This issue can happen when transferring data from master data of vendor/customer into DMEE file output, for instances.
Suppose, you've changed language key for vendor from KG to KZ on 01.01.2015. All of the invoices posted prior that date, will transfer KG into REGUH/REGUP tables, from F110 t-code. Invoices posted after 01.01.2015 will pick KZ into REHUG/REGUP.
So there REGUH/REGUP fetches data from KNA1/LFA1 based on date indexes. Which is incorrect. And this means there's inconsistency between KNA1/LFA1 and ADRC tables.
For our case, for vendor, there might be KG still stored in ADRC table, despite changes on 01.01.2015.
Resolution to such bug is as simple as that:

FK02:

change of language key from  KZ to KG    (current date)

again FK02:

change of language key from KG to KZ     (current date)

And now ADRC is consistent with KNA1

that's about it, simple as that :)

Victory Day, 09.05.2016

Happy 71st anniversary of Victory!