I've tested this using ipython, after setting up the session, book etc...

invoice = book.InvoiceLookupByID("000100")
entries = invoice.GetEntries()
e0 = entries[0]
e0.GetDate()
returns: datetime.date(2012, 2, 1)

There have been several changes in the bindings since 2.4 and it looks like your code needs to be updated to suit.  

invoice = Invoice.from_gnc_invoice(i, slots) Isn't required, once you have the invoice object you can call the invoice methods directly.

Thanks Mike,

Actually that part of the code is OK I think. It was all the other lines where I was trying to reconstruct the objects by passing 'instance=' that was the issue. E.g.

        #gnc_entry = gnucash_business.Entry(instance=gnc_entry)

Fixed that and the other places I was doing that and now it works on 2.6.1!!!

Now I tried it on 2.6.4 and I have a different issue, looks like qof_book_get_slots() has been removed from the C API. Can you please point me in the right direction for how to get to the slot data so I can print it on my invoice? This is how I've been doing it (ugly hack anyway; please help me to make it cleaner)


# gnucash-python doesn't have the functions we need to get the company info
# from the book. This ugly hack gets the job done.
libgnc_qof = ctypes.CDLL('/home/jeff/lib/libgnc-qof.so')
libgnc_qof.kvp_value_get_string.restype = ctypes.c_char_p
libgnc_qof.kvp_frame_get_slot_path.restype = ctypes.c_void_p
libgnc_qof.qof_book_get_slots.restype = ctypes.c_void_p

class BusinessSlots(object):
    def __init__(self, book):
        self._slots = libgnc_qof.qof_book_get_slots(ctypes.c_void_p(book.instance.__long__()))
    def __getitem__(self, key):
        kvpv = libgnc_qof.kvp_frame_get_slot_path(
                        self._slots, 'options', 'Business', key, None)
        val = libgnc_qof.kvp_value_get_string(kvpv)
        return val

session = gnucash.Session(input_url,ignore_lock=True)
book = session.book

slots = BusinessSlots(book)

employer_id = slots['Company ID']
name = slots['Company Name']
contact = slots['Company Contact Person']
...

Jeff,

qof_book_get_slots has been deliberately removed from the public api.

Slots are considered an implementation detail and should not be used directly. All data should be retrieved via the standard api functions. If some functions are missing from the python api, these can probably be added.

Which company info are you looking for that doesn't have its functions exported ?

Here are all the values I'm retrieving from slots

        vendor.employer_id = slots['Company ID']
        vendor.name = slots['Company Name']
        vendor.contact = slots['Company Contact Person']
        vendor.email = slots['Company Email Address']
        vendor.phone = slots['Company Phone Number']
        addr = slots['Company Address']
        vendor.address = addr.split('\n') if addr is not None else []
        vendor.website = slots['Company Website URL']

I'd be very happy to have a cleaner way to do this!

Thanks
Jeff

Now I'm a bit confused because it looks like the stock Scheme invoice scripts are still using qof-book-get-slots. How is that possible if it's been removed?

This is what I copied to get it to work in Python in the first place

@2.6.4 ./src/report/business-reports/easy-invoice.scm +633:

(define (make-myname-table book)
  (let* ((table (gnc:make-html-table))
	 (slots (qof-book-get-slots book))
	 (name (kvp-frame-get-slot-path-gslist
		slots (append gnc:*kvp-option-path*
			      (list gnc:*business-label* gnc:*company-name*))))
	 (addy (kvp-frame-get-slot-path-gslist
		slots (append gnc:*kvp-option-path*
			      (list gnc:*business-label* gnc:*company-addy*)))))

I was able to get my invoice script working again by loading qof_book_get_slots from libgncmod-engine.so which I guess is it's new home. Since I'm using ctypes to load it dynamically I don't care if it's not in the public API. I'm just happy I can resume billing my customers. But I am still interested in doing this the "right" way if there is a "right" way. I'm also curious about when/if the scheme invoice scripts will be updated.

Thanks,
Jeff

Not sure about the Python way, but in C you'd call 
  addr = gnc_vendor_get_address(vendor);
then e.g. 
  email = gnc_address_get_email(addr);

You could also use the g_object_get() or qof_instance_get() interfaces, as both address and gncAddress's fields are exposed as GObject properties.

But those fields are all normal fields/elements stored in the regular database/XML file, not KVP. How are they getting into KVP?

Sorry for the confusion, but I'm not querying a vendor record, I'm querying information about my own company, which is stored in the book object, in kvp I guess. 

Please take another look at the code I posted, including the stock scheme report code which does the exact same thing as my python code and somehow still works.

Ah. This is an example of why we removed KVP from the public API. Those fields are added in scheme and used only in reports, completely invisible to the C core of GnuCash. As a result, there's no guarantee that changes will be saved in the SQL backend.

However, the KVP change is only in master. qof_book_get_slots is still in the maint branch. Are you sure you built from maint?

In that case, it sounds like the scheme invoice report will eventually experience this issue as well and a better all around solution is necessary for printing company data on reports.

I vote to make the company information fields first class data in the schema. They're a must-have for printing invoices and stuff. I really don't want to hard code that or make it some sort of special invoice config data outside gnucash. It's also a very long standing feature of gnucash which will impact other users if it's no longer available.

I was building against the 2.6.4 git tag when I noticed the missing qof_book_get_slots. Looks like maint has been merged into that branch.

commit 1df569e98c883dd6b3f4f06e16784a50af0cd6ee
Merge: 3cc4dc0 29f6c08
Author: John Ralls <jralls@ceridwen.us>
Date:   Thu Sep 4 17:01:12 2014 -0700

    Merge branch 'maint'

There might be some sort of git/svn impedance mismatch here; I notice now that 2.6.4 hasn't been released yet and that qof_book_get_slots is indeed present when I check out the 2.6.3 tag. So I'll take your word for it that it will continue to be available in 2.6.x.

Thanks
Jeff

(In reply to comment #10)
> In that case, it sounds like the scheme invoice report will eventually
> experience this issue as well and a better all around solution is necessary for
> printing company data on reports.
> 
> I vote to make the company information fields first class data in the schema.
> They're a must-have for printing invoices and stuff. I really don't want to
> hard code that or make it some sort of special invoice config data outside
> gnucash. It's also a very long standing feature of gnucash which will impact
> other users if it's no longer available.
> 
> I was building against the 2.6.4 git tag when I noticed the missing
> qof_book_get_slots. Looks like maint has been merged into that branch.
> 
> commit 1df569e98c883dd6b3f4f06e16784a50af0cd6ee
> Merge: 3cc4dc0 29f6c08
> Author: John Ralls <jralls@ceridwen.us>
> Date:   Thu Sep 4 17:01:12 2014 -0700
> 
>     Merge branch 'maint'

There is no 2.6.4 tag. 2.6.4 won't be released until the end of the month.

You're building against master, which is for this development cycle *extremely* unstable. Don't do that unless you want to help with the C++ conversion, and make sure that you have a good backup before you use it on a live data file.

Otherwise check out the maint branch and build against that. You'll be able to use qof_book_get_slots() that way. 

While I'd love to get rid of KVP altogether and move the data "into the schema", doing so would break file compatibility between versions. We may do it anyway at some point, but not now.

Since you've brought to light the Scheme-only use of KVP and seem to have solved your invoice problem, do you mind if I hijack this bug to track the Scheme-only KVP?

(In reply to comment #11)
> There might be some sort of git/svn impedance mismatch here; I notice now that
> 2.6.4 hasn't been released yet and that qof_book_get_slots is indeed present
> when I check out the 2.6.3 tag. So I'll take your word for it that it will
> continue to be available in 2.6.x.

We're not using SVN anymore. It's git all the way down. There are two active branches in the canonical repository, maint and master. Releases are done from maint and most bugs are fixed there; we frequently merge maint back into master to ensure that bug fixes are applied to both branches. New development work is done only in master, and is never applied to maint.

(In reply to comment #12)
> (In reply to comment #10)
> > In that case, it sounds like the scheme invoice report will eventually
> > experience this issue as well and a better all around solution is necessary for
> > printing company data on reports.
> > 
> > I vote to make the company information fields first class data in the schema.
> > They're a must-have for printing invoices and stuff. I really don't want to
> > hard code that or make it some sort of special invoice config data outside
> > gnucash. It's also a very long standing feature of gnucash which will impact
> > other users if it's no longer available.
> > 
> > I was building against the 2.6.4 git tag when I noticed the missing
> > qof_book_get_slots. Looks like maint has been merged into that branch.
> > 
> > commit 1df569e98c883dd6b3f4f06e16784a50af0cd6ee
> > Merge: 3cc4dc0 29f6c08
> > Author: John Ralls <jralls@ceridwen.us>
> > Date:   Thu Sep 4 17:01:12 2014 -0700
> > 
> >     Merge branch 'maint'
> 
> There is no 2.6.4 tag. 2.6.4 won't be released until the end of the month.
> 
> You're building against master, which is for this development cycle *extremely*
> unstable. Don't do that unless you want to help with the C++ conversion, and
> make sure that you have a good backup before you use it on a live data file.
> 
> Otherwise check out the maint branch and build against that. You'll be able to
> use qof_book_get_slots() that way. 
> 
> While I'd love to get rid of KVP altogether and move the data "into the
> schema", doing so would break file compatibility between versions. We may do it
> anyway at some point, but not now.
> 
> Since you've brought to light the Scheme-only use of KVP and seem to have
> solved your invoice problem, do you mind if I hijack this bug to track the
> Scheme-only KVP?

It's all yours!

(In reply to Geert Janssens from comment #6 on Bug 645786)
 
> The issue with this approach is that direct kvp access is deprecated and
> will be disabled in the unstable release. So trying to use this to enable
> fancy date formats in the invoices is a dead end street. The proper solution
> is probably to define a "book" object in the engine like any other
> serializable object (accounts, transactions, splits, invoices,...) and have
> object manage these book related properties.
> 

These properties aren't really part of the book object, they just happen to be stored there, so I think that they should be first-class objects themselves, perhaps GncProperty, that happens to store itself in the Book's KVP.

Note that the options database already is just such a first-class object, GNCOptionsDB. Aside from the load/save code in qofbook.cpp, most of the code which works with it is in several files in app-utils, and there is indeed some Scheme that's directly accessing KVP which needs to be changed to using the OptionsDB.

Fixed in kvp-cleanup, using gnc_book_set_options(). Merging to master shortly.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=736139. Please update any external references or bookmarks.