Decimal places in database

Hi all,
Please can you make B1 do all calculations and store all data in the database to the maximum number of decimal places, and then let users pick to how many decimal places to view on screen?
At the moment, if I only pick 2 decimal places, the database saves and calculates values to 2 decimal places, so in long marketing documents causes mis-pricing of things like tax/VAT.
Current option is to set everything to 6 decimal places, and use round(xxx,2) in PLD, but this makes the user's B1 screen in marketing docs etc very very ugly
Thanks
Rajiv

Hi there,
Firstly, thank you for looking into this, it is appreciated. VAT is at 17.5%:
Invoice contains:
Item A x1
Price 2.22
VAT 0.3885 (4dp)
VAT 0.39 (2dp)
Item B x1, Item C x1, and Item D x1 - all like Item A
In this scenario, VAT on Items A,B,C, and D.
With 4 dp - 0.3885 x4 = 1.554 -> 1.55
With 2 dp - 0.39 x 4 = 1.56 -> 1.56
So there is a difference of one penny in this mock scenario.
Hence, all calculations should be done and stored to the full 6dp within the database, however, the end user should be able to choose how many dp to view "on screen" as it were.
Does this make things clearer?
Rajiv

Similar Messages

Error while updating decimal places in general settings

Hii All
         I have got an error while updating Decimal places in General Settings
Cannot update while another user is connected to the company i have checked, there is no other user logged in, i could add other settings but the problem is only with Decimal Places
Note : there are no postings yet, a fresh database for a new client
         what could be the possible reason
                                                             thanks
                                                                     RIYAZ

Hiii All
      As a forum rule, i have initially gone through with the existing threads and then i was force to post a thread,
          would be helpfull if there is any other way..
                                            Thanks
                                                     RIYAZ

Error message when updating decimal places in general settings

Hello together,
I got a big problem with the settings of decimal places.
I know that I am only be able to incerase these but it's a virgin database for a customer with no data imported.
Everytime I want to increase the prices decimal places I get the following error message:
"cannot update while another user is connected to the company"
But I checked all sessions connected to this database. I am the only person that is logged in.
I closed the db more that one time but it doesn't work.
Can you help me please?

Hello Meike,
I have had this problem a while ago and it was caused by the RPD-connection i had made with the customer server.
I had to change the values directly on the client machine.
Hope this also your solution.
Kind regards.

Issue with display of decimal places

Hi,
In our custom built components we are facing a strange issue with the display decimals where the data type of an element is "QUAN - Quantity field, points to a unit field with format UNIT".
If the element has a value of 3000.000 KG the value is displayed as 3000. Where as for an element which has a value 3000.123 KG the same is displayed as it is with the decimals. We tried to resolve the issue by using Text editor or Input field as read only but in vain. The display property in the context are set to default.
If we change the element data type reference to "Dec - Counter or amount field with Comma and Sign" then all the values are displayed with the decimal places even if decimals are zero.
As a result we are facing alignment issues for the various quantity related elements displayed on the screen. To change the underlying data type of the element is a not a solution for us as the data type quan is required for conversion from one unit to another unit.
Can someone please advise how we could resolve this issue. We are on NW 7.0 + EHP4 + NW 7.01 SP4, kernel patch level 55 for 7.01
Regards
Rohit Chowdhary

Jameel, Thanks for the answer but this is a not a solution for us. We have around 40-50 webdynpro components and with mutliple views referring to this data element / domain combination. More so the context are bound to database tables / structures .
I hope to get a reply from Thomas on possible solution for this. I am not sure if I can open an support ticket for this issue.
Rohit Chowdhary

Decimal places in MD04

Hi
In MD04 , we are getting decimals for the quantity. Is there any settings or config change involved to remove display of
decimals.
Regards
Mani

