Custom Processor Applet

The monitoring and set-up screen for a hand-off queue to an external processor: a Processor Filter names a sales document type, a company and a posting status, and when a matching document becomes final its header is copied into the Processing Queue for your own integration to pick up through the API. Nothing here changes a document’s status or posts anything; the processing itself happens outside BigLedger. A filter with posting status Draft never fires, and the field cannot be changed after creation, so create each filter as Final, one per company.

Your job, and the screen for it

Overview

The Custom Processor Applet is the monitoring and configuration screen for a hand-off queue between BigLedger and an external processor. You create a Processor Filter that names a sales document type, a company and a posting status; when a matching document reaches FINAL, the backend copies its header into a Processing Queue row. An external integration reads that queue through the API and does its work. While it works it may write its progress and errors onto the queue row; when it reports back, the queue row is deleted and a Processing History entry takes its place. The applet also lists the Price Tag Sync History — the successful pushes of pricing-scheme changes to an electronic-shelf-label (ESL) system.

Nothing in this applet or in the BigLedger backend changes a document’s posting status. The old description “moves documents from DRAFT to FINAL” is not what the code does: the queue is filled because a document became FINAL, and the processing itself happens outside BigLedger.

Where it fits

Screens and menus

Route root applet/tnt/wavelet/erp/custom-processor-applet. The left menu has four listings, all read from the backend with a paginated grid (search, column filters, grid toggle). Only the Processor Filter listing has a create/edit form.

The queue, history and price-tag screens have no buttons other than the grid toggle: there is no retry, re-queue or delete from the applet.

The only image under static/images/custom-processor-applet/ is an illustrative infographic; it is not embedded because its “automated processing filters / real-time background queues” story overstates what the applet does.

Configuration

Before you can use it

• The five sales document applets above produce the documents; a document is only considered at the moment it becomes FINAL — from the listing, from inside the document, or through the API.
• The company exists in Organisation; the filter lookup is by tenant, server document type, the document’s company and posting status, so create one filter per company.
• An external processor — your integration, built by you or your integrator — that reads the queue through the API and reports back through the access-key callback POST …/histories/custom-creation/etl-ep, which permanently deletes the queue row and then writes the Processing History row — so a row that vanishes from the queue is the normal end state, not a fault. The two are separate steps (read from the code, not tried): if the history write fails, the queue row is already gone, so have the integration keep its own record of what it reported. (Before that, the processor can write its status and errors onto the queue row through the queue’s own access-key etl-ep endpoints: a query, a read and two updates.) Without a processor the queue only grows. The integration contract is a developer matter; ask BigLedger for the queue API when you commission one.
• For Price Tag Sync History: the shelf-label (De-Tag) sync must be installed on your tenant by BigLedger, and the PRICING_SCHEME_DE_TAG_SYNCING_PROCESSOR job must be scheduled in the Scheduler with its settings (interval, username, password, company, store).
• API permissions: TNT_DM_ERP_GENERIC_DOC_CUSTOM_PROCESSING_FILTER_{OWNER, ADMIN, CREATE, UPDATE, DELETE, READ} and the matching _QUEUE_* and _HISTORY_* sets.

Applet settings

No setting does anything — nothing in the four listing screens or the filter form uses one:

• Settings › Default Selection shows Default Branch / Default Location under “Applet Default Settings” — the “User Default Settings” copy is commented out of the template — and cannot save: the route mounts the component with no settings input and no save listener, so picking a value throws in the browser (a known issue, reported to engineering). Nothing in this applet asks for a branch or location anyway.
• Settings › Field Settings shows eight toggles (Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project) with a SAVE button that does nothing — a placeholder copied from the document applets.
• Personalization › Default Selection fails when you pick a value.

Configuration is the Processor Filter records themselves (Fields below).

There are no document-behaviour settings: the applet owns no document.

Feature visibility / permissions

The applet has no SHOW_* / HIDE_* client-side permissions of its own. The Client-Side Permission and permission-set screens are the shared ones.

Fields

Processor Filter

Processing Queue (read-only)

Each row carries the filter, the document (type, numbers, dates, company) and then what the external processor has written: processor, start and end, process status and error, response status and error, and the external document it created. There is at most one row per tenant, company, processor, posting status and document — a second is refused with GENERIC_DOC_CUSTOM_PROCESSING_QUEUE__UNIQUE_CONSTRAINT_ALREADY_EXIST.

Processing History (read-only)

What the external processor reported: the document, the processor, the external document type, code and submission number and the response. History is append-only — nothing edits an entry once written.

Price Tag Sync History (read-only)

One row per price change the shelf-label system accepted.

Lifecycle and effects

Master-data / monitoring applet: no posting status, no journal, no stock. Filters are created, edited and deleted from the Processor Filter screen.

Document hand-off

1. A sales document becomes FINAL — from a screen or through the API.
2. BigLedger looks for the first ACTIVE filter matching the tenant, the document type, the document’s company and the document’s posting status. One document therefore creates at most one queue row even if several filters match.
3. If one is found, a background job runs at once (with two retries ten seconds apart) and creates the Processing Queue row. It sets no processor and no external status, and does not touch the document.
4. Everything after that is the external processor’s job: it reads the queue, may write its status and errors onto the queue row while it works, and finally calls the access-key callback, which deletes the queue row for good and records the Processing History row that carries its status and result. A failure shows on the queue row (External Process Error / External Response Error) only while the processor has written to the row and not yet called back.

Price tag sync

1. Once the sync is installed, every new or changed pricing-scheme price is queued for sync.
2. The scheduled job PRICING_SCHEME_DE_TAG_SYNCING_PROCESSOR (settings: interval, username, password, company, store) signs in to the shelf-label vendor and sends each queued price: a price whose pricing scheme is not coded PRICE_001 is marked SYNCING_SKIPPED — only that one scheme is ever pushed, so a differently coded scheme never gets a history row; a vendor answer of SUCCESS adds a Price Tag Sync History row and marks the price SYNCING_SUCCESSFUL; anything else marks it SYNCING_FAILED with the vendor’s text. The NFC URL on the history row is the same fixed value for every item, not one derived from the item.
3. PRICING_SCHEME_DE_TAG_SYNCING_QUEUE_DELETE_PROCESSOR, when scheduled, removes queued prices older than three months. The queue itself is not visible in this applet — only the success history is.

Related applets

• Sales Order (Internal), Sales Invoice (Internal), Sales Return (Internal), Sales Debit Note (Internal), Sales Credit Note (Internal) — the document types a filter can watch; finalising one of them is the only event that fills the queue.
• Organisation — companies used to scope filters.
• Pricebook — pricing-scheme link changes are what the price-tag sync pushes to the shelf labels.

Troubleshooting

Related documentation

• Pricebook Applet — pricing schemes and links.
• Sales Invoice (Internal) Applet — the posting-status endpoint that triggers the hand-off.