Invoice Importer

[Mike Evans]

On Monday June 14 2010 22:31:39 Mike Evans wrote:
> On Monday June 14 2010 16:58:37 Derek Atkins wrote:
> > Hi,
> > 
> > Mike Evans <mikee at saxicola.idps.co.uk> writes:
> > 
> > [snip]
> > 
> > >> > New patch seems to work fine.
> > >> 
> > >> Excellent.  Does this mean it can be merged into gnucash before 2.4,
> > >> or does the string freeze prevent that?
> > > 
> > > Really not sure.  It's not my code, it's Sebastian's, although I have
> > > a patch for it to fix some minor issues.  I think it could be further
> > > augmented to give more flexibility too.  As a user I can write a
> > > script to massage any sales application exports to suit the format.  I
> > > guess the string freeze will be an issue too as, it would need the
> > > strings to be made translatable and accepted into trunk.  Again, not
> > > my code even though it's GPL.  It has a fixed csv field sequence so
> > > may not be universally useful.  I have no idea whether Sebastian wants
> > > it included in the build, or whether the devel team want it included,
> > > or whether my patches (unfinished) to the patch are acceptable.  I
> > > suggest you try it out and mail here with your views.  That
> > > presupposes that you are able to compile from sources.  Use a backup
> > > data file for testing obviously.
> > > 
> > > It's written as a plugin and  I'm not sure if plugins are part of the
> > > core code or what the procedure is for including them is, although it
> > > does require changes to configure and some makefiles.
> > 
> > Many plugins are still part of the core code.
> > 
> > As for the string freeze....  That's a good question.  I think it would
> > be up to Phil to decide what to do, but more likely it's missed the
> > train for 2.4.0.
> > 
> > > Mike E
> > 
> > -derek
> 
> I thought it may too late.  More time to get it right then.
> 
> Anyway, if anyone is testing this.
> 
> I've made a patch to fix:
> 1. Invoices are created in GnuCash even though there is a invoice with same
> number already existing.  The patch asks if you want to update the existing
> invoices with new rows.  This may not be the ideal behaviour but it is
> better. behaved.  Alternatively it could just ignore any lines with
> existing numbers but this way you can just stop the import and
> re-examine|edit the csv.  You're asked only once per import, not once per
> line.
> 2. Previously posted invoices are ignored.
> 3. Lines in the csv with a # at the start are now ignored as comments.
> 
> The csv line format is:
> 
> id,date_opened,customer_id,billing_id,notes,date,desc,action,account,quanti
> ty,price,disc_type,disc_how,discount,taxable,taxincluded,tax_table,date_pos
> ted,due_date,account_posted,memo_posted,accu_splits,
> 
> Compulsory entries appear to be: id, date_opened, customer_id, price
> 
> 
> Apply this patch after applying Sebastian's patch.
I've now written a bill/purchase order importer for the reasons I've 
previously mentioned.  Basically, it's slightly adapted Sebastian's code so I 
hope he's OK with that.  Recent changes in the gnucash code seem to have 
broken it, so I've fixed that too.  Since it's not actually in SVN yet, I think 
the best thing to do with it is to open a enhancement-bug and post it there.  
As Derek says, it's likely too late to include a new feature into 2.4.0 but 
interested (?) people can test it and use if they want this functionality.

To recap.  I often make purchases of electronic components with often 30-50 
lines in the purchase order.  Some of the PO is for stock (assets?), some for 
a specific project(expense or stock?) and some of it may be tools (assets).  
Manually re-inputting a PO into gnucash is a PITA and since most vendors offer 
a order download in CSV format a better solution is wanted.  With a simple 
Python script to massage their CSV  into the correct format the import becomes 
trivial and each PO line can be manually assigned to the correct account.

Mike E


-- 
GPG Key: 1024D/050895C2
Keyserver: http://pgp.mit.edu/          
Search String: 0x050895C2