[jira] [Commented] (FINERACT-789) Wrong Journal Entry Posting on Disburse to savings.
[ https://issues.apache.org/jira/browse/FINERACT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921321#comment-16921321 ] Mexina Daniel commented on FINERACT-789: Hello [~pnyota] Can you reproduce this in a demo account and provide the loan and the date you tested. > Wrong Journal Entry Posting on Disburse to savings. > --- > > Key: FINERACT-789 > URL: https://issues.apache.org/jira/browse/FINERACT-789 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.2.0, 1.3.0, 1.4.0, Backlog, 1.5.0, 1.3.1 > Environment: All >Reporter: Nyota Macharia >Priority: Critical > > When a loan with a fee charged at disbursement is disbursed to savings the > the journal entries happen as follows: Eg. Loan of 50,000 with 1% processing > fees charged at disbursement. > # Loan Portfolio is debited by by 50,000. This is okay. > # Liability Transfer is credited by 50,000. This is okay. > # Fee income is credited with 500. This is okay. > # Loan fund source is debit with 500. This is the error, Liability Transfer > should be debited. > # Savings Portfolio is credited with 49,500. This is okay. > # Liability transfer is debited with 49,500. this is okay. > As you can see the end result is that liability transfer is left with a > balance with in fact it is a control account. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (FINERACT-791) Transfer of fund from saving balance to shares
Mexina Daniel created FINERACT-791: -- Summary: Transfer of fund from saving balance to shares Key: FINERACT-791 URL: https://issues.apache.org/jira/browse/FINERACT-791 Project: Apache Fineract Issue Type: Improvement Components: Savings, Shares Affects Versions: 1.0.0 Reporter: Mexina Daniel Assignee: Mexina Daniel Fix For: 1.3.0 This improvement will enable to use saving balance to purchase a share through the feature of transfer fund. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (FINERACT-391) Fund Management-Delete Enhancement
[ https://issues.apache.org/jira/browse/FINERACT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854254#comment-16854254 ] Mexina Daniel commented on FINERACT-391: [~edcable] We have not yet implemented the feature, the features was not requested by our clients but our QA Agness Meena saw the need of having the ability to delete a fund once it is created (If it is not linkend to any active loan product ) to remove un-needed funds which does not used anymore. > Fund Management-Delete Enhancement > -- > > Key: FINERACT-391 > URL: https://issues.apache.org/jira/browse/FINERACT-391 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Reporter: Santosh Math >Assignee: Markus Geiss >Priority: Minor > Labels: 2019-mifos-gsoc, Volunteer, gsoc, p3 > Fix For: 1.5.0 > > > Reported by Agness Meena at https://mifosforge.jira.com/browse/MIFOSX-2822 > Go to Admin > Organization > Manage Fund > Once you create a new fund you can only edit it but not deleting it. > Need a Delete button to delete existing fund. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-690) Global configuration to disallow the change of overdue charges on a loan product to affect the already created loans.
[ https://issues.apache.org/jira/browse/FINERACT-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854251#comment-16854251 ] Mexina Daniel commented on FINERACT-690: [~edcable] The requirement is, for some of the MFI when a client take a loan with the agreement of no penalty, when the MFI come to introduce the penalty before they have completed their loans, the changes of loan product should not affect the already applied loans. My suggestion on implementation was to have a global configuration that will allow a MFI to either allow the already applied loans to be affected with the changes or to disallow that. > Global configuration to disallow the change of overdue charges on a loan > product to affect the already created loans. > - > > Key: FINERACT-690 > URL: https://issues.apache.org/jira/browse/FINERACT-690 > Project: Apache Fineract > Issue Type: New Feature > Components: Charges, Loan >Reporter: Mexina Daniel >Priority: Major > Labels: 2019-mifos-gsoc, GSoC > Fix For: 1.5.0 > > > For now when you attach an overdue charge to a loan product which did not > have previously, it affect the active loans that were created without a > penalty. > Am suggesting for the system to have a configuration to allow are disallow > this feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-688) Periodic Accrual accounting: Accrue fees when paid
[ https://issues.apache.org/jira/browse/FINERACT-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812412#comment-16812412 ] Mexina Daniel commented on FINERACT-688: Hello [~sapana] Thank you for the clarification, i didn't know if the charges were treated differently. > Periodic Accrual accounting: Accrue fees when paid > -- > > Key: FINERACT-688 > URL: https://issues.apache.org/jira/browse/FINERACT-688 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.1.0 >Reporter: sapana >Priority: Major > > As per periodic accrual accounting method, charges are accrued when they > become due. Ideally, as per standard industry practice, charges should accrue > when borrower actually pays them, not prior to that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-688) Periodic Accrual accounting: Accrue fees when paid
[ https://issues.apache.org/jira/browse/FINERACT-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812369#comment-16812369 ] Mexina Daniel commented on FINERACT-688: Hello [~sapana] On the description, you said "_as per standard industry practice, charges should accrue when borrower actually pays them, not prior to that._" What is the difference between the Cash accounting and Accrue accounting? > Periodic Accrual accounting: Accrue fees when paid > -- > > Key: FINERACT-688 > URL: https://issues.apache.org/jira/browse/FINERACT-688 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.1.0 >Reporter: sapana >Priority: Major > > As per periodic accrual accounting method, charges are accrued when they > become due. Ideally, as per standard industry practice, charges should accrue > when borrower actually pays them, not prior to that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-109) Bank Reconciliation Module
[ https://issues.apache.org/jira/browse/FINERACT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762378#comment-16762378 ] Mexina Daniel commented on FINERACT-109: This is very important feature for Fineract to have [~edcable] [~emmanueln...@musoni.eu] Any update on this? > Bank Reconciliation Module > -- > > Key: FINERACT-109 > URL: https://issues.apache.org/jira/browse/FINERACT-109 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Emmanuel Nnaa >Assignee: Markus Geiss >Priority: Minor > > A number of MFIs have requested the addition of a bank reconciliation module, > making it easier for them to reconcile any journal entries made against their > Bank Account GL(s) in Fineract, with the actual transactions in their bank > account. First thoughts on how this would work below: > * User will need the ability to select a specific GL Account to reconcile. > Perhaps a checkbox should be added when creating / editing a GL to specify if > it should be made available in the reconciliation module > * Reconciliation module should show all GL accounts that were previously made > available, along with the reconciled balance and unreconciled balance > * User should then be able to select the GL account, and pull out either all > journal entries between a start and end date, or all unreconciled entries, or > all reconciled entries > * User should have the ability to tick a checkbox for any entry that they > wish to reconcile and then to save at the end once they have ticked multiple > checkboxes they can save > * The act of reconciliation should be tracked and shown in the audit module > The more complex, but key, addition, will be the option to group (or if > possible to sum) all transactions with the same reference together. This will > be useful when reconciling group postings which appear as multiple GLs in > Fineract, but only one transaction in the bank account. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-363) Penalty to be attached/updated to a loan account which was created when a loan product had no penalty/penalty with different amount
[ https://issues.apache.org/jira/browse/FINERACT-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732731#comment-16732731 ] Mexina Daniel commented on FINERACT-363: [~santoshmath] Global configuration will be good Already opened the ticket https://issues.apache.org/jira/browse/FINERACT-690 > Penalty to be attached/updated to a loan account which was created when a > loan product had no penalty/penalty with different amount > > > Key: FINERACT-363 > URL: https://issues.apache.org/jira/browse/FINERACT-363 > Project: Apache Fineract > Issue Type: Bug > Components: Charges >Reporter: Mexina Daniel >Assignee: Shaik Nazeer Hussain >Priority: Major > Labels: gsoc, p1 > Original Estimate: 12h > Remaining Estimate: 12h > > 1. Create a loan product without overdue charges (penalty) in Admin -> > Product -> Loan Product -> Create Loan Product > 2. Apply a loan account of that loan product to a client at Clients -> View > Client -> New Loan > 3. Approve a loan, disburse and make few repayments > 4. Then create a charge which is overdue (is penalty) in Admin -> Products -> > Charges -> Create Charge > 5. Go to that loan product and attach an overdue charge > What happens: > The applied penalty is also attached to that loan which was created before > this update > Expected: > The loan account should not be updated if it was created before the change, > the penalty should be applied to loan accounts that will be applied after > update of loan product. > 6. Update a penalty and change it's amount > What happens: > All loan accounts that the penalty is applied, the amount of the penalty will > also change. > Expected: > The amount of the penalty should not change to the loan accounts that were > attached before the update of the penalty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-690) Global configuration to disallow the change of overdue charges on a loan product to affect the already created loans.
Mexina Daniel created FINERACT-690: -- Summary: Global configuration to disallow the change of overdue charges on a loan product to affect the already created loans. Key: FINERACT-690 URL: https://issues.apache.org/jira/browse/FINERACT-690 Project: Apache Fineract Issue Type: New Feature Components: Charges, Loan Reporter: Mexina Daniel Fix For: 1.3.0 For now when you attach an overdue charge to a loan product which did not have previously, it affect the active loans that were created without a penalty. Am suggesting for the system to have a configuration to allow are disallow this feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-363) Penalty to be attached/updated to a loan account which was created when a loan product had no penalty/penalty with different amount
[ https://issues.apache.org/jira/browse/FINERACT-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731774#comment-16731774 ] Mexina Daniel commented on FINERACT-363: [~santoshmath] The concept is now clear to me, that is the expected behavior implemented for most of MFI. For those exception can use the work around. [~Shruthi M R] [~edcable] We can either not implement this and for those few exceptions to use the work around or if possible we can make a way for both options to be available. 1. For those who will want the change of the overdue charge to affect the already active loan 2. For those who will want the new change to affected only the ones will be created after the change. > Penalty to be attached/updated to a loan account which was created when a > loan product had no penalty/penalty with different amount > > > Key: FINERACT-363 > URL: https://issues.apache.org/jira/browse/FINERACT-363 > Project: Apache Fineract > Issue Type: Bug > Components: Charges >Reporter: Mexina Daniel >Assignee: Shaik Nazeer Hussain >Priority: Major > Labels: gsoc, p1 > Fix For: 1.3.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > 1. Create a loan product without overdue charges (penalty) in Admin -> > Product -> Loan Product -> Create Loan Product > 2. Apply a loan account of that loan product to a client at Clients -> View > Client -> New Loan > 3. Approve a loan, disburse and make few repayments > 4. Then create a charge which is overdue (is penalty) in Admin -> Products -> > Charges -> Create Charge > 5. Go to that loan product and attach an overdue charge > What happens: > The applied penalty is also attached to that loan which was created before > this update > Expected: > The loan account should not be updated if it was created before the change, > the penalty should be applied to loan accounts that will be applied after > update of loan product. > 6. Update a penalty and change it's amount > What happens: > All loan accounts that the penalty is applied, the amount of the penalty will > also change. > Expected: > The amount of the penalty should not change to the loan accounts that were > attached before the update of the penalty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-536) Report categories are inconsistent and causing reports to go missing in the drop-down
[ https://issues.apache.org/jira/browse/FINERACT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712823#comment-16712823 ] Mexina Daniel commented on FINERACT-536: [~Shruthi M R] when i said "source codes to change the category of the report" i thought the category of the report was coded on the platform source codes and so was asking for the file to edit since they can't be edited in the community-app. > Report categories are inconsistent and causing reports to go missing in the > drop-down > - > > Key: FINERACT-536 > URL: https://issues.apache.org/jira/browse/FINERACT-536 > Project: Apache Fineract > Issue Type: Improvement > Components: System >Affects Versions: 1.0.0 >Reporter: thynn win >Assignee: Shruthi M R >Priority: Minor > Labels: gci, gsoc, p1 > Fix For: 1.3.0 > > Attachments: Untitled.gif > > > Currently in Mifos, if you go to Reports menu and use the drop down to see > "Clients" or "Loans", we notice that some reports are not showing up in the > proper list. > For instance, if you pick Reports>Clients , some client reports such as > "Client Listing" will not show up. This is because the category is 'Clients' > while the expected category value for "Clients" drop down is "Client". > The same issue presents for other category such as Loans. In this case, some > loan reports are created with category "Loan" not "Loans" and then they are > not showing up. It's confusing to end users. > To solve this, review all the report categories and make sure they are > consistent with the expected value from the drop down (be it Client or > Loans). > Acceptance criteria: > All the report categories are cleaned up and consistent and they should all > show up under right drop-down. > The end result is a sql script for the next release that fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-574) Issues related to share Account Creation
[ https://issues.apache.org/jira/browse/FINERACT-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706725#comment-16706725 ] Mexina Daniel commented on FINERACT-574: [~Shruthi M R] i don't have any more inputs You can proceed to review the PR and merge if no other queries. > Issues related to share Account Creation > > > Key: FINERACT-574 > URL: https://issues.apache.org/jira/browse/FINERACT-574 > Project: Apache Fineract > Issue Type: Bug > Components: Shares >Reporter: Santosh Math >Assignee: Shaik Nazeer Hussain >Priority: Critical > Labels: gci, gsoc, p1 > Fix For: 1.3.0 > > Attachments: Screenshot from 2017-12-12 21-05-47.png > > > 1. Create Share Product with Accounting Enabled > 2. Create a share charge with type 'Share Purchase' ,'Flat' amount $2. > 3. Create and activate savings account for client which is needed to link > with share account > 4. Create a share Account application for current date using above product > and charge and number of shares issued as 10 , each share price as $0.5. > > Once you 'Submit' the share application journal entries are created > > (including charge) even though share account is not yet approved/activated. > >Approve the share account and again duplicate jounal entries are created. > >If share account application is attached with 'Share Activation Fee' , upon > >submission of share account application, if we check 'Transaction Overview' > >tab, it shows 'Activation Fee' is received even though share account is not > >activated. Same is updated in the database > >table,"m_share_account_charge_paid_by". But under the 'Charges' tab, it > >shows Outstanding(which is correct). > The all scenarios can be tested here by modifying application and using the > charges > 'Share Purchase Fee' or 'Share Activation Fee' > https://staging.openmf.org/#/viewshareaccount/5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FINERACT-416) Interest to be calculated for the whole loan term given
[ https://issues.apache.org/jira/browse/FINERACT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel resolved FINERACT-416. Resolution: Fixed > Interest to be calculated for the whole loan term given > --- > > Key: FINERACT-416 > URL: https://issues.apache.org/jira/browse/FINERACT-416 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.1.0 >Reporter: Mexina Daniel >Assignee: Mexina Daniel >Priority: Critical > Labels: gsoc, p1 > Fix For: 1.2.0 > > > As for some of the MFI practise here in our country, they specify the > interest for the whole loan term given, i.e their loan product have the > interest for the whole loan term regardless of the frequency of repayment () > To accomplish this in mifos, a user has to do calculation of finding an > interest of a month/year with respect of the loan term of that specific > client. This is a very tiresome work as for a day a user can have apply many > loans and the task of calculation make the work even harder. > I was suggesting improvement in the loan product, to be able to allow the > interest rate of the whole loan term. > Example: > Loan product - Development Loan > Amount - Min: 100,000, Max:1,000,000 > Interest - 20% > Loan term - From 3months to 6months > -- This means the interest given is for any loan term the client will want to > take the loan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FINERACT-623) The restriction of product mix should apply during submission of another loan
[ https://issues.apache.org/jira/browse/FINERACT-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel reassigned FINERACT-623: -- Assignee: Mexina Daniel > The restriction of product mix should apply during submission of another loan > - > > Key: FINERACT-623 > URL: https://issues.apache.org/jira/browse/FINERACT-623 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Mexina Daniel >Assignee: Mexina Daniel >Priority: Major > Labels: gsoc, p2 > Fix For: 1.2.0 > > > For now when you configure one loan account of Product1 not to be applied > when a client already have another loan account of Product2, during the > application of another loan account, the system accept to submit and approve > the loan and give the error of co-exist during disburse. > Expected: The system should give the error of co-exist of the restricted loan > when a user is submitting the new loan account since the two loans should not > exist together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FINERACT-630) Bulk import to allow importing loan with decimal interest
[ https://issues.apache.org/jira/browse/FINERACT-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel reassigned FINERACT-630: -- Assignee: Mexina Daniel > Bulk import to allow importing loan with decimal interest > - > > Key: FINERACT-630 > URL: https://issues.apache.org/jira/browse/FINERACT-630 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.1.0 >Reporter: Mexina Daniel >Assignee: Mexina Daniel >Priority: Major > Labels: LOAN, bulkimport, gsoc, p1 > Fix For: 1.2.0 > > > For now the downloaded sheets to import loans does not allow the interest > which is of decimal value. > The platform should allow both decimals and without decimal values of > interest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FINERACT-416) Interest to be calculated for the whole loan term given
[ https://issues.apache.org/jira/browse/FINERACT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel reassigned FINERACT-416: -- Assignee: Mexina Daniel (was: Markus Geiss) > Interest to be calculated for the whole loan term given > --- > > Key: FINERACT-416 > URL: https://issues.apache.org/jira/browse/FINERACT-416 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.1.0 >Reporter: Mexina Daniel >Assignee: Mexina Daniel >Priority: Critical > Labels: gsoc, p1 > Fix For: 1.2.0 > > > As for some of the MFI practise here in our country, they specify the > interest for the whole loan term given, i.e their loan product have the > interest for the whole loan term regardless of the frequency of repayment () > To accomplish this in mifos, a user has to do calculation of finding an > interest of a month/year with respect of the loan term of that specific > client. This is a very tiresome work as for a day a user can have apply many > loans and the task of calculation make the work even harder. > I was suggesting improvement in the loan product, to be able to allow the > interest rate of the whole loan term. > Example: > Loan product - Development Loan > Amount - Min: 100,000, Max:1,000,000 > Interest - 20% > Loan term - From 3months to 6months > -- This means the interest given is for any loan term the client will want to > take the loan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-574) Issues related to share Account Creation
[ https://issues.apache.org/jira/browse/FINERACT-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695646#comment-16695646 ] Mexina Daniel commented on FINERACT-574: Hello [~Shruthi M R] Are the above response answered well your question and hence the can proceed with the fixing of this issue? > Issues related to share Account Creation > > > Key: FINERACT-574 > URL: https://issues.apache.org/jira/browse/FINERACT-574 > Project: Apache Fineract > Issue Type: Bug > Components: Shares >Reporter: Santosh Math >Assignee: Shaik Nazeer Hussain >Priority: Critical > Labels: gci, gsoc, p1 > Fix For: 1.2.0 > > Attachments: Screenshot from 2017-12-12 21-05-47.png > > > 1. Create Share Product with Accounting Enabled > 2. Create a share charge with type 'Share Purchase' ,'Flat' amount $2. > 3. Create and activate savings account for client which is needed to link > with share account > 4. Create a share Account application for current date using above product > and charge and number of shares issued as 10 , each share price as $0.5. > > Once you 'Submit' the share application journal entries are created > > (including charge) even though share account is not yet approved/activated. > >Approve the share account and again duplicate jounal entries are created. > >If share account application is attached with 'Share Activation Fee' , upon > >submission of share account application, if we check 'Transaction Overview' > >tab, it shows 'Activation Fee' is received even though share account is not > >activated. Same is updated in the database > >table,"m_share_account_charge_paid_by". But under the 'Charges' tab, it > >shows Outstanding(which is correct). > The all scenarios can be tested here by modifying application and using the > charges > 'Share Purchase Fee' or 'Share Activation Fee' > https://staging.openmf.org/#/viewshareaccount/5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-661) Not able to import Savings, FD and RD transactions
Mexina Daniel created FINERACT-661: -- Summary: Not able to import Savings, FD and RD transactions Key: FINERACT-661 URL: https://issues.apache.org/jira/browse/FINERACT-661 Project: Apache Fineract Issue Type: Bug Components: Savings Affects Versions: 1.1.0 Reporter: Mexina Daniel When account number preference is enable for a saving account, during download of Saving/Fixed deposit/Recurring deposit transactions, the system bring an error *Whitelabel Error Page This application has no explicit mapping for /error, so you are seeing this as a fallback. Tue Nov 06 12:11:50 EAT 2018 There was an unexpected error (type=Internal Server Error, status=500). For input string: "CS00094" * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-660) Not able to import Loan, Savings, Fixed Deposit and Recurring deposits accounts
Mexina Daniel created FINERACT-660: -- Summary: Not able to import Loan, Savings, Fixed Deposit and Recurring deposits accounts Key: FINERACT-660 URL: https://issues.apache.org/jira/browse/FINERACT-660 Project: Apache Fineract Issue Type: Bug Components: Loan, Savings, Shares Affects Versions: 1.1.0 Reporter: Mexina Daniel In bulk importation, when you want to import loan accounts, Savings account, Fixed Deposit Accounts and Recurring Accounts, you can download the template but when you upload, it doesn't give any error but when you refresh to see the record, it shows the importation didn't complete even if you wait for a long time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-647) Allow rescheduling of loan with recalculation of interest enabled
Mexina Daniel created FINERACT-647: -- Summary: Allow rescheduling of loan with recalculation of interest enabled Key: FINERACT-647 URL: https://issues.apache.org/jira/browse/FINERACT-647 Project: Apache Fineract Issue Type: Improvement Reporter: Mexina Daniel There is a need of allowing the loan which has enabled interest recalculation to be rescheduled once needed. for now the system does not allow that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-623) The restriction of product mix should apply during submission of another loan
[ https://issues.apache.org/jira/browse/FINERACT-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589848#comment-16589848 ] Mexina Daniel commented on FINERACT-623: Hello [~Shruthi M R] For now when you set restriction on product mix between LoanProduct1 and LaonProduct2 : Admin -> Product -> Product Mix Then apply a loan of LoanProduct1, approve and disburse it : Clients-> View client -> new loan On the same client, apply a loan of LoanProduct2. Now: The system allow to submit the loan of LoanProduct2, approve it and throw an error of restriction during disbursement. Expected: The system should through an error to tell the user that the loan from LoanProduct2 can not co-exist with the loan from LoanProduct1 during submission. Also if the loan from LoanProduct2 was submitted before the configuring of product mix and then product mix configured before disbursement, during disbursement it should through the error. > The restriction of product mix should apply during submission of another loan > - > > Key: FINERACT-623 > URL: https://issues.apache.org/jira/browse/FINERACT-623 > Project: Apache Fineract > Issue Type: Bug >Reporter: Mexina Daniel >Priority: Major > Labels: gsoc, p2 > > For now when you configure one loan account of Product1 not to be applied > when a client already have another loan account of Product2, during the > application of another loan account, the system accept to submit and approve > the loan and give the error of co-exist during disburse. > Expected: The system should give the error of co-exist of the restricted loan > when a user is submitting the new loan account since the two loans should not > exist together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FINERACT-644) Allow to undo disbursal in topup loans
[ https://issues.apache.org/jira/browse/FINERACT-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel updated FINERACT-644: --- Component/s: Loan > Allow to undo disbursal in topup loans > -- > > Key: FINERACT-644 > URL: https://issues.apache.org/jira/browse/FINERACT-644 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Reporter: Mexina Daniel >Priority: Major > > As of now, the system does not allow to undo disbursal of a topup loan, the > system should allow this in case the disbursal was done by mistake or user > want to change something before disbusing the loan. When the loan is undone > the disbursal, it will undo the last repayment of the loan which was closed > by the topup action. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-644) Allow to undo disbursal in topup loans
Mexina Daniel created FINERACT-644: -- Summary: Allow to undo disbursal in topup loans Key: FINERACT-644 URL: https://issues.apache.org/jira/browse/FINERACT-644 Project: Apache Fineract Issue Type: Improvement Reporter: Mexina Daniel As of now, the system does not allow to undo disbursal of a topup loan, the system should allow this in case the disbursal was done by mistake or user want to change something before disbusing the loan. When the loan is undone the disbursal, it will undo the last repayment of the loan which was closed by the topup action. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FINERACT-607) Need a bulk repayment functionality in MifosX
[ https://issues.apache.org/jira/browse/FINERACT-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel updated FINERACT-607: --- Issue Type: Improvement (was: Bug) > Need a bulk repayment functionality in MifosX > - > > Key: FINERACT-607 > URL: https://issues.apache.org/jira/browse/FINERACT-607 > Project: Apache Fineract > Issue Type: Improvement > Components: Groups, Loan > Environment: Apache Tomcat 7, MySQL 5,7.21, CentOS 7 >Reporter: Rituparna B >Priority: Major > > We use the MifosX Community App which runs on the Fineract Platform. > Requesting a new feature to enable the user enter group repayments in bulk, > instead of entering group-wise. This will save us a lot of valuable time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-624) Penalties are getting duplicated
[ https://issues.apache.org/jira/browse/FINERACT-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515639#comment-16515639 ] Mexina Daniel commented on FINERACT-624: Hello [~santoshmath] The loan on the link above has a penalty that its frequency of charging is daily and hence the penalties you see with similar dates are of different installments which was supposed to be paid. The system is behaving correct. Notice the double penalties start from "due as of" 15th Dec, which mean it start to charge the penalty of installment due of 8th Dec and installment due of 15th Dec, the same with triple in "due as of" 22nd Dec which is for three due installments. > Penalties are getting duplicated > - > > Key: FINERACT-624 > URL: https://issues.apache.org/jira/browse/FINERACT-624 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Reporter: Santosh Math >Priority: Critical > Labels: gsoc, p1 > Fix For: 1.2.0 > > > For the following loan account the penalties are applied for overdue loans. > After some initial penalties next penalties are getting duplicated (check > 'Charges' tab) > [https://staging.openmf.org/#/viewloanaccount/91] > (mifos/password) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-632) Description in Saving Product should not be mandatory
Mexina Daniel created FINERACT-632: -- Summary: Description in Saving Product should not be mandatory Key: FINERACT-632 URL: https://issues.apache.org/jira/browse/FINERACT-632 Project: Apache Fineract Issue Type: Improvement Reporter: Mexina Daniel The is no necessarily of making the description filed of saving product to be mandatory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-631) Allow to specify transfer date when transferring client from one branch to another
Mexina Daniel created FINERACT-631: -- Summary: Allow to specify transfer date when transferring client from one branch to another Key: FINERACT-631 URL: https://issues.apache.org/jira/browse/FINERACT-631 Project: Apache Fineract Issue Type: Improvement Reporter: Mexina Daniel Then transferring the client from one branch to another, the system take the current data and assume its a transfer date, the system should allow a user to specify, sometimes it might be a back date. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-630) Bulk import to allow importing loan with decimal interest
Mexina Daniel created FINERACT-630: -- Summary: Bulk import to allow importing loan with decimal interest Key: FINERACT-630 URL: https://issues.apache.org/jira/browse/FINERACT-630 Project: Apache Fineract Issue Type: Improvement Reporter: Mexina Daniel For now the downloaded sheets to import loans does not allow the interest which is of decimal value. The platform should allow both decimals and without decimal values of interest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-605) Bug when creating cashier in a teller without an end date
[ https://issues.apache.org/jira/browse/FINERACT-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465940#comment-16465940 ] Mexina Daniel commented on FINERACT-605: Hello [~pnyota] Where did you tested this? It worked fine here https://demo.openmf.org/#/tellers/112/cashiers > Bug when creating cashier in a teller without an end date > - > > Key: FINERACT-605 > URL: https://issues.apache.org/jira/browse/FINERACT-605 > Project: Apache Fineract > Issue Type: Bug > Components: Organization >Affects Versions: 1.0.0 > Environment: Linux >Reporter: Nyota Macharia >Priority: Major > Labels: p1 > Fix For: 1.3.0 > > > When a User creates a teller without an end date, then proceeds to create a > cashier for this teller the following error appears > 05:34:05.816 [http-bio-443-exec-6] ERROR o.s.boot.context.web.ErrorPageFilter > - Forwarding to error page from request [/api/v1/tellers/1/cashiers] due to > exception [Partial cannot be null] > java.lang.IllegalArgumentException: Partial cannot be null > at org.joda.time.base.AbstractPartial.isAfter(AbstractPartial.java:351) > ~[joda-time-2.8.1.jar:2.8.1] > at > org.apache.fineract.organisation.teller.data.CashierTransactionDataValidator.validateCashierAllowedDateAndTime(CashierTransactionDataValidator.java:99) > ~[classes/:na] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-623) The restriction of product mix should apply during submission of another loan
Mexina Daniel created FINERACT-623: -- Summary: The restriction of product mix should apply during submission of another loan Key: FINERACT-623 URL: https://issues.apache.org/jira/browse/FINERACT-623 Project: Apache Fineract Issue Type: Bug Reporter: Mexina Daniel For now when you configure one loan account of Product1 not to be applied when a client already have another loan account of Product2, during the application of another loan account, the system accept to submit and approve the loan and give the error of co-exist during disburse. Expected: The system should give the error of co-exist of the restricted loan when a user is submitting the new loan account since the two loans should not exist together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINERACT-602) Unable to Submit loan application in demo server, going in infinite loop
[ https://issues.apache.org/jira/browse/FINERACT-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445469#comment-16445469 ] Mexina Daniel commented on FINERACT-602: Hello [~santoshmath] I was able to create a loan account https://demo.openmf.org/#/viewloanaccount/2558 For the client you mentioned above, he was activated on 13th February 2018 and you are trying to submit the loan at 11th February 2018 > Unable to Submit loan application in demo server, going in infinite loop > > > Key: FINERACT-602 > URL: https://issues.apache.org/jira/browse/FINERACT-602 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.1.0 >Reporter: Santosh Math >Priority: Blocker > Labels: p1 > Fix For: 1.2.0 > > > For the following client: > [https://demo.openmf.org/#/viewclient/4513] > Try to submit loan (clicking on 'New Loan) > Provide 'Submitted Date' and 'Expected Disbursement Date' as 11th February > 2018 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FINERACT-413) Any character is allowed on creation of client, user and employee
[ https://issues.apache.org/jira/browse/FINERACT-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel closed FINERACT-413. -- Resolution: Fixed > Any character is allowed on creation of client, user and employee > - > > Key: FINERACT-413 > URL: https://issues.apache.org/jira/browse/FINERACT-413 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Mexina Daniel >Assignee: Markus Geiss >Priority: Minor > Labels: p2 > > The system allow any character in firstname, middlename, lastname and > username during creation of user/client/employee. A user of the system can > enter "." in both fields and the system will allow to submit. Practically i > don't think if this is correct > Reproduce this by: > Client->Create client > Fill '.' (dot) In the field for first name, middle name and last name and > other mandatory fields. > The system will allow the submission successful > You do the same in User creation and Employee creation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (FINERACT-544) Delete Client Signature
Mexina Daniel created FINERACT-544: -- Summary: Delete Client Signature Key: FINERACT-544 URL: https://issues.apache.org/jira/browse/FINERACT-544 Project: Apache Fineract Issue Type: New Feature Reporter: Mexina Daniel Assignee: Markus Geiss As in client image were you can upload the image and delete it when you want to remove it, i would suggest to have the same functionality in client signature. When client signature is uploaded, the system should allow the signature to be deleted -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (FINERACT-543) Edit Client Signature
[ https://issues.apache.org/jira/browse/FINERACT-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel updated FINERACT-543: --- Description: As in client image were you can upload the image and come back to replace it by uploading another one when you want, i would suggest to have the same functionality in client signature. When client signature is uploaded, the system to allow the signature to be replaced with another in case it was wrong signature uploaded. was: As in client image were you can upload the image and come back to replace it by uploading another one when you want and even delete it, i would suggest to have the same functionalities in client signature. When client signature is uploaded, the system to allow the signature to be replaced with another in case it was wrong signature uploaded and also allow to delete it. > Edit Client Signature > - > > Key: FINERACT-543 > URL: https://issues.apache.org/jira/browse/FINERACT-543 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Mexina Daniel >Assignee: Markus Geiss > > As in client image were you can upload the image and come back to replace it > by uploading another one when you want, i would suggest to have the same > functionality in client signature. > When client signature is uploaded, the system to allow the signature to be > replaced with another in case it was wrong signature uploaded. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (FINERACT-543) Edit Client Signature
[ https://issues.apache.org/jira/browse/FINERACT-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mexina Daniel updated FINERACT-543: --- Summary: Edit Client Signature (was: Edit and Delete Client Signature) > Edit Client Signature > - > > Key: FINERACT-543 > URL: https://issues.apache.org/jira/browse/FINERACT-543 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Mexina Daniel >Assignee: Markus Geiss > > As in client image were you can upload the image and come back to replace it > by uploading another one when you want and even delete it, i would suggest to > have the same functionalities in client signature. > When client signature is uploaded, the system to allow the signature to be > replaced with another in case it was wrong signature uploaded and also allow > to delete it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (FINERACT-543) Edit and Delete Client Signature
Mexina Daniel created FINERACT-543: -- Summary: Edit and Delete Client Signature Key: FINERACT-543 URL: https://issues.apache.org/jira/browse/FINERACT-543 Project: Apache Fineract Issue Type: New Feature Reporter: Mexina Daniel Assignee: Markus Geiss As in client image were you can upload the image and come back to replace it by uploading another one when you want and even delete it, i would suggest to have the same functionalities in client signature. When client signature is uploaded, the system to allow the signature to be replaced with another in case it was wrong signature uploaded and also allow to delete it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FINERACT-532) Issue in Address section of Client creation page
[ https://issues.apache.org/jira/browse/FINERACT-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207732#comment-16207732 ] Mexina Daniel commented on FINERACT-532: [~aparna.cha...@thitsaworks.com] - I tested and see, This is real an issue, it seems when you submit for the first time although it fails to submit due to validation error the part of address is submitted while it shouldn't > Issue in Address section of Client creation page > > > Key: FINERACT-532 > URL: https://issues.apache.org/jira/browse/FINERACT-532 > Project: Apache Fineract > Issue Type: Bug > Components: Client >Reporter: Chanda Aparna >Assignee: Markus Geiss > Attachments: Address Issue.png > > > Multiple addresses are created during client creation. Please try to get > validation error during client creation. It will create multiple addresses. > Client (Test Client 12334 Client #: 03272) created in Demo site has 4 > times Address created. > This issue is from the current version of demo site (Version > 17.07.01.RELEASE). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FINERACT-533) The field for "is staff" in the client creation does not store data
[ https://issues.apache.org/jira/browse/FINERACT-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205953#comment-16205953 ] Mexina Daniel commented on FINERACT-533: This issue is already reported here https://issues.apache.org/jira/browse/FINERACT-520 > The field for "is staff" in the client creation does not store data > --- > > Key: FINERACT-533 > URL: https://issues.apache.org/jira/browse/FINERACT-533 > Project: Apache Fineract > Issue Type: Bug >Reporter: Chanda Aparna >Assignee: Markus Geiss > > When you create a client and select the field "is staff", it is selected but > after submission and come again to edit, you find the field not selected, > which shows the value was not stored. > For your reference I am giving the Client details in Demo site: *Test > Client-Migrated-10 Client #: 03301* > This issue is from the current version of demo site (Version > 17.07.01.RELEASE). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FINERACT-536) Report categories are inconsistent and causing reports to go missing in the drop-down
[ https://issues.apache.org/jira/browse/FINERACT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205935#comment-16205935 ] Mexina Daniel commented on FINERACT-536: I checked this issue, i see you can change the category of the report direct through the system for the reports which are not pentaho report type. Is there a file of source codes to change the category of the report? so that can be shared for other releases. And for the pentaho report, is it edited only by editing the pentaho file? if yes, what is the means of sharing it after editing? > Report categories are inconsistent and causing reports to go missing in the > drop-down > - > > Key: FINERACT-536 > URL: https://issues.apache.org/jira/browse/FINERACT-536 > Project: Apache Fineract > Issue Type: Improvement > Components: System >Affects Versions: 1.0.0, 1.1.0 >Reporter: thynn win >Assignee: Markus Geiss >Priority: Minor > Labels: GSOC > Attachments: Untitled.gif > > > Currently in Mifos, if you go to Reports menu and use the drop down to see > "Clients" or "Loans", we notice that some reports are not showing up in the > proper list. > For instance, if you pick Reports>Clients , some client reports such as > "Client Listing" will not show up. This is because the category is 'Clients' > while the expected category value for "Clients" drop down is "Client". > The same issue presents for other category such as Loans. In this case, some > loan reports are created with category "Loan" not "Loans" and then they are > not showing up. It's confusing to end users. > To solve this, review all the report categories and make sure they are > consistent with the expected value from the drop down (be it Client or > Loans). > Acceptance criteria: > All the report categories are cleaned up and consistent and they should all > show up under right drop-down. > The end result is a sql script for the next release that fixes it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FINERACT-431) Should not allow more than expected loan term based on 'number of repayments' and 'Repaid every' values.
[ https://issues.apache.org/jira/browse/FINERACT-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171669#comment-16171669 ] Mexina Daniel commented on FINERACT-431: Hello [~santoshmath] I agree with you, this is required improvement that it will be good for the system to have it. > Should not allow more than expected loan term based on 'number of > repayments' and 'Repaid every' values. > - > > Key: FINERACT-431 > URL: https://issues.apache.org/jira/browse/FINERACT-431 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Reporter: Mexina Daniel >Assignee: Markus Geiss >Priority: Minor > Labels: p2 > > In loan application, the frequency of the loan term has to be the same with > the frequency of repaid every (days/weeks/months/years), by this : loan term > = number of repayment x repaid every. > e.g > 1. Create a loan product and fill the necessary requirements (put default > number of repayment = 6, repaid every = 1 month) > 2. Create a loan account to an active client and fill all necessary > requirement ( put loan term = 8 months), leave the number of repayment to 6. > The system is allowing the loan term to be greater than (number of repayments > x repaid every) and provide the repayment schedule based on 'number of > repayments' and 'repaid every' values > It should deny the submission and through an error like when you provide loan > term less than (number of repayments x repaid every) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
