You just made my point. Since it is your opinion, then true resolution is not likely to be achieved. I, in fact, agree with your approach and would do this your way if it was my decision. That doesn't make it "right" if I or 100 others agree with you, it just means we have the same opinion. But the problem here is that the client doesn't agree with your opinion. And the only way to sway them is to provide compelling evidence that is not a matter of style but one of substance thereby not making it an opinion but a fact that your choice provides greater efficiencies and end results that produce greater gains (and believe me, I know this is not easy).

And whenever I get the answer 'We have always done it this way' (which is often), I re-query with 'Then why did you always do it this way?'.

Good luck again!


>I disagree somewhat. I feel that you shouldn't mix and match. An invoice that one day indicates someone owes you money should not be treated as a credit memo the next day. Think of looking at old and new reports. On one report, you see an invoice - an amount billed, then you look at a more recent report and suddenly the same invoice shows a credit. Makes for a messy audit trail, IMHO. I think an invoice should be an invoice and a credit invoice should be a credit invoice and never the two should meet. And just because someone wants to do something a certain way doesn't make it right (hey, I guess you could say the same thing about my argument <g>). But my point is that these aren't always highly trained or knowledgable accountants. They are just bookkeepers "who've always done it this way" - which is not a reason to do something a certain way. I'm trying to keep a clean system behind the scenes with a clear path about what happened.
>
>
>>Hi Russell,
>>
>>As a systems professional who has worked with accounting systems for over 25 years, I thought I would chime in here.
>>
>>First, I like to stay away from saying that there is a right way or wrong way of doing something. I prefer to use the efficient vs inefficient argument. By doing this, both sides can most of the times come to an agreement, otherwise you end up arguing on style which will never come to resolution.
>>
>>In order to achieve this in your situation, I would have to ask what does the approach of the client do that makes this process inefficient? Does it break underlying rules of the system because the system does not have a way of handling negative invoices? If this is true, then you have a cold hard argument that supports moving to the other approach. If it doesn't then it is just a matter of style and the new way provides no benefits. This is like trying to convince someone that blue is a better color than red when red is their favorite color.
>>
>>In the end, I never try to force something on a client. I try my best to give them compelling reasons as to why they would need to change their methods so that in the end, they decide to make the move because they have been convinced of the better (or more efficient) way. It doesn't always happen that way, but it happens many more times than not.
>>
>>As far as your particular situation, it appears to me to be a six of one/half a dozen of the other. In other words, it appears to be an issue of style, not substance. Unless you tell me that you have to re-design software to handle doing this their way (cost and time now come into play), in which case you have a compelling reason to do it your way.
>>
>>Good luck!
>>
>>Bob
>>>While converting a system for a client, I'm running into problems with the way they approach things. One is simply the age-old "we've always done it that way" problem. Something more specific is their desire to have an overpayment on an invoice make the invoice balance go negative, effectively making it an open credit that can later be applied against another invoice. So you have a situation where it's an invoice one day, a credit the next. One day you're getting a payment against it and the next you're using it as a payment to pay something else. To me, this is the wrong way to go about it. I have the system never letting a balance fall below zero and generating a credit invoice for the overpayment amount. Then the credit invoice can be used later to apply against another invoice. This causes some issues for them, though I'm going to address them. Anyone have any thoughts on these two appoaches?
>>>
>>>Russell Campbell