Hi Richard. Richard Lyons wrote:
> Steve: Thanks. But I was unable to access the demo properly. When I > clicked on any report on the menu panel, I got: > > Error! > > Can't locate users/demo.conf in @INC (@INC contains: > /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 > /usr/local/lib/site_perl .) at /var/www/cgi-bin/sql-ledger/menu.pl line 65. Thanks for telling me. I had a couple of those and I'm looking into it. Just try again, it's still there. > Anyway, I think the credit note problem is a little different. It is in fact > easy to enter a credit note -- it is just a matter of entering an invoice > using a negative amount. > > 3 examples: > (a) one issued by a supplier to cancel from an already issued invoice an > item which has been returned - this will be used to partially pay the > invoice > (b) one issued by a supplier to cancel a whole invoice > (c) one issued by a supplier to recognise some other damage which may > result in a credit great enough to "pay" more than one invoice and > may including partially paying another invoice (I had one that offset > roughly three and two thirds invoices) > > The problem is that when using the "payments" routine, there is no way to mark > the debit and credit amounts that offset one another except to use a cheque > to pay them. This then results in the case (a) in the bank account showing a > larger credit for the whole invoice and a debit for the credit note, rather > than the actual amount of the cheque paid. In (b) you have to invent a > non-existent cheque and pay both the invoice and the credit note with it, > creating two spurious entries in the bank account listing. In (c) you get a > stack of virtual credits and a debit to cancel a proportion of it, rather > than the actual amount of the cheque paid. All of this makes the apparent > turnover of expenses higher than it really is. What one needs to do is > simply credit the accounts payable (which the use of a negative amount as > above succeeds in doing) and then to mark the component transactions (of > which there are three in case (a), two in case (b) and many in case (c)) as > closed. So what we really need is a tick box for "closed" in the payments > screen and a routine that will check that the items ticked do in fact > balance. An added help would be if SL recognised the negative amounts and > printed some indication that they are credit notes (or even just put them in > red). I paid the Fred Flintstone invoices 12245 and 4421 with check number 1234 on the demo. In reality, these credits (and debits for A/P) and taken on a check. The systems of the people you're doing business with should do this also. You get a $75 check to pay invoice 12245 for $125, and invoice 4421 for -$50. Both are closed with the receipt of the one check. The check stub should detail the invoices being settled with the check. They should be plugging their credit memo, for example, into their A/P system just like a positive invoice and actually pay it on some check. Play around with some of these on the demo and post back to the list referring to a certain transaction if you don't think it handles it correctly and I'll look at it. >Why is it so complicated to explain simple thoughts about bookkeeping? There's a reason accounting is a degree program at most colleges/universities, ;-). Good luck, Steve > > -- > richard > > On Wednesday 03 July 2002 23:46, Steve Doerr wrote: > > I set up a service called "credit memo" (number - cm) on the Kansas City > demo. > > Zero list/sell price and I unchecked the tax boxes at the bottom. I > invoiced the > > customer Fred Flintstone for the service "credit memo" for a negative $50 - > tax > > included unchecked. In reality, you will probably, but not necessarily, be > > crediting some previously charged tax, but I wanted a clean example to show > how > > this might work. > > > > I think this will accomplish what you want to do a little cleaner than > journal > > entries/other workarounds because if you invoice this negative amount, > there it is > > associated w/ the customer. > > > > Please feel free to go to the KC demo and set up a similar invoice/credit > > situation and see if you're comfortable with how it works. Watch your > taxes, > > discounts, and G/L accounts on these and consider your due date for aging > > purposes. > > > > You should be able to apply a similar approach to A/P with a "debit memo" > service. > > > > The demo's url: > > http://accounting.dyndns.org/cgi-bin/sql-ledger/login.pl > > > > Good luck, > > Steve > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf
