Settings patterns the connectors share

Lesson 4 of 28 8 min read

Import windows, filters, translation maps with defaults, tag-driven rules and reference types appear on almost every warehouse connector. Learn them once here.

Open the settings of any two warehouse connectors and you will see the same ideas under slightly different names. Once you recognise the patterns, a new connector's settings read like a checklist rather than a puzzle.

By the end of this lesson you will be able to explain the five patterns that recur across Mintsoft, Clarus WMS, Logiwa, Manhattan, DespatchCloud, ControlPort and Flexport, and know which values you should and should not edit.

Pattern 1: the import window

Every Receive Configuration that polls the warehouse (shipments, receipts, stock, imported orders) controls which records it fetches with three settings.

setupDate	Only records created on or after this date are imported. Set automatically when the integration is first configured, so historical orders and shipments are not pulled in at go-live. Not normally changed afterwards.
lastImportDate	The timestamp of the most recent import. Updated after each run, so the next run only fetches records changed since then. Managed by the system: do not edit it by hand unless a connector's guide tells you to.
importDelay	A wait applied before a record is imported, written as a duration such as 00:05:00 for five minutes. It gives other systems, or the warehouse itself, time to finish changing the record first.

Rendering diagram...

One documented exception

Clarus WMS stock levels use lastImportDate deliberately: clearing it makes the next run import a complete stock snapshot. You will meet this in the Clarus module. Outside cases like that, leave lastImportDate alone.

Pattern 2: filters, where empty means everything

Many connectors let you narrow an import to particular warehouses, clients, channels, statuses or depositors. They all follow the same rule: when the list is set, only matching records are imported; when it is empty, everything is included.

Examples: Mintsoft's filterByWarehouseId and filterByClientId, Clarus WMS's filterByAccountCode, Logiwa's depositorIds and warehouseIds, ControlPort's includeWarehouseIds.

Empty is not safe on a shared 3PL account

A 3PL often runs many clients, and your credentials may see more than your own. An empty client or account filter imports every record the credentials can see. Clarus's guide says it plainly: set the account filter to the organisation's own account code.

Pattern 3: translation maps with a default

Your carriers, services and channels rarely use the warehouse's names. Connectors carry maps that translate one into the other, for example Mintsoft's courierServiceMap, Manhattan's carrierMap and carrierServiceMap, and DespatchCloud's shippingMethodMap.

Most are evaluated in order and support a default value used when nothing matches. Always ask what should happen to an order with an unmapped service: a sensible default, or (where the connector allows it) passing the original value through, as Mintsoft's fallBackToDocumentCourierService does.

Pattern 4: rules driven by tags

Documents in Supply Lens carry tags: labels such as rush, a sales channel or an order type. Several connectors use the first matching tag to decide a warehouse value:

Mintsoft tagChannelMap (tag → Mintsoft channel)
Manhattan tagToOrderTypeMap (tag → Manhattan order type)
ControlPort tagChannelAccountIdMap, tagOrderTypeMap and tagAllowPreorderMap
Clarus WMS ids such as goodsInReceiptKindId, which can be a constant or a rule reading the document's tags

The reverse also exists: tag generation settings (documentLevelTagGeneration and documentLevelAdvancedTagGeneration on Mintsoft and Flexport) create tags from fields on the imported record, so later steps can classify it.

Tags let you change behaviour without a settings change

If orders can be tagged upstream, a tag-driven rule lets the business route a new order type by tagging it, rather than asking you to edit the configuration.

Pattern 5: reference types for traceability

A warehouse order number, an ERP order number and a customer's PO number are all references. Settings such as orderNumberReferenceType, externalOrderReferenceType (Mintsoft) and orderIdReferenceType, erpOrderReferenceType (Manhattan) choose which document reference type carries each one. Get these right and a shipment imported weeks later can still be matched to the order it fulfils.

Reading a new connector in five minutes

Priya, an implementer, opens the ControlPort guide for the first time. She sorts every setting into the five patterns:

Import window: the Shipment setupDate, lastImportDate, importDelay.
Filters: Inventory includeWarehouseIds.
Translation map: carrierServiceShippingMap.
Tag rules: tagChannelAccountIdMap, tagOrderTypeMap, tagAllowPreorderMap.
Left over: importBatches and takeLatestBatchOnConflict.

Only the last two need real study. Everything else she already understands.

Recap

Import windows use setupDate, lastImportDate and importDelay; leave lastImportDate to the system except where a guide says otherwise.
Filters import only matching records when set and everything when empty.
Translation maps are evaluated in order and usually have a default; decide what unmapped values should do.
Tag-driven rules pick warehouse values from the first matching tag; tag generation creates tags from imported data.
Reference types keep warehouse, ERP and customer numbers traceable across Documents.

Quick guides for this topic

Complete and continue

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

Master data a warehouse depends on Testing and going live with a warehouse