Rounding issue?

Business created a specific purchase order consisting of material and returned material (credit memo):
- Pricing condition consist in PBXX gross price and NAVS VAT non refundable.
- After entering the material, when we try to simulate and pre save the invoice with MIR7 there is an error which consists in a sold between credit and debit. -0,03 preventing from having the invoice.
I noticed that when the VAT amount in the order is entire like 115 or 1023 system fonctions.
So I checked the rounding in the condition type but with no effect.

Dear ,
To achieve this go to OBYZ -> Procedures
Select the tax procedure you are using say TAXINN
Here for all your ED conditions type
Like JMOP,JMX1 for BED
JAOP,JAX1 for AED
also for all condition type E Cess ,HE cess ,VAT ,CST assign CalType  --> 17 (Rounding As per T001R)
And save
Now go to SPRO-> IMG->SAP NetWeaver ->General settings ->Currencies ->Define rounding rules for currencies->
OR use OB90 directly
here maintain a entry For your company code ,Cureency (INR), Rounding unit (100)
Save the entry
Now try to run a new cycle you will find system is rounding off all the tax amounts
Please check and revert

Similar Messages

  • 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

  • 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?

  • 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

  • PO Rounding Issue

    I have an issue with PO’s 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 day’s 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.

  • KF rounding issue

    Hi,
    I have a query based on a cube which deals with sales data. In this query a lot of calculations are done based on a small number of base key figures.
    As a simple example, turnover (500) devided by quantity (1000) should lead to a price of 0.5.
    A week ago I had to add some more calculations and since then all values get rounded. It looks as if the result is no longer a decimal but an integer instead.
    The above example now gives me 1 instead of 0.5
    Nothing else was changed, just adding some further calculations. Also the base data has not changed. It's a development system where the last data import was in august, 2009 so the data in the cube is correct.
    Also if I adjust the formula to: turnover/quantity*1000 the result is 500 (according to the example of the beginning). So for some reason the calculation is done with correct values but the presentation has changed.
    I have no clue how to solve this...
    Please advice.

    Hi,
    thanks for the hint but this doesn't help either
    Maybe it wasn't clear enough in my first post:
    It's not one formula, it's any in this query. Except for the new KFs all of the values rounded now were presented as decimals before.
    Very strange...
    I had this issue once before and could not solve it. The "workaround" was to create a new query and built it again from scratch. But also this didn't help this time.
    Regards

  • 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

  • Formatted Search Rounding Issue

    Hi everyone,
    I have a slight issue. I have defined a formatted search on the A/R Invoice that calculates the item price based on a user defined field. The problem is whenever the formatted search runs, it rounds the figure to two decimal places. For instance; the query is supposed to divide a value you put in the user defined field by 50 if you put in 2.25 the value you get is 0.04 instead of 0.045. The query i've used is as below.
    Please assist.
    SELECT (CAST($[$38.U_pprf.0] AS DECIMAL)/50)

    Hi Duncan,
    Try this FMS in UDF2. you will be get the exact value in UDF2.
    for Example:
    *Create 2 UDF's
    UDF Type -> Unit and Total.
    UDF Structure -> Price (or) Amount.
    UDF1 -> U_pprf
    UDF2 -> U_Item_Price
    UDF1 = 2.25
    UDF2 = 2.25/50 => 0.045
    SORRY Last Query is not correct because that Query will not get Exact Result.
    If you want exact value. Try the below Query.
    First Assign the below Setup.
    ->> Administration.
    ->> System Initialization.
    ->> General Setting. -> Display Tab.
    Assign the Decimal Places  (0..6) value.
    Price (or) Amount -> 3
    IF you assign the setup of Price (or) Amount = 3 in Decimal Places.
    Result: 0.045
    IF you assign the setup of Price (or) Amount = 2 in Decimal Places.
    Result: 0.05
    Query: 2
    declare @UDF as numeric(19,6)
    set @UDF = $[PDN1.U_pprf]
    select  (@UDF/50)
    Result: 0.045
    Assign this FMS in UDF2 and Auto Refresh of U_pprf
    Regards,
    Madhan.

  • Deployment rounding issue

    Dear Friends,
    After running deployment for purchase requisitions coming from PP/DS I am getting message:
    Deployment stock transfer was not confirmed (                                             11,000 <           40,000 (rounding value))
    Here 11 is PR quantity and 40 is rounding value. Some PRs are not getting converted in deployment orders and so getting material shortage. We want system to upsize PR(purchase requisition) qty to rounding value in this case.
    Please suggest any note,setting,user exit or BAdi to do this.
    Thanks in advance.
    Best regards,
    Shirish

    Hi Amol,
    Thanks for reply. My problem is diffrent I have sufficient ATD quantity and all settings are maintained properly. Say purchase requisition quantity is 130 EA and rounding value is 50. Then after deployment run I am getting order of 100EA and for remaining 30EA we are getting open PR which will not get convert in to deployment order. So there will be always shortage of 30 in ECC. I want system to round up quantity to 150EA.
    Hope you have understand issue. Kindly let me know fir more information.
    Thanks,
    Shirish

  • 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

  • Rounding issue in CRM and R/3

    The question is – Is there a standard way  to  switch on the same functionality in CRM as done in R/3 for rounding the quantity at order entry .
    The  configured material   will generate rounding in multiples of defined figure eg 500   , Due to the Rounding Profile  used in material master
    meaning that if you maintain any of the fields below in Material Master, Sales Org 1 view, R/3 will automatically adjust the quantity at order entry according to the rounding rules.
    Note that the rounding profile can be set up in Cust Mat Info record .
    Any suggestion is appreciated .
    BR//Ankur

    Hi Ankur,
    Did you get any solution to the above. We have also a similar requirement to use the rounding profile. Any help is appreciated.
    Thanks
    Sayan

  • Purchase Order Rounding Issue

    Hi
    I want to round the Purchase Order qty based on the Info Record Standard Qty.
    Example
    If standard Qty = 50LB in Info Record.
    If MRP generated the requisition for 100Kg (in material master Base UOM = KG and Order Unit = LB)
    when we converting the PR to PO, system should round the PO qty to 250 LB (multiples of 50)
    How to do this?
    IF i'm wrong, Please suggest where we can do this setting.
    Please suggest me ASAP
    Thanks for your help in advance
    SUNIL

    hi,
    Go to Material master ---> Make your material for the View MRP1 --> In it enter the rounding value as 50...and then save...
    Now the values will in the multiples of 50...
    Hope it helps..
    Regards
    Priyanka.P

  • SUM function not working correctly (not a rounding issue)

    OK.
    So in the E-column, I have a list of statistics going from E4 through E11. E12 is supposed to give the sum of the preceding numbers within that range.
             E
    4     34000
    5      7000
    6      7000
    7    30500
    8      7000
    9      3000
    10          0
    11    1500
    The sum of these numbers should appear in the next row, E12, where I have the formula: "SUM E4:E11". However, whereas E12 should be giving me $91,000, it's instead giving me $57000. There's nothing that I can see that is wrong with my formula. If I modify one of the cell amounts, the 57000 will change by the amount I changed the cell. But there's no reason on earth it should be giving me 57000. I thought maybe there is an issue with how large a cell number can be, but if I change the 0 to a 1 in E10, it outputs 57001 to E12.

    I cannot confirm your problem.
    When I add: "34000+7000+7000+30500+7000+3000+1500" in the spotlight (top right of the menu bar),  the total of is 90,000
    Using Numbers, I also get 90,000
    =SUM(E1:E8)
    There is something wrong with your data.
    Please post a screenshot

Maybe you are looking for