[GNC-dev] Can a module call a function from another module?
Devs, I have a question to which I can't find an answer. It is possible for a function from a module (say import-ofx) to call a function from another module (declared in "reconcile-window.h" for example). I'm not able to include reconcile-window.h from gnc-ofx-import.cpp , I assume the build isn't setup to include the right headers. But perhaps this is by design and a module isn't supposed to be able to call another one. In that case, how can we make it so a function from a certain module is followed by a call to a function from a different module automatically? J. -- 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Geert > From an implementation point of view I'd structure this slightly > differently: > 1. instead of adding an account property with a list of reconciliation > history, I would introduce a > new object, like a "statement" This object would have the fields you > mention before (date of > reconciliation, statement start date, statement starting balance, > statement end date) and some > more: > *statement id* - most bank statements has a unique number which may be > helpful to track > *statement ending balance* - particularly useful to verify manual > transaction entries. If you > explicitly enter a start and ending balance in addition to the > transactions themselves, amount > typos will be caught by the numbers no longer adding up. > *account" - the account this statement refers to. > > Lastly each split should get an additional field "statement id" referring > to the statement which > includes it. The split "reconciliation date" field would no longer be > necessary. That info is > encapsulated in the associated statement. > > This mapping would be much closer to the real world order of things: > * during reconciliation a split is matched to a line on a statement > * each split can be linked to only one statement > * in case of reconciliation trouble in the past, the extra statement > details make it easier to dig > up the related external source (there's a statement id in addition to a > reconciliation date). > * it is more clear which splits were reconciled together - they are tied > to the same statement, > where in the past there was only a reconciliation date, which may have > been wrong for various > reasons. I also agree that this is a good way to implemnet the idea. It meets what i had in mind for a reconciliation history much better. David - David Cousens -- 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Thanks John for clarifying that. My take on that situation is that the statement start date is TODAY. The statement end date is TODAY and the reconciliation date for any included transactions is TODAY. That is obviously consistent with the manual reconciliation process. David - David Cousens -- 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Adrien, I am referring specifically to setting the reconciliation date for the split you are reconciling. When a transaction is created in GnuCash both the date it was entered into Gnucash and the date it was posted are recorded in the transaction data structure and file. Only the posted date is normally displayed in the register. The posted date should of course be the date relevant to the event which you are recording in your books. The reconciliation date is separate from both of these and is part of the data structure for the split to the account being reconciled that is part of the transaction data It is currently set to the end date for the statement when the reconciliation flag for the split is set to 'y' by the reconciliation. During the import process when an existing transaction is updated from an imported record, it is set to 'c' (cleared) and TODAY, the date at which the importation occurred is recorded in the reconciliation date field. splits set to 'c' are not included in the starting balance calculation for a transaction, only those set to 'y'. WHen they are included in a reconciliation process, then they are set to 'y' and the reconciliation date field is set to the end date of the relevant statement. I believe the above is all kosher and the current situation only arises AFAIK when the user has inadvertently set the end date of a statement to a far future date as I did and then Chris's improvement in 3.9 prevents them from being included in the starting balance sum. My reference was only to the dates the bank records the transactions at in its statement not to any dates recorded for the transaction in GnuCash. I was being very pedantic in the interest of trying to make what I meant clear (but still didn't quite manage it). One problem in all these discussions is always making sure everyone is using the same terminology for the same conceptual structure/objects. I agree adjusting transactions may not have the date of the original transaction and may not necessarily fall within the period encompassing the original transaction at the date recorded in the book and could possibly have been recorded in the future relative to the end of statement date. AFAIK there is nothing which prevents a user from reconciling a future event to the account. These appear in the debits and credits panels in the reconciliation window even if their transaction posted date is after the end of statement date so they can be checked for inclusion in the relevant reconciliation process along with the original transaction they correct - hopefully to the value recorded in the statement. David - David Cousens -- 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Dale, I was referring specifically to the dates the bank puts on transactions included in the statement for a specific period but not necessarily the dates that may have been recorded by a user in GnuCash. The latter of course may be different and the reconciliation process deals with that. I disagree with you however about which date should be recorded as the *reconciliation date* for a split to the specific account you are reconciling for a transaction maked as 'y' (not 'c'). When you do a reconciliation you are confirming that the transactions in your books agree with the transactions in the statement up to the end date of the statement are correct in the amounts recorded and that the balances recorded by the bank and yourself at that date are in agreement. This is the date you are reconciled to not the date at which you entered the transaction into GnuCash or the date at which you posted the transaction (the date at which the event which causes the transaction to be recorded occurred). Both of these dates are already recorded in the Gnucash transaction data structure and recording them as the reconciliation date on a split does not really add any new information. David - David Cousens -- 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
Re: [GNC-dev] About 3.9 and reconciliation balances
David, No, Gunter meant what he said. If the bank's response to a FinTS or OFX DirectConnect query includes a balance, GnuCash will pop a dialog telling you that and allow you to reconcile. If you reconcile it will skip the reconcile info dialog and open the reconcile window with the statement date set to now and the statement balance set to what the bank sent. This dance is separate from the matcher window dance, and the bank-sent-balance dialog pops up at the end of communication rather than waiting for the matcher window to complete. Regards, John Ralls > On Apr 16, 2020, at 8:45 PM, David Cousens wrote: > > hi Geert > > The first was really about directConnect OFX imports, not something I am all > that familiar with since banks here won't allow us access. Another user in > the discussion around Bug 797668 which I initially raised had mentioned > direct reconciliation in the import of OFX directly from the bank. I may > have misunderstood Gunter's comment that that procedure was starting the > reconcile procedure and automaticallly reconciling. I was trying to say > tthat if the bank provided enough information that matched the GnuCash > information, it may be possible to reconcile automatically but I think > Gunter was actually referring to the marking of the transactions as cleared > so it appeared checked when the reconcilaition was initiated. > > Agreed that the statement date is totally independent of the transaction > date. The dates in a statement will all fall between the end date of the > last statement +1 (the start date of the current statement) and the end date > of the current statement as the statement dates are inclusive. > > The importers as far as I can tell so far (OFX and CSV) don't set the > reconcile flag to 'y' only to 'c' and the reconcile date is set to TODAY in > the importing process. This shouldn't affect the manual reconcilaition > process though which should set the reconciliation date to the statement end > date when the flag is set to 'y'. > > I am currently trawling through the code to satisfy myself that I understand > fullywhat is happening and will update the documentation accordingly if the > update i did last year is misleading. > > Davdi > > > > - > David Cousens > -- > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] iOS app
Hello, I developped an iOS app that allows me to view my gnuCash files on iphone or ipad. It shows the list of accounts with totals. It also shows Balance sheet to date, Balance sheet last year, income statement last year and income statement to date. Is this of interest to the community? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Import multiple OFX
Hi Devs, I have code that enables importing multiple OFX in one shot. It's actually *almost* already supported by GC, and required few changes. - The file import dialog needs a new option to allow multiple-file selections - Then there's simply a loop over files using the regular code. This is great for some people (me) whose banks don't combine ofx files, makes the workflow a lot nicer. What do you think, should I do a PR for this? Jean Note: the normal file dialog returns a char* . I added a new type IMPORT_MULTIPLE that enables the multiple file selection, but then the return must be a GSList*. It's easy (and hacky) to masquerade this GSList* as a char*, and this requires no change anywhere else. The alternative is to add 1 input parameter GSList** to the file dialog, but this requires changes in many files since there are no default parameter values in C. -- 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
Re: [GNC-dev] About 3.9 and reconciliation balances
+1 on your idea of the statement as a separate object. If a closing date is later realized to be erroneous, it only needs to be corrected in one place, not every transaction involved. And I hazard the guess that the UI that allows a user to edit a statement object data would be simpler and more straightforward than walking through every transaction looking for suspected bad dates and then making changes. Regards, Adrien > On Apr 15, 2020 w16d106, at 6:14 AM, Geert Janssens > wrote: > > I agree this is useful extra information and also what Christopher Lam has > been playing with. > > From an implementation point of view I'd structure this slightly differently: > 1. instead of adding an account property with a list of reconciliation > history, I would introduce a > new object, like a "statement" This object would have the fields you mention > before (date of > reconciliation, statement start date, statement starting balance, statement > end date) and some > more: > *statement id* - most bank statements has a unique number which may be > helpful to track > *statement ending balance* - particularly useful to verify manual transaction > entries. If you > explicitly enter a start and ending balance in addition to the transactions > themselves, amount > typos will be caught by the numbers no longer adding up. > *account" - the account this statement refers to. > > Lastly each split should get an additional field "statement id" referring to > the statement which > includes it. The split "reconciliation date" field would no longer be > necessary. That info is > encapsulated in the associated statement. > > This mapping would be much closer to the real world order of things: > * during reconciliation a split is matched to a line on a statement > * each split can be linked to only one statement > * in case of reconciliation trouble in the past, the extra statement details > make it easier to dig > up the related external source (there's a statement id in addition to a > reconciliation date). > * it is more clear which splits were reconciled together - they are tied to > the same statement, > where in the past there was only a reconciliation date, which may have been > wrong for various > reasons. > > Regards, > > Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About 3.9 and reconciliation balances
I concur. It is not unusual for a transaction to be made in one period and clear in the next, even in modern times. This is highly probable with issuing a paper check. Lower date bounds are going to be a problem. While I don’t think there is much case (though one user reported so) for a future date (beyond ’today’) there is a case for including a transaction dated past the statement date. If you need to enter a balancing or correcting transaction some users may prefer the date of that transaction be the day it was made, not ‘as of the closing date’. Sticklers for using correcting transactions (as opposed to editing transactions) are likely to prefer such dating. This date can very likely be more than ’closing +1’. Regards, Adrien > On Apr 17, 2020 w16d108, at 9:27 AM, Dale Phurrough via gnucash-devel > wrote: > > As an attempt for clarity, I don't globally agree with what David wrote > "The dates in a statement will all fall between the end date of the last > statement +1 (the start date of the current statement) and the end date of > the current statement as the statement dates are inclusive." > > I believe in the global (as in all scenarios all possibilities) that the > dates for transactions in a statement would be on or before the end date of > the current statement. However, such transactions could also be before the > end date of the last statement. I have countless examples of this where I > caused/made a payment before the end of month and that payment wasn't > booked by a bank until the next month. In this scenario, the date that one > wants in GnuCash might be the causation date or the booking date. > > I believe it is the user's choice of which date to save into GnuCash: > either the date the transaction was caused (e.g. data entry into GnuCash) > or the date the bank finally booked it. So the date should not be lower > bounded by the end date of the last statement. Instead, only upper bounded > by the end date of the current statement. > > Follow my thinking? > > --Dale ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About 3.9 and reconciliation balances
As an attempt for clarity, I don't globally agree with what David wrote "The dates in a statement will all fall between the end date of the last statement +1 (the start date of the current statement) and the end date of the current statement as the statement dates are inclusive." I believe in the global (as in all scenarios all possibilities) that the dates for transactions in a statement would be on or before the end date of the current statement. However, such transactions could also be before the end date of the last statement. I have countless examples of this where I caused/made a payment before the end of month and that payment wasn't booked by a bank until the next month. In this scenario, the date that one wants in GnuCash might be the causation date or the booking date. I believe it is the user's choice of which date to save into GnuCash: either the date the transaction was caused (e.g. data entry into GnuCash) or the date the bank finally booked it. So the date should not be lower bounded by the end date of the last statement. Instead, only upper bounded by the end date of the current statement. Follow my thinking? --Dale On Fri, Apr 17, 2020 at 5:46 AM David Cousens wrote: > hi Geert > > The first was really about directConnect OFX imports, not something I am > all > that familiar with since banks here won't allow us access. Another user in > the discussion around Bug 797668 which I initially raised had mentioned > direct reconciliation in the import of OFX directly from the bank. I may > have misunderstood Gunter's comment that that procedure was starting the > reconcile procedure and automaticallly reconciling. I was trying to say > tthat if the bank provided enough information that matched the GnuCash > information, it may be possible to reconcile automatically but I think > Gunter was actually referring to the marking of the transactions as cleared > so it appeared checked when the reconcilaition was initiated. > > Agreed that the statement date is totally independent of the transaction > date. The dates in a statement will all fall between the end date of the > last statement +1 (the start date of the current statement) and the end > date > of the current statement as the statement dates are inclusive. > > The importers as far as I can tell so far (OFX and CSV) don't set the > reconcile flag to 'y' only to 'c' and the reconcile date is set to TODAY in > the importing process. This shouldn't affect the manual reconcilaition > process though which should set the reconciliation date to the statement > end > date when the flag is set to 'y'. > > I am currently trawling through the code to satisfy myself that I > understand > fullywhat is happening and will update the documentation accordingly if the > update i did last year is misleading. > > Davdi > > > > - > David Cousens > -- > 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 > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
