Re: Scope of GNUCash

[Mike or Penny Novack]

On 2/13/2018 9:49 PM, Wm via gnucash-devel wrote:


Why are you blaming the workers rather than the employers?

Why do you think a piece of software can help if you are shitting on 
your employees?


Mike, is this what you expected as a response?  Adrien appears to be a 
person that trusts no-one.


Welcome to the tacky politics of Trumpian merka :( 


Absolutely not, it is your response I find surprising. Problems do not 
arise just because employers are sh*tting on employees << this is NOT to 
say that some employers don't do exactly that >>


However an auditor should NOT approve use of a system without the sort 
of controls we are talking about, limiting access to those who have 
need, etc. One of the organizations where I am on committees, etc. (and 
have been on the board, and in the aftermath aiding the new treasurer 
recover) was hit by embezzlement by an office manager, from which a 
decade later we have not fully recovered in the financial sense*. 
Trusted with access to which she should not have been trusted.


* We agreed to a plea bargain "no jail" in exchange for repayment of 
what she stole (working over time) as if in jail we wouldn't have gotten 
even THAT back. But what she directly stole was only about half the 
damage as payments that should have  been made to governmental bodies 
weren't  and though those bodies  agreed to waive penalties still had to 
pay the interest on the amounts owed as well as the amounts. The bank 
involved agreed to lend us the money no interest for a number of years, 
but still had to be paid back. The total we had to make up close to a 
year's budget!

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

Re: Scope of GNUCash

[Mike or Penny Novack]

 I think I would love to sit down in a pub with the three of you 
(Wm, Adrien, and Mike). I think we could have such awesome 
semi-drunken discussions about the nature of life, the universe and 
everything!


I'm in London. Mike is in a Trump voting bit of Merka. Don't know 
where Adrien is and he shouldn't have to say.
 I am NOT in a "Trump voting bit of Merka". Not only in one of the 
"bluest" of the blue states but in a county of that state where on 
primary election day Bernie had an absolute majority of all votes cast 
(for all candidates in all parties). Here, people organized FCCPR 
(Franklin County Continuing the Political Revolution) BEFORE the general 
election. Not to oppose Trump (didn't know/expect he would win) but 
intended to try to keep Hilary's feet to the fire on the program. Of 
course the focus of FCCPR is now different.

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

Re: Scope of GNUCash

[Mike or Penny Novack]

On 2/13/2018 4:53 PM, Matt Graham wrote:

 I think I would love to sit down in a pub with the three of you (Wm, Adrien, 
and Mike). I think we could have such awesome semi-drunken discussions about 
the nature of life, the universe and everything!

I think you have basically answered my question, and I think we all basically 
agree on the rough direction things *should* go in (separate interacting 
packages). I’m just not sure how to help make it happen (I’m an enthusiastic 
amateur when it comes to programming). I think I’ll start by updating the 
budget part of the tuts and concept guide like I have promised elsewhere, and 
then start looking into how the C++ modules have been structured (to see what 
connection will be possible within the 3.0 releases).

Thanks and regards,
 Well of course I am not an amateur, it is how I used to make my 
living. But I can't help out with program design/coding unless/until I 
can get bandwidth here a home < unwilling to cut down enough large trees 
to get a "window" for satellite >


But besides being a senior systems analyst (programs) also a senior 
analyst (business -- the part that comes before)


A comment on the third part --- HOW the process of feeds and their 
reception is handled. That  can be deferred for now and at the 
beginning  can assume manual because whether "job scheduling" is 
possible is more or less OS dependent. For example, I haven't a clue how 
for Windows could have a job submit (other jobs), tell whether other 
jobs were running or had completed and if so, whether successfully, etc. 
That I knew very well how to do this under MVS/XA (a mainframe OS) and 
am pretty sure I could figure it out for a 'nix is besides the point.


Remember (an important point) a feed can FAIL. Not only once the program 
tries to bring it in but it could have failed in "input editing". In the 
initial project phase we might better assume that a human is running 
these things and will not start the next step of the process until 
seeing that predecessor steps worked. How an automated system is stopped 
part way and resumed after a "fix" is a project in itself. I'm the sort 
of guy who used to get woken up in the middle of the night when the 
programmers on standby couldn't fix the problem.


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

Re: Scope of GNUCash

[Mike or Penny Novack]

On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote:



A couple of times I have noticed that people have said "That's not 
what GNUCash is for". It begs the question - where is it defined what 
GNUCash is and isn't for? The charter for GNUCash doesn't seem to 
ever been formalised.
There is a long term plan, we never write it down because people ask 
us about it :) Is it intended that people should establish a 
complementary but separate project for functionality they want, but is 
not included in GNUCash scope?


I don't see why not if that is what they want to do.


Since I have been one of the people arguing for "separation" (I think 
this is being misunderstood) I want to clarify the reasons and what I 
mean when I use the term.


a) I do NOT mean that needs to be a separate project. Could be part of a 
PACKAGE (even installed together) but not a single program.


b) The reason for separate "packages" that interact with each other 
rather than a single program (that a user is or is not allowed to use) 
is so that ONE "system" (interacting parts) can be used for all. Those 
people who are running "one man band" businesses do not see the problem, 
do not see why things like (proposed extensions) like "inventory", 
"point of sales", "payroll",  etc. cannot be PART of the "general 
ledger" program. Call these "one man band" users businesses of class A.


But there is another sort of business user, call these class B. They 
have employees, they have division of responsibility and authority. They 
may have need of safeguards. I am not meaning JUST businesses since even 
a larger non-profit (call these class C, they might have other needs 
too) might need safeguards making embezzlement more difficult.


These need separation. They need to be able to have people "log in and 
use" things like an inventory system or "point of sales" system WITHOUT 
being able to access "general ledger. Does not have to be a very large 
small business before it has people waiting on customers, stocking 
inventory, etc. These people need to be able to do their jobs without 
being able to access "general ledger".


c) A solution with separated subsystems that feed each other would 
satisfy the needs of these entities (class B and C) while at the same 
time satisfy the needs of entities of class A. The reverse is not true 
AND not practical to "first build what would just work for class A and 
then modify that to work for classes B and C". That would be pretty much 
a complete rewrite.


d) However, the IS a common element for all the proposed additions (if 
separate). They need a way to FEED (send transactions to) general 
ledger. So general ledger (gnucash as it is) would need a way to accept 
feeds. And that includes a component to "input edit" feeds (make sure 
all the transactions coming in are valid, in balance, accounts they 
refer to exists, etc.) so that "general ledger" can reject (hopefully 
with meaningful explanations of the problems) a feed.


e) Not discussing at the present time feeds that might be required 
between these proposed extensions. For example, we would want a point of 
sales system to feed an inventory system. But things like that would not 
be "in common". Likewise not yet discussing safeguards (if a feed was 
not accepted, how is the system producing this feed temporarily blocked 
from adding to it. However I will say that to start, these systems 
should be designed to work "asynchronous batch" and only later consider 
expanding to supporting "real time update". Again this is a matter of 
"would work for all" while small entities could not safely make the 
assumption that all parts are up << and even some VERY LARGE entities do 
batch feed to general ledger --- I worked for the 43rd? largest 
"financial >>


Michael D Novack





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

Re: Future allocated money, aka Envelope Budgeting

[Mike or Penny Novack]

On 2/2/2018 7:04 AM, Wm via gnucash-devel wrote:

On 31/01/2018 16:09, Christopher Lam wrote:
Hi Matt- I thought this should move to the devel list, because of 
technical details, and this discussion will be very speculative.


I had a thought about how envelope budgeting could work: "divide your 
paycheck into separate envelopes for different purposes".


A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
transactions. And (f)rozen I believe is unused. Let's create a new 
type - (b)udget. But the balances are handled differently.
I disagree that the time is yet ripe for this discussion to be on the 
developer's list. It should be there only AFTER the "what is wanted" has 
been fully defined from the user perspective. The reason some of you 
think the time IS ripe is that you are missing some of the potential 
complexities of the behavior desired << you are considering only the 
special case where the amounts are equal >>  That I can see "special 
case" is that although I don't use "envelope budgeting" I frequently am 
dealing with an analogous situation where the amounts are sometimes 
equal and sometimes not*.


To see this limiting the context of "envelope budgeting" we need to 
realize that there are two types of envelope budgeting, strict << CAN'T 
use more than what is in an envelope >> and less strict where if an 
expenditure DOES use more than what is left in an  envelope the 
remaining portion comes from some other envelope of general funds. I 
contend that this IS the real situation that most people using "envelope 
budgeting" face. Yes, you may have allocated a certain amount for the 
envelope for "dining out" or other discretionary activity BUT if the 
envelope say for "gasoline" doesn't contain enough to fill the tank you 
are likely to decide to skip going out for dinner rather than give up 
driving.


I am suggesting that IN GENERAL going to use manual adjustment/choices 
so the call to automate premature unless can deal with those issues.


Michael D Novack

* Examples from my world (accounting for non-profits)
 The organization has a fund for "zero turn mower for orchard Y". 
The fund has built up to a balance of $2400 by the time the mower is 
purchased for $2700. All the funds in the special account are used plus 
$300 of general funds.


 The organization sells tee shirts as a fund raiser. For 
non-profits, gross sales and cost of goods sold are line items on the 
990/990-EZ. So the sale of a tee shirt is a debit to cash, a credit to 
gross sales, a debit to cost of goods sold, and a credit to tee shirt 
inventory << but presumably the latter two amounts are less than the 
first two or would not be making a "profit" >>


 And yes, I am able to do a "two side split" transaction, but even 
for me might be quicker/easier to do it in two simple transactions.

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

Re: Fw: VAT Call for Software developers

[Mike or Penny Novack]

Uh ... Putting my "business analyst" hat on I see nothing there which 
says WHAT data needs to be transmitted to them digitally.


This discussion has seemed to be making the assumption that gnucash 
would need to be sending it's "books" to them digitally which is NOT the 
same thing as saying that some reports, filings, etc. must be sent to 
them digitally << perhaps they get exported and then something else 
sends them >>


For example here I might do an electronic FILING using data produced by 
gnucash to supply the numbers that get filled in during the electronic 
filing process. But gnucash is not doing the electronic filing.


I think, before involving coding developers we need that information so 
that "business" level developers can determine what the REQUIREMENTS are.


Michael D Novack

PS: In my working days, sometimes wore one of those hats and sometimes 
the other.




On 8/17/2017 8:47 AM, Mike Evans wrote:

I just received this from HMRC.

Begin forwarded message:

Date: Thu, 17 Aug 2017 10:46:57 +
From: 
To: 
Subject: VAT Call for Software developers


Dear All,

I writing to tell you about a conference call that has been arranged for 
11:00am on 05 September 2017.

You may be aware that the Government has proposed that businesses with a 
turnover above the VAT threshold (currently £85,000) will be mandated to keep 
digital records and submit data to HMRC through its secure API platform 
service. The changes will take place from April 2019 for VAT.

Current plans are to make the APIs available for private beta test in October 
2017 and we want to advise interested software vendors about our thinking as 
well as provide them with an early opportunity to raise any issues or 
questions. It will of course also help us identify if your company is 
considering developing or enhancing a VAT product to support the proposals.
We can then arrange to work with you going forward, providing the usual 
technical assistance and other support needed to prepare for the pilot, from 
April 18 and  in readiness for the changes being mandated from April 2019.

   *   Only businesses with a turnover above the VAT threshold will have to 
keep digital records and only for VAT purposes. They will only need to do so 
from 2019.
   *   Other businesses will be able to file digitally on a voluntary basis for 
both VAT and Income Tax and NICs

Our current development schedule is as follows

   1.  October 2017 - private beta (API testing) with interested software 
vendors
   2.  April 2018 - public beta (pilot) data submission for VAT purposes (MVP 
to include unincorporated businesses); we will be inviting business volunteers 
throughout the year, anticipating that early adopters will already be using 
software and therefore likely to already be your customers. These will include 
both Tax Agents, their clients as well as unrepresented VAT businesses.
   3.  From April 2019 - data submission for VAT purposes (that is all 
VAT-registered businesses whether the business is unincorporated or not); 
Mandated for VAT registered businesses with a turnover above the VAT threshold, 
but all VAT registered businesses can use the service.

Please let me know if you intend to join the call so I can make the necessary 
arrangements. Please send your reply to this email no later than 17:00 on  24th 
August 2017.


Kind Regards

Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - Software 
Developers Collaboration -  Software Developers Support Team (SDST) | 2nd 
Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 8AA

The information in this e-mail and any attachments is confidential and may be 
subject to legal professional privilege. Unless you are the intended recipient 
or his/her representative you are not authorised to, and must not, read, copy, 
distribute, use or retain this message or any part of it. If you are not the 
intended recipient, please notify the sender immediately.

HM Revenue & Customs computer systems will be monitored and communications 
carried on them recorded, to secure the effective operation of the system and for 
lawful purposes.

The Commissioners for HM Revenue and Customs are not liable for any personal 
views of the sender.

This e-mail may have been intercepted and its information altered.


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



--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide

[Mike or Penny Novack]

On 7/4/2016 9:54 AM, John Ralls wrote:
Read the original letter again. He's asking about copying parts of the 
Tutorial and Concepts Guide, which is published under the GNU Free 
Documentation License, or GFDL. That's separate from the program's 
copyrights and licenses. Regards, John Ralls . 


Yes of course, he could not do THAT, actually incorporate it. I was 
responding to what appeared to be a broader interpretation of what he 
could not do. That's because I can see how he could accomplish (much, 
probably all) of what he says he wants to do without being in 
non-compliance.


Michael D Novack



Michael D Novack

--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide

[Mike or Penny Novack]

On 7/3/2016 6:05 PM, Chris Lyttle wrote:

