Allow calculation of total to use rounded tax amounts, and other invoice processing

OK, it was western-centric of me to assume that all currencies have a two decimal point cutoff point. The rupee and yen seem to work differently. Here are some random links (ok, maybe I am getting too much into this):

- an analogous bug report for another software product
- Some european rounding rules
- Some yen rounding rules
- Some rupee rounding rules

(By the way, I would be curious to hear from anyone in India, Sri Lanka, Japan or other countries which use diverse rounding systems.)

Perhaps we could introduce the concept of a 'currency pack' which defines some callback functions. Third-party modules could then define these currency packs as needed via hooks.

For example, when it comes time to calculate totals on the invoice, in line with the attached images in the issue description, we could do something like:

$invoice = array(
  'lines' => array(
    array('amount' => 0.11),
    array('amount' => 0.09),
    array('amount' => 0.08),
);
  
  // defaults to 'North America and Europe' if no attribute is defined in the settings pages.
$currency_pack = storminvoice_get_currency_pack();

  // call the currency pack hook
foreach (module_implements('currency_calc') as $module) {
  module_invoke($module, 'currency_calc', 'apply', $invoice, array('pack' => $currency_pack)));
}

/*
$invoice should now contain 

$invoice = array(
  'lines' => array(
    array('amount' => 0.11, 'tax1' => 0.01, 'tax2' = 0.01, 'total' => 0.12),
    array('amount' => 0.09, 'tax1' => 0.0, 'tax2' = 0.01, 'total' => 0.10),
    array('amount' => 0.08, 'tax1' => 0.0, 'tax2' = 0.01, 'total' => 0.09),
  'subtotal' => 0.28,
  'tax1' => 0.01,
  'tax2' => 0.02,
  'total' => 0.31
);
*/

// ...

function storminvoice_currency_calc($op, &data, $options) {
  switch($op) {
    case 'names':
      return array('North America and Europe', 'Storm Invoice Legacy');
      break;
    case 'apply':
      switch($options['pack']) {
         case 'North America and Europe':
           // ...
           // do our calculation...
           // ...
           break;
         case 'Storm Invoice Legacy':
           // ...
           // do what we always did...
           // ...
           break;
         default:
             // do nothing. Another hook call defines this.
           break;
      } 
  }
}

now, it will be quite easy to create a patch, or for a third party module to do something like:

function stormyen_currency_calc($op, &data, $options) {
  switch($op) {
    case 'names':
      return array('Yen');
      break;
    case 'apply':
      switch($options['pack']) {
         case 'Yen':
           // ...
           // do our calculation with the yen...
           // ...
           break;
      } 
  }
}

Anyhow, your comments are welcome.

Albert.

Hi, after pondering this, I don't think a simple setting would work, because there are several settings:

- *when* to calculate taxes (at the very end or at every line)?
- round at every step or not?
- how many decimal points?
- whether or not to allow different tax settings on different lines and how to deal with this if taxes have to be calculated at the end.

All of these settings can be packaged into a rounding mechanism. My suggestion is to package storm with two rounding mechanisms: default (as always) and a new setting: something like "apply taxes at the end and round every step of the way".

Further, it is impossible to predict every single possibility for these settings, so my solution would be to provide a hook allowing modules to define other rounding mechanisms if they are required.

Here is a patch that does this that I've used without side effects. I am including some simpletests as well. Comments welcome.

I have found in the past that when it is hard to implement all possibilities, the best thing is to provide a hook to avoid to try to be all things to all people in the main module. Hooks after all are what make Drupal so scalable.

Let's say in the future someone in Quebec wants to start selling insurance alongside banking services alongside computer services, and all are taxed differently. It is likely that this will never happen, so we don't want to implement it now; If it does happen, I like the idea of that person having the option to have a module for that rather than submitting a patch with yet more options to click.

This being said, I too am open to be convinced, but for now I'm still not sure :)

What do you think?

Cheers,

Albert.

In fact, there being a hook opens the possibility of a lot more than rounding.

What do you think if the following scenario, which corresponds to my case? In addition to rounding and using a unique tax system per invoice, I also would like to:

- make sure my client's Organization has a billing address and recognized province and country.
- make sure only one tax is used if selling to Canada outside Quebec and that its rate is correct.
- make sure two taxes are used if selling to Quebec and that their rates are correct.
- make sure not taxes are used if selling outside Canada.
- provide a warning if the total before taxes exceeds my client's credit limit, which is fetched from a cck field.
- make sure the second tax rate is correct according to the date of the invoice: in my jurisdiction, 2 changes to tax rates have been announced in the last 2 years, and I got a few complaints from clients because I forgot to lower the tax rate on the right date. Two more changes have just been announced in the coming years.

All this processing exceeds the concept of rounding, which is why I am changing the title of this issue slightly.

What do you think: is it better to provide a simple setting for rounding, and have users such as myself use hooks such as hook_form_alter to set this up all this stuff? Or to provide a hook as in comment #3, above (which might be easier to use for beginner programmers because they can be inspired by the rounding example)? I would have penchant for the latter.

Cheers,

A.

Sounds right.

In the module, though, we would need to have the option of forcing each line to have the same taxation scheme. This is important where taxes are added to the subtotal.

However, this raises the question of how to deal with invoices which already contain multiple taxation rates per line. If you create one of those invoices, then check the box that states, for example "single tax rate per invoice, rounded at end", what happens when you try to view an invoice which has already been created with multiple taxation rates?

Food for thought...

Albert.

Actually, we can't do the sum of tax1 and then the sum of tax2, because the requirement in many jurisdictions is that the total without tax be the basis for applying tax 1, then tax 2 is applied to the rounded sum of tax 1 and the subtotal, then tax 2 is rounded -- and finally the total is calculated... Therefore, tax2 can't be calculated per line.

I think there really should be an option to calculate taxes at the very end of the process and not per-line.

I'm sure there is an elegant solution to this :)

The patch in comment #3 doesn't work with storm 6.x-1.33. I've created an updated version of the patch, with no new functionality, that works with 6.x-1.33.

Albert.

Related: #2365799: Total should be sum of price + rounded tax not rounded sum of price + tax

I have no objection.