Re: Invoices & Clients

I know I'm a bit daft, but it seems like there's a design flaw to have
add-on modules that REQUIRE other add-on modules.  It's my feeling that
modules SHOULD be able to work by themselves under the horde framework. 
You're creating a house of cards, here.

Seems that juno, turba, whups should NOT require one another BUT use a
central database to pass info back and forth.  Perhaps this is actually
what you mean, and I'm just too tired to pick up on it....  If so, sorry
:)

Furthermore, it seems like turba (and maybe even whups) is now becoming a
conduit of sorts between several modules.  Perhaps it would be better to
bring that UNDER the horde-hood, so to speak.

Just my humble opinion...
Jeremy


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