I agree with John, as long as it keeps with the requirements of the GFDL, which 
means the work is available under the same license, I have no objection.
Uh, I am not one of the developers but am old enough to have been able 
to follow the original "free software" discussions. My opinion?


I think an awful lot of people are interpreting "derivative work" in a 
sense never intended. If there is some free software X, and somebody 
writes a book "How to make good use of X" or "X for Dummies" that is NOT 
a "derivative work" << they would have to, of course, not simply 
incorporate any documentation/help provided with the software >> Or 
suppose the developers had NOT created a "manual" or a "user guide". 
Somebody could write either/both of those and would not be a "derivative 
work".


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

Re: Recommendations on Coding programs

[Mike or Penny Novack]

On 10/17/2015 7:06 PM, Matt Graham wrote:

G’day all,

Now that I finally have myself set up to be able to view, edit and test the 
gnucash sources, I have come across the limitation of using text editors (using 
nano at the moment...) to code. Can anyone recommend a good program for doing 
coding for Gnucash? I’m mainly looking at the C side of things rather than 
guile, but a program that can do multiple types of code would be useful. 
Preferably ones that are supported on both windows and linux.

Cheers,

Matt G
Well during several decades writing software for a living, I wrote* a 
few hundred thousand lines of code without a language sensitive editor. 
But since these are now readily available, I strongly recommend you use 
one. In any 'nix operating system this is no problem at all, since the 
standard library of utilities will give you a choice of them.


Under Windows you probably have a choice of at least some of these. Many 
decades back a friend sent me a copy of xemacs for Windows, so I know 
that one existed at least that far back << I was using it just to be 
able to do LISP under Windows >>


Michael D Novack

* I don't mean I entered that many keystroke by keystroke! Folks who are 
experienced at the trade usually know where to find "useful chunks" and 
have decent personal libraries from which chunks perhaps as big as 
hundreds of lines can be grabbed and used with just a few key changes.

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

Re: Suggested (and Requested) Feature

[Mike or Penny Novack]

On 2/12/2015 10:26 AM, Neal Lithwick wrote:

Hi


I would love to migrate over to this program but I have one problem (so
far). I need to have the ability to set a Starting Balance for the balance
sheet items as I am not starting anew but migrating over from Money Smith.
Since every transaction needs to be reconciled, I would have to go back 7
years and enter each transaction to get this to work (Money Smith does not
have a file format compatible with GnuCash migration requirements).

  Any chance you might consider adding this feature to this program?

  Neal
The only time you would need to do THAT is if Money Smith no longer 
worked. Normal in a situation like this, especially where close to the 
start of the year, is to continue to use Money Smith for years 2014 
and before (in case you need to refer to that data, for example, doing 
your 2014 taxes) but using gnucash for 2015 and forward. You would do 
this by 


In Money Smith produce a Balance Sheet report for 12/31/14 (end of 
2014). I am assuming that Money Smith has at least that capability. 
Print that out unless you have multiple terminal capability or the next 
step will drive you crazy. You will probably also want a PL Report so 
you see the various income and Expense Accounts you had under Money Smith.


Now use THIS data to create your chart of accounts under gnucash. Don't 
for the moment bother about opening balances (let them all be zero). It 
will make you open the books transaction cleaner and you will have a 
chance to see that you have the chart of accounts the way you want it 
before actually entering data.


Make a copy of this file! (in case you have an accident with the opening 
transaction(s). Read the documentation on splits. I recommend that 
that you use TWO opening transactions because a two way split is tricky 
and you are new to gnucash. If you have no liabilities (unlikely, but of 
course possible) you'd only have one transaction anyway.


Now look at that Balance Sheet. Let's say you will do assets first. You 
can date the opening transaction 12/31/14 and then it won't show up on 
your 2015 reports but that is up to you. The easiest way to do the split 
is to start in equity where you credit the amount total assets and 
then hit split. Chance the debit amount to the amount of the first asset 
account and specify the account. On to the next and repeat until all are 
done. There should be nothing left as Imbalance. Now do the same for 
your liabilities, again starting in equity as a debit, split, and now 
all the liability accounts.


At this point I'd run a Balance Sheet in gnucash. Compare with the one 
from Money Smith. You are now at the beginning of 2015.


Now you enter all your transactions from Jan 1st 2015 to present (a 
month and a half of data, not seven years). When done, run Balance 
Sheets from both programs (for that end date), Money Smith's PL for 
Jan 1, 2015 to that end date and gnucash's Income Statement for the same 
time interval. Everything should match up.


If it does, you have a choice. You can consider it done and just use 
gnucash, or you can have a test period for a while using both until you 
are confident with gnucash.


Michael D Novack

PS: You CAN of course specify opening balances as you create the 
accounts. But that just makes a whole bunch of opening transactions 
instead of the two or one. And I don't know what date would get assigned.



.

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

Re: Apportioning GST in the account register

[Mike or Penny Novack]

Steven Patrick wrote:



The GnuCash invoicing process does this automatically for larger businesses, 
but many smaller businesses use only cash book records and need to be able to 
automatically calculate and record GST in bank account transactions.  Because 
it is already being done in the invoicing process, it would seem logical it can 
be done in the bank account process.

Well let me put my analyst hat on to see what additional problems might 
be there.


Not bank account. What might be needed here is an account type 
designation (for accounts otherwise simply assets) which for the moment 
I will call GST figuring accounts. Would have to be treated as asset 
accounts for balance sheet purposes.


In other words, might have to be more general than bank account. I 
don't know how your small business or organization does it but the 
organizations I keep books for do not  necessarily make daily deposits 
at the bank. So there would be an undeposited cash account used 
because it is possible that the payments were received in one accounting 
period but deposited in another  maybe your country is different, but 
over here its when the money gets to you, not when you get around to 
depositing it, that counts for cash basis accounting 


However I really think you overestimate the ease for which this can be 
easily automated, possibly because sales tax computations are much 
simply in your jurisdiction than in some of the ones with which I am 
familiar. For example, in MA assuming the business is a small supermarket

1) The bottle of laundry detergent is taxed.
2) The small box of donuts to be taken home is not.
3) The small box of donuts and coffee eaten in the store while going 
over the sale list are taxed, but a different rate than the laundry 
detergent.
In other words, over here in some jurisdictions things aren't simply 
taxed or not taxed, but possibly taxed at different rates.


Might I suggest something? Maybe what is missing isn't this feature you 
see as missing but an entire  point of sales system and it is the 
output of that system which enters the accounting package -- also 
typically feeds the inventory system, also missing. Note that these 
are not normally PART of the accounting package. Some commercial 
products are a complete SET of packages, accounting, inventory, point of 
sales, etc. In cases like this it is a business decision of the vendor 
of such packages which jurisdictions to support and which to ignore (too 
small to be enough potential customers to compensate us for tailoring a 
version for their specific needs).


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

Re: Apportioning GST in the account register

[Mike or Penny Novack]

  The way the current Gnucash customer invoice interface works with 
options for Taxable? and Tax Included? is perfect for their needs, 
as long as it can be implemented in a normal cheque account register.  
Some transactions would be taxable and others not.


I am happy to do the development work and release it under GPL, but 
just need some assistance in homing in on the appropriate source files.


I really do not comprehend how people think this could be automated.

If I walk into Wilsons (a local independent department store, does 
carry high end stuff at excellent prices for the quality) and purchase a 
number of items and pay at checkout with one check:


1) Eight  pairs of slacks at $40  - $320  (not taxable in 
this jurisdiction)
2) A fancy new winter coat with fur trimmed collar at $310  TAXABLE -- 
although clothing isn't taxable in this jurisdiction luxury clothing 
is; any  items costing over X dollars. I am saying X because can't 
expect another jurisdiction that has this policy to be using the same X. 
Note that the slacks weren't' taxed because in this jurisdiction that X 
is on a per item basis.

3) A set of pots and pans $95 --- $95 taxable
4) A small box of buns to be taken home and eaten there --- $4 not 
taxed, food
5) A small box of buns $4 to be eaten along with our coffee $2  so $6 
and this is subject to the tax as meals and is treated different than 
food.


Look, I can enter this manually into gnucash from the receipt which will 
spell out the amount that was tax. But I can't imagine gnucash having 
code to automate for THIS specific jurisdiction, especially if you 
consider that if this were at a store 20 miles to the North or 30 miles 
to the NE (as the crow flies) or 50 miles to the W or 60 miles to the S 
would have been in different jurisdictions with different sales tax 
rules (no sales tax in the one 30 miles to the NE).


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

Re: backend encryption / security

[Mike or Penny Novack]

The developers are generally agreed that we are NOT interested in this.

 


  (b) although I will probably
manage to code the open and save routines, I'm not sure I will not get
stuck somewhere, in which case it will either remain as an unfinished
project, or I will need some help from somebody more experienced.
   



I think we would help you if you get stuck, but I would recommend
instead that security/encryption should be done by a tool that is
designed to do security/encryption, and GnuCash should remain its own
core competency:  accounting.

 


Your thoughts?
   

Yes I have some thoughts. Would it not be far better to simply provide 
instructions for how to install, set up, and use software that provides 
for an encrypted partition/disk? Or rather, refer people to a site 
offering such software and our part of it just how to arrange that (once 
the encrypted disk, partition, directory, exists) the gnucash data would 
be stored there.


That would not deal with the while in RAM but would address the logs 
not being encrypted since these are created in the same directory the 
main data file is in.


Michael D Novack

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

Re: [Bug 710873] New Tax Declaration Info Report - multi-national, multi-purpose (private, business, ...)

[Mike or Penny Novack]

Perhaps totally underestimating the scope of the problem.

For example, in the US there are 50 states, perhaps half of which have a 
sales tax. The problem isn't just that the rates would all be different 
but also that to what they apply (or not) would be different* and you'd 
need in addition a way to waive sales tax (for example, this customer is 
a non-profit that has filed a copy their exemption certificate with 
you). That's just for ONE country.


For doing this automated, leave to the folks (if any) trying to develop 
a point of sales system  (that would feed an accounting system like 
gnucash with the transaction already properly split).


Michael

* You might want an example of complexity? I am in Massachusetts. We 
have a sales tax but (in this state) it does not apply to items of 
clothing below a certain cost. If I bought a fancy coat for $300 it 
would be taxable. If I bought four dress pants at $80 per pair even 
though the total for those pair $320 that would not be taxable. If I 
went to a supermarket and bought various items of food (for home 
consumption), a bottle of laundry soap, and while there from the deli 
dept a sandwich to eat while in the store the food isn't taxed, the soap 
and the sandwich are.


  And proper calculation of sales tax amounts isn't to compute the tax 
individually on each item but to total up the taxables and compute the 
tax on that (like many states with sales tax the tax is rounded *up* to 
the nearest penny so if figured individually would average one cent more 
per item rather only rounding up once on the total). But I am far from 
certain all states work it that way.




Carsten Rinke wrote:


Hi Frank,

thanks for your comments. As I am not an accountant and also not 
familiar with business taxation there are a couple of questions to 
your comments - maybe even very basic ones.


First the most general question:
I am not sure if I should read a message like this is not a good 
idea from your comments, because it is colliding with other already 
ongoing work.
My general goal is to have a common framework for taxation that can be 
used for all (ok, let's say most) tax countries and tax types. The 
setup shall be adjustable per country.
My hope is that the work already done for Germany can be 
combined/merged with this. I volunteer to do the merging but I 
probably need some help for that (once I have reached that point).


My question: Do you agree or disagree that my approach can also be 
used for your purposes?


Other questions and comments I have inserted below.

Gruss,
Carsten



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

Re: Approval for Introducing Your Software in Japanese PC magazine

[Mike or Penny Novack]

 


The rules say that you have to distribute all of the source code, but I think 
that it's become
pretty common to rely on the fact that the sources are all readily available 
via the net. You'll
probably want to get an OK from your lawyers.
   



The rules say that if you make changes to the code, you must make those changes 
to the source available under the same license.

If you don't make changes to the code, for example you just publish the 
binaries as provided, then just link back to the source here.

The source doesn't need to be on the same physical medium, but does need to be 
available. An example might be binaries on an operating system CD, with source 
available via the operating system website.

 

Except technically it the source code doesn't have to be available 
somewhere. I know many projects figure let them seek out and download 
BUT the language really is for good copy on medium. Remember, while 
perhaps most people live where they have broadband right in their homes 
most places do not (think land area, not people density). When I need 
something as large as operating system software that means paying a 
download service to get it burned to medium for me. And BTW, the free 
software project WOULD be allowed to charge the usual and customary 
amount for doing just that. So not a violation of the license to say 
send us five bucks and we give you the source code on medium. The 
software itself might be provided only that way too; they ARE allowed to 
charge for that. They do NOT have to provide a free as in free beer 
download from a website because the license language was developed well 
before those days. By the language of the license you don't necessarily 
have to put the source on the same medium but have to be willing to 
produce medium with the source upon request so unless no space on the 
medium, why not put it there.


On the first part -- that is NOT so simple because there are strongly 
differing interpretations to what is meant by make changes to the 
code. New code could UTILIZE (make calls of) existing binaries without 
actually changing them. New code (or other material) could serve 
functions related to what some existing binary does. In other words, the 
extent to which non-free work may legitimately utilize free software 
without being captured is a matter of much dispute.


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

Re: GNUCash

[Mike or Penny Novack]

Jasper,

First of all, there are no fees to use this software (or to get 
help using it). Donations are always welcome.


Second, you posted to the developers list. Questions such as you 
have just asked should be on the users list, gnucash-u...@gnucash.org


Third, I'll answer some of those questions anyway.

a) security --- not WITHIN the software itself as any such password 
security would be an illusion of security. What operating system do you 
use? Most currently in use allow users of the computer (assuming a 
shared computer) to have ALL  of their data secure from other users who 
do not have supervisor rights on that computer. Silly to password the 
data of each application separately when ALL the data of all you 
applications can be protected by one log in password.
b) difference from Quickbooks? Well first of all you pay a hefty price 
for Quickbooks.
c) I doubt there is an agency in Kenya but you don't need that to be 
able to download software. I won't go further about how since exactly 
how you would go about it depends on bandwidth (for example, although I 
am in the US I live in a rural area without broadband so can't download 
anything as large as software at my house).

