### Symptom

The system calculates the condition amount using custom logic implemented in one of the following Business Add-Ins (BAdIs), but the decimal places are not displayed correctly:

- Define Alternative Calculation of Condition Amount in Document
- Define Alternative Calculation of Condition Amount in Document Item

### Environment

SAP S/4HANA Cloud

### Cause

During pricing, some currencies are involved that have more or fewer than two decimal places, for example:

- COP (Colombian Peso): zero decimal places
- JPY (Japanese Yen): zero decimal places
- JOD (Jordanian Dinar): three decimal places

In the system, all currency fields are represented with two decimal places, for example, JPY 112 is internally represented as JPY 1.12.

Most of the values are converted to the external representation before the custom logic is called, so that they can be used correctly in the custom logic.

This means the system multiplies JPY 1.12 by 100, which results in JPY 112 in the custom logic.

After the custom logic has been executed, the value is divided by 100. This means JPY 112 will be changed back to the internal representation of JPY 1.12.

The condition amount is not converted in this way.

If you would like to calculate the condition amount using a document currency that has more or fewer than two decimal places, you must implement the conversion of the condition amount in the custom logic manually.

Otherwise, if the system calculates the condition amount using a converted field, for example, a subtotal, this could lead to an incorrect value as the subtotal is converted but the condition amount is not converted.

The relevant parameter in the custom logic is **prcg_element_result_amounts** that includes fields, such as **conditionamount**, **conditionbasevalue**, and so on.

**Examples**

You would like to calculate the condition amount for a document item using buffer field **xworkd** for the condition amount (**ConditionAmountBufferXworkd**).

Therefore, you have created custom logic for the alternative calculation of the condition amount and assigned a corresponding routine number in your pricing procedure.

In this example, we use the transaction currency *Colombian Peso* (COP).

**1. Without enhancing the custom logic with the conversion of decimal places for currencies**

Just before the custom logic is called, the **ConditionAmountBufferXworkd** has a value of 18,765.98 and the system multiplies it by 100, which results in 1,876,598 according to the used currency and its decimal places.

The custom logic in the *Define Alternative Calculation of Condition Amount in Document Item* BAdI calculates as follows:

PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT = ITEM_RESULT_AMOUNTS-CONDITIONAMOUNTBUFFERXWORKD

...with a result of 1,876,598.

ITEM_RESULT_AMOUNTS-CONDITIONAMOUNTBUFFERXWORKD field is then converted back to 18,765.98 internally, but the PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT field is not converted back to 18,765.98.

As a result, it is still 1.876.598. In this example, the condition amount is too large by a factor of one hundred.

**2.** **Enhancing the custom logic with the conversion of decimal places for currencies**

PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT is not converted per default because it would lead to inconsistencies.

Therefore, you can enhance the custom logic with two manual calculations for the two conversions. You insert these before and after your custom logic:

*Manual calculation before custom logic:*

PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT = PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT * 100

*Custom logic:*

PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT = ITEM_RESULT_AMOUNTS-CONDITIONAMOUNTBUFFERXWORKD

...with a result of 1,876,598.

*Manual calculation after custom logic:*

PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT = PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT / 100

...with a result of 18,765.98

Right after the BAdI Implementation, the ITEM_RESULT_AMOUNTS-CONDITIONAMOUNTBUFFERXWORKD field is converted back to 18,765.98.

In this example, the condition amount equals the **ConditionAmountBufferXworkd **field.

**Note**If the system calculates the condition amount by using converted and unconverted fields, the calculation can lead to a completely incorrect result.

For example, PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT= PRCG_ELEMENT_RESULT_AMOUNTS-CONDITIONAMOUNT (unconverted, for example 1,000.00) + ITEM_RESULT_AMOUNTS-CONDITIONAMOUNTBUFFERXWORKD (converted as above from 18,765.98 to 1,876,598)...with a result of 1,877,598 (instead of 1,876,598 + 100,000 = 1,976,598)

### Resolution

To ensure that the condition amount is converted accordingly, enhance your custom logic manually with the following:

1. To determine the decimal places of the transaction currency (that is, the document currency), you add the following code snippet manually:

SELECT SINGLE * FROM i_currency INTO @DATA(ls_curx)

WHERE currency = @item_amounts-transactioncurrency.

2. To convert before the condition amount is calculated, you add the following code snippet manually:

IF sy-subrc IS INITIAL.

prcg_element_result_amounts-ConditionAmount =

prcg_element_result_amounts-ConditionAmount / ( 10 ** ls_curx-decimals / 100 ) .

3. To calculate the condition amount as required, you add your own logic manually:

// Do your calculation

4. To convert back the condition amount, you add the following code snippet manually:

prcg_element_result_amounts-ConditionAmount =

prcg_element_result_amounts-ConditionAmount * ( 10 ** ls_curx-decimals / 100 ).

5. To implement error handling, you can set a message manually, if necessary:

ELSE.

pricing_message = 'Your error message'

ENDIF.

### See Also

### Keywords

Conversion of Decimal Places, Currency, Cloud BAdI, CHANGE_CONDITION_AMOUNT , KBA , SD-BF-PR , Pricing , SD-BF-PR-2CL , Pricing (Public Cloud) , How To