Re: [GNC-dev] GnuCash 3 on Linux

[Wm via gnucash-devel]

On 24/02/2019 15:40, Colin Law wrote:

On Sun, 24 Feb 2019 at 15:21, Wm via gnucash-devel
 wrote:


That is the point, dear, you may not have said a swearword but what you
are supporting is shameful.


Please don't call me dear.  That is almost as bad as labelling me a
Trump supporter.
I don't understand what it is you think I am supporting, all I am
supporting here is gnucash and civility.


If arguments were heard I'd agree.

No-one likes repeating themself.

--
Wm




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

[Wm via gnucash-devel]

On 07/03/2019 23:42, David Cousens wrote:


I backup all user data including hidden directories on my hard disk to an
NAS so no matter where it is I have it copied. I do full backups monthly
with daily incrementals and usually retain them for 3 months these days.  I
off load the backups onto USB for offsite storage as well now that they are
big enough. I'm retired so the data flow is very much reduced these days. I
also do selective backups to offsite cloud locations of critical data
including GnuCash. For those I backup all the data in the locations given
for v3+ in the wiki Configuration Locations for GnuCash. I don't bother with
the aplication config in /usr/local/etc/gnucash as I don't edit anything in
it.  My desktop is also synced with my laptop and my wife's laptop- not
really secure as a backup as any saved changes get propagated including
those that might take the system down but it has helped with some simple
problems. My NAS is NFS4 based so my Linux boxes communicate pretty easliy
with it (it is mounted when switched on on all computers and Samba takes
care of the one Windows machine. Took a while to setup but the NAS initiates
backups to itself on a schedule. Also backs up our mobile phones.

When I was operating a business and in a past side job as a systems manager,
I used a Towers of Hanoi (annual/quarterly/monthly/weekly/incremental)
backup plan.

The locations I would backup as a matter of course would be the ones
labelled GNC_DATA_HOME and GNC_CONFIG_HOME ( and all files and
subdirectories in those locations) in the diagrams. I haven't bothered
customising the gtk-3 setup for GnuCash so I wouldn't bother with the GTK
locations.


Devil's advocate:

If (I am not wishing this on you, David, or anyone else, but it is not 
an unreasonable thing to think about if you are in Oz) flood or fire 
destroyed your home and your computer systems would you know what to 
restore?


I think you don't or can't know what to restore wrt gnc at the moment.

Making a backup plan is good but purposeless if there isn't a restore 
plan to match.


re GNC_DATA_HOME and GNC_CINFIG_HOME you don't seem to have grasped that 
these are not consistent!


At the risk of re-using stuff take a look at
https://en.wikipedia.org/wiki/Fitch%27s_paradox_of_knowability

In plain terms you may have a good back up strategy but have you tried 
putting it all back together?  I think not, if only because the gnc bits 
will be all over the place.  Will you have the latest version of all the 
files?  Probably.  Will you be able to put it together as it last was? 
Unlikely.


--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

[Wm via gnucash-devel]

On 08/03/2019 14:49, Derek Atkins wrote:

Adrien Monteleone  writes:


Separating preferences for reports is, I suspect, more useful to a
multi-user environment, which GnuCash does not support, but can be
useful for a single user who keeps books for multiple entities that
are all in the same jurisdiction and might well even use the same
CPA. (and certainly have to file the same tax forms) They might even
all follow a July-June fiscal year, for example.


The whole options subsystem needs to be re-evaluated.  I feel there are
multiple categories:

* Per-User
* Per-User Per-Book
* Per-Book


I agree.  Further, we are able to do this and have done it before, those 
with long memories may recall some things were moved (in a user sense) from

  Edit / Preferences (where they didn't belong)
to
  File / Properties (where they sat more naturally)

It might be useful for people to consider
  what belongs to the file?
  what belongs to me?
  is gnc an extension of me as a person?
  or is it a record of fact?

I've said this before but gnc has a screwed up view of ownership when 
the prices.db (which is by definition impersonal) is included in the 
book but reports (which are intrinsic to the book, as in they contain 
actual id's that don't make sense anywhere else) are left all over the 
place.



This includes things like the display features that you mentioned (which
I snipped off).  You're right, I feel that the column settings, and even
whether to display placeholder and/or zero-balance accounts is probably
a Per-User setting.


Column settings I think of as per user.

Placeholder ticks should be per book as gnc "does things wrong" if you 
enter tx at the placeholder level by accident and the account structure 
includes a mixture of commodities, currencies or anything else not the 
same.  If all of the accounts below the placeholder are the same as the 
the placeholder account it works OK in my experience, but only in that case.


I think of zero balance account display as a report setting.


I think it would behoove us to go through every option, every
preference, and every report option and decide which bucket they belong
to.  Indeed, many of the report options may need to be split into
different categories, but I'm not exactly sure how to do that properly.


I would be prepared to help with this as I would like to contribute and 
it seems like it will be years before my database and reporting skills 
will be utilised.



I'm not convinced it's all about multi-user -- although part of it is.
And for the record, GnuCash DOES support multiple sequential users.  It
just does not support multiple simultaneous users.


Agreed. I think the multi-user argument is a red herring.  The current 
structure is failing on all of


  same-user same-computer different-login
  same-user same-login different-computer
  same-book same-user different-login
  same-book same-user different-computer

I could go on about all the combinations the 3.x structure simply does 
 not support, hopefully those are enough for ordinary people to 
understand that what we have is fucked.


multi-user isn't the problem to be solved, people understand if you say 
to them "gnc is like a spreadsheet, it doesn't work well if more than 
one person is changing it at once", it is damn hard to explain to them 
you don't know where their reports are!  saying "gnc did it" doesn't 
work in my world view.



I started a project to map out report preferences as part of a revamp
of the tab content and I didn’t finish it. Perhaps completing that
project will offer more insight. (and very likely allow me to discover
that the present situation is optimal)


I think this would still be a useful project, to map out all the various
preferences and settings throughout the application.


+1

I think we might need some people to change their ideas about what 
belongs to what before we can really progress.  There isn't any point in 
defining stuff if it isn't going to be listened to or understood.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

[Wm via gnucash-devel]

On 07/03/2019 20:03, Adrien Monteleone wrote:

Derek,

I don’t disagree with your assessments of what certainly *can* (and maybe even, 
more often than not) be specific to a book rather than a user. I was thinking 
more along the lines of what someone *might* most likely want to carry over 
across multiple books. For example, I keep books for a few entities. Everything 
is in USD. (except for my personal book which has a smattering of left over 
currency from travels and some bullion I track as currency) I have no need for 
other currencies, and likely never will. At the least, I’d want to start books 
for a new entity, should one arise, with that same default currency in my 
reports. (simple enough since the default book currency is also the default 
report currency)

But I might also like to never show zero balance amounts or the corresponding 
accounts, and I might like to always roll up the sub account totals into the 
parent (since I set all parents as placeholders) and *not* show any duplicative 
’total’ lines.

These were the types of settings I was thinking of that someone might want to 
carry over across all books and maybe even all reports. (where applicable) The 
same might very well applied to financial periods.

Separating preferences for reports is, I suspect, more useful to a multi-user 
environment, which GnuCash does not support, but can be useful for a single 
user who keeps books for multiple entities that are all in the same 
jurisdiction and might well even use the same CPA. (and certainly have to file 
the same tax forms) They might even all follow a July-June fiscal year, for 
example.

It might be that this is too small of a use case, and the user’s setup work so 
light that the development burden is simply not worth the effort. (and I’m by 
no means advocating for more work for the team already, I’m just chiming in 
with my own user story to consider.)

I started a project to map out report preferences as part of a revamp of the 
tab content and I didn’t finish it. Perhaps completing that project will offer 
more insight. (and very likely allow me to discover that the present situation 
is optimal)


If you're doing accounting for yourself and never plan to use a 
different computer or operating system, know how to make backups and are 
infallible (think about that list) the 3.x model is fine.


OK, the infallibility is extreme but the 3.x file structure is just 
putting stuff all over the place without apparent thought.


There are really simple answers to this, they presume
===
don't do what Microsoft told you to do
===
especially since they don't do it themselves in their own products.
===


No one in their right mind puts reports that depend on exact information 
in another file in personal file space *AND* expects things to work when 
any of so many things change.


Another e.g. someone sets up a report, their PC has got a bit cluttered, 
they run a popular disk cleaner, result?  Report is AWOL.


--
Wm




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Transactions vs Splits

[Wm via gnucash-devel]

On 05/03/2019 12:57, David Cousens wrote:


I will get to testing the import of these transactions either tomorrow
morning or Thursday. I don't know yet whether it is possible to import them
in the multiline format with 2 or more splits yet.


Yes, it is possible but you have to be very careful when creating the 
export.



i am working slowly and
documenting everything i do so the developers have enough data to start
identifying where the problems are. 


I am impressed at your attention to detail, D

I think the problem is that once you've worked everything through in 
your beautifully crafted way you're going to reach the same conclusion 
as me.


At that point you should make a mug of tea, swig a beer or whatever is 
appropriate and conclude, the gnc people haven't got it right yet.



Once I understand it I will update the
wiki and then get the Help/Guide docs up to date for the next release.  I
suspect the bug fixes might not make it until the next release comes out


OK, the documentation theory works in two ways: the document can say 
what happens or the document can say what might happen.


We are free software so we can't do the latter, doing the former doesn't 
make sense either as it hasn't been done yet and may never be done.


What do you put in the wiki, Mr David?


If you are only exporting and importing transactions with 2 splits you
should be able to get it to work.


I can make it work with many splits but not many currencies or commodities


I would create a dummy transaction first
and export it, delete it in the book and then reimport it. 


NAUGHTY BOY!  you *know* gnc can't do the round trip of export and 
import.  It doesn't understand itself.



There is an
identified bug in the Export Transactions to CSV where transactions cannot
be exported on the date they are created so it is better to use Export
Transactions from Active Window to export a dummy transaction. Bob Fewel is
already working on a fix for this.


buglist ref please


I normally setup a test datafile to work with while exploring this rather
than use a real datafile so that other transactions don't complicate life.


If the test file I looked at earlier is an example, it is near perfect, 
I can see your thinking, actually, more importantly, I think other 
people can see your thinking.  I'm not the important person because I'm 
looking at another problem that you may not have thought about yet.  I 
do question documenting in such detail a problem that might change or 
not be there in a month or so, D.


I'm more interested in structural stuff at the moment.

--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] budget.scm augmented to show ytd

[Wm via gnucash-devel]

On 03/03/2019 12:14, Christopher Lam wrote:

for augmented budget report, which computes accumulated budget amounts
instead of periodic budget amounts.

https://github.com/christopherlam/gnucash/tree/maint-budget-refactor for
the whole repo

https://raw.githubusercontent.com/christopherlam/gnucash/maint-budget-refactor/gnucash/report/standard-reports/budget.scm
for the report (which may require a recent maint build)

adds a new option "YTD" which will display accumulated budget amounts (and
also accumulated budget less actuals)

the actuals remain period-specific.


You're presuming budget.scm is a good start

It *is* a good report, the problems are

 the code is overused in other reports

 the code presumes values that may not be true

 it is generally out of date unless you only have certain stuff

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] balance sheet review

