Calling Multiple BAPIs in a single LUW

[anup_deshmukh4]

Hi All,

I have a requirement where I am getting the data in XML payload through PI in a proxy method for a single line item. I need to create PO, GR and Invoice using this data. The requirement is that either all should be completed successfully or none should be committed. How can this be achieved using BAPIs or is there any alternative to do the same?

How can the BAPIs be cascaded?

For example:

BAPI_PO_CREATE1 -> PO gets created

if successful : BAPI_GOODSMVT_CREATE -> GR done for the PO created (FAIL - return and rollback PO)

if GR is successful : BAPI_INCOMINGINVOICE_CREATE -> IV done (FAIL - return and rollback GR and PO)

If Invoice is created successfully, we need to commit all the results, Else nothing should be committed.

[shahid]

when BAPI_PO_CREATE1 is executed in TEST RUN, does it returns any PO Number or the PO number will be some temp number like ("$00001")...( i saw similar thing when creating condition numbers)...

I assume that BAPI_GOODSMVT_CREATE needs PO Number.., what happens if we pass the temp number .

Have you tried running all in TEST RUNS and using single commit?

[anup_deshmukh4]

Hi SSM,

When I am running the BAPI_PO_CREATE1 in test run, I am not getting any temporary PO number nor any error message

[Former Member]

Hi

In your running you have to call the BAPI for commit too

Max

[anup_deshmukh4]

Hello max bianchi ,

Didn't got you... because if my PO is committed and GR fails for the same PO line item then I have to rollback the PO also.

And if PO is created, GR is also created, BUT IV fails then I need to rollback PO and GR both.

Will you please elaborate on your comment. Thanx for help.

[Sandra_Rossi]

Hi Anup Deshmukh,

I don't understand where is your question, your logic is correct, generally speaking. As Max says, for BAPIs, you must use BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK function modules instead of COMMIT WORK, ROLLBACK WORK (if you want to know the reason, there is a wiki in SDN).

Notes:

1) there are very few BAPI which commit database, but this is very unfrequent. To be sure, use SQL trace (ST05).

2) sometimes, BAPIs cannot be chained without an intermediate COMMIT when the second one has to read the data written in database table by the first BAPI (for example, creating 2 materials, where second one uses the first material as attribute "replacement material", system says it doesn't exist unless you commit). Some BAPIs accept that to be chained without intermediate commit, though the second one uses data created by the first one, because the first BAPI keeps in memory that data will be created.

BR

Sandra

[anup_deshmukh4]

Hello Sandra,

Thanks for your clarification ,

So is it that

BAP_PO_CREATE1 -> BAPI_GOODSMVT_CREATE - > BAPI_INCOMMINGINVOICING_CREATE

can not be Chained without using without intermediate commit .

so what is the alternative for same.

(My requirement is like i have to simulate all the the three doc if all are successful then all should be in DB or else NOTHING related to it must be in DB)

Edited by: Anup Deshmukh on Jul 27, 2011 4:21 PM

Edited by: Anup Deshmukh on Jul 27, 2011 4:23 PM

[Sandra_Rossi]

It's exactly as you said in your first post : in case of intermediate error, you rollback and stop the "chain", if no error at all you commit at the end (not between BAPIs).

BR

Sandra

[anup_deshmukh4]

Thanks ,

so if my third level fail that is invoice fails will by GR and PO will dissolve ?

M still trying ...!

Edited by: Anup Deshmukh on Jul 27, 2011 4:35 PM

[Sandra_Rossi]

yes, that is the principle of commit and rollback.

[anup_deshmukh4]

Look my thing :

1 . BAPI_PO_CREATE1

success BAPI_TRANSACTION_COMMIT

2. BAPI_GOODSMVT_CREATE (for the same po above )

success BAPI_TRANSACTION_COMMIT

3. BAPI_INCOMINGINVOICE_CREATE (for the same GR above )

ERROR BAPI_TRANSACTION_ROLLBAck

In the above case I want to dissolve the PO as well as GR in the DB . Can you please help me achieve this.

[Sandra_Rossi]

As I said in my last post, you must not commit between BAPI calls.

But, as I said in my first answer, if one BAPI needs data created/changed from previous BAPI, if it doesn't work (saying "object does not exist"), then you're stuck and you have no other choice than committing between calls , so there's no solution to your issue except doing extra work : for instance, storing the IDs of created objects in database so that to allow recovery from the failed BAPI. If you really want to "rollback" the created objects, then you should see if some BAPIs exist to cancel these objects.

BR

Sandra

[SuhaSaha]

Hello Sandra,

I remember you mentioning (in the wiki) about the "BAPI Buffer".

I think the OP should check if the buffer is available in his BAPI calls. If yes, he can read the data from it & not from the database.

What do you say?

BR,

Suhas

PS: Unfortunately i don't have a proper R3 system to check if the BAPIs in question share the common buffer!

[Former Member]

Hi

Sandra is right

You need to create several documents in your flow, so after creating them the rollback is useless, you can cancell the object only,

That means:

- if you have create the PO you need to cancel it (so to cancell all items)

- if you have create the good movement you need to cancel it

So your flow should be:

BAPI_PO_CREATE1
IF.OK 
    BAPI_TRANSACTION_COMMIT
    BAPI_GOODSMVT_CREATE.
    IF OK
       BAPI_TRANSACTION_COMMIT
       BAPI_INCOMINGINVOICE_CREATE 
       IF OK
          BAPI_TRANSACTION_COMMIT
       ELSE.
* Cancel material document
          BAPI_GOODSMVT_CANCEL
          BAPI_TRANSACTION_COMMIT
* Cancel PO 
          BAPI_PO_CHANGE
          BAPI_TRANSACTION_COMMIT
        ENDIF.
     ELSE, 
* Cancel PO 
          BAPI_PO_CHANGE
          BAPI_TRANSACTION_COMMIT
      ENDIF.
ENDIF.

Max

[Sandra_Rossi]

Hi Suhas,

well, the BAPI buffer is filled by BAPIs, to be used by themselves (BAPI materials for instance) or by some other BAPIs (RE-FX BAPIS for instance). If the test without intermediate commits doesn't work then it means these BAPIs don't exchange data via this buffer, so there's nothing that can be done (easily). Except maybe first looking if there are some SAP notes about that topic (on these BAPIs).

Sandra

[Sandra_Rossi]

Thanks Max, it is always better to provide a practical answer rather than theorical ones (mines ). To your algorithm, I would add a BAPI_TRANSACTION_ROLLBACK in case of error, to empty the BAPI buffer in case one of the BAPIs uses it (let's imagine BAPI_PO_CREATE1 uses it in write/read mode, that could conflict at the second call if error occured in first loop (if there's one)).

