The variable $client->payment_balance is not showing the correct amount. #9421
Labels
Comments
|
the payment_balance column is delayed in its value. ie. if you perform a payment action, it may take 5 minutes for the payment_balance to update. could this explain it? |
|
I believe the payment was applied yesterday. So that exceeds 5 minutes. If it is delayed, perhaps I jumped the gun a bit and it will fix itself tonight? Also, when you said column that made me wonder if this can also be seen in the client list. And yes it is also seen there! A much easier way to see the value output without editing the code. Additional picture of the payment applied to automatically created invoice. |
|
Do you have the cron scheduler running? There is a scheduled task which updates this field every 5 minutes. |
|
I am running the application in a docker container. I have not changed anything other than some small html/php snippets. Here is the crontab on my docker container:/var/www/app> cat /etc/crontabs/root
# do daily/weekly/monthly maintenance
# min hour day month weekday command
*/15 * * * * run-parts /etc/periodic/15min
0 * * * * run-parts /etc/periodic/hourly
0 2 * * * run-parts /etc/periodic/daily
0 3 * * 6 run-parts /etc/periodic/weekly
0 5 1 * * run-parts /etc/periodic/monthlyHere is a capture of my recent logsJust for some added contexts, I pull the latest docker image, override the original entry point script add extra commands to change the html/php snippets, then immediately call the original entrypoint script while leaving the original calling parameters in place. (I have been wanting to get into building docker images without that entrypoint override, but have not had the time to fully do that properly yet.) This is purely to make cosmetic changes for our specific use case. |
|
I thought to also get the daemon controller Supervisord and currently running processes if that helps. Supervisord.conf on my docker container during production:[supervisord]
nodaemon=true
pidfile=/tmp/supervisord.pid
logfile=/dev/null ; nodaemon will cause logs to go to stdout
logfile_maxbytes=0
loglevel=info
[program:php-fpm]
redirect_stderr=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
command=php-fpm
[program:scheduler]
autorestart=true
redirect_stderr=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
command=php artisan schedule:work
[program:queue-worker]
process_name=%(program_name)s_%(process_num)02d
autorestart=true
redirect_stderr=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
numprocs=2
command=php artisan queue:work --sleep=3 --tries=1 --memory=256 --timeout=3600
[eventlistener:shutdown]
command=shutdown.sh
events=PROCESS_STATE_STOPPED, PROCESS_STATE_EXITED, PROCESS_STATE_FATAL
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0Top on my docker container during production:Mem: 7855196K used, 280692K free, 97776K shrd, 248052K buff, 1261424K cached
CPU: 57% usr 3% sys 0% nic 39% idle 0% io 0% irq 0% sirq
Load average: 0.21 0.20 0.21 4/888 202
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
69 65 invoicen S 181m 2% 1 0% php-fpm: pool www
70 65 invoicen S 179m 2% 0 0% php-fpm: pool www
65 13 invoicen S 178m 2% 0 0% php-fpm: master process (/usr/local/etc/php-fpm.conf)
66 13 invoicen S 103m 1% 1 0% php artisan queue:work --sleep=3 --tries=1 --memory=256 --timeout=3600
67 13 invoicen S 103m 1% 0 0% php artisan queue:work --sleep=3 --tries=1 --memory=256 --timeout=3600
68 13 invoicen S 101m 1% 0 0% php artisan schedule:work
13 1 invoicen S 28232 0% 0 0% {supervisord} /usr/bin/python3 /usr/bin/supervisord
148 0 root S 1700 0% 2 0% sh
1 0 invoicen S 1632 0% 0 0% sh /usr/local/bin/prepend_entrypoint.sh supervisord
64 13 invoicen S 1628 0% 0 0% {shutdown.sh} /bin/sh /usr/local/bin/shutdown.sh
202 148 root R 1624 0% 0 0% top |
|
I have updated the docker container to v5.8.47-W156 and it has not changed the issue. |
|
I have opted to purge the client and spend a couple days recreate them due to this not going away on its own. I now no longer have access to the data for test purposes. I suppose I will also close the ticket as it is no longer relevant. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setup
v5.8.39-W156
Docker
Interface
Checklist
Describe the bug
I have placed the custom code of
$client->payment_balanceinv5-develop/resources/views/portal/ninja2020/dashboard/index.blade.phpand everything works perfectly.Except on one of my clients it shows an incorrect balance. It is supposed to read as $23.24 but is instead showing $63.68. I suspect it is not subtracting one of the $40.44 invoices. The April 1st invoice did automatically use some of the available unapplied payment via recurring invoice creation, perhaps there is a bug there?
(Additional side note, I had a client that had $0.01 in unapplied payment, but, it did not use it automatically. so something weird is happening there. Let me know if I need to make this a different bug report.)
The client has 4 payments for their entire history as follows:
Steps To Reproduce
Not sure how to reproduce. I have put
{{ App\Utils\Number::formatMoney($client->payment_balance, $client) }}somewhere in the dashboard page to get the variable's output as expected.May need to trigger the automatic use of unapplied payments.
Expected Behavior
Return the payment balance of the client that has not been used yet.
Screenshots
The text was updated successfully, but these errors were encountered: