Pricing Rounding Issue.

Hi Team,
I want to round my Amount and condition value to Integer level(Remove decimal and following two values)
E.g. my PR00 has value 110 for quantity 11 so my condition value will be 110*11 =1210. If i want to apply 1.9% discount on this using condition type ZXXX it would calculate it as 22.99. I want this value to be rounded off to 23 or 22 hence removing the last two digits on the right of decimal.
Also since SAP calculates % on the condition value as in above case it calculates 1.9 % on 1210, I have a requirement where 1.9% should be calculated on amount per unit in this case on 110 and then multiply it with the qty.
I hope I am clear with my explanation, and in case you need further infi, pls let me know.
Regards,
Anupam

Hi,
Check these notes,
Note 80183 - Rounding
Note 315792 - Group conditions of the same amount on item
Note 166952 - Rounding when distributing header conditions
I hope this helps you,
Regards,
Eduardo

Similar Messages

Pricing Conditions Rounding Issue

Currently, our system has two pricing condition types. ZP,ZD. The ZP conditions represent a base price and the ZD represent a differential(- discount or + surcharge). Both are based on the same hierarchy. ZP00,ZP01,ZP02.ZP03,ZP04. A ZP01 overrides a ZP00 and ZP03 overrides ZP00, ZP01,ZP02 and so on and so forth. All transactions are settled in USD. However, most of the time the ZP, ZDs are based on prices that extend out more than two decimal places. I am experiencing and issue because SAP calculates the ZP and ZD separately and is rounding each. For example the ZP or base price in this case is $2.245. This times quantity of 3,999Gal = $8,977.755. SAP rounds this to $8,977.76. SAP then calcs. the differential ZD $.0235X3,999Gal = $93.9765. SAP rounds to $93.98. This is a total price of $8,977.76+$93.98 =$9,071.74. However the unit price is ZP $2.245 + ZD $0.0235 = $2.2685. If you take this price multiplied by the quantity $2.2685 X 3,999Gal = $9,071.7315. So the actual total price is off by 1ct because SAP treats the ZP and ZD as two separate calculations. I have seen various ideas on how to fix, from creating another pricing condition, to user exits. I was wondering if there was a preferred method? Or if there is a simpler solution?

Good Evening,
1. Please review OSS NOTE 80183 regarding Rounding.
   Values calculated in pricing are always rounded to the amount of
   decimal places which the used document currency owns. As subsequent
   processing steps setup on this rounded value rounding differences can
   occur in the calculation of the price per unit or in subtotal line.
   To bypass such effects note 80183 describes possible solutions to
   reduce / bypass this effect.
   A few problems in rounding after applying note 80183, variant 2 have
   been recorded where it was recommended to use the formulas 919 and
   920 on all discounts and surcharges that appear before NETP and the
   problem was solved.
2. In transaction V/06 there is a field under header 'Control data1'
   which can effect how the system rounds off condition values during
   pricing:
   ->> Rounding rule
       The rule that determines how the system rounds off condition
       values during pricing. The last digit will be rounded.
Example
o In the standard rounding rule '_', values are rounded off according
   to business standards:
   10.454 -> 10.45 DEM
   10.455 -> 10.46 DEM
o In rounding rule 'A', values are always rounded up:
   10.459 -> 10.46 DEM
   10.451 -> 10.46 DEM
o In rounding rule 'B', values are always rounded down:
   1045.9 -> 1045 LIT
   1045.1 -> 1045 LIT
   In this example, the currency of the condition rate is Italian Lira.
   The Italian Lira does not have any places after the point.
3. Also check if the condition type is set as item condition as well
   as group condition in transaction V/06. What this means is that
   the system will calculate the value of the condition on header level
   and compares it with the sum of item values in the document.
   Any rounding difference (KONV-KDIFF) detected, will be populated
   in the line item with greatest value or in first line item if all are
   of equal value.
   In other cases where there is no adjustment because there is no
   rounding difference when comparing the header value and the sum of
   item values.
   ->> Solution to this scenario -
       If you remove the 'group condition' setting, the system will then
       calculate amount for the items directly and you will not get the
       rounding. You must decide which setting is more suited for your
       business. This is not a bug, but works as per designed.
       EXAMPLE: MWST - tax condition (a group condition)
                Item 10     16%   of 100.90 = 16.14
                Item 20     16%   of 100.90 = 16.14
                                       Total = 32.28
I hope this helps you!
Kind Regards,
Martina McElwain
SD Forum Moderator

Rounding Issue with Pricing Conditions

Currently we have in place a pricing hierchery that consists of two pricing conditions. ZP for base price and ZD for a +-differential. Both conditions begin with 00. ZP00. ZP01, ZP03, ZP04. If a ZP01 exists it overrides a ZP00. If a ZP03 exists it overrides ZP00,ZP01, etc. So basically the higher the number means it overrides anything underneath it. The ZD conditions are setup exactly the same way. I am currently running into a round issue. We settle all transactions in USD however the manual and differentials are often based on prices that go out more than 2 decimal places. SAP is treating the calculation for the ZP and ZD as two separate calculations. It rounds each of them and then combines for a total price. So if the base price ZP02 is $2.245 multiplied by quantity 3,999 = $8,977.755 which it rounds to $8,977.76 and the differential ZD02 is $.0235 this = $93.9765 which it rounds to $93.98 for a total price of $9,071.74. However if you add the ZD02 + the ZD02 you get a total unit price of $2.2685. This multiplied times the quantity 3,999 = $9,071.731 which is correct. But because SAP does each calc separately the price comes out to $9,071.74 or off 1CT. I have seen various solutions on how to fix this from user exits to creating additional conditions that takes both ZP and ZD conditions and calculates them as one but I was hoping someone had come up with something better? Or if there was a preferred method?

Currently we have in place a pricing hierchery that consists of two pricing conditions. ZP for base price and ZD for a +-differential. Both conditions begin with 00. ZP00. ZP01, ZP03, ZP04. If a ZP01 exists it overrides a ZP00. If a ZP03 exists it overrides ZP00,ZP01, etc. So basically the higher the number means it overrides anything underneath it. The ZD conditions are setup exactly the same way. I am currently running into a round issue. We settle all transactions in USD however the manual and differentials are often based on prices that go out more than 2 decimal places. SAP is treating the calculation for the ZP and ZD as two separate calculations. It rounds each of them and then combines for a total price. So if the base price ZP02 is $2.245 multiplied by quantity 3,999 = $8,977.755 which it rounds to $8,977.76 and the differential ZD02 is $.0235 this = $93.9765 which it rounds to $93.98 for a total price of $9,071.74. However if you add the ZD02 + the ZD02 you get a total unit price of $2.2685. This multiplied times the quantity 3,999 = $9,071.731 which is correct. But because SAP does each calc separately the price comes out to $9,071.74 or off 1CT. I have seen various solutions on how to fix this from user exits to creating additional conditions that takes both ZP and ZD conditions and calculates them as one but I was hoping someone had come up with something better? Or if there was a preferred method?

Sales Order Discount Pricing Rounding Error

When we use discount RA01 in our Sales Pricing / Orders it results in rounding issue that shows on Customer Invoice.
eg: Sales Order Conditions Tab
Product XXXX x 2 EACH
CnTy Amount (per ea)
PR00 $141.55 EA
RA01 10%
$14.16
Net Val $127.40EA
Total Condition Value (x Order qty)
PR00 $283.10
RA01 $28.31
Net Val $254.79
So what the Customer sees is the unit price of $127.40 and totol line cost of $254.79.
But $127.40 x 2 is obviously $254.80
It looks as though the discount is being calculated as 14.155, then the Net Value rounding from $127.395 to $127.40
Where as the TOTAL Net Value for the line is showing the $127.395 x 2 = $254.79.
How do we get this scenario to result in the Net Value Amount, and Net Value Condition Value multiplying correctly by Qty on the Order??
Thanks
Hayley McDougal

Hi Thenmozhi
Sorry for confusion, I am responding to your question above using a new Public logon, as the logon i used to raise this question has been locked, and SAP advise may take a few days to rectify. But I am hoping I can sort this issue ASAP.
The Requirements indicator for PR00 and RA01 is 2
The Calculation Type is PR00 = C (qty) and RA01 = A (%)
The Net Price, PR00 and RA01 are all set to Rounding = Commercial.
Thanks

Net price rounding issue in PO

Hi,
Please note that I am facing net price rounding issue in PO.
For. e.g.
In a PO line item of Qty 25 PC of base price 6 INR, there is a discount of 3.64 INR.
So gross price = 150 INR (25*6)
Net value = 150 - 3.64 = 146.36
No net price = 146.36 / 25 = 5.8544
When we round of two decimal places 5.85 INR (since INR is two decimal curr)
When we show in PO output we will show like below
Material X 25 5.85 146.25 (this is calculated by multiplying qty with net price of 5.85 INR)
So there becomes a difference of .11 INR due to rounding issue.
Net value in PO and PO output are differing. Net price of material & net value should match exactly in PO & PO output
without any differences.
Please throw your views.
Note: can we make discount condition statistical & take it to separate G/L account during GRN?
Regards,
Partha

