Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)
Am 2018-08-06 16:14, schrieb John Ralls: On Aug 6, 2018, at 5:19 AM, c.holterm...@gmx.de wrote: Am 2018-08-06 11:35, schrieb Geert Janssens: Op maandag 6 augustus 2018 05:32:27 CEST schreef John Ralls: > On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote: > > Hello, > > after some time I get back to the gnucash python bindings. > > I worked on a str method for GncNumeric. It's in the example_script > dir > (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_sc > ripts/str_methods.py) I changed it to python3. I read at the beginning of this file you chose to implement it as an example script which - if found useful - could be added to gnucash_core. You have my blessing to include it in gnucash_core :) > Well I found it interesting to think these things through. Maybe someone > can tell me about the mysterious "later on" in the cited comment. At this > point I find it useful to have a way from the instance to the wrapping > object through some kind of link as I suggested in the patch to > function_class. Christoph, The person who wrote the first two lines of that, Mark Jenkins, was the original source of the Python bindings. He was never a regular dev, he just got 16 patches committed between 2007 and 2012, 10 of which touched the python bindings. Your history with them is almost as long as his--in fact you have *12* commits--and pretty much no one else has done anything serious with them. Hopefully Mark is still around on the list to clarify. In other words, if anyone knows, it’s you! True :) Just to add some more confusion, there’s now a C++ class GncNumeric that handles the actual implementation of many of the gnc_numeric.* functions. I believe that SWIG can’t see it, only the C wrapper functions are exposed to SWIG. It would be a very useful experiment to wrap the C++ GncNumeric class directly rather than it's c wrapper gnc_numeric_xxx. Python doesn't need the c compatibility layer it represents. Geert Geert, unfortunately your mail went to my spam folder for whatever reason. Trying to do C++ bindings for python sounds very interesting. I'd like to try that when I find the time for a simple example type. I don't know if GncNumeric would be a good candidate. I'll have a look at it. Thanks for the blessing :-) Python has its own rational numbers so the only thing the Python bindings need is a way to convert to-and-from that to GncNumeric for communicating with the rest of the GnuCash API. I suggest QofSession as the first C++ class to play with SWIGing. It’s fairly simple and using it is the first step in using the bindings. Regards, John Ralls John, Thanks for the suggestion. I'll also think about what you said about the numerics. regards, Christoph Holtermann ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)
> On Aug 6, 2018, at 5:19 AM, c.holterm...@gmx.de wrote: > > Am 2018-08-06 11:35, schrieb Geert Janssens: >> Op maandag 6 augustus 2018 05:32:27 CEST schreef John Ralls: >>> > On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote: >>> > >>> > Hello, >>> > >>> > after some time I get back to the gnucash python bindings. >>> > >>> > I worked on a str method for GncNumeric. It's in the example_script >>> > dir >>> > (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_sc >>> > ripts/str_methods.py) I changed it to python3. >> I read at the beginning of this file you chose to implement it as an example >> script which - if found useful - could be added to gnucash_core. >> You have my blessing to include it in gnucash_core :) >>> > Well I found it interesting to think these things through. Maybe someone >>> > can tell me about the mysterious "later on" in the cited comment. At this >>> > point I find it useful to have a way from the instance to the wrapping >>> > object through some kind of link as I suggested in the patch to >>> > function_class. >>> Christoph, >>> The person who wrote the first two lines of that, Mark Jenkins, was the >>> original source of the Python bindings. He was never a regular dev, he just >>> got 16 patches committed between 2007 and 2012, 10 of which touched the >>> python bindings. Your history with them is almost as long as his--in fact >>> you have *12* commits--and pretty much no one else has done anything >>> serious with them. >> Hopefully Mark is still around on the list to clarify. >>> In other words, if anyone knows, it’s you! >> True :) >>> Just to add some more confusion, there’s now a C++ class GncNumeric that >>> handles the actual implementation of many of the gnc_numeric.* functions. I >>> believe that SWIG can’t see it, only the C wrapper functions are exposed to >>> SWIG. >> It would be a very useful experiment to wrap the C++ GncNumeric class >> directly >> rather than it's c wrapper gnc_numeric_xxx. Python doesn't need the c >> compatibility layer it represents. >> Geert > > Geert, > > unfortunately your mail went to my spam folder for whatever reason. Trying to > do C++ bindings for python sounds very interesting. I'd like to try that when > I find the time for a simple example type. I don't know if GncNumeric would > be a good candidate. I'll have a look at it. Thanks for the blessing :-) Python has its own rational numbers so the only thing the Python bindings need is a way to convert to-and-from that to GncNumeric for communicating with the rest of the GnuCash API. I suggest QofSession as the first C++ class to play with SWIGing. It’s fairly simple and using it is the first step in using the bindings. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp
Hi All Thank you for feedback - I *do* take all feedback into account, even if I don't always agree with them-- and this is from my understanding of Gnucash evolution(*) rather from any expert knowledge of accounting. (*: we all know Gnucash has evolved through generations rather than a grand design ) 1) Frank et al requests some analysis of accounts for grouping into Short/Long, etc. I disagree. The current balance-sheet does not make any judgements into the types of monies held in various asset/liability accounts, and I do not particularly think it is universally agreed which assets should be long/short-term, which ones are fixed etc. The current balance-sheet will just take a nested list of asset/liability accounts, and simply list them sequentially, up to depth-limit. The ways that an account can be tagged fixed, long or depreciation, contra, etc is not something the current balance-sheet can understand, nor am I willing to impose my judgement to report. The Tutorial and Concepts Guide does encourage that Fixed Assets are held in account structure Assets:Fixed:Asset1 and its depreciation amounts are recorded in Assets:Fixed:Asset1:Depreciation, and I see no problem in that, and balsheet (old or new) will diligently report all amounts. However I do understand there may be a wish for a customized balsheet to apply heuristics/rules for depreciation/current/fixed etc assets but this requires expert accounting knowledge. 2) Subtotals being above or below the account-and-children family is something that current balsheet already does, and I'm keen to preserve. The current balance-sheet allows 4 combinations of display/parent-account-subtotal strategies, and 2 of them produce nonsensical reports. I've distilled 4 into 2 valid possibilities, and I know the 2 other options are nonsensical. From prior discussion, some preferred above, and some preferred below, so be it. Additionally, I have seen numerous examples, from my nested chart of accounts with account-depth of 4, that the amount indenting is just wrong. I have fixed it. 3) In the screenshot, EUR Amounts not converted to USD is not confusing at all. In the test book there are USD/GBP prices but no USD/EUR prices. The old balance-sheet would convert any EUR amount to 0 USD and display an incorrect total.4) The amounts being links are a new feature - the new income-statement links to a transaction report detailing the amounts, and the new balance-sheet links to the register entry which documents the exact balance-sheet figure. 4) Amounts being indented are not my preference, however they are indented in existing balsheet and I'd rather leave the possibility for those who prefer. It could be done in CSS, but it's not difficult at all to leave it in scheme. 5) Amounts being clickable is a nice addition... do try and see what it does. 6) My main concern remains the accuracy of figures -- I use official API to retrieve xaccAccountBalanceAsOfDate so I don't doubt the amounts are right, but I'm not sure the outcome when unusual CoA are used eg depreciation, contra accounts, equity with opening-entries or closing-entries etc. 7) The sections are copied from balance-sheet and they need experimentation... I'd be grateful if anyone can review the section amounts are selecting the correct amounts. I don't think I've got it 100% correct and need feedback. C On 31/07/18 09:04, Adrien Monteleone wrote: Chris, Here are my impressions and questions, perhaps I’m not understanding what you were trying to show with the screenshot. (does this contain illustrations of multiple presentation possibilities all-in-one or is this intended as how the report will look by default?) The asset summary at the top seems confusing and isn’t labeled. If I don’t know who or what this entity is or how their books are arranged, how do I know what these figures represent? Each section seems to be missing the standard headings. (Current/Non, Short/Long Term, Fixed/Intangible etc.) I know other discussions have touched on the duplication in some reports in the menus, but maybe this is how it’s addressed - have a basic report that has multiple entries based on the report type desired for a particular entity. (or determined by book/app preferences, say report defaults for a particular jurisdiction) So there might be a Personal Balance Sheet, Small Business Balance Sheet, Public Entity / Non-Profit Statement of Financial Position, etc. Each would have the appropriate major sections in the report with the standard headings expected for each. The account structure *might* mimic this but it shouldn’t have to. The report options should ask the user to select the accounts to include for each section. (rather than just one account list for the entire report) So you would select the accounts to include in Current Assets, the accounts to include in Fixed Assets, the accounts to include in Short Term Liabilities, etc.
Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)
Am 2018-08-06 11:35, schrieb Geert Janssens: Op maandag 6 augustus 2018 05:32:27 CEST schreef John Ralls: > On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote: > > Hello, > > after some time I get back to the gnucash python bindings. > > I worked on a str method for GncNumeric. It's in the example_script > dir > (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_sc > ripts/str_methods.py) I changed it to python3. I read at the beginning of this file you chose to implement it as an example script which - if found useful - could be added to gnucash_core. You have my blessing to include it in gnucash_core :) > Well I found it interesting to think these things through. Maybe someone > can tell me about the mysterious "later on" in the cited comment. At this > point I find it useful to have a way from the instance to the wrapping > object through some kind of link as I suggested in the patch to > function_class. Christoph, The person who wrote the first two lines of that, Mark Jenkins, was the original source of the Python bindings. He was never a regular dev, he just got 16 patches committed between 2007 and 2012, 10 of which touched the python bindings. Your history with them is almost as long as his--in fact you have *12* commits--and pretty much no one else has done anything serious with them. Hopefully Mark is still around on the list to clarify. In other words, if anyone knows, it’s you! True :) Just to add some more confusion, there’s now a C++ class GncNumeric that handles the actual implementation of many of the gnc_numeric.* functions. I believe that SWIG can’t see it, only the C wrapper functions are exposed to SWIG. It would be a very useful experiment to wrap the C++ GncNumeric class directly rather than it's c wrapper gnc_numeric_xxx. Python doesn't need the c compatibility layer it represents. Geert Geert, unfortunately your mail went to my spam folder for whatever reason. Trying to do C++ bindings for python sounds very interesting. I'd like to try that when I find the time for a simple example type. I don't know if GncNumeric would be a good candidate. I'll have a look at it. Thanks for the blessing :-) have a nice day ! Christoph ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Import PDF to GnuCash
A company I work with just started using QB Pro 2018, so I’ll check on this feature, but a web search turned up this forum topic: https://quickbooks.intuit.com/community/Do-more-with-QuickBooks/Pdf-Conversion-to-QBO/td-p/145466 which seems to indicate that it’s nothing new. You need 3rd party software to convert an *electronically generated* pdf to QBO format which QuickBooks can then upload. Scans of paper are not recommended due to the OCR issues, so OCR isn’t their method. They seem to be ’scanning’ the text of the file, but they specify ALL of the text has to be selectable and they recommend only PDF statements generated by the bank. So most likely, these are programmatically generated plain text files that have styling and formatting applied and shipped in a PDF container. The rather expensive software, reverses the process back to plain text and then interprets what the transactions are. I guess it’s possible the banks are doing EDI and simply offering customers a ‘pretty printable version’ in PDF format but with the EDI fields embedded so the file could still be used with EDI and this special software is just taking advantage of that to generate an importable format. Other solutions mentioned for various incarnations of Intuit software is to skip the QBO step and go to CSV, which puts us in GnuCash territory. But I’d bet dimes to dollars, you don’t need $100+ software to accomplish that task if OCR isn’t part of the workflow. Regards, Adrien > On Aug 6, 2018, at 4:47 AM, c.holterm...@gmx.de wrote: > > Am 2018-07-26 21:56, schrieb deltatango: >> Hello, >> Very interested in the possibility of importing PDF statements into GnuCash. >> I know Quickbooks now has this functionality. >> I searched online and found a few clunky possibilities that would convert >> the data into excel which can then be converted to csv and then imported >> into GnuCash. >> I was envisioning a system where you select a PDF statement to be imported. >> The program then asks you to select the area of the statement which contains >> the transactions, much like a photoshop selection. (And perhaps you could >> save templates of selections for different statements). >> Then some kind of OCR scanning reads the columns and data and convert it to >> columns/rows. >> Is this in the realm of possibility for some future release? >> It is so common now that exporting csv or qfx ,etc files from your bank only >> go so far back and you have to download PDFs instead... >> I dream, I hope... >> But in vain I wish not... >> -- >> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > Hello ! > > I haven't heard of PDF statements before. Is it some sort of embedded data ? > Quick googling led me to https://pdftables.com/blog/convert-bank-statement. > It seems to be some sort of standard embedding mechanism. Am I right here ? > > Anyway the way would be to extract the data from the PDF. That would either be > through this statement data or through OCR. The data could be converted to CSV > and be imported to gnucash. > > The missing link seems to be extraction of data from PDFs. > > Is there a FOSS tool to extract statement data and convert it to CSV ? > Or when we go OCR. Is there a tool capable of extracting tables ? > > With OCR you usually only get a text file. It does not recognize that it is > structured table data. At least with the software I used some years ago that > had been the case. > > The OCR way would be interesting if there are possible right issues as John > has pointed out about statement data or reverse engineering. > > regards, > > Christoph > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)
Op maandag 6 augustus 2018 11:35:43 CEST schreef c.holterm...@gmx.de: > Then you speak of c++ GncNumeric. As I understand you are moving the > source > from c to c++. So the python bindings need to reflect that. That sounds > like > another piece of work. Is there imminent need for change there ? Chances > of > breaking changes ? We're indeed converting the internals of gnucash (that part we refer to as "libgnucash" among developers) to c++. As long as parts of gnucash as a whole still depend on the c interface that will continue to exist as a wrapper around the c++ code. So the C interface will probably still be around for a couple of years. So there is still quite some time available to port the python bindings. I suggested this as an interesting project in my previous mail. Thinking about this some more it probably only makes sense when all of the objects that are being wrapped are converted to C++. I guess the wrapper would otherwise have to wrap both the C and the C++ interface to provide full functionality, which sounds a bit awkward. A first experiment to get an idea of what to expect on the other hand may still be useful. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Import PDF to GnuCash
Am 2018-07-26 21:56, schrieb deltatango: Hello, Very interested in the possibility of importing PDF statements into GnuCash. I know Quickbooks now has this functionality. I searched online and found a few clunky possibilities that would convert the data into excel which can then be converted to csv and then imported into GnuCash. I was envisioning a system where you select a PDF statement to be imported. The program then asks you to select the area of the statement which contains the transactions, much like a photoshop selection. (And perhaps you could save templates of selections for different statements). Then some kind of OCR scanning reads the columns and data and convert it to columns/rows. Is this in the realm of possibility for some future release? It is so common now that exporting csv or qfx ,etc files from your bank only go so far back and you have to download PDFs instead... I dream, I hope... But in vain I wish not... -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Hello ! I haven't heard of PDF statements before. Is it some sort of embedded data ? Quick googling led me to https://pdftables.com/blog/convert-bank-statement. It seems to be some sort of standard embedding mechanism. Am I right here ? Anyway the way would be to extract the data from the PDF. That would either be through this statement data or through OCR. The data could be converted to CSV and be imported to gnucash. The missing link seems to be extraction of data from PDFs. Is there a FOSS tool to extract statement data and convert it to CSV ? Or when we go OCR. Is there a tool capable of extracting tables ? With OCR you usually only get a text file. It does not recognize that it is structured table data. At least with the software I used some years ago that had been the case. The OCR way would be interesting if there are possible right issues as John has pointed out about statement data or reverse engineering. regards, Christoph ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)
Am 2018-08-06 05:32, schrieb John Ralls: On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote: Hello, after some time I get back to the gnucash python bindings. I worked on a str method for GncNumeric. It's in the example_script dir (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_scripts/str_methods.py) I changed it to python3. Then I began to wonder about the relationshipp of the SwigObject and the wrapping object. In this case it's something like '_gnc_numeric *' at 0x7f11908da840> > and When I have the GncNumeric object I can access the SwigObject through its instance property. The other way round seems not as simple. My method __gncnumeric__str__ overwrites the __str__ method using add_method. In this method self points to the swig object. I cannot use the methods of GncNumeric as it is the layer of the wrapping object. To access these methods I used to instantiate a GncNumeric(instance=self) as a temporary self. But that seems not right as this probably already exists. I wondered if I could know about the wrapping object when I had the instance only. I did not find a way. I stumbled over an interesting comment in https://github.com/Gnucash/gnucash/blob/69fef8277fde56e7d2df700b21c63c19c115852a/bindings/python/function_class.py#L50 # why reimpliment __new__? Because later on we're going to # use new to avoid creating new instances when existing instances # already exist with the same __instance value, or equivalent __instance # values, where this is desirable... I did not find "later on". But if that works I can safely do GncNumeric(instance=self) as it would reuse the existing GncNumeric object. But nevertheless I wondered if we could put a link to the GncNumeric in the Swig Level. I tried it: https://github.com/c-holtermann/gnucash/commit/a6c2adf7d29c4367728a4fa920307ee595eefa5a (link to my fork) Interstingly some Swig objects can be added to and some others not. GncNumeric works while QofSession doesn't. So I made it a try block for now. Having done that I can get to the GncNumeric (sort of higher self) from the Swig object: https://github.com/c-holtermann/gnucash/commit/2f35b550709ad4131aca0e7309f6bb4b0f984b84 Well I found it interesting to think these things through. Maybe someone can tell me about the mysterious "later on" in the cited comment. At this point I find it useful to have a way from the instance to the wrapping object through some kind of link as I suggested in the patch to function_class. Christoph, The person who wrote the first two lines of that, Mark Jenkins, was the original source of the Python bindings. He was never a regular dev, he just got 16 patches committed between 2007 and 2012, 10 of which touched the python bindings. Your history with them is almost as long as his--in fact you have *12* commits--and pretty much no one else has done anything serious with them. In other words, if anyone knows, it’s you! Just to add some more confusion, there’s now a C++ class GncNumeric that handles the actual implementation of many of the gnc_numeric.* functions. I believe that SWIG can’t see it, only the C wrapper functions are exposed to SWIG. Regards, John Ralls John, thank you for the insights and the friendly words. I like the python bindings for gnucash and use them to feed my bank data to gnucash using a webscraping script that fetches a CSV for me which I can then import using the bindings. This has worked quite well for me for years. At some point in time gnucash wouldn't build due to some segmentation error. The system was working but I only now came back to compile gnucash again when I made a big system update. I'm willing to now and then do something for the python bindings. I don't feel like an expert. But surely I'd like to talk and think things through about them. Maybe someone is interested. I saw that there were some people asking questions about the bindings on this list. Maybe they don't commit but still work with the bindings. So my question remains and maybe someone has an idea. I will continue to think about it anyway (depending on the time I can spare on this project :-). I thought I will look through the python bindings and see if all files are compatible with python3. Thanks to you developers who made that step for the bindings ! I suppose some of the example scripts are not yet converted. The information in the wiki should reflect the step to python3. I'll try to have a look at that. Then you speak of c++ GncNumeric. As I understand you are moving the source from c to c++. So the python bindings need to reflect that. That sounds like another piece of work. Is there imminent need for change there ? Chances of breaking changes ? regards, Christoph Holtermann ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)
Op maandag 6 augustus 2018 05:32:27 CEST schreef John Ralls: > > On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote: > > > > Hello, > > > > after some time I get back to the gnucash python bindings. > > > > I worked on a str method for GncNumeric. It's in the example_script > > dir > > (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_sc > > ripts/str_methods.py) I changed it to python3. I read at the beginning of this file you chose to implement it as an example script which - if found useful - could be added to gnucash_core. You have my blessing to include it in gnucash_core :) > > Well I found it interesting to think these things through. Maybe someone > > can tell me about the mysterious "later on" in the cited comment. At this > > point I find it useful to have a way from the instance to the wrapping > > object through some kind of link as I suggested in the patch to > > function_class. > > Christoph, > > The person who wrote the first two lines of that, Mark Jenkins, was the > original source of the Python bindings. He was never a regular dev, he just > got 16 patches committed between 2007 and 2012, 10 of which touched the > python bindings. Your history with them is almost as long as his--in fact > you have *12* commits--and pretty much no one else has done anything > serious with them. > Hopefully Mark is still around on the list to clarify. > In other words, if anyone knows, it’s you! True :) > > Just to add some more confusion, there’s now a C++ class GncNumeric that > handles the actual implementation of many of the gnc_numeric.* functions. I > believe that SWIG can’t see it, only the C wrapper functions are exposed to > SWIG. > It would be a very useful experiment to wrap the C++ GncNumeric class directly rather than it's c wrapper gnc_numeric_xxx. Python doesn't need the c compatibility layer it represents. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp
Op dinsdag 31 juli 2018 03:04:25 CEST schreef Adrien Monteleone: > I see too that some child amounts show in two currencies but not others. > (looks like just the GBP accounts) Is this intended or just an illustration > (or an omission)? I think this is to illustrate how the report would look if some exchange rates are missing. Your remark shows the current state is confusing. I think the report should render a note or even warning at the beginning to indicate which exchange rates are missing and the consequences this has: - only the commodity/foreign currency value is displayed - (more important) these values are not added to any higher level subtotal Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp
Op vrijdag 27 juli 2018 15:01:17 CEST schreef Christopher Lam: > Latest iteration of balsheet > > * restored amount-indenting. IMHO this is now producing sane indenting > for any subtotal strategy For a completely different idea: is indenting something that could be handled with a css stylesheet ? I imagine adding classes to each account/amount based on their level in the account hierarchy, and then in a css stylesheet add incremental padding per level. Different stylesheets could then independently choose to indent (and how). > * option to toggle amount/account indenting Which would then not be needed. The stylesheet could take care of that for you. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp
Chris, Here are my impressions and questions, perhaps I’m not understanding what you were trying to show with the screenshot. (does this contain illustrations of multiple presentation possibilities all-in-one or is this intended as how the report will look by default?) The asset summary at the top seems confusing and isn’t labeled. If I don’t know who or what this entity is or how their books are arranged, how do I know what these figures represent? Each section seems to be missing the standard headings. (Current/Non, Short/Long Term, Fixed/Intangible etc.) I know other discussions have touched on the duplication in some reports in the menus, but maybe this is how it’s addressed - have a basic report that has multiple entries based on the report type desired for a particular entity. (or determined by book/app preferences, say report defaults for a particular jurisdiction) So there might be a Personal Balance Sheet, Small Business Balance Sheet, Public Entity / Non-Profit Statement of Financial Position, etc. Each would have the appropriate major sections in the report with the standard headings expected for each. The account structure *might* mimic this but it shouldn’t have to. The report options should ask the user to select the accounts to include for each section. (rather than just one account list for the entire report) So you would select the accounts to include in Current Assets, the accounts to include in Fixed Assets, the accounts to include in Short Term Liabilities, etc. Perhaps this can be somewhat determined or guessed by default, but that might be lots of work. The same would be needed for Income/P I find totals/subtotals above the child amounts to be odd. Perhaps less emphasis on the parent label, with maybe a colon indicator (like on the wikipedia entry) would be cleaner with a bold subtotal/total line will make the important numbers stand out more. (that is, not showing the amount on the initial label line at all) Also, usually single lines are to delineate figures from subtotals and double lines to indicate totals from subtotals. (again like the wikipedia sample) I don’t think the figures need to be indented as well, just marked off with single/double lines and appropriate line-spacing. For account indentions, does the report indent contra-accounts? Most statements I’ve seen that have them do so. I understand and like that I have the option for levels deeper than 1 or 2, but usually such official statements are intended as an overview, not for detailed analysis. They should be very easy to read and decipher without extraneous info or styling. And ideally, you should accomplish this with plain-text monospaced. Perhaps work it back to that point and then embellish if needed. A few minor points: --- Is there is a reason why the child totals are also links? It lends a sense of clutter. I noticed in the Equities & Liabilities section that some figures have no currency symbol. While I might be able to figure out what they are by studying the document, that info should be more readily discern-able at a glance. I’m puzzled by that section though. Usually it’s one or the other (separated or consolidated) but not both. Also, the total for Assets and the total for Liabilities & Equity should be on the same horizontal line when in 2-column mode. I see too that some child amounts show in two currencies but not others. (looks like just the GBP accounts) Is this intended or just an illustration (or an omission)? Regards, Adrien > On Jul 27, 2018, at 8:01 AM, Christopher Lam > wrote: > > Latest iteration of balsheet > > * restored amount-indenting. IMHO this is now producing sane indenting > for any subtotal strategy > * restore dual columns (i.e. left=asset/income, right=liability/expense) > * the above two only enabled when multicols are disabled > * option to toggle amount/account indenting > * incorporated bug 623381 recommendations for sections labels/totals > * added sections for equity, liability+equity > * modify 'original-currency' display to match eguile report i.e. > smaller font, precedes converted currency > > I would really like feedback on > > * accuracy of amounts > * accuracy of sections > o further tweaking of option names/sections/ordering > > Screenshot: > https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null > > On 25/07/18 15:53, Frank H. Ellenberger wrote: >> Am 19.07.2018 um 13:09 schrieb Christopher Lam: >>> Hi Frank >>> Thank you - I can restore the dual-columns when the periods have been >>> disabled. >>> I'd prefer to limit the number of options; so, if the "period duration" is >>> disabled, the report will automatically show dual columns >> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous >> years in the Income statement. >> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge >> >>> (Asset/Income=left, Liability+Equity/Expense = right).
Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp
Frank, I’ve been following this for a while, and perhaps I’m not understanding, but are the groupings just presentational? If that’s the case, I would think the place to address this is in the report options, not the account structure. (you could use any structure you need, and easily re-group based on the rule you decide or need to follow.) Regards, Adrien > On Jul 25, 2018, at 2:53 AM, Frank H. Ellenberger > wrote: > > Am 19.07.2018 um 13:09 schrieb Christopher Lam: >> Hi Frank >> Thank you - I can restore the dual-columns when the periods have been >> disabled. >> I'd prefer to limit the number of options; so, if the "period duration" is >> disabled, the report will automatically show dual columns > > while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous > years in the Income statement. > https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge > >> (Asset/Income=left, Liability+Equity/Expense = right). This works? > >> Can you please show me good examples of idealised T-account balance >> sheet/income statement? Or the scaled form? I have no idea. > > To get an impression you could starting from: > > https://en.wikipedia.org/wiki/Balance_sheet - which has > #US_small_business in account form and #Sample in scaled form - > or > > https://en.wikipedia.org/wiki/Income_statement and an example in account > form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv > > Note: There are several different methods for grouping the positions > with differrent pros and cons allowed for different company types: > Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no > better idea for the grouping than adjusting the account structure. > > Optionally select other languages e.g. > https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz > > HTH > Frank > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
