RE: Invoices & Clients

Jason et al.

Just a note from a hermes lurker who definately has not earned any right to
comment but... at what point are you writing an accounting system and not a
groupware module? Perhaps this is laid out in the Juno roadmap.

I think that better ties to something like Nola and/or
Quickbooks(unfortunatley) has far more utility from a groupware point of
view.  Starting too much on an invoicing side is a really slippery slope.

Links beween Hermes, Turba, Juno and Whups as you describe are critical.  I
would love to see a timeline based project planner type app, but, before
Chuck jumps on me I have to admit I am too lame a coder to do so myself.  I
do stand by with cash though, instead of skills.

Best to all and many thanks for all the great work.

Charles Overy
LGM

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Jason M. Felice
Sent: Wednesday, June 18, 2003 10:41 AM
To: [email protected]
Cc: [email protected]
Subject: [hermes] Invoices & Clients


Here's how I think clients and invoices and everything _should_ work.  This
is sort of a proposal.  I'm looking for input on it, and there are a few
points which need to be hammered out.  This was condensed from IRC
discussions
and a lot of notes I've been taking on our company's invoice process.  If
other
companies have different requirements, please speak up so I can at least not
paint this into a corner.

I'm cc'ing Hermes because the topic of invoices seems to come up from Hermes
users (like me, for example).

Thanks,
-Jay 'Eraserhead' Felice

1. Clients:

Clients will be handled in a juno table which mirrors turba's contact table
format.  Turba should be confgiured to use this table as a public address
book, and turba will be used to maintain this.

	[Question: how to prevent deletion of a client when we have billing
	info on them?]

whups will be modified so that it can assign a client to each module, so
that
we can have multiple whups modules for a client.

	[Question: do we provide a "client" api?  Or do we just use the link
	type stuff to link to contacts in turba?]

2. Invoices:

2.1. To-invoice Account

juno will have a `to-invoice' account.  Items added to this account will
have
an assigned client, amount, decription, and other invoice-type information.
This will queue the items until invoicing time, and the user will be able to
manually add an item to this account at any time.

Juno will provide an API for posting invoice items to the `to-invoice'
account in a batch.  The posting application will supply its name, and juno
will supply a batch id.  Hermes will be modified to allow a user to post
a week and keep track of which weeks are posted, along with the juno batch
id.

2.2. Invoicing Process

Invoices are done in batches, grouped by client.  The user creates a new
invoice, chooses the client from a list of clients who have outstanding
items to invoice, and then selects which invoice items to bill.  The user
can then edit amounts, rates, quantities, whatever.  The user can edit the
terms of the invoice, put a comment on it and other miscellaneous invoice-
level stuff.  The user can then submit the invoice.  Repeat until all of the
week's (or whatever) invoices are entered, the user can then submit the
invoice batch.

The user should be able to browse invoice batches, then browse invoices,
then see invoice detail.  He will be able to export an invoice batch or
selected invoices to make a QuickBooks import file.

3. Miscellaneous Points

* No expense feature is really needed this way if users can enter to-invoice
  transactions.
* Had an idea about a scheduler app that can schedule "event types" exported
  from other applications.  This solves two issues- recurring invoice
charges
  and recurring tasks.


--
hermes mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]



-- 
hermes mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]