TxDownloaderPro ← Salesforce — QuickBooks Desktop: what the shipped default templates set up

TxDownloaderPro ← Salesforce — QuickBooks Desktop: 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-salesforce is the Salesforce 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-salesforce/erps/quickbooks-desktop.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. The community templates the catalogue also carries for this pair are listed in a section of their own below, by count, object and name only.

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
Sales Invoice Import	Commercient sync’s your CRM Invoice with item list and creates standard Order records in the ERP. The Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Opportunity, Order, Quote → Invoice	6	create / update
Sales Order Import	Commercient sync’s your CRM Orders with item list and creates standard Order records in the ERP. The Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Opportunity, Order, Quote → Order	4	create / update
Create Item and Sales Order	Salesforce Opportunity to QuickBooks Sales order	Opprtunity, Order, Quote → QuickBooks Sales Order	3	create / update
Customer Import	Commercient sync’s your CRM Accounts and creates Receivable Customer (AR Customer) list in the ERP. The AR Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Account, Customer → Customer	3	create / update
New Bill Import	Commercient sync’s your CRM Orders with item list and creates standard Order records in the ERP. The Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Opportunity, Order, Quote → Bill	3	create / update
Purchase Order Import	Commercient sync’s your CRM Purchase Orders with item list and creates standard Order records in the ERP. The Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Opportunity, Order, Quote → Purchase Order	3	create / update
Vendor Credit Memo Import	Commercient sync’s your CRM Orders with item list and creates standard Credit Memo records in the ERP. The Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Opportunity, Order, Quote → Vendor Credit Memo	3	create / update
Create New Customer with Contact	Salesforce Account to QuickBooks Customer Contact	Account → Customer, Customer Contact	2	create / update
Create New Lead	Salesforce Lead to QuickBooks Lead	Lead → Lead	2	create / update
Create New Non Inventory Item	Salesforce Product to QuickBooks Non Inventory Item	Product2 → ItemNonInventory	2	create / update
Create New Sales Receipt	Salesforce Order to QuickBooks Sales Receipt	Order → SalesReceipt	2	create / update
Create or Update Payment	—	Order → Payment	2	create / update
CreateNewEstimate	Salesforce Quote to QuickBooks Estimate	Quote → Estimate	2	create / update
New Job Import	Commercient sync’s your CRM Accounts and creates Receivable Customer (AR Customer) list in the ERP. The AR Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Account → Customer, Job	2	create / update
CustomerShipToAddress	Salesforce Account to QuickBooks Customer Ship To Address	Account → ShipTo	1	update
Delete List Entry	Salesforce Account to QuickBooks Customer - Delete List Entry	Account → List Entry	1	delete
Delete Transaction Entry	Salesforce Order to QuickBooks Sales Order - Delete Transaction Entry	Order → Transaction Entry	1	delete
Inventory Product Import	Commercient sync’s your CRM Products/Items with item list and creates standard Product/Items records in the ERP. Item stock, item related taxes, item unit price, unit of measure, description will be imported to its an equivalent field of ERP.	Product → Inventory Product	1	create / update
New Vendor Import	Commercient sync’s your CRM Accounts and creates Receivable Customer (AR Customer) list in the ERP. The AR Customer’s ship to and a bill to addresses are imported and mapped to the ERP fields.	Account → Vendor	1	create / update
Service Product Import	Salesforce Product to QuickBooks Service Product	Product → Service Product	1	create / update

Across the 45 default templates: 31 carry IsInsert, 35 carry IsUpdate, 2 carry IsDelete. A flag decides which operation the process is allowed to perform, not which one it performs on a given record. 2 catalogue descriptions were not printed because they are placeholders or carry text that is not ours to publish.

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_5_22, TxDownloaderPro_5_25, TxDownloaderPro_5_15, TxDownloaderPro_5_28, TxDownloaderPro_5_27, TxDownloader_5_11, TxDownloaderPro_5_16, TxDownloader_5_1, TxDownloaderPro_5_17, TxDownloaderPro_5_19, TxDownloaderPro_5_20, TxDownloader_5_8, TxDownloader_5_6, TxDownloader_5_4, TxDownloader_5_5, TxDownloader_5_7, TxDownloader_5_3, TxDownloader_5_2, TxDownloader_5_9, TxDownloader_5_12.

10 of these template rows carry a licence-group id, so what a given tenant is offered in the picker is narrower than what the catalogue holds.

3. What the query retrieves

Query does not have one shape across the product (parent §9). For this pair, 45 carry a SELECT statement in the CRM’s own query language. No query text is reproduced here; what follows is what those queries read and filter on.