d) We can advise you by email. Cheaper than international phone calls, yes?

Michael D Novack, FLMI


Hello !!

Please i need to know from u when i do install your software in my
computer, if theirs any additional fee to give to you so that i may
stay in the Accounting Room.  Also i want to know all about the
software, and if theirs some security for this software eg putting
password and security for the i mean to protect from other staff from
opening the files.Please give me the different between your software
GNUCash and Quickbooks?  I want to inquire from you if you have an
agency here in Kenya who supplies your free software for GNUCash or
how can i get it, please to give your contact number so that i my call
you a day time contact.

Yours
Jasper

From Kenya

___
 



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

Re: Scam site selling GNUCash

[Mike or Penny Novack]

Can't really recall whether or not they included the required license terms, 
but I guess they did.

I did uninstall that particular version and re-install the version from your 
official download source so hopefully that should be safe unless he has done 
something a little more devious.

Thanks for getting back to me.

Fraser

 

The free in free software refers to the license terms, not the cost. 
Anybody is allowed to give it to you for free as in free beer but 
nobody is required to do that and what MUST be free is the source code, 
not the compiled run exec ready to run on your computer under your 
favorite operating system.


A little history? The free software movement goes back before the 
internet as we know it. The people taking part in this discussion* 
weren't necessarily envisioning free as in free beer but software for 
the price of a book (and being academics, that might be a pricey book). 
There was no distribution of software via downloads from websites in 
those days. They envisioned free meaning for the reasonable and 
customary price of a good copy on standard medium (which these days 
would be CD or DVD). And I repeat, that was the SOURCE CODE.


Anybody could distribute compiled versions for whatever they wanted to 
charge for these with the idea being that they couldn't charge an 
unreasonable amount for the service or somebody else would step in to 
undercut them.


BTW --- That reported 35 pounds IS unreasonable. Living out here beyond 
broadband I have a good idea what the services charge that will download 
what you want and deliver it to you on disk. Yes I can put a laptop into 
the car and drive into a town where public access to bandwidth is 
available for free but the gallon+ of gas and the hour round trip 
driving time isn't free. Most of the services charge $5-10 (but certain 
standard requests for which they get lots of requests may be much 
cheaper as are bulk orders). Might I humbly suggest that this (and 
other) free software projects make available their distributions on 
medium for a fee. That IS allowed and some of us would choose that way 
of getting software.


Michael D Novack

* Sorry, my records of the discussions (exchanges of position papers, 
etc.) was lost in a house fire. I can't quote from it.


  


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

Re: Equity Account Postings - a bug or a misunderstanding?

[Mike or Penny Novack]

(this should have been on the user list)

I would handle this with an asset account (as opposed to equity).

It is very like what for me is a common situation. I live in a rural 
area, don't drive to town where the bank is every day. In fact, we try 
to combine trips so only go to town once or twice a week. But I receive 
mail six days a week.


Let's say the organization receives a check from national (our share of 
membership dues and any extra donations made to our chapter but 
processed through national). I record this into an asset account 
undeposited funds split to the income accounts membership and 
unrestricted donations. When at some later date I get to town and can 
make a deposit a second transaction transferring between the asset 
accounts checking (or savings) and undeposited funds.


Isn't your situation like that? This money you are due as of some date 
is an asset, but not yet deposited into the bank account where will be 
going.


Michael


Philip Haynes wrote:


Hi All,
I have a situation where I am making some postings in gnucash and the
resulting values are making no sense to me at all (from an accounting
perspective). The lack of sense is such that I am leaning towards a
bug explanation rather than a user problem (I know, a dangerous
assumption).

So here we go;

I have a mutual fund account that regularly (monthly) sells a number
of units in order to generate a cash amount.
The date of the transaction for selling the funds is one date and
the date at which the resulting money is credited to my account is a
separate date, usually two days later.
Both of these accounts are owned by a Trust and so the set of accounts
I am managing with gnucash are the accounts for the Trust.
I load both these data sets from different QIF files from different
insitutions, the sell from my fund manager and the cash receipt from
my bank.

As a result of this date inconvenience I have to post the amount from
the sale of the funds somewhere until I am able to link it to the
bank transaction receiving the cash.

Here is where the problem occurs;

My thought is that this posting should be to an equity account, so I
have one, but when I post the proceeds of the sale of the Fund to this
account it shows a decrease in equity which does not seem right to me.
This transaction, a sell from a commodity (the fund) should give me an
increase in equity. It's all ok insofar as when I then post the funds
to the bank account from this equity account they appear as a funds
increase in my bank account, its just that I don't see why this
process should decrease the equity of my Trust.

This thought is reinforced by the fact that if I post it to a
liability account instead, I get a decrease in liability which makes
perfect sense in the same way that an increase in equity make sense.

I am running stable (r17949M built 2009-09-14) on unbuntu.

Am I making an error or is the equity account getting the sign of the
postings reversed?

Thanks,
Philip


 



--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Cashflow reports

[Mike or Penny Novack]

Alan Duffell wrote:


Hi there,

Excuse the probably stupid question as I'm new to Gnucash!

I'm using the software at a small charity and we'd like to know the following:

1) Is it possible to produce monthly cashflow reports, e.g. with months on the 
x axis and income/expenditure/balance on the y axis?

2) Is it possible to produce reports that are compliant with UK company law, 
charity law (Statement of Required Practices) and accounting law, and can this 
in turn be made compliant with accruals accounting?

Many thanks for your time,

Alan Duffell.

 


Respecify the question? Are you asking:
1) Can GnuCash generate reports containing the data from which such 
finished reports could then be produced?

Yes
2) Can GnuCash produce the reports in the proper format to be filed with 
the appropriate authorities with no further editing?

No
3) Would any accountant expect 1 or 2?
Ours expects 1.

If you think about 2 for just a moment it should immediately become 
clear that this would be a MASSIVE project dwarfing all the rest of 
GnuCash. There are an awful lot of jurisdictions and each could want a 
slightly different format for reports. For example, the non-profit for 
which I am treasurer has to file with the US Federal government and the 
Commonwealth of Massachusetts. Do you imagine that Mass wants exactly 
the same thing as the Feds? Or that any of our other 49 states want the 
same as Mass?


Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Close books trashes Income Statement and Net Income on Balance Sheet

[Mike or Penny Novack]

You can disagree all you want, but you're still wrong. ;) The GAAP
method to close the books is to create a fake date (or 'invalid' date)
that sits between the periods.  That's what most accountants and
large-scale accounting programs do.  You might dislike it, but it's the
way the world works.

Maybe needs more explanation? The reason many of you see fake is that 
you assumed that a fiscal date HAD to be a calendar date. Or where 
the same data as calendar date is used for fiscal date assumed that 
meant they had magically become the some thing.


The properties you NEED for fiscal dates:
a) Unique.
b) Ordered

Imagine the following rules:
a) The ID of a an ordinary fiscal date will be the calendar date. All 
fiscal transactions will occur on an ordinary fiscal date.
b) The ID of a special fiscal date will be the ID of the preceding 
(ordinary) fiscal date with a S appended. No fiscal transactions 
allowed on a special fiscal date, just things like closing the books.
c) Only transactions occurring on ordinary fiscal dates are considered 
in reports.


Michael D. Novack, FLMI


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

Re: Close books trashes Income Statement and Net Income on Balance Sheet

[Mike or Penny Novack]

JT Morée wrote:


I realize the close books issue has been dealt with for years but I'm coming up 
empty on searching for this particular aspect.  Please tell me if there is 
another way to fix this issue that I'm not seeing.
 

As I have mentioned before (more than once) the way around this is to 
use a date for the close the books transactions which is after the 
last date of the previous fiscal period and before the first date of the 
current fiscal period (and to allow no other fiscal transactions on that 
date). That's what I do for the books of the organization of which I am 
treasurer -- our fiscal year ends Dec 31st and I allow no outside 
transactions on Jan 1st so I can assign that date to closing (and then 
the next year starts Jan 2nd -- the 1st isn't IN any year).


Back when I did this for a living, easier. In house software so we could 
make it do what we wanted and calendar allowed for the special date 
year end. In other words, we could insert a date in between two (real) 
calendar dates that fell after the first but before the second. Think of 
it as a December 32 or a Jan 0


Not an easy problem for GnuCash (no way of knowing what the user's 
fiscal year might be)


Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GNUCash for non profits

[Mike or Penny Novack]

Frank H. Ellenberger wrote:


Am Wednesday 13 January 2010 23:01:07 schrieb Mike or Penny Novack:
 


As treasurer of a 501(c)3 ...
   



I fear, outside of USA not much people know the meanig of 501(c)3.

Best wishes
Frank



 

Sorry --- that's ONE type of non-profit here in the US. Donations to it 
are tax deductible. There are other types of non-profits donations to 
which would also be tax deductible but following different rules. There 
are also types of non-profits which don't pay taxes but donations to 
which are not tax deductible.


As anywhere else, tax laws are quite complicated. I'm sure outside the 
US you have different rules and different designations. Here the names 
in some cases derive from the section of the tax code (501(c)3 an 
example of that) and in others form acronyms (PAC and example of that).


Michael

--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: GNUCash for non profits

[Mike or Penny Novack]

Phuntsok Rapden wrote:


Hello, can GnuCash be used by non-profit organizations if the account
descriptions are modified? Thank you so much for this wonderful product.

   


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

 

As treasurer of a 501(c)3 I use GnuCash to keep the organization's 
books. I am a bit puzzled by the if account descriptions are modified. 
For the books themselves I can't see what modifications would be 
required. For the reports as generated you could either use custom 
reports (more trouble than worthy) or do as is normally done, after 
exporting the reports, edit the titles, etc. as your heart desires.


In other words, the raw reports aren't what you would pass out to the 
board of directors (or file with governmental agencies) but the finished 
reports. In our case we produce the Income Statement and Balance 
Sheet reports out of GnuCash but these are just the DATA used for the 
finished product annual report according to GAAP for non-profits. That's 
going to be produced under the control of some editor anyway, so you 
simply change the names, etc. then.


Michael

--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Looking for help with the reporting feature

[Mike or Penny Novack]

Karey Broach wrote:



I would like to know if there is the ability to change the reporting
criteria from a year at a time to monthly?

I would like to be able to see monthly reports as well as yearly reports?  


Is there any documentation on creating new reports or are the ones that are
created the only ones that we can use.


Ted Broach

 

This sort of question should really be asked on the user's list. You 
need to know how to set the date ranges on the reports? As well as alter 
all sorts of other ways in which the reports can be changed? Edit = 
Report Options   Take a look at all the things you can change and then 
get back to us with questions.


Michael











 




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




--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Model of report

[Mike or Penny Novack]

Phil Longstaff wrote:


At some point, I want to modify some of the reports (balance sheet/income 
statement especially) to allow multiple dates or time periods to be specified, 
resulting in multiple columns.  However, I'm busy with too much else right now.

Phil
 


THAT would be welcome, Phil.

The only reason I have not done this (I'm a retired senior systems 
analyst) is that the board member who takes the data I supply out of 
GnuCash and uses that to prepare a financial statement in proper GAAP 
format as done for non-profits is that he told me not to bother --- the 
process involves adding footnotes for everything that needs an 
explanatory note as well as some stock text and he uses his favorite 
document processing app for that.


However, being able to prepare a report giving the current year an 
prior year in parallel (what is standard for a non-profit) would be handy.


The other side of that coin is that accounts would not necessarily match 
1:1 and you need to give some thought what you plan doing in that 
situation.  The account might not have existed in the prior time period 
or might not still exist (no longer applicable -- would be cumbersome 
carrying on the report accounts that are obsolete and/or accounts that 
only rarely have activity always showing with zero balance).


Michale D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: transaction corrections

[Mike or Penny Novack]

Gnucash is a usable program.  It however lacks something *very basic 
and important.*  Any professional accounting program must not allow 
the editing or deleting of entered transactions.   All corrections 
must be made by an additional correction entry which will refer to the 
original erroneous transaction.


Sincerely,
Jay Seidler


I agree with what the others have said, that there is little likelihood 
of a version to do this. But .


a) There is nothing preventing professional standards bookkeeping 
procedures. In other words, instead of deleting an erroneous entry, 
stet, and make a correcting entry. Then the audit trail indicates 
exactly what was done.


b) The locked  version security would be more apparent than real. I am 
speaking as a retired senior analyst with a few decades experience in 
the cypher mines of one of the world's largest financials. It would be 
VERY difficult to construct a system where somebody like myself could 
not alter the data. Keep in mind not restricted to working WITHIN the 
application to do that and it's not just the data file used by the 
application that must be hard to manipulate but the logs/backup from 
which it might be reloaded.


Besides, let's be honest here. In the real world whether a couple 
correcting entries made or the transactions edited depends on the 
VOLUME. Suppose some less than happy morning it was discovered that 
because of a program change 50,000 transactions with errors were 
processed. No, did not print them out and have a bevy of worker bees sit 
at their terminals for a couple weeks entering correction transactions. 
We'd simply fix the program, rerun it so we now had all correct 
transactions, and then rerun general ledger for that night (recreating 
the files, replacing the bad file with the good, in my mind at least is 
just a form of editing).


BTW --- the b I described (to edit that way) does NOT require any 
knowledge of programming. Just the ability to do a restore to the 
state before you made the transaction you want to edit out and then you 
re-enter all that day's transactions without the bad one.


Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: sorting of transactions within day

[Mike or Penny Novack]

marcus.wolsc...@googlemail.com wrote:


