Project:
| View Revisions: Issue #19930 | [ All Revisions ] [ Back to Issue ] | ||
| Summary | 0019930: Various improvements to the dunning module | ||
| Revision | 2012-03-01 17:01 by dbaz | ||
| Description | This issue is to collect several things which need to be improved in the dunning module. 1) Add an orange text button in "Work Flow Definitions" to be able to view the flow picture 2) the email doesn't have feedback at all: * If there is no email configured in "Client" -> "Email Definition" it should raise an error notifying that no existing email configuration * If the email sending fails (bad email configuration, or whatever) it should be notified to the user. Right now the message returned is always "Email sent successfully" even if it is not true. 3) the email sending needs to be made more configurable for an end user when he/she presses the email button in the payment plan, see the attached screenshot on how the standard email button works. The code from the POC should be re-used (ask David Baz for more info) 4) In mp9 or later the dunning module should use the EmailManager.sendEmail method should class instead of the deprecated EmailManager.newMailSession method 5) make the sending of email more a specific feature of the dunning status, by for example having a checkbox in the dunning status which controls if an email is to be send and not only depend on the existence of the email definition. The question is if this fits in the work flow approach. 6) When the user clicks the email button or the print button the system should check directly if all the information is present and not after the user presses ok on the confirmation. If an error exists then it can make sense to show it as a red message bar as this is more the standard. 7) The start dunning process button could be an orange button (to be discussed with Rob) 8) the print dunning letter button should work the same as in poc, to allow to only print or print and attach to the payment schedule 9) inside the dunning status there is a document template which has a child email definition. The email definition should be a sibling of document template and not a child |
||
| Revision | 2012-03-01 17:00 by dbaz | ||
| Description | This issue is to collect several things which need to be improved in the dunning module. 1) Add an orange text button in "Work Flow Definitions" to be able to view the flow picture 2) the email doesn't have feedback at all: * If there is no email configured in "Client" -> "Email Definition" it should raise an error notifing that no existing email configuration * If the email sending fails (bad email configuration, or whatever) it should be notified to the user. Right now the message returned is always "Email sent successfully" even if it is not true. 3) the email sending needs to be made more configurable for an end user when he/she presses the email button in the payment plan, see the attached screenshot on how the standard email button works. The code from the POC should be re-used (ask David Baz for more info) 4) In mp9 or later the dunning module should use the EmailManager.sendEmail method should class instead of the deprecated EmailManager.newMailSession method 5) make the sending of email more a specific feature of the dunning status, by for example having a checkbox in the dunning status which controls if an email is to be send and not only depend on the existence of the email definition. The question is if this fits in the work flow approach. 6) When the user clicks the email button or the print button the system should check directly if all the information is present and not after the user presses ok on the confirmation. If an error exists then it can make sense to show it as a red message bar as this is more the standard. 7) The start dunning process button could be an orange button (to be discussed with Rob) 8) the print dunning letter button should work the same as in poc, to allow to only print or print and attach to the payment schedule 9) inside the dunning status there is a document template which has a child email definition. The email definition should be a sibling of document template and not a child |
||
| Revision | 2012-03-01 11:32 by dbaz | ||
| Description | This issue is to collect several things which need to be improved in the dunning module. 1) the email sending needs to be made more configurable for an end user when he/she presses the email button in the payment plan, see the attached screenshot on how the standard email button works. The code from the POC should be re-used (ask David Baz for more info) 2) In mp9 or later the dunning module should use the EmailManager.sendEmail method should class instead of the deprecated EmailManager.newMailSession method 3) make the sending of email more a specific feature of the dunning status, by for example having a checkbox in the dunning status which controls if an email is to be send and not only depend on the existence of the email definition. The question is if this fits in the work flow approach. 4) When the user clicks the email button or the print button the system should check directly if all the information is present and not after the user presses ok on the confirmation. If an error exists then it can make sense to show it as a red message bar as this is more the standard. 5) The start dunning process button could be an orange button (to be discussed with Rob) 6) the print dunning letter button should work the same as in poc, to allow to only print or print and attach to the payment schedule 7) inside the dunning status there is a document template which has a child email definition. The email definition should be a sibling of document template and not a child |
||
| Copyright © 2000 - 2009 MantisBT Group |
 |