rob,
in bvc2004, we built purchasing. each vendor could have multiple terms. the system calculated an items accurate cost. purchase orders were easily generated and submitted to vendors.
calculating actual cost can be a daunting task.
typical cost calculated from mfg program might follow as such:
Dealer Price Less
$3 SPA
10% Buy-In DFI
5% Masterpack Discount
8% CategorySpecificDiscount
4% Volume Discount
3% Scrap Allowance Discount
5% DFI
5% NET 60
$2000 Prepaid Freight Level
3% Quarterly VIR
5% Bi-Annual MAP/MDF Rebate
This is cascaded - so to calculate
if dealerprice = $200.00
cost = (((200-3)*.9*.95*.92*.96*.97*.95*.95))-((((200-3)*.9*.95*.92*.96*.97)*.03) + (((200-3)*.9*.95*.92*.96*.97)*.05))
with this data, we can determine competitor pricing models. this provides precise data to use to negotiate our program with manufacturers. the biggest benefit was stopping any and all vendor errors. we found vendors would often enter incorrect quantites and pricing. we also found that even large suppliers were error prone. the multi-million dollar oracle systems still resulted in regionals and nationals using a calculator line item by line item to punch purchase orders into their systems.
having additional data will allow for more granular control of what pricing is displayed and when. for example:
you have an item in bv cart priced at MAP - say $299.99
you:
a) put the item on sale
b) put a category containing the item on sale
what happens? is there a trigger for the override text to display? are you breaking MAP agreements?
in a large catalog, this can become a nightmare to manage and maintain.
I am working on expanding this into a more flexible purchasing system that better supports multiple vendors and costing at the product level.
Scott Mech
[email protected]