[GNC] Reconciliation Report -> Trade Debtors -> pairing transactions

[Uttam Chakravorty]

Dear Michael,



Many thanks to both you and Adrien.  Both the answers are far more considered than my initial comment had intended to provoke, thank you.  I had made my original comment by way of explaining how I was approaching the puzzle i.e. in the early eighties I would parse the software through a hexadecimal editor such as Norton and then check the search results in plain English by interrogating the Audit Trail.  It seems so primitive compared to what I have just learned.


In general today I'm very happy to use the TB as my critical check at the risk of missing out on any reciprocating errors.  I find they either prove de minimis or so big that they don't stay hidden.


The first part part of what I was seeking has been addressed by Adrien.  If there is a way to get the average debtor/creditor days this would be the icing on the cake.


 
Returning to Gnucash I find it the best piece of software I have used in 40yrs and it handles our needs brilliantly.  I love the way it sticks to the T-bar principles, I'm sure the Medici would have loved it and could have avoided so much bloodshed.  I appreciate it is far more capable than simple bookkeeping, the limitation is that is all I know.  I was put out to grass nearly a decade ago and I only get to do this as it is a small business (just my wife and son evangelising Linux - fun but not particularly business-like).  The multi-user issues that you recall bring a smile to my face as they can no longer strike terror into my soul.



With many thanks and best wishes, Uttam (and a beer or three (who's counting) if you are ever in my neighbourhood)






 From:   Michael or Penny Novack <stepbystepfarm at comcast.net> 
 To:   <gnucash-user at gnucash.org> 
 Sent:   02/10/2022 3:46 PM 
 Subject:   Re: [GNC] Reconciliation Report -> Trade Debtors -> pairing transactions 

 
> 
> And in that case of 'breadcrumbs' the entirety of GnuCash is an audit  
> trail, as that is how double-entry accounting works. 
> 
> If you are looking for some record of exactly who entered which  
> transactions and the date/time stamps, no, that is not available.  
> Technically I think the posting date/time does get recorded, but it is  
> not readily available to users. If you really need it, perhaps start a  
> thread just on that question. 
> 
> Certainly the 'who' will be impossible, because GnuCash is not a  
> multi-user application. Whomever has access to run the app, and access  
> to the file, can post or edit transactions.  
 
As somebody who used to do this (for one of the world's largest  
"financials") my comment might (or might not) be useful. 
 
a) The accounting system itself (its own reporting functions) would not  
provide a way of reporting when/who by. It is important to understand  
that this information is NOT part of the accounting system. Accounting  
is not a "real time" process nor would who by (what worker bee) be  
relevant to the question of correctness in an accounting sense. 
 
b) But there are OTHER ways in which general ledger might be audited.  
Internally correct is one matter, but externally correct is another. For  
example,here we have an invoice marked paid by check. But WAS there  
actually such a check, and if not, who (falsely) entered that invoice as  
paid and when. How many of you when first learning to use gnucash  
created a set of "test books" and into these entered a number of "test  
transactions"? Understand? There was nothing wrong internally with this  
set of test books you were using to learn gnucash but they matched  
nothing in the real world. 
 
c) Like I said, there would be no functions PART of the accounting  
system to be used for this sort of purpose. But when the auditors  
(checking against the real world) found something suspicious, this sort  
of problem would come t my desk. "Mike, figure out who entered THIS  
transaction and when". So I would figure out what feed to the system  
would have fed that transaction to general ledger, get the right backup  
tape recovered from the vaults, and with a little "ad hoc" program I'd  
write for the purpose, get that information. It's not as if I'd be  
writing a lot of these ad hoc programs from scratch, just take to one I  
used last time and change a line or two of code. 
 
    THIS sort of "check against the real world" was rare. I [probably  
did only a few times a year. More often it was personal and quickly  
enough after that fact I didn't have to have backups recovered from the  
vault. Thus suppose I was handed a problem from a client area "here's  
what one of our worker bees entered but it didn't "take", figure out the  
bug". Well actually MOST of the time no bug. Just a typo, what was on  
the piece of paper (as what was entered) didn't match what the worker  
bee actually entered at the terminal. We all do typos, and that's how I  
would report the problem as solved. No harm done. I probably did a few  
of THESE per week. It'd have been a waste of programmer time my handing  
off to one of our programmers to try to find a bug that didn't exist. 
 
Michael D Novack 
 
 
 
 
 
 
 


------------------------------------------------
If this email has been sent to you in error please delete it and accept my apologies
Company number: 4324700