Hello,

what sorting is used for the transactions
within a single day?
I would like to make sure the transactions
get the same sorting-order they have on
the bank-account to make comparing both
easier for the user.
Could this be done my modifying the time
in the postedDate or should I look somewhere
else?


Marcus
 

You would first have to look at what rule does the bank follow with of 
course no expectation that any two banks would be following the same 
rule. That should be enough to convince you that nothing done at the 
Gnucash end could guarantee the same order except the ability to define 
a complex set of rules for order.


When choosing a bank, an important consideration is whether for 
transactions on the same date they process debits before credits or 
credits before debits as that can influence whether or not you get hit 
with overdraft penalty charges or even have checks bounce for 
insufficient funds. You MIGHT find a bank which used time of day but I 
have never encountered any. Take a look at the fine print and you will 
probably see things like deposits will be credited as of the close of 
business on the day made or even deposits made after X time of day  
will be credited as of the following business day (the last is the only 
place I have seen time of day taken into consideration).


Keep in mind that for checks coming back to the bank, their arrival and 
entry into the bank's records is random with respect to when written and 
entered in GnuCash. The only thing that would be the same in both places 
is the check number and the date written.


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

Re: Suggestions of improvements

[Mike or Penny Novack]

The other thing is, we want to write a new invoice (or improve the ones which 
are there), so that they have more information (which is needed to create a 
legal invoice in germany and some other useful information like bank 
connection of the business, logo, ...). But actually we don't find the 
documentation of the Gnucash-Report-API. So maybe someone can lead us to that 
location.


So I hope that my/our suggestions of improvements are found useful and good!

Joachim Langenbach
 



Perhaps worthy of a comment explaining how this is done in the world of 
large scale commerce before seeing the lack of this sort of facility in 
GnuCash as a defect.


I'm retired now after several decades in the cypher mines at one of 
the world's largest financials. Having designed and written such 
software I know how we did it. The application did NOT do that stuff 
(the logo, etc -- think of the fixed background of the invoice.). 
There were two ways that might be done, one pass or two.


In the two pass method, pre-printed stock. In other words, one program 
controlled printing of background on the paper and then this paper stock 
was used for the run creating the invoices filling in the variable data 
fed by the application. This would probably be the simplest solution for 
the small business user of GnuCash (in Germany or wherever) and how this 
paper gets printed with the background outside the scope of something 
like GnuCash. What you would do is load the right (per-printed) paper 
into the printer before printing off a batch of invoices.


In the one pass method, there would be a powerful printer which had its 
own printer control language, commands for which could be inserted 
into the program and then passed along with the variable data. A 
solution like that which would depend upon the specific printer hardware 
and call for printers MUCH more powerful and expensive than used by any 
small business (except perhaps those whose business WAS printing) and is 
obviously out of the question for GnuCash. I'm just mentioning it so 
folks who know that one pass exists don't fault me for suggesting that 
the proper solution for small businesses is two pass.


So Joachim -- for your legal in Germany invoices you would take the 
text/image editing program of your choice and work up the background 
printing for your invoice, the logo, company address and contact info, 
the bank info, etc. and print up a supply of paper with that printed on 
it. You then batch the production of invoices coming out of GnuCash 
and run them through the printer after having loaded this special 
invoice paper. Notice that this lets you get pretty fancy. For 
example, potentially the background could be calling for capabilities of 
a printer you did not have in house as you could have a printing 
specialist shop do that for you.


Michael

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

Re: Support for multiple account types for an account placeholder

[Mike or Penny Novack]

I am quite sure I have read a discussion a while ago about the
constraint of not being able to set more than one account type for an
account. The thing is that the standard BAS account plan, which is being
used in Sweden, has a top account (placeholder) which holds both equity
and liabilities. Its child accounts are split into accounts of either
the types equity or liabilities.

Could this support be implemented without too much work? If you think
it seems to be an OK idea but are not interested in implementing it, I
can maybe do it, provided I get some help.

Thanks,

Mikael

  

Question (because never perform major surgery when a minor fix might work)

Is this just something affecting how balance sheet type reports would 
appear?(and maybe some other reports) The fundamental equation of 
bookkeeping A = L + E remains the same, only with BAS there is this top 
account assigned to be the root of the L + E tree? But is it otherwise 
USED for anything? If not, then implementation might require nothing 
more than creating the BAS Style Balance Sheet (and other reports that 
would be different in BAS --- and if this root account has a non 
constant name, filling that in can be done at the edit-option level).

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

Re: Gnucash suggestion

[Mike or Penny Novack]

Stuart Andrews wrote:

Dear Gnucash team,

I've been happily using your software since the end of last year, having
ditched Windows completely.  I was using Microsoft Money before.

Can I make a suggestion for possible inclusion in the future?  It would
save me a lot of time reviewing scheduled transactions if the entry date
could be set to the first/last business day of the month, or first
Monday etc. rather than setting a date.  I see there is an option to
enter a transaction on the first day of the month but this is the
absolute first day, not first weekday.

It's fantastic software though, very powerful and apart from that
suggestion it does everything I could need.  Many thanks for the hard
work.
  

As a person who among other things did calendar programs to control 
task running let me explain that while Stuart's suggestion is a good 
starting point the problem is really MUCH more complex. Adding just one 
more option that will please few not the best way to proceed.

1) Business day is NOT well defined. Sorry Stuart, but that's just the 
way things are in this world of ours. We humans do not agree on 
calendars, do not agree what's a work day and what a holiday. Even 
within a country there may be regional differences (like in the US, 
state holidays). And we're not all in the same country.

2) The only thing guaranteed to work IS specified dates. Might allow 
three year's of calendar data (file) so users can establish business 
days for last year, this year, and next year  (and in the new year drop 
the oldest and add a new one). Of course that depends upon just how much 
look ahead and look back you need.

3) And yes, I designed (and wrote) the very fancy automated calendar 
program* still used by one of the world's largest financials that 
allows specification by rules. But that still requires calendar data 
 sometimes when work falls behind (or at expected busy times) you DO 
run a business cycle on a weekend, etc. So a general rule might be 
Saturday is not a business day subject to the specific override but 
February 6th is The point is that I know very well just how much work a 
comprehensive fits everybody (can be user modified to fit) system 
would be, how many months of my time to design/write such a thing. WAY 
out of scope for a volunteer project like this.
   It also would NOT be all that easy for end users to learn how to use. 
Has to TRAIN people how to set up the next year's calendar of events.

Michael D Novack

* replacing the old control system where all data had to be entered 
manually and mistakes were common even with the procedure that one 
person did each day's data and one person checked.


There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Two Income Statement patches: Assets Value

[Mike or Penny Novack]

Andrew Sackville-West wrote:

I don't want to rain on your parade, but in my opinion this is the
wrong thing to do. 

What would be better is to have a separate balance sheet report that
provides the delta over a time period. I don't begin to know how to do
that, but IMO, it is the proper thing to do. 

Allowing assets into an income statement flies in the face of any
accounting I've seen. Note that IANAA. 

A
  

I'm finally going to jump in here too. It has been very frustrating to 
be expected to answer basic accounting/bookkeeping questions being 
trated as what facility within GnuCash because the reality is that 
like ANY accounting package, GnuCash can't help you with what should I 
be doing? sort of questions.

OK -- Andrew is completely correct here. However different Canadian tax 
laws the basic accounting wouldn't be different. What accounts and how 
reported, yes.

I believe the confusion is between the individual reports produced by 
GnuCash and the report (complete financial statement) needed for 
reporting purposes. The USUAL process is that the individual reports are 
generated, think of them as data and turned over to the accountant who 
uses them to produce the finished product. That will at least be an 
Income Statement and a Balance Sheet but might include other 
specialized reports depending on what the complete financial report must 
contain (cash flow might be important, distinguishing between 
unrestricted and restricted funds might be important, for a 501c3 
distinguishing the source of funds, qualified or unqualified might 
be important).

For example  one of the organizations for which I keep the books is 
a 501c3 and the standard (GAAP = generally accepted accounting 
principles) format for presenting reports to the board of directors (and 
also used for tax purposes) would be 
1) Income statements (not called that in the finished product as 
non-profit accounting uses different langauge) for the current period 
side by side with that of the previous period.
2) Balance sheets for the ends of the two periods (same as the start and 
end of the current) also side by side.
3) Anything requiring explanation annotated (like footnotes, but using 
the endnote format)
4) Any special accounting procedures specified in a general note (say 
what fixed assets subject to depreciation and by what rule)

I asked the accounting type person to whom I was turning over the data 
(two Income Statements and two Balance Sheets as produced by GnuCash) if 
I should try to create a custom report to put all that together (I've 
written a few hundred thousand lines of financial system code in my day, 
so COULD do it). He said definitely not, that this was the accountant's 
task, that every accountant would have his or her own favorite editor, 
and as produced by the proposed custom report, would STILL need to be 
edited at least to insert the annotation so savings of effort minimal. 
In other words, to produce a finished product would be more than a 
custom report. Would need an EDITOR that took the custom report as 
input and allowed the accoutant to then edit it.

That's a LOT of work for very little gain. Suitable editors already 
exist for accountants to use and all that would be saved is the 
copy/paste of data. If there was only ONE finished product format 
required perhaps worth while but that's not the case here. What a formal 
report for a 510c3 looks like not necessarily the same as for some other 
form of organization.

Back to the original question which was really how do I properly keep 
the books to reflect depreciation and what information must I be able 
to report for my jurisdiction. That's NOT a GnuCash question. That's a 
basic business accounting question in this case with emphasis on 
Canadian tax law. It simply isn't fair to expect the user guide of 
GnuCash to cover such a wide range of user needs from hand to mouth 
cash flow personal budgeting to acounting for a 510c3. A work 
covering such a range would be a massive tome with each end user 
interested in just a tiny portion AND total beginners at accounting 
might get inot worse trouble if wandering into the wrong sections.

Frédéric, my best advice to you is go to a library where they have a 
number of accounting texts, look in the index in the back of each for 
depreciation, then see how good the section of this book is covering 
that topic, and select the best book to learn from. To me (also) the 
very thought that you picture the depreciation accounting (as opposed 
to the total depreciation expense transactions) would show up in the 
Inccome Statement tells me that you are starting at the very beginning 
of this subject. This is double entry bookkeeping. ONE side of the 
transactions recording depreciation ends up as an expense; the OTHER 
side of those transactions is what affects the balance remaining of each 
fixed asset being depreciated (and will affect the Balance Sheet).

Michael D Novack, FLMI

PS -- 

Re: Two Income Statement patches: Assets Value

[Mike or Penny Novack]

Frédéric

Actually, it was not.  But I can certainly understand how it could seem
that way to you.

My question/need was actually technical: how much money went into asset
account X last year?  [*]

This need comes as a result of two things:

* Under Canadian law, the half-year convention applies to everything.

* Most (if not all) of my assets are actually small things, regrouped
  into generic accounts.  I'll be damned to create a specific account
  for each USB stick I've ever purchased; they all get dumped into
  Computer Equipment.

Taken separately, these two issues wouldn't be a problem at all;
applying the half-year rule to an account that only has one asset is
easy as pie.  But when you've got years worth of stuff in there, you
really need to know how much was bought/sold this year, ie. how much
falls under the half-year rule.

(I guess most businesses don't give a rat's ass about their USB sticks,
or simply cheat and declare them as expenses.  Lucky them.  g)
  

Again, I am not an accountant. But I think if you look at a standard 
accounting text you WILL see how to do this. I have to account for fixed 
assets and their depreciation and so I know how to do that (though at 
the moment, no fixed assets*). Depending on your tax laws, you might 
even have to have different depreciation schedules for fixed assets 
purchased in the same year and so more than one account under parent for 
fixed assets purchased in year X (or half year X -- here in the US 
don't need to get any finer than by year).

So no, you would (presumably) not have to have an account for each USB 
stick purchased in period . Just one account for fixed assets purchased 
in period X subject to the same depreciation schedule).

And BTW -- you are right that businesses might be immediately expensing 
 small items. They simply need to make that clear in their accounting 
procedures.  Most  places tax laws are reasonable in that regard. A 
mechanical pencil (or USB stick) might in fact last several years but 
small items of that sort allowed to be treated as consumables and 
immediately expensed as office supplies. Normally you go through the 
whole fixed assets rigamarole only when you are required to:
1) Your tax laws won't let you treat this item as a consumable.
2) The item has a substantial value and so not carrying it on the 
balance sheet distorts the financial position.
One or both of these and you do all that work of accounting for the 
fixed asset and its gradual conversion to an expense over time via 
depreciation.

OK -- I will try to describe what I would be doing. Our rule* is 
anything under $400 is expensed and depreciation over three years. The 
tree for fixed assets would look like ..

Fixed assets
  ...
  ..(dead accounts that are fully depreciated --- but 
they MIGHT be needed later -- sale of fully depreciated assset is a gain)
  Purchased in 2006
  Purchased in 2007
  Purchased in 2008
  Purchased in 2009

Now take that account Purchased in 2006. It would contain transactions 
for all items purchased in 2006. I would put those in a sub account and 
have a second subaccount for the depreciation of those items because 
easier math that way.
  Purchased in 2006
  Items
  Depreciation
During 2006 each fixed asset pruchase was a transaction to the Items 
account. After the end of 2006 no more transactions add any items so 
that total becomes the basis for fixed assets purchased in 2006. At the 
end of 2006, 2007, and 2008 a depreciation transaction for 1/3 of that 
balance is entered (and as an depreciation expense for that year, the 
other side of the transaction). So after the third year the balance will 
be zero, fully depreciated. If later something gets sold, will be 
income (gain from disposal of fully depreciated asset) or maybe an 
expense (had to pay somebody to cart it away).

