Custom SKU Pricing per customer without discount levels

Just to add.... my thoughts at the minute are to look at using product variants. The product won't actually vary, but if I create product variants for each user, and automatically add the correct variant to the cart for the logged in user, this would allow proper skus to exist, but still maintain custom pricing?

If the external system has a complex discount algorithm I would use the solution you are using. If it doesn't have anything too complicated I would look to move it to Kentico. You say you have ~24,000 products and these should be managed with SKU's. They should be easy enough to create as products with either product options and / or product variants.

The issue is when these products are added to the cart how do we generate the customers price, and without having some details on how this is currently done it would be near impossible to give you ideas for an alternate solution.

Personally I think you probably have the best way, although I will take a guess and say it is because your external system holds quotations and hence a customer account is created in that system during some consultation phase. If this is the case, then you may look at how this system is being used and possibly replicate that functionality as a module in Kentio elliminating the need for the external system. It all depends on functionality in the external system. The external system is somehow capturing / calculating the price and hence it should be storing the products as SKU's in some form.

Given the last statement that the external system is calculating the price, then we could standardize the data in Kentico a bit. You would create the SKU's based on the ID's being used to reference the products in the external system. These would be stored with standard pricing. You then create an extra table in Kentico which holds CustomerID, SKUID and Price. As the customer steps through your existing order process you update this table with that values retrieved from the external system.

Hi Suneel,

Thanks for your reply.

We do in part duplicate it to get the correct price in the first place obviously, but I don't believe there is any kind of 'standard' to how the pricing is produced. Therefore I couldn't replicate it fully, and this would mean a pricing update would have to be done twice. I think pulling from the external system is the only option.

I've been messing with product variants, and it seems like I could use them to create variants on the fly rather than new SKUs. This would have the benefit of allowing SKUs to existing with the kentico tree, but no other benefits. Is there a particular reason why variants (with customer id for example) wouldn't work for us?

Actually half way through typing this, I've seen something else.... If I continue to auto-create skus on the fly, if I set a parent SKU ID, does this prevent them appearing in the products app?

In summary, the main reason for wanting to change is because I want to use the Kentico tree, and products rather than our old 'productdetail' query string powered page (for SEO reasons, and other stuff). However the 'real' skus would merge with our created 'fakse' sku's which wouldn't be good for the end admin users!

Thanks again,

Mark

I believe you should actually use a custom pricing table.

Your initial post says you have ~24,000 products that have a standard price. Therefore, these should form your SKU's. I would extend the SKU to include an extra field that links the SKU to your external system. This way you should be able to pull products from your external system and have some way of reconciling them. This would also represent all products visible in the Tree. Of course, you can also use options and variants on these.

You would then have an additional table which links your Kentico CustomerId to the SKUId and the Price. This can also be populated by your external system since you would extend the Customer table with the External Account ID.

This scenario would work well for a clean set-up. However, since you have an existing set-up it might prove to be a trickier. One possible trick with a bit of manual intervention is to change the Base ID for the SKUID in the SQL database so that autonumbering starts from the higher ID. You can then use the SKUID > newbaseID in your queries to limit the data returned.

Withut knowing what other features / functions the external system provides it would be difficult to give you any further hints. But for what's it's worth, you should be able to envisage a single central product catalog that both system use as a base, this would then be the info you want to represent in your tree. Any further info would be customizations on top of that base and for the most part is probably just price per customer.