Since there are different means to pay, I tried clicking the PAID button, but nothing happens.
Looking at the Debug logs, I am seeing:
ERROR - 2023-08-21 17:52:02 → Severity: Notice → Trying to access array offset on value of type bool /opt/ASTPP/web_interface/astpp/application/libraries/Usertracking.php 167
Also, this may not be related, but I am also seeing this just by loading the invoice page:
Yes, the design of label should be different to avoid and misunderstanding. Please log the suggestion.
About package and ‘no sufficient fund’ message, are you dialling the number starting the same prefix as you have added in the created and assigned package?
Yes I am doing that. That still leaves the issue of conflicting balances with one showing paid, and the other negative balance. So which is correct?
As I mentioned, I am still seeing two errors:
ERROR - 2023-08-25 00:00:34 --> Severity: Notice --> Undefined index: billseconds /opt/ASTPP/web_interface/astpp/application/models/common_model.php 204
ERROR - 2023-08-25 00:00:34 --> Severity: Notice --> Trying to access array offset on value of type bool /opt/ASTPP/web_interface/astpp/application/libraries/Usertracking.php 224
Could those have an effect on the issue?
Also, suggestion of making a change to PAID, which also so happens to even act like a button which does nothing. That is the reason for opening this thread in the first place.
I am no longer getting the insufficient funds error, but still brings me back to how the package was paid for, and why the low balance still exists on the main page.
Also, while the previous problem has gone away, I am seeing a new issue related to making the same call.
About package purchase, how did you purchased, meaning paid while your have purchased it from customer potall?
Incompatible_destination has to do with codec negotiation
I am using a softphone which does have uLAW and aLAW enabled. I am also using the default SIP Profile which I see it is using PCMA & PCMU. As well, the gateway is also set up to use PCMA & PCMU.
Update 2: Using sngrep, I see the source of the issue is actually coming from the provider. It is responding with SIP/2.0 488 Not acceptable here. I guess I will have to get with them to see what the issue could be.
I guess the issue leftover for now is how the plan was paid for without payment. In addition, the period of the product of 30 days has long expired. Maybe time for a new thread on that?
Update 3: The call fail issue is with the provider which I am trying to resolve now. That still leaves the unpaid/paid balance issue, and package has gone over 30 days.
So, I am seeing conflicting information. Balance is not paid, but for some reason, it is PAID on the main page. and a balance of 100, with a credit limit of 200 on a prepaid account.
@KNERD
This static balance and credit limit are ‘static’ not ‘real-time or dynamic’, the reason is that further logic can consider the available balance or credit limit for the account which is having package active for the dialed destination and can allow the call to pass instead checking its actual balance or credit limit.
About the case of package purchase without balance, that cannot be done, and its working as it should be, now to check how it happened in your case, can you reproduce it and share exact step you are following?
As mentioned, this testing was done on a PREPAID account.
It should not have any credit, or am I incorrect? I tried adding a credit limit to it, but I was unable to. That is why I put in the suggestion for a hybrid account of being prepaid with some calling being postpaid.
For the package purchase, as I mentioned before, during creation I had the YES selected for “Apply on Existing Accounts” during the Product creation.