Feature request: process multiple invoice with single payment

Derek Atkins warlord at MIT.EDU
Tue Aug 14 10:19:54 EDT 2007


Hi,

I'm sure you meant this in a constructive way, but even after
reading this over several times over a couple days it still
comes across as condescending.  I'm SURE you didn't mean it that
way, but honestly, I (and most of the GnuCash developers) have
a lot of experience in software development.  Of COURSE we're going
to think about how it's supposed to work and behave before
we go implement it! That's just.... Duh!

"Suspense" accounts are a user thing.  GnuCash doesn't care, and
indeed shouldn't care.  You can Process Payment into a Suspense
Account just as easily as you can Process Payment into a Checking
Account.

For the record, I wrote the business features to MY needs as a
consultant.  I tried to make them more general, but honestly
I focused on the features that I needed.  I never needed Credit
Memos or Refunds or anything like that, so I never implemented
it.

Lately I've had very little time to work on GnuCash, and I don't see
that changing anytime soon.  So I suggest you find someone else
who can champion your cause and actually write code.

Good Luck,

-derek

Mike or Penny Novack <stepbystepfarm at mtdata.com> writes:

> Rare, but remember the 80/20 rule (in general, 80% of the coding
> effort will for handling situations that are less than 20% of the
> time). In my experience, fully half of the coding effort will be for
> situations which occur only a couple percent of the time -- all the
> "exception" processing.
>
> I only rarely was involved with the "invoice billing/collections"
> system unless the programmers there were really stumped or a disaster
> of some sort. But I still have a few suggestions:
>
> 1) Don't start with the coding issues or even what sort of drop down
> menus. Start with considering all the functionality that should be
> provided (what situations might arise, how to deal with), then how to
> be handled at the user view level (menus, etc.) and only then how you
> will implement.
>
> 2) I am getting a little concerned that I have not (yet) seen any
> mention of "suspense" (the usual name for the account into which
> amounts are dropped where the person dealing with the check that has
> come in can't immediately put it where it eventually goes). Take the
> check covering several invoice situation we are discussing. Customers
> can do odd things. Here's examples:
>    Your are billing customers $10/mo for some service. The invoices
> are prepared some number of days in advance of the bill mailing so you
> assume that you will have an invoice available before the check comes
> in. People here seem to be talking about the situation where there are
> several as yet unpaid invoices and a check comes in to cover all of
> them. Fine, the invoices exist. But suppose the customer isn't
> behind. For the August invoice you receive a check for $30 (the
> customer is going away for a couple months, paying bills in advance --
> but the corresponding invoices do not yet exist ). There are a number
> of ways your business can handled that, send a check back in return,
> prepare the future invoices and mark them paid, wait till they get
> produced in due course and pay them, etc. -- but none of these options
> are immediately available at the moment you are trying to process that
> check. Or how about a check for an amount that does not match the
> total of the invoices. Too little and you have an unpaid balance left
> on an invoice, you probably considered that. But what if too much?
>
>

-- 
       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


More information about the gnucash-devel mailing list