Attribute based pricing

[dwlhs]

Hi,

We don't have the concept of price groups and discount groups for customers and products in Dynamicweb as we do in BC and F&O. We work around this by organizing customers in user groups and products in product groups at the integration level. Functionally, it can work, but there are a few downsides. One is that we have an extra hierarchy in the systems, and considering product groups, these are great for orchestrating inheritance and in PIM and navigation in the frontend and wasn't really meant for managing discounts.

But the major downside is, when we consider moving products or users to a different group at the integration level. Both customer and products can be in different groups, and how do we know, which group relationship to remove, when, let's say the product is moved from "cheap" to "cheaper" discount groups a the integration level?

But, if we add an option to select a parameter in prices for custom fields for both products and customers, we could quite easily map this information to the prices in DW. So, add fields for

Product Discount Group
Customer (i.e., User) Discount Group
Customer Price Group

This would be much easier to maintain, when the relationship changes in the ERP system, and we could make do without the additional structuring in PIM and Users.

"Couldn't we make some fixed fields for this"? Sure, but there will be situations, where these would not be sufficient, or the values would need to be different in different contexts, so being able to point the out (like order field value discounts) would add some flexibility in these situations.

Thanks :)

Br.
Lars

[nicped]

We have had this before. If I decompose it into an actual feature that can also be setup in DW:

Introduce the same three pricing identity fields that ERP uses, and let the price engine filter on them.

We add three concepts:

• Customer Price Group (on the user/customer)
• Customer Discount Group (on the user/customer)
• Item/Product Discount Group (on the product)

Each user gets one price group and one discount group. Each product gets one item discount group. They’re just fields—simple, explicit, and easy to overwrite in integration.

Then we extend Prices / Price Matrix filtering so a price row can optionally target one or more of these group codes. So in addition to the existing filters (shop, currency, customer/user, product, variants, dates, etc.), a price row can say:

• “This applies to Customer Price Group = WHOLESALE”
• “and/or Customer Discount Group = DEALER”
• “and/or Item Discount Group = CHEAP”

That gives you BC-like behavior.

Finally, we expose this in the UI:

• selectors on the User and Product screens to set the group values
• extra fields/filters in the Price Matrix to define which group(s) a price row targets

With that in place, the integration should become straightforward.

Would that be viable?

[dwlhs]

Hi Nicolai,

Thanks for the quick respons:)

Yes, would indeed be viable for the vast majority of solutions. There are maybe two points, to consider.

1. We have scenarios, where the same product is available in multiple legal entities inside the same erp, and even where many companies share the same pool products. In these scenarios, the PIM enriched products are published different shops, but the different shop owners could have different discount settings for different products. This is where the custom field setting could come in handy, so we could have different settings on the products on different channels. But that's such a low number, and you know who they are :)

2. In DW the price line must contain a product, but both in BC and FO the price/discount line can contain a product discount group to indicate that e.g. a customer or customers with the right setting receive a discount on a selection of products. It is possible to maintain this in Discounts. Integrating this is quite challenging, though, as we need to create groups and relationships (from the original topic), and or concatenate this in DiscountProductsAndGroups in EcomDiscounts. Add to this, the amount groups and discounts we need to manage. In a current project we +500 product discount groups alone, which will become a separate discount. No big deal, when we just want to reflect, what is in ERP, but when we then start using DW discounts for vouchers and such, it starts becoming challenging keeping the overview of, which discounts are ERP and which are DW discounts.

Enjoy the weekend :)

Br.
Lars