From NewHaven Software Wiki

Revision as of 18:38, 22 August 2014

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.

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

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:

1. 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.
2. 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 <Order><Customer><ContactAddress><Address><Email> element is used for email address matching.
3. 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:

William Smith
123 Main Street Apt 3
Evanston, IL 60202-1234

will still match

Bill P. Smith
123 Main St. #3
Evenston, IL 60202

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

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:

1. 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'.
2. 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.)
3. 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.

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

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.

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.)

Alternate search terms - customer matching, order imports, order importing, name matching