Hi,

I would like to share a small configuration regarding the rounding off for the condition types in pricing. Case 1 explains how to round off a condition value directly and Case 2 explains how to round off and post the rounded value to separate GL.

Let us discuss the scenarios in detail:

Case 1: How to Round off the condition values:

You can round off particular condition values based on the rounding figures, like 10th place, 100th place etc. For example, suppose you have a condition type, say ZMOP. The client requirement is to round up the condition values for this condition type to two decimal places.

The configuration steps are as follows. (The same is applicable in case of MM pricing procedure as well as tax procedure.)

1. Maintain the rounding rule in the condition type (M/06 or OBQ1) as shown. It could be round up or round down.

2.  Maintain the calculation type “17” in the pricing procedure.

3. Now Maintain the rounding rule for the company code in the transaction OB90.

If its 100, the value will round off to 100 place, means the 2 decimals will be rounded off to upper or lower  value based on the condition rule specified in condition type.

After these configuration steps, you can test the scenario. The values for the respective condition types will be rounded off accordingly.

Example: Condition value before the above settings:

Condition Value after the settings made:

Case 2: How to round off and post the Rounding Difference to separate GL:

If you want to post the rounded value to separate GL, you may proceed with below steps: Here. there will be different condition types for capturing the rounding values.

1. Create a new condition type, say Z001 (in OBQ1 or M/06 or V/06 or similar) for rounding off value.

•      Maintain the condition class as D if its tax condition type. Else, maintain it as A.
•      Maintain the access sequence if its tax procedure. Else, keep it blank.

2. Create a new condition type (in OBQ1 or M.06 or V/06 or similar) for rounded value – You can copy the parent condition type which is to be rounded and change the key.

•     Suppose we need to round off JMOP condition and post the difference to separate GL. Then copy JMOP and create a new condition, say ZMOP.
•     In this example, JMOP will show the value without rounding and ZMOP will show the value after rounding.
•     Maintain the access sequence for the new condition type. We will be maintaining the condition record as 100% for this condition type.

3. Go to the Calculation schema (Tax procedure or MM/SD pricing Procedure) and maintain the condition types in the procedure, as below.

•     Z001 is the condition type to post the rounding difference.
•     ZMOP is the condition type to calculate the value of the parent condition type JMOP after rounding off.

• Calculation type 16 will bring only the round off value, based on the OB90 (configuration explained in case 1).
• The parent condition type is made as statistical in the pricing procedure.
• Now, the system will split the value of the parent condition type (JMOP in example) to ZMOP (rounded value) and Z001 (Round off value).
• Maintain the account key / acruel key for the new condition types depending on tax procedure / pricing procedure.
• Maintain the step number (from and to) accordingly.

Save the procedure.

4. Maintain the GL account for the account keys.

5. If its tax condition type, maintain the condition record for the round off condition type (Z001) as 100% in FV11.

6. Maintain the condition record for the rounded value condition type (ZMOP in example) as 100%.

7. Test the scenario with a new PO:

Result:

The condition value (12.06 in example) for the condition type (JMOP in example) is splitted as round off value ( 0.06-) and rounded value (12.00). The splitted values will be posted to the corresponding GL.

MIRO GL Postings:

Note: Same procedure (Case 1 and Case 2) is applicable for all similar scenarios in MM / SD / Tax procedure.