Re: [GNC-dev] Further feedback
Thanks! And a report example as well as the options to be specified too? On Tue., 5 Feb. 2019, 08:54 Stephen M. Butler On 2/4/19 2:56 PM, Christopher Lam wrote: > > Thank you for detailed algorithm. I'll see about that over next week. > Yup. A lot of work there. > > > > We may have to limit the report to one account for various reasons, > > but will try avoid this. > I could work with that. But a bank statement might trigger a reconcile > for Checking, Saving, Money Market, Visa card (all on one statement). > But it would be four different reconciliations -- all on the same day. > > > > If you have the time and inclination, a test datafile, with crafted > > but realistic amounts, is very welcome. Perhaps about 10 transactions > > of various dates in 3 accounts, fully or partly reconciled (or not) in > > the past, and example report output, will help illustrate. <-- Welcome > > to test-driven development. > > > > C > > > I tried. Hope it is interesting enough. Noticed that some had partial > reconciliations already done. So > > All Asset accounts (low level) and all Liability accounts (lowest level) > should be reconciled at some point. None have been. I removed a bunch > of accounts and transactions to get here. It might not make sense (or > cents either). > > --Steve > > > > > > > On 5/2/19 2:37 am, Stephen M. Butler wrote: > >> Some additional thoughts. > >> In the summary listing at the top of the report, in addition to the > >> last-reconcile-date and fixing the existing amount columns, add one > >> final column which is the account ending balance (which should match the > >> check register or sum of all check registers for that account). It > >> would also be the bank ending balance + outstanding transactions. > >> > >> Also, I selected a Placeholder account plus all the children. In the > >> summary the placeholder account has all zeros in the columns. Suggest > >> that if the account is a placeholder account and the column value is > >> zero, then blank suppress the amount. > >> > >> Column recap: > >> Account -- account name as now shown. Allow option to get the full > >> name. > >> Reconcile-Dt -- Date of most recent reconciliation for the account. > >> Most likely will be today or very recent. > >> Starting -- Sum of all reconciled transactions for this account prior to > >> Reconcile-Dt. AKA -- Bank Starting Balance > >> Reconciled -- Sum of all reconciled transactions for this account on > >> Reconcile-Dt (only those transactions just reconciled). > >> Ending -- Sum of Starting and Reconciled -- AKA Bank Ending Balance. > >> Outstanding -- Sum of all non-reconciled transactions for this account > >> (include future dated transactions). > >> Balance -- Sum of Ending and Outstanding. Should be the account balance > >> shown in the Accounts tab. > >> > >> > >> Note -- on the options Display tab, the Amount can be None, Single or > >> Double. Changing this appears to make no difference in the report. > >> Perhaps it should be removed if it does nothing. > >> > >> Also when selecting all accounts, the summary did list all accounts > >> including those that never had a reconciliation. Perhaps we should > >> impose a filter that the account has to have been reconciled at least > >> once before showing up in this report. I'm thinking maybe add an > >> additional restriction that it has to have been reconciled more recently > >> than x days ago (a really old account that was reconciled years ago is > >> just hanging around but gets included because it was reconciled a > >> century ago -- slight hyperbole!). I would probably pick 100 days as > >> there are accounts that get a statement only quarterly. > >> > >> That way we could pick some options that 80% of the user base could use > >> without having to click on the options button to configure the report: > >> * All accounts > >> * Reconciled within the last 100 days > >> > >> That way the default report would pop up and it would suffice for the > >> vast majority of users. It would only show accounts that had been > >> recently reconciled. > >> > >> --Steve > >> > >> > >> > >> On 2/3/19 6:58 PM, Stephen M. Butler wrote: > >>> On 2/3/19 3:35 AM, Christopher Lam wrote: > Hi Stephen > > If possible I'd be grateful if you would check my branch > maint-scheme-progress > > * cd gnucash > * git fetch --all > * git checkout chris/maint-scheme-progress > * dpkg etc (note there will be gnc-date error - ignore) > > Main issues for feedback: > > * Reconciliation report modified header hopefully is satisfactory > > Thank you, your (and house accountant) feedback *very* much > appreciated! > > >>> git describe > >>> 3.4-104-gacbcc6a1a > >>> > >>> Reconciliation report. Looks like I can no longer select the date for > >>> the reconciliation. I had done one a few days ago. At this point it > >>> showed only the un-reconciled
Re: [GNC-dev] Further feedback
On 2/4/19 2:56 PM, Christopher Lam wrote: > Thank you for detailed algorithm. I'll see about that over next week. Yup. A lot of work there. > > We may have to limit the report to one account for various reasons, > but will try avoid this. I could work with that. But a bank statement might trigger a reconcile for Checking, Saving, Money Market, Visa card (all on one statement). But it would be four different reconciliations -- all on the same day. > > If you have the time and inclination, a test datafile, with crafted > but realistic amounts, is very welcome. Perhaps about 10 transactions > of various dates in 3 accounts, fully or partly reconciled (or not) in > the past, and example report output, will help illustrate. <-- Welcome > to test-driven development. > > C I tried. Hope it is interesting enough. Noticed that some had partial reconciliations already done. So All Asset accounts (low level) and all Liability accounts (lowest level) should be reconciled at some point. None have been. I removed a bunch of accounts and transactions to get here. It might not make sense (or cents either). --Steve > > On 5/2/19 2:37 am, Stephen M. Butler wrote: >> Some additional thoughts. >> In the summary listing at the top of the report, in addition to the >> last-reconcile-date and fixing the existing amount columns, add one >> final column which is the account ending balance (which should match the >> check register or sum of all check registers for that account). It >> would also be the bank ending balance + outstanding transactions. >> >> Also, I selected a Placeholder account plus all the children. In the >> summary the placeholder account has all zeros in the columns. Suggest >> that if the account is a placeholder account and the column value is >> zero, then blank suppress the amount. >> >> Column recap: >> Account -- account name as now shown. Allow option to get the full >> name. >> Reconcile-Dt -- Date of most recent reconciliation for the account. >> Most likely will be today or very recent. >> Starting -- Sum of all reconciled transactions for this account prior to >> Reconcile-Dt. AKA -- Bank Starting Balance >> Reconciled -- Sum of all reconciled transactions for this account on >> Reconcile-Dt (only those transactions just reconciled). >> Ending -- Sum of Starting and Reconciled -- AKA Bank Ending Balance. >> Outstanding -- Sum of all non-reconciled transactions for this account >> (include future dated transactions). >> Balance -- Sum of Ending and Outstanding. Should be the account balance >> shown in the Accounts tab. >> >> >> Note -- on the options Display tab, the Amount can be None, Single or >> Double. Changing this appears to make no difference in the report. >> Perhaps it should be removed if it does nothing. >> >> Also when selecting all accounts, the summary did list all accounts >> including those that never had a reconciliation. Perhaps we should >> impose a filter that the account has to have been reconciled at least >> once before showing up in this report. I'm thinking maybe add an >> additional restriction that it has to have been reconciled more recently >> than x days ago (a really old account that was reconciled years ago is >> just hanging around but gets included because it was reconciled a >> century ago -- slight hyperbole!). I would probably pick 100 days as >> there are accounts that get a statement only quarterly. >> >> That way we could pick some options that 80% of the user base could use >> without having to click on the options button to configure the report: >> * All accounts >> * Reconciled within the last 100 days >> >> That way the default report would pop up and it would suffice for the >> vast majority of users. It would only show accounts that had been >> recently reconciled. >> >> --Steve >> >> >> >> On 2/3/19 6:58 PM, Stephen M. Butler wrote: >>> On 2/3/19 3:35 AM, Christopher Lam wrote: Hi Stephen If possible I'd be grateful if you would check my branch maint-scheme-progress * cd gnucash * git fetch --all * git checkout chris/maint-scheme-progress * dpkg etc (note there will be gnc-date error - ignore) Main issues for feedback: * Reconciliation report modified header hopefully is satisfactory Thank you, your (and house accountant) feedback *very* much appreciated! >>> git describe >>> 3.4-104-gacbcc6a1a >>> >>> Reconciliation report. Looks like I can no longer select the date for >>> the reconciliation. I had done one a few days ago. At this point it >>> showed only the un-reconciled transactions. >>> >>> This summary at the top was interesting (I selected a parent with 3 >>> children): >>> >>> Account Starting Reconciled Ending >>> BECU $0.00 $0.00 $0.00 >>> Checking $1,591.23 $1,591.23 $4,039.74 >>> Money Market $1,004.44 $1,004.44 $17,004.61 >>> Savings
Re: [GNC-dev] Further feedback
Thank you for detailed algorithm. I'll see about that over next week. We may have to limit the report to one account for various reasons, but will try avoid this. If you have the time and inclination, a test datafile, with crafted but realistic amounts, is very welcome. Perhaps about 10 transactions of various dates in 3 accounts, fully or partly reconciled (or not) in the past, and example report output, will help illustrate. <-- Welcome to test-driven development. C On 5/2/19 2:37 am, Stephen M. Butler wrote: Some additional thoughts. In the summary listing at the top of the report, in addition to the last-reconcile-date and fixing the existing amount columns, add one final column which is the account ending balance (which should match the check register or sum of all check registers for that account). It would also be the bank ending balance + outstanding transactions. Also, I selected a Placeholder account plus all the children. In the summary the placeholder account has all zeros in the columns. Suggest that if the account is a placeholder account and the column value is zero, then blank suppress the amount. Column recap: Account -- account name as now shown. Allow option to get the full name. Reconcile-Dt -- Date of most recent reconciliation for the account. Most likely will be today or very recent. Starting -- Sum of all reconciled transactions for this account prior to Reconcile-Dt. AKA -- Bank Starting Balance Reconciled -- Sum of all reconciled transactions for this account on Reconcile-Dt (only those transactions just reconciled). Ending -- Sum of Starting and Reconciled -- AKA Bank Ending Balance. Outstanding -- Sum of all non-reconciled transactions for this account (include future dated transactions). Balance -- Sum of Ending and Outstanding. Should be the account balance shown in the Accounts tab. Note -- on the options Display tab, the Amount can be None, Single or Double. Changing this appears to make no difference in the report. Perhaps it should be removed if it does nothing. Also when selecting all accounts, the summary did list all accounts including those that never had a reconciliation. Perhaps we should impose a filter that the account has to have been reconciled at least once before showing up in this report. I'm thinking maybe add an additional restriction that it has to have been reconciled more recently than x days ago (a really old account that was reconciled years ago is just hanging around but gets included because it was reconciled a century ago -- slight hyperbole!). I would probably pick 100 days as there are accounts that get a statement only quarterly. That way we could pick some options that 80% of the user base could use without having to click on the options button to configure the report: * All accounts * Reconciled within the last 100 days That way the default report would pop up and it would suffice for the vast majority of users. It would only show accounts that had been recently reconciled. --Steve On 2/3/19 6:58 PM, Stephen M. Butler wrote: On 2/3/19 3:35 AM, Christopher Lam wrote: Hi Stephen If possible I'd be grateful if you would check my branch maint-scheme-progress * cd gnucash * git fetch --all * git checkout chris/maint-scheme-progress * dpkg etc (note there will be gnc-date error - ignore) Main issues for feedback: * Reconciliation report modified header hopefully is satisfactory Thank you, your (and house accountant) feedback *very* much appreciated! git describe 3.4-104-gacbcc6a1a Reconciliation report. Looks like I can no longer select the date for the reconciliation. I had done one a few days ago. At this point it showed only the un-reconciled transactions. This summary at the top was interesting (I selected a parent with 3 children): Account Starting Reconciled Ending BECU $0.00 $0.00 $0.00 Checking $1,591.23 $1,591.23 $4,039.74 Money Market $1,004.44 $1,004.44 $17,004.61 Savings $454.09 $454.09 $486.21 With apologies to wm, and warning therefore that TMI is forthcoming (wm, skip to next email to avoid being offended). At first I was expecting the Reconciled column to show what had been reconciled in the last pass. However, it shows everything that had been reconciled up to that point. My question now is, when would those first two columns be different after the first reconciliation? The Ending column appears to go into the future. My checking register has upcoming entries that I know will happen so I an forecast if the account will be overdrawn at any point. I'm wondering if it shouldn't end at today. I then reconciled the bottom two accounts and noted: 1. Unable to locate the option to see the reconciled transactions. I should be able to see the transactions just reconciled (most recent date reconciled). 2. The bottom two accounts had all three columns the same as the ending figures
Re: [GNC-dev] Further feedback
Some additional thoughts. In the summary listing at the top of the report, in addition to the last-reconcile-date and fixing the existing amount columns, add one final column which is the account ending balance (which should match the check register or sum of all check registers for that account). It would also be the bank ending balance + outstanding transactions. Also, I selected a Placeholder account plus all the children. In the summary the placeholder account has all zeros in the columns. Suggest that if the account is a placeholder account and the column value is zero, then blank suppress the amount. Column recap: Account -- account name as now shown. Allow option to get the full name. Reconcile-Dt -- Date of most recent reconciliation for the account. Most likely will be today or very recent. Starting -- Sum of all reconciled transactions for this account prior to Reconcile-Dt. AKA -- Bank Starting Balance Reconciled -- Sum of all reconciled transactions for this account on Reconcile-Dt (only those transactions just reconciled). Ending -- Sum of Starting and Reconciled -- AKA Bank Ending Balance. Outstanding -- Sum of all non-reconciled transactions for this account (include future dated transactions). Balance -- Sum of Ending and Outstanding. Should be the account balance shown in the Accounts tab. Note -- on the options Display tab, the Amount can be None, Single or Double. Changing this appears to make no difference in the report. Perhaps it should be removed if it does nothing. Also when selecting all accounts, the summary did list all accounts including those that never had a reconciliation. Perhaps we should impose a filter that the account has to have been reconciled at least once before showing up in this report. I'm thinking maybe add an additional restriction that it has to have been reconciled more recently than x days ago (a really old account that was reconciled years ago is just hanging around but gets included because it was reconciled a century ago -- slight hyperbole!). I would probably pick 100 days as there are accounts that get a statement only quarterly. That way we could pick some options that 80% of the user base could use without having to click on the options button to configure the report: * All accounts * Reconciled within the last 100 days That way the default report would pop up and it would suffice for the vast majority of users. It would only show accounts that had been recently reconciled. --Steve On 2/3/19 6:58 PM, Stephen M. Butler wrote: > On 2/3/19 3:35 AM, Christopher Lam wrote: >> Hi Stephen >> >> If possible I'd be grateful if you would check my branch >> maint-scheme-progress >> >> * cd gnucash >> * git fetch --all >> * git checkout chris/maint-scheme-progress >> * dpkg etc (note there will be gnc-date error - ignore) >> >> Main issues for feedback: >> >> * Reconciliation report modified header hopefully is satisfactory >> >> Thank you, your (and house accountant) feedback *very* much appreciated! >> > git describe > 3.4-104-gacbcc6a1a > > Reconciliation report. Looks like I can no longer select the date for > the reconciliation. I had done one a few days ago. At this point it > showed only the un-reconciled transactions. > > This summary at the top was interesting (I selected a parent with 3 > children): > > Account Starting Reconciled Ending > BECU $0.00 $0.00 $0.00 > Checking $1,591.23 $1,591.23 $4,039.74 > Money Market $1,004.44 $1,004.44 $17,004.61 > Savings $454.09 $454.09 $486.21 > > With apologies to wm, and warning therefore that TMI is forthcoming (wm, > skip to next email to avoid being offended). > > At first I was expecting the Reconciled column to show what had been > reconciled in the last pass. However, it shows everything that had been > reconciled up to that point. My question now is, when would those first > two columns be different after the first reconciliation? > > The Ending column appears to go into the future. My checking register > has upcoming entries that I know will happen so I an forecast if the > account will be overdrawn at any point. I'm wondering if it shouldn't > end at today. > > I then reconciled the bottom two accounts and noted: > > 1. Unable to locate the option to see the reconciled transactions. I > should be able to see the transactions just reconciled (most recent date > reconciled). > > 2. The bottom two accounts had all three columns the same as the ending > figures above. In this case I would expect: > > A. Starting column would have the account balance prior to the > transactions reconciled in this just finished action (most recent date > reconciled). > > B. The reconciled column would have the total reconciled. In this > case I think you need two numbers. Total credits and total debits > reconciled. > > C. Ending column should be the account balance just after the >
Re: [GNC-dev] obfuscation script, windows/Perl SheBang
Am Montag, 4. Februar 2019, 16:32:38 CET schrieb John Ralls: > >>> Thanks for the pointer. I've copied this script into our git at > >>> > >>> ./util/obfuscate.pl > >> > >> While for most gnc-fq-* scripts we us > >> #!@-PERL-@ > >> and adjust them while building. > >> > >> In utils all perl scripts are hardcoded to > >> #! /usr/bin/perl > >> Wouldn't it make sense to have them also configurable? > > No, because gnc-fq-* are build products and util/*.pl are build tools. Since > obfuscate.pl isn't a build tool it doesn't belong in util; if we're going > to distribute it for users (and if we're not why put it in the repo at > all?) then it needs to go somewhere Cmake can find it and install it to > $CMAKE_INSTALL_PREFIX/bin or libexec and it needs to be renamed to > "gnc-xml-obfuscate". Sure. Since it's code and I wanted to edit it, I wanted to put it somewhere in git. If there is a better place for it, please anyone feel free to move it there. > > How about going: > > > > #! /usr/bin/env perl > > That's widely regarded as a security hole, though it's also widely used. > Since it's trivial to override the shebang by calling the perl of your > choice and passing the script as $1 it's kind of pointless. > > While we're on the topic of shebangs remember that they don't work on > Windows. Remember too that running this obfuscate script on Windows will > require the user to install perl. They might already have done so for > Finance::Quote, but lots of users don't use F::Q. The script won't work on Windows anyway, at least not out of the box, because it not only needs a Perl installation including XML::DOM, but also some word list. On Linux this is available under /usr/share/dict/words (symlink to the default language's word list), but for windows some other choice has to be written into the obfuscate.pl script. Currently this isn't the case, so it will just complain about the missing word list. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Perl SheBang
> On Feb 4, 2019, at 1:27 AM, Alain D D Williams wrote: > > On Mon, Feb 04, 2019 at 10:23:46AM +0100, Frank H. Ellenberger wrote: >> >> >> Am 04.02.19 um 09:40 schrieb Christian Stimming: >>> Thanks for the pointer. I've copied this script into our git at >>> ./util/obfuscate.pl >> >> While for most gnc-fq-* scripts we us >> #!@-PERL-@ >> and adjust them while building. >> >> In utils all perl scripts are hardcoded to >> #! /usr/bin/perl >> Wouldn't it make sense to have them also configurable? No, because gnc-fq-* are build products and util/*.pl are build tools. Since obfuscate.pl isn't a build tool it doesn't belong in util; if we're going to distribute it for users (and if we're not why put it in the repo at all?) then it needs to go somewhere Cmake can find it and install it to $CMAKE_INSTALL_PREFIX/bin or libexec and it needs to be renamed to "gnc-xml-obfuscate". > > How about going: > > #! /usr/bin/env perl That's widely regarded as a security hole, though it's also widely used. Since it's trivial to override the shebang by calling the perl of your choice and passing the script as $1 it's kind of pointless. While we're on the topic of shebangs remember that they don't work on Windows. Remember too that running this obfuscate script on Windows will require the user to install perl. They might already have done so for Finance::Quote, but lots of users don't use F::Q. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Test
The mailman output queue got hung up during the upgrades and mail was being received but not sent. I restarted the queue runners and mail started flowing, but it took a while to clear out the queue. The queue was empty when I went to bed. -derek Sent using my mobile device. Please excuse any typos. On February 4, 2019 5:26:17 AM Liz wrote: On Sun, 03 Feb 2019 21:21:22 -0500 Derek Atkins wrote: Testing mailman... -derek It's fine, the spam is arriving in a normal fashion. Thanks for the efforts you are making to keep all running. Liz ___ 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] Normalizing live data, a suggestion for discussion
Op zaterdag 2 februari 2019 22:36:18 CET schreef Wm via gnucash-devel: > On 02/02/2019 15:24, Geert Janssens wrote: > > As for Colin's question: on Windows and MacOS sqlite is supported out of > > the box. On linux it may require the additional installation of a libdbi > > driver. Most distros I know have packages for this driver but they may > > not be installed by default. > > It would be an odd distro that excluded SQLite, it is a requisite for a > lot of other stuff like browsers. Thinking aloud: maybe a server only > install might not have it or someone stupid enough to put their data on > Amazon might not have it available. The question then becomes, why was > the person so stupid? Well I do understand sqlite is available by default, but gnucash requires libdbi with the sqlite backend (which in turn indeed uses sqlite). I haven't checked whether all supported distros also have that combination installed by default. I don't know if webbrowsers also use libdbi. I know firefox does not. And I haven't and won't spend time to check this for all those distros. However I do agree this should only be a small hurdle. And I understand your script is an optional aid for those people that would want a better privacy guarantee before sending their data in for analysis. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
Op zaterdag 2 februari 2019 22:36:18 CET schreef Wm via gnucash-devel: > On 02/02/2019 15:24, Geert Janssens wrote: > > Yes, if you use business features, you may have entered business > > identifying data in File->Properties. It think that's what David is > > referring to. > I agree, the third party should not be identified. > > > Similarly there may be customer and vendor data (names addresses) in the > > book that should equally be obfuscated. Just random data is fine. > > Yes. > > Geert, at the moment I am putting guid in place of random, do you think > that is a wrong way to approach this? > I think GUIDs are probably fine as well. Note I'm going by the theoretical goal of not being able to reconstruct the user's real financial data from the obfuscated file. Personally I'm not interested in doing that at all, but people's paranoia levels may vary. So talking of guids. If I remember correctly the default guids for accounts coming from gnucash account templates are hard-coded (or at least they used to be until somewhere in the 2.6 series. So if that is still true then guid for account names is only fake obfuscation. And perhaps these guids should be replaced throughout the book during the obfuscation before replacing account names with guids > Actually, the nearer we get to complete random the less useful the file > becomes. Actual random data is harder than most people think and pretty > much defeats the purpose if you think about it. > >From a human's point of view a guid is just random numbers. So I don't see how that makes a difference. If the same random value is used where the data was the same in the original book, it's just like using a guid. And I'm no talking of numbers for this part, I'm talking about customer names, vendor addresses, that kind of stuff. > > Continuing on that vein, if you have bills and invoices, aside from > > randomizing the transaction's split amounts and values you'll also have to > > do the same for invoice entries. > > I don't think that is true in most situations and even if what you say > is true, I don't see it as a good argument against *attempting* a > normalized book for most people. > It's true if the bug to investigate is somewhere in the business code. In that case what your invoice data says should match what the resulting transactions say. Those are stored in different parts in the book, but are interrelated. But even if the bug is not in business data, the business data should be properly anonymized or removed anyway such that the user can confidently share it without risking real financial or private info can be extracted from it. Of course in that context the business data no longer has to be consistent though I still believe it makes debugging harder if it isn't. > > And to make the book useful for detecting > > business data bugs this should happen in such a way that invoice tax and > > discount amounts remain consistent after multiplying with random numbers > > *and* that the invoice totals continue to match the business transactions > > amounts in AR/AP accounts. > > There will be situations that involve the person doing the triage > needing to see actual transactions, I have already commented on that. > Sure. However that's not what I'm implying here. The extra business requirements are an extension of your initial concept that transactions should continue to balance. From a business data point of view invoices with their entries should continue to balance with their invoice transactions or the data quickly becomes meaningless. > > And to make that one level more complicated, after that the payment > > transactions *also* have to continue to match the new randomized invoice > > amount (if the invoice was paid in full). > > U, I don't think that is true. If the munged numbers match (and > they will, that is what the script will do) the transaction stream will > be OK. > > It is possible I have missed your point, Geert, but I think it is > looking like I understand the contents of the gnc files better than you :( > You did miss the point. You only think of balancing transactions. I'm also thinking of balancing lots, a more hidden aspect of the business data that's crucial to debug payment issues. My next reservation was also about consistent lots. > > It doesn't end there, payments can be split over multiple invoices, so > > again when one randomizes invoice amounts care must be taken to adjust > > the payments in proportion to the invoice amount change or fully paid > > invoices suddenly can become partially paid or overpaid. > > Not true. > > Geert, I don't want to say this but I believe you are actually wrong, > for once. It would be more useful to explain why you think that. > > > While this is probably all possible I believe the resulting script will be > > so complex that it will become a source of bugs in itself which would > > divert developer time to debugging and maintaining this script
Re: [GNC-dev] Test
On Sun, 03 Feb 2019 21:21:22 -0500 Derek Atkins wrote: > Testing mailman... > -derek It's fine, the spam is arriving in a normal fashion. Thanks for the efforts you are making to keep all running. Liz ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Perl SheBang
On Mon, Feb 04, 2019 at 10:23:46AM +0100, Frank H. Ellenberger wrote: > > > Am 04.02.19 um 09:40 schrieb Christian Stimming: > > Thanks for the pointer. I've copied this script into our git at > > ./util/obfuscate.pl > > While for most gnc-fq-* scripts we us > #!@-PERL-@ > and adjust them while building. > > In utils all perl scripts are hardcoded to > #! /usr/bin/perl > Wouldn't it make sense to have them also configurable? How about going: #! /usr/bin/env perl -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/contact.php #include ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Perl SheBang
Am 04.02.19 um 09:40 schrieb Christian Stimming: > Thanks for the pointer. I've copied this script into our git at > ./util/obfuscate.pl While for most gnc-fq-* scripts we us #!@-PERL-@ and adjust them while building. In utils all perl scripts are hardcoded to #! /usr/bin/perl Wouldn't it make sense to have them also configurable? Regards Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing/obfuscating live data
Am Sonntag, 3. Februar 2019, 17:03:06 CET schrieb John Ralls: > > On Feb 2, 2019, at 8:10 PM, David Carlson > > wrote: > > > > OK, I want to try https://wiki.gnucash.org/wiki/ObfuscateScript but I am > > not a computer programmer. I have no clue how to use it. Can someone > > help me? Thanks for the pointer. I've copied this script into our git at ./util/obfuscate.pl The script manages to process my 50MB file in approx. 30 seconds. The account and txn texts are all nicely obfuscated. The script also contains a random obfuscation for the amounts, which will simply cause lots of transactions to the equity account upon loading, but this could be enabled as well. In a real data file there are still more places with text that need to be modified, e.g. the scheduled transaction templates, bayes import matching, and such. Also, the dates are left unmodified which may or may not be a problem. Anyone please feel free to check with this script and add more obfuscation steps. I would like to achieve a state where the script will obfuscate my personal data file enough so that I feel I can make it available as a test file. Usage of the script: Save your normal file in uncompressed form to XML file. Then, ./obfuscate.pl inputfile.gnucash > outputfile.gnucash (Contrary to the comments, the output is just written to stdout, not in-place into the file.) Thanks for the idea here! Regards, Christian > Run it from a command line using perl, assuming here that you have > Strawberry installed on C: > > c:\strawberry\perl\bin\perl.exe ObfuscateScript path/to/myfile.gnucash > > Note that it rewrites the file in place, so make a copy and run it on that. > The file needs to be uncompressed. > > Regards, > John Ralls > > ___ > 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
