Bonjour,
Voici la réponse de notre ingénieur.
As requested, here are some details on the client type bug in Hikashop.
The problem lies in the convoluted relationships between a seemly unconnected global configuration parameter "Default address type" and the php function getTaxType() in currency.php, which determines whether the order belongs to an individual, a non-VAT registered company, or a VAT registered company :
function getTaxType(){
static $taxType = '';
if(empty($taxType)){
$config =& hikashop_config();
$type = $config->get('default_type','individual');
$app =& JFactory::getApplication();
$shipping_address=$app->getUserState( HIKASHOP_COMPONENT.'.'.$config->get('tax_zone_type','shipping').'_address',0);
if(!empty($shipping_address)){
$addressClass = hikashop_get('class.address');
$address = $addressClass->get($shipping_address);
if(!empty($address->address_company)){
$type = 'company_without_vat_number';
}
if(!empty($address->address_vat)){
$vat = hikashop_get('helper.vat');
if($vat->isValid($address)) $type = 'company_with_vat_number';
}
}
$taxType=$type;
}
return $taxType;
}
In the function, the line:
$type = $config->get('default_type','individual');
looks up the "Default address type"parameter. If this parameter is not set to "individual", the function's client type logic does not work correctly.
The global Hikashop parameter "Default address type" does not seem to achieve anything useful apart from breaking the above function.