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!

Mom

I Love you Mommy!