No invoice had a link to its TXN, but the field post_txn_guid was filled and verifiable by filtering book.transactions for that guid.
Very likely this fixes the same problem but for 'Lot' Many2one as well, but I don't have data like that.
If you made it this far... I'm not a sqlalchemy or GNUCash expert, but it very much appears that the invoices table does double duty and represents what the column entries.bill would be a GUID for (i.e. Entry.bill would be a Many2one char field filled with a GUID that points to an Invoice by its GUID).
My use case is to extract GNUCash to an 'other' accounting platform and am currently doing some sqlite3 updates to just put it in the invoice field UPDATE entries SET invoice = bill;.
I'd guess that bill could become a @property that returns the correct Invoice on the Entry side, but I wouldn't hazard a guess how to make Invoice.entries work on the reverse... maybe be an @property that checks returns different sets based on a field on the Invoice itself?
No invoice had a link to its TXN, but the field post_txn_guid was filled and verifiable by filtering
book.transactions
for that guid.Very likely this fixes the same problem but for 'Lot' Many2one as well, but I don't have data like that.
If you made it this far... I'm not a sqlalchemy or GNUCash expert, but it very much appears that the
invoices
table does double duty and represents what the columnentries.bill
would be a GUID for (i.e.Entry.bill
would be a Many2one char field filled with a GUID that points to anInvoice
by its GUID).My use case is to extract GNUCash to an 'other' accounting platform and am currently doing some sqlite3 updates to just put it in the invoice field
UPDATE entries SET invoice = bill;
.I'd guess that bill could become a @property that returns the correct Invoice on the Entry side, but I wouldn't hazard a guess how to make
Invoice.entries
work on the reverse... maybe be an @property that checks returns different sets based on a field on the Invoice itself?