Print configuration

A print integration turns Documents into PDFs, such as delivery notes, invoices and pallet labels, and emails them. Every print is driven by one entry in the integration's genericPrintConfigs. Each entry is a print key, which chooses the print, plus a free-form properties object, which is whatever that print accepts:

{
  "emailAddresses": ["warehouse@example.com"],
  "emailSubject": "Delivery note {0}",
  "genericPrintConfigs": [
    {
      "printKey": "pallet-label",
      "properties": { "copies": 2, "maximumItems": 4 }
    }
  ]
}

This page lists every print, the Document type it renders from, and the properties it reads.

Rules every print follows

• A property left out falls back to its default. The Default column in the tables below is what the print uses when the property is absent. A blank means null or empty.
• The properties object is never validated. A misspelt key is silently ignored, so check names against this page. Each print reads its own shape, so the same property name can mean different things to different prints.
• A print only renders Documents of its type. Configuring order-a4 against a pick produces a translation error, not a PDF.
• A print the Document gives nothing to produces no output, and that's not an error. A pallet label on a despatch that was never palletised creates no PDF and no email, and the integration's other prints are unaffected. You don't need a requirement for this.
• Several prints can share one integration. A despatch producing a delivery note and pallet labels lists both keys, each with its own properties.

Integration settings around the prints

These settings sit beside genericPrintConfigs and belong to the integration rather than to any one print: emailAddresses, emailSubject, emailBodyText, emailSubjectTemplate, emailBodyTemplate and cartonUnitOfMeasureId. The source guide documents them with the other integration settings rather than here.

Every print entry

Each entry in genericPrintConfigs can carry these properties.

Email subject and body

Each print can carry its own subject and body, so a despatch producing a delivery note and pallet labels doesn't send both under one subject. The subject and the body each resolve down their own chain, stopping at the first one that's set:

subjectTemplate (entry) -> subject (entry) -> subjectTemplate (integration) -> subject (integration)

Null falls through. An empty string is an answer: it stops the chain, and the email goes out with nothing there.

Templates

A template is written in Liquid and rendered when the output is created. It can read printKey, reference, filename, documentNumber, documentType and documentDate:

"emailSubjectTemplate": "Delivery note {{ documentNumber }} for {{ reference }}"

Link placeholders

A template can't link to the Document or the file, because those links are built when the email is sent, long after the template has run. A plain emailSubject or emailBodyText reaches the sender unrendered and keeps its numbered placeholders, which is where the links are:

Use a template for anything that reads the Document, and a plain string for anything that needs a link.

Requirements

An entry's requirement is a true-or-false map expression, in the same language (and with the same $.document root) as a config-driven map's condition. Omit it and the print always runs. This one prints pallet labels only when the Document has containers:

{
  "printKey": "pallet-label",
  "requirement": {
    "op": "compare", "operator": "gt",
    "left": { "op": "path", "path": "$.document.containers.length()" },
    "right": { "op": "literal", "value": 0 }
  }
}

• Anything but true is a no. An expression that reads a field the Document doesn't carry produces nothing, and nothing doesn't print.
• op needn't be written first. Stored settings can come back with their keys reordered.
• A field the language doesn't have is refused, not dropped. This stops half a requirement silently deciding whether a Document prints. Both checks happen when the settings are saved, not on the first despatch.
• A skipped print has still had its identifiers resolved, because that happens before any requirement is evaluated. It costs a lookup and changes nothing about what's produced.

Print keys

A4 Document prints

Used by credit-a4, invoice-a4, order-a4 and proof-of-delivery-a4 (configuration type DocumentWithLinesConfig).

Note tags (noteTags)

Line notes (lineNotes)

Pallet label

Used by pallet-label (configuration type PalletLabelConfig).

Tesco pallet label

Used by tesco-pallet-label (configuration type TescoPalletLabelConfig).

3V delivery note and packing list

Used by 3v-delivery-note and 3v-packing-list (configuration type _3VPrintConfig).

3V large label

Used by 3v-large-label (configuration type _3VLabelConfig).

Reference types

The referenceType1 and referenceType2 properties on the 3V prints take one of these values: buyerorder, credit, deliverynote, fulfilment, default, inventory, invoice, invoiceadditional, journal, order, orderadditional, payment, paymentadditional, product, proofofdelivery, quote, remittance, salesreport, shipment, statement, stockadjustment, transaction, warehousetransfer, workorder.

We Are Rise delivery note

Used by we-are-rise-delivery-note (configuration type WeAreRiseDeliveryNoteConfig).

Layout and despatch details

Lines, codes and dates

Templates and values

Variants (variants)