Old fashioned pen and ink on paper would maybe just have the one ledger 
account (as the debit side total remains constant after end of year). 
But with GnuCash and similar software you are shown balance and that's 
why I would prefer the subaccount method.

Michael D Novack

* We are allowed to set a reasonable de minimis amount and also 
allowed to set an arbitrary depreciation time period. But we're a 
non-profit in the US and your rules could be quite different. As has 
come up on this list before, including the text of the statement of 
practices we use is part of our formal finacial report.

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Enhancement request: 'Native' importing of '.CSV' files

[Mike or Penny Novack]

I just want to point out what .cvs support entails for the benefit of 
those for whom this isn't immediately obvious.

.cvs refers to the low level format of the data -- just that the file of 
data consists of records? delineated by newline and the records 
consist of fields delineated by commas. But there is nothing defining 
what data is in these fields and just as important, in what order.

That means that an import from .cvs functionality requires more than 
just being able to accept data separated by commas. It needs a facility 
where the user gets to enter information specifying which fields to be 
included (and which possibly ignored) and in what order. That's the 
substantial component of a project to import from .cvs. Especially 
since without a guide for the user on using* this field specification 
component likely to be beyond the abilities of many end users.

Michael D. Novack, FLMI


* keep in mind that it's not SIMPLY using (how to specify the skipping 
fields and reordering fields. The end user is unlikely to know 
(initially) what are the required fields and their order.

PS -- in it's simplest form, .cvs is an example of positional; rather 
than keyword data. However it is entirely possible that keyword type 
data could be stored in commas separated format (alternate fields are 
field identifier followed by field data). If the data is of that 
sort you don't need a field skipping and field reordering facility (a 
program can use the field identifiers to determine the fields it wants 
to put where regardless of order). However that isn't strictly speaking 
cvs. data in spite of the way delineated by commas. In other words, 
.cvs data and .cvs file don't mean EXACTLY the same thing.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Request: Enhancement in Use of Account Codes

[Mike or Penny Novack]

My understanding for the reason of the current situation is that there 
is nobody fitting all of the following description.

1) can code
2) has time to contribute code
3) business user
4) lives in Europe

I fit 3 and 4.  I currently think that trying to get gnucash into shape 
for business users is unlikely to happen even in the medium term.  I use 
gnucash when it is the right tool and thank Phil for providing us with 
the SQL backend which then allows me to access the accounting data for 
reporting and manipulation from other SQL tools.  AFAICS, it currently 
is the only sane way to handle this.
  

IMHO you do not want a person who meets all those criteria. And the 
additional criteria can design (not the same as coding) and can 
test/has time to test. Those criteria define the TEAM you want to 
assemble. Some of the hats can be worn by the same person but it is 
actually a rather bad idea if one person is doing the whole thing.

Unless a program hangs or loops, if what it is SUPPOSED to do has not 
been properly specified, then it must be doing the right thing 
(whatever behavior it exhibits is what it does, there is no outside 
criteria of rightness.

The business USER in conjunction with a BUSINESS ANALYST constructs the 
requirements (definition of what is needed). Alone the USER is 
unlikely to consider all the rare situations since from an end user 
point of view, what a system usually does is what is in their mind.
The SYSTEM ANALYST in conjunction with the BUSINESS ANALYST designs the 
system.
The PROGRAMMER in conjunction with the SYSTEM S ANALYST implements the 
program.
The TESTERS in conjunction with the PROGRAMMER test the system according 
to the test plans devised by the BUSINESS ANALYST and SYSTEMS ANALYST 
and the USER usually is involved too (but in MY work, I would have been 
embarrassed if the user ever got to see something not working correctly; 
that final sign off should be a formality of the other pros have done 
their jobs).

I do not mean to imply it has to be formal titles or different people -- 
but these are hats, many of which I have worn, sometimes several on 
the same project but that's not easy or the safest thing to do. While 
wearing one hat must somehow keep from considering the problem too much 
from the other person's point of view (when designing, should NOT be 
thinking how am I going to code that?). Only to the extent necessary 
(when coding, always thinking what test data/process will be necessary 
to test every bit of logic -- perhaps building the test processes at the 
same time as the main program).

Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Request: Enhancement in Use of Account Codes

[Mike or Penny Novack]

Rolf Leggewie wrote:

Mike or Penny Novack wrote:
  

IMHO you do not want a person who meets all those criteria.



Mike, thank you for your reply.

While your theoretical description may be correct, I think I have 
accurately summed up why in reality gnucash is not moving forward for 
European business users.  That is, there is no person who can actually 
code with time on their hands, an interest and an understanding of where 
gnucash currently falls short.

A number of bugs were recently closed as wontfix with the idea of 
support for European/German business users is out of scope for 
gnucash.  That is because all people concerned are well aware that it 
won't happen anytime soon inside gnucash and thus it may be better to 
pursue solutions outside of gnucash bolted on to the gnucash data.

  

Well first of all, bolted on MIGHT be the appropriate solution. That 
is precisely the reason for my theoretical description of the 
development process.

A bug is a program not doing what it is SUPPOSED to do (doing 
something wrongly). Failure to do something that was never part of the 
specifications is not a bug, it's a user request for development work. 
But to have jumped ahead from the this is what I need to THIS 
application should be changed to provide that functionality is an 
error. First the end users and the business analysts decide what is 
needed. Then decisions are made how to best fill that need.

I faced this directly as I am both an end user and somebody quite 
capable of designing/coding --- all aspects of a project from inital 
user requirements analysis through final acceptance testing* -- though 
as I have already said, not great if wearing too many of the hats. In my 
case it was getting from the reports produced by GnuCash (income-expense 
statements, balance sheets, etc.) to the final form of the 
organizational financial statements as would be presented to the board 
of directors and filed with governmental agencies. I was advised NOT to 
try to add finished form, that no accountant would want that, that 
they would simply take the reports as generated to be the data they then 
used to fill in a proper GAAP format report. And that they normally do 
this by hand.

BUT -- let's say that I was going to do that. Would it end up as part 
of GnuCash? (part of the same executable). Probably not. It would 
probably be a stand alone application which accepted as input the 
reports as produced by GnuCash plus some fixed test files but functioned 
more or less as and editor allowing the accountant to insert the 
necessary notes and texts. That, by the way, was why I was told don't 
bother. Any accountant already has preferences as to which editor 
application he or she prefers to use and all of them allow the pasting 
in of the GnuCash reports and the fixed descriptive texts as a starting 
point.

Point is, I don't have to live in Europe to design/code what you need. 
You assemble the European end users and agree on a specification of what 
you need done, what your business requirements are. Then we see 
whether what you need is for GnuCash to do this for you, some stand 
alone system that takes feeds from GnuCash (that can still be part of 
the GnuCash PROJECT), or something completely independent. Understand? 
Simply saying GnuCash doesn't do what we need done is not enough to 
get my attention. If I'm helping you with the requirements phase then 
I would probably rule myself out as a resource for later phases because 
wearing too many of those hats clouds judgement -- you need more 
distance from some of the decisions.

The business requirements phase is NOT a trival part of the process.

Michael D. Novack, FLMI

* I'm a retired very senior sort of analyst who used to do this stuff 
for one of the world's largest financials
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Request: Enhancement in Use of Account Codes

[Mike or Penny Novack]

  I am not sure your experiences, the analytical approach, division of labor 
 (hats as you described them) which I would consider best practice in any kind 
 of business project can easily be transferred to gnucash or any other FOSS 
 project.
  

  The only real difference is that it's voluntary. Nobody paying the 
bills and so nobody in a position to say do thus and so. I agree with 
you very much that I do not see standard software development process 
being used in FOSS. Could that the the reason for some of the problems?

  User expectations? My sense is that users do not seem to understand 
their role in the process. When I was PAID to do this sort of work, I 
might have had to tolerate a user who wasn't willing at first to do more 
than tell me it's broken, fix it. In other words, my job to help this 
user and so would devote as much time in as many meetings as necessary 
to tease out what the users ACTUALLY need till there was a clear 
understanding of what the darned thing was SUPPOSED to do. I certainly 
wouldn't bother to take a look at the code until that was out of the way.

   Unless there is a clear understanding of what the program is supposed 
to be doing DIFFERENTLY, it ain't broke. It's working perfectly well 
(doing whatever it does) right now. I'm an analyst, not a mind reader, 
can't guess what it is that the users really want/need (often NOT what 
they initially say that they want/need).

I've never seen you around before, but you seem to have valuable 
knowledge.  What is it that you are suggesting and what role do you see 
for yourself in that?  How long have you actually been following what is 
going on with gnucash development?

Almost two years. Had a house fire November 2006 which took out the 
hardware and software on which the organizational books were kept. At 
the same time as reconstructing the books the old fashioned way on 
paper, began a parallel with GnuCash, and recommended adoption of this 
software instead of replacing the commercial package. In terms of 
standard bookkeeping (auto posting ledger) I've never had the slightest 
problem with GnuCash except for the annoyance of not being able to set 
up properly under all legal Windows* user names.

   I've been watching both the user and developer lists since, and 
consider that my professional expertise should be available to the 
project. I've done a few hundred thousand lines of code in my day, all 
in financial applications. Never worked in any of the languages 
GnuCash is in but that's not really relevant (not when you are fluent 
writing in half a dozen and can read most anything -- pretty fast to add 
one more).

   Anyway, I don't see the real bar to getting things done to be lack of 
programmer availability as much as the lack of user commitment to do 
their part of the process. I've seen lots of complaints doesn't do this 
or that but not one presentation of a business spec of what a group 
of users would want differently. Complaints that the the programming 
developers aren't doing their job misunderstands the problem. They 
aren't being given a clearly defined proposal.

   Thus --- asking please have GnuCash create the xyz report such that 
it meets county C's reporting requirements is NOT how you properly 
frame a request to a programmer. It's not the programmer's job to look 
up the regs of country CD and find sample reports meeting these regs, 
etc. That's the user's job, assisted by the business analyst (who 
might not initially know the answers but knows how to tease those out of 
the users). Very important to have all the loose ends defined, because 
in reality, perhaps 80% of the coding of any real life software project 
is dealing with the exceptional conditions the end user doesn't even 
think of as potentially existing (unitl the business analyst begins 
asking questons).

Michael D Novack, FLMI


* That I might be perfectly happy running under a 'nix OS besides the 
point. Only one other board member of one organization and none on the 
boards of any of the others would, so software caapble of running under 
Windows a must. Might not always be treasurer.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: String lengths in the SQL backend

[Mike or Penny Novack]

.
I'd have to look back, but I think Derek's reply was the only one.  I'd like 
to open the topic again, because of Rolf's problem.  Can anyone think of a 
reason that account code size limit cannot be reduced to a smaller value (e.g. 
32)?   Will anyone ever enter an account code longer than that?

Phil
  

ROFLOL --- as soon as you set a limit that a user could bump into, 
somebody will. Best to look at this from a human engineering 
perspective. There's no obvious reason why somebody someday couldn't 
possibly want to use account codes larger than 32. But there are reasons 
to decide that nobody would ever use ones as large  256 -- because no 
screen wide enough to enter something like that on a single line.

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

Re: import/export bounty

[Mike or Penny Novack]

Hence, if *you* want to invest money and expect results from it, comparable to 
a classic project, you will have to find a project manager first, or 
alternatively you will have to put yourself into that position. 
(Incidentally, your resume indicates you might actually be rather qualified 
for picking up such a job yourself.) Without a person who acts like a project 
manager I wouldn't expect any short-term results that meet your explained 
needs.

Regards,

Christian
  

Hits the nail on the head.

Let's say that wit enough nagging folks convince me to take on being an 
active developer. Well there are three things that would hold me back. I 
have the time (retired) and the experience (a few hundred thousand lines 
of code in my day) and while I am unfamiliar with the code base, I 
rather suspect that GnuCash is fairly small compared to the size of 
applications I had to learn about in the past (50-500K lines, multiple 
languages). BUT (some big buts)

1) I would need help/mentoring getting started working in an unfamiliar 
environment (Windows on small computers) and at the moment don't have 
tools installed -- no complier, language context sensitive editor, etc. 
I might not even know all the languages but that's not as big a deal as 
it sounds since once you've learned half a dozen, what's one more.

2) I wouldn't even consider it if required to wear multiple hats. If 
you've ever done this in the real world you know that it is a very bad 
idea if the person doing the analysis/coding/testing ALSO is the person 
setting the priorities of what SHOULD be done first (project manager) or 
the persons deciding what the application SHOULD be doing and deciding 
if it is or not (end user testers).

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

Re: how to create balance sheet as on date ...

[Mike or Penny Novack]

samar shailendra wrote:

I am a new user of gnucash ...

I am entering transactions in gnucash account for last two years(eg. 2006-07
and 2007-08) .. now I want to generate the balance sheet for the
transactions of last year only(i.e. 2006-07).. Can I do that , if yes how ?
  

You first generate the balance sheet. Then you use Edit=Options which 
brings you to menus where you can change things about your report.

You can change things like whether accounts with zero balance show, how 
subtotals for groupings of accounts show, and specific to your case, the 
effective date of the report.



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

Re: RFC2: Date/Time proposal

[Mike or Penny Novack]

  

I believe several users have expressed that they do not want a time written
to their data file if they never actually entered one. That's one of the
things I am proposing to support with this proposal. Saving defaulted
transaction times would mean that when you read the file back in, you
wouldn't know which times were user-entered and which times were defaulted.


Not EXACTLY.

Or at least it wasn't what I was asking about.

What happens now, what happens given the proposal, if the user does not 
enter a transaction time? WHAT time gets entered? (what value is used 
for the time component and if not a constant value, upon what does it 
depend?)

My question is related to the stability of sort operations (a sort is 
stable if/f when a set of records is sorted by field X, the relative 
order of records which have the same value in field X is the same after 
the sort as before).

Michael


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

Re: time_t - When does it break?

[Mike or Penny Novack]

