Roundup Issue with Pending amount

[alvinaraujo]

I have an entry in the system, where the pending amount is being shown as 1500.80 INR in database(invoice_amounts table). Now when I go to enter payment in payment form , it shows pending amount is 1501 INR coz of round up.

Now when I enter 1501 INR, it doesnt make me submit the payment form as the system checks if the payment amount is <= pending amount.

I am using the latest updated version of invoiceplane, please advise an entry point for code level changes that I have to do.

[miquel_cabanas]

Can you upload a screenshot?

There are several ways to enter a payment, which one are you using?

• the Options button -> Enter Payment in the View Invoices window, that opens a modal window,
• the Payments -> Enter Payment option in the top menu that opens the payments/form page, or
• the New button in the View Payments that opens the payments/form page too.

What happens if you enter in the payment form the amount saved in the database,1500.80?

[alvinaraujo]

The problem is that the amount is rounded up and showed in the amount field, and the user has no clue that the actual amount is 1500.80… When I went to check in the database, thats where I came to know that the actual amount is 1500.80.-------------This is happening in the modal window.

==========================================

The second screnshot shows an error page when i try to enter a payment more than the amount due, from the payments module (payments->new).

==========================================
The same error is encountered in the ajax call while entering the payment(I am referring to screnshot 1) and hence it does’nt get submitted.

[miquel_cabanas]

The Payments Form in the second screenshot looks different than the one in the last version v1.5.9 (see demo site at http://demo.invoiceplane.com). Which version of IP are you running? because I don’t see that behavior in the current version.

[alvinaraujo]

I am running 1.5.9. The same is happening even with the online version. Try updating a value of amount greater than the actual invoice amount, you would see that error.

[miquel_cabanas]

I am a bit confused now. I thought the problem was that IP was displaying the rounded up amount of the invoice and fooling users, but now you say the problem is that IP is not accepting over-payments which are planned for IP 2.0 (see IP-253 - Add option to add an existing balance for clients.)

So, is your IP installation displaying rounded-up amounts in the payment forms or are you trying to enter an over-payment?

[alvinaraujo]

You need to go through the screenshot more precisely, I have made myself very clear. For better understanding

• Create an invoice which equates to a decimal amount may be 1000.80/- and check in the database what gets saved(confirm that in the database table “invoice_balance = 1000.80”).
• Now come to the front end and do the payment.

In the payment form you will be shown 1001/- as the balance amount, this transaction would not go through when u enter 1001. Hope this clarifies the issue…

[miquel_cabanas]

I’ve run a test case in the demo version. I have created an invoice with a total amount of $22,729,74,

The amount is correctly displayed in the modal “Enter Payment”

and in the “Payment Form”

and if I enter the correct amount (equal or less than the total amount) the payment gets processed,

and the invoice status changes,

In summary, I cannot reproduce the problem you describe in the current stable version.

[miquel_cabanas]

Just in case, can you post a screen shot of your “Amount Settings” in the Settings → System Settings → General tab?

For instance, this was the configuration of demo when I ran the test,

[alvinaraujo]

Database Entry

Payment Modal

Payment Form

Settings

The only difference I see is that my (decimal point) field value is empty. It seems to work fine when I put a value “.”
Had to face a lot of hardship with this, probably if we put some validation on this would be great and helpful for those who might end up in a mess in case they remove the decimal point value.

Thanks for your quick revert miquel_cabanas

[miquel_cabanas]

Glad to know that the problem is solved.

Also, you are right that the code should be improved to make sure this error doesn’t happen, so I have opened an issue,

IP-727 - Improve handling of decimal and thousand separator symbols

[miquel_cabanas]

An additional benefit is that I have spotted another small bug,

IP-728 - Add “Bank Transaction ID” field to the modal window “Enter Payment”

[miquel_cabanas]

I have just submitted a fix for this problem,

@miquel_cabanas

IP-727 - Improve handling of decimal and thousand separator symbols

if accepted, in future versions users will choose the number format and the decimal and thousands separators will be set accordingly by the software.