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

Re-Triggering ATP check for Sales Orders through program

Posted on Jul 15, 2016 at 02:41 PM 2.9k Views

Hi Experts,

I have a scenario in my project related to consignment scenario.

During the time of sales order creation if we don't get the confirmation and later on if the stock arrives we would like to re-trigger the ATP again for list of SO items which didn't get confirmation earlier.

Kindly note the ATP check is done with in ECC and not APO.

I tried using the BAPI_SALESORDER_CHANGE, the confirmation is happening for line items only when i update the ATP relevant fields like Requested Qty, Material or Plant.

Come across the standard T.Codes: V_RA, V_V2, COMAC & COHV but none of them suited my requirement.

However I would be interested in getting the SO items confirmed without changing any of the fields in the SO.

Your thoughts would be of great help.

Regards,

Srini.

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • Best Answer
    author's profile photo x xk
    x xk
    Posted on Jul 15, 2016 at 03:03 PM
    2

    Hello,

    why v_ra,v_v2 did not work?asking cuz you dont need to change any fields on those programs as you require.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Noel Connolly
    Noel Connolly
    Posted on Jul 18, 2016 at 03:52 PM
    1

    This is exactly what V_V2 is for! You need to use this transaction; you can also schedule it in the background

    Add a comment
    10|10000 characters needed characters exceeded

    • Noel Connolly Former Member
      Jul 19, 2016 at 11:08 AM

      Hi Srini,

      I understand what you are saying now. I have seen this requirement in the past but unfortunately V_V2 was not designed to be executed for specific sales orders. V_V1 does allow you to select by sales document but it is not supported any more (Note 1371800).

      I dont really see the advantage of executing V_V1 over VA02 to be honest. Lets take this example:

      There is an available quantity of 5.

      Sales Order is created with a requested quantity of 10. 5 are confirmed.

      A GR is posted for 5.

      Now, you want to update the Sales order so that it has a confirmed quantity = 10. V_V1 will allow you to do this for the Sales Order. However, it does not give you any advantage over just going into the sales order manually and selecting "Check Availability". Actually, you are at a disadvantage as the system cannot show you the availability control screen which gives the user greater control.

      Lets take another example.

      There is an available quantity of 10.

      Sales Order 1 is created with a required quantity of 10 and a confirmed quantity of 5

      Sales Order 2 is created with a required quantity of 10 and a confirmed quantity of 5

      A GR of 5 is posted, so now you have enough stock to be confirmed for one of the orders. But which one should get the available stock? Ideally, you would have variants set up in V_V2 which is executed regularly in the background. These variants would decide whether order 1 or order 2 now gets confirmed (based on creation date, priority etc.). If you wanted to force a particular order to get the new stock, then VA02 seems like the better option to me.

      I would strongly recommend that you look into utilising the standard V_V2 functionality and to execute new ATP checks by material / plant rather than by specific sales orders. However, if it is essential that you check by specific sales order, I think you need to look at enhancing V_V2 - note 549064, point 2.

      Hope this helps.

      Regards,

      Noel

  • author's profile photo Lakshmipathi Ganesan
    Lakshmipathi Ganesan
    Posted on Jul 19, 2016 at 09:28 AM
    0

    You have missed to explain why V_RA and V_V2 are not working for you. These are the standard transactions apart from CO06.

    G. Lakshmipathi

    Add a comment
    10|10000 characters needed characters exceeded