Magento – Minimum Advertised Price (MAP) Kludge

Special Note May 28, 2009

I’m keeping this here for historical purposes, but I will revisit. I strongly discourage using the SQL code I’ve specified here, and once I’ve got things working appropriately I will post my findings with a more appropriate Magento-friendly solution.

Introduction

Many manufacturers enforce Minimum Advertised Price (MAP) policy with their resellers, in order, I think, to level the playing field. Especially in electronics, especially when a new product comes out. Over time, the manufacturer will drop the MAP for a particular product as new products come out.

Magento, as of 1.1.6 (and 1.1.7, apparently), does not natively support this construct. After reading over the responses in the thread “How Do I Implement Minimum Advertised (MAP) Pricing?“, I came away with a few concepts that, slightly tweaked, would work for me.

In my case my store’s pricing, stocking and MAP policies are dictated by our backend distribution system.  From this backend system, I create a csv that I upload to Magento via the Profile feature.

Different MAP Policies

I have 3 kinds of MAP I deal with:

  • The first, simplest and most common policy is that I can sell at my price, but I have to show MAP. Click Add to Cart to put the item in your cart and reveal the price.
  • The second, less common, policy is that I can’t sell for less than MAP online. Effectively, then, it isn’t MAP at all. The sell price is set to MAP.  MAP is a non-issue,  Magento-side.
  • The third, least common is: I can’t even sell this thing online. That one solves itself by never entering Magento!

Changing Magento – a Little

The more I pondered, I came away thinking it wasn’t necessary for a product to “know” it was a MAP product in Magento. That would mean an extra attribute that doesn’t really buy me anything, except more maintenance. Remember, MAP lives in my backend system already.

I just want to add the item to the cart at a different price than the one displayed. Tiered Pricing already does that. If I set my Tier Price level to 1 @ $MySellPrice, it just about does exactly what I want it to do. The more I thought about it, this solution is just fine – in may case.

By default it wants to say “Buy q at $x and Save y% ,”  so I changed:

app/design/.../template/catalog/product/view/tierprices.phtml ; around line 40, I commented out the php code like this: <?php /* echo $this->__('Buy %1$s for %2$s each', $_price['price_qty'], $_price['formated_price']) */ ?>

Next, around line 45, I changed:

<?php echo $this->__('and') ?>&nbsp;<strong class="benefit"><?php echo $this->__('save')?>&nbsp;<?php echo $_price['savePercent']?>%

to

<?php echo $this->__('Add to cart for best Price') ?>

Additionally, I lopped off the errant </strong> from line 46, as it wasn’t needed any more (its opening tag was formerly on line 45).

app/design/.../template/catalog/product/price.phtml ; around line 87, I deleted these lines:

<a href="<?php echo $_product->getProductUrl(); ?>" class="minimal-price-link">
<span class="label"><?php echo $this->__('As low as:') ?></span>
<span class="price" id="product-minimal-price-<?php echo $_id ?><?php echo $this->getIdSuffix() ?>"><?php echo Mage::helper('core')->cu    rrency($_minimalPrice,true,false) ?></span>

Changing SQL – I know it’s a No No, but …

Since I had a csv, here’s how I did it. I exported from my backend system – written in a form of Business Basic. The Basic program reached out and grabbed the entity_id for my SKU, and wrote the entity_id, and sell-for price into a csv file. The format:

sku <TAB> entity_id <TAB>   display_price <TAB>  sell_price <TAB>  map_type

The SKU, display_price and map_type are irrelevant to Magento, but relevant to my sanity in trying to make sure everything matches up to the backend system.

A little php code wrapped around a SQL insert, and I’m all set. Here’s a pseudo-code to help get you started:

$fh=fopen("myCsvFile.csv";
while( !feof($fh) ) {

$buffer = fgets($fh, 8192);
$item = explode( "\t", $buffer );
$i = 0;

/* Parse out field names as described above */
$sku = $item[$i++];
$entity_id = $item[$i++];
$display_price = $item[$i++];
$sell_price = trim($item[$i++]);
$map_type = $item[$i++];

/* Construct a query. I've assumed a re-rimport of everything every time - I'm truncating the table every time before I start inserting. */

$query = sprintf( "
INSERT INTO catalog_product_entity_tier_price
( entity_id, all_groups, customer_group_id, qty, value, website_id )
VALUES ( '%s', 1, 0, 1.0000, '%s', 0 )", $entity_id, $sell_price );

/* Execute query here */

}

Even though I’m doing this in SQL, there’s no reason you can’t do it right in Magento. If you have, say, 20 MAP items, just make the changes to the template phtml files, and then set the tier pricing.

Pros and Cons

Pros

  • If you don’t need tiered pricing otherwise, this is a quick and easy solution.
  • Runs fast.

Cons

  • Breaks tier pricing for anything else at the moment. But stay tuned, we’ll be refining that over the 2-3 weeks or so to restore that ability.
  • Totally not the “right” way to do things in Magento.

Next

First, I’ll need to fix tiered pricing, because I need that for my next project. Even though I’ve left tiered pricing broken in this pass, there’s nothing about the fundamentals here that will break it going forward. That is, using Quantity Break 1 to mean “Show one Price, Sell at Another” doesn’t break Quantity Break 2 and so on.

Of course if you’re providing quantity break pricing on MAP items, things will begin to get sticky. As for me, I’m ignoring that problem. The site I need to build that will have that scenario will force customer login to see pricing.

Facebook comments: