Scheduled invoices

Derek Atkins warlord at MIT.EDU
Thu Dec 25 22:40:59 CST 2003

Lionel Elie Mamane <lionel at> writes:

> 1) I'm starting to wonder why I shouldn't take a book* argument,
>    too. After all, even gncInvoiceCreate takes one.
>    If I don't have to take a book* argument, what do I put in the inst
>    field of the new invoice?

Use the same book* from the original invoice.

> 2) What does this do?
>      gnc_engine_gen_event (&invoice->inst.entity, GNC_EVENT_CREATE);
>    (No, I'm not expecting "generate the event 'A new entity is
>     created'" as an answer, but rather what happens when this event is
>     generated)

I don't understand -- this is exactly what this function does.  It
generates an engine event that an invoice has been created.  That's
all this function does.

>    In particular, I'm trying to understand if I should first generate
>    the event and then post, or first post and then generate the
>    event.

You should not need to generate any events on your own.  At least I
cannot see any reason why you would need to do so.  Just use the
existing APIs and all the events would be fine.

> 3) I have to call gncInvoicePostToAccount in the process. But it takes
>    non-const pointers for posted_date and due_date. Does it *change*
>    them in some cases? Will it be confused if they are equal?

It takes non-const because some of the other APIs are broken and take
non-const pointers.  No, it does not change them, ever.  No, it will
not be confused if they are equal, but I see no reason why they should
be equal in the general case.  However, the dates are just arbitrary
-- the due date is used to detect when an invoice is, well, due..  And
the post date is for when it's posted (e.g. the 'post date' of the

> 4) The GUI callback for the "post" button calls gncInvoiceBeginEdit
>    before gncInvoicePostToAccount. Should I do that too, or am I off
>    the hook because it is an invoice I'm busy creating (linked with
>    question 2, I guess)?

You should call gncInvoiceBeginEdit() at the beginning of your
function and CommitEdit() at the end of your function.  It is
perfectly safe to nest Begin/Commit calls -- but you must be sure to
actually call CommitEdit for every call to BeginEdit.  Take a look at
all the other setter functions, or the GUI functions.

> Thanks for your help,

You're welcome.

> Lionel


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list