• Objects read: OpportunityLineItems, OrderItems, QuoteLineItems, Account, Lead, Product2, Order, CommercientSF11__Customer__c, product2, CommercientSF11__SalesOrderLines__r.
• Child collections pulled in the same query: OpportunityLineItems, OrderItems, QuoteLineItems, CommercientSF11__SalesOrderLines__r. A header retrieved without its lines is a query that does not name the child collection.
• Marker and key columns the queries name: CommercientSF__Commercient_ArCustomerCode__c, Commercient_ExternalKey__c, Commercient_EditSequence__c, CommercientSF11__Account__r, CommercientSF11__AccountNumber__c, CommercientSF11__AltContact__c, CommercientSF11__AltPhone__c, CommercientSF11__Balance__c, CommercientSF11__BillAddressAddr1__c, CommercientSF11__BillAddressAddr2__c, CommercientSF11__BillAddressAddr3__c, CommercientSF11__BillAddressAddr4__c, CommercientSF11__BillAddressAddr5__c, CommercientSF11__BillAddressBlockAddr1__c, CommercientSF11__BillAddressBlockAddr2__c, CommercientSF11__BillAddressBlockAddr3__c, CommercientSF11__BillAddressBlockAddr4__c, CommercientSF11__BillAddressBlockAddr5__c, CommercientSF11__BillAddressCity__c, CommercientSF11__BillAddressCountry__c, and 148 more. These are the columns a user’s flag lands in and the columns the run writes an outcome back to; which ones are in the WHERE is what decides whether a record is in scope at all.
• Operators present: !=, an empty-string test, =. The parent’s §12 is the authority on the vocabulary; the point here is only which of it these templates use.
• Where the filtering happens: in the query, on the CRM side, before anything reaches the source system. Narrowing a template means editing its query — not its mapping.

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 45 default templates, 43 carry a DefaultProcessStructure and 2 carry none. A parseable document carries about 14 members.

• Template path roots used: Order, Quote, Account, Opportunity, OrderItems, QuoteLineItems, OpportunityLineItems, Product2, Lead. 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.Quantity, Line.Rate, Line.Desc, Line.Amount, Line.ItemRef, Line.ItemListID, Line.UnitOfMeasure, Line.mainXml, Line.ItemRefFullName. 4 templates 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 45 default templates, 7 carry a parseable DefaultResultStructure, 36 carry none, and 2 do not parse and are counted but not described. 1 parse but are not in the four-part shape at all — a flat field document where the parts should be.

Part	Filled by	What it addresses	Members present
Part1	6 templates	the record the run is already working with	a source-path-to-CRM-field map
Part2	0 templates (6 explicitly null)	the child/line records under it	—
Part3	0 templates (6 explicitly null)	a new record, matched on an external id field	—
Part4	0 templates (6 explicitly null)	a different record, addressed by an id field	—

• CRM fields Part1 writes to: Commercient_ExternalKey__c, CommercientSF__Commercient_ArCustomerCode__c. These are the fields on the flagged record that carry the source system’s key or outcome once the write has happened — the names only; what lands in them is the response, per record.
• Response fields it reads them from: ListID, NewCustomerCode. The map is written source-path first, CRM-field second (parent §11); the wrong way round resolves to the same silent empty string as a mistyped path.

6. Community templates

The catalogue carries community templates for this pair as well as the default set above: templates written on a tenant rather than shipped. Their content is not read and not described here — no query, no mapping document, no field. What this section states is how many there are, which objects they start from, what they are called where the name is a product artefact name, and which field-process versions they belong to.

• How many: 74 community templates, across 14 field-process versions.
• Operations: 47 carry IsInsert, 15 carry IsUpdate, 0 carry IsDelete. A flag decides which operation the template is allowed to perform, as it does for a default template.

Source → destination	Templates
Customer → —	30
Sales Invoice → —	11
Sales Order → —	9
Job → —	6
Inventory Product → —	5
Service Product → —	4
Bill → —	2
Credit Memo → —	1
Deposit → —	1
Invoice → —	1
Payment → —	1
Purchase Order → —	1
SalesReceipt → —	1
a custom object → —	1

None of these rows carries a destination object name in the catalogue, so the destination side of every shape above is empty.

• Template names the catalogue carries: Create New Customer (8), Update Customer (6), Create New Invoice (5), Create Customer (4), Customer Import (4), Create New Account (3), Create New Sales Order (3), Create New Product (2), Create New Service Product (2), Create Customer Job (1), Create Customer Job Project (1), Create Item and Sales Order (1), Create New Account from Contact (1), Create New Customer with Contact (1), Create New Deposit (1), Create New Inventory Product (1), Create New Purchase Order (1), Create New Sales Invoice (1), Create New Sales Receipt (1), Create Order and Item (1), Create Sales Order (1), Inventory Product Import (1), New Account (1), New Accounts (1), and 10 more.
• Names not reproduced: 12 of these templates carry a name that is not a product artefact name, and it is not printed here.
• Field-process versions they belong to: TxDownloaderPro_5_22, TxDownloaderPro_5_25, TxDownloaderPro_5_26, TxDownloaderPro_5_27, TxDownloader_5_11, TxDownloader_5_1, TxDownloader_5_8, TxDownloader_5_6, TxDownloader_5_4, TxDownloader_5_7, TxDownloader_5_3, TxDownloader_5_2, TxDownloader_5_9, TxDownloader_5_12.

Importing one of these writes the same TxDownloaderPro row that importing a default template writes (parent §9); what differs is where the template came from, not how it is stored. What any one of them contains is read from the imported row itself, with the tools below.

7. 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>

# run the SAVED query against the live CRM and render one record as the engine’s XML
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 query’s own condition and not the mapping; 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.

8. 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-salesforce — the Salesforce 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.