Re: [GNC] Delete, copy and paste to fix mistakes?

2023-11-19 Thread Adrien Monteleone
I forgot to mention about suggestions #6–8, that accounting is not 
really about math. It is about documentation.


Deciding how/where to record something is the primary question of 
accounting.


Accounting is your proof or explanation where money came from and where 
it went to. (with no missing or vanishing money, 'unaccounted' for)


Any related math is simple addition and subtraction, but that is mostly 
for reports.


Transaction math simply asks, "Do Debits equal Credits?"

Regards,
Adrien

On 11/19/23 1:13 PM, Adrien Monteleone wrote:

While you are learning GnuCash (and accounting) I recommend:



6. Record transactions as soon as you can after they occur.

7. Record as much information as you can using Description, Notes (only 
visible in Double Line Mode) and Memo fields.


8. Don't combine receipts with multiple line-items into a single split.


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Delete, copy and paste to fix mistakes?

2023-11-19 Thread Adrien Monteleone

While you are learning GnuCash (and accounting) I recommend:

1. Turning on Formal Accounting Labels
Preferences > Accounts > Labels > Use formal accounting labels

2. Turning on Transaction Journal View
Preferences > Register Defaults > Default Style > Transaction Journal

3. Turning on Double-Line Mode
Preferences > Register Defaults > Other Defaults > Double line view

4. Find a basic accounting text online, or buy one for reference
https://www.principlesofaccounting.com/

5. Record transactions in the account where the money comes 'from'.

6. Record transactions as soon as you can after they occur.

7. Record as much information as you can using Description, Notes (only 
visible in Double Line Mode) and Memo fields.


8. Don't combine receipts with multiple line-items into a single split.

#1–3 will be useful for facilitating your learning from the #4 text 
references. Those options will also allow you to see all-at-once, all of 
a transaction's info/data as close as you can get to a spreadsheet or 
text file. (with a caveat for the special Business Features, though 
there are ways to see most/all of that too, just not in one place)


#5 will help you keep straight the idea that money always flows *from* 
one (or more) accounts *to* one (or more) other accounts. It never 
appears or vanishes from/to thin air.


Alternatively, if you don't want to be restricted in the visible 
accounts, enter transactions using Tools > General Journal, but do note 
that it is limited by default to only 30 days (changeable, but you have 
to do so each run) and using it can certainly lead to some confusion if 
you are still learning the 'flow' of money.


#6 is important to prevent a pile-up of data to enter, and makes the 
task less daunting. I try to enter transactions daily if possible. 
Frequent entry also facilitates #7, because info about the transaction 
is freshest in your mind.


#7 is important for general documentation reasons, and is always good 
habit, but this is especially true when learning accounting and GnuCash 
as you will invariably adjust your Chart of Accounts over time and will 
very likely desire to re-assign entire transactions, or even just one or 
two splits of a transaction to a different account. With the info at 
hand, you can make a better decision in those cases. I use the 
Description for the Payee/Payor (who the money goes to, or comes from), 
the Notes field for general transaction info, and the Memo fields for 
anything specific to that split line.


#8 is also important for the same reasons. If you combine line items 
now, and later decide to separate them, if you don't have the individual 
amounts and a good Memo description, you can't. Autofill works wonders 
in GnuCash. Yes, initially you will be doing lots of typing, but this 
will drastically fall off over time.


-

As others noted, the default data store is XML. Stick with that for now. 
(GnuCash only uses db backends as a data store that is read entirely 
into memory like with XML, it is not a real database application, yet.)


-

Concerning 'immutability' there is no such thing if you have sufficient 
access and knowledge to manipulate files. You impose your own rules on 
yourself in this regard. (unless you have an outside 'controller' 
individual that you have to verify and report to)


In the old days, one of these controls was to use ink, not pencil to 
record transactions. This necessitated correcting entries, rather than 
editing. Original errors are preserved and then later corrected and 
explained. You can still work this way if you like, but you also have 
the flexibility to just edit the original transaction too. Since my 
books are for me and no one else, I just edit in place. But if I did 
have to report to someone else, I'd use correcting entries.


Regards,
Adrien

On 11/18/23 9:08 PM, Wu Ming via gnucash-user wrote:

Hello,

I am not an accountant. Nevertheless was recently asked to administer a family 
micro business.

With few tens of customers and a handful of transactions a year for each, 
volume doesn’t seem large. I can possibly manage with a spreadsheet.

The newly hired, first employee is an unknown. There’s no transactions history 
to look at.

One concern is the learning process. On a text document or spreadsheet I am 
used to fix mistakes by deleting what is wrong. And start over with ample copy 
and paste to reuse. On a spreadsheet also everything is, mostly, under sight. I 
can literally use the zoom in and out function.

I have the idea of accounting books being this sacred repository carved in 
stone. Where only adding transactions is allowed. What is the reality for who 
uses GNU Cash?

Another concern is of reproducibility. With a text file it is easy to diff and 
find what changed and by who. And merge or roll back version. With a database 
is not. Data model is likely relational, db file is binary so it requires 
another tool to interact with, backup up as well and con

Re: [GNC] Delete, copy and paste to fix mistakes?

2023-11-19 Thread Ken Farley
A caveat about this. Any method of storing data could be used by 
multiple people, as long as they have access/permissions to the data. 
However, this is one person at a time. Simultaneous changing of the data 
is not allowed. I believe it's a case of "whoever saves last wins". The 
program reads the data from the database when you open the file only. 
All work you do is only affecting the data in your computer's' memory. 
The data in the database is only updated when you execute a save 
operation in the program.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Delete, copy and paste to fix mistakes?

2023-11-19 Thread Mark at Lorimark

Gnucash can;

1. add/change/delete freely
2. works with sqlite, can't really do multi-user there
3. works with postgres/mysql (multi-user capable)



~mark
On 11/18/23 21:08, Wu Ming via gnucash-user wrote:

Hello,

I am not an accountant. Nevertheless was recently asked to administer a family 
micro business.

With few tens of customers and a handful of transactions a year for each, 
volume doesn’t seem large. I can possibly manage with a spreadsheet.

The newly hired, first employee is an unknown. There’s no transactions history 
to look at.

One concern is the learning process. On a text document or spreadsheet I am 
used to fix mistakes by deleting what is wrong. And start over with ample copy 
and paste to reuse. On a spreadsheet also everything is, mostly, under sight. I 
can literally use the zoom in and out function.

I have the idea of accounting books being this sacred repository carved in 
stone. Where only adding transactions is allowed. What is the reality for who 
uses GNU Cash?

Another concern is of reproducibility. With a text file it is easy to diff and 
find what changed and by who. And merge or roll back version. With a database 
is not. Data model is likely relational, db file is binary so it requires 
another tool to interact with, backup up as well and concurrent use requires 
checks and locks. I have read GNU Cash uses SQLlite. How do you deal with 
versioning / backups and uncoordinated, albeit rare, access from few users?

On the subject I was also toying with the idea to implement something with GNU 
Recutils. Relational, plain text file based data store. But I don’t think have 
the skills or time for it.

I helped at developing web applications for medium sized businesses. Have some 
experience of databases and UNIX. Not with accounting on a shoestring though.

Thanks for sharing.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.