Skip to Content
author's profile photo Former Member
Former Member

Validating APO temporary quantity assignments using ABAP program


I expect I need assistance with tracing task handlers and transaction GUIDs.

I have been looking at creating a program for checking the consistency of the temporary quantity assignments in APO. When documents such as sales orders are created in ECC, stock is reserved in APO using a temporary quantity assignment.

The open assignments can be viewed using APO transaction /n/SAPAPO/AC06. For new orders the document number is correctly not displayed in APO since it is not assigned until the order is saved in ECC. Therefore determining if the assignment can be deleted can be a complex task. Normally I resort to asking a user to log off if I think there is a problem.

I would like to build a link from the transaction GUID available in the //AC06 temporary quantity assignment transaction and the ECC transaction.

Here is my intention:

1. Read the transaction GUID from the //AC06 transaction using function module /SAPAPO/OMB_DELT_READ_TOTAL

2. Find the second connection from the GUID as discussed in FAQ note 488725 (see below)

3. Find the original ECC transaction

4. If the ECC transaction is still active, the temporary quantity assignment is valid

5. If it is no longer valid, then the temporary quantity assignment can be deleted

According to SAP note 488725 (FAQ: Temporary quantity assignments in Global ATP):

The temporary quantity assignments are written to the liveCache using a second database connection and are committed immediately. This ensures that they are immediately visible for parallel transactions but this also means that they are not automatically deleted during a rollback. The "task handler" is available for an almost automatic deletion of quantity assignments. The task handler is triggered as soon as the RFC connection between the calling system and the SCM is (unexpectedly) ended. It deletes all quantity assignments written in the transaction, but it cannot recuperate the non-persistent quantity assignments that were implicitly deleted in the transaction Terminations that do not break off the RFC connection (for example a dump in the SAP GUI) cannot be caught by the SCM system.

The temporary assignments are deleted when I back out of a transaction or abruptly cancel it. I expect the link is buried deep within the kernel, but I have hopefully missed something simple as this is definitely outside my area of expertise. I have checked transactions such as STAD in both ECC and APO and I cannot find a common transaction GUID, and I cannot find a matching GUID when I convert the 22 character GUID to 32 characters.

Thanks in advance as any help is appreciated.


Add a comment
10|10000 characters needed characters exceeded

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Mar 14, 2011 at 01:20 PM

    Hi Martin,

    What I understand from your explanation is that you are stuck on how to read orderdata using GUID from livecache.

    Correct me if I am wrong.

    There are a number of Function Modules available to read order data from Live cache.

    You can also use tcode : /n/SAPAPO/OM16 which uses most of them..

    You can have a look on FG: /SAPAPO/OM_ATP Which has all Fm related to LiveCache - ATP interface.

    Let me know your feedback..



    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Mar 15, 2011 at 11:14 AM

    Hi Ajay

    I am hoping to dive a little deeper and I have function modules read the order data.

    My real challenge is trying to map the live cache delta anchor GUID in APO with the transaction GUID in ECC. For example, if there is a temporary lock in APO then I want to check that the user is still creating the sales order that generated the temporary quantity assignment. If I cannot find the initiating transaction, then the temporary quantity assignment can be deleted.

    I have spent a while searching the function modules and classes. It is possible that some of the information I require is stored in memory rather than in the database or live cache. In this case, I believe I would need to read information from the kernel.

    Documentation on the kernel functions is limited probably for good reasons. For example, transaction SM04 reads the screens users are logged on to from the kernel rather than using function modules or classes. Before anyone points it out, I do know about TH_LONG_USR_INFO.

    I will need to work backwards:

    - Find the link from the temporary quantity transaction code to the task handler used for the gATP check

    - Find the associated transaction for the ECC second database connection as discussed in the note

    - Find the initiating transaction in ECC

    If this proves too much, I will have to resort to checking for record locks but I will not be able to determine which orders can be deleted if the user has locks for more than one order in APO and they are currently in VA01.

    Thanks for taking the time to reply


    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Jan 08, 2014 at 06:28 PM

    Hi Martin,

    I know it's a very old post, i have a similar requirement at hand. Is there any chance that you can recall it how you have addressed the issue. any help would be appreciated


    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.