xTuple.com xTupleU Blog & News Customer Support

xTuple ERP 5.0.0-alpha and other components are now available

xTuple ERP 5.0.0-alpha is now available for download from xTuple.org. Thanks to all who contributed to make this release possible, including Cordeck Building Solutions, Warning Lites, Larry Cartee, Alfredo Martinez, Scott Zuke, Steven Buttgereit, Jim Wirt, Wes Baker, and Joel White.

This release includes major changes to CRM functionality and the tax system, including integration with Avalara. There are significant changes to how CRM and tax data are stored in the database, so you may need to update customized scripts, reports, and MetaSQL queries. In addition, the deprecated portions of the Script Toolbox have been removed as previously announced, which may also require script updates.

Strict country checking is now required and how countries are stored in the database has been changed. Before upgrading to 5.0.0-alpha or later, you must install fixCountry 5.0.0-beta and migrate the country data.

We have also published a new Time & Expense extension version for 5.0.0 compatibility:


  • A new package has been released (deprecatedtb) to help remove deprecated toolbox calls from custom scripts. A gz file (deprecatedtb-1.0.0-beta.gz) for this package has been attached to this announcement.
  • Edited Dec 11, 2018 to update fixCountry extension download version and attach it here directly.

deprecatedtb-1.0.0-beta.gz (3.8 KB)
fixcountry-5.0.0-beta.gz (9.5 KB)

EDIT: sourceforge and github links removed (2019-07-12 15:52 UTC)

On the Avalara integration: what geopolitical area(s) does it cover? Avalara has at least some countries’ VAT available, but not all their ERP integrations support it.

Hi, Phil:

When Avalara certified the xTuple integration, they recognized our solution with the Avalara VAT badge. This means xTuple ERP supports the international tax scenarios currently supported by Avalara.

xTuple ERP was also certified with these other Avalara badges:

  • Sales badge (A/R)
  • Returns badge (A/R)
  • Consumer-use badge (A/P)

Best regards,

Good Evening,
Could we get some clarification on the fix county package. I installed the fix country package. however the pre-check for the 5.0 beta update fails and cites the fixcountry package.

I am assuming that I missed a step. how do I need to change my data after applying the fix country package


After installing the fixCountry extension, you need to actually fix the country references:

  • CRM > Utilities > Fix Countries
  • follow the directions at the top of the window

[Edit] An updated version of the fixCountry extension has been put on SourceForge and has been attached to the original announcement above.

Important note: Do not click the FINISH MIGRATION button unless you are ready to upgrade the database to 5.0.0 immediately. The updates made by clicking this button make the data incompatible with 4.12.0 and earlier desktop clients


Caleb, were you able to get the 5.0 alpha client to open on Windows. I am still getting the error. Rebecca

I was able to get the client to open and make a connection to a database. I have not yet been able to update my database. I did not use the Sourceforge link though. I went through Xtuple.org and got the distribution release there

1 Like

FYI - I was able to open the 5.0Beta client after turning off SSL in the pg_hba.conf.

@gmoskowitz -

Using a test machine, test database, test Mac (in other words, fully protected from live data!), I cannot seem to get past the ‘fixcountries’ issue on a 5.0 testbed. All country data is cleaned up and nothing remains in the Query list — but when I try the “migrate” button, it hangs for a few minutes then crashes, suggesting more dirty country data remains. Not sure how I’d find it… suggestions?

We do have some entries in the DB which have a blank/null country, which is actually ‘United States’, but the fixcountry application doesn’t allow me to mod/update those entries.

@ricambiamerica -

Two questions:

  • What exactly do you mean by “then crashes” and “suggesting more dirty country data remains”? The word “crash” has a specific meaning that conflicts with the software making suggestions.
  • What version of the fixCountry extension are you using?

We’ve made some minor improvements with version 5.0.0-rc of the utility extension (attached below) that might help answer your question.

fixcountry-5.0.0-rc.gz (10.2 KB)

This is the error screen that appears (see below). We have manually cleaned all the addresses that were previously shown in the fixcountry window.

Then I suspect there’s a bug in the way the fixCountry extension handles the metrics table.

Try this:

  • System > Design > MetaSQL Statements
  • click NEW
  • type this in the MetaSQL Editor window:
UPDATE metric
   SET metric_value = country_abbr
  FROM country
 WHERE lower(country_name) = lower(metric_value)
   AND metric_name IN ('DefaultAddressCountry', 'remitto_country')
  • Tools > Execute Query

I’m guessing this will return 2 rows. If so, make the change permanent:

  • Tools > Test Mode to un-✓ Test Mode
  • Tools > Execute Query
  • Tools > Test Mode to restore the ✓

You should now be able to finish the migration. Let us know either way. If this works then we know to fix the extension. If it doesn’t then we need to look for a different cause.

@gmoskowitz -

First time the query was executed in test mode, indeed two rows appears. Disabled test mode, ran query again. No errors. Put query back into test mode and executed query to indeed find 0 rows.

Re-ran the migration step and got the same error. :frowning:

Hey Daniel, I took a look and the package is running this:

SELECT fetchMetricBool(‘ISOCountries’)
What do you get false for that?

I get ‘FALSE’ on that

Let’s see if any of the countries have a problem or not:
select * from addr
left outer join country on(addr_country=country_name)
where country_name is null

That should find any that do not match exactly what is in the country table.

R’uh R’oh… hundreds of entries! All USA ones, where country_id, abbr, curr_abbr is all NULL.

This is a total sandbox environment. Should I just whack them all to USA defaults via SQL and see if it works?

Select * from country table to get the exact but I think they should “United States”, copy what is in country and update them.

[/blunt weapon ON]
update addr set addr_country = ‘United States’ where addr_country = ‘’
[/blunt weapon OFF]

select * from addr where addr_country = ‘’

Happily returns zero results.

But unfortunately the “FinishMigration” wizard still reports an error:

Daniel and Tom,

There are really a number of tables in play here, not just addr. It’ll take me a while to figure out where the problem is, as the same MetaSQL statement is used to populate the window and confirm migration success. Somehow the query returns conflicting results depending on context.