AAVLD-USAHA-ITStandards / eCVI

eCVI Data Exchange Standard (Starting with version 2)
12 stars 9 forks source link

International Consignor/Consignee (Not origin/destination) #69

Open StaceySchwabenlander opened 3 years ago

StaceySchwabenlander commented 3 years ago

I was recently reviewing some eCVI files and found a file that did not meet the XML schema. If I'm reading the error correctly, it is because the schema doesn't allow for international consignee/consignor addresses. Is this something that should be allowed under the schema? I realize these CVIs are likely rare. I am bringing this up in the event other states see this more commonly or feel this is something that should be addressed.

I am not suggesting the schema consider international destinations, that is addressed in issue #48 and doesn't need to be part of this issue. This issue is specific to international consignees/consignors when the origin/destination is a US state/territory.

The specific example was a swine movement from MN to NE where the consignor was from Manitoba.

This is the error that was generated by our CVI processing software, in case it is helpful: Errors:47:0: ERROR: Element '{http://www.usaha.org/xmlns/ecvi2}State': [facet 'enumeration'] The value 'MB' is not an element of the set {'AA', 'AE', 'AK', 'AL', 'AP', 'AR', 'AS', 'AZ', 'CA', 'CO', 'CT', 'DC', 'DE', 'FL', 'FM', 'GA', 'GU', 'HI', 'IA', 'ID', 'IL', 'IN', 'KS', 'KY', 'LA', 'MA', 'MD', 'ME', 'MH', 'MI', 'MN', 'MO', 'MP', 'MS', 'MT', 'NC', 'ND', 'NE', 'NH', 'NJ', 'NM', 'NV', 'NY', 'OH', 'OK', 'OR', 'PA', 'PR', 'PW', 'RI', 'SC', 'SD', 'TN', 'TX', 'UT', 'VA', 'VI', 'VT', 'WA', 'WI', 'WV', 'WY'}. 48:0: ERROR: Element '{http://www.usaha.org/xmlns/ecvi2}ZIP': [facet 'pattern'] The value 'R0H0Y0' is not accepted by the pattern '\d{5}-\d{4}'.

mkm1879 commented 3 years ago

A proposed solution is in the commit f20b2f7 in the PendingChanges branch. I took the Address element and changed it to two complex types: USAddress and InternationalAddress. The Address element (same name in both places for continuity) has the appropriate type in each location.

I've done only simple testing of this so far.

This might also benefit extensions that support international origin and destination by making the changes from the standard involve much less text.

(Apologies. It seems the commit pulled in formatting changes that happened automatically in my editor. So the diff view is confusing.)

SusanCulpDVM commented 2 years ago

@mkm1879 thank you. We can bring this in draft issue up on the call today to see if any other committee members have comments.

mkm1879 commented 2 years ago

I fixed the reformatting that switching computers had introduced--at least removed it from any of the commits we are saving. And of course then I misspelled the commit message!

ryanscholzdvm commented 1 year ago

There was discussion around potentially adding further annotation to the state element on InternationalAddress to indicate that the full state/territory name be used for international locations rather than the state code.

CAllenMN commented 1 year ago

Diane Kitchen asked at our 8/31/2022 meeting if this can require NAN for vets with an international address to ensure they are US accredited?

mkm1879 commented 4 months ago

In creating examples of InternationalAddress, I found some countries don't have a political subdivision above town as part of their postal address. Should State be made optional?