What should new customers and orders be given?

Lesson 13 of 24 8 min read

Set customer type, price tier, payment terms, tax code and discount for new customers, and choose who the salesperson is on each order.

A new wholesale account that arrives with the wrong price tier or no salesperson creates work for someone. This lesson covers the settings that give new customers sensible defaults, and the settings that decide which salesperson appears on each order and on the customer.

Decision 1: what type of customer?

customerTypesBySourceIntegration	A default Unleashed customer type for each source Integration, with a fallback for any not listed. Use it when the channel tells you the type, for example Retail for the web shop and Trade for the B2B portal.
customerTypeTagMap	Sets the customer type from a tag. If the rule has data, that value is used; otherwise the tag's own value. Tag rules win over customerTypesBySourceIntegration.

Decision 2: what defaults should a customer get?

customerDefaultsTagMap	Sets a bundle of defaults on customers created or updated from tagged orders. The map's default applies when no tag matches, so a blanket set needs no tags.

Each entry in customerDefaultsTagMap can set any of these:

Field	What it sets
`customerType`	Unleashed customer type
`salesOrderGroup`	Default Sales Order Group
`deliveryMethod`	Default delivery method
`defaultWarehouse`	Default warehouse code
`sellPriceTier`	Sell price tier
`paymentTerm`	Payment term, used only when the order carries none of its own
`taxable`	Whether the customer is taxable
`taxCode`	Unleashed tax code name

Only set the fields you need. Each field you leave unset is left alone, but because the customer is written as a whole object, a field you do set overwrites whatever Unleashed would otherwise have defaulted to. paymentTerm and taxCode must name a payment term and tax code that already exist in your Unleashed account.

Decision 3: should customers carry a discount rate?

customerDiscountRateTagMap	Sets the discount rate on a created customer from a tag. Without data, the rate comes from the tag; with data, a fixed rate. With nothing configured, no rate is written.

Two things to get right:

The value is a rate between 0 and 1. A fifth off is 0.2, not 20. Nothing is converted on the way through. Some channels tag both a percentage and a rate (B2B Wave writes customer_discount_percentage as 20.0 and customer_discount_rate as 0.2). Point the map at the rate tag.
It does not discount the order it came from. A channel that applies discounts per line has already applied it. The rate governs orders raised inside Unleashed afterwards.

Decision 4: who is the salesperson?

The salesperson can come from several places. From most specific to least:

salesPersonTagMap (by tag on the order)
storeKeyToSalesPersonMap (by store)
A salesperson already on the Document

salesPersonTagMap	Sets the salesperson from a tag, with an optional default. Tag values support * wildcards and ^…$ regular expressions. Use it when the salesperson depends on the individual order.
storeKeyToSalesPersonMap	Sets the salesperson for every order from a given store. Use it when each channel has one owner.
salesPersonEmailTagMap	Sets the salesperson's email address from a tag. Email is preferred over name when resolving, because it survives spelling differences.
loadDefaultSalesPerson	When true, the salesperson on the Unleashed customer record is put on the order.
setCustomerSalesPerson	Off by default. When true, the salesperson resolved for the order is also written to the customer.

A name must match an Unleashed salesperson's full name or email address exactly. If it does not, the salesperson is dropped with a warning; the order is not failed. Matching by email is more forgiving of a missing initial or a changed spelling.

setCustomerSalesPerson re-stamps every order

Because the customer is written as a whole object on every order where Supply Lens holds no resolved Party, setCustomerSalesPerson re-stamps the rep each time, quietly undoing changes made in Unleashed. Pair it with skipCustomerUpdateIfExists so the first order sets the rep and later orders leave it alone.

Two directions

loadDefaultSalesPerson takes the customer's rep and puts it on the order. setCustomerSalesPerson takes the order's rep and puts it on the customer. With both on, the first order decides the customer's rep and every later order reads it back.

Hilltop's café defaults

New cafés should be Trade customers on the Wholesale price tier with 30-day terms. Priya sets customerDefaultsTagMap with a rule for the café tag setting customerType, sellPriceTier and paymentTerm, each named exactly as in Unleashed. Cafés in the north belong to Sam and those in the south to Alex, and the B2B portal tags each order with the rep's email. She uses salesPersonEmailTagMap on that tag, turns on setCustomerSalesPerson with skipCustomerUpdateIfExists, and the first order from each café sets its rep in Unleashed.

Recap

Customer type comes from tags first, then the source Integration.
customerDefaultsTagMap sets type, group, delivery method, warehouse, price tier, terms and tax; set only what you need.
Discount rates are between 0 and 1, and do not discount the order they came from.
Salesperson: tag map beats store map beats the Document; names must match exactly, emails are safer.
Pair setCustomerSalesPerson with skipCustomerUpdateIfExists.

Quick guides for this topic

How do I add Unleashed?

Complete and continue

Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.

How should customers be found and created?How should delivery details appear?