3

This is less a programming question and more a process/policy question.

When dealing with product feeds from manufactures/resellers, it's very common to run into a product variant that looks something like this

Size        Color       price
--------------------------------------------------
625 ml      Red         47.70
1.25 litre  Red         69.33
4 litre     Blue        165.98
4 litre     Green       170.78
5 litre     Red         173.56
10 litre    Blue        454.72
10 litre    Green       454.72
16 litre    Yellow      456.96
200 litre   Yellow      4648.00

We have a product with two attributes (Size, Color), and it's unclear how each attribute effects the price. In the above example you might assume its size that would effect the price (as more product would cost more). However, comparing two products with the same size

4 litre     Blue        165.98
4 litre     Green       170.78

there's still a slight price different due to color.

When setting these products up as configurable products, how do you split the option price between the two attributes for the Super Product Attributes Configuration? It doesn't seem like it's possible algorithmically without more information, but I also see feeds like this all over the place so I assume people are finding a way to deal with it.

3 Answers 3

3

My first thought is to just assign those prices directly to the component "Simple" products and install "Simple Configurable Products" extension. Of course this means you would have to treat all configurable products this way, you can no longer use the old scheme for pricing.

With a bit of thought you can show that it is not possible to correctly price these products with the old scheme. Look at these 4 in particular:

4 litre     Blue        165.98
4 litre     Green       170.78
...
10 litre    Blue        454.72
10 litre    Green       454.72

The difference between blue and green is both 4.80 and 0.00 which is not an option in an unaltered Magento.

7
  • Any experience with that extension — it looks like the developer abandoned it around Magento 1.5 Commented Oct 7, 2013 at 16:30
  • Honestly that was about the last time I used it too... Commented Oct 7, 2013 at 16:36
  • 1
    I've run into issues with that extension on Mage 1.7 with promotions and tax calculations, cant remember exacts but i'd advise against using it Commented Oct 7, 2013 at 16:37
  • 1
    We're still using it on 1.7 using the github.com/lejoko/magento-configurable-simple branch on github - unfortunately so many customers have individual prices per variant, we can't live without it.
    – xyphoid
    Commented Oct 7, 2013 at 20:45
  • 1
    @alanstorm we use a forked version of SCP with good success, YMMV. It is fairly active when you look at the fork's network graph: github.com/aligent/magento-configurable-simple/network - seems like j0s3f has taken our fork and added to HEAD considerably. Ping me if you want more info. Commented Oct 15, 2013 at 11:40
1

To my experience - and in the long run - it would be good to make that manufacturer to fix their stuff one way or another. By "dealing with this" on Magento's side is just moving the problem around from one place to another. It's not finding and fixing the root cause. Finding the root cause of problems was something that I learnt to be important while I was in telco business. Just ask your customer to put a little more pressure on the manufacturer, write some good specs, invent, discuss and promote standards.

About specific problem - explain it to your customer and ask them to advise you if you should go for highest price or the lowest. At Eepohs we built an addition to our EepohsImporter that was called "Margin Matrix". The logic was that often stores import manufacturer prices, not retail prices and there could be some logic to add margins to cost level prices. I guess it can be reused here, too. Build a matrix where there are blanks for price ranges and blanks for prices or margins or whatever "fixes". Then let your customer to fill it in so you'd get logic like that: IF price >=x and =q and

I guess most important is to check with the customer and not to make pricing decisions for them:)

3
  • 2
    +1, because I agree completely. The main problem is this may not be an "error" with the manufacturer. Not every product make uses the same "cost per attribute" model as Magento. Commented Oct 7, 2013 at 19:15
  • 1
    I think Magento's "cost per attribute" approach is flawed.
    – Vinai
    Commented Oct 8, 2013 at 16:34
  • Btw I've played around with an idea of a setup where I'd use MULE Enterprise Service Bus as Integration Engine for aggregating and transforming data for x number of sources. It has Magento connector too. Has anyone tried that kind of setup?:) Any experiences, comments?
    – Sven
    Commented Oct 9, 2013 at 7:51
1

Yes, supplier onboarding is a pain. The data feeds are usually low quality so you need some pretty complex solutions to automate it hence why companies like Heiler charge $10s-$100s thousands for their solution. We use a supplier onboarding solution that does this using non-code mapping with direct loading to Magento from supplier files, but it was developed by high-end consultants who knew what they were doing.

Manufacturers are unlikely to change their feeds, and you would be suprised how they generate them anyway. There is a lot of Excel used, we know of multi-nationals who ran on Excel taking data from high-end ERPs.

For the above you set the combination price and add your markup, that is the simple way rather than trying to reverse engineer their pricing structure.

1
  • 1
    This doesn't answer the question at all
    – choco-loo
    Commented Oct 11, 2014 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.