понедельник, 30 мая 2016 г.

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.

- 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! :)

воскресенье, 29 мая 2016 г.

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.

четверг, 19 мая 2016 г.

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

понедельник, 9 мая 2016 г.

Victory Day, 09.05.2016

Happy 71st anniversary of Victory!

понедельник, 30 мая 2016 г.