Invoice Importer

[Mike Evans]

On Wednesday July 21 2010 11:17:45 Mike Evans wrote:
> 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,quan
> > ti
> > 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
I filed it as bug(enhancement) 624911.


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