2014 Oct 23 10:46 AM
Hello guys,
I got the following requirement:
Whenever a user posts a FI document with some special CO object, I need to post an additional document with the information of the corresponding BSEG row with the CO object. Best point of posting of course would be after the original FI document is posted so that my additional document canot be posted when some error is done in the original document.
What would be the best way for it? If possible I would prefere object oriented BADI but I looks like there is no option for that?
Is it only possible with BTE? If so which one is the right one after the document is posted? 1030? Or is there any other way like User-Exit / Substitution Rule?
Thanks a lot!
Regards
Michael
Hello guys,
I got the following requirement:
Whenever a user posts a FI document with some special CO object, I need to post an additional document with the information of the corresponding BSEG row with the CO object. Best point of posting of course would be after the original FI document is posted so that my additional document canot be posted when some error is done in the original document.
What would be the best way for it? If possible I would prefere object oriented BADI but I looks like there is no option for that?
Is it only possible with BTE? If so which one is the right one after the document is posted? 1030? Or is there any other way like User-Exit / Substitution Rule?
Thanks a lot!
Regards
Michael
2014 Oct 23 1:43 PM
BTE 00001030 and 00001050 (*) were created for this kind of requirement; nevertheless, yes you can use any BAdI or validation/substitution exit to initiate the same. In every case just create a wrapper RFC RFM and call it with IN BACKGROUND TASK option to fulfill your requirement.
Regards,
Raymond
(*) Depend on origin of document "FI" or "AC interface", so implement both. Also use TH_IN_UPDATE_TASK as you may alreeady be called in update task, and don't forget to prevent infinite loop and do not trigger from your generated document.
2014 Oct 23 2:11 PM
Origin document would be in normal case incoming invoice from vendor which is created in SAP as parked document from external software. When finance department checks the parked document and tries to post it, then after it is getting posted without any error the additional document should be posted as well as simple general ledger posting + - 0 but with different CO objects.
For what do I need wrapper RFC RFM? I do not call any other server or external program with RFC. I just tested BTE 1030 with BAPI_TRANSACTION_COMMIT at the end and the document was created fine like I want it. Is there any problem for this way of solving the problem?
What would you prefer? I think BTE is easier handling than substition, but of course BADI would be the best one, but I did not find any BADI for this scenario.
Regards
Michael
2014 Oct 23 2:34 PM
2014 Oct 23 3:59 PM
Documentation is
All current data, all document data required for the update, and various control parameters are transferred to the additional component. The indicator I_XVBUP is used for information purposes only - that the SAP standard system carries out an update posting asynchronously.
It follows that no database activities involving the writing of data may be carried out in the additional component.
The update posting (including tables specific to Add-ons) are carried out by the COMMIT WORK of the standard process. If your function module is not accessed via RFC, you should always initiate asynchronous update posting using the ABAP statement:
IN UPDATE TASK.So what to do? I'm sorry but the whole update posting module handling in SAP is very technical for me, because I canot see what happens in background when SAP posts a document. I only know that every posting will be transfered to the update posting module and if something goes wrong I can see it in SM13 🙂
At the moment I'm testing around with BTE 1030 custom sample function and creating the document with function 'BAPI_ACC_GL_POSTING_POST' or 'BAPI_ACC_DOCUMENT_POST' and after that the COMMIT BAPI. So I should call this with additional 'IN UPDATE TASK'?
How can the second document being created before the first one? As I understand BTE 1030 will be called after update posting module is called?
It would not be that sad when the documents will be created vice versa, but of course it would be better in the right order. So placing in UPDATE TASK would be enough?
Regards
Michael
2014 Oct 24 8:03 AM
BTE is called after submission of update FM, but before their actual execution.
As I already wrote, for "safety" reason, I would creare the new document in another LUW, not bothering the current transaction. That can be achieved thru a RFC wrapper FM (which execute BAPI and commit) called IN BACKGROUND TASK, so after update success and where erros can be monitored thru SM58.
If you don't want such solution, remove your commit-work, and see if the transaction commit-work is able to commit your document; maybe you were lucky and your commit work was executed just before the standard on (this last one wont actually perform anything...) Either check with debug or Abap trace (SAT/SE30)
Regards,
Raymond
2014 Oct 24 9:17 AM
Ok you mean with RFC wrapper FM placing a Z-function into my Z_SAMPLE_INTERFACE_00001030 function simply with addition 'IN BACKGROUND TASK' and then putting just my DOCUMENT_POST and MY COMMIT BAPI into it?
What would that mean for the posting process? As I understand the documentation it says that the RFC function will be called after the commit work of the calling programm which would be in my case FB60 transaction? So the difference is that in this case it waits until the first document is posted and then my second document will be posted in new LUM? But in every case it depends on the first document? When origin document canot be posted, second will also not be posted?
Is there any influence at other processes? Of course it can happen that many user post documents at the same time in SAP, but that would be unimportant?
Regards
Michael
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |