Adrien Monteleone <adrien.montele...@gmail.com> writes:
> Thank you Derek,
>
> The inefficiency I referenced was in respect to having to make many
> accrual entries at the end and beginning of each month simply to shift
> the recognition of parts of invoices and bills to their proper periods
> that otherwise would not have to be done if the posting process
> allowed for using the line-item dates. As it stands, using a single
> posting date for a bill/invoice that either crosses periods or
> contains multiple periods results in incorrect recognition. This is
> what I mean by a carryover limitation of paper ledgers. That practice
> was necessary with paper. It is not with computers. (at least I don’t
> see that it is, of course, if you *want* to make all those entries
> manually, by all means… )
The design is such that a single invoice is not supposed to cross period
boundaries. If you find you are invoicing your customers across
periods, that implies (to me) that you don't invoice often enough (or
your periods are way too short). Making new invoices (at least one per
period) is rather cheap, so I recommend you do that ;)
It's certainly true that the invoice posting and payments could occur in
different boundaries -- which revert back to the cash v accrual
accounting question. In accrual accounting that disparity is fine.
Oh, and in terms of a vendor bill, in my mind the period is when I
receive the bill. If someone did work for me in December and doesn't
bill me until February, I'm booking it in February.
> I’m not asking for the business features to work on a cash basis. I’m
> wanting them to not cause me to have to make multiple correcting
> entries for proper expense and revenue recognition. I’m not concerned
> with recognizing bills/invoices when the money changes hands. I’m
> concerned with recognizing them when the expense is incurred or the
> work performed. This works perfectly if everything is tidy in one
> period. It’s a mess if the ‘document' is not.
If it's your own invoicing, then just invoice more often.
If it's a vendor bill, then treat it as a single transaction regardless
of when they did the work... Or enter it as multiple related vendor
bills.
> Perhaps I’m misunderstanding something that you or someone else could
> help clear up for me. Let’s take a simpler example of a single period
> bill:
>
> I receive local telephone service in October. The phone company
> generates a bill for that October service on November 7th. It arrives
> (postmarked) November 12th. I enter it in GnuCash the same day. The
> due date is November 27th.
>
> What should my posting date be?
>
> 1) November 7th?
> 2) November 12th?
> 2) November 27th?
> 3) some date in October? (31st perhaps)
> 4) something else?
Nov 12. That's when you received the bill and posted it to your account.
> What should the ‘opening date’ be?
>
> 1) November 7th?
> 2) November 12th?
> 3) something else?
> 4) If I enter the bill on November 13th, is *that* the opening date?
>
> I guess I’m thinking the ‘opening date’ must preceded the posting
> date, but I suppose that doesn’t matter. (maybe that’s me carrying
> over from paper here)
The opening date would be Nov 7. That's the date the bill is dated.
> Now, let’s complicate things:
>
> I also receive long-distance telephone service from the same phone
> company and they bill me on one bill for everything. That November 7th
> bill is for long-distance calls made in September AND October. All
> other dates remain the same.
>
> What should my posting date be?
>
> 1) same as above?
> 2) same as above and then I have to accrue September’s charges back
> and forth from the above date?
> 3) some date in September and then accrue October’s charges back and forth?
> 4) something else?
Same as above. It doesn't matter that you made the calls in September,
it matters that you're being billed in November.
> What should the ‘opening date be?
>
> 1) same as above?
> 2) some date in September?
> 3) something else?
Same as above.
> (Thankfully, I don’t have to deal with customer charge-backs using the
> business features in this scenario as not only is there a limitation
> of one customer & job per bill, there is the added limitation of one
> period. But it would be nice to see how much expense a particular
> customer is ‘costing' me.)
>
> Derek, thank you very much for your time and effort and thank you for
> writing the business features in the first place! Long ago I was sold
> on GnuCash over other options precisely because I found this mailing
> list and found that developers are active on it. I can’t express
> enough how valuable that is and how much it is appreciated. I shudder
> to think of the cold, faceless brick wall I would encounter (and have)
> with other software. GnuCash and its developer team deserve FOSS
> awards for sure.
>
> Please don’t take anything I say here as any form of criticism or
> complaint. I’m merely trying to understand how this is supposed to
> work. (furthering my understanding of accounting in the process) I
> appreciate that you wrote these features based on your own needs and
> experience.
Not at all. Just trying to backfill the 15+ years of history ;)
I'm sure I didn't get everything right. I was very new back then, and
didn't understand accounting nearly as well as I do now. But I needed
something that would work for my consulting company, so I wrote
something that worked for me (trying, of course, to make it more
general). I know I missed corner cases that apply to others' uses.
Cash v. Accrual was never handled. Similarly, applying multiple
invoice-line-item dates into multiple transaction dates was even never a
glimmer of concept that should even be considered. This is especially
true as a transaction only has one post date, and there is a 1:1 mapping
of Invoice <-> Transaction.
What you're asking for would absolutely violate the 1:1 mapping. I
think it would be very hard to make that change.
> Regards,
> Adrien
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
-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
warl...@mit.edu PGP key available
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