Ian Lewis wrote:

I kind of understand where Stuart is going with this. There are a lot
of parallels. The currency example is one. From a programming
perspective, storing strings without an encoding is another.
Essentially to know the real value you need to know another piece of
metadata.

Stuart,
I'm curious though, and maybe you can fill me in, is the reason that
the timestamp is important that, from an accounting standpoint, the
transaction occurred on the day (in the timezone) that it was entered
into the register? .

Not exactly.

I believe (from my own experience) that what Stuart is trying to say is 
that for ordinary bookkeeping/accounting purposes transactions occur on 
a DATE. That for the legal purposes of when was payment received (so 
called constructive delivery) all that matters is the date. That a 
payment made on 07/18/08 is before any made on 07/19/08 but one made at 
0700 on 07/18/08 is NOT before one arriving at 0800 on 07/18/08

There may indeed by (other) purposes where the time is meaningful.

But just where is this time coming from? What is the source of this 
data? When I enter a transaction into GnuCash I have to specify a date 
-- the time component filled in for that date (when stored as time) 
comes from where? Remember, the real time at which the bookkeeper enters 
the transaction bears no relationship to the date of the transaction 
itself. Since NO time data was entered the only thing that would be 
correct coding was for the SAME (constant) time of local day to be used 
in all instances. If the time of day of the date upon which the 
bookkeeper enters the data is used that's dead wrong, implies assigning 
a before/after that has nothing to do wit the transactions themselves, 
just the order in which the bookkeeper pulled them from the stack.

Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: RFC: Timestamps/timezones proposal

[Mike or Penny Novack]

The key is that the register would display date,time, AND TIMEZONE.  The 
timezone lets the user recognize that ...
  


I am going to ask again.

On July 18th at 14:30 EST the bookkeeper enters a transaction involving 
accounts whose time zones are all also EST (in other words there will 
be NO time zone issue here) with a transaction date of July 15th.

I'll repeat to make that very clear. The date of the transaction is July 
15th. As is NORMAL the transaction is not entered in the books real 
time but entered at some later point in time when the bookkeeper gets 
around to it.

OK -- the question is -- what TIME is associated with that transaction 
in GnuCash? Why? In other words, since the bookkeeper never entered any 
effecitve time for the transaction (just a date) then where does that 
time come from? What is its meaning? That's why I would consider the 
time assigned to be random or meaningless (say the system assigned a 
constant time of day value --- zero bits of information). Yes of course, 
I would consider the time of day at which the bookkeeper happened to get 
around to it (if that is what gets used) a random time. Remember, just 
because the bookkeeper posts transaction A (effective July 15th) before 
posting transaction B (effective July 15th) doesn't mean transaction A 
took place before transaction B.

Michael

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: time_t - When does it break?

[Mike or Penny Novack]

As a retired pro who has debugged many date errors in my day I really 
have to side with Stuart here.

Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: average monthly report

[Mike or Penny Novack]

Can you explain me please what does submitting means here?
If you need a person who will say yes, I need it, I can be this 
person for sure.
But there will be no use from me if volunteering=programming - I have almost
no experience here.



  

However do not underestimate the need for end users in various phases. 
SIMPLY making a request isn't very likely to result in what the end 
users want even when the programming resources are available. End user 
input/cooperation is required for:

1) The REQUIREMENTS phase. Not just a roughly specified request but 
EXACTLY what is this feature supposed to do. Otherwise there is little 
chance that the end user's expectations and the programmer's 
understanding of those will match.
EXAMPLE (in this case)   what do you mean here by averaging 
and precisely what does that mean for budgeting purposes. Speaking as an 
experienced analyst who has spent decades trying to figure out what the 
client REALLY wants/needs I have some suspicions here. IMHO a budgeting 
process has to take into account not only will the averages be OK but 
that the CASH FLOW will remain positive throughout the period. If not, 
then this average feature would be useful only for the budgeting needs 
of organizations that can presume unspecified lines of credit. But note 
that even in this case having a cash flow issue affects the budgeted 
amounts (you have to pay interest on amounts borrowed to deal with cash 
flow issues, yes?).

2) DESIGN phase. The analyst will surely have all sorts of details 
questions that weren't settled in the requirements phase, little (or not 
so little) things that come up when doing the actual design.

Now the client can take a break until.

3) TESTING phase. The programmers test till there are no hangs and they 
THINK the new feature is doing what it is supposed to be doing. But it's 
the end users and their requirements that matter. However this user 
testing has to be cooperative with the programmers suggesting odd 
cases that the the clients wouldn't have likely thought of on their 
own. Natural for users to think only about the usual/common cases but in 
a real project, about 80% of the code is handling all the various 
oddball situations which can be expected only when the moon is in some 
odd phase (NOTE: for those of who enjoy the challenge, these are the 
fun bugs that appear but the program has worked just fine in production 
for ten years, why is it hanging now?)

SO --- I would say that any users making requests should be prepared to 
do THEIR part of this should programming resources agree to take on 
their request. As a potential resource, I will say loud and clear that 
any willingness on my part to code something would be conditional on 
the requester persons being willing to commit to their part.

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

Vista (progress? estimate?)

[Mike or Penny Novack]

I need to do some organizational planning but I am posting this here 
rather than the user list because of the nature of parts of this question.

Problem statement --- I am currently the Treasurer for a 501c3 but next 
year will have to take at least a one year hiatus (term limit bylaw). 
Which means I have to be able to turn this over to somebody else. I have 
the organizational books up under GnuCash and would like them to be able 
to remain under GnuCash. Currently running on our PERSONAL computer but 
that's part of the problem for turnover. There is a time limit issue on 
getting a reimbursement for the organizational computer lost in the fire.

1) What is the current Vista situation? If GnuCash still isn't Vista 
ready, anybody willing to give a time estimate on when they think the 
problem will have been solved? Please, I am not intending this as 
holding anybody's feet to the fire or hanging them for a bad guess -- I 
used to do this for a living and know how deliverable dates slip OR 
what gets delivered actually missing pieces. But I need a guesstimate 
in order to make other choices.

2) What is driving this is another time limit -- one involving 
reimbursement (replacement) insurance for what was lost in the fire. 
There are naturally some constraints (besides cost) but essentially I 
can buy an approximately ~550* device for ~150 (the already received 
depreciated current value of the destroyed device). The sad realities 
are..
  a) Nobody is very willing to house an extra desktop. They will want it 
on a laptop.
  b) There is ONE other director who would be willing to run Linux. I 
just can't make use something other than Windows a requirement for 
running for Treasurer.
  c) I can get a refurbished laptop under XP with adequate modern 
hardware to possibly be able to justify the decision. You need to 
understand that the problem is at
  this cost my choices in new laptops running XP is very limited. 
Remember -- for the rest of the board (minus one other person besides 
myself) the politics of free software irrelevant AND the 
cost issue not as relevant (Intuit won't -- but many vendors charge 
non-profits less and/or agencies give grants for purposes like all 
directors get the same version of MS Office).

 The point here is that I don't want to wage a fight that I don't 
have to (justify why I got a refurbished laptop rather than a new one 
for the same price!). I can hold off on action six months at least. 
That's why I am asking for a prediction. I also face the potential 
problem of my replacement NOT wanting a dedicated device but asking me 
to install GnuCash on their device. So we aren't talking about date when 
buildable on Vista but availability of a stable release.

Michael

* allowed to spend more -- essentially for any replacement device bought 
costing that mush or more get the maximum reimbursement of 400 so only 
paying cost-400 for the device

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Vista (progress? estimate?)

[Mike or Penny Novack]

Derek Atkins wrote:

 Um, I've heard no news that 2.2.4 doesn't work on Vista.  Does 2.2.4
 NOT work on vista?

That's why I am asking. I don't (thank goodness) have a Vista machine 
here at the moment. The last discussions about this problem were around 
October with the problem then not resolved (there was a work around, but 
not the sort of thing I could tell an 'end user to do). AFAIK there 
hasn't been an all fixed now posting.

I am just trying to be proactive. The replacement part of our 
insurance will reimburse for a number of machines (at various different 
amounts for each) so I have to figure out how best to juggle. I was able 
to get use of GnuCash approved (replacing QuickBooks Pro nonprofit -- 
more precisely NOT replacing this software post fire) but need to look 
ahead how to maintain that decision. I have board approval NOT to 
replace the machine dedicated to chapter financials under the assumption 
that anybody becoming treasurer would probably already have more 
machines in their house than room for (don't we all). But doing it that 
way means my being able to install the software on the new treasurer's 
machine and I can't specify must still be running XP (so if not OK on 
Vista by this Fall, I would get an inexpensive laptop running XP for 
dedicated)

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

Re: building gda-dev2 on windows XP Pro SP2

[Mike or Penny Novack]

 I haven't done much work on Gnucash on Linux or Windows but I was able 
 to get it to compile under Windows by following the instructions on 
 this page:

 http://wiki.gnucash.org/wiki/Windows

 There are a few manual steps and then a script that downloads and 
 installs a bunch of tools and then compiles the code.

 I still haven't figured out how to just compile the local code, the 
 default scripts seem to go out to the svn repository and pull down the 
 latest code every time.
 Anyone know anything about debugging Gnucash under windows?


I should have been more explicit about my situation?

I cannot do downloads here -- especially not downloads of unknown size. 
In other words, in need the sort of information that one gives to a 
download/burning service that I have them get me the software on CD or 
DVD that I can then install. It really isn't practical working it any 
other way (can't ever get a net data transfer much faster than 3000 
bytes/second over just a phone line).

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

Re: building gda-dev2 on windows XP Pro SP2

[Mike or Penny Novack]

Andreas,

I think we are getting somewhere

Please take a look at
http://svn.gnucash.org/trac/browser/gnucash/branches/gda-dev2/packaging/win32
  

 So I would want to get the compiler (and presumably including a 
link-editor) here?  This is achieved by using the mingw32/gcc compiler 
environment. Where do I go for that?

 Especially because of the time required to make the whole kit and 
caboodle, I would want to be able to compile and link edit individual 
components (and yes, my background is in that sort of environment where 
programmers/analysts were expected to be able to determine if their 
change was going to affect anything globally (remake the whole thing) or 
entirely local (recompile and relink just the altered component). That 
is of course just for TESTING as changes are developed.

Pre-compiled versions of emacs can be found
at ftp://ftp.gnu.org/gnu/emacs/windows/ (if you want to use miktex as
well, take a look at
http://www.gnu.org/software/auctex/download-for-windows.html )
  

 Thanks. Any chance there is a gvim equivalent for Windows? Or any 
other suggested language sensitive editors?

Additionally, you will want to use gdb as debugger, see
http://wiki.gnucash.org/wiki/Windows#Debugging_with_gdb .  I have
updated that page a little bit, but it probably needs more input from
those actively developing with Windows :-)
  

It might sound strange, but in practice been many decades since I 
ever  complied anything with debugging on (just knowing where the 
problem was sufficient for me to spot it -- so recompile with an 
assertion or two -- and again influenced by knowing that this sort of 
change HAD to be local and a recompile/relink of a single component 
fast). My bailiwick was applications ~500,000 lines (in 300 modules) 
running against databases whose compressed size was in gigabytes.

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: building gda-dev2 on windows XP Pro SP2

[Mike or Penny Novack]

Thanks everybody (keep up with suggestions)

I will probably want a C for Windows sort of book if such exists. Not 
how to program in general but how to interact with objects of type 
window. Any ideas? I have written some* C, but that was in a Linux 
environment and I wasn't (yet) interacting with GUI windows. Before 
trying to fix anything, I'll want to do a little practicing. Nobody ever 
paid me to write stuff for them in C, just picked it up (yet another 
language, easy once you know half a dozen) after retiring early post 
Y2K. All that stuff (hardware and software) lost in the Nov 2006 house 
fire. Keep in mind that we just got back into the house December and 
won't be making final decisions on equipment replacement till the 2 year 
cutoff next November so I won't have a machine under 'nix till then.

Michael



* Only a few thousand lines total, but including a fairly substantial 
project (2nd Lempel-Zev Universal Data Compression Algorithm -- a finite 
version so once the dictionary reached a defined limit, replacement of 
entires by RLU --- lots of practice with lists and queues). Programs to 
meet standards in how parameters entered, having help and about and 
stuff like that.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: building gda-dev2 on windows XP Pro SP2

[Mike or Penny Novack]

Related to getting started. (now that my post fire life is more or 
less back to normal -- sorry for the long delay)

I haven't ever done any work in the Windows environment before. Which 
means I don't have a set of development tools. Anybody willing to make 
some suggestions? What open source compliers. etc. and since LISP is 
involved, that too (is there such a thing as emacs for Windows?). I am 
also open to suggestions for books* (we lost about 2500 including all my 
computer science, math, etc.). Level? A retired senior systems analyst 
who has probably written a couple hundred thousand lines of code in my 
day but limited experience with small machines like personal computers.

If I am going to be of any use, time to get started.

Michael D Novack, FLMI

* I used to get by mainly with old ones (RK for C, etc.). So I don't 
know what's current, especially with regard to standards. I have till 
November with the insurance reimbursements.


-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: Setting date range in reports

[Mike or Penny Novack]

Al,
The problem is unclear documentation? I put it that way because 
obviously not adequate to get you to the right spot.

That's not customization and it is via options that you get to 
set things each time you run a report -- things like the date range, 
what subtotals you want to see, whether zero balance accounts are 
included, etc. But apparently you weren't helped to find the RIGHT 
options.

FIRST you run the desired report (balance sheet, income/expense 
statement, whatever)

NOW look at the Edit pull down menu and you should see a sub menu for 
Report Options. You use that to CHANGE the settings which apply to the 
open report and each time you OK/apply the change the report is altered 
according to what you just specified. When you are done, export/save the 
report (what I do).

I can't tell you how I figured out what to do, whether this was 
something I learned going through the tutorial or via help when in the 
context of creating a report or whether looking around and seeing h 
report options -- maybe that will do what I want. Was half a year ago.

Michael

I am running version 2.2.1 of gnucash as installed from the PCLinuxOS 
repository. There was no gnucash-docs file installed and none in the 
repository, so I came to gnucash.org/docs.phtml to consult the help 
manual there. I found the following entry there, and also in the help 
manual in an older system which is running gnucash 2.0.5:
5.4.3. To Customize Reports and Graphs

GnuCash reports have many options for customization. To access report 
options choose the Options button on the toolbar.

There is no button named Options that I can find on the toolbar of 
either version.

I looked at edit-preferences-Accounting Period to find where date 
ranges can be set. Changing the ranges here had no visible effect on the 
date ranges in several reports that I used for testing.

I am sorry if the problem is simply my bad comprehension, but perhaps 
others might have a similar problem trying to find the place to 
configure the date range for a report to use.  I am unable to tackle the 
task of correcting source and then compiling and installing it.
Regards and thanks for a great accounting package..
Al Hawley

  


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

Re: Feature request from German list: Disable editing of transactions

[Mike or Penny Novack]

my two cents

I think it would be wise to collect a precise definition of the formal 
requirements before making any design decisions.

   ABSOLUTELY -- determining requirements is the first step in design.

How about collecting translations of relevant sections of the actual laws in 
the wiki, to 
find the common denominator? 

   But that is overly optimistic. It is very unlikely that there will not be 
inconsistency in the requirements. What we will need is not so much a system 
(hard coded) that can satisfy all of them but PROCEDURES how to accomplish what 
is required under various conditions. I'll give a concrete example using the 
problem stated --- a POSSIBLE solution. 



You are right, closed books  and uneditable transactions seem to be tied 
closely together. I wonder whether that is enough though, in terms of 
requirements set by law in some countries. I think in Norway one must 
not be able to _make_ any transactions prior to the book closing date 
either.

On the other hand: I close my books manually every other month, in order 
to get the numbers for the VAT form. But occasionally I find an error in 
the previous period and then I correct that and the closing transaction, 
and send in a revision of the form if necessary. I am not sure how I am 
supposed to properly correct errors in previous periods if transactions 
are prohibited.
  

   Bastian -- you could, after the first closing and immediately 
preceding applying the freeze burn a copy of the file. Notice that I 
don't know whether the data indicating frozen as of X date would be 
kept in the books themselves or in some secondary file but it is data 
and will be in SOME file. In other words, the state immediately before 
the freeze can be saved and if necessary to later make changes (and then 
resubmit the tax reports) restored from this backup and a new final 
burned.

BTW --- the process I am using here (I'm Treasurer of a 501(c)3 ) is 
to recognize that NO software freeze could stop me from editing the data 
(remember -- I made my living designing software). So I burn TWO copies 
and give one of these to another party. In the event of legal questions 
these could be compared.

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

Re: testing the book zeroing code (maybe for backport?)

[Mike or Penny Novack]

On Feb 6, 2008, at 9:16 PM, David Reiser wrote:

  

Using Tim's approach, I have:
642 accounts
6423 transactions
and it took 4 minutes, 6 seconds to close the books.




1minute 46 seconds for a trial balance.
Dave
--
David Reiser
[EMAIL PROTECTED]
  

OK --- we seem to be seeing that test results are in the same 
ballpark. That to me would imply that the way close the books is done 
now isn't an urgent candidate for tuning. Probably it would be possible 
to cut its run time in half, but that wouldn't change the situation if 
your books contain many accounts/transactions will take a long time AND 
this is something one runs very rarely*.

BUT  I would suggest (both)
a) A progress bar, spinner, etc. -- something to let the user know task 
is active
b) A text message along the lines of May take substantial time 
according to the number of accounts/transactions. Comparable to the time 
required to produce a Trial Balance