Hi,
As per the note 80193 rounding, I defined a condition type NETP and it captures the rounding difference.
So now netprice (after discount) * quanity = netvalue (after discount) relationship matches.
But my concern is that the rounding difference is not getting captured in G/L accounts (neither in GR/IR clearing account nor in separate accounts).
Please throw your comments.
Partha

Unit price rounding issue

I'm from Australia. We have stock items some have 10% GST and some don't have. there is a rounding issue on SAP since 2005A. For example, we input $9.55 pre GST price ($10.50 is gst inclusive). When processing invoice, the gross price will display $10.51, a user has to change it to $10.50 manually. The more quanaity, the more rounding error. We check with our supplier, only temporary patch on it. Can standard SAP fix the rounding issue ?
Thanks
KC

normaly It will not happen .
have any add-on and FMS in same filed ? if not then make FMS to copy same data from Base document.
Thanks
Manvendra Singh Niranjan

Price Rounding Issue - AFS Pricing

Hello Friends,
We are facing an issue in sales order pricing & its subsequent effect in invoice. We use AFS pricing, where different grid sizes have its basic price.
We have a basic price condition which come thru a master record, and this can be overridden by a manual price condition.
When such manual condition is entered, it applies to all the quantity of the line item irrespective of the number of grid sizes.
So suppose I had 6 grid sizes in the line item (which also results into 6 schedule lines) list price will be shown across all the grid sizes, see DOC1
But when I enter a manual price EUR 7, it applies to the total quantity that is 6. So the net value in this case will be EUR 7, See DOC2
By calculation, 7/6 = 1.166666666666667
So when now I create the invoice, the value gets rounded for all the grid sizes & it becomes 1.17
Here when system calculate the net value it will sum up 1.17, six times & the resultant net value is EUR 7.02, see DOC3
As a result most of the time there is difference between the order value & the invoice value.
Please suggest what action should be taken.
Regards,
Dhananjay Borate

Dear Dhananjay Borate,
You can avoid this issue working this the following options:
Every Condition Type, in the "Control Data Box 1" have the option to apply a "Rouding Rule" with three different options:
Empty.
                     In the standard rounding rule '_', values are rounded off according to business standards:
                         10.454 -> 10.45 DEM
                         10.455 -> 10.46 DEM
"A"
                    In rounding rule 'A', values are always rounded up:
                        10.459 -> 10.46 DEM
                        10.451 -> 10.46 DEM
"B"
                   In rounding rule 'B', values are always rounded down:
                      1045.9 -> 1045 LIT
                      1045.1 -> 1045 LIT
Also you can use, in the "Gruop Condition ", the Rounding difference comparison.
         Indicator that controls whether rounding difference is settled for group conditions with a group key routine. If the indicator is set, the system compares the condition value at header level with the total of the condition values at item level. The difference is then added to the largest item.
Use the Conditons Types:
PDIF - Diff.value (own)
DIFF - Rounding Offwith the Conditions that apply to your needs. The standard gives this ones as examples: [Requirement: Routine 13 - Rounding as perT001R], [Condition Formula 16] and [Basis Type 4]
Regards,
Johnattan.

Rounding issue in pricing

HI,
system is showing different condition values(condition type PNTP) in sales order and Invoice..
Eg. material cost in Material master is 16.59 $ per 1000 PCS
here our ordering quantity is 10,000 pcs
in sales order it is taking amount as 16.59 per 1000 pcs and for 10,000 condition value is 165.90 $
but in invoice it is taking amount as 0.02 per 1 pc ( rounding the 16.59 to 1 pc i.e 16.59/1000 = 0.01659 = 0.02) and hence for 10,000 qunatity it is showing condition value as 0.02*10,000 = 200 $
here i am getting around 30$ different.. can you please help me in solving this issue...
are there any SAP notes available for this?
thanks,
sudhir

Hi,
Go to VK11 and save the condition record as 0.01659 for your condition type.
Or save the condition record as 16.59 per 1000.
Then go to V/08 and select your pricing procedure.
Over there remove the rounding of the condition type.
Also go to V/06 select your condition type and go to detail.
Over there just remove the rounding rule.
Now try to create the sales order and check the pricing.
One question do you want rounding should be done in the last of the pricing?
Regards
Raj.
Edited by: Raj Aryan Malhotra on Jul 16, 2009 1:25 PM

F&A Pricing Rounding

