Developer forum

Hello Matthias,

- I have updated as you recommended and it seems to work as expected regarding "AssignToNo" / "PriceAccessUserGroup".

Since the EcomProvider is a bit of a 'black-box', is there also a solution to the challenge with variants? Or do I need to write a TableScript?
Currently is "Variant_Code" mapped to "PriceProductVariantId", but "Variant_Code" contains eg '00000002' from Business Central, but products have been created with a "ProductVariantId" like ''colors_0072.intex_42.length_20".

Br. Michael Knudsen 

Hi Michael,

What do you do in your product/variant import/export, as it should be the same approach here too? :)

BR

Matthias Sort

Hello Matthias,

- each product in BC have 3 variant dimensions (color, length1, length2), so I haven't been able to use the blueprint in this matter. I assume, a TableScript will be the solution.

Br. Michael Knudsen

Hi Michael,

Yeah might be the solution for your case.

Not sure why you're not just combining all of them to the "Variant_Code" in BC as then you have a 1 to 1 mapping into Dynamicweb? maybe it's not your decision to make, but could be an easier solution/implementation to do :)

BR

Matthias Sort

Hello Matthias,

- as far as I know, a . (dot) notation must be used in the "ProductVariantId" field when you have multiple variant dimensions, correct?

When I receive data from the "ItemVariants" the field "Code" contains eg. '000000002'. There are other fields on the "ItemVariants" that contains the variant dimensions for color, length1, length2 and these fields are used to build the "ProductVariantId" eg. ''colors_0072.intex_42.length_20".

When I receive data from the "SalesPriceListLines" the field "Variant_Code" contains eg. '000000002', but since the "SalesPriceListLines" dosn't contains information about the variant dimensions, I somehow have to lookup the "colors_0072.intex_42.length_20" from the product.

Br. Michael Knudsen

Hi Michael,

Well all you need is mapping the data correct into Dynamicweb. I am not sure that you have to do it the "dot"-way (I am not strong when it comes to 3 or more fields that makes the VariantID), but is it the only way to have your products/variants unique? the Code isn't unique enough?

In the blueprints I've not made the VariantID with dots, I just combine "Item_No" & "Code", but I keep the keys from BC, "Item_No" & "Code" in the "hidden" fields I've made on the EcomProduct table "ProductExternalId" & "ProductExternalVariantId" so I can use it for export jobs. Then in the relation tables (EcomVariantsOptions & EcomVariantOptionsProductRelation) I do the same combination for the VariantId.. 

I don't know your project, but what I am trying to say is, it might not need to be that complex to do your import? :)

Hello Matthias,

- if you combine products to variants with 2 or more variant dimensions, ProductVariantId will be built using the . (dot) notations when I look in the database.

Would it be possible for you to get this confirmed by one of fellow Dynamicwebber?

Br. Michael Knudsen

Hi Michael,

Yes, when you combine products into multiple dimension variants, the variant option id's will be separated by a dot sign.

It that the situation here? That you receive products and variants from BC and combine them in PIM? Variants in BC are very similar to "simple variants" in DW, where you have one record in EcomProducts representing the item and a number of records in EcomVariantOptionsProductRelation representing the variants.

When they are combined and receive a dotted variant id, each variant will have its own record in EcomProducts also, and when importing prices and other related information, you need to keep track of the original item number and variant code from BC, as suggested by Matthias in ProductExternalId and ProductExternalVariantId. Then, you can resolve the DW ProductId and ProductVariantId by looking the record using these fields when importing prices.

You also need this information when submitting an order back to BC, so there's probably a need for tweaking that integration too :)

An alternative to use variants could be to use product families (https://doc.dynamicweb.dev/manual/dynamicweb10/products/concepts/variants-families.html). They use the same tables as variants, but the structure is a bit different, since each item will have a record in EcomVariantGroups containing the Item Number, and the variant codes will be saved in ProductVariantId in a releate record in EcomVariantOptionsProductRelation. This structure fits nicely when sending over orders to BC but of cause it doesn't contain any variant dimension information.

Feel free to post back if you have comments or questions :)

Br.
Lars

Hello Lars,

- thanks for confirming the . (dot) notation regards variant dimentionsions.

However I'm still surprised what the Ecom Provider can do and now you mention two new fields "ProductExternalId" + "ProductExternalVariantId". Is there any documentation regards the Ecom Provider available, because I can't find anything using the Dynamicweb 10 Documentation GPT?

Due to some custom BC extention one 'variant' in BC is actually a combination of color + length1 + length2, so I have to build the variants in DW myself, which isn't that big deal, but as you might can see, am I struggling with getting the corresponding VariantId from EcomProducts.  I will try the "ProductExternalId" + "ProductExternalVariantId" instead of the TableScript.

Br. Michael Knudsen

Hello Lars,

- if I use the Ecom Provider and what to map XML > EcomPrices, there isn't any "ProductExternalId" or "ProductExternalVariantId" available in the 'Destination'?

Br. Michael Knudsen

Good morning Michael,

You'll find the documentation for the Ecom provider here:

https://doc.dynamicweb.dev/manual/dynamicweb10/integration/setup/providers/ecom-provider.html

Alternatively here for DW9:

https://doc.dynamicweb.com/documentation-9/integration/integration-framework/data-integration-activities/ecom-provider

The external id fields are used in the product import to keep track of the original codes, in case the products are combined in PIM afterwards. However, when doing so, you need to resolve the ProductId and ProductVariantId from EcomProducts to attach them correctly.

Using the Ecom provider, the solution to this is table script, but an alternative - and my prefered way - could be to load the data into a staging table and create a view that joins the staging table with EcomProducts to retrieve the correct prices. I wrote blog on this a while back if you're interested:

https://doc.dynamicweb.com/community/devblog/blog/alternatives-to-applying-code-in-you-integration-flow?PID=8967

Enjoy your day :)

Br.
Lars