Hi Everyone,

There were several errors in the Application Event Log on the CRM server from the InfuseServer.exe service.  There were two errors being thrown:  “Invalid Sales Territory ‘0’…” and “TaxID ‘0’ is invalid for address ‘DEFAULT’…”.   Infuse often gets blamed for these errors.  However,  we have uncovered some SL magic going on in the background that causes these types of errors. 

First, some background…

Infuse uses the Solomon Business Objects for our connection into SL.  The Solomon Business Objects operate a bit differently from the application itself. The application will not validate data in a field on the screen unless that field’s data is changed. The Business Objects are not so forgiving. The Business Objects (BO) run a validation on all fields, and even on some other data (eg. Class ID defaults), whenever a customer update/insert is attempted.

Often there are records in our clients' systems that get hung up in the process by the Solomon BO validation.  There were several customer records in Demo Data that show this behavior, when they were assigned a Sales Territory of ‘0’.  As there are no sales territories defined in the system, this is obviously an invalid value for the field. The Business Objects were rejecting this entry, even though Infuse was not trying to update it.

Along the same lines, there were several SO Addresses (ID=DEFAULT) that were assigned TaxID values of ‘0’.  Again, as there are no Tax ID’s defined in the system, this is also an invalid value for any of the TaxID fields on the SO Address record.

In order to remedy this, I identified all such customer and SO Address records and removed these invalid values. Once the records are corrected in SL with valid data, then we go into the Config utility and change the ActivityStatus field value to ‘0’ for the Infuse Service to re-process the record.  All records processed successfully.

It is not unusual to run into these types of problems with a Solomon system that has been in use for a while.  Throughout upgrades, the Solomon schema has changed.  Microsoft’s upgrade utilities don’t always go through and validate existing data against the new schema.

Additionally, if someone goes from SL 5 to a new version, Customer Priority Scheduling fields were not in that old schema so SL will extend the table and add the colum for CPS but leave all the data null.  The SL app must have some "If is Null" then... logic.  But the Business object needs to have data.