Invoice defaults

[Neil Williams]

I've been away from the gnc code - working on the other end of the data chain 
that will allow me to create gnucash invoices from Palm data.

That end is now ready and I've been reconsidering how to convert QOF objects 
from pilot-qof to gnucash. I may be removing the QSF map code in favour of a 
SQL-type join interface that has far reaching implications. (More anon.)

I've been considering the question of default values for invoices - on a 
per-user, per customer and per job basis. I propose:

1. New parameters for gncCustomer and gncJob: mileage_rate and hourly_rate.

These would cascade, ala CSS, so that if a customer has a rate set and that 
customer has a job, if the job also has a rate, the job rate overrides the 
customer rate for invoices that refer to that job.

If you're wondering 'what about other rates' - IMHO we only need these two 
because other material gncEntry's have a fixed number of units and a price 
that varies, compared to these which have a rate that is agreed with the 
customer *and* a number of units that vary. gncInvoice/gncEntry currently 
only implements 'Hour & Material'.

Example:
I work for a client at a job for 8 hrs. I charge an hourly rate for that job. 
Whilst at the job, I incur a daily parking charge, a bridge toll and I cover, 
say, 70 miles. I charge my hours under the hourly rate for that job 
(different jobs/customers, different rates), I charge one material entry for 
the daily parking charge (qty=1, price=charge) and another material entry for 
the bridge toll (qty=1, price=toll). I also charge one material entry for 
70miles at the mileage_rate (qty=distance, price=rate). This, to me, accords 
with how expenses are invoiced - either as a single total or as a series of 
separate expenses. Multiple expenses could be listed as separate entries 
(above) or combined into one as an aggregate - (qty=1, price=(toll+charge)).

2. Per-user Account defaults for invoices.

I find it laborious to keep re-entering the same accounts in each invoice and 
I worry that sometimes I get the wrong one. gncInvoice could have a new 
parameter: The GUID of the per-user default account for invoices, the A/R 
account. There could also be a default account for posting. These would need 
some GUI code to allow the user to select the default(s) which could be 
stored in gconf or (more likely) in the data file.

Results:
I could then "pre-populate" a gncInvoice from Palm data. The Palm QSF XML 
would describe the customer and the job - allowing gnucash to skip the 
current laborious interface for starting a new invoice - and populate the 
entry list using data from the Palm calendar and expenses tables.

I'd have a new Business menu command to load data from QSF XML or (optionally) 
directly from the Palm using the new pilot-qof command: 
e.g. 
$ pilot-qof -a --invoice-city -t 2005-09-14

(How would a system command like this be handled behind the menu? Presumably 
some gconf setting to enable/disable it and simply hardcode the options into 
the C call? Can gconf check if a program is installed on the user's system? 
We don't want this as a dependency, just work with it if it is present.)

This would take the user from the gnc main window *straight* to the invoice 
entry window, with all customer and job selections set and all relevant 
gncEntry lines completed, ready for any further tweaks and checks before the 
user posts the invoice. (I'm not happy writing code that automatically posts 
invoices - if someone else wants to cross that bridge later, that's fine, but 
auto-post is just too scary for me!)

The code behind the menu command would use QOF queries to convert the data 
from pilot-qof to gnucash, instead of QSF maps. This 'join' type interface 
will be new to QOF and would bring considerable advantages. The queries 
themselves can be hardcoded into gnucash or stored externally in a text/sql 
file.

In pseudo-SQL :
INSERT into gncEntry (gncEntry.qty=(pilot_datebook.end_time - 
pilot_datebook.start_time), ... );

There is no actual code for this yet. (And joins would only be supported for 
INSERT - there would be no support to select elements of a particular object. 
i.e. joins are a mapping / data creation tool only and the target object must 
be registered in the QOF process running the join. This is to retain object 
integrity.)

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060103/ed7fdcf1/attachment.bin