[Wm via gnucash-devel]

balance-sheet.scm is a core accounting report in gnc, an essential in 
accounting as it allows the person presenting or viewing a report on a 
set of tx to show a full set of accounts or a subset.  It generally does 
sums well.


it is also core in that a number of other reports are built on top of 
it, i.e. if the basic balance sheet fails, the other reports fail too.


if the basic balance sheet fails we have a systemic collapse because of 
over reliance on code people no longer understand.


gnc has a second balance sheet (eguile on the menu) which is useful for 
auditing and similar uses but less useful for management reporting as 
the detail may be considered superfluous.


balance-sheet.scm no longer understands the level of detail it was 
originally expected to understand wrt currencies and commodities.


For emphasis: I don't say balance-sheet.scm is wrong, I love it and use 
it, I think it is a fantastic report; it just hasn't been maintained 
relative to the changing data it is reporting on ... the report no 
longer understands the inputs expected of it :(


read from the bottom up of https://bugs.gnucash.org/show_bug.cgi?id=797046
for some incomplete details

P.S. My political comment for today is that I think my own government 
consists of idiots that can't make up there minds, they're like children 
in a sand box.  The EU is the teacher or parent watching and waiting 
until the children stop arguing and decide what they want to do next.


--
Wm















___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] CSV Import Format

