Skip to Content

Zero price returned in BAPI_SALESORDER_SIMULATE for newly created price (VK11)

We are having a problem with BAPI_SALESORDER_SIMULATE returning a price of "0" immediately after a price condition is created in VK11. Here is the sequence of events:

  1. User executes a custom-built screen in order to create sales order line items.
  2. The material the user is entering on the sales order is not found in the database.
  3. A pop-up screen allows the user to enter the new material along with the price.
  4. Behind the scenes, when the user clicks "Save" on the new price, the material is created and the pricing condition is also created using CALL TRANSACTION 'VK11' with updmode set to 'S' fo Synchronous.
  5. After this code is finished executing, the user is returned to the main screen where BAPI_SALESORDER_SIMULATE is used to look up the newly-created price and add it to the sales order.

About one out of every three or four times, the price is coming back as "0" even though the pricing condition is created. Shouldn't the "Synchronous" option in the VK11 call ensure that the condition is saved prior to BAPI_SALESORDER_SIMULATE returns "0"? (The field that returns zero is GT_OUT-NET_VALUE1... see code below.)

ALSO NOTE: So far we are only seeing this in our production system. I wonder is multiple users using BAPI_SALESORDER_SIMULATE simultaneously could play a role in the problem.

Some key bits of code are shown below in order of execution. Please help us spot the problem if you can. Thanks!

   wa_params-dismode = 'N'.      "Mode 'No Display'(Mode A/E/N)   wa_params-updmode = 'S'.      "synchronous Posting   wa_params-defsize = 'X'.* ----[some unrelated screen filling code omitted]----     CONDENSE gv_fval.     PERFORM fill_bdc_data USING:                         ' '          'KONP-KBETR(01)' gv_fval,                         ' '          'KONP-KONWA(01)' c_unit.     CLEAR:gv_fval.     gv_fval = c_kpein.     CONDENSE gv_fval.     PERFORM fill_bdc_data USING:                           ' '          'KONP-KPEIN(01)' gv_fval,                           ' '          'KONP-KMEIN(01)' c_uom.     CLEAR: gv_start_date,gv_end_date,gv_date_e.     WRITE sy-datum TO gv_start_date.     gv_date_e = sy-datum + wa_material-valid.     WRITE gv_date_e TO gv_end_date.     PERFORM fill_bdc_data USING:                           ' '          'RV13A-DATAB(01)' gv_start_date,                           ' '          'RV13A-DATBI(01)' gv_end_date.*--submit the mapped data to VK11 transaction     CALL TRANSACTION 'VK11' USING t_bdcdata                             OPTIONS FROM wa_params                             MESSAGES INTO t_mestab.* etc....

*--subroutine excerpt FORM GET_PRICE_OF_MATERIAL USING MATNR TYPE MATNR                                 MEINS TYPE MEINS                                 WERKS TYPE WERKS_D.  DATA : L_TABIX TYPE SY-TABIX.  CLEAR : GV_HEAD,GT_ITEM,GT_PARTNER,GV_RETURN.  REFRESH : GT_ITEM,GT_PARTNER,GT_OUT.  IF GV_VBELN IS INITIAL.* Populate the header data for BAPI Sales Order Simulate    GV_HEAD-DOC_TYPE = 'ZPOR'.    GV_HEAD-SALES_ORG = GV_VKORG.    GV_HEAD-DISTR_CHAN = '20'.    GV_HEAD-DIVISION = 'PT'.* here we are checking for this condition as 9999 is a vitural Branch and not* defined in the system as real sales office.    IF GV_VKBUR = '9999'.      GV_HEAD-SALES_OFF = '4001'.    ELSE.      GV_HEAD-SALES_OFF = GV_VKBUR.    ENDIF.    GV_HEAD-REQ_DATE_H = GV_VDATU.    GV_HEAD-DATE_TYPE = '1'.*  GV_HEAD-PRICE_GRP = KONDA.*  GV_HEAD-PRICE_LIST = PLTYP.* Populate the Partners values for the sold to and    GT_PARTNER-PARTN_ROLE = 'AG'. "SOLD TO PARTY.    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'      EXPORTING        INPUT  = GV_SOLD_TO      IMPORTING        OUTPUT = GV_SOLD_TO.    GT_PARTNER-PARTN_NUMB = GV_SOLD_TO.    APPEND GT_PARTNER.    CLEAR GT_PARTNER.    GT_PARTNER-PARTN_ROLE = 'WE'. "SHIP TO PARTY.    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'      EXPORTING        INPUT  = GV_SHIP_TO      IMPORTING        OUTPUT = GV_SHIP_TO.    GT_PARTNER-PARTN_NUMB = GV_SHIP_TO.    APPEND GT_PARTNER.    CLEAR GT_PARTNER.* Populate the Items of the sales order Simulate Bapi    GT_ITEM-MATERIAL = MATNR.    GT_ITEM-REQ_QTY = 1000.  " Here we want price per item hence we are passing only 1    GT_ITEM-SALES_UNIT = MEINS.    APPEND GT_ITEM.    CLEAR GT_ITEM.* Call the Bapi Simulate funcation module to get the customer price.    CALL FUNCTION 'BAPI_SALESORDER_SIMULATE'      EXPORTING        ORDER_HEADER_IN           = GV_HEAD*   CONVERT_PARVW_AUART       = ' '     IMPORTING       RETURN                    = GV_RETURN      TABLES        ORDER_ITEMS_IN            = GT_ITEM        ORDER_PARTNERS            = GT_PARTNER        ORDER_ITEMS_OUT           = GT_OUT.   " GT_OUT-NET_VALUE1 RETURNS ZERO!!!!!????    IF GV_RETURN-TYPE <> 'E'.*-- miscellaneous error handling...    ENDIF.ENDFORM.
Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Apr 30, 2012 at 05:34 PM

    You make a good point about the multiple users, but don't know if that is all the problem.

    Personally, I would suspect that there is sometimes a timing problem between the VK11 call and the next step. A couple of things come to mind... is the price there at some point, e.g., is it being put into the table at some point, and not lost completely? If so, I would try adding a read for the prices via Open SQL Select, perhaps with the bypassing buffer addition, to be sure that the data had made it into the tables from the VK11 call. And, you might consider adding a loop that tries x number of times, even inserting a wait up to nnn seconds if the first read fails, to be sure you retrieved a non-zero value from your pricing table before continuing to the simulate call. Sadly, that would just slow down an already slow process, but it might cure the zero value problem, which I believe is the result of updates to database not having completed before the next step from time to time, perhaps (as you mentioned) due to system load and the number of db updates queued at any one time. Would it be possible to do a commit work after the VK11 call without blowing away the process? The synchronous call success may mean only that the data has beens stored in the DB level buffer for update to the table? Have to consult the DB admins on that one.

    And, I would guess that you already know that the VK11 update and the simulate are looking at the same condition table(s)? There's no chance that pricing routine is causing simulate to look at different conditions that what is expected?

    Add a comment
    10|10000 characters needed characters exceeded

    • Clemens,

      I appreciate the idea. It's a logical idea, but for this particular lock, the lock arguments are super-duper-complex, so it would be a difficult look-up. Also, I feel like our SQL query loop of 15 times covers the same turf as looking at the locks in a much more simplified way. Thank you for your idea.

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.