[GNC-dev] donation problem
Would love to donate, but ... Unfortunately your donation process assumes we can either ... a) Do an international bank transfer (would be a great deal of trouble/red tape getting this set up as would need a one time override of fraud controls) b) Receive a confirmation code by text to a cell phone number. Cannot do that from HERE. While we do have an emergency cell phone my wife caries in case she breaks down on the road somewhere (at a location where there IS cell phone service) we do not have cell phones to RECEIVE cell phone calls. That's because there is no cell service where we live. If I am here at the computer in the house, cannot receive a text. This is not an infrequent problem, a site ASSUMING can use a cell phone for this. Thus we are limited in with whom we can have accounts and have to do things like choose banking institutions based on whether they provide an alternative authentication method (like automated voice call to our land line number to send the code) 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: [GNC-dev] Sample Report with Examples
Let me ask you, have you ever coded for a non-procedural language? If not, if scheme is your first, there is going to be learning curve, and much of your experience with procedural languages not as much help as you might think. I'd suggest you get an elementary LISP text (scheme is a dialect of LISP) But essentially. a) It is a functional language. Instead of carrying out some procedure you are evaluating some function*. A scheme (LISP) program is a function. To make matters worse, sometimes the result of the evaluation is irrelevant and what is wanted are "side effects" resulting form the evaluation. b) The fundamental data type is "list" c) Those top level definitions are the definitions of named functions that will be used in the main evaluation. Like in a procedural language you might define subroutines that would be called. BUT you can also "define on the fly" (a "lambda" function, not named, so only can be used in this place) Like I said, get an elementary LISP text and get well beyond the equivalent of :hello world" before you try to understand scheme Michael D Novack * The computer science among us will know that these can be proven equivalent (that's what LISP was all about originally). BTW, although c is usually used as a procedural language it can be used as a functional language. While learning c and on a list discussing what we were learning I got challenged to rewrite one of my exercises as a pure function (to convince me c could be used that way) PS: the 'nix users who are comfortable at the command line and writing scripts well your shell language plus library of standard utilities constitute a non-procedural language of fundamental data type "string". So what you learned doing that not completely useless. Also 'nix users who use Emacs/XEmacs, well you ARE in a LISP environment when you do that. On 1/15/2023 5:38 PM, flywire wrote: This exercise has left me with a few questions about https://github.com/flywire/gnucash/blob/Hello/gnucash/report/reports/example/options-example.scm 1. I'm not clear on the scheme terminology. What are the lines in the top-level definitions I labelled initialise values? I understand they are not constants and I'd normally call it initialising or assigning variables. 2. Why does the section referred to in the above point normally only contain option name and help but not default, section, or sort order? 3. If option sections are defined, does a default section need to be set? 4. Can a default General section be added to? It seems not and the whole thig must be created. 5. The formatting style is different to most standard reports. Does it need updating? 6. How can I make the version number bold: https://github.com/flywire/gnucash/blob/3a949c269735709b47e02f181d80ad7e8c671982/gnucash/report/reports/example/options-example.scm#L340-L345 7. What is the best way of understanding/searching the api? Things like html format and date interval below or tracing from date intervalin other reports back to the specific date. 8. I'm still not clear on things like let, let*, and nested let. 9. There seems to be some sort of git corruption. How can I move this forward as a contribution? 10. > [raised previously] I'm not sure if version or report-guid should be updated. ___ 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: [GNC-dev] Fetching invoice tax list and general business information in python
On 10/12/2022 6:41 AM, Tim van Osch wrote: Hey everyone, I would like to render my invoice using the python bindings but I am having two issues. The main issue I am having is getting the tax values of an invoice per tax table. Something like this: *VAT 21% *€152.00 *VAT 6%*€23.00 I found the method: Invoice.GetTotalTaxList() which is expected to return an AccountValueList. Unfortunately in the python bindings it returns a list of _gnc_monetary, which I think is a wrong/incomplete typing. Does anyone know how I can fetch the tax values per table for an invoice in Python? Just a reminder. Those that want/ask for something like this are almost always in a jurisdiction where it is a relatively simple problem. In other words, they do not recognize they are a "special case" of a "figure the tax" problem where the general case is FAR more complicated, Where it would require a "system"/function to compute the applicable sales tax (VAT is a form of "sales tax". In the general case, the "compute the tax" process has to deal with multiple tax tables (one for each jurisdiction claiming sales tax) and that also needing to take into account what is or is not "taxable" in that jurisdiction. Over here we have 50 states plus some local jurisdiction also wanting sales tax and which applies is not necessarily based on where the business is located. If the sale is remote, that will depend on the customer location. USUALLY these calculations are done by a POS system which feeds the accounting package, not as part of the accounting package. Why "point of sales" should be obvious when you recognize that sales AT a "brick and mortar" store will depend on where (the "point of"). Thus a small business with three buildings, one in Greenfield MA, one in Brattleboro VT, and one in Keene NH (these would all fit in a 40 mile circle) could be the same POS software with the program in one place "follow MA rules", one "follow VT rules", one "follow NH rules" << the program is told where its "point" is >> but if say one of those stores is also handling remote sales that "point" changes with each sale << according to where the customer/delivery is >> NOTE: POS systems usually also feed the inventory system so the sale results in reduction of physical inventory Gnucash is JUST an accounting package, the "general ledger" part of a complete business system, which might include POS, inventory, payroll, billable hours, etc. Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Data Model Schema
On 8/21/2022 11:42 AM, john wrote: On Aug 21, 2022, at 7:51 AM, Michael or Penny Novack wrote: I do not understand what you could mean by going back and forth from Quickbools to gnucash (or any other double entry bookkeeping software) as Quickbooks is not double entry. Michael, you're confusing Quicken that isn't double-entry with QuickBooks that is. Regards, John Ralls I meant Quicken Quick Books is regular double entry. I was rather familiar with QuickBooks Pro as before the fire several of my orgs used it << was replaced with gnucash as QuickBooks refused to replace for free, and besides, their "for non-profits" version didn't actually have any of the special features a non-profit would want >> 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: [GNC-dev] Data Model Schema
On 8/20/2022 3:06 PM, Scott Morgan wrote: Hi John, Well, I did some work building an open source Java Accounting Model ( adligo.org) a few times of the past two decades. Now I find my self using QuickBooks online, so I have been looking for some collaborators and gnucash seems like the most successful project out there. The enriched metadata would allow me to build ETL tools to go back and forth between QuickBooks, my system and gnucash. In my opinion accounting systems are basically the evolution of / fancy spreadsheets. The main difference is the way transactions are linked in double-sided accounting. Longer term I'm hoping for some sort of import-export standardization of accounting data.The current standard seems to still be CSV files, which have problems binding the accounts together. You can do this by tracking source systems and source Ids. But it's still fairly painful. So I figured I would start looking at the model you all were using inside of GnuCash. At the "data model" level you should not be thinking about language of implementation. I do not understand what you could mean by going back and forth from Quickbools to gnucash (or any other double entry bookkeeping software) as Quickbooks is not double entry. No, did not evolve from spreadsheets. Double entry bookkeeping is many hundreds of years old. Was once done pen and ink on paper (was still done that way during my lifetime and how I learned). THAT process, enter transactions into a book called the journal, then posted from there into a book called the ledger, could be directly implemented using a spreadsheet application instead of paper. But note that the posting process was particularly prone to error. IF you were using gnucash in "journal entry mode" (what you are using entering transactions that are splits) you would see the evolution more clearly. When you complete the journal entry and hit enter, the posting is automatic (and error free -- the computer will not miss copy a digit, transpose digits, etc.) Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] „Accruals are potentially missing as account_types in the db scheme
On 4/16/2022 6:56 AM, Alexander Damm wrote: " If I understand correctly what you mean by "accruals" you mean that this report requires you to treat some liabilities differently than others. You need to be able to distinguish between them. This would not require a new "account type", just a partitioning of liabilities between "ordinary liabilities" << a place holder under liabilities; its children would be ordinary liabilities >> and "accruals" << a second place holder under liabilities; its children would be accounts that are "accruals" >> Then you only need to "scrape" the Balance Sheet as produced by gnucash." yes that is exactly what I would like to have. So you're suggesting to use the field "placeholder" in the table accounts and match all the accruals accounts under one account with the name:"accruals" and the account_type:"liablility" and the placeholder: "1" and the parent_guid: "(form the main accruals account)" ? regards alex Yes, I am suggesting that it isn't gnucash that needs to change in order for it to produce OUTPUT that contains the DATA you need for German reporting and that you then write something (or convince somebody to do that for you) to "scrape" from the report produced by gnucash (and exported from gnucash). You also have to structure your CoA so that the data in the report will be easily separated out as needed, That puts this specific German requirement OUTSIDE of gnucash proper so we don't need a "German version", "Ruritanian" version, etc. Each to be maintained annually as the jurisdictions change what they require. This seems obvious to me (isolating what has to be different) based on my professional experience (*) . Bear in mind, I'm in the US where not only the Federal government but each state might have different requirements. Michael D Novack (*) in other words, if in my working days I had been asked to design such a program (have "general ledger" produce the file as required by the government) THIS is the approach I would have advised the client to ask for (wearing my "business analyst hat") explaining that the separation would make the annual changes quicker/cheaper and then switching to my "systems analyst hat", how I would have speced it out for the programmers. Understand? Making the annual changes, no need to test the entire LARGE "general ledger" system but only the trivial add on that took a file from "general ledger" and massaged it to the required format for the government. Only THAT part would need to be tested when being changed. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] „Accruals are potentially missing as account_types in the db scheme
Due to the mandatory Taxonomie I have to use among other things the following acoounts: Activ: (Fixed Assets) de-gaap-ci:bs.ass.fixAss (Current Assets) de-gaap-ci:bs.ass.currAss Passiv: (Equity) de-gaap-ci:bs.eqLiab.equity (Accurals)de-gaap-ci:bs.eqLiab.accruals (Liability) de-gaap-ci:bs.eqLiab.liab Currently I programmed a workaround in python to get all the liabilities from the db. Still it would be nicer, if we would have an account_type "accurals" or another field in the table accounts to distinguish between liability and accurals. If I understand correctly what you mean by "accruals" you mean that this report requires you to treat some liabilities differently than others. You need to be able to distinguish between them. This would not require a new "account type", just a partitioning of liabilities between "ordinary liabilities" << a place holder under liabilities; its children would be ordinary liabilities >> and "accruals" << a second place holder under liabilities; its children would be accounts that are "accruals" >> Then you only need to "scrape" the Balance Sheet as produced by gnucash. Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Omit zero balance figures Vs Show zero balances
On 11/29/2021 9:37 PM, Adrien Monteleone wrote: I could be mistaken as to your question, but you can include accounts with zero balances, but not show the actual zeros. This allows you to not show zeros for 'header' accounts in your tree. (even if they aren't set as technical placeholders) I think he is referring to the "subtotal"options. You can set these to appear "before" or "after" and whether or not to show. Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] "Mortgage Repayment Druid"
On 9/16/2020 12:52 PM, David Carlson wrote: Unfortunately, it is not flexible enough to handle modern calculations involving daily interest calculations, prepayments, and other variations, but it can still be used to set up a reasonably good estimated split between principal and interest with or without escrow or insurance, but to keep an accurate running balance it is usually necessary to manually adjust It is actually a "tricky" problem if needing to exactly match the bank's amortization table. And in any case will need at least an annual adjustment for changes to the escrow component << which if anything, is even nastier even after the "what it has to cover for the year*" has been entered (the new RE tax and insurance). There are simply too many places where you algorithm and what the bank used might make different assumptions, where rounding takes place, significant digits used, how the final payment to be, etc.** Michael D Novack * The problem is that NOT simply "enough to cover those payments" (over the year) but to be such that the account NEVER goes below zero or a specified safety amount at any time during the year. Likely best handled by a "trial and error" algorithm to determine the least per payment amount that will accomplish that. It is why the amount appears to jump around so wildly year to year. ** For that reason, I also used a "trial and error" algorithm for that which produced more than one potential solution for the amortization table, one of which guaranteed to match the bank to the penny << in other words, which had the same payment - escrow component as the bank did >> In other words, knowing the payment the bank claimed was correct, produce the amortization table that matched that . The bank would the table FOR A FEE but hey, I was doing software for a living. -- 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: [GNC-dev] Deprecation of XML file
Is there a reason to keep supporting the XML file in future? Wouldn't it be easier to force save the data to SQlite to tackle the move from QOF? The benefit of point in time save (instead of transactional save) could be achieved by working from a copy instead. Probable issue would arise from users that read the XML file directly. Here's my two cents. And I am perhaps a good person to stick my nose in because of one of the issues raised. No, keep XML. a) A burden to require existing users to obtain and maintain SQLite. b) Don't forget that some of us, quite properly, have long term backups of books << say the books after YE ab initio >> If gnucash were no longer to support XML, we wold have to convert all of those. And since the issue of "unalterable books" has been raised, I will point out that these backups might be considered so -- made onto "write once" medium and in "legal custody". Converting them to SQLite removes that guarantee << how do you know that NOTHING else was done besides conversion, no alterations of data >> c) The issue of those who manipulate the gnucash database (I am using in the generic sense) directly OR extract feeds from it OR send feeds to it. They would have to change all their stuff. And here's why I am an especially good person to respond. In my working days I have DIRECTLY modified an SQL database. Not SQLite but real SQL, DB2 on mainframe. Not going into why this done was beyond saying during testing a MAJOR change was made to a project, tables were added, and a need to populate the redefined database with test data << done the "right way", lots of people working many days entering one at a time from terminals -- even a batch DB2 process would have been slow >> The point here is that I was real sneaky. Out of the hundreds of IT people in this very large shop I was perhaps the only one who could have thought of the trick I used. So I would consider writing something to do this sort of thing way beyond reasonable for even very skilled end users. Michael D Novack PS: I might as well include a plus for SQLite at the same time. Probably much less skill required (once having learned SQLite) to query the database outside of gnucash. I would think that far easier than what I would have to do to write a program to query when a XML file. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] PDF Reports
On 3/17/2020 11:00 PM, David Carlson wrote: I added gnucash-user to the cc to distribute this to wider audience. I believe that if you export to pdf, then some pdf readers do split between lines. I think Firefox is one that works ok, but it has been a while since I tried it. David Carlson Again I will point out, IF you are after "pretty printed" reports (for example, when treasurer of an org, what is handed out to the board or posted on the organization's web site, DON'T expect to be able to all the fancy editing within gnucash. That is not the place for it, and a waste of time for accounting system programmers to try to provide expanded editing control when perfectly good general purpose editors already exist. So in the example here, instead of exporting into PDF expecting that to be print ready, export into something else you can edit, get things like those page breaks where you want them, then convert to PDF and print (or link to site). Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Interest
On 12/14/2018 10:26 AM, David Cousens wrote: Frank, Will give it a go. Hamid is possibly right in that it will be too complex to deal with the various possibilities but I will see if I can illustrate a few simple cases. David It is definitely too complex. There are simply far too many variants possible. And many of them would not be properly entered as loans << except perhaps that "iron sheep" contract (illegal* in Jewish law referring to no interest "loans" >> I mentioned which DOES have a definite minimum amount that must be repaid >> What I would suggest is that before any attempt is made to code or even describe how in documentation is that a discussion be opened in the user group where people can describe variants. While I am against us "amateurs" giving accounting advice, this is a situation where standard accountant training might not be useful and the average accountant likely to respond "I never heard about an arrangement like that". Once we have classified variants, we would be in a better position deciding how to proceed. Michael D Novack * In effect partnership agreements where upon dissolution, capital returned based on percentage contributed, both partners share in profits (per what is agreed) but one bears all the risk of loss. In other words, a "loan" where instead of interest, the lender receives a share of profits (but bears no risk if a loss). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Interest
On 12/11/2018 11:07 PM, Hamidreza Jafari wrote: I didn't follow Michael D Novack. Though I can clarify on some issues that were mentioned. Hamid Sorry about that. I was not expecting many on this list to understand, but there can be MORE differences between Western Civ "interest" loans and no interest loans of various traditional societies. Interest loans are (almost always) fully defined as to the amount to be paid back. No interest loans are not necessarily so defined, may resemble "partnership investments". An "iron sheep" contract was a very unfair arrangement (unfair to the borrower) which was definite on the downside but profit shared on the up side. Forbidden by Jewish law and the "sheep" because originally poor shepherds needing to borrow to get sheep to manage. Please understand, the no interest loans of traditional societies do NOT necessarily mean that the lender could not make a profit on the loan. Just that this could not be from INTEREST, had to be conditional on outcome, and the borrower not assuming all of the risk << "iron sheep" >> Accounting for CONDITIONAL items can be non-trivial. Let me give an example from my days. I went to college partially with NDF loans. These were CONDITIONAL loans. They had an interest rate but interest was not charged if in school or if teaching school (after graduation) and each year teaching forgave a percentage of the loan. Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Interest
On 12/11/2018 7:05 AM, Hamidreza Jafari wrote: Enter the annual interest rate in percent. Accepts values from 0.001 - 100. The Mortgage Assistant does not support zero-interest loans. What's the situation? Hamid Needed for more than just Islam BUT perhaps this belongs in the "user" discussion as maybe no programming involved. You would need/use the "mortgage assistant" only for an amortizing loan WITH interest. Just because you might be thinking of a loan as for the same purpose as a mortgage (buying a house, etc.) does not make it one as the term is being used in gnucash. Put your question on the other list as a "how do I do in gnucash" spelling out ALL of the conditions of this loan. I'm not a Muslim but do have an understanding of some of the forms of "no interest" loans and so understand that while no interest MAY be conditions of "profit sharing" if the property involved is sold before the loan paid off. Or in the condition of losses if not forbidden as "iron sheep" contracts << that's just to show you I do know something about traditional societies >> Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] UK VAT - Making Tax Digital
On 11/1/2018 12:12 PM, Clint Redwood wrote: Hi Folks, I’ve been using GNUcash to manage my company accounts for 10 years, but a change in the UK law means that all VAT will need to be submitted electronically from an accounting package from April 2019. FIRST need to settle the literal wording of the requirement. Submitted electronically FROM the accounting package? (meaning NOTHING in between) Or submitted electronically -- the accounting package must be able to produce output that can be submitted electronically. Thus the previously existing "accounting package" PLUS whatever is connecting to the governmental agency and electronically sending it data is now "the package". Those are NOT the same thing. I'll leave it up to the UK folks to determine what the new requirement is. Except to point out, as a person who in my working days did software for one of the world's largest "financials", I would have my doubts about the former interpretation << our systems were composed of LOTS of programs sending data to each other --- what would be meant by THE accounting package >> Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