[Wm via gnucash-devel]

On 01/03/2019 22:42, Geert Janssens wrote:


Yes. The matcher should only be needed in the even more restricted case that
no transfer account is set.


In my experience the matcher is OK if you ignore it and understand the 
tx.  You should just import it and fix it by hand, presuming the 
importer is wrong.


Fact is gnc doesn't understand itself.

--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] CSV Import Format

[Wm via gnucash-devel]

On 01/03/2019 22:26, David Cousens wrote:

Geert,

I can feed you what I've done so far with the multiline, double currency
transaction. My apologies for taking so long. My wife is a poet and I'm the
publishing company these days. She handed me the latest book of poetry to
edit and typeset for printing along with a manuscript from another friend
just after I started on testing the importer.


I know I appear horrible here but I would like to read that poetry.


I made it back to the importer the day before yesterday. I have presumed the
multiline import is working for accounts in the same currency but haven't
actually tested it so far. 


It works for me.


It would have been logical to do that first.  I
have also ignored trading accounts so far either.


Trading accounts and importing are fine for me so long as you are specific.


I am counting on that
being largely dealt with if the multicurrency transactions work.


Nope.


The results so far are attached.
ExportImportCurrencyTransaction.odt



I can see what you're thinking and it isn't going to work, sir.

The round trip doesn't work.

