| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000143 | SKGB-intern | sepa | public | 2014-11-28 16:58 | 2015-10-18 18:02 | ||||||||
| Reporter | aj | ||||||||||||
| Assigned To | |||||||||||||
| Priority | low | Severity | major | Reproducibility | have not tried | ||||||||
| Status | acknowledged | Resolution | open | ||||||||||
| Projection | major rework | ETA | > 1 month | ||||||||||
| Platform | The Web | OS | HTTP | OS Version | 1.1 | ||||||||
| Product Version | 1.3.1 | Product Build | 2014-11-17 | ||||||||||
| Target Version | 2.1 | Fixed in Version | |||||||||||
| Summary | 0000143: Locking for mandates used by multiple members | ||||||||||||
| Description | Members that share the same mandate apparently don't share the 'chek' lock. On 2014-11-17 two distinct pre-notifications were issued for the same UMR. Since both were 'rcur', this might not result in any actual problems this time around (unkown at this point). But clearly a second debit should not be possible wihout explicit unlocking by the user. | ||||||||||||
| Additional Information | Debiting two or more members who share an UMR is not an issue if done at the same time as part of the same debit run. SKGB-intern will then correctly identify the issue and aggregate the debits in a single transaction by adding the amounts. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
| There are no notes attached to this issue. |
| Notes |