dlake-crmpro-magento

CRMPro → Magento: what the shipped 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.

The source ERP has its own page under this skill. erps/<erp>.md is a child file of this skill and describes what the shipped templates for that ERP → Magento pair set up. §6 lists every one of them and how to pick the right row; read this page first, then that one.

dlake-crmpro is the parent skill and the authority for everything general: the crmpro_* tools, CRM_Configuration and CRM_FieldList, TimeStampRepository, the three kinds of source view, the NULL-cursor rule and the silent zero-record run. Read it first; this page does not repeat it. What follows is only what the shipped Standard templates for Magento themselves set, and only the part of it that is the same across 4 source ERPs. Everything that belongs to one source — which groups ship, which clone tables the views read, which view names and prefixes are paired — is on that ERP’s own page under erps/. This page grows as the catalogue does.

The catalogue spells this destination MEGENTO, so that is the value to pass as a tool argument — dlake admin crmpro_templates --crmName MEGENTO — but the product is Magento, which is what this skill calls it.

1. The objects these templates push to

These appear in some sources’ sets and not others:

CRM_Object_API_Name	Sources whose templates push it
customers	3 of 4
products	3 of 4

2. The repository key these templates build

Every one of these template sets builds its TimeStampRepository key as <TimeStamp_Prefix>:<key>. The literal in the view and the TimeStamp_Prefix on the configuration row have to be the same string, case included; a key built with the other separator matches nothing the engine wrote.

The views these templates create are named with the vw_ prefix form. The TimeStamp_Prefix is not reliably the view name — the ERP pages carry the pairings — and it is what every downstream view joins on, so it is effectively public API between processes.

3. What the template groups deliver

The rest are shipped by some sources only:

Template group	Sources that ship it
MAGENTO_Customer	2 of 4
MAGENTO_GetProduct	2 of 4
MAGENTO_customerupdate	1 of 4
MAGENTO_CustomerUpdateKey	1 of 4
MAGENTO_Product	1 of 4

Every one of these templates inserts Is_Active as 0, so an imported process is inactive until an operator activates it, and the Registration API’s import does not populate CRM_FieldList — an object with no CRM_FieldList rows pushes nothing and records no error. Read MappingJson off the template with dlake admin crmpro_templates, then check crmpro_field_mapping on the created process before activating it.

4. When a run pushes no records

The signature failure is the one dlake-crmpro §7d describes: every object logs a start and an end in about 0.00 seconds, the total is zero, and no error is written anywhere. For this destination, check in this order.

1. Does the view return rows? Zero rows means the answer is in the view.
2. Does TimeStamp_Prefix equal the literal the view builds its key from, case included — and not, by reflex, the view’s own name?
3. Is the separator the one §2 names, in both the view literal and the prefix?
4. Does CRM_FieldList have rows for that Object_Name, spelled as the API name?
5. Any NULL nullable text column on the configuration row? The templates set '' throughout, and a NULL throws inside the engine, which catches it — so the object is skipped with no recorded error.
6. Is the parent’s prefix the one that actually holds the ids? A view that reads another process’s prefix returns nothing until that process has run, which is what makes Sync_Order a dependency order rather than a preference.
7. Do the clone tables the view reads carry the prefix this ERP’s templates expect? That is on the ERP’s own page, and it differs between sources.

5. Verifying

# per-prefix counts; every synced record carries its destination id
dlake tool query --profile <tenant> --sql "SELECT LEFT([Key], CHARINDEX(':',[Key])-1) AS prefix, COUNT(*) n, COUNT(NULLIF(SFDCID,'')) withId FROM dbo.TimeStampRepository WHERE CHARINDEX(':',[Key])>0 GROUP BY LEFT([Key], CHARINDEX(':',[Key])-1)"

withId = n for every prefix is the success condition dlake-crmpro defines. The split is on the first colon, which is the prefix boundary whether the key separator is : or ::.

6. The source ERP’s own page

One row per source ERP the catalogue carries Magento templates for. Each page is a child file of this skill, addressed as dlake-crmpro-magento/erps/<erp> — dlake skills show dlake-crmpro-magento/erps/<erp> prints one, and dlake skills install writes them beside this file.

ERP	Page	What its templates deliver
Epicor 10	erps/epicor-10.md	1 Standard template in 1 group, pushing customers; : repository keys; 19 community templates
Microsoft Dynamics GP 2017	erps/microsoft-dynamics-gp-2017.md	3 Standard templates in 3 groups, pushing customers, products; : repository keys; 4 community templates
Sage 100 2017	erps/sage-100-2017.md	no Standard templates; 8 community templates
Sage 100 US (SAGE100US)	erps/sage-100-us-sage100us.md	no Standard templates; 3 community templates
Sage 300	erps/sage-300.md	no Standard templates; 2 community templates
Sage 50 UK	erps/sage-50-uk.md	2 Standard templates in 2 groups, pushing products, customers; : repository keys; 4 community templates
SYSPRO 7 and above	erps/syspro-7-and-above.md	1 Standard template in 1 group, pushing products; : repository keys; 8 community templates

Work out which row applies before reading one. The source is the ERP the tenant was registered with: dlake register erps lists the catalogue’s names and codes, and dlake admin crmpro_templates shows what that tenant can actually import. Match that ERP to a row above, then read its page alongside this one — this page for the conventions that hold across every source, that page for what this source’s own templates set. If no row matches the tenant’s ERP, this skill alone applies: the catalogue ships no Standard templates for that pair, so there is nothing ERP-specific to read and nothing to import.

7. Where this sits

dlake-crmpro is the general operating surface — the crmpro_* tools, the setup and transaction tables, field mapping, and the source-view contract that applies to every destination. This skill adds what the shipped Magento templates set up, and its erps/ pages add what each source ERP’s own templates set. dlake-crmpro-hubspot, dlake-crmpro-salesforce and dlake-crmpro-shopify are the hand-written destination skills for their CRMs, and the conventions genuinely differ between destinations. For the extract leg that fills the clone tables, see dlake-normalsync; for the on-premises agent that runs it, dlake-syncagent; for the writeback leg, dlake-txdownloaderpro; for standing an integration up, dlake-integration-setup.