Address Matching in CMS - Revision history

Russ horton at 18:48, 18 September 2014

2014-09-18T18:48:28Z

← Older revision		Revision as of 18:48, 18 September 2014
Line 33:		Line 33:

	'''Note:''' CMS uses an internal address_id to uniquely identify the recipient in an order. This means the same customer/recipient cannot appear more than once in the order but otherwise there is no reason why you cannot have two recipients with the same name (as long as they are different customers.) This has changed in CMS 9.0 where you can now have the same recipient on the order multiple times.		'''Note:''' CMS uses an internal address_id to uniquely identify the recipient in an order. This means the same customer/recipient cannot appear more than once in the order but otherwise there is no reason why you cannot have two recipients with the same name (as long as they are different customers.) This has changed in CMS 9.0 where you can now have the same recipient on the order multiple times.

			=Address Display and Handling During Verify Imports=
			When cycling through orders in Verify Imports, you'll see an address displayed. This address is the address from the Customer node of the imported order's XML. This section explains in a bit more detail about how addresses are used during imports and verification.

			In most order imports, including those from CommerceV3 (CV3), the order file only contains a customer and shipping address. Our XML allows for a separate billing address to be specified but is rarely done. As such CMS will use the Customer address from the XML as the billing address. Even if a billing address is included in the XML, CMS will still display the customer address.

			The really important point to understand though is that you are looking at the XML data only at this point. No attempt has been made to match it to an existing customer yet (or allocate stock or anything else). That
			all happens at the moment you click Verify.

			If CMS does match to an existing customer, particularly a match by email address, the Customer address from the customer list in CMS could be very different than the Customer address in the XML. Either way, the
			order will retain the original Customer address from the XML as its billing address.

			It may also help at this point to reinforce that an order really only has two addresses, shipping and billing. The address you see on the Customer tab of Order Entry is the address from the purchasing customer
			record, essentially a mini version of the Contact Manager, and that data is stored with the customer, not the order. This is why on the View Invoice tab of order entry, we only show Sold-to (Billing) and Ship-to addresses.

	=Customer Duplicate Report=		=Customer Duplicate Report=

Msnyder: /* Customer Duplicate Report */

2014-08-22T18:45:07Z

Customer Duplicate Report

← Older revision		Revision as of 18:45, 22 August 2014
Line 38:		Line 38:
	Also worthy of note is the Customer Duplicate report used for finding possible duplicates. This report is found in the Reports menu under the category Customers. The logic this report uses is a bit different than CMS's and can be a good tool to find those that made it past CMS's logic. The most notable difference in logic is that it is matching on physical or email address, not by name.		Also worthy of note is the Customer Duplicate report used for finding possible duplicates. This report is found in the Reports menu under the category Customers. The logic this report uses is a bit different than CMS's and can be a good tool to find those that made it past CMS's logic. The most notable difference in logic is that it is matching on physical or email address, not by name.

	Matches are on state, city, 5-digit ~~zipcode~~, then first 10 digits of either the ~~address3~~ line or Address1 line, depending on which has data.		Matches are on state, city, 5-digit ZIP code, then first 10 digits of either the Address3 line or Address1 line, depending on which has data.

	This system has a lot of merit in that it is ~~total~~ independent of name spellings or most cases of address spellings (even St vs Street) since only the first 10 characters are considered. (UPDATE: As of CMS 8.0 this report now allows you to select how many characters to consider which allows you to control the level of sensitivity.) This system is really matching on the address vs the customer so if you had a husband and wife with ~~diff~~ names at the same address, you'd find them as a possible dupe match. This should prove to be a good tool to find duplicates that escaped CMS's customer matching (or dupes created by operators for non-imported orders.)		This system has a lot of merit in that it is totally independent of name spellings or most cases of address spellings (even St vs Street) since only the first 10 characters are considered. (UPDATE: As of CMS 8.0 this report now allows you to select how many characters to consider which allows you to control the level of sensitivity.) This system is really matching on the address vs. the customer, so if you had a husband and wife with different names at the same address, you'd find them as a possible dupe match. This should prove to be a good tool to find duplicates that escaped CMS's customer matching (or dupes created by operators for non-imported orders.)

