To meet the new UN agreed designation of Turkey as now Turkiye I have been looking at how to change this in Epicor.
Not as trivial as one might think.
I tried a UBAQ to edit the description field in the Country table, but this is only part of the ‘story’
There are plenty of tables where the country name Erp.Country.Description is copied into another table field. For example; Erp.Customer.Country.
I wonder if creating a new country and then updating countynum on any related tables would be cleaner?
You should try contacting Tech Support. They may have a tool that will help to properly fix the Country table. As for any other tables that store the description, that legacy data (what I am calling teh data that happened before the change) would stay the same unless you forced a change (much like the Part Description in a sales order doesnt change when you change the part description in the part table).
But I would think that you would not need to change the old orders for Turkiye, but only active/new orders, invoices, etc.
Country and CountryNum are often both stored in tables for some reason. I’m surprised that because there is a numeric key behind the actual country that the name is not serviceable by default.
yes, and not only that, the Country table has been my nemesis for years… when setting up a multi-company environment, that shares customers, you need to make sure that all the COUNTRY tables are 100% matched across all companies, or your data gets skewered. Since the Country NUMBERS are Automatically assigned in the sequence you add the country, you have to be very careful.
Out of curiosity why aren’t these maintained by Epicor as a global. They are what they are why are we required to even enter them manually at all?
Blockquote
yes, and not only that, the Country table has been my nemesis for years… when setting up a multi-company environment, that shares customers, you need to make sure that all the COUNTRY tables are 100% matched across all companies, or your data gets skewered. Since the Country NUMBERS are Automatically assigned in the sequence you add the country, you have to be very careful.
Yup, found that out the hard way once.
For our setup, we were told Avatax requires the country’s two-letter ISO code in the description field (I don’t know if that’s true, but that’s what we were told), so that’s what we did. (That’s how our previous ERP was set up too, anyway, so that made data migration easier.) I’ve recently added a separate Country.LongDescription_c UD field as they want the actual name of the country visible and updateable and translatable for our European branch we’re adding to Epicor. Then it was mostly just a matter of adding a customization to several forms to change the display member of any country combo box, and force-refresh the combo box right after loading. We’ll probably deploy this for our other companies in Epicor, too, because having the name of the country looks a lot better.
It is curious why there is a per-company country table… perhaps future-proofed against the discovery other inhabited planets or alternate universes?
I think the idea is that you don’t have to put every country in the world in the Country table. You could just put the countries you do business with. Then if you have multiple companies that only do business with certain countries, they would use different Country tables. I think the only time that doesn’t work is when using intercompany processes, in which case all involved companies will need to have the exact same countries in the same order (same Country.CountryNum and Country.Description at least, probably). But I think you could still have another company/other companies not using intercompany processes with a different Country table.
Maybe a better question is, “Why isn’t there a separate GlbCountry table for intercompany processes like there is for every other table?”
Sorry to necro-post, but is this still an issue in 2024.1? We just got done setting up our multi-companies and do not have matching numbers for the first 7 (we put the Company’s country at the #1 spot across each of them)
Yes, this is still the way that it works.
New Idea: Make Country.description field updateable
Another new idea: Change the Erp.Country table to be OUTSIDE the Company hierarchy, similar to Erp.UserFile
Maybe not the right channel for this, but I didn’t see that in the documentation for Multi-Company setup. It might be a good place to have that listed officially if it’s not considered a bug. Sorry if it was in there and I missed it! Thanks for your fast response
“If I was king” back when Kinetic was being designed (before I was an employee 25 years ago), I would probably have enforced that idea. Like you said, Countries (and STATES, and ZIP CODES) could all be pre-defined in tables and released with the software. Same goes for Units of Measure since there are ANSI standards for these. But, we cannot rewrite history, and changing this now would be very problematic and complex. Sometimes we just have to live with those decisions (like we all live with the fact that the SUPPLIER table is called “VENDOR” in the database) because the cost of changing it overrides the value of the change.
It would be fine if they didn’t change it in the UI in the first place!
Way back in the main frame days, the same thing was in Powerhouse, because most of the business back then was IBM, the machines were identified by Vendor, Type, Model and Feature.
We ended up having to change all the visible references from Vendor to Manufacturer. That was a lot of work 
Now in this case, Manufacturer really isn’t the same as Vendor, but Supplier and Vendor really do sort of mean the same thing. We do still use Manufacturer in a few places, but it’s a different field for us.
Luckily in Kinetic, we have a table for the SUPPLIER (the Vendor table), and a separate table for Manufacturer. When setting up a part, you can have YOUR part number, your supplier’s part number, and your Manufacturer’s part number all linked together as three separate entries.