Jump to content

Problem About The Invoice


chinapao

Recommended Posts

Can you provide a screenshot or steps to duplicate?

 

 

Hi Paul, please refer to the attached picture. ..This client has paid the his invoice by paypal but it remains open...  I also tried to cron manually but this problem remains so I think it is not about the cron.

 

If you need I can provide you a root access to my client area or staff area.

123.JPG

Link to comment
Share on other sites

  • 2 weeks later...

I experienced this problem, too.

 

Two thoughts about the possible cause:

 

1. Calculating:

I see that the amounts are saved into the database in 4 digit format. But payments are usually processed in 2 digit format. So in some cases the client stays on a milli digit due.

e.g.:

Invoice #1 has total $ 49.6779, the client is billed for $ 49.68 -> ok, invoice gets closed

Invoice #2 has total $ 28.4706, the client is billed for $ 28.47 -> the invoice remains open

previous_due always stays on $ 0.0000

 

After checking this I tried to put a manual payment about the remaining digits to the client. It was saved, but didn't help: Now the due of the client is shown with a minus, but invoice still remains open.

 

I'm not sure about the calculating behaviour, but this could be the cause, I think. Suggestion: save totals in 2 digit format or round it up / down, so that the last two digits are zero.

 

(btw the 4 digit values are set because of calculated taxes.)

 

2. Order of cron tasks:

I wondered when using a payment gateway that the client still gets an unpaid invoice per mail. So I checked the order of the cron tasks. I think the run in the order of their ID:

 

|1|create_invoice
|2|autodebit
|3|payment_reminders
|4|apply_payments
|5|provision_pending_services
|6|cancel_scheduled_services
|7|card_expiration_reminders
|8|deliver_invoices
|9|backups_sftp
|10|suspend_services
|11|exchange_rates
|12|deliver_reports
|13|cleanup_logs
|14|backups_amazons3
|15|process_renewing_services
|16|unsuspend_services
|17|license_validation
|18|accept_paid_orders
|19|poll_tickets

 

I'm not sure, but could it be, that "accept_paid_orders" should be before "deliver_invoices" and before "apply_payments" ? I think the best would be if "deliver_invoices" would run at last and "accept_paid_orders" at the beginning.

Link to comment
Share on other sites

Sorry, something's wrong in my post above (but this is more strange):

Invoice #1 was total $ 28.4706, the client was billed for $ 28.47 -> the invoice got closed

Invoice #2 was total $ 49.6779, the client was billed for $ 49.68 -> the invoice remains open

 

Here an partial output of the transaction arrays:

 

Invoice #1:

[amount] => 28.4700[applied_amount] => 28.47[credited_amount] => 0

 

Invoice #2:

[amount] => 49.6800[applied_amount] => 49.6779[credited_amount] => 0.0020999999999987

Question: Where does the credited_amount go to? I didn't find an entry for this in the db.
And what happens with the due of 0.0006 of invoice #1 ?

Link to comment
Share on other sites

Were you using quantities that resulted in these invoice values, or were these values entered with 4 decimal precision? I ask to make sure the value stored for the line item is indeed correct.

 

Thanks for your example, it appears as if an "overpayment", paying 49.68 when 49.6779 is due, (and correctly rounded to 49.68) results in the invoice not being marked paid.

Link to comment
Share on other sites

I'm not able to duplicate this.

 

  1. Find client
  2. Create Invoice with line item amount of 49.6779
  3. Pay invoice with CC payment for 49.68
  4. Invoice is closed, 49.68 is applied to the invoice

Can anyone you provide steps to duplicate? We need full details including tax rules applied (levels, amounts, country/state), all line items of the invoice (quantity, amount, and whether or not it is taxable), currency format, and any previous applied amounts to the invoice.

Link to comment
Share on other sites

It seems the failure was caused by the gateway. The $amount was sent in another format than inside the $invoice_amounts array.

And it was triggered by using another currency format (##.###,##) - so sometimes the numbers were interpreted as string, sometimes as number. It's not persistent. E.g. when I add a manual payment for the client as staff, the first field forces numbers in format ##.##, the second field, where amount is applied to specific invoices allows ##,## - in the line items and service packages I always used ##,## - so the ##.## at manual payment was a little surprise.

 

For me I got it working now by forcing the gateway to use persistent number formats for both amount variables. And using ##.## for manual payment entries.

Link to comment
Share on other sites

Were you using quantities that resulted in these invoice values, or were these values entered with 4 decimal precision? I ask to make sure the value stored for the line item is indeed correct.

 

I use values with 4 decimal precision nearly everywhere. That's because I have to precalculate the tax, I mentioned that in another thread. My clients prefer round numbers in the totals.

In Germany we have a tax of 19%. This makes a low decimal precision unusuable. E.g. try to find a value for the line item, that will be 17.00 including tax. 17 / 1.19 = 14.2857143

In Blesta 2.5 I could not do this, 14.28 gives a total of 16.99, and 14.29 a total of 17.01 ...

 

Fortunately the calculation with the 4 decimal precision works now! :-)

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...