Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Removing Multi-Currency or fixing roving digits in amounts 2

Status
Not open for further replies.

deerichards

Technical User
Feb 10, 2004
7
US
Sometime in the past (before we started supporting this system), the mult-currency option was "turned on" then it was "turned off". This system has been around since at least version 4. Inventory items are showing 5 digit currency when the system should be using 2 digit currency. After the data is corrected (using both the convert digits screen and separate instructions from GP support), running checklinks will return the items to 5 digits. We understand that turning mult-currency on, then off, in previous versions did not work properly leaving 'residue' in the data; however, we can not find the magic change that will stop the conversion from 2 digits to 5 digits. Anyone else have this type of problem?
 
Check links on inventory actually verify the consistency between over 10 tables. The tables with the decimal places currency in them are:

IV00101 (DECPLCUR should be set to 3 in order to be 2 in GP)
IV00105 (DECPLCUR should be set to 3 in order to be 2 in GP)

Assuming that the unit of measures assigned to each item is setup correctly (if not, you could run a script on those tables as well), run an update statement on the IV00101 and 105 to change the decimal places.
 
Thank you for your response.

In accordance with an incident response from GP support, we wrote the following update script:

update iv00101 set decplcur = 3 where decplcur = 6# --Item Master
update iv00105 set decplcur = 3 where decplcur = 6# --Item Currency Master
update POP10110 set decplcur = 9 where decplcur = 12# --Purchase Order Line
update SOP10200 set decplcur = 3 where decplcur = 0# --Sales Transaction Amounts Work
update SOP10200 set decplcur = 3 where decplcur = 6# --Sales Transaction Amounts Work

This script takes care of the problem temporarily. After checklinks is run, checklinks 'fixes' the digits back to 5 digits. We can run this script after running checklinks; however, we would love to find the root of the problem.
 
How are the unit of measure setup tables? If you go to tools > resource > Tables. Change the view to be by table group. When check links is run, it goes through each one of these tables. I would run a select on each and see if anything sticks out.

Are you just running check links on the item master or all?
 
Usually when checklinks is run, it is run on the entire system as a maintenance. Sometimes they have a stuck invoice, etc.

I checked all the tables. Other than decplcur and currnidx, I don't know what other fields are used in the digit process. As a rule, I would think that the decplcur and currnidx fields would be consistent throughout the data; however, the previous script sets decplcur in POP10110 to 9. Rational.. the majority of the working records contained 9.. no other reason.

In the iv00103, the distinct values of currnidx are 0,9 & 12. I can get a list of all distinct occurrences of currnidx and decplcur from all files if it would help find the problem.

This company has one decimal preference (2 digits) and one currency (US dollars). They are not using the multi-currency function (even though at one time it was turned on then off).

Really appreciate it.
 
Is Multicurrency turned off? Have you ever actually used MC? If it's off and never had been used really, there is a MC Fix chunk that can be used to remove all the "residue" as you called it. I think you are having a combination of problems including what Luvsql is helping you with.

Anyway, I have had to use the MC Fix before for a client who never really used MC but had sent some files to GP to fix back in the days they used ctree. GP then sent the files back fixed but they had MC registered and it left MC information in the tables. When the client actually purchased MC and went to use it we were unable to set a Functional currency because of this. So we had to run this fix to clean it all out and then we were able to continue. I think you should ask them for this chunk.
 
Multicurrency was turned on, then off, and never really used; however there are some residual numbers with 5 decimal places.

Do you have a copy of this fix? It takes an act of congress for me to get anything from support. They are on GP 7.5 SP4.
 
Well, I was able to find the file I had but it's version 6.0. I'm not sure it would work. Maybe you can ask for the file and see what they say? Maybe they don't even make the file anymore.

I could send you the 6.0 one but there are table changes between each version so it probably wouldn't work anyway.
 
It is amazing that this company has 4 or 5 incidents recored with GP support on this problem and NO ONE has ever suggested this fix before. Wish I had a script of what the chunk does...I would make the updates manually. I have a really good idea of what updates to make; however, with GP you never know what the results will be, even if you follow their documentation and instructions from support.

Really appreciate everyone's help in this matter.

 
I looked at the instructions and it starts by saying: WARNING: This utility is only to be used on Dynamics version 6.0 with the Btrieve or C-tree databases.

It doesn't say anything about what it's doing though. Sorry :(
 
Ahh....have an idea. Create a new support case and select under Tools support. Many times, regular support does not know what Tools has done. Tell them it's a continuation of incident #XXXX so you shouldn't be charged. Or, ask to transfer your existing case to Tools support.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top