I have an issue related with the F&A pricing. I need to have gross price value to be rounded up to 4 decimal only , for which I have selected the correct rounding rule but still in the PO , value is coming as 6 decimal places. Can any body tell me what could be the reason and what need to be done?
Dipak Kadam

Hello Dipak,
Please ensure that you are seleceting the correct rounding rules for the field "term rounding rule" and "Currency rounding rule". Also ensure that you have selected the rate based Indicator tick mark in the formula. One more thing to ensure that you select the correct currency symbol for which no of decimal palces are allowed as expected by you.
Hope this will work. Let me know if you need any more info.
thanks,
Ritesh
Edited by: attarde2009 on Mar 28, 2010 3:26 PM

Rounding Issue Excise Invoice and Accounting document

Hi
I have made and Excise Invoice with following values
Base Price                          4110
BED    10%                           411
CESS   2%     on BED               8
HEC     1%      on BED              4
In the Excise Table J_1IEXCDTL also values for BED is updated as 411, CESS as 8 and HEC as 4
But in Accounting Documetn following values gets updated
Base Price                          4110
BED    10%                           411
CESS   2%     on BED               8.22
HEC     1%      on BED              4.11
So at times there is a difference in both Excise Invoice and Acocunting Document. We want same values should appear in Excise Invoice and Accounting Document. Since EXCISE does not accept value in paise, we need to round off the value to the nearest rupee and accordingly update the accounting document.
My Pricing procedure mentions Cal Type as 17 Rounder off as per T001 R for BED / CESS /HEC...
Please guide...
Regards
Sanjeev

Dear Sanjeev,
Check whether there is a Condition type DIFF in the pricing procedure, and also in the invoice (conditions)
Check whether there is any account key assigned to it, in the pricing procedure.
Thanks & Regards,
Hegal K Charles

Pricing date issue

Hello All,
We have an issue with the Line item pricing date.
In our project we are using the supersession functionality; we have one sales order with header pricing date ex: 25.12.2008 with some line items, for line item 10 we have created superesession material on 01.01.2009 with other material and maintained the pricing condition records validity date same as 01.01.2009.
We maintained in a way that if the material is not available and superseded material is available one job will run and creates the new line item with superseded material and copies the all information from the old line item. Here the problem is it copied the old material pricing date as 25.12.2008 due to this the new line item price is not calculated because the condition record is available from 01.01.2009 and it is disable mode.
Can any one give an idea how to solve the above issue.
Thanks and Regards
Srinivas Kapuganti

Hi Srinivas,
reading the answer above, there are 2 ways to solve your problem:
1) Modify the logic that determines the pricing date
2) Use the pricing reference material field (i.e. workaround)
Unfortunately in the landscape currenly i'm working, I haven't installed APO... So I cannot make any tests in a similar landscape.. however I can try to suggest to you something...
Concerning the "idea" N. 2 you have:
A) To check (from a "business point of view") if superseeded material and the new material have the same price.. I think so.. In the past I've worked as consultant in an A&D company and we have implemented supersession.. Usually, from a "commercial point of view" no impact on pricing must be "charged" to the customer because "supersession". So, usually, the superseeded material and the new one has the same pricelist...
B) From a "technical" point of view, try change manually the sales order updated by APO BOP and fill (manually) the field VBAP-PAMTN (item detail, tabstrip "Sales B") and, please, check if SAP determines the correct price condition record.
C) If test in point B is "ok".. I think that when BOP try to change the sales order, the userexit move_field_to_vbap will be called (include MV45AFZZ).. If you are able to understand to which "old" SO item is referred the new one, you can use this exit to fill VBAP-PMATN field of the new item with the superseeded material code (the old one)....
Advantage:
1) You don't have to change the program called by RFC from APO (maybe it requires an out of standard solution? I don't know..). You have "only" to implement an userexit..
2) SD pricing date will be, also for the new item, the 25.12.2008; but, in this case, SD will be able to find (via PMATN field) the pricing condition record linked to the superseeded material. This solution is Ok if hypotesis in point A) is correct. Otherwise it make no sense.
Sorry for quite long answer. Hope this help.
Have a nice day - Massimo

PO Rounding Issue

I have an issue with POs rounding up the unit when in days and subsequently calculating the value of the PO based on the rounded up figure.
In summary, when a half a day is selected on shopping cart for services, the shopping cart calculates the values based on the unit entered. So for example: 3.5 days for Consultancy @ £1,000 per day is calculated as £3,500 on the shopping cart. Which is correct.
However, when the PO is raised, the 3.5 days are rounded up to 4 days, and this results in the PO value been calculated based on 4 days, hence £4,000. This issue seems to only occur when selecting half days as your unit.
Has anybody experienced a situation similar to this, or have any suggestions?
Any help would be greatly appreciated.
Regards,
Shahzad.