in plain words:
gnc doesn't understand itself;
there are some basics you need to know about munging, essentially gnc is 
generous in what it allows to be stored in a file via the UI (I think 
this is a mistake as it allows new lines in a file format that depends 
on new lines and so on) and it doesn't allow those chars back in.


Now you know the round trip doesn't work, you know you need to fix a gnc 
 file to make it gnc compatible ... which sounds weird but is true.



I will continue and check out a multiline import to accounts with the same
currency with 2 or more splits.


I'm going over your work and I am impressed with your attention to detail.

in 1.4.1 (c) you say "Set date format to d-m-y to match locale" I think 
that is a wrong thing to do, it is all about the file and the round trip.


You also raise something that has been puzzling me, in your table under 
1.4.1 (d) I don't know what a withdrawal or deposit is relative to. 
Surely gnc should understand debits and credits and plus and minus.  I 
suppose it is possible someone will import tx to a CC or similar 
Liability account as the base for their finances but how likely is that?


Don't most people start with "I have" rather than "I'm fucked, I owe so 
much I'm going to use gnc to see how bad it is".


gnc people are generally positive, they're taking care of their finances.


One thing I am not clear on is whether or not the single line mode is meant
to be able to import a two split transaction when the split target
currencies are in the same currency without relying on the matcher. I am
presuming it is.


I don't know.

I can say the importer says it knows about commodities and doesn't.


My secondary aim is to learn enough to be able to put some documentation
together for the importer once I have some idea of what aspects are working.


I'll happily help with that.


Unfortunately I will have another break as I am off to Singapore in 2 weeks.
I will keep appending to the document and send you updates.


Have fun, eat some food for me :)

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] CSV Import Format

[Wm via gnucash-devel]

On 01/03/2019 11:39, Geert Janssens wrote:


I am aware multi-currency import is currently flawed. Having a detailed
overview of what fails/what extra is needed will help a lot in setting this
straight.


Meneer, the import and multi currency are like the boy with his thumb in 
a dyke being asked to meet a lovely girl from africa.


They look at each other, they like each other, but they have no way of 
communicating at the moment.


===

More seriously, Geert, and we have been through this before, what you 
need to do is a round trip.


Export a set of tx, import a set of tx, do you end up with the same thing?

gnc cannot do this yet.

why does this matter?

it means gnc doesn't understand itself, that is why it matters.

===

I know what happens next, I get personal emails

I am honest

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel