Key takeaways
- A lookup table pairs each partner value (the lookup value) with the value your system uses (the end value). Mappings call it with
$lookupTable. - Link a table to one of your connected apps and end values are picked from that app’s records, not typed.
- Weredi checks your partners’ recent documents and lists the codes your table doesn’t translate yet, before they cause a failed order.
Why partner codes need translating
EDI is full of codes that make perfect sense to the company that sent them and none to your software. A retailer doesn’t write the name of the store it wants delivered; it writes its own location number. It doesn’t name the carrier; it sends a four-letter SCAC. Your accounting system knows none of these.
N1*ST*SUMNER DC*92*0412~ TD5**2*FDEG~ PO1*1*2*CA*100.80**UP*012345678905~ ITD*01*3*2**30**60~
You could fix each one by hand on every order. Or you translate it once, in a table, and let every order after that use it.
What a lookup table looks like
| Lookup value | End value | Used for |
|---|---|---|
0412 | Sumner distribution centre | Customer or ship-to |
0587 | Kent store | Customer or ship-to |
FDEG | FedEx Ground | Carrier |
CA | Case of 12 | Unit of measure |
In a mapping, the field that needs translating wraps its expression in $lookupTable: the partner’s value goes in, your value comes out.
End values from your own records
A table can be general purpose, with end values you type. Or you can link it to one of your connected apps and one of its entities. From then on, each end value is chosen from that app’s real records, so a customer name can’t be misspelled into a customer that doesn’t exist.
Forgiving matching
Partners aren’t always consistent with their own codes. Weredi first looks for an exact match, then tries again ignoring case and spaces, so a partner sending dc0412 still finds the line you wrote as DC 0412.
Missing codes, found before they hurt
Each table shows which mappings use it and on which field. Weredi then runs those mappings on your partners’ recent documents and lists the values they produce that the table doesn’t translate yet, with a count of what’s missing. A new store number shows up there before it shows up as an order that couldn’t be booked.
Add it where you notice it. In the mapping editor, pick a sample and the lookup card evaluates the expression on it. If the value has no line yet, add it right there; the expression is wrapped in $lookupTable for you.
Bring your spreadsheet
Most suppliers already keep these codes somewhere. Import a CSV with two columns, the lookup value and the end value: new values are added, existing ones get their end value replaced, and Weredi tells you how many rows were added, replaced and skipped. Export the table to CSV whenever you want a copy.
Safe to change
Because a table knows which mappings use it, removing one isn’t a blind click: Weredi warns that those mappings will stop translating its values, so you decide with the consequences in front of you.
Questions
One table per partner, or one shared table?
Either. Location numbers are usually specific to one retailer, so they get a table each. Carrier or unit codes are often the same everywhere, and one general-purpose table can serve every mapping.
Is the matching case-sensitive?
No. An exact match wins first; failing that, case and spaces are ignored.
Can I bring my existing code list?
Yes. Import a CSV of lookup values and end values, up to 2 MB per file, and export it again at any time.
Which plans include lookup tables?
Lookup tables are part of Weredi Plus and Enterprise, and of every active trial, along with mappings and the accounting connections.