Using BAPI_PRICES_CONDITIONS for modification

[Former Member]

Hi,

To update coditions, I use BAPI_PRICES_CONDITIONS (update table A004 and KONP)

tn_bapicondct-operation = '023'.

tn_bapicondct-table_no = '004'.

tn_bapicondct-cond_no = '0000016926'.

tn_bapicondct-cond_usage = 'A'.

tn_bapicondct-applicatio = 'V'.

tn_bapicondct-cond_type = 'PV00'.

tn_bapicondct-varkey = 'OC0102000000000002146041'.

tn_bapicondct-valid_to = '20080131'.

tn_bapicondct-valid_from = '20050517'.

APPEND tn_bapicondct.

tn_bapicondhd-operation = '023'.

tn_bapicondhd-table_no = '004'.

tn_bapicondhd-cond_no = '0000016926'.

tn_bapicondhd-created_by = sy-uname.

tn_bapicondhd-creat_date = sy-datum.

tn_bapicondhd-cond_usage = 'A'.

tn_bapicondhd-applicatio = 'V'.

tn_bapicondhd-cond_type = 'PV00'.

tn_bapicondhd-varkey = 'OC0102000000000002146041'.

tn_bapicondhd-valid_to = '20080131'.

tn_bapicondhd-valid_from = '20050517'.

APPEND tn_bapicondhd.

tn_bapicondit-operation = '023'.

tn_bapicondit-cond_no = '0000016926'.

tn_bapicondit-cond_count = '01'.

tn_bapicondit-applicatio = 'V'.

tn_bapicondit-cond_type = 'PV00'.

tn_bapicondit-scaletype = 'A'.

tn_bapicondit-scalebasin = 'C'.

tn_bapicondit-scale_qty = '1'.

tn_bapicondit-cond_p_unt = '1'.

tn_bapicondit-cond_unit = 'UVC'.

tn_bapicondit-calctypcon = 'C'.

tn_bapicondit-cond_value = '2.09'.

tn_bapicondit-condcurr = 'EUR'.

APPEND tn_bapicondit.

I want to modified an existing condition number to update DATBI and Condition value (KONP-KBETR). But the only update, after launching, is the condition value, the date (valid_to) is not updated. Why ?

Thanks for all of the responses.

Henry

[Former Member]

Check this FM which is also used for updating pricing - CND_PRICES_CALL_BAPI

[Former Member]

Ok,

I try tu use this function.

Thanks

[Former Member]

> Check this FM which is also used for updating pricing

> - CND_PRICES_CALL_BAPI

This function module just calls the BAPI_PRICES_CONDITIONS under the covers (as implied by its name), and is less flexible than calling BAPI_PRICE_CONDITIONS directly, so I am not sure that this suggestion is very helpful.

In any case, BAPI_PRICES_CONDITIONS is not released to the customer, and I am aware of at least one known bug (which occurs in rare circumstances), which you cannot get help from SAP on (for the reason that it is not released).

To get around the bug requires making a minor change to a FORM in the function module, either by copying it to a Z function module, or making a direct change using SSCR.

This is only necessary if the BAPI is being used under the circumstances which trigger the bug (which causes a hard error and a short dump).

Based on your description of how you are using the BAPI, you should not encounter the error, which occurs only when multiple different condition tables are being updated one after the other.

Good luck

Brian

Message was edited by:

Brian Sammond

[Former Member]

This question is for Brian Sammond.

You mentioned that in order to handle the bug in FM,

we need to

"To get around the bug requires making a minor change to a FORM in the function module, either by copying it to a Z function module, or making a direct change using SSCR."

Do you know what modification we need to make in the FM?

Thanks.

Lily

[Former Member]

Lily, I am sorry I did not see your question sooner. Here is the answer that you were seeking.

The change that is required is in FORM get_vakey_old in Include LCND_PRICES_INBOUNDF0G.

This is for version ECC 6.0, but the same fix also applied in earlier versions.

Look at lines 59 thru 62 in the original in this release. You need to add the line

CLEAR sv_offset_kfrst.

before

LOOP AT lt_t681e_fields INTO ls_t681e_fields.

or the offset will be wrong on second and subsequent calls when a change in the buffering condition occurs. Such a change is controlled by the following:

*------------------------ CHECK BUFFER ---------------------------------
  IF sv_kvewe IS INITIAL OR
     sv_kvewe NE pi_vakedb-kvewe OR
     sv_kotabnr NE pi_vakedb-kotabnr.

The following is the change in context:

* read offset for KFRST
    CLEAR sv_kfrst_exists.
    CLEAR sv_offset_kfrst.  "*****This is the line that needs to be added****
    LOOP AT lt_t681e_fields INTO ls_t681e_fields.

The problem is that the FM sets up a buffering mechanism, and the buffering mechanism must be reloaded under certain circumstances. However, to do this successfully the offset must be first reset, and that was missing.

If you do not do this, and call the FM repeatedly with different tables etc being updated, you will eventually get a short dump with "GET_VAKEY_OLD" "DATA_OFFSET_TOO_LARGE" as key words.

Brian

Edited by: Brian Sammond on Oct 12, 2011 12:14 AM

Fix spelling etc

[former_member314455]

Hello,

FM 'BAPI_PRICES_CONDITIONS' has a major problem-

It does not delimit the dates of condition records. For example: If you have a condition record valid from Nov-16-2011 till Dec-31-9999 and if you create a new record for the same VAKEY with validity from Nov-20-2011 till Dec-31-2011, FM does not delimit the date of previous condition. This is not desirable. If you create your condition from VK11/MEK1, system will always delimit the dates.

I would suggest you to use COND_A Idoc / RV_CONDITION_COPY & RV_CONDITION_SAVE & RV_CONDITION_RESET.

Regards,

Ajith

[Former Member]

Hello,
> 
> FM 'BAPI_PRICES_CONDITIONS' has a major problem-
> It does not delimit the dates of condition records. For example: If you have a condition record valid from Nov-16-2011 till Dec-31-9999 and if you create a new record for the same VAKEY with validity from Nov-20-2011 till Dec-31-2011, FM does not delimit the date of previous condition. This is not desirable. If you create your condition from VK11/MEK1, system will always delimit the dates. 
> 
> I would suggest you to use COND_A Idoc / RV_CONDITION_COPY & RV_CONDITION_SAVE & RV_CONDITION_RESET.
> 
> Regards,
> Ajith

The problem you note is easily remedied, and I have done so in applications where I have used the FM 'BAPI_PRICES_CONDITIONS' without any difficulty.

You simply do a multi-step update, where you adjust the existing condition valiidity dates, and then update with the new conditions. This is what the system itself appears to do behind the scenes in VK11/Vk12 etc.

Your suggestion to use the RV_CONDITION_COPY and related modules is interesting, but it appears that RV_CONDITION_COPY uses dialogs, whereas you can simply do an update without a dialog using FM 'BAPI_PRICES_CONDITIONS' . I have not looked at RV_CONDITION_COPY in depth, however. What is your esperience with it?

Brian Sammond

[ferry_lianto]

Hi,

Please try to add BAPI BAPI_TRANSACTION_COMMIT after calling BAPI BAPI_PRICES_CONDITIONS.

Regards,

Ferry Lianto

[Former Member]

Hi,

The BAPI_TRANSACTION_COMMIT is used after BAPI_PRICES_CONDITIONS