openpetraorg-financeexperts Mailing List for OpenPetra
Free Administration Software for Non-Profits
Brought to you by:
christiankatict,
pokorra
Menu
▾
▴
openpetraorg-financeexperts — notification emails for SubForum of finance experts and developers
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
(18) |
Apr
(28) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
|
Jun
(8) |
Jul
|
Aug
|
Sep
(6) |
Oct
(3) |
Nov
(2) |
Dec
(2) |
| 2013 |
Jan
(14) |
Feb
(4) |
Mar
(6) |
Apr
|
May
(5) |
Jun
(3) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ro...@op...> - 2014-06-11 11:54:18
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=969#p969">"Display local Cost Centres first" option in Trial Balance</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=969#p969"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=124">tim-ingham</a></strong> » Wed Jun 11, 2014 11:30 am </p> <div class="content">I'm looking at the mantis bug 0003054: <span style="font-weight: bold">Add "Display local Cost Centres first" option to 'Trial Balance' report</span>:<br /><br /><a href="https://tracker.openpetra.org/view.php?id=3054" class="postlink">https://tracker.openpetra.org/view.php?id=3054</a><br /><br />Rob says that Petra originally produced the trial balance with Cost Centres sorted alphabetically, but in some cases this would cause Foreign Cost Centres to appear among Local ones, so the "Display local Cost Centres first" option was added and it brought better order to the report.<br /><br />So my question is, shouldn't we just do this anyway, and not provide the option? Isn't "Display local Cost Centres first" simply the obvious way to go?<br /><br />(The background to this is, although it's really easy to tweak the report so that local cost centres always come first, it's a nuisance to tweak the User Interface and provide this option . When its utility is in doubt, it seems better to me to leave off the option for near term, while providing the sorting as standard behaviour.)</div> |
|
From: <ro...@op...> - 2014-05-06 20:04:49
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=959#p959">Showing International Currency Column</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=959#p959"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=93">ctopenpetra</a></strong> » Tue May 06, 2014 3:23 pm </p> <div class="content">In Petra, the Gift batch screens do not show the international currency amount, but just the other two currency amounts (i.e. transaction currency amount and ledger base currency amount), whereas the GL batch screens show all three.<br /><br />Currently, in OP we only show the two, i.e. transaction currency and base currency amounts, to the user, for both GL & Gift batch. Do we need to show the international currency amount as well on GL or even GL & Gift?<br /><br />The benefit of not showing it is that the value can simply be computed at posting time and is then available for reporting etc. on posted batches.<br /><br />The benefit of showing OM's international currency column is that the information it provides (i.e. the amount in USD) may be useful to the user for various reasons during the data entry, pre-posting process.<br /><br />Any comments, please?<br /><br />Thanks<br /><br />Chris</div> |
|
From: <ro...@op...> - 2013-07-22 11:54:21
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=862#p862">AP: Should over-payment be allowed?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=862#p862"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=124">tim-ingham</a></strong> » Mon Jul 22, 2013 11:16 am </p> <div class="content">In Open Petra, a warning is generated when the user selects "partial payment", then sets the payment amount to more than the outstanding amount. If the user confirms that the figure is OK, the payment is made.<br /><br />Rob says that in Petra this is an error - the user is not allowed to pay more than is due.<br /><br />What do we think we should do?</div> <h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=863#p863">AP: Consolidation of payments</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=863#p863"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=124">tim-ingham</a></strong> » Mon Jul 22, 2013 11:23 am </p> <div class="content">When a number of AP payments are made in Petra, the payments are "consolidated" so that only one transaction is created to debit the AP account and one to credit the Bank Account, regardless of how many invoices there were.<br /><br />In open Petra, a pair of transactions is created for each payment.<br /><br />The result is the same, but perhaps we think that consolidating multiple payments has benefit?</div> |
|
From: <ro...@op...> - 2013-06-27 10:54:19
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=853#p853">Re: AP - All invoices are "Approved"</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=853#p853"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=90">simonyeomans</a></strong> » Thu Jun 27, 2013 10:28 am </p> <div class="content">Personally I would be for retaining the current Petra model in four stages:<br />Open - Approved - Posted - Paid<br />Approval is such a simple step that I cannot see why including it would be a problem.<br />Open corresponds to receiving the invoice and entering it in the system. This is very different to approval, since the invoice may need to be checked by someone other than the bookkeeper.</div> |
|
From: <ro...@op...> - 2013-06-25 11:54:21
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=852#p852">AP - All invoices are "Approved"</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=852#p852"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=124">tim-ingham</a></strong> » Tue Jun 25, 2013 11:43 am </p> <div class="content">At present in Open Petra, all invoices are set as "Approved" when they are created, but the implementation isn't "clean" - it's inconsistent, because these invoices are editable even though they are approved.<br /><br />I think as a minimum we need to do one of two things:<br /><br /> 1) We can leave out approval and use the "open" status instead, modifying "Post" so that invoices don't require approval,<br /> 2) We can implement approval and make approved invoices read-only. "Post" would not work on "open" invoices.<br /><br />We heard that some discussion amongst finance people shows a division of opinion, with some users wanting approvals to be implemented, and some not wanting it.<br /><br />Will it be appropriate for us to implement both 1) and 2) above, with a configuration option that sets the system to either requiring or not requiring approval? This is relatively straightforward for u s to do - the most difficult question is where we should put the UI for setting the option.<br /><br />Comments?</div> |
|
From: <ro...@op...> - 2013-06-24 11:54:18
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=850#p850">Report: Field Leader Gift Summary 2</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=850#p850"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=124">tim-ingham</a></strong> » Mon Jun 24, 2013 11:02 am </p> <div class="content">I am looking at this "Field Leader Gift Summary 2" report, because in OpenPetra it's "obviously not right" at the moment.<br /><br />If anyone can tell me in detail what this report is supposed to do, that would be helpful!<br /><br />The report requires only a date range - it then makes a list of accounts, and for each account a list of cost codes, and for each combination it reports all transactions within the date range.<br /><br />In the current OpenPetra implementation it's clearly not right - it takes massively too long to calculate the report, and then produces a massive printout, most of which may be "empty" transactions - i.e. an account / cost centre combination that had no transactions during the requested period.<br /><br />Would anyone like to tell me in detail what the report should attempt to communicate?</div> |
|
From: <ro...@op...> - 2013-05-28 09:54:22
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=838#p838">Re: Multiple email-Addresses in *one* Partner Address required?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=838#p838"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=71">christiankatict</a></strong> » Tue May 28, 2013 9:00 am </p> <div class="content"><span style="font-weight: bold">Hi Timo,</span><br /><br />thanks for thinking about this further!<br /><br />I had a look at how it is done in TntMPD and can't see an option how to enter e-mail addresses for husband and wife separately, though I saw that one can enter their names separately.<br /><br />Here you can see how e-mail addresses are entered/maintained in TntMPD:<br /><a href="https://www.tntware.com/tntmpd/help/en/pages/contacts_emailaddresses.aspx" class="postlink">https://www.tntware.com/tntmpd/help/en/pages/contacts_emailaddresses.aspx</a><br />So they concatenate e-mail addresses where 'Preferred' next to the email has got a tick into the 'Preferred Email' shown at the top.<br /><br />Our plan for OpenPetra, however, is to have a ComboBox from which a 'Primary E-Mailâ can be selected (from among any of the Contact Detail Records that are for an e-mail). If we would want to follow the approach of TntMPD we would need to add a âPrefer redâ CheckBox to the Detail section of a Partner Contact Detail record, but only for e-mail-type detail sections. Because of other ComboBoxes on the same screen that have somewhat similar effects we would prefer to keep the approach with the ComboBox from which a 'Primary E-Mailâ can be selected. <br />The other difficulty is that OpenPetra will allow not only the selection of a 'Primary E-Mail' from a ComboBox, but for Partners of Partner Class PERSON also of an 'Office E-Mail', again from a ComboBox. That is where the approach with 'Default' CheckBoxes would fall short as it could not designate multiple 'Office E-Mail' addresses that would be different from the 'Primary E-Mail'.<br /><br /><span style="font-style: italic">Fortunately,</span> I think I have finally found a workable solution that will allow us to have multiple e-mail addresses in a single special TextBox Control which turns multiple e-mail-Adresses into multiple clickable hyperlinks if the TextBox is not edited. Up till now I couldn't do that, but that now looks feasible. That is probably the best implementation option and preferred by Matthias. OpenPetra's 'Primary E-Mailâ ComboBox would then simply hold entries with single or multiple email addresses for selection.<br /><br /><br />Apart from that, OpenPetra will allow entry of 0..n email addresses for any Partner Class, of which one email address record can become the 'Primary E-Mailâ for the Partner (which, with the discussed change, could be multiple email addresses entered in a single TextBox of a single record). <br />Comments can be entered for every email address, hence it will be possible to record separate email addresses for the husband and for the wife, and to add a comment to each so it is known which one is for whom. A 'Primary E-Mailâ can then be selected for the family. That was deemed sufficient by all who reviewed the implementation proposal.<br />If one really needs the 'Primary E-Mailâ to be a c oncatenation of multiple email addresses (like in the example you have given for OM Germany) then one could add a contact detail record that holds both email addresses in concatenated form and then set this one to be the 'Primary E-Mailâ but (optionally) one could have two separate contact detail records in addition for the email address of husband and wife... (Alternatively, if one doesn't want to create those two optional records then a simple comment added to the record that holds the email address in concatenated form can be used to describe which one is for the husband and which one is for the wife.)<br /><br /><br />Thanks,<br /><br /><br />ChristianK</div> |
|
From: <ro...@op...> - 2013-05-28 05:54:21
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=837#p837">Re: Multiple email-Addresses in *one* Partner Address required?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=837#p837"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=67">pokorra</a></strong> » Tue May 28, 2013 5:49 am </p> <div class="content">Hello Christian,<br />just thinking about this again.<br />It might be worth looking at TntMPD, how they have done it.<br /><!-- m --><a class="postlink" href="http://www.tntware.com/tntmpd/">http://www.tntware.com/tntmpd/</a><!-- m --><br /><br />I have not looked at it myself, but at OM Germany I was told that there are two columns for couples, so you can add different surname, but also different email address, for the members of a family.<br />I guess this is something to be considered in the long run, especially in our ongoing discussion about FAMILY partner type.<br /><br />Timo</div> |
|
From: <ro...@op...> - 2013-05-27 10:54:19
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=836#p836">Re: Multiple email-Addresses in *one* Partner Address required?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=836#p836"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=71">christiankatict</a></strong> » Mon May 27, 2013 10:02 am </p> <div class="content">Hi Timo,<br /><br /><br />yes, that scenario makes sense!<br /><br />I thought of the example you have provided myself, but wasn't sure whether that scenario is 'constructed' / far-fetched or whether OM offices are actually doing that/relying on that feature in that way.<br /><br /><br />Thanks,<br /><br /><br />ChristianK</div> |
|
From: <ro...@op...> - 2013-05-27 09:54:23
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=834#p834">Re: Interesting article about accounting in Not-For-Profit Orgs</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=834#p834"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=67">pokorra</a></strong> » Mon May 27, 2013 9:36 am </p> <div class="content">Alwyn replied via Email:<br /><blockquote class="uncited"><div>Thanks for this very good article and that is some of the issues we are currently struggle to work through at the moment.</div></blockquote></div> <h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=833#p833">Multiple email-Addresses in *one* Partner Address required?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=833#p833"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=71">christiankatict</a></strong> » Mon May 27, 2013 9:32 am </p> <div class="content"><span style="font-weight: bold">Hi all,</span><br /><br />In Petra 2.x it is possible to enter <span style="font-style: italic">multiple</span> E-mail Addresses for a <span style="font-style: italic">single</span> Address record. The valid formats for that are âme...@th..., <!-- e --><a href="mailto:yo...@al...">yo...@al...</a><!-- e -->â and âme...@th...; <!-- e --><a href="mailto:yo...@al...">yo...@al...</a><!-- e -->; <!-- e --><a href="mailto:ano...@he...">ano...@he...</a><!-- e -->â (comma and semicolon are the valid separators, and there is no limit on how many e-mail addresses can be entered in that way).<br /><br />Now, if one enters multiple E-mail-Addresses for a single Address and that Address is the <span style="font-style: italic">âBest Addressâ</span> in Petra 2.x, Petra will send an email to all those e-mail addresses <span style="font-style: italic">simultaneously</sp an> in situations where e-mails should be sent by Petra 2.x (by adding them all in the âToâ field of the e-mail application).<br />If âSend Emailâ is chosen in the File Menu of the Partner Edit screen this would happen with the <span style="font-style: italic">highlighted</span> Address record (though the âBest Addressâ will be the one that is highlighted if a Partner Edit screen is opened [unless if opened from Partner Find, there the Address that is selected in Partner Find will be highlighted]).<br /><br /><span style="font-weight: bold">We wonder if there is need to retain the ability to send an email to multiple e-mail addresses at once in OpenPetra. </span> (It would be simpler if this feature would not need to be retained.)<br /><br /><br />When discussing this in the team, RobP wrote: <br /><blockquote class="uncited"><div>I could envisage the situation where finance users might want to have more than one recipient Email associated with a Cost Centre (for example where that CC represents a department) so that Cost Centre I&E and Account Detail reports get auto-emailed to multiple recipients. Iâm not certain that this is happening but I wouldnât want to assume that it isnât!<br /></div></blockquote><br /><br /><ul><li>Do you know wheter the practice that Rob mentions is in use like that?</li><li>Do you know of other reasons why the ability to record multiple E-mail addresses per Address might need to retained in OpenPetra, esp. seen from the finance users' perspective?</li></ul><br />Please come back to me as soon as possible by replying to this Forum post.<br /><br /><br />Kind regards,<br /><br /><br />ChristianK</div> <h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=835#p835">Re: Multiple email-Addresses in *one* Partner Address required?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=835#p835"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=67">pokorra</a></strong> » Mon May 27, 2013 9:39 am </p> <div class="content">OM Germany needs multiple email addresses per partner.<br />For example, a supporter couple is stored as a FAMILY partner, and both should get the PDF version of the bi-monthly magazine (subscription).<br />We do not want to create two partners for them. <br />Does that scenario make sense?</div> |
|
From: <ro...@op...> - 2013-05-27 07:54:34
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=832#p832">Interesting article about accounting in Not-For-Profit Orgs</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=832#p832"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=67">pokorra</a></strong> » Mon May 27, 2013 7:33 am </p> <div class="content">This interesting article about accounting in Not-For-Profit Organisations mentions the term "four-sided accounting" for transfering money between funds, and other useful considerations:<br /><br />How to determine if a Not-for-profit organisation needs specialized Accounting software<br /><!-- m --><a class="postlink" href="http://mcgladrey.com/pdf/nfp_specialized_accounting_software.pdf">http://mcgladrey.com/pdf/nfp_specialize ... ftware.pdf</a><!-- m --><br /><br />I think it is worth reading by us developers working on the finance module, and also the experts who have to consider other options as well.</div> |
|
From: <ro...@op...> - 2013-03-27 17:54:21
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=810#p810">When to Save on GL & Gift Batch screens</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=810#p810"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=93">ctopenpetra</a></strong> » Wed Mar 27, 2013 5:25 pm </p> <div class="content">There has been some discussion regarding the behaviour of the GL & Gift Batch screens with regard to when data should be saved to the database. Currently all data is saved whenever you change tabs, the only visible evidence of this happening being the greying out of the Save button. Also, data is saved whenever you click the Add button (whichever tab you are on). However, this does not save the new row that is created, but will save all rows previously entered. If you close the window without saving then you will be asked if you want to Save. If you say no then only the row you just entered will be lost, all other rows will have been saved already.<br /><br />In "old" Petra the saving was much more explicit because you always had a separate Edit screen for whatever record you were editing and had to Save before you could continue to the next journal/transaction/etc. These issues arise because of the more flexible interface that we have in OpenPetra.<br /><br />There are three main questions:<br /><br />1. Should OpenPetra Save when you switch tabs? This is not consistent with other parts of OpenPetra (eg. Partner Edit screen) where data is only saved when the user clicks Save. The user may be surprised to discover that their data has been saved without them explicitly saying it should be. Since it is not currently possible to delete a batch (only Cancel it) you would not be able to undo what you have done by closing the screen. However, this approach does ensure that data is saved automatically without an additional click.<br /><br />2. Should OpenPetra Save every time a new row is added. In a way this mimics the Petra approach in that you can't move on to the next transaction without first saving the one you just edited. Therefore the risk of data loss in the case of a crash is much reduced. However, it is not obvious to the user that this saving is taking place and the "Do you want to Save?" mess age that comes up on closing the window could be confusing. It is also not consistent with other parts of OpenPetra.<br /><br />3. Should it be possible to fully delete a batch (rather than just set it to Cancelled)? If so, is it acceptable for there to be a gap in the batch numbering? For example, I create batch 3 then delete it. Is it ok if the next batch created is batch 4?<br /><br />So, this is partly a trade off between being consistent with other parts of the application and having different functionality considering that this is the one part of Petra where data may be entered in bulk. We first need to know how the users would really like this to work before tackling some of the technical hurdles which it might throw up.</div> |
|
From: <ro...@op...> - 2013-03-20 08:54:29
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=798#p798">Re: Ledger Name and Number on GL and Gift Batch Screens</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=798#p798"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=132">alwynpaul</a></strong> » Wed Mar 20, 2013 8:19 am </p> <div class="content">Hi<br /><br />Sorry I was away and that is the reason for my delay in answering your note.<br /><br />I agree we need to have consistency and if space is not an issue, then I think it is good to display the number and name.<br /><br />Blessings</div> |
|
From: <ro...@op...> - 2013-03-13 12:54:24
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=795#p795">Re: Ledger Name and Number on GL and Gift Batch Screens</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=795#p795"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=89">wbrowa</a></strong> » Wed Mar 13, 2013 12:23 pm </p> <div class="content">Alwyn, any opinion on this topic from your side?</div> |
|
From: <ro...@op...> - 2013-03-01 18:50:04
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=792#p792">Re: Gift Batch Import - Remove Donor/Recipient Short Name?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=792#p792"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=86">robertpickett</a></strong> » Fri Mar 01, 2013 9:58 am </p> <div class="content"><blockquote><div><cite>dwmosman wrote:</cite>Can I remove Donor Short Name and Recipient Short Name from the import? They are both ignored by the import code.</div></blockquote><br /><br />I think it would be best to keep them for compatibility with Petra and iConnect. Also, it can be helpful for the user to be able to see those fields when they do an export and we want to keep the export and import formats the same.</div> <h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=793#p793">Re: Gift Batch Import - Add Admin Grant and Key Ministry?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=793#p793"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=86">robertpickett</a></strong> » Fri Mar 01, 2013 10:07 am </p> <div class="content"><blockquote><div><cite>dwmosman wrote:</cite>The Gift Batches Details screen has two additional entry fields, Admin Grant and Key Ministry. Should I add those to the batch input format? If so, are there any special validation rules?</div></blockquote><br /><br />The Key Ministry field is just an alternative way of setting the recipient so that is already covered by the import. As for the "Admin Grant" tickbox, I guess that is a question for the finance guys. If we were to add it then it would obviously have to be done in such a way that the "old Petra" format, without that field, is still supported. I think if we don't get any response on this forum from the finance guys saying, "yes we want that", then best to leave it. My understanding is that this check-box would rarely be unticked and I've certainly never had any request to add it to the import.</div> |
|
From: <ro...@op...> - 2013-03-01 08:55:33
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=788#p788">Gift Batch Import Specification</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=788#p788"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=135">dwmosman</a></strong> » Thu Feb 28, 2013 7:46 pm </p> <div class="content">As per today's meeting, I have been working on the specification for Gift Batch Import. You can see it <a href="https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Gift_Batch_Import_File_Specification" class="postlink">here.</a> Several questions and the responses are included in an earlier version, <a href="https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Gift_Batch_Import_File_Specification&oldid=3419" class="postlink">16:53, 27 February 2013.</a></div> <h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=789#p789">Re: Gift Batch Import - User Interaction on Errors</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=789#p789"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=135">dwmosman</a></strong> » Thu Feb 28, 2013 8:51 pm </p> <div class="content">One of the questions was on the user process for dealing with errors.<br /><br />In Petra, some errors ask the user for immediate response in the middle of the import. For example, "This partner has been merged. Do you want to replace it with the merged partner?". <br /><br />However, this behaviour is more complex to support in a multi-user client-server environment. After discussion, it was decided that if at all possible, batch processing would continue un-interrupted to completion. A complete list of errors should be returned to the user so all errors can be corrected before resubmitting the batch (as opposed to rejecting on the first error, the corrected batch is resubmitted, the next error is found, the corrected batch is resubmitted, the next error is found, etc.).<br /><br />Rob and Christopher raised several good points to be considered in the decision so I have included the discussion below.<br /><br /><blockquote class="uncite d"><div>On 2/27/2013 4:28 AM, Christian Kendel (ICT) wrote:<br /><br />Hi all,<br /><br />If Merged Partners is the only issue on which we would need to ask Partners for a decision, i.e. the only user interaction needed while the Batch Import is processed (after having checked with Alwyn that that we could introduce a checkbox to the import dialog for the 0-prefixing of Cost Centre numbers), then I would go with the following suggestion:<br /><br />If Merged Partner(s) is/are encountered then cancel the Batch Import and report to the user in some way that Partner âaâ has been merged into Partner âbâ (and possibly that Partner âcâ has been merged into Partner âdâ, etc. in case that happens more than once in the same Batch Import). On receiving that âreportâ the user would need to be instructed to manually amend the Partner Keys of the respective CSV âcolumnâ and ârowâ in the CSV import file accordingly (they would do this in Excel and export as CS V again, I assume) and to then run the Batch Import again after that. (That would of course only be necessary if at least one Merged Partner was encountered in one of the respective columns.)<br /><br />That approach needs no client-server interaction while the process is running as the Data Validation checks on correctness of the data formats (e.g. integers need to be integers, dates need to be valid dates, etc.), checks for lookup values to be valid (e.g. âBank Account Codeâ), and the checks for Merged Partners can all be done before the writing to the DB happens â essentially a âpre-flight checkâ. Only if no problems were found with the pre-flight check then the actual writing to the DB (i.e. the importing) is allowed to go ahead. If any problems were found then the DB transaction would be rolled back so no DB Locks would be held anymore and the Batch Import process would be cancelled completely while the user amends the CSV file (which could be done at any poin t in the future and not necessarily soon and could take an unknown amount of time).<br /><br />Once the user has corrected the PartnerKeys of the Merged Partners to the PartnerKeys that the Partners were merged into in the CSV file then he/she performs the Batch Import again freshly (we could keep the Batch Import dialog open so the user only needs to click âImportâ again without needing to go the screen), on which the pre-flight check is executed again. If everything is fine then the writing to the DB can go ahead in the same DB Transaction that was started with the pre-flight check, if not, then the DB rollback and cancelling and reporting would happen as before.<br /><br />The approach that I described above would be much easier to implement and less error-prone than a user interaction that would need to happen while the Batch Import is processed. As Doug said it is not impossible, but much more work (we use that approach in the Partner Edit screen for the Addresses T ab: after the user has pressed the âSaveâ button, DB checks need to be performed and the user might need to be presented with the right options in specific Dialogs, some of which even offer multi-select Grids. If that is case then the saving is aborted and the DB transaction rolled back before the user sees the Dialog(s). The user then makes his/her choice in the Dialog(s) and the whole data saving operation starts again, this time with input parameters that reflect the usersâ choice for that particular question and that particular Address record. After that more checks against the DB need to be performed which can result in more questions that the user needs to be asked for, again for particular Address records. That client-server âping-pongâ can go a number of times, and may be repeated for an arbitrary number of questions and Address records. Finally, after all the answers are collected the saving is allowed to go ahead, taking all the userâs answers on all th e records into consideration and performing the correct actions. Checks then need to be done whether the answers are still valid as data in the DB might have changed in the meantime...)<br /><br />The approach that I described above would also make no changes to the Gift Batch screens necessary as no invalid data will ever get imported and hence no invalid Batches would need to be edited or deleted. Of course, DB locks would also never be held longer than absolutely necessary.<br /><br />As far as I understand the issues present this should be a workable approach.<br /><br />Kind regards,<br /><br />______________________________________<br /><br />Christian Kendel<br />> <br />><br />> From: Douglas Mosman [mailto:dwm...@us...]<br />> Sent: 26 February 2013 20:26<br />> To: Robert Pickett (ICT)<br />> Cc: Christian Kendel (ICT); Timotheus Pokorra<br />> Subject: Re: Questions on Batch Import Approaches<br />><br />> Rob,<br />><br />> Thanks for your comments. I responded below. <br />><br />> At this point, it seems that merged partners is the only real process question. Do you agree? I am continuing to think about what might be a relatively straight-forward approach that still supplies a satisfactory experience for the users. I hope you don't mind some questions since I don't have a precise feel for the use case around batch imports.<br />><br />> How often do you think a user running imports might experience the merged partner issue?<br />> What is normally (80-90% of the time) the maximum number of distinct donors that you would expect to find in a batch?<br />> How often do you think the user would want to auto-load the new donor records vs. rejecting the batch and manually re-keying the entries?<br />> Were you thinking that this same logic would need to be applied to recipients as well?<br />><br />> -- Doug<br />><br />>> On 2/26/2013 9:03 AM, Robert Pickett (ICT) wrote:<br />>><br />>> Hi Doug,<br />>><br />>> Please see comments below...<br />>><br />>> Pre-selecting the Choices<br />>><br />>> For example, add a check box on the import dialog, "[x] add a leading 0 and retry cost centre lookups when the original lookup fails"<br />>> Rob: I'm fine with this approach for the leading zero question.<br />> Doug: But, as you say, doesn't answer the "merge" question.<br />>><br />>> Two-stage Validations<br />>><br />>> Perform an initial pass on the client (call it "Building the Batches").<br />>> Do field type checking (numerics, dates, etc.). Do logical validation (ex. effective date cannot be older than today - x). Verify (for example) that cost centre codes are a valid length (if we know them).<br />>> Limit interactive questions to what we can perform in t he client edit.<br />>> If the batch is not rejected, then pass it down to the server for<br />>> "Validating Batches". Perform database lookups and more complex<br />>> validation in normal remote mode, waiting until the end to pass the results back to the user.<br />>> Rob: Up to here is ok, except that it doesn't handle questions like whether they want to use the Merged into donor if the donor has status MERGED as that requires some database checking first. For that example, if it really can't be done, I guess you'd have to reject the import if a MERGED donor was used and the user would have to change the Partner Key of that donor themselves in the import. Alternatively would it not be possible at this point to return the validation results to the client, ask any questions that need to be asked, then call an additional server process to actually load the data into the database (if the import is not being rejected). If th e import is rejected then just list the errors and finish.<br />> Doug: Speaking with Christian, the root of the concern, I believe, is two-fold. First, that the system is now a multi-user system and, secondly, that the import process is a synchronous process between the client and server. Thus, it locks up a certain portion of resources along the path, including some database records. If the process is halted and the user doesn't respond right away, then those resources stay locked up which can cause problems for other users. If I understand your alternative suggestion, I'm not sure that it would speak to these issues any better than the original proposed behaviour. However, Christian could better speak to that as he understands the nuances of this much better than I do. Also, please note that he did not say the originally proposed behaviour was impossible, just that it would be better if a good alternative approach was found. <br />>><br />>> L oad All Batches to be Cleaned Up in OpenPetra Gift Batch Edit <br />>><br />>> Since screens have already been written to save and edit unposted gift batches, is the "all or nothing" philosophy still the best approach for batch imports? As long as the input fields were the right type of data (i.e., dates are dates, numeric's are numeric's), we could force the batches in and just return them to the user with an error list. The user could then decide whether to correct the batch on line or simple delete it and clean up the data in his original source file.<br />>> Rob: I don't think I like the sound of this part. The way the edit screens currently work, once you are in a batch that is invalid you are stuck there until you fix it, so having multiple bad batches could get really frustrating for the user. It would also mean that any process that runs on a batch would have to first validate it (whereas currently it could assume that a saved ba tch is a valid batch), unless you are going to prevent the user from doing anything else until they have fixed all the batches (but then what happens if OpenPetra crashes while they are doing it). Also, it is not possible to delete batches, only set them to cancelled, so you would end up with a lot of unnecessary cancelled batches. I suspect in most cases users would want to correct the import file anyway as they may use it as a template for future imports.<br />> Doug: Good points Rob. Definitely the screens would need to be modified to allow unfinished batches for this approach to work. And I had assumed that users would normally use the OpenPetra screens to clean up errors so the batches would eventually be processed and clear the system. However, if users fixed and re-imported batches then the unposted batches could certainly become an issue. And validation would have to be separated from posting so batches could be rechecked...<br />><br />> The rea son I thought of it is because a) it is essentially your alternative suggestion from above, only the batch data and errors are stored on the client and the link to the server is released, eliminating the lock issues (perhaps this is what you meant?) and b) I think we may already have the issues to some degree. What happens today in OpenPetra if a batch is imported, the recipient's partner record is merged, and the batch is then posted?<br />>><br />>> Apologies if I have misunderstood anything.<br />>> Thanks,<br />>><br />>> Rob.<br /></div></blockquote></div> <h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=790#p790">Re: Gift Batch Import - Remove Donor/Recipient Short Name?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=790#p790"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=135">dwmosman</a></strong> » Thu Feb 28, 2013 9:02 pm </p> <div class="content">Can I remove Donor Short Name and Recipient Short Name from the import? They are both ignored by the import code.</div> <h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=791#p791">Re: Gift Batch Import - Add Admin Grant and Key Ministry?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=791#p791"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=135">dwmosman</a></strong> » Thu Feb 28, 2013 9:13 pm </p> <div class="content">The Gift Batches Details screen has two additional entry fields, Admin Grant and Key Ministry. Should I add those to the batch input format? If so, are there any special validation rules?</div> |
|
From: <ro...@op...> - 2012-11-07 21:54:18
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=743#p743">Re: Posting Gift & GL Batches</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=743#p743"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=67">pokorra</a></strong> » Wed Nov 07, 2012 9:43 pm </p> <div class="content">I think it is better the users post each batch at one time.<br />In Germany, they always have some batches that they keep open. It would be too dangerous to post a batch by mistake.</div> |
|
From: <ro...@op...> - 2012-11-06 09:54:21
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=740#p740">Posting Gift & GL Batches</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=740#p740"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=93">ctopenpetra</a></strong> » Tue Nov 06, 2012 9:28 am </p> <div class="content">Do we want to give the user the ability to opt to post the currently selected batch as opposed to automatically posting all batches that are ready for posting? In other words, two buttons: [Post] and [Post All]</div> |
|
From: <ro...@op...> - 2012-10-08 14:54:18
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=733#p733">Re: Gift Dates - per batch or per gift?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=733#p733"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=112">matthiasschwarz</a></strong> » Mon Oct 08, 2012 2:44 pm </p> <div class="content">forwarded the forum entry to Alwyn. Will post his reply here.</div> |
|
From: <ro...@op...> - 2012-10-04 15:54:21
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=729#p729">Re: Gift Dates - per batch or per gift?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=729#p729"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=90">simonyeomans</a></strong> » Thu Oct 04, 2012 2:59 pm </p> <div class="content">I know of no OM requirement as such, but personally would find this a very positive and useful change.</div> |
|
From: <ro...@op...> - 2012-10-04 14:54:22
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=728#p728">Gift Dates - per batch or per gift?</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=728#p728"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=86">robertpickett</a></strong> » Thu Oct 04, 2012 2:35 pm </p> <div class="content">Currently Petra only allows a single date for all gifts within a batch (ie. the date is entered on the batch and cannot be changed per gift). In OpenPetra currently it is possible to enter a different date on each gift as long as the date is within the same period as the batch date. This has been done because one of Timo's clients wanted to be able to enter just a single batch per month but still be able to specify individual dates per gift.<br /><br />What is the requirement within OM? Should it be the same as Petra (ie. just one date per batch) or would the change to allow a different date per gift actually be desirable?</div> |
|
From: <ro...@op...> - 2012-09-25 15:54:20
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=724#p724">Gift Detail Display</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=724#p724"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=86">robertpickett</a></strong> » Tue Sep 25, 2012 2:59 pm </p> <div class="content">I think there may need to be some discussion regarding the display of the Gift Detail tab. I think the current screen is confusing as the distinction between a normal gift and split gift is not clear enough. The problem is that you are representing a one to many structure in a flat grid. The old Petra screen looked like this:<br /><br /><img src="https://sourceforge.net/apps/mediawiki/openpetraorg/nfs/project/o/op/openpetraorg/d/d7/Petra_gift_detail.jpg" alt="Image" /><br /><br />So the split gifts were made obvious by the donor name only appearing once. Note, there was no user sorting available, sorting would always be by Gift, Detail.<br /><br />The OpenPetra screen currently looks like this:<br /><br /><img src="https://sourceforge.net/apps/mediawiki/openpetraorg/nfs/project/o/op/openpetraorg/6/6a/Openpetra_gift_detail.jpg" alt="Image" /><br /><br />There are several problems here:<br /><br /><ul><li>It is possible to sort by any column. If the user does this then the relationship between the details is lost. Two details from the same gift could appear at opposite ends of the grid. I suggest disabling user sorting on this tab or limiting it to either Gift Transaction Number, Gift Number (this should be the default) or Donor Name, Gift Transaction Number, Gift Number.</li><li>It is not immediately obvious where a row is a member of a split as opposed to a complete gift. I don't know the capabilities of the OpenPetra grid or other available controls so it would be good if someone could give some thought to the best way to address this. Obviously the old Petra way might be one way to do it but there might be better ways.</li><li>The column names Gift Transaction Number and Gift Number don't mean anything to the user. The old "Gift" & "Detail" in Petra is better but still not great. I wonder if "Gift Number" & "Split Number" (or just "Gift" & "Split") would be better but am very open to better suggestions. Also the column "Transaction Gift Amount" should be renamed "Gift Amount" or just "Amount" and a column should be added for "Reference".</li></ul><br />Alwyn, how happy are users with the current Gift Transaction list view in Petra? Are you aware of any complaints or suggestions for improvement?</div> |
![https://sourceforge.net/apps/mediawiki/openpetraorg/nfs/project/o/op/openpetraorg/d/d7/Petra_gift_detail.jpg"](https://sourceforge.net/apps/mediawiki/openpetraorg/nfs/project/o/op/openpetraorg/d/d7/Petra_gift_detail.jpg"){kind=link}
![https://sourceforge.net/apps/mediawiki/openpetraorg/nfs/project/o/op/openpetraorg/6/6a/Openpetra_gift_detail.jpg"](https://sourceforge.net/apps/mediawiki/openpetraorg/nfs/project/o/op/openpetraorg/6/6a/Openpetra_gift_detail.jpg"){kind=link}
|
From: <ro...@op...> - 2012-09-24 07:54:21
|
<h3 ><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=723#p723">Re: Show Batch Options</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=723#p723"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=67">pokorra</a></strong> » Mon Sep 24, 2012 7:53 am </p> <div class="content">Alwyn wrote an email saying:<br />I agree with Simon but it will be nice to have a posted button as well.</div> |
|
From: <ro...@op...> - 2012-09-17 13:54:20
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=718#p718">Default Effective Date when adding a new Gift & GL batch</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=718#p718"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=93">ctopenpetra</a></strong> » Mon Sep 17, 2012 1:10 pm </p> <div class="content">The Gift & GL Batch screens both allow the user to filter existing batches by year and period.<br /><br />When the user clicks the Add button to add a new batch, I remove any filter so that the list is showing current period and forwarding periods and set the effective date for the new batch to be the starting date for the current accounting period.<br /><br />Is this satisfactory, or is there a need to take the filter into consideration when creating a new batch, i.e. the batch effective date is set to the starting date of the period filter value as opposed to just current?<br /><br />One thought is that the user might find it annoying if they had filtered the list, forgot about it, and then added a new batch in the filtered period unintentionally. Perhaps it is better to force the user to explicitly change the effective date from the current period starting date to a different one.<br /><br />Comments, please<br /><br />Thanks</div> |
|
From: <ro...@op...> - 2012-09-13 09:54:20
|
<h3 class="first"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=715#p715">Support for restricted gifts</a></h3> <p class="author"><a href="http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=715#p715"><img src="./styles/sf/imageset/icon_post_target.gif" width="11" height="9" alt="Post" title="Post" /></a>by <strong><a href="http://sourceforge.net/apps/phpbb/openpetraorg/memberlist.php?mode=viewprofile&u=124">tim-ingham</a></strong> » Thu Sep 13, 2012 9:23 am </p> <div class="content">Petra has the idea of "Restricted Gifts", where access to the details of a gift is restricted to certain personnel with specific access rights.<br /><br />Do we want to implement the same / similar functionality in OpenPetra, and if so, when should this functionality be included? Should it be implemented right now, or can we ignore it for a while?<br /><br />In Petra, the "Restricted Gift" functionality was retro-fitted, and this would apparently be easy to do for us too, so potentially there's no urgency about it.<br /><br />There's also the possibility that we should take the opportunity re-evaluate exactly what we're trying to achieve, and how it should best be implemented.</div> |
54 messages has been excluded from this view by a project administrator.