Sandra

[Former Member]

Yes Sandra

I agrre with you

I think it's important our friend Anup understands the BAPIs for commit and rollback are usefull only for a single call of a BAPI.

And I believe it needs to considere the time taken to store the data in the database: I mean the next BAPI can be called only if the process of previuos BAPI is really over else it can have an error due to the locked objects.

So the commit should be called with option WAIT

Max

[anup_deshmukh4]

Hello ,

Thaks for all your clarifications,

Things are clear now....!

@ Suhas BUT still one doubt Where can i trace wether a Perticulater bapi BAPI can be Chained without commiting ...!

a simple hint will be enough...!

Thanks all once again.

[former_member183880]

Hi Anup,

To be my knowledge as per your requirement, you may follow this.

While real run, validate all 3 BAPI's before COMMIT and save it in internal table and loop through again for 3 BAPI's and end of the BAPI use one single LUW once for all.

Guess i am not sure. But Just try it.

Regards,

Partha.

[Sandra_Rossi]

Hi Partha,

>  While real run, validate all 3 BAPI's before COMMIT and save it in internal table and loop through again for 3 BAPI's and end of the BAPI   use one single LUW once for all.

What Anup said is that it doesn't work since the second BAPI needs data from the first one, so the second one will always fail, unless a COMMIT is done after the first one.

Max,

oops, WAIT was the most important part, I didn't see it 😛

Sandra

[anup_deshmukh4]

Helllo all,

Actually i am getting all the data for PO GR IV from a non sap system ( the masters are in sync) from all the the discussions from experts I am on a conclusion that the bapis can't be chained and GR Cancellation PO logical deletion will happen ,

so.. any other approaches are welcome !

[SureshRa]

Hi Anup,

In my opinion we don't have to re-invent the wheel while standard SAP has given a strong document flow in this case of PO->GR->IV.

The MM functional consultant in your project should be able to convince the customer in this regard.

You first create the PO from legacy system. There is nothing happening in the system financially. There would be an internal commitment (PO Commitment) in the system.

Once the PO is created successfully, post GR. If GR posting fails, no need to panic. Nothing has happened. You can happily modify the above PO so that the internal commitment is zero - by changing the price / qty to negligible amount.

If GR is also successful, please note that there are financial documents created in SAP - e.g. a Credit to GR/IR Accrual Account and a Debit to Vendor Account. So at this point if the IV fails, you have to follow the proper reversal process - again consult the functional consultant on how to reverse through standard SAP transactions. There is no way that you can keep GR virtually and attempt posting IV - so that you can "rollback".

I would suggest you push back this requirement saying it is not within SAP framework. Thanks.

Regards

Suresh

[viva_kd]

Perfect Answer.

[Former Member]

Hello Anup,

you have dependence here ,i.e need to have PO No to check if you can do GR or not , same applies to IV as well...

i dont think you can check all these transaction in single shot...

im stil thiking abot another options..

regards

Prabhu

[anup_deshmukh4]

Answered

[Former Member]

Hi Anup,

I have a similar kind of requirement. could you please help me on this, How you solved this issue.

Thanks,

Naveen Kumar CH

[Former Member]

An excellent thread..