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:
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.
Its outstanding post with good information.
ОтветитьУдалитьvat return services london