Source ERP · 2 of 7
CRMPro → Magento — Microsoft Dynamics GP 2017: what the shipped templates set up
Read it in the terminal with "dlake skills show dlake-crmpro-magento/erps/microsoft-dynamics-gp-2017". It extends the dlake-crmpro-magento skill, which holds what is true whatever the source ERP.
CRMPro → Magento — Microsoft Dynamics GP 2017: what the shipped templates set up
Keep this skill current.
dlakeships updates often and this text is embedded in the CLI you have installed. Before relying on it, comparedlake --versionwithnpm view @commercient/dlake version; if they differ, runnpm install -g @commercient/dlake@latestand thendlake skills install, which overwrites the installed skill files with the current text.
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.
dlake-crmpro-magento is the destination skill this page is a child of, and the authority for the
Magento conventions that hold across every ERP: read it first, then come back here for what this
source’s own templates set. This page is
dlake-crmpro-magento/erps/microsoft-dynamics-gp-2017.md, and that skill’s ERP table is what
points at it. 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 page calls it. What follows is only what the shipped Microsoft Dynamics GP 2017
→ Magento templates themselves set, read from their Insert_Query, CreateViewQuery and
MappingJson. This page grows as the catalogue does.
1. What the templates deliver
| Group | Business outcome | Objects | Source tables and views |
|---|---|---|---|
| MAGENTO_Customer | ERP GETCOUNTRYCODE, RM00101, SY01200 data becomes customers in Magento. New records are created, existing ones updated, and records removed in the ERP are deleted. | customers | SF_ERP_Salesforce_Clone_RM00101, SF_ERP_Salesforce_Clone_SY01200, SF_ERP_Salesforce_Clone_RM00102, vw_MAGENTO_Matched_Customers, GetCountryCode, SF_country_region |
| MAGENTO_customerupdate | ERP GETCOUNTRYCODE, RM00101, SF_COUNTRY_REGION data becomes customers in Magento. New records are created, existing ones updated, and records removed in the ERP are deleted. | customers | SF_ERP_Salesforce_Clone_RM00101, SF_ERP_Salesforce_Clone_RM00102, vw_MAGENTO_Matched_Customers, Countries, GetCountryCode, SF_country_region |
| MAGENTO_Product | ERP IV00101, IV00102, IV00105 data becomes products in Magento. New records are created, existing ones updated, and records removed in the ERP are deleted. | products | SF_ERP_Salesforce_Clone_IV00101, SF_ERP_Salesforce_Clone_IV00102, SF_ERP_Salesforce_Clone_IV00108, SF_ERP_Salesforce_Clone_IV00105 |
2. The process rows the templates create
Each template’s Insert_Query writes one CRM_Configuration row. These are the values it sets; a
column the inserts never set is not listed.
| Display name | CRM_Object_API_Name | CRM_PK_API_Name | Sync_Order | TimeStamp_Prefix | SQL_Query target | field prefix / postfix | Sync_Operation_Type |
|---|---|---|---|---|---|---|---|
| MAGENTO_Customer | customers | ExternalKey | 1 | vw_Customer | vw_MAGENTO_MSDYNAMICGP2017_Customer_Pro | '' / '' | 1 |
| MAGENTO_customerupdate | customers | ExternalKey | 2 | vw_Customer | vw_MAGENTO_MSDYNAMICGP2017_CustomerUpdate_Pro | '' / '' | 1 |
| MAGENTO_Product | products | ExternalKey | 3 | vw_Product | vw_MAGENTO_MSDYNAMICGP2017_Product_Pro | '' / '' | 1 |
Every one of these inserts Is_Active as 0, so an imported process is inactive until an
operator activates it. Across the set they insert Is_Create_Entity 0, Is_Create_Fields 0,
Is_Active_Get_Records 0, Is_Active_Delete_Records 0, IsAccountMatching False,
Sync_Batch_Size 200. Text columns a template does not use are inserted as '' rather than
left NULL.
3. The views
Each template creates its view with CreateViewQuery, in the gateway dbo schema. “Change
detection” names which of the three kinds dlake-crmpro defines the view’s own WHERE makes it;
where a view’s shape is not one of those three the column is left empty and the view’s own WHERE
is the authority.
| View | Change detection | Repository key | Reads other prefixes | Identity column | Source tables |
|---|---|---|---|---|---|
vw_MAGENTO_MSDYNAMICGP2017_Customer_Pro | insert-only | vw_Customer: | vw_Get_Customer: | ExternalKey | SF_ERP_Salesforce_Clone_RM00101, SF_ERP_Salesforce_Clone_SY01200, SF_ERP_Salesforce_Clone_RM00102, vw_MAGENTO_Matched_Customers, GetCountryCode |
vw_MAGENTO_MSDYNAMICGP2017_CustomerUpdate_Pro | insert-only | vw_Customer: | vw_Get_Customer: | ExternalKey | SF_ERP_Salesforce_Clone_RM00101, SF_ERP_Salesforce_Clone_RM00102, vw_MAGENTO_Matched_Customers, Countries, GetCountryCode |
vw_MAGENTO_MSDYNAMICGP2017_Product_Pro | insert + update | vw_Product: | vw_GetProduct: | — | SF_ERP_Salesforce_Clone_IV00101, SF_ERP_Salesforce_Clone_IV00102, SF_ERP_Salesforce_Clone_IV00108, SF_ERP_Salesforce_Clone_IV00105 |
The repository key these templates build is <TimeStamp_Prefix>:<key>. The literal in the view
and the TimeStamp_Prefix on the configuration row have to be the same string, case included.
4. Order of work
The templates set Sync_Order to 1, 2, 3. A run processes active rows in ascending
Sync_Order, which is the order the templates put them in:
1— MAGENTO_Customer2— MAGENTO_customerupdate3— MAGENTO_Product
These views read another process’s repository prefix, which is what makes the order a dependency order: the row appears in the view only once the process that writes that prefix has run, so a parent flows on one run and its children on the next.
vw_MAGENTO_MSDYNAMICGP2017_Customer_Proreadsvw_Get_Customer:; no template in this set writesvw_Get_Customer:vw_MAGENTO_MSDYNAMICGP2017_CustomerUpdate_Proreadsvw_Get_Customer:; no template in this set writesvw_Get_Customer:vw_MAGENTO_MSDYNAMICGP2017_Product_Proreadsvw_GetProduct:; no template in this set writesvw_GetProduct:
5. Field mapping
CRM_FieldList carries one row per pushed column, with Object_Name equal to the
CRM_Object_API_Name value — as dlake-crmpro puts it, an object with no CRM_FieldList rows
pushes nothing and records no error. Each template carries its intended mapping in MappingJson.
Read that with dlake admin crmpro_templates, then check crmpro_field_mapping on the created
process before activating it.
| Template | Object | Mapped fields | First ERP → Magento pairs |
|---|---|---|---|
| MAGENTO_Customer | customers | 35 | email → email, CNTCPRSN → CNTCPRSN, FirstName → FirstName, LastName → LastName, CUSTOMATTR_commercient_id → CUSTOMATTR_commercient_id |
| MAGENTO_customerupdate | customers | 10 | email → email, FirstName → FirstName, LastName → LastName, CUSTOMATTR_commercient_id → CUSTOMATTR_commercient_id, CUSTOMATTR_customer_number → CUSTOMATTR_customer_number |
| MAGENTO_Product | products | 46 | sku → sku, WEIGHT → WEIGHT, CUSTOMATTR_commercient_id → CUSTOMATTR_commercient_id, add_urlkey → add_urlkey, CUSTOMATTR_description → CUSTOMATTR_description |
6. Community templates
The catalogue carries 4 community templates for this pair. A community template is authored in a tenant rather than shipped with the product, and it imports the same way as any other. Its own names, notes, field mapping and SQL are tenant content, so what this section states is what the set amounts to: how many templates there are, what they default to doing, which destination objects they write and which groups they fall in. They are not part of the shipped set described above.
- Templates: 4
- Default operations: insert on 4, update on 4, delete on 4
- Marked circular-sync: 0
- Licence groups they span: 1
- Destination objects:
customers,products,updateprice - Object display names: MAGENTO_Customer, MAGENTO_customerupdate, MAGENTO_Product, MAGENTO_updateprice
A community template is imported the way a shipped one is, and the same rules apply to what it
creates: read the process it creates with crmpro_get_process, its mapping with
crmpro_field_mapping, and the view it selects from, before activating it.
7. 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 ::.
The prefixes these templates set:
vw_Customervw_Product
8. 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 page
adds what the shipped Microsoft Dynamics GP 2017 → Magento templates set up.
dlake-crmpro-magento is the destination skill this page sits under: its own text is the
authority for the Magento conventions that hold across every ERP, and its ERP table lists this
page alongside every sibling ERP page for this destination. 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.