Hi
For a line item , you have a price and a unit/value... the multiplication of both results in the final line item price...
say 0.5 days and 100.10 USD
then
0.5 * 100.10 => 50.05
If the result equals to or exceeds 0.5, then it's rounded off to the next upper limit
In this case, the result will be 50.1 (not 50.05 )
<b>----
*---- Temporary work around can be inside the BADI, you can change the value as you wish...
The BADIs which can be used here are
Incase you are using Extended Classic Scenario in EBP System.</b>
BBP_CREATE_BE_PO_NEW Exit while creating a purchase order in the backend system
BBP_CREATE_PO_BACK OLD Exit while creating a PO in the backend system
BBP_ECS_PO_OUT_BADI ECS: PO Transfer to Logistics Backend
BBP_EXTLOCALPO_BADI Control Extended Classic Scenario
<b>Please raise a message with SAP to look into it.</b>
Hope this will help.
Please reward suitable points.
Regards
- Atul

Production order Unit of Messure-decimal rounding issue

Finished product is a Metal conveyor belt.
Material Base UoM is Links u2018LKu2019
Alternative UoM are:
10 link = 1 Feet
1 meter = 3.2808 Feet
Plant X800, (MTO) Sales orders created in meters. So production orders in Meters (MM02->work scheduling view->Production unit & Unit of Issue maintained in Meters)
Now Issue is:
If production order is 10 meters, this is converted to 328.084 LK. Physically shopfloor receives only 328 LKs after production.
Links cannot be in decimals. Inventory and Costing is done u2018per Linku2019.
This needs a decimal rounding to u20180u2019 value. Expectation will be 328 LK.
If the value is 1.49 then the rounding value will be u20181u2019 (< 0.5)
If the value is 1.5 then the rounding value will be u20182u2019 (>0.5)
Please help me. Is there a config Setting or a work around (user exit)?

Your requirement cannot be fulfilled by customization. Nor it can be perfectly implemented though BAdI's or Userexits.
The settings in CUNI only hide the decimal zeros but it won't prevent either users or programs to enter decimals. in R/3 quantity field uses the domain MENG13 so in your case, in the production order it will always display in decimals (eg 328.084 LK) .You can refer to note for more understanding about CUNI settings and IM postings 931971
Also the following threads:
UOM EA is taking data in decimals
The solution (this is more of workaround) I would suggest is you need to implement a BAdI WORKORDER_GOODSMVT in which it will round off according the logic you mentioned in your posts above. Also you need to implement a user exit for CO11N/CO11/15 to confirm the same yield according to the same rounding logic. Since yours is MTO you need to evaluate the impact of this in other areas mainly controlling and finance.

Pricing Computing issue..

Hi,
In the pricing procedure, I made two condition type is statistical.
During the net value calculation it considers the statistical condition type values also.
Strange, can you suggest, is there any other place other v/08, do we need to maintain statistical value?
Little urgent issue.. help need

Hi,
Thanks for your effort.
But, I can't restructure my pricing procedure.It should be the same way what i mentioned.
You guys say, if I mention 50 to 80, it will consider the statiscal value also?
New apporach
I created a new alternative calculation type and attached to nete value calculation. which will calculate 50 +60 +80.
But, why SAP strangly behaves?

Pricing calculating issue

Hi,
I have a specific issue regarding pricing:-
The requirement is that the following entry should be passed in accounting while billing:-
Dr. Revenue 100
Cr. AR 100
Dr. Cost of sales 5
Cr. TAX payable 5
For this requirement we have maintained a condition of TAX in pricing, assigned accrual key & account key & it is determined on net price. We have also assigned G/L (both columns) for the same in VKOA.
I copied from WUST as ZWUS, and checked it as accrual conditon type. and the GL documents are created successfully.. BUT no accural account is hitting for Dr. Cost of sales 5
Cr. TAX payable 5.....
Pls help !!!

Hi,
Can you confirm whether you have maintained the Accrual account key in V/08 for the TAX condition type.
For Account key (ex. ERB), you should maintain the G/L account in VKOA.
For Accrual you should maintain the G/L account and Provision Account.
For your reference you can check the Rebate condition types BO02 in Pricing procedure RVAA01 in V/08 and also check the Account Assignment in Account key combination in VKOA.
Hope this info will solve your problem.
Regards
M. Lakshmi Narasimhan

Pricing Rounding Issue.

Similar Messages

Maybe you are looking for