88 lines
4.0 KiB
Plaintext
88 lines
4.0 KiB
Plaintext
POSSIBLE CHANGES TO APP OR DOCUMENTATION
|
|
|
|
|
|
list clients notes - noteType needs a 'text' DOING
|
|
createdOn & updatedOn values... do they need reformatting? DOING
|
|
|
|
loan template - repaymentSchedule is null - I can't see it set in the app - used in preview schedule functionality maybe? - probably not used and will be deleted
|
|
|
|
|
|
loan retrieve DOING
|
|
break up data into categories.. e.g.
|
|
Basic - lifeCycleStatusText thru
|
|
Convenience - open thru waitingForDisbursal then maxSubmittedOnOffsetFromToday, maxApprovedOnOffsetFromToday , maxDisbursedOnOffsetFromToday, actualLoanTermInDays, actualLoanTermInMonths, loanTermInDays, loanTermInMonths
|
|
Permission - undoDisbursalAllowed, waiveAllowed, makeRepaymentAllowed, rejectAllowed, withdrawnByApplicantAllowed, undoApprovalAllowed, disbursalAllowed, anyActionOnLoanAllowed
|
|
flatten loadData
|
|
repaymentSchedule
|
|
summary
|
|
loanRepayments
|
|
|
|
|
|
Loan Transitions ... approve etc - possible done
|
|
if "eventLocalDate" parameter added with string date then instead of parameter not support msg do get jackson conversion exception.
|
|
approve loan (already closed) with approval date before submitted date
|
|
The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>org.mifosng.platform.loan.domain.InvalidLoanTimelineDate: The date of when loan is approved cannot be before its submittal date.
|
|
|
|
approve loan (already closed) with approval date after submitted date
|
|
Column 'loan_status_id' cannot be null; SQL [n/a]; constraint [null]; nested exception is org.hibernate.exception.ConstraintViolationException: Column 'loan_status_id' cannot be null
|
|
|
|
if I do an approve when already approved also get
|
|
Column 'loan_status_id' cannot be null; SQL [n/a]; constraint [null]; nested exception is org.hibernate.exception.ConstraintViolationException: Column 'loan_status_id' cannot be null
|
|
|
|
|
|
sometimes clientId returned... always loanId OK? DOING
|
|
|
|
|
|
Loan Transactions (repay and waive - and maybe reversal - but not disbursement) general talk needed as retrieve could work for any txn?
|
|
transaction type... UNKNOWN(0), DISBURSEMENT(1), REPAYMENT(2), REVERSAL(3), WAIVED(4);
|
|
Create - (command has string and proper value fields... so assume its like eventDate above)
|
|
|
|
retrieve: display transaction type value? DOING
|
|
"principal" : null, "interest" : null, total, "totalWaived" : null, "overpaid" : null, and the offset - are nulls ever put in? DOING
|
|
adjust:
|
|
|
|
when adjusting a disbursal - The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>java.lang.IllegalArgumentException: Only repayment and waiver transactions can be adjusted. DONE
|
|
on create and adjust, app returns clientId can it be transaction id or loanId?
|
|
|
|
|
|
|
|
BUT NOT FOR NOWS
|
|
should be able to get clients by branch as well
|
|
also get loans of different status's by branch etc
|
|
list of loan transactions not available (except in summary - presume repayments section has repayments and waivers and adjusts)
|
|
|
|
|
|
|
|
|
|
DOCUMENTATION REMAINING
|
|
|
|
Just Errors section to do in the Overview section
|
|
|
|
Identify Fields that need explaining
|
|
=========================
|
|
bit of loan product/loan
|
|
|
|
repayment/waiver - describe waiver
|
|
why fields "totalWaived", "overpaid"
|
|
|
|
|
|
take aout /v1 from resource name.
|
|
|
|
maxJoinedOnOffsetFromToday
|
|
|
|
- create a client example could show second example with the
|
|
field clientOrBusinessName being used instead of firstname, lastname,
|
|
no mention of it.
|
|
- mention if optional externalId is provided, it must be unqiue?
|
|
- TODO - check update of client with 'clientOrBusinessName' with
|
|
a first name/last name results in error
|
|
|
|
- Loans
|
|
- digitsAfterDecimal and currencyCode should NOT be sent during
|
|
creation - they should be inherited from the product. Likewise for
|
|
update.
|
|
- Would be better if it was possible to not pass any of these
|
|
details if defaults from loan product are acceptable, they can be
|
|
inherited from loan product.
|
|
|