Purchase Order Quantity in Decimal Point not accepted

pyramid

Active Member
Hi! Everybody,

I have a case here when entering a Purchase Order with Quantity in Decimal point (e.g. 200.2, 10.3, 12.4) System take it without decimal point (e.g. 200, 10, 12).
Please if any one knows what is required to be done in the setup to avoid this "Rounding off" of the quantity decimal point. Please let me know.

Also one more thing when quantity is entered on the PO with decimal .5 or greater then .5 system automatically round off point decimal value to full number/digit (e.g. 15.5, 10.6, 99.8, 99.9 etc)

Please advise if any knows the solution to above mentioned issue.

Thanks.
AK
 
Decimal Display of Quantity field (UORGE1) is set to zero as default.

You need to increase it more than zero in Data Dictionary (P92001). But this is very dangerous way, you can spoil the data in F4311. OK I'm warning you.
 
Hi Ali,

Thanks for your reply, Yes i agree with you changing data dictionary values is deadly dangerous thing. And we have an historical data it will be corrupted if changed the data dictionary. But is there any other support or solution that can help us without effecting our current data. Can we install some package to resolve our problem without effecting historical data in the system.

Thanks.

Aqeel

Ali Kara <[email protected]> wrote:
Decimal Display of Quantity field (UORGE1) is set to zero as default.

You need to increase it more than zero in Data Dictionary (P92001). But this is very dangerous way, you can spoil the data in F4311. OK I'm warning you. Ali Kara Sr.Application Consultant Manufacturing & Logistics Istanbul - Turkiye
 
We have done it earlier and may do it during migration from A7.3 to E1 where
our decimal for price will change. I do not think it is dangerous. You need
to ensure that the historical data in appropriate files is updated.




Regards

Nandan Shah






_____

From: [email protected] [mailto:[email protected]] On
Behalf Of AAK
Sent: 28 January 2008 23:02
To: [email protected]
Subject: Re: Purchase Order Quantity in Decimal Point not accepted



Hi Ali,

Thanks for your reply, Yes i agree with you changing data dictionary values
is deadly dangerous thing. And we have an historical data it will be
corrupted if changed the data dictionary. But is there any other support or
solution that can help us without effecting our current data. Can we install
some package to resolve our problem without effecting historical data in the
system.

Thanks.

Aqeel

Ali Kara wrote:
Decimal Display of Quantity field (UORGE1) is set to zero as default.

You need to increase it more than zero in Data Dictionary (P92001). But this
is very dangerous way, you can spoil the data in F4311. OK I'm warning you.
Ali Kara Sr.Application Consultant Manufacturing & Logistics Istanbul -
Turkiye

_____


The entire <http://www.jdelist.com/ubb/showflat.php?Cat=&Board=> JDELIST
thread is available for viewing.


Looking for a job? Check out the Job
forum


This is the JDELIST EnterpriseOne Applications Mailing List.

To unsubscribe from this list via email, Click
<mailto: [email protected]?Subject=Unsubscribe&Body=Sirs,

Pl
ease remove this address from the JDELIST EnterpriseOne A
 
Re: RE: Purchase Order Quantity in Decimal Point not accepted

Hi Nandan,

If it is do able, can you please tell me the steps & procedures to change the decimal point upto 4 places without effecting the historical data.
Awaiting for ur reply.

Thanks.
Aqeel
 
Re: RE: Purchase Order Quantity in Decimal Point not accepted

Hi

I am Mr. Nandan’s colleague.
Steps to do data dictionary changes vary from version to version.
We have done it in E1 – 8.12.
Its not advisable to do changes only in one data item. JDE grouped all distribution related quantity data items together with a data item class QTYINV.
So it is recommended to change all data items in that class.
After changing the decimals, we need to correct the historical data also. JDE does not provided a program to correct historical data after changing qty decimal places except for QNTY data item.
UBE – R9200100 can be used to update the decimal places in data dictionary of a data item class. (This will only change the decimal places in Data dictionary, not historical data)
As mentioned earlier, if you are using QNTY data item, even data related to that data item can be converted using R30QNTY UBE.
Other data affected by above changes must be updated with SQLs.

Example: If you are changing decimal from 0 to 3, then you must update data in F4311 with an SQL like
Update testdta.f4311
set
PDUORG=PDUORG*1000,
PDUCHG=PDUCHG*1000,
PDUOPN=PDUOPN*1000,
PDUREC=PDUREC*1000,
PDCREC=PDCREC*1000,
PDURLV=PDURLV*1000,
PDPQOR=PDPQOR*1000
PDSQOR=PDSQOR*1000

This sql is an example only and you may need to correct SQl as per your requirement and environment.
You need to update all tables using data items in QTYINV data dictionary class.
But which all tables to be updated are purely depends on what all modules/ features you are using from JDE.
Some of the main tables are F4211, F42199, F4311, F43199, F41021, F4111 etc.

Then all these data dictionary changes need to be deployed again on client and server.
You need to clear the spec from client and Enterprise server and create full packages and deploy.
Also you may have to regenerate the serialized objectto reflerct in HTL environment using eGenerater. I think 8.12 onwards you can skip this step.
Refer SOLUTION ID: 200783541 for more details about it.

Regards
Binu P Abraham
E1 - 8.12 Tools 8.97 on I5 with Websphere 6.0.x
 
Re: RE: Purchase Order Quantity in Decimal Point not accepted

Hi!

Thank you very much for the solution you provided. We are also using E1 - 8.12, I hope that the solution you mentioned will solve our problem.

Thanks.

Aqeel Khan

Binu Abraham <[email protected]> wrote:
Hi

I am Mr. Nandan’s colleague.
Steps to do data dictionary changes vary from version to version.
We have done it in E1 – 8.12.
Its not advisable to do changes only in one data item. JDE grouped all distribution related quantity data items together with a data item class QTYINV.
So it is recommended to change all data items in that class.
After changing the decimals, we need to correct the historical data also. JDE does not provided a program to correct historical data after changing qty decimal places except for QNTY data item.
UBE – R9200100 can be used to update the decimal places in data dictionary of a data item class. (This will only change the decimal places in Data dictionary, not historical data)
As mentioned earlier, if you are using QNTY data item, even data related to that data item can be converted using R30QNTY UBE.
Other data affected by above changes must be updated with SQLs.

Example: If you ar! e changing decimal from 0 to 3, then you must update data in F4311 with an SQL like
Update testdta.f4311
set
PDUORG=PDUORG*1000,
PDUCHG=PDUCHG*1000,
PDUOPN=PDUOPN*1000,
PDUREC=PDUREC*1000,
PDCREC=PDCREC*1000,
PDURLV=PDURLV*1000,
PDPQOR=PDPQOR*1000
PDSQOR=PDSQOR*1000

This sql is an example only and you may need to correct SQl as per your requirement and environment.
You need to update all tables using data items in QTYINV data dictionary class.
But which all tables to be updated are purely depends on what all modules/ features you are using from JDE.
Some of the main tables are F4211, F42199, F4311, F43199, F41021, F4111 etc.

Then all these data dictionary changes need to be deployed again on client and server.
You need to clear the spec from client and Enterprise server and create full packages and deploy.
Also you may have to regenerat! e the serialized objectto reflerct in HTL environment using eG! enerater . I think 8.12 onwards you can skip this step.
Refer SOLUTION ID: 200783541 for more details about it.

Regards
Binu P Abraham
E1 - 8.12 Tools 8.97 on I5 with Websphere 6.0.x
 
Re: RE: Purchase Order Quantity in Decimal Point not accepted

Hello, Here is the sql I used to find all of the columns:

-- CREATE TABLE tmp_e20081231_pd_jim_cols AS
-- SELECT owner,table_name,column_name
-- FROM all_tab_columns
-- WHERE OWNER IN ('PRODDTA','SYS7333','OBJ7333')
--
--
-- CREATE TABLE tmp_e20081231_jim_pfx AS
-- SELECT DISTINCT trim(a.siobnm) table_name, a.sipfx prefix
-- FROM obj7333.f9860 a
-- WHERE a.sifuno = 'TBLE'
--
-- CREATE TABLE tmp_e20081231_jim_tai AS
-- SELECT trim(b.frdtai) fldname
-- FROM dd7333.f9210 a,
-- dd7333.f9203 b
-- -- obj7333.f9860 c
-- WHERE a.frdtai = b.frdtai
-- AND a.frclas = 'QTYINV '


SELECT DISTINCT a.table_name,a.column_name,SUBSTR(a.column_name,3) tai
FROM tmp_e20081231_py_jim_cols a,
tmp_e20081231_jim_pfx b,
tmp_e20081231_jim_tai c
WHERE a.table_name = b.table_name
AND SUBSTR(a.column_name,3) = c.fldname
AND SUBSTR(a.column_name,1,2) = b.prefix
ORDER BY 1,2

SELECT DISTINCT
'UPDATE '||a.owner||'.'||a.table_name||' SET '||a.column_name||' = '||a.column_name||' * 100 WHERE '||a.column_name||' IS NOT NULL;'
FROM tmp_e20081231_pd_jim_cols a,
tmp_e20081231_jim_pfx b,
tmp_e20081231_jim_tai c
WHERE a.table_name = b.table_name
AND SUBSTR(a.column_name,3) = c.fldname
AND SUBSTR(a.column_name,1,2) = b.prefix
 
Back
Top