Hi Rick,
We only keep about a week's worth of inventory (50 turns a years), and might sell 50 different distinct item numbers a day to 50 different customers. So we're basically purchasing each day what we're selling each day (toner, paper). Each product item num will have a price record for multiple clients (some item nums we might have 100 clients buying, and some item nums might have 2 or 3). If a specific item has 50 customers buying it, there will be 50 price records (the price record is identified by a combo of the client id and the product item num) and each price record might be a different price (based upon customer factors like size, qty purchased, timeliness of payment, etc). Example: an item costs us $60, and prices for that item might range from $68 to $100. If we're only selling 3 or 4 of that item a week, I'm only going to stock 4 or 5 of them a week. So we're quite sensitive to cost changes on that item. If in the course of a year my cost goes up incrementally from $60 to $73, then the quicker I can adjust our price records for that item, the better I can maintain/increase my profit on that item num. And that's just one item - we face that scenario dozens of times a day.
So before Sesame (we were using Q&A) when we placed the PO to replenish a few days' quantity of that item, and the cost changed from $60 to $63, then we had to manually go into the Q&A price records and figure new pricing for those 50 different customers - based upon each customer's unique margin for that product. Multiple that problem by a couple dozen each day. Very tedious. You may perhaps guess that in many many instances those price records were not being changed/updated to reflect the new cost reality, and you'd be correct. So a year and a half later, my cost might be $69 instead of $60, but many of those price records have not be changed upwards, and thus the ever increasing downward pressure on margins.
But with Sesame, that cost increase on a PO triggers automatically an immediate update of all price records for that item num, calculated upon each price record's unique margin. No human has to 'keep track of cost changes and then edit price records', so I get the instant price changes I need, and it doesn't cost me expensive human labor that I can't afford. In the 2.5 years since I built this application suite (on Sesame - yea!) of Sales Order, Invoicing, Purchase Order, Quote, PricingRecords, Client, Vendor, Delivery/Shipping Logistics, Sales Analysis, we have increased our margins 7.5 full points, which is huge, and is the reason in this lousy economy why we haven't had to lay anyone off. And Sesame has reduced our data entry keystrokes by 60% at the same time.
So, to answer your question, the costs rarely change greatly, but they change frequently, and there are so many products that the collective impact of not adapting a sale to that individual instance of a, say, 4% increase in cost is, over time, a big deal. As to the customer mindset, if they order a particular item 8 times in a year, the price might be different by a little bit 5 of those times. But if they're ordering 25 different products from us in that year, some percentage of those items will have a decreasing cost (and therefore a decreasing price), so it's a constant flux of prices going up and down (like the stock market). the changes upward are usually small, and Sesame always points out to the customer when a price has gone down from 3 months ago, so the customers are happy to know that Sesame is reflecting the cost trends of the industry both up and down.
In my experience, traditional accounting systems work fine in models where you buy a 6 week supply of something, sell it off, then buy another 6 week supply of something, then sell it off, and you know for those 6 weeks what your cost is on that item. But we're only carrying a few days (or on some items, one sale's worth of inventory; or on some items we're not carrying ANY inventory, but only ordering the product when we've got a sale for it) and we generate invoices automatically every day from the previous day's sales orders (yea!), which increases our cash flow by about 3 days worth (yea!), and accounting systems that must wait for vendor invoices, and completed delivery tickets to be turned into invoices, for the accounting system to calculate/communicate profitability are too slow afoot.
Couldn't think of how to make that a shorter explanation - apologies! But the short of it is - Sesame has allowed us to dig holes using a backhoe instead of a shovel, so we can dig, with no increase in personnel, more holes per day that are bigger and deeper.
I'm just interested in programming technique that would allow the 'can't execute this event at this time' to be accomplished, later, programmatically instead of manually (the phrase that is in my head - though not exactly on point - is 'rollback transaction', or 'third normal').
|