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