Moving transactions retrospectively

Geert Janssens geert.gnucash at kobaltwit.be
Tue Aug 9 05:55:15 EDT 2016


On Tuesday 09 August 2016 18:38:39 Chris Good wrote:
> Geert,
> 
> There is nothing in the guide or help about read-only business
> transactions (as far as I can find), and the Business Features Issues
> wiki [1] doesn't really say much other than [2].
> 
> The wiki statement:
> 
> 'Yet gnucash does not prevent direct manipulation because sometimes a
> manual intervention is needed to keep the books correct.'
> 
> And the fact you can (according to help ch7 Writing off a Bad  Debt)
> 
> ' Change the asset or liability account, in the non Accounts
> Receivable split of the payment transaction, to the BadDebt expense
> account.'
> 
> contributed to my delusion(s?).
> 
> If you could give me some info about what conditions make a business
> transaction read-only, I'd be happy to update the documentation?
> 
> [1] http://wiki.gnucash.org/wiki/Business_Features_Issues
> 
> [2]http://wiki.gnucash.org/wiki/Business_Features_Issues#..._or_I_can.
> 27t_delete.2Fedit_a_transaction_of_type_.22.3F.22_from_the_AR.2FAP_acc
> ount
> 
> Regards,
> Chris Good

Hi Chris,

That's a good observation. From the inside things tend to be too obvious sometimes so we 
forget to clarify certain details.

Here's the thing. The general premise remains: avoid making changes directly in AR and AP 
accounts as much as possible. I have written a few exceptions to correct issues to which you 
refer in [1].

These accounts can have four different types of transactions:

1. invoice transactions (type 'I' in the register). These transactions are generated by the 
business code the moment you post an invoice/bill/credit note. The data you enter for an 
invoice/bill/credit note maps to what you see on the physical paper (or electronic document). 
This is not directly usable in double entry accounting. The invoice transaction is a translation of 
your invoice object into a transaction suitable for double entry. It is composed of all invoice 
entries, optionally a few extra splits for tax purposes and a balancing split in the AR/AP. The 
invoice data is the primary input of the user. The transaction is only a translation of this.
Posting an invoice is also a statement of finalizing. Depending on the legislation in your area a 
posted invoice should be immutable. Gnucash doesn't enforce this though, it only makes it 
read-only by default until you explicitly unpost it again.
For all these reasons you are not allowed to change the transaction directly. Hence this type of 
transaction is always read only.

2. payment transactions (type 'P' in the register). These transactions are generated by the 
business code via the Process Payment window. These transactions are simpler in their internal 
dependencies than invoice transactions. There is no strong link to another business object, only 
a weak one. That's why you can reassign a payment to another invoice for example. And that's 
also the reason unposting an invoice breaks the link with the payment. For this reason a 
payment transaction can be altered by the user directly (though still care should be taken as 
there can be unintended side effects).

3. link transactions (type 'L' in the register). This is a new type that was introduced to solve the 
problem of "paying" an invoice with a credit note. It's similar to a payment transaction, however 
there's no real money moving so the split to an asset account has been suppressed. While 
these transactions are weak links just like payment transactions and hence they are editable, I 
do advise against altering the amounts. At best you can remove such a transaction to reset the 
invoice/credit note "payment" link and start over. All other changes would cause confusing side 
effects.

4. ordinary transactions (type '?' in the register). These are transactions that have not been 
generated by the business features. IMO they don't belong here because some business reports 
will ignore them and hence you may get false results. If you have such transactions in your 
AR/AP accounts investigate why they are there and clean them up.
If they are there because you want to track certain receivables or payables outside of the 
business features, you're better of creating separate accounts for those of type asset or liability 
respectively. You can still call them receivable and payable if you like but they should not be of 
type AR/AP.
On the other hand, if these transactions were meant as payment transactions for your 
invoices/bills/credit notes, use 'Assign as payment' to really make them payment transactions 
or check they aren't doubles that were missed for some reason (perhaps you imported 
payments from csv, but the invoice for which the payment was intended is already set as paid 
manually ?)

There you go, a somewhat structured summary of read-only vs editable transactions in AR and 
AP. Is that sufficient to get you started ?

Thanks,

Geert


More information about the gnucash-user mailing list