Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext’s rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here’s a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups "ERPNext User's Forum" group.
On 02-Aug-2013, at 7:03 AM, lxnow <la...@union.ph> wrote:
Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext's rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here's a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups “ERPNext User’s Forum” group.
Now I understand why the number of decimal points for the float numbers is so important. And if I understand correctly, in order to get to results very, very close to Approach 2, I would need to increase decimal points to 6. This would reduce the margin for rounding error so much that it would be acceptable.
But you're right, I am concerned about it looking ugly. One solution I propose here is to have the number maintained at 6 decimals but displayed in 2 decimals (sorry, wasn't this the approach you previously took before the July UI change?)
Another possible solution is to have this kind of tax treatment be used in the Tax Master as a separate type; wherein tax is only applied to net total and not per item. Is this something that can already be done in the current feature set?
On Fri, Aug 2, 2013 at 1:24 PM, Rushabh Mehta <rm...@gmail.com> wrote:
Laurence,
If you need to have 2 decimals for the rate, then you are going to have some rounding variance. If you keep more decimals then it looks ugly.
On 02-Aug-2013, at 7:03 AM, lxnow <la...@union.ph> wrote:
Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext's rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here's a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups "ERPNext User's Forum" group.
We will have to look at what we can do. Give us some time. Can you raise this issue on github. It will help us to keep track of it.
Thanks,
Anand.
On 02-Aug-2013, at 11:37 AM, Laurence Cua <la...@union.ph> wrote:
Now I understand why the number of decimal points for the float numbers is so important. And if I understand correctly, in order to get to results very, very close to Approach 2, I would need to increase decimal points to 6. This would reduce the margin for rounding error so much that it would be acceptable.
But you’re right, I am concerned about it looking ugly. One solution I propose here is to have the number maintained at 6 decimals but displayed in 2 decimals (sorry, wasn’t this the approach you previously took before the July UI change?)
Another possible solution is to have this kind of tax treatment be used in the Tax Master as a separate type; wherein tax is only applied to net total and not per item. Is this something that can already be done in the current feature set?
On Fri, Aug 2, 2013 at 1:24 PM, Rushabh Mehta <rm...@gmail.com> wrote:
Laurence,
If you need to have 2 decimals for the rate, then you are going to have some rounding variance. If you keep more decimals then it looks ugly.
On 02-Aug-2013, at 7:03 AM, lxnow <la...@union.ph> wrote:
Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext's rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here's a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups “ERPNext User’s Forum” group.
But as an aside, under Global Default settings, the float precision option is described as “Precision for Float fields (quantities, discounts, percentages etc) only for display. Floats will still be calculated up to 6 decimals.”
If this were the case, then there shouldn’t be significant rounding differences in the two approaches I described below. Yet it appears there is. Is this description deprecated?
On Friday, August 2, 2013 2:14:48 PM UTC+8, Anand Doshi wrote:
Hi Laurence,
We will have to look at what we can do. Give us some time. Can you raise this issue on github. It will help us to keep track of it.
Thanks,
Anand.
On 02-Aug-2013, at 11:37 AM, Laurence Cua <la…@union.ph> wrote:
Now I understand why the number of decimal points for the float numbers is so important. And if I understand correctly, in order to get to results very, very close to Approach 2, I would need to increase decimal points to 6. This would reduce the margin for rounding error so much that it would be acceptable.
But you’re right, I am concerned about it looking ugly. One solution I propose here is to have the number maintained at 6 decimals but displayed in 2 decimals (sorry, wasn’t this the approach you previously took before the July UI change?)
Another possible solution is to have this kind of tax treatment be used in the Tax Master as a separate type; wherein tax is only applied to net total and not per item. Is this something that can already be done in the current feature set?
On Fri, Aug 2, 2013 at 1:24 PM, Rushabh Mehta <rm...@gmail.com> wrote:
Laurence,
If you need to have 2 decimals for the rate, then you are going to have some rounding variance. If you keep more decimals then it looks ugly.
On 02-Aug-2013, at 7:03 AM, lxnow <la...@union.ph> wrote:
Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext's rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here's a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups “ERPNext User’s Forum” group.
I had set decimals to 6 decimals and based on my desired Approach 2: VAT-inclusive item pricing with VAT back-computed out from the grand total, here’s what I’ve figured out so far:
1. net_total_export = the Grand Total I want to show for the order/deliver note/invoice
2. but grand_total_export > net_total_export. is it possible to make grand_total_export = net_total_export?
3. other_charges_totalis the correct VAT tax I want to see and will show in our print outs and records
I need some help with #2. I can easily opt to hide grand_total_export when sending out the sales invoices, but this would create variances with the invoice records when it comes to paying receivables.
On Friday, August 2, 2013 2:58:33 PM UTC+8, lxnow wrote:
I’ve submitted to github.
But as an aside, under Global Default settings, the float precision option is described as “Precision for Float fields (quantities, discounts, percentages etc) only for display. Floats will still be calculated up to 6 decimals.”
If this were the case, then there shouldn’t be significant rounding differences in the two approaches I described below. Yet it appears there is. Is this description deprecated?
On Friday, August 2, 2013 2:14:48 PM UTC+8, Anand Doshi wrote:
Hi Laurence,
We will have to look at what we can do. Give us some time. Can you raise this issue on github. It will help us to keep track of it.
Thanks,
Anand.
On 02-Aug-2013, at 11:37 AM, Laurence Cua <la…@union.ph> wrote:
Now I understand why the number of decimal points for the float numbers is so important. And if I understand correctly, in order to get to results very, very close to Approach 2, I would need to increase decimal points to 6. This would reduce the margin for rounding error so much that it would be acceptable.
But you’re right, I am concerned about it looking ugly. One solution I propose here is to have the number maintained at 6 decimals but displayed in 2 decimals (sorry, wasn’t this the approach you previously took before the July UI change?)
Another possible solution is to have this kind of tax treatment be used in the Tax Master as a separate type; wherein tax is only applied to net total and not per item. Is this something that can already be done in the current feature set?
On Fri, Aug 2, 2013 at 1:24 PM, Rushabh Mehta <rm...@gmail.com> wrote:
Laurence,
If you need to have 2 decimals for the rate, then you are going to have some rounding variance. If you keep more decimals then it looks ugly.
On 02-Aug-2013, at 7:03 AM, lxnow <la...@union.ph> wrote:
Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext's rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here's a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups “ERPNext User’s Forum” group.
This issue has been fixed. It was a due to an incorrect choice of sequence of calculation when back-calculating tax exclusive prices.
Thanks,
Anand.
On 03-Aug-2013, at 1:48 PM, lxnow <la...@union.ph> wrote:
I had set decimals to 6 decimals and based on my desired Approach 2: VAT-inclusive item pricing with VAT back-computed out from the grand total, here's what I've figured out so far:
1. net_total_export = the Grand Total I want to show for the order/deliver note/invoice
2. but grand_total_export > net_total_export. is it possible to make grand_total_export = net_total_export?
3. other_charges_totalis the correct VAT tax I want to see and will show in our print outs and records
I need some help with #2. I can easily opt to hide grand_total_export when sending out the sales invoices, but this would create variances with the invoice records when it comes to paying receivables.
On Friday, August 2, 2013 2:58:33 PM UTC+8, lxnow wrote:
I've submitted to github.
But as an aside, under Global Default settings, the float precision option is described as "Precision for Float fields (quantities, discounts, percentages etc) only for display. Floats will still be calculated up to 6 decimals."
If this were the case, then there shouldn't be significant rounding differences in the two approaches I described below. Yet it appears there is. Is this description deprecated?
On Friday, August 2, 2013 2:14:48 PM UTC+8, Anand Doshi wrote:
Hi Laurence,
We will have to look at what we can do. Give us some time. Can you raise this issue on github. It will help us to keep track of it.
Thanks,
Anand.
On 02-Aug-2013, at 11:37 AM, Laurence Cua <la...@union.ph> wrote:
Now I understand why the number of decimal points for the float numbers is so important. And if I understand correctly, in order to get to results very, very close to Approach 2, I would need to increase decimal points to 6. This would reduce the margin for rounding error so much that it would be acceptable.
But you’re right, I am concerned about it looking ugly. One solution I propose here is to have the number maintained at 6 decimals but displayed in 2 decimals (sorry, wasn’t this the approach you previously took before the July UI change?)
Another possible solution is to have this kind of tax treatment be used in the Tax Master as a separate type; wherein tax is only applied to net total and not per item. Is this something that can already be done in the current feature set?
On Fri, Aug 2, 2013 at 1:24 PM, Rushabh Mehta <rm...@gmail.com> wrote:
Laurence,
If you need to have 2 decimals for the rate, then you are going to have some rounding variance. If you keep more decimals then it looks ugly.
On 02-Aug-2013, at 7:03 AM, lxnow <la...@union.ph> wrote:
Hi, we utilize value-added tax in our sales. I realize there are two ways to compute for sales tax.
Approach 1: declare item prices pre-tax, total the amount, then add the tax a the end on the total.
Approach 2: declare item price tax-inclusive, total the amount, then back-compute the sales tax from the total amount (tax = amount / (1+tax rate))
Due to erpnext's rounding off to two decimal points, the values will differ in tax, net total and grand total for the two approaches. (here's a sample calculation to illustrate) I observed that erpnext uses approach 1, but for our company, we need to use Approach 2. Does anyone have advice how to do this?
–
You received this message because you are subscribed to the Google Groups “ERPNext User’s Forum” group.