Problem invoices

Thu Sep 4 11:26:57 CDT 2003

Hi,

Messages like this should be sent to the list, not to me personally.
Frankly, you are the only person I've heard of having this problems,
and I've got dozens of people know claims it works fine.

As for posting a payment directly to an invoice, see bug #121420.

As for the numbers being screwey, I've already explained that there
seems to be something going on but you've been unwilling or unable to
tell me what you did to get gnucash into the state you did.  NOBODY
else has seen this behavior, only you, and without a way to reproduce
it I can't find the problem.

But as always, you're welcome to use whatever program you wish.
Me, I'm going to continue happily using gnucash..  I've already
posted and paid dozens of invoices over the last year and I've had
no problems, and all the numbers work out just fine.

The balance sheet is exactly what it should be.  The P&L is exactly
what it should be.  Unless of course you're not using "current" software.

Oh well -- good luck..

-derek

John Zoetebier <john.zoetebier at transparent.co.nz> writes:

> Hi derek,
> 
> Thought I let you know that I have given up on Gnucash, business part.
> It is simply not workig  for me and I doubt it will be working for any
> business.
> I have decided to go for Quasar in stead.
> The base version of Quasar is free of charge and it does anything I
> need for my business.
> Most importantly, Quasar works right the first time without a single
> problem.
> Quasar has excellent support for sales, puchases and all documents are
> very easy to find and drill down.
> 
> The business part of Gnucash is not working properly.
> It is not only a matter of bugs, but there are design flaws as well.
> The most worrysome thing from my perspective is that I simply cannot
> rely on the reports and processen in Gnucash.
> For example none of the business reports show the right information.
> Payable Aging shows a negative number, heaven may know where that
> number comes from.
> Receivable Aging shows numbers that I have no idea where they come from.
> The balance is not right, nor the profit and loss statement.
> 
> Forms are floating everywhere over the screen. Sometimes they are too
> small, sometimes too big.
> Buttons are inconsistently placed, sometimes the close button is at
> the top, other times at the bottom.
> I cannot count the number of times I wanted to close a form, while in
> fact I was closing the form below it.
> The tracking of invoices + corresponding payments is flawed by design.
> Payments are assigned to the customer rather than the invoice. I have
> not seen a single accounting package that handles payments like
> Gnucash. They all link a payment to an invoice, like it should be.
> For example there can be a dispute over an invoice.
> In Gnucash there is simply no way to know if the invoice has been paid
> or not, because a customer could have paid a following invoice.
> 
> I had to endlessly fiddle with numbers to enter my existing invoices.
> My GST return took me half a day, because there is no report in the
> system that shows me sales, purchases and GST.
> I have to calculate the sales and purchases from the GST amounts
> stored in the register.
> It was a plain nightmare.
> 
> Anyway, those problems are gone know.
> Regards,
> 
> -- 
> John Zoetebier
> Web site: http://www.transparent.co.nz
> 
> 
> 
> 
> 
> On 02 Sep 2003 19:16:40 -0400, Derek Atkins <warlord at MIT.EDU> wrote:
> 
> > Hi,
> >
> > John Zoetebier <john.zoetebier at transparent.co.nz> writes:
> >
> >> Hi Derek,
> >
> > First, what version of gnucash are you using?  You've upgraded
> > to 1.8.5, right?  I doubt it based on the data file you sent me.
> > Also, there appears to be at least one problem with your datafile
> > that causes this error:
> >
> > ** CRITICAL **: file gnc-invoice-xml-v2.c: line 189 (set_timespec):
> > assertion `ts' failed.
> >
> > In fact, the issue is this:
> >
> > <gnc:GncInvoice version="2.0.0">
> > <invoice:guid type="guid">7e2d17fa03e5a3b97a52559bda4d6c3c</invoice:guid>
> > <invoice:id>1074</invoice:id>
> > <invoice:owner version="2.0.0">
> > <owner:type>gncCustomer</owner:type>
> > <owner:id type="guid">d982d3fbb1efa9a1222011d90d797e23</owner:id>
> > </invoice:owner>
> > <invoice:opened>
> > <ts:date>1969-12-31 01:00:00 -1100</ts:date>
> > </invoice:opened>
> > <invoice:active>0</invoice:active>
> > <invoice:currency>
> > <cmdty:space>ISO4217</cmdty:space>
> > <cmdty:id>NZD</cmdty:id>
> > </invoice:currency>
> > </gnc:GncInvoice>
> >
> >> Attached is a file with data of Transpaent Systems.
> >> I received a cheque payment from KiwiPlants for invoice 000001
> >
> > Payments cannot be applied to specific invoices...  A payment is applied
> > as a FIFO to all existing invoices for a particular customer.
> >
> >> To my surpise the system thinks invoice 000001 has alrady been paid,
> >> while it is not.
> >
> > Indeed, it does think it's been paid.  I dont know what order you used to
> > enter your invoices and payments, but that will certainly affect what
> > happens.
> >
> >> You can check this by function "Process Payment": the amount is 0
> >
> > Uhh, I dont think you understand how the "Process Payment" works.
> > First, you will only get a non-zero value if you click on it from a
> > particular invoice.  HOWEVER, that does _NOT_ apply the payment to
> > that invoice!  ALL PAYMENTS ARE APPLIED TO THE CUSTOMER ACCOUNT (and
> > applied to invoices on a first-come, first-served basis).
> >
> >> An other problem is report "Receivable Aging"
> >> There are amounts of 00 for some customers.
> >
> > This is not a bug.  This means that you have some entry in the AR
> > account for this customer, and it just happens to balance out.
> >
> > However, I _DO_ see a problem because the aging report seems to claim
> > that Kiwi Plants owes you 84.37 under the 31-60 days, but the Total of
> > that column is 0.00.  I don't know why it's doing that -- looks like
> > there are some payments that aren't applied to some invoices properly.
> >
> > Just like the last time I worked through this with you, I don't know
> > why it's doing it and I cannot reproduce it unless you've kept an
> > intimate detail of all your actions to enter your invoices and
> > payments (including Posting and Unposting invoices, and processing
> > payments).
> >
> >> An other problem is on "Customer Report"
> >> Click on KiwiPlants in the previous report.
> >> The subtotails at the bottom of the page do not add up to "Total Due"
> >> Total Due is: $84.37
> >> 61-90 days: 0.01
> >> 91+ days: 167.81
> >>
> >> It is a complete mystery to me where the system gets these data from
> >> as all previous invoices have been paid and reconciled.
> >
> > Yea, this is weird.  It's as if some payments aren't attached to
> > invoices.  I'll have to take a look at the lot editor in CVS and see
> > what's going on.  But I suspect that you did the same thing that you
> > did before with posting/process-payment/unpost/post.  Note from your
> > doctor: Don't Do That.
> >
> >> A general comment: It would be extremely helpful if the screen which
> >> shows the list of invoices for a customer woud show the amount due.
> >> Now I have to click on "Process Payment" to see the amount due, which
> >> is not correct either (see problem 1).
> >> Regards,
> >
> > File an RFE at bugzilla.gnome.org...
> >
> >> John Zoetebier
> >> Web site: http://www.transparent.co.nz
> >
> > -derek
> >
> 
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available