How print integrations work
Lesson 26 of 28 7 min read
A print integration turns Documents into PDFs - delivery notes, invoices, pallet labels - and emails them. Learn how print entries are structured and the rules every print follows.
Warehouses and their customers still need paper: a delivery note in the box, a label on every pallet, an A4 invoice for a customer who doesn't take EDI. A print integration in Supply Lens produces those PDFs from Documents and emails them to whoever needs them.
By the end of this lesson you will be able to read and write a print configuration, and predict when a print will and won't produce output.
One entry per print
Every print is driven by one entry in the print integration's genericPrintConfigs list. Each
entry is a print key (which print to produce) plus a free-form properties object (how
that print should look):
{
"emailAddresses": ["warehouse@example.com"],
"emailSubject": "Delivery note {0}",
"genericPrintConfigs": [
{
"printKey": "pallet-label",
"properties": { "copies": 2, "maximumItems": 4 }
}
]
}
Here, every despatch the integration receives produces pallet labels, two per pallet, listing up to four products each, emailed to the warehouse.
Integration settings versus print settings
| Belongs to the integration | Belongs to one print entry |
|---|---|
emailAddresses, emailSubject, emailBodyText, emailSubjectTemplate, emailBodyTemplate, cartonUnitOfMeasureId | printKey, properties, requirement, and the entry's own emailSubject, emailSubjectTemplate, emailBodyText, emailBodyTemplate |
The integration settings are shared by every print; a print entry can override the email subject and body for itself (next lesson).
Six rules every print follows
- A property left out uses its default. Each print's reference table lists defaults; a blank default means null or empty.
- Properties are never validated. A misspelt key is silently ignored, so check names against the reference, not a schema.
- A print only renders documents of its type.
order-a4against a pick produces a translation error, not a PDF. - Nothing to print is not an error. A pallet label on a despatch that was never palletised creates no PDF and no email, and the other prints are unaffected.
- Several prints can share one integration. A despatch producing a delivery note and pallet labels lists both keys, each with its own properties.
- The same property name can mean different things in different prints, because each print reads its own shape.
Silent typos
Because properties are not validated, "copys": 2 does nothing and raises no error: you get
the default of one label. When a print ignores your setting, check the spelling first.
Which Document does each print need?
Most warehouse prints (labels, delivery notes, packing lists) render from a Pick Document. The A4 prints render from the Document type in their name. Printed invoices now show any prepaid amount between the charges and the totals.
Sandpiper Gifts' despatch paperwork
Sandpiper's 3PL wants a pallet label for every pallet and a copy of each wholesale order
as an A4 PDF. The implementer plans two print entries: pallet-label, fed by Picks, and
order-a4, fed by Orders. Because each print only renders its own Document type, each
needs the matching Documents mapped to the print integration.
Recap
- A print integration's genericPrintConfigs holds one entry per print: a printKey plus properties.
- Email addresses and default subject and body belong to the integration; entries can override them.
- Missing properties use defaults, misspelt ones are silently ignored.
- Each print renders only its own Document type; nothing to print is not an error.
- Warehouse labels and notes mostly render from Picks; A4 prints from their named type.
Quick guides for this topic
Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.