Michael


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

Re: C commenting style?

[Mike or Penny Novack]

As a practical matter, depends on whether you are looking at that code 
with an editor that is language sensitive or not. Probably why seeing 
so many different styles.

For example -- take style 2
   Less keystrokes (a true RK tradition) and as long as you are using a 
language sensitive editor that knows C syntax the fact that the 
intermediate lines of a comment aren't marked is irrelevant (the entire 
comment is recognized and showing up in the COLOR assigned to comments 
-- clearly viable as such). BUT (and this is a big but) were you looking 
at or working on C code with an ordinary text editor this is a terrible 
style for you.

Michael


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

Re: Guile bug could affect Windows users

[Mike or Penny Novack]

To all Scheme/Guile developers:

Although the dirname and basename procedures are not currently used in
any GnuCash source code (.scm files), please be aware that these procedures
do not work properly in Guile 1.6.8 (the version recommended for GnuCash)
running on mingw. This affects those of us who have a Windows build
environment. If you are writing new Scheme code, I would suggest that these
procedures be avoided, at least for now.

I reported the bug on the Guile mailing list a few days ago, along with a
patch to fix it, but haven't heard anything back yet.
  

I am slightly confused here. Please correct which of my assumptions is 
wrong.

a) Guile is some sort of LISP dialect.
b) Two of its built in functions are incorrect (ones in the set of 
predefined functions and/or procedures)
c) We, more precisely some among us, know what the correct definitions 
should be.

Why would this have to wait till THEY (the Guile folks) made a 
correction to the base system Guile? Could we not publish the correct 
definitions? It's been a LONG time(many decades) since I did anything 
with any LISP dialect (and even then just playing/learning; nobody ever 
paid me to produce LISP programs). But I pretty strongly recall that if 
anything is defined in an environment the evaluation will not use a 
definition from any surrounding environment  -- in other words, names 
are not unique and the most local definition is used.

In other words, were some source code (.scm file) being evaluated 
incorrectly, prepend to that file the two corrected definitions.

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

Re: Guile bug could affect Windows users

[Mike or Penny Novack]

Additionally, when building the setup.exe on Windows we compile guile from
source anyway, so applying a patch that has been sent to bug-guile but is
not contained in any release yet is perfectly fine, at least IMHO.

-- andi5

  

Again I am probably making some wrong assumptions. Compiling WHAT? The 
interpreter certainly, eval itself, perhaps a few of the most 
basic/most frequently used function definitions. But with most 
extendable languages like LISP and its dialects the bulk of the 
definitions available at the start are usually done in the language 
itself. OR, in compile and go implementations that makes little 
difference (any that are added are compiled before execution/evaluation 
as opposed to a strict interpreter implementation where the expression 
would be reinterpreted every time used.)

Isn't that true of Guile? Some reason to believe that these particular 
erroneous definitions were part of the compile? Even if they were, what 
difference would that make except perhaps speed when being evaluated? 
They still could be overridden by redefinition, yes?

(I hope not confusing people with bringing up matters of how LISP like 
languages are implemented..)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: RFC: A book-close dialog to help auto-zeroize all Inc/Exp accounts

[Mike or Penny Novack]

   The other issue is the fact not really how traditional accounting 
 would do this. More usual is a temporary equity account (receiving 
 total income and total expenses) which is then closed to retained 
 equity with a single entry, either gain or loss for the year (thus 
 making it clear which the case was).


 I was planning to close all the accounts in a single transaction.
 Actually, two, one transaction for income and one for expense.

I understood what you were doing. Now let me try to explain why that 
MIGHT be an issue.

The result you have is two transactions, one representing total income 
and one representing total expenses. But the absolute magnitude of these 
two amounts is of little interest while the difference between them and 
especially the sense of that difference is considered of paramount 
importance (oh the famous lines from Dickens's David Copperfield say 
that so much better).

So yes, your users can see whether the total income amount or the total 
expenses amount is the greater and perhaps even do a rough subtraction 
in their head BUT they probably would prefer a single amount clearly 
labeled as a gain or loss for the year. Which is why the traditional 
method was as it was (and from that temporary account the profit and 
loss report easily produced).

Now equity accounts are standing accounts. Not entirely crazy for the 
close the books function to require the existence of a named equity 
account to be used for the closing process. The closing function would 
then generate THREE (instead of two) transactions (total income, total 
expenses, and gain (or loss) for the year).

Michael

PS: We (MA Chestnut Foundation) will probably agree to adopt GnuCash at 
the January board meeting after I present my recommendation. After which 
I presumably will become available to work on some of the things 
desired. But also likely to at first be working on the special report 
formats generally used by non-profits (we have so few 
accounts/transactions that no big deal to close the books manually so an 
autoclose not my highest priority). If I get involved, would have to be 
considered a serious resource (retired senior analyst with a few 
decades experience designing/writing/debugging financial business software).
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: RFC: A book-close dialog to help auto-zeroize all Inc/Exp accounts

[Mike or Penny Novack]

Ah, yes, a Description for the transaction.  Good point!  Thanks,
I'll go add that.

Anything else
  

-derek

  

The date for which the closing takes place should be a user set variable 
(OK to have it default to 12/31/current year).
a) You don't know the FISCAL calendar of your users. Not necessarily the 
calendar year so should be able to close books as of any date.
b) You don't know if they close the books for ordinary transactions on 
the 30th or the 31st and what day, if any, is a no external 
transactions day.

Example:
   The MA Chapter of TACF does use calendar year.
   I will probably opt to make Jan 1st (next year) be the day that has 
no ordinary transactions. The reason is that I expect to have at least 
a bank interest transaction on December 31st AND  will want to be able 
to produce and Income/Expense report for the year and burn the pre 
close books. Can THEN do a book closing as of Jan 1st. NOTE that this 
would take place (real time) about a week into January to make sure that 
I actually have all transactions for 2007.

   The other issue is the fact not really how traditional accounting 
would do this. More usual is a temporary equity account (receiving total 
income and total expenses) which is then closed to retained equity with 
a single entry, either gain or loss for the year (thus making it clear 
which the case was).

A minor detail, but you probably do not want to generate a split for 
those income or expense accounts which have a zero balance as of the 
closing date. No harm mathematicly, but a zero amount transaction looks odd.

Michael



-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: PATCH: Advanced portfolio report revisions

[Mike or Penny Novack]

We believe, but we are not sure, that the Microsoft-Money Annual % Return is 
the Internal Rate of Return (IRR).  See 
http://support.microsoft.com/kb/131664. We believe that the IRR is the best 
measure of return, because it allows any two investments to be meaningfully 
compared..  The calculation is non-trivial.  I recommend Financial 
Calculation Programs for Linux by James Shapiro at 
http://www.linuxjournal.com/article/2545.  He gives C, Java, and Perl programs 
for calculating IRR.
  

Close. But just IRR by itself without including its standard deviation 
for the time period doesn't allow proper comparison of investments. Not 
that past measures of risk provide a certain measure for the future 
but it's the best that is available. The point here is that investment A 
with an IRR of M but a large deviation might not be a better than 
investment B with an IRR of N slightly smaller than M but with a much 
smaller deviation. The usual idea is that the real comparison gets made 
after adjusting for risk -- how much of the higher yielding would 
instead have to be invested at low yield very low risk to bring the 
blend to the same deviation -- and then use that blended yield.

The problem is that the deviation can't be simply calculated from the 
beginning and ending states but needs the history in between.

Michael



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

Re: Feature request: process multiple invoice with single payment

[Mike or Penny Novack]

Suspense accounts are a user thing.  GnuCash doesn't care, and
indeed shouldn't care.  You can Process Payment into a Suspense
Account just as easily as you can Process Payment into a Checking
Account.


Is it useful to allow aliases for Account Types? Or to add a Suspense 
type which is just a Checking type with a different name? Just thinking 
out loud here

.Dan W.


Oh dear, making me sorry I ever brought the issue up. Look, I'm not an 
accountant but have worked on systems that have to record billings and 
payments.

Yes, some businesses do put suspense money into a separate bank 
account (asset side of the ledger). But when I used the word suspense 
I wasn't thinking about bank accounts but accounting accounts (see the 
word account gets used in multiple ways). That sense of suspense 
would be a liability type account to represent that this check was 
deposited into one of the businesses bank accounts (asset) but the 
money, or at least this portion of it is owed back to somebody pending 
disposition and so is a liability.

What the disposition ultimately is not YET specified. Once that is 
decided the item gets removed from suspense (counterbalancing entry) 
when a refund check is sent back to the customer, an entry to their 
customer account against future bills, or whatever action gets taken 
(generally you have to contact the customer to ask what do you want 
done with the extra? and the amount is in suspense while that is 
determined). If you knew at the time the amount was being processed 
where it was to go, just do that (no need for a suspense entry).

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

Re: Feature request: process multiple invoice with single payment

[Mike or Penny Novack]

Doing multiple non-consecutive invoices for the payment process would
be arbitrarily complex.  At that point the real answer is a real
solution to http://bugzilla.gnome.org/show_bug.cgi?id=108570

In my business experience this disputing an invoice is extremely
rare, so I dont think that supporting it is a large requirement.
However, I'm beginning to actually believe that I should change
the search to a dropdown.  But I have no time to do any implementation
here.

Patches welcome.

-derek
  

Rare, but remember the 80/20 rule (in general, 80% of the coding effort 
will for handling situations that are less than 20% of the time). In my 
experience, fully half of the coding effort will be for situations which 
occur only a couple percent of the time -- all the exception processing.

I only rarely was involved with the invoice billing/collections system 
unless the programmers there were really stumped or a disaster of some 
sort. But I still have a few suggestions:

1) Don't start with the coding issues or even what sort of drop down 
menus. Start with considering all the functionality that should be 
provided (what situations might arise, how to deal with), then how to be 
handled at the user view level (menus, etc.) and only then how you will 
implement.

