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..
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..
Комментариев нет:
Отправить комментарий