Moving transactions retrospectively

[Chris Good]

> Message: 1
> Date: Tue, 09 Aug 2016 11:55:15 +0200
> From: Geert Janssens <geert.gnucash at kobaltwit.be>
> To: Chris Good <chris.good at ozemail.com.au>
> Cc: gnucash-user at gnucash.org
> Subject: Re: Moving transactions retrospectively
> Message-ID: <3936336.22LxTUr9lj at legolas.kobaltwit.lan>
> Content-Type: text/plain; charset="us-ascii"
> 
> 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_ac
> c
> > 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
> 

Hi Geert,

That's really helpful thanks. The info re link transactions has really
resolved some confusion I had too.
Back to the Olympics! Aussie Aussie Aussie :-)

Regards, Chris Good

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4817 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20160810/97be82ad/attachment.p7s>