2) I am getting a little concerned that I have not (yet) seen any 
mention of suspense (the usual name for the account into which amounts 
are dropped where the person dealing with the check that has come in 
can't immediately put it where it eventually goes). Take the check 
covering several invoice situation we are discussing. Customers can do 
odd things. Here's examples:
Your are billing customers $10/mo for some service. The invoices are 
prepared some number of days in advance of the bill mailing so you 
assume that you will have an invoice available before the check comes 
in. People here seem to be talking about the situation where there are 
several as yet unpaid invoices and a check comes in to cover all of 
them. Fine, the invoices exist. But suppose the customer isn't behind. 
For the August invoice you receive a check for $30 (the customer is 
going away for a couple months, paying bills in advance -- but the 
corresponding invoices do not yet exist ). There are a number of ways 
your business can handled that, send a check back in return, prepare the 
future invoices and mark them paid, wait till they get produced in due 
course and pay them, etc. -- but none of these options are immediately 
available at the moment you are trying to process that check. Or how 
about a check for an amount that does not match the total of the 
invoices. Too little and you have an unpaid balance left on an invoice, 
you probably considered that. But what if too much?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Intro + a bug

[Mike or Penny Novack]

Uh, I'm not sure exactly what you mean, but GnuCash does (should) create a
$HOME/.gnucash/ dir for its own storage, as well as leveraging the
$HOME/.gconf/ storage we've talked about.

  

Sorry -- but I don't understand.

Yes, I see that GnuCash has created a directory named .gnucash 
(presumably for SOME of its storage). It also creates separate 
directories .gconf   .gconfd   .gnome2   .gnome_private   and the file 
.gtk-bookmarls (presumably for other parts of its storage)

What leverage? You imagine that any of these would be there in a 
Windows user's c:\documents and setting\userID (the Windows XP 
equivalent of $HOME/ ) for some other purpose than holding GnuCash data? 
I think I see what the problem might be and why hard to fix. This .gconf 
stuff isn't GnuCash specific, is it? There's been a piggyback 
utilizing existing stuff and that defines where to put it because if  
it isn't specific to a particular app, can't be in a subdirectory 
devoted to that app's data.

Back to the previous suggestion (other post). While the user can't be 
asked to create another directory path not containing  putting in 
first time code to detect the situation and present a message IS a 
viable option since few users affected. The message might be along the 
lines:

SORRY --- special characters in your user ID prevents all features of 
GnuCash from operating correctly. Have your administrator create for you 
a second account whose name does not contain   (list forbidden 
characters here) and run GnuCash while logged in to that account.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Intro + a bug

[Mike or Penny Novack]

[[Maybe a bit off-topic for this mailinglist, but I thought it could give some 
additional background]]

... and some are already. A fine example is The  Gimp (http://www.gimp.org), 
an alternative image manipulation program for Photoshop. Whether it truly can 
replace Photoshop is a long debate, but in itself it's a very good image 
manipulation program. Originally written for *nix, but also running on 
Windows for quite some time now. The Gimp also uses GConf and as such uses 
the same common directories.

Regards,

Geert
  

Not off topic at all (open source projects need to help each other out)

If the Gimp shares this problem (inability of the gconf routines to 
cope with ALL legal Windows directory names) I haven't seen it reported 
-- say from when the Open CD folks were testing the Gimp. But this 
may well be the consequence of the rarity of Windows users chosing an 
account name with an asterisk in it. Can anybody here identify the 
address of the team working on gnome for Windows because they should 
be made aware that there is a problem affecting their project.

The implication is that the problem isn't FIXABLE (can't make GnuCash 
work completely properly for all legal Windows user account names) but 
that doesn't mean it should be no action. One possibility would be for 
the first time routine to check whether the directory it is being 
asked to set up is legally named (as far a gnome is concerned) and if 
not, temporarily pasues the process to explain the problem. Might 
suggest that the user either:
1) abort (option provided) to allow the system administrator to allocate 
another user account whose name would not be a problem (tell what the 
illegal characters are). The Windows user would then use this other 
account for GnuCash.
2) allow to proceed (option provided) warning the  what the user what 
won't work (there may be more things than just being unable to save 
preference changes. That might not be totally unacceptable while the 
person LEARNS about GnuCash. An administrator can always later copy the 
books to another user's data area.

Alternatively, if it is decided that account names that will cause 
problems are so rare that not worth a coding effort, then at least 
something in the read me for the Windows install. Yes I know people 
tend not to read those until AFTER encountering difficulties, but if 
they then look and see an explanation of Problem with some legal 
Windows account names telling them what to do at least it won't be a 
mystery.

Michael



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

Re: Intro + a bug

[Mike or Penny Novack]

Josh Sled wrote:

The developer who started that work hasn't had a lot of time for GnuCash in
the last few years.  I really hope he does respond, but I don't feel out of
order responding on his behalf.


There are two approaches to book closing:
  

Maybe stop right there. As soon as there appear to be difficulties with 
the only approaches step back one level of the process and maybe more 
alternatives will appear.

In other words, what must close the books DO. Let's consider what an 
accountant did when keeping books on paper to close the books.
1) Create a special closing equity account (name usually 
Income-Expense or ProfitLoss) and close all income and expense accounts 
into it (they now all have zero balances)
2) Close this account into equity at start of new fiscal period 
(equity at start of last period + amount to close PL)
3) Check that the standing accounts (asset and liability accounts) 
balance with this account.
4) Disallow any entries with dates prior to closing (but allow 
recreation of reports, allow closed accounts to be viewed, etc.)
The fact that normally (when using paper) might have been into a new 
physical book not really relevant, just that an effective double line 
has been drawn with all temporary accounts closed (all the income and 
expense accounts) and the standing accounts are in balance and that no 
alterations are allowed.

There should be no specification that this be calendar year (fiscal 
year might or might not coincide)
There may or may not be a special date for these entries that falls 
after the last date of the books being closed and before the first date 
of the new books.

Obviously users should burn a copy of the books before and after 
closing, but backup procedures are really outside the process except 
that I will revisit this when discussing the security of the closing 
process. Whether the obsolete accounts are deleted or not is again an 
additional feature. Personally I would prefer to leave them there, 
perhaps just make them invisible (have an income placeholder and an 
expense placeholder with names like obsolete income -- move them there 
and then not expand the view to hide them). You want the accountant to 
easily be able to answer questions like how much did we pay for tree 
guard last year? (a deer repellent, our organization grows trees) and 
this shouldn't require reloading from backup. I can't see how the 
decision whether obsolete can be other than manual. It's CHANGES to 
prior year entires that must be prevented. In our case (and this is not 
untypical) only sometimes would an income or expense account with the 
same name be used in the following accounting period, the majority would 
remain in use.

Because it is easy to underestimate the abilities of programmers to 
alter data in spite of whatever checks exist in the programs (they can 
do that OUTSIDE the control of the program), I would recommend that the 
process include at least the opportunity to make that burn to read 
only medium and to include a compare/verify function that given such a 
CD or DVD (and a date) could confirm that no entries prior to that date 
have been altered. In other words, to confirm that no entries have been 
made for a date prior to the previous closing. This function could be 
used whenever doubts arose that perhaps the entries for a prior period 
have been altered.

OK -- accountants reading this, what have I left out of the close the 
books process? (I am not an accountant). Consider all the options 
which would be good to include and what parameters these would require. 
With NO options at least name of books to be closed and 
closing/reopening date but might provide choices like continue vs 
new books (requires name/path). We might also want to perhaps enforce 
some of these choices (if close the books is to exist). Thus we might 
REQUIRE new books (starts out with all the accounts of the old, all 
temporary accounts zero balance, all standing accounts as they are at 
the start, no transactions prior to the date (for any account), but 
everything else copied exactly (doesn't this answer the 3 and 4 
points below) and BTW, this does NOT eliminate the need for a verify 
against read only copy.

Michael

One approach has a structure either above or within the current top-level
data structure of a book.  This structure is probably an archive section
that contains transaction/history information outside of the current
financial period.  All of the rest of the application (file load/save; the
UI, generally; reports; c.) would need to be extended to support this
indirection.

Another approach would be more procedural, simply creating a new, standalone
datafile for the new period.  While we already have the functionality to
export the existing account hierarchy (only and alone), a welcome
extension/variant of that export would probably also...

1/ allow the user to ignore obsolete accounts that the user doesn't want to
   carry forward...

2/ create appropriate 

Re: Intro + a bug

[Mike or Penny Novack]

 Very interesting observation. Does the directory .gnucash get  
 created on both account names? If it does, gnucash's handling of  
 account names and paths is correctly implemented. In that case we'd  
 have to forward the bugreport about the .gconf directory to the  
 GConf project: http://bugzilla.gnome.org/show_bug.cgi?id=161209  
 (Andreas already brought up the issue there). That's fine and we will  
 gladly do so, but I'm asking anyway to narrow down this bug as much 
 as  possible (Are Spaces the problem? Or the Ampersand?)

Yes, all get created except .gconfThe following all exist.
.gconfd
.gnome2
.gnome_private
.gnucash
.gtk-bookmarks

It's not EVERYWHERE tat the problem exists. For example, .gtk-bookmarks 
contains the correct path to the books (and of course one of the 
directory names in that path has space and ampersand in it).

Andreas Kohler just posted THIS on the user list

that is correct. Spaces are not the problem on Windows, but the
ampersand. In

http://svn.gnome.org/viewcvs/gconf/trunk/gconf/gconf-backend.c?revision=2371view=markup

you will find that the string invalid_chars is defined as \t\r\n\$,
+=#!()'|{}[]?~`;%\\ and if any of those characters appears in a gconf
configuration source address, then that is declared as invalid. In the
end you do not have any writable gconf source and are tied to the
default values.

I have asked there whether this problem is top level directory name or 
anywhere in the path because if the former, there may be a 
(relatively) easy fix. GnuCash is the first open app for Windows that 
I have encountered so far that did NOT create a directory in the user 
data directory to contain all its configuration data but instead drops 
all of these directories (and file) separately into the user data 
directory without grouping them into one subdirectory (increases the 
risk of a name conflict problem and complicates backup*).

Michael

* A Windows XP user cannot back up his/her entire data directory from 
own log in  as the burn to CD/DVD process will make a temporary  copy of 
what is to be burned in that directory (recursion error). Pre Gnucash I 
was simply supporting my end user by burning a CD with copies of all the 
data subdirectories actually in use --- My Documents, .Mozilla, 
.Thunderbird, etc. etc., a fairly short list).  I understand that a 'nix 
user would normally back up the entire /home/userID but especially for a 
Windows user who is using open source alternatives, useless to copy each 
time tons of essentially constant app data for the MS apps that are not 
being used. The scattering  of the GnuCash configuration stuff rather 
than grouping into a GnuCash subdirectory more than doubles the number 
of items to be copied!

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Intro + a bug

[Mike or Penny Novack]

It was suggested that I join this list in addition to the users list. I 
am a retired senior systems analyst with a few decades experience in 
software for a financial. Well call that semi-retired as they 
sometimes tempt me back into the cypher mines for a little juicy 
consulting. At the moment I am doing an evaluation of GnuCash to see if 
ready (close enough to ready) for our purposes and am paralleling 
using the books of a 501(c)3 of which I am treasurer. I don't expect 
that all the special report formats as normally used by non-profits will 
be in place, but hey, they aren't in QuickBooks (supposedly) Non-Profit 
version either --- and presumably if GnuCash passes initial testing I 
can write mods, this being open source.

I would like to do a little more than simply report any problems I find 
from the point of view of an end user because with a little help, I 
could. In other words, when I report a problem, if a developer could 
point me to the right subsystem I'll look at the code to try to 
include with the bug report not only what is experienced as wrong by the 
end user but why.

Here's the first one. I am of necessity testing GnuCash under Windows 
(sorry, but we can't make it an organizational requirement for Treasurer 
must be able to run under a 'nix OS). The only interesting problem 
encountered so far is a total inability to save changes to 
preferences/setting. At first I thought this was something I had done 
wrong in set up but no, after much testing, have determined it's a bug.

The initialization routine (I don't know its name) which executes the 
first time a user runs GnuCash, in particular, which creates the .gconf 
directory and it's contents, does not work for all legal Windows XP user 
account names. In other words

If the XP account is named Testonly the initialization will work, the 
directory .gconf and its contents will be created as expected, and 
preference changes can be saved (normal behavior)

If the XP account is named Test  Retest (this is a legal XP account 
name) the directory .gconf doesn't get created, and though this user 
will be able to create a set of books and process them normally, save 
them normally, etc. preference changes like turning off tip of the day 
or altering the frequency of autosave will not take.

Whether the account does or does not have administrator privilege does 
not matter. Sticking in a .gconf directory from another account doesn't 
fix it. More an annoyance than anything else (can always set up another 
XP account with a different name in which to run GnuCash). I suspect 
that very few Windows users have an account name with space and 
ampersand in them  so no surprise something like this would have 
passed through alpha and beta testing without detection. If somebody 
would point me to the right routines I'll have a look. Probably a string 
processing error and most likely the space being mistaken for end of 
string.  Most of my career worked in COBOL and BAL (IBM mainframe 
assembler)  but am reasonably fluent in C (will need to learn Scheme 
when tinkering with reports, but hey, when you have learned a dozen 
languages, what's one more).

Meanwhile, I understand that close the books isn't working. If whoever 
is the developer on that portion wants a hand, please get in touch. 
Unlike the problem I just reported (nuisance, not serious, unlikely to 
affect many people) the lack of a working close the books routine 
would be a serious minus in my evaluation because while can be done by 
hand, onerous if there is a large number of income and expense accounts. 
I am not in a position to offer to take over since I can't make a long 
term commitment not to return to paid work should a tempting offer 
arrive* but at the moment have time available.

Michael D Novack, FLMI(the FLMI is an insurance designation)


* I'm not actively SEEKING paid consulting work, not on any head hunter 
lists  -- but I don't turn down help requests from my ex-employer . 
Totally unpredictable.

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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