Dear,
If the database contains an amount with decimal places for an MRP element, the system also displays this value this way in MD04, because this is the value relevant for MRP purposes.This does not depend on the settings for the unit of measure in transaction CUNI (table T006).In case of values without decimal places, the system displays the value according to the setting in the unit of measure (T006-DECAN).Therefore, the decimal places of the MRP elements can vary. Check CUNI setting for rounding the values.
Regards,
R.Brahmankar

Decimal Places in Hyperion Enterprise

Since upgrading to Hyperion Enterprise 6.5.1, we have lost the ability to see any values beyond the decimal point. I can go to View and select decimal places, but it used to appear in the bottom right corner of the Data Entry screen as Value: 7195.1548869 now all I get is Value:7195
Does anyone know how to get that Value to show all the decimal places?

Hello,
During operation, you must neither delete currencies used nor change their definition of decimal places. Amounts in posted documents could become invalid or incorrect as a result.
You cannot subsequently use R/3 standard functions to make a consistent change to the number of decimal places of a currency in the R/3 system that is already operatively used because the system interprets all amount values on the database according to the number of decimal places of the reference currency that is stored in the system.
Prase

Decimal Places in Currencies

Dear gurus,
What is the decimal places in currencied?
how it works in table tcurx.
Regards
R.Rajendran

Hello,
During operation, you must neither delete currencies used nor change their definition of decimal places. Amounts in posted documents could become invalid or incorrect as a result.
You cannot subsequently use R/3 standard functions to make a consistent change to the number of decimal places of a currency in the R/3 system that is already operatively used because the system interprets all amount values on the database according to the number of decimal places of the reference currency that is stored in the system.
Prase

Select amount field of a table with decimal place of 3rd value grater than 0.

Select all the reord in a table with amount decimal place of 3rd value grater than 0.

Can you show the sample data + desired result?
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

Number with more than 10 decimal places display as 0 in report

We have a number stored on a table as this long with several decimal values.
2440.159999999999854480847716331481933593
On one PC it display in a Crystal report as 0 and to another user it displays at the 2440. The report formats the display field with 0 decimal places.
Is there a max precision setting at the database level that is causing this?
It seems I can add an SQL express as follows:
Round ("ORDER_RELEASE"."TOTAL_WEIGHT", 2) to resolve the issue but cannot determine could be causing the differences in display among two different client PCs running the same report.

Hello,
CR was built using C++ and therefore the max number is 15 digits plus 1 for the sign of the number.
Cause could be different runtime of MS C++ but hard to say for sure. I any event the only work around is to use Store Procedure and break the field into 2 parts. The in CR add a text object and drop the fields into it next to each other. For doing any calculations on them you'll also have to do that in the SP or handle each field manually.
Thank you
Don

ToGB() decimal places

