TxDownloaderPro ← Shopify — Epicor 9 and 9.5: what the shipped default templates set up

TxDownloaderPro ← Shopify — Epicor 9 and 9.5: what the shipped default templates set up

Keep this skill current. dlake ships updates often and this text is embedded in the CLI you have installed. Before relying on it, compare dlake --version with npm view @commercient/dlake version; if they differ, run npm install -g @commercient/dlake@latest and then dlake skills install, which overwrites the installed skill files with the current text.

dlake-txdownloaderpro is the parent skill and the authority for everything general: what the writeback objects are and how they are exposed to the Data API (§1–§7), how a key is scoped to them, the TxDownloaderPro configuration table and the TxDownloaderProTrans transaction table and their columns (§9, §10), the SFUpdated state machine (§10), the field-mapping columns ProcessStructure, ResultStructure, XMLResult, ERPResponse, JsonRequest and JsonResponse and the {{Object.Field}} template paths that read them (§11), the filter-operator vocabulary (§12), and the txdownloaderpro_* tools that are the preferred way to configure any of it (§14). Read it first; this page does not repeat it. dlake-txdownloaderpro-shopify is the Shopify page and carries the destination-side detail: it is the skill this page is a child of, and the authority for the conventions that hold across every ERP, so read it before this page. This page is dlake-txdownloaderpro-shopify/erps/epicor-9-and-9-5.md, and that skill’s ERP table is what points at it.

What follows is only what the shipped default templates for this pair themselves set, described from their DefaultQuery, DefaultProcessStructure and DefaultResultStructure columns. It is a description of structure: which objects and marker columns are read, which parts and members are filled, which token names appear. No template text is reproduced. This page grows as the default catalogue does.

1. What the templates deliver

One row per process the default set ships for this pair. The business language is the catalogue’s own, where it carries any; where it does not, the row says what the source and destination objects are and what the operation flags allow. Operations are the union of the IsInsert, IsUpdate and IsDelete flags over that process’s templates.

Process	What it delivers	Source → destination	Templates	Operations
Create New Customer	Shopify Customer to Epicor 9 Customer	Customer → Customer	1	create
SalesOrder	Shopify Order to Epicor 9 SalesOrder	Order → SalesOrder	1	create

Across the 2 default templates: 2 carry IsInsert, 0 carry IsUpdate, 0 carry IsDelete, and 2 carry IsCustomization. A flag decides which operation the process is allowed to perform, not which one it performs on a given record.

2. The process rows the import creates

Importing one of these templates writes one TxDownloaderPro row. The columns the import fills from the template are the ones the parent’s §9 describes: the query goes into Query, the inbound mapping into ProcessStructure, the outbound mapping into ResultStructure, and the operation flags onto the row. In-flight state is never in this table — it is in TxDownloaderProTrans (parent §10), keyed by SFUpdated.

A default template carries no TxDownloaderDllName and no template name of its own. It is identified by its field-process version, and the version is what supplies the DLL on a create. That is where erpProcessId comes from, so a create against the wrong version produces a row that never matches a run.

What the import sets	Where it comes from
Query	the template’s DefaultQuery — section 3
ProcessStructure	the template’s DefaultProcessStructure — section 4
ResultStructure	the template’s DefaultResultStructure — section 5
IsInsert / IsUpdate / IsDelete	the template’s own flags — section 1
the DLL and erpProcessId	the field-process version, not the template

The field-process versions this pair’s default templates belong to: TxDownloaderPro_11_1, TxDownloaderPro_11_2.

3. What the query retrieves

Query does not have one shape across the product (parent §9). For this pair, 2 carry a JSON object naming the module to retrieve. No query text is reproduced here; what follows is what those queries read and filter on.

• Objects read: customer, order.
• Members present in the JSON query object: ModuleName (2). Where a Where member is present it is empty.
• Where the filtering happens: the query names a module rather than a condition, so the selection the parent’s §12 describes is applied after retrieval, not by the query.

4. The inbound mapping document

ProcessStructure is a flat JSON object: each member names a field on the source side and its value is a template resolved against the retrieved record’s XML document (parent §11). Of this pair’s 2 default templates, 2 carry a DefaultProcessStructure. A parseable document carries about 11 members.

• Template path roots used: Customer, Order, line_items. A path’s first segment has to match the element the engine emits, and the document root itself is never part of the path.
• Line. section members present: Line.mainXml, Line.PartNum, Line.UnitPrice, Line.OrderQty, Line.LineDesc. 1 template name the collection through Line.mainXml; the members beside it are resolved against that collection’s own root rather than through the header.

5. Result structure — what goes back to the CRM

ResultStructure is the outbound half: up to four parts, each optional, filled from the source system’s response after the write (parent §11). Of this pair’s 2 default templates, 0 carry a parseable DefaultResultStructure, 2 carry none.

No default template for this pair fills a part. Nothing is written back to Shopify by these templates: the source system’s key stays in TxDownloaderProTrans and the CRM record is left as the user flagged it. If a tenant needs the key on the CRM record, ResultStructure is the column to fill, and the parent’s §11 gives its shape.

6. Verifying

Read the imported row before a run, not after. The parent’s §14 is the authority on these tools and §10 on the state they report.

# the processes this tenant has, with their unresolved-error counts
dlake admin txdownloaderpro_list_processes

# one process in its edit shape, including the query and both mapping documents
dlake admin txdownloaderpro_get_process --processId <id>

# retrieve one record through the SAVED query and render it as the engine sees it
dlake admin txdownloaderpro_preview_xml --processId <id>

# the state breakdown the parent §10 reads
dlake txdownloaderpro transactions <processId> --status <state>

The two failures this pair’s templates actually produce: a run that retrieves nothing, which is the module the query names, since these queries carry no condition of their own; and a record that arrives with fields empty, which is a path that does not match the emitted document. Both are read through txdownloaderpro_preview_xml, against a real record.

7. Where this sits

• dlake-txdownloaderpro — the parent: exposure, key scoping, the two tables, SFUpdated, the mapping columns, the filter vocabulary, the txdownloaderpro_* tools. Read it first.
• dlake-txdownloaderpro-shopify — the Shopify destination page, which this page is a child of: the query shape, marker conventions and mapping conventions this destination uses across every ERP, and the ERP table that lists this page and its siblings.
• dlake-integration-setup — registration, CRM choice and the ERP connector, of which writeback is one step.
• dlake-crmpro and dlake-normalsync — the inbound leg, going the other way.
• dlake — general tenant operation.

This page describes the shipped default template set for this pair, and grows as that set does.