Here are my comments on the points above with respect to the US market:

Taxation:

• In order to support the various jurisdictions, I would add a tax calculation ruleset that allows a multitude of configurable options. Things like: calculate tax on total (boolean), display ex tax (boolean), use high line item precision (boolean) etc. Various rounding strategies could also be added, things like: rounding strategy (enum: accountants, half_up, half_even, etc..).
• Here's a link back to part of that discussion: http://www.openvpms.org/forum/gst-calculations-vs-us-sales-tax-calculations
• In general, the items in OVPMS-916 look reasonable to me.
• Even if we don't get it perfectly right the first time, the few cents that are incorrect probably won't be a big deal at the end of the day. Sometimes the appearance of propriety goes a long way. :)
• Also, an alternative to actually storing the ex tax price is storing the tax incl price and the tax amount. Depending on the logic in the rest of the system one of these may work better than the other. At first blush, I'm guessing that the way you've already stated it would be better for things like the product list, etc. Day-to-day in the US, tax is almost never quoted in item level quotes. It should be in an estimation however, because that's representative of all costs.

Reporting:

• I have a set of reports that works for us here in the US that I can volunteer. Obviously it doesn't show the tax correctly at this point, but it's formatted all letter size, w/ US spellings, etc...

Postcodes:

• Not much to add here. We've gotten by without a big problem by just adding the suburb's on-demand. Our initial load required a bit of doing to get them all in there, but the fact is that no practice will have need of all US postal codes because practices tend to be local businesses. After our initial load, we've needed to add about one every couple months on average. To load the data initially, I wrote a script to do it myself using an xwindows macro recorder and a spreadsheet. So, for folks that can't do that, a CSV based tool would probably be great.

Localization:

• The only thing that we run into regularly on an upgrade is the date/time format. Unfortunately the US uses MM/dd/yyyy or MM/dd/yy fairly regularly.
• We've manually modified the architype defaults to use LBS instead of KGS here. I believe that archetype default gets blown away on upgrade as well.
• We've also had requests in the office for AM/PM type time numbering. I'm hesitant to make this sound very important however because most human hospitals use 24 hour time in the US to avoid confusion... and asking our staff to do the same is fine for us -- but some others may feel differently because it's so common here.
• I've made a list of things I need to reconfigure on upgrade, but it's really just those first two items.  Making this easier, or unnecessary would be nice for folks in the US.

Cheers,

Paul