Hi All,
I have this piece of code which outputs the values to a html file.
(get-mailboxdatabase)|foreach-object {
$database= $_.name
$accounts= (get-mailbox -database $_.name).count
$size = (get-mailboxdatabase $_.name -status).databasesize.ToMB()/1024
    add-content $wfile "<tr>"
    add-content $wfile "<td align= 'center'>$database</td>"
    add-content $wfile "<td align= 'center'>$Accounts</td>"
    add-content $wfile "<td align= 'center'>$size</td>"
My issue I can't get the size to output to 2 decimal places it outputs 8 decimal places.
If I use ToGB() instead of ToMB()/1024 I only get the whole number
I have tried using {N0:02} but it doesn't help
What am I doing wrong?
TIA
Andy

How are you applying the format string?
$size = '{0:N2}' -f ((get-mailboxdatabase $_.name -status).databasesize.ToMB()/1024)
[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

Changing Decimal places in table TCURX

Hi There
We have a business requirement to change the decimal places in table TCURX from 3 Decimals to 5 Decimal places. No previous postings have been made in foreign currencies.
If no transaction data has been posted in foreign currencies yet, will this have an impact?
What will the impact be?
Regards

Hi,
Refer to this SAP text:
In the R/3 System tables currency fields are stored as decimal figures with a variable number of decimal places. The decimal point is not stored in the field in the database. Instead, each currency field refers to a currency key field. In this transaction you assign the number of decimal places to this currency key uniquely. Example: If you have set currency USD to have two decimal places and you post an amount of 100 USD, an amount of 10000 USD is stored in the currency field in the database. Not until this
amount is processed further or is output does the system use the currency key from the reference field to determine the number of decimal places via this table. In this way the table content can be interpreted correctly for further processing or formatted for output with the correct punctuation. If after posting you changed the number of decimal places for USD, for example, to 3, the existing field content of 10000 would be interpreted for futher processing or output as 10 USD (10.000). This would mean that the contents of tables across the system would, for all currency fields containing an amount in USD,
be interpreted incorrectly by 10 per cent. To change the number of decimal places for a currency already in use, you must convert all the tables in the R/3 System that contain currency fields, so that the data integrity remains. This cannot, however, for both organizational reasons and under the runtime
aspect be carried out in a productive system. The following changes to the TCURX table can
thus lead to the loss of data integrity if you make the changes in a productive system or transport them into a productive system:
o Change to the number of decimal places of an existing currency
o Deletion of an entry from the TCURX table (corresponds to changing the decimal places to the standard value of two decimal places)
o Insertion of an entry in the TCURX (corresponds to changing the standard value of
2 decimal places to a different value), if this is a currency code that already exists
Uncritical changes are any made to this table during the Customizing of a new installation or the insertion of TCURX even during operations, if the currency codes have just been entered in the TCURC table using transaction OY03, signifying that no postings to these currency codes can have been carried out yet.
Regards,
Eli

Changing of decimal places from 2 to 6 digits

Hi,
Currently, our PO price and GR/GI quantities are being limited to two (2) decimal places only. However, we want to maintain it into six (6) digits so that we can have a more accurate PO price and GR/GI quantities in our record.
We tried to do this in Tcode OY04 but the system issued as the following warning messages:
1. In a productive system, you must not delete the currencies in use or change the decimal places. This could make amounts in document already posted incorrect or invalid.
2. In the R/3 System tables currency fields are stored as decimal figures with a variable number of decimal places. The decimal point is not stored in the field in the database. Instead, each currency field refers to a currency key field. In this transaction you assign the number of decimal places to this currency key uniquely.
Can you please explain to me the warning messages further?
Thank you.

Hi Jack,
Please never try to change the decimal places in PRD system, you will be in deep deep trouble.
Let me give one example , If the current decimal is set to 2 digit and you are going to change it 3 digit, then USD 100.00 will become USD 10.000 for the already posted document.
Please not that, the decimal places are not sotred in the database, when you run a tcode to see any posted data the system queries the currency table and see the value for the decimals, if it finds 3 in OY04, it simply places the decial point afer 3 digit from right, if the decimal is set to 4m it will simple place the decimal point after 4 digit from right.
Hope this clears your doubt.
Best Regards
Hari K.

Question about decimal places for currencies

hi ,experts ,
   here is the problem , when i use mb5s, i found the net price has been enlarged 1000 times . I also found the data of the table EKPO has been enlarged 1000 times. So ,i check the decimal places for currencies , i found there are five decimal places , the standard system is two decimal places .
   Does this mean that we cann't change the decimal places in SAP? If we can change , what should we do for configuration ？
Jarod

When running OY04, you are receivingin the following message:
Before you continue, please read the following
text carefully.
If you do not heed this note, you can cause
irreparable damage to the system with this
transacton.
In the R/3 System tables currency fields are
stored as decimal figures with a variable number
of decimal places. The decimal point is not
stored in the field in the database. Instead,
each currency field refers to a currency key
field. In this transaction you assign the number
of decimal places to this currency key uniquely.
Example: If you have set currency USD to have
two decimal places and you post an amount of 100
USD, an amount of 10000 USD is stored in the
Do you want to change the decimal places despite
all recommendations?

Decimal places diferent in BO SUM function than from DB

Hi,
I have a column from a Netezza database with 2 decimal places, if I apply a sum() function in BO (report) the decimal places are 4.
The strange part is that if i do exact the same query in a DB2 database the decimal places are always two (like in DB) even if i use a sum function in report.
There is some configuration regarding the database i'm using to set the decimal places in the report level to be the same than in DB?
Edited: I've been studing the problem and I found using a odbc instead of a jdbc makes all the columns have 2 decimal places, and the sum problem doesn't happen. Now my issue is the division. How is possible that with the exact same values with two decimal positions, in BO and exporting to excel the last decimal place is different in some cases
Example:
Lets say A/B with A=13549678065,560000 and B= 21629484348,690000. With Netezza result is 62,6444803173527 and Db2 62,6444803173528
Thanks for your time.

I've never seen this particular problem before. Quite strange. It sounds more like an OLAP or SQL Server issue, not BPC.
I'm not aware of any configuration on SQL server that allows you to control the decimal separator.
I had a similar problem in the past, when my customer refused to follow the install guide instructions, and insisted that the server be set to non-US English regional settings. If I recall, the issue had to do with date formats not decimal separators. They ended up un-installing and re-installing the entire OS (with US English setup, the second time around), and then it worked fine. This was back on 5.0, and perhaps the situation has changed since then. There's a section in the master / install guide that covers the server-side language & regional settings in some detail.
But before you look at that, try something easier -- is it possible that the cube is somehow corrupted? Do you get any errors when you process the application? Perhaps there is some data in the fact table with an invalid member ID.
Do you get the same result in your Excel report when you use both EVDRE and EVGET?
And if you browse the cube data in SQL Mgmt Studio (logging into the Analysis Services cube) do you see aggregated data there?
Regards,
Tim

11g Client - Inconsistencies at the 16th decimal place

In TOAD, SQLPlus, & ODBC clients numbers returned from a query are correct (max 3 decimal places)
In Discoverer & from a report, the numbers are off at the 16th decimal place...
EG:
7.081 becomes 7.0810000000000004
7.090 becomes 7.0999999999999994 (which is exceptionally weird because the rounding doesn't work)
7.200 becomes 7.2000000000000002
Any idea what would cause this?
How can I query from SQLPlus (or TOAD) to confirm whether or not those extended decimal places actually exist in the table?

Alan3 wrote:
Maybe I should have added this little tidbit...Please be as verbose as possible (feasible). Show queries etc. - use copy and paste.
The particular table in question is an interface table that has been in place for 4+ years.
The columns in question are of data type NUMBER.
We just switched the PC that runs this interface to Win7 with an 11g client.Describe the interface. E.g. In what program language is it written?
Now we see the extended decimals with Discoverer (on any PC) and the interface report (an old report built from developer 6) as well, but not from SQL, etc...How is changing one pc client related to the Discoverer and Reports reports? Has the database server been upgraded also? (full version from select * from v$version; )
Do you see the same change for "old" data (from before the switch).
I want to know if there is a setting in SQLPlus or the DB client that limits the display of the decimal places that I can alter to determine if the extended decimals actually show up... (they shouldn't be there at all)Both sqlplus and db may affect the outcome, e.g.
SQL> desc test
Name                                      Null?    Type
A                                                  NUMBER
B                                                  NUMBER(38,5)
SQL> show numw
numwidth 10
SQL>
SQL> select * from test;
         A          B
     12345      12345
123456789 123456789
    123,45     123,45
123,456789 123,45679
     1,234      1,234
1,23456789    1,23457
6 rows selected.The same values was inserted to both columns of test. With scale = 5 for its datatype, B values are rounded (4th and 6th row).
SQL> set numw 5
SQL> select * from test;
    A     B
12345 12345
123,5 123,5
123,5 123,5
1,234 1,234
1,235 1,235
6 rows selected.The numwidth setting affects sqlplus formatting.
Edited by: orafad on Jan 5, 2011 9:44 PM

Decimal places in database

Similar Messages

Maybe you are looking for