I witnessed another bug. Suppose the user has credits in the amount of 100 units. Suppose each SMS is 1 credit. Suppose the user used 35 SMS and left him 65 units. If you delete his credit, his balance (ideally) should be zeroed, i.e. on it the account should be 0. The bug is manifested in the fact that if you delete a user’s credit with a balance (it was initially 100) 65 in his account will remain -35 instead of 0. I ask to fix the bug. Thank you for your product.
can you confirm with screenshots
before deletion admin credits was +0.15
after delete admin credits
in last screenshot we may see that admin credit stand -0.85
So what is ur suggestion?
My subjective opinion is:
The user must have credits, but they must be managed flexibly, ie:
- As previously written (TTL (Time To Live) for for credits), loans should have a lifetime, i.e. they should be calculated for a period of use of a certain period (the manager should have the option to set the days interval within which a valid number of SMS will be valid);
1.1. At the end of the SMS package term, the subscriber’s balance must be zeroed (if this is the only deposit) or return to the initial position ie. if, for example, there were 100 on the balance sheet, and with this, 200 units were added and when the expiration date of the added 200-units SMS should remain 100;
1.2 If it is monolithic (one large deposit, after the end, the user’s balance must be 0;
- When deleting credits, they must be reset. those. on the balance sheet should be 0 (if this is all the loans that it has on the balance sheet) and certainly should not go into minus, or if he, in addition to the number of CMCs to be deleted, there are still, the unites to be deleted must be deducted and should remain exactly how much does the rest of the deposit.
Adding credits is transaction, if you remove it then ofcourse we need to simply calculate whats left.
Whats wrong with negative balance ?
In your example admin did remove the transaction, so the balance in playSMS become negative to be “balance”
I realized this was a transaction! But the work of the service should work on the basis of ordinary arithmetic, is not it? Those. if there were 500 on the balance sheet, 340 was lost, and there were 260 units left. The month is ending, I must reset it. Instead, a negative floating-point number appears. Even if the balance is not zeroed, when deleting everything, again, it should start from 0. This will be the correct distribution of events.
You added 100, and then used 65, thus left 35, then you remove the 100 transaction, so it should be -65.
If its -35 then its a bug, but -65 is not, the user does owe -65 for the credit he used when he still got 100.
Service PlaySMS, should reflect the work of the mobile operator. Because the mobile operator provides services on a monthly basis, therefore the services for PlaySMS clients must adapt to them. (Unless, of course, in addition to using a billing system that provides special tariff plans for users of PlaySMS). As I wrote earlier, the first thing that must include credits is the lifetime of SMS units, the second one could be reset (in cases when the lifetime for an SMS package is not set).
Oh ok, I thought its a real bug, if its a request then yes it can be anything.
Please submit a request in github, Ill mark as request, if eventually I go that way then I will write the code. Thanks.
Yes of course without problems.
Btw what you post as bug is not a bug, it is by design.
- Admin add 100, user balance become 100.
- User used 35, user balance become 65.
- Admin delete 100 from user then user owe the system -35. User credit must not be zero, it has to be -35.
This is the result of transactions! Once again I’m telling you, from the point of view of usability, from the point of view of management, this is not convenient. You have a user with a balance. You either zero it at the beginning of the month and the balance becomes negative. Either add an underserved amount of SMS and round to the appropriate rate. And if you had the opportunity to give the life time of a pack that gives a limit (a certain amount of SMS) for a certain period. And add a policy for adding credits to users automatically. For example, ABS user needs every month, a credit of 100 units. A policy that automatically added a user’s credit at the beginning of the month (which, incidentally, is an idea for you, for the future). A manager, this would not do, instead, he would remain in the role of a controller.