Msnyder: /* Multi-recipient and Gift orders */

2014-08-22T18:43:25Z

Multi-recipient and Gift orders

← Older revision		Revision as of 18:43, 22 August 2014
Line 25:		Line 25:

	=Multi-recipient and Gift orders=		=Multi-recipient and Gift orders=
	CMS is capable of handling and importing orders with multiple recipients and/or gift orders (where the recipient is different than the buyer.) In either of the two scenarios the purchaser may or may not be receiving merchandise themselves. When importing such orders, CMS needs to determine if the recipient(s) is the same as the purchaser or if they should be treated as someone else. The reason for this is CMS will can (optionally) create new customer records for recipients ~~and~~ when printing invoices/pick-tickets CMS will suppress prices from showing so the recipient will not see what you paid.		CMS is capable of handling and importing orders with multiple recipients and/or gift orders (where the recipient is different than the buyer). In either of the two scenarios, the purchaser may or may not be receiving merchandise themselves. When importing such orders, CMS needs to determine if the recipient(s) is the same as the purchaser or if they should be treated as someone else. The reason for this is CMS will/can (optionally) create new customer records for recipients. Additionally, when printing invoices/pick-tickets, CMS will suppress prices from showing so that the recipient will not see what you paid.

	~~This is~~ logic used to determine if the recipient is the same as the buyer works in the following ways:		The logic used to determine if the recipient is the same as the buyer works in the following ways:
	~~<ol>~~		# In our XML specification document (CMSxml.xsd) there is an attribute of the <Recipient> tag that reads "IsPurchaser". If the system that is generating the output for CMS to import is capable, our first recommendation would be to use this attribute. In use it looks like: <Recipient IsPurchaser="false"> In this example the value of "false" is telling CMS that the recipient is not the same as the purchaser and as such should treat this as a gift order, even if there are no gift notes. If the purchaser is shipping to themselves, even at a different address, this value should be "true".
	~~<li>~~In our XML specification document (CMSxml.xsd) there is an attribute of the <Recipient> tag that reads 'IsPurchaser'. If the system that is generating the output for CMS to import is capable, our first recommendation would be to use this attribute. In use it looks like: <Recipient IsPurchaser="false"> In this example the value of 'false' is telling CMS that the recipient is not the same as the purchaser and as such should treat this as a gift order, even if there are no gift notes. If the purchaser is shipping to themselves, even at a different address, this value should be 'true'.~~</li>~~		# If any gift notes are present, CMS assumes the buyer is not sending themselves a gift ,and will make the order a gift order (multiple ship-to, in this case with just one recipient.
	~~<li>~~If any gift notes are present, CMS assumes the buyer is not sending themselves a gift and will make the order a gift order (multiple ship-to, in this case with just one recipient.~~)</li>~~		# If there are no gift notes and there is no "IsPurchaser" attribute passed in the import, CMS then has to determine if the recipient and purchaser are the same or not. In this case, CMS is only using the last name. If the last name matches exactly, CMS will treat the recipient as if they are the purchaser, even if the addresses or any other information is different. While there are a few scenarios where this logic fails (parents shipping to their kid at college, for example), it is the best CMS can do without having the information from 1 and 2 above. It does ensure, though, that the more common scenario of a person shipping to themselves at another address (work, vacation, etc.) will be handled correctly as a normal, non-gift type order.
	~~<li>~~If there are no gift notes and there is no 'IsPurchaser' attribute passed, CMS then has to determine if the recipient and purchaser are the same or not. In this case CMS is only using the last name. If the last name matches exactly, CMS will treat the recipient as if they are the purchaser, even if the addresses or any other information is different. While there are a few scenarios where this logic fails (parents shipping to their kid at college) it is the best CMS can do without having the information from 1 and 2 above. It does ensure though that the more common scenario of a person shipping to themselves at another address (work, vacation, etc.) will be handled correctly as a normal, non-gift type order.~~</li>~~
	~~</ol>~~

	Note: CMS uses an internal address_id to uniquely identify the recipient in an order. This means the same customer/recipient cannot appear more than once in the order but otherwise there is no reason why you cannot have two recipients with the same name (as long as they are different customers.) This has changed in CMS 9.0 where you can now have the same recipient on the order multiple times.		'''Note:''' CMS uses an internal address_id to uniquely identify the recipient in an order. This means the same customer/recipient cannot appear more than once in the order but otherwise there is no reason why you cannot have two recipients with the same name (as long as they are different customers.) This has changed in CMS 9.0 where you can now have the same recipient on the order multiple times.

	=Customer Duplicate Report=		=Customer Duplicate Report=

Msnyder: /* Matching orders to existing customers during order import */

2014-08-22T18:38:26Z

Matching orders to existing customers during order import

← Older revision		Revision as of 18:38, 22 August 2014
Line 5:		Line 5:

	=Matching orders to existing customers during order import=		=Matching orders to existing customers during order import=
	All imported orders that are not imported with the [[Automated Imports Module]] option must go through a verification process (Fulfillment>Verify Imports) so you can ensure the imported order is one that should be converted into a real order. During that verification process you can tell if a customer match was found by looking at the Cust# field on the View Invoice screen (the first screen you are presented with when verifying an order.) If there is a number in this field you know CMS has matched it up to a customer in your mail list. If no match was found, the Cust# field will instead say "<new>".		All imported orders that are not imported with the [[Automated Imports Module]] option must go through a verification process (Fulfillment->Verify Imports) so you can ensure that the imported order is one that should be converted into a real order. During that verification process, you can tell if a customer match was found by looking at the Cust# field on the View Invoice screen (the first screen you are presented with when verifying an order). If there is a number in this field, you know CMS has matched it up to a customer in your mail list. If no match was found, the Cust# field will instead say "<new>". The logic CMS uses to find such matches is as follows:
	The logic CMS uses to find such matches is as follows:		# If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.
	~~<ol>~~		# The next matching will be done on email address (CMS 9.0.1 or later. To disable the option you need to be on CMS version 9.0.4 or later, and then remove the check on the setup option under Fulfillment Options->Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address. '''Note:''' in the XML only the <nowiki><Order><Customer><ContactAddress><Address><Email></nowiki> element is used for email address matching.
	~~<li>~~If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.~~</li>~~		# If no customer number or email match is found, it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit ZIP code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation, or abbreviations. Here is an example:
	~~<li>~~The next matching will be done on email address (CMS 9.0.1 or later. To disable the option you need to be on CMS version 9.0.4 or later and then ~~removing~~ the check on the setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address. '''Note:''' in the XML only the <nowiki><Order><Customer><ContactAddress><Address><Email></nowiki> element is used for email address matching~~</li>~~
	~~<li>~~If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit ~~zip~~ code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation ~~and~~ abbreviations. Here is an example:~~</li>~~
	~~</ol>~~

	<blockquote>		<blockquote>
Line 25:		Line 22:
	</blockquote>		</blockquote>

	If you should find that CMS has matched up an order to the wrong customer or did not find a customer that it should have, during the verification of the order you can still go to the first screen on the order (Customer) and retrieve the proper customer there. Be warned that when retrieving a customer in this manner it will replace the billing and shipping addresses from the imported order with the default addresses from the retrieved customer record. We expect this behavior to change in the future so CMS will retain the addresses from the imported order or give you the option which to use.		If you should find that CMS has matched up an order to the wrong customer or did not find a customer that it should have, during the verification of the order you can still go to the first screen on the order (Customer) and retrieve the proper customer there. Be warned that when retrieving a customer in this manner, it will replace the billing and shipping addresses from the imported order with the default addresses from the retrieved customer record. We expect this behavior to change in the future so CMS will retain the addresses from the imported order or give you the option of which one(s) to use.

	=Multi-recipient and Gift orders=		=Multi-recipient and Gift orders=

Msnyder: /* Overview */

2014-08-22T18:33:22Z

Overview

← Older revision		Revision as of 18:33, 22 August 2014
Line 1:		Line 1:
	=Overview=		=Overview=
	When an order or catalog request is imported into CMS, from any source, CMS must take steps to identify if this is a new or existing customer. If it is a new customer you'd want CMS to create a new customer record. On the other hand, if it is for an existing customer you'd want CMS to attach the order or catalog request to its matching/existing customer record and not create a duplicate customer.		When an order or catalog request is imported into CMS, from any source, CMS must take steps to identify if this is a new or existing customer. If it is a new customer, you'd want CMS to create a new customer record. On the other hand, if it is for an existing customer, you'd want CMS to attach the order or catalog request to its matching/existing customer record and not create a duplicate customer.

	This article explains the logic used by CMS uses when trying to determine ~~that~~ customer match during an import. A similar process is used to determine if the recipient (ship-to) is different from the buyer and this ~~too~~ is covered here.		This article explains the logic used by CMS uses when trying to determine a customer match during an import. A similar process is used to determine if the recipient (ship-to) is different from the buyer and this is also covered here.

	=Matching orders to existing customers during order import=		=Matching orders to existing customers during order import=

Luke steinmetzer at 20:05, 23 July 2014

2014-07-23T20:05:20Z

← Older revision		Revision as of 20:05, 23 July 2014
Line 9:		Line 9:
	<ol>		<ol>
	<li>If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.</li>		<li>If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.</li>
	<li>The next matching will be done on email address (CMS 9.0 or later ~~only~~ and ~~can be defeated with a~~ setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address. '''Note:''' in the XML only the <nowiki><Order><Customer><ContactAddress><Address><Email></nowiki> element is used for email address matching</li>		<li>The next matching will be done on email address (CMS 9.0.1 or later. To disable the option you need to be on CMS version 9.0.4 or later and then removing the check on the setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address. '''Note:''' in the XML only the <nowiki><Order><Customer><ContactAddress><Address><Email></nowiki> element is used for email address matching</li>
	<li>If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit zip code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation and abbreviations. Here is an example:</li>		<li>If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit zip code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation and abbreviations. Here is an example:</li>
	</ol>		</ol>

Jmorrison: /* Matching orders to existing customers during order import */

2013-08-22T23:57:47Z

Matching orders to existing customers during order import

← Older revision		Revision as of 23:57, 22 August 2013
Line 9:		Line 9:
	<ol>		<ol>
	<li>If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.</li>		<li>If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.</li>
	<li>The next matching will be done on email address (CMS 9.0 or later only and can be defeated with a setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address.</li>		<li>The next matching will be done on email address (CMS 9.0 or later only and can be defeated with a setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address. '''Note:''' in the XML only the <nowiki><Order><Customer><ContactAddress><Address><Email></nowiki> element is used for email address matching</li>
	<li>If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit zip code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation and abbreviations. Here is an example:</li>		<li>If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit zip code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation and abbreviations. Here is an example:</li>
	</ol>		</ol>

Russ horton: /* Multi-recipient and Gift orders */

2013-06-27T23:36:06Z

Multi-recipient and Gift orders

← Older revision		Revision as of 23:36, 27 June 2013
Line 28:		Line 28:

	=Multi-recipient and Gift orders=		=Multi-recipient and Gift orders=
	CMS is capable of handling and importing orders with multiple recipients and/or gift orders (where the recipient is different than the buyer.) In either of the two scenarios the purchaser may or may not be receiving merchandise themselves. When importing such orders, CMS needs to determine if the recipient(s) is the same as the purchaser or if they should be treated as someone else. This is ~~handled~~ in the following ways:		CMS is capable of handling and importing orders with multiple recipients and/or gift orders (where the recipient is different than the buyer.) In either of the two scenarios the purchaser may or may not be receiving merchandise themselves. When importing such orders, CMS needs to determine if the recipient(s) is the same as the purchaser or if they should be treated as someone else. The reason for this is CMS will can (optionally) create new customer records for recipients and when printing invoices/pick-tickets CMS will suppress prices from showing so the recipient will not see what you paid.

			This is logic used to determine if the recipient is the same as the buyer works in the following ways:
	<ol>		<ol>
	<li>In our XML specification document (CMSxml.xsd) there is an attribute of the <Recipient> tag that reads 'IsPurchaser'. If the system that is generating the output for CMS to import is capable, our first recommendation would be to use this attribute. In use it looks like: <Recipient IsPurchaser="false"> In this example the value of 'false' is telling CMS that the recipient is not the same as the purchaser and as such should treat this as a gift order, even if there are no gift notes. If the purchaser is shipping to themselves, even at a different address, this value should be 'true'.</li>		<li>In our XML specification document (CMSxml.xsd) there is an attribute of the <Recipient> tag that reads 'IsPurchaser'. If the system that is generating the output for CMS to import is capable, our first recommendation would be to use this attribute. In use it looks like: <Recipient IsPurchaser="false"> In this example the value of 'false' is telling CMS that the recipient is not the same as the purchaser and as such should treat this as a gift order, even if there are no gift notes. If the purchaser is shipping to themselves, even at a different address, this value should be 'true'.</li>

Russ horton: /* Matching orders to existing customers during order import */

2013-06-27T23:33:21Z

Matching orders to existing customers during order import

← Older revision		Revision as of 23:33, 27 June 2013
Line 22:		Line 22:
	Bill P. Smith <br />		Bill P. Smith <br />
	123 Main St. #3 <br />		123 Main St. #3 <br />
	Evenston, IL 60202~~-1234~~		Evenston, IL 60202
	</blockquote>		</blockquote>

Russ horton: /* Matching orders to existing customers during order import */

2013-06-27T23:33:07Z

Matching orders to existing customers during order import

← Older revision		Revision as of 23:33, 27 June 2013
Line 10:		Line 10:
	<li>If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.</li>		<li>If a customer number was passed in the file, CMS will use that customer number to match against the customer number in CMS and will append to that customer. No further matching logic will be used. Most sources of orders will not be able to establish and/or pass the proper customer number so, while it will be considered the best match if present...it usually isn't.</li>
	<li>The next matching will be done on email address (CMS 9.0 or later only and can be defeated with a setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address.</li>		<li>The next matching will be done on email address (CMS 9.0 or later only and can be defeated with a setup option under Fulfillment Options>Import). CMS will match the order to a unique customer record it finds with the same email address. If more than one customer record is found with the same email address, no match will be made by email address.</li>
	<li>If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and zip code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation and abbreviations. Here is an example:</li>		<li>If no customer number or email match it is then up to CMS to scrutinize the name and address to find a match. In this case CMS will match the last name and all of the numbers from the address and 5 digit zip code. (Note: this matching is done by comparing the customer's mailing address against the order's mailing/primary address, not billing or shipping.) Only when there is a perfect match will CMS link the imported order to a customer. The reason CMS uses numbers only for the address and only a last name is to ensure the match does not get tripped up by middle initials, misspellings, punctuation and abbreviations. Here is an example:</li>
	</ol>		</ol>

Line 16:		Line 16:
	William Smith <br />		William Smith <br />
	123 Main Street Apt 3 <br />		123 Main Street Apt 3 <br />
	Evanston, IL 60202 <br />		Evanston, IL 60202-1234 <br />
	<br />		<br />
	will still match <br />		will still match <br />