Display decimal change in One World

LPeters732

Member
Group,

Has anyone changed Display Decimals for the QTYINV group in One World after
data have been entered?

We have read the White Paper. It has left us with several questions.

If you did, what problems did you experience?

How did you do it?

Were custom programs written.


We are on One World B733 version SP11.2 on an AS400 model 830

Sincerely,

Roy Peters

Philip Services Corporation
Houston, Texas
 
Hello LPeters732,

We had this fun today.
===8<==============Original message text===============
Group,
Has anyone changed Display Decimals for the QTYINV group in One World after
data have been entered?
=====================
1) First we ran Update Decimals UBE (Dec=2), and tested everything in DEV
environment with separated Data Dictionary. We made some tests and
have decided that system works with decimals>0
2) then there where written custom program (VBasic) which does following:
Goes through F98711 (Table columns), and for every line, which has <Table
name> (TDOBNM), <DD Alias> (TDOBND) and <SQLColumn>
(TDSQLC) looks to F9210 linked with F98711 by
F98711.FRDTAI=F9210.FRDTAI and checks if this <DD Alias> is in Class
(FRCLASS) "QTYINV". If Alias is in our class, proper Column in
Database table is updated (multiplied by 100 in our case).
Totally where about 230 tables and 1300 field which where updated.

Looks like this step was also successful.
IMHO, this algorithm is quite straightforward and should return correct
results (at least in theory :))
The one problem you can get is when your current quantities are
longer then 13 digits. In this case after conversion you'll get
quantity longer than 15 which is out of limits for QTYINV class.

Generally, if you don't need to convert Base Unit of Measures (Kgs to Tonns, for instance)
for existing items/transactions, game is
over, and you can repeat everything in Production. (After looooong testing, of course :)

3) The biggest fun begins when you decide to convert Base Unit of measures
for a just few thousands items.
In this case you can't uniquely identify tables/fields which needed to
be updated, because you also have to update Prices, Costs, and something
else.

Now is getting dark, and consultants are still thinking what fields
should be converted ....

sorry for my english which is far from ideal, but hope this can help.


Regards

Yaroslav

--------------------------
 
Yes we did, and it did mess up our data. Fortunately, it was only test data and we were in the Dev Environment. I'm not sure which white paper you were referring to that you have read, but I would suggest the document titled "OneWorld Display Decimals Update" available on the Knowledge Garden. We found this document after the fact. The document clearly states that if display decimals are changed after data has been entered the data entered before the change will be displayed incorrectly. The document also refers to a batch job to run to update the decimals for class QTYINV - R9200100 but I would research this prior to doing it.

We also learned that all Display Decimals in this class must be set to the same value. There is a report R92400 that you can run called the Data Dictionary Items Report (setting data selection for class QTYINV) this will give you a listing of all data items by alias in that class(with or without glossary descriptons) and what there display decimal is currently set to.

Hope this helps.

By the way, we had to add new data after we made our changes to correct any issues we had.

We are on XE.
 
Re[2]: Display decimal change in One World

Forgot configuration:

Xe SP13,
Enterprise : NT4/SP5 , MS-SQL7SP2


=============================
data have been entered?
=====================
1) First we ran Update Decimals UBE (Dec=2), and tested everything in DEV
environment with separated Data Dictionary. We made some tests and
have decided that system works with decimals>0
2) then there where written custom program (VBasic) which does following:
Goes through F98711 (Table columns), and for every line, which has <Table
name> (TDOBNM), <DD Alias> (TDOBND) and <SQLColumn>
(TDSQLC) looks to F9210 linked with F98711 by
F98711.FRDTAI=F9210.FRDTAI and checks if this <DD Alias> is in Class
(FRCLASS) "QTYINV". If Alias is in our class, proper Column in
Database table is updated (multiplied by 100 in our case).
Totally where about 230 tables and 1300 field which where updated.

Looks like this step was also successful.
IMHO, this algorithm is quite straightforward and should return correct
results (at least in theory :))
The one problem you can get is when your current quantities are
longer then 13 digits. In this case after conversion you'll get
quantity longer than 15 which is out of limits for QTYINV class.

Generally, if you don't need to convert Base Unit of Measures (Kgs to Tonns, for instance)
for existing items/transactions, game is
over, and you can repeat everything in Production. (After looooong testing, of course :)

3) The biggest fun begins when you decide to convert Base Unit of measures
for a just few thousands items.
In this case you can't uniquely identify tables/fields which needed to
be updated, because you also have to update Prices, Costs, and something
else.

Now is getting dark, and consultants are still thinking what fields
should be converted ....

sorry for my english which is far from ideal, but hope this can help.


Regards

Yaroslav

--------------------------



--------------------------
 
Back
Top