Now, if you’re anything like me, you recognize how important warranty is to many (if not most) companies out there. This is essentially money you have to set aside, because you need your customers to feel comfortable enough to buy your products and know it won’t break in 10 days after purchase. In that respect, warranty is more of a marketing feature than a product feature, but it is a fact of business none the less. Now, of the things that always frustrated me was that as a service person, how do I know I can trust the warranty dates on the products. Because let’s face it, customers will always claim it’s warranty, no matter what. And why do they do it? because many companies either don’t care or don’t know if it really is warranty, so they do a free repair or send a free replacement. Well, at the end of the day, it all comes off the bottom line.
This led me to the latest piece of development I wanted to start, but I wanted to find out if others thought this would be valuable, or has everyone already built their own solution to handle this. The idea is to determine the warranty end date similar to the pricing tables. If you aren’t familiar with pricing, think of it as a table (or series of tables) that are read to determine what the warranty end date (or perhaps master warranty) should be applied. The idea is that you can determine the products by profit center, material group, product hierarchy, or even material based on your own rules. So you say the first table to look at is material number as the key. if you find an entry, stop and apply that value. If you don’t, drop down to the next table that is product hierarchy. If you find an entry, stop and apply, otherwise move onto to table 3, and so on. This gives you an incredibly flexible way to set the warranty dates automatically.
Now, in order to accommodate, my idea is that my customers will build their own structures (z tables, or pricing tables, doesn’t matter), then just plug the tables into my configuration tables. (It’ll take a bit of mapping, since the application will need to know where to get the data from (sales order, delivery, material master, etc.). But then, my application will use the tables to set the dates on shipment, user registration, or even on repair. IN order to avoid complex user exits, I’d design a program that can be run in batch. I’d pick the most common scenarios (installation, post goods issue, registration) and make sure the dates could be set based on certain key changes. For most organizations, a nightly run of this would be sufficient to handle the warranty dates.
I’d love to hear your thoughts or concerns… and if this might be useful for your organization or someone you know.
thanks for reading,
As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,Mike