Hi Kiddy,

This issue will more than likely be resolved by applying the latest release of IOM version 3.3.1.2.

Best,

Adam

I have the new version. And this is the first import we did after we installed the new version 3.3.1.2

 

Was this ever answered - we also see this and are at the latest versions of both IOM and the LO Connectors.

I still get this error message when a non-constituent spouse is part of my import and the non-constituent shares a piece of data with the constituent record (i.e. alias ID). If I remove the alias from the constituent record the import will work.

Deb, do you know if this is in Omatic's 'bug fix' pipe line?  If not, I will take the info you provided a log a ticket with them to investigate.  Thanks

Dennis, I had a ticket running when I first encountered the issue but I'm not sure if I properly closed the loop or if my observations made it the next step along the bug fix pipe line. Thank you for moving it along.

Just logged a new ticket with Omatic - will keep all updated as they may need various pieces of info from all of us.  Thanks

Here is the response from OmaticSupport - all which were already done and/or no applicable(this uses the LO Connector and not an excel file import) - standard Tier 1 stuff.

1. Ensure that the correct profile is being selected for the data file that is being imported.
2. Ensure that the profile and data file end on the same letter.
3. Check the data file against the profile. Ensure that the data that is in "Column A", should in fact be mapped to the record type and value type that "Row A" in the profile is mapped. Repeat this cross-reference for each column in the file until the issue is found, correct to resolve.
4. If the profile and data file do match and everything is mapped correctly, check to ensure that the correct dictionaries are applied.
5. If the data file and profile match and the everything is mapped correctly, including dictionaries, Excel may be adding ghost columns to the data file. Highlight all the cells that have data (don't highlight the entire row or column, only the actual cells that have data), copy and paste into a new spreadsheet.
6. Refresh the LO Connector mapping

Sounds like all the steps we went through in trying to determine the cause of the error. It was only by studying the records impacted by the error and discovering a spouse record that led me to dig into relationships and then to uncover the fact that for us a patient id was imported as an alias. It was the alias id being part of my import file that I found the commonality of data. I must have mistakenly imported a patient id to the spouse by mistake. Now it wants to match on the alias and creates an error.

Initially I thought it was the spouse record itself. If I unchecked the spouse checkbox and removed the link between the spouse record I was able to import successfully. It could be something with the fields used as duplicate criteria that causes an import meltdown when it appears in a constituent record and then with an import that contains mutual data but a different name?????

Frustrating response!!

Thanks Sharifa,

I think for me discovering the patient ID alias conflict was the solution. Our early imports had incorrect constituent matching criteria which caused the patient ID to be entered on the spouse constituent instead of creating a new list management record for the actual patient. I rarely encounter the error anymore. It was impossible to clean up once we realized the error. Knowing the cause allows me to quickly identify and fix the problem and then I rerun the exceptions.

Hopefully sharing the information will allow for a fix or at least a more descriptive error message to guide the next recipient.

Deb

Deb, FYI - the most recent(last week) LO Connector upgrade appeared to resolve this issue for us.

Hooray! Hopefully our struggles helped to map the way. We're not seeing those issues very frequently. In fact I can't remember the last time that error impacted an import.
It's a good week. :-)