Add support for other modules to enter prices inclusive of VAT

Thanks for the patch. However, I'm currently reluctant to commit any support like this, as if I'm not careful we will have a huge number of form alter functions that all look very similar. I think instead uc_vat needs to provide either some kind of hook or FormAPI extension that makes it simpler for modules to say "this is a price that could be VAT altered" and somehow save copy and pasting an alter function and submit handler for each one. Ideally I'd like other modules to be able to support this simply by adding a line or two to their own form functions.

I will be testing some out some code to do this as soon as I can, but any ideas on how to approach this sort of thing are welcome!

Thanks for your input on this! I was thinking along the same lines for a FAPI extension, basically. Perhaps the form should also set $form['#uc_vat_process'] = TRUE to so uc_vat can quickly check for alterations without having to iterate through all elements on all forms. For some prices we also need to know the node type and shippable flag so we can calculate the taxes correctly, this would also have to be stored in the FAPI array somewhere - for forms that cover multiple nodes we cannot rely on just $form['#node'] for this.

I don't like the uc_vat_price() idea as this moves more specific VAT support into each module, which I was trying to avoid, and as you say we still need to handle altering the prices again on form submission. It would be better if modules can implement this themselves, or if their maintainer has no interest in VAT support, a small glue module can be written that provides uc_vat support on behalf of the other module.

My other idea was to implement a hook where modules declare the forms they use that can be altered, but this seems to be unnecessary if we can use FAPI to achieve the same thing in a simpler way.

For non-form inputs, there's so many ways a price can be output that I don't think we can cover them all. However, these prices should be generated by uc_price(), so perhaps we can add an extra flag to the context that lets uc_vat's price alterer decide whether or not to alter prices in more specific cases? A 'location' was provided in context earlier in uc_price's development, but unfortunately this was dropped as we could not see any use cases for it at the time! But again this means the calling module has to declare this, and other modules cannot override this easily; maybe a hook would work for this, that declares URLs/path where the price alterer should/should not be run depending on the price editing configuration options? This would likely also need extra checks on $context to ensure we do not inadvertantly override modifying cart prices on pages where these altered prices are displayed...

I don't know if this can help but I've been working on this kind of issue to make modules like uc_coupon, uc_discount_alt and uc_gift_certificate handle vat.
So here is what I've done :
Added a function called get_uc_price in uc_vat.module which looks like :

/**
+ * Returns the price for a product including Tax,
+ *
+ * @param object $item
+ */
function uc_vat_get_uc_price($item,$qty=0) {
	if ($qty==0) $qty=$item->qty;
  $price_info = array(
    'price' => $item->price,
    'qty' => $qty,
  );
  $context = array(
    'type' => 'product',
    'revision' => 'altered',
    'subject' => array(
      'product' => $item,
      'node' => node_load($item->nid),
    ),
  );
  return uc_price($price_info, $context);
}

This function should be called by the modules whenever they want a price to be displayed or calculated inclusive of VAT.
So, for instance, in the uc_gift_certificate, the amount of a gift certificate you purchase is exclusive of VAT but the amount you pay is inclusive of VAT. So to fix this issue, using the above function, a patch would looks like :

         $new_gc = new stdClass();
         $new_gc->name = $title;
-        $new_gc->value = $product->qty * $product->price;
+		$new_gc->value = $product->qty * $product->price;
+		foreach (module_implements('get_uc_price') as $module) {
+			$fonction=$module."_get_uc_price";
+			$new_gc->value = $fonction($product);
+		}
         $new_gc->purchaser_id = $order->uid;
         $new_gc->order_id = $order->order_id;

The way the code is written is specific to the module use and should insure the price is not added twice or some other mistake like this.

Does this look like the solution you were thinking about ?

@nicolasb_cdip: I'm not sure what you're trying to do with module_implements() there but it doesn't look like correct usage, if multiple modules implement your hook what do you expect to happen? It looks like only the last module to be called will have any effect. Also your hook_get_uc_price() function defeats the point of using uc_price() in the first place, it assumes that the price being altered is a product, when for the purposes of this particular issue, we cannot assume that - I intend to be able to alter shipping prices here, for example, which are not products or even nodes.

@fenstrat: I think that adding vat_note either to the top or bottom of forms affected by this code would be acceptable, maybe allowing it to be switched on and off via a site-wide configuration variable, and also through a further FAPI extension for specific forms where this technique does not work well?

Hi everybody, I had the same problem, but I could fix it,

You don't need put any patch
You must to change these line in case 'load' in the function uc_price_per_role_nodeapi in uc_price_per_role.module file

case 'load':
        $result = db_query("SELECT rid, price FROM {uc_price_per_role_prices} WHERE vid = %d", $node->vid);
        $prices = array();
        while ($row = db_fetch_object($result)) {
          $prices[$row->rid] = $row->price;
        }

        $original_price = $node->sell_price;
        $price = uc_price_per_role_find_price($prices);
        if ($price !== FALSE) {
			$taxes = uc_vat_load_taxes(); //THIS
			foreach (array_reverse($taxes) as $tax) { //& THIS
					$node->sell_price = $price/(1 + $tax->rate); //& THIS
			}//& THIS
        }

Just thought I'd thank you jansete. I just found this post and it fixed my problem!

Forget about #13: it does adjust the price on display only, applies all configured taxes regardless the product and is incompatble with the proposed patch.