Hart

i campi per la fatturazione elettronica devo essere legati all'indirizzo (dove è èresente anche ragione sociale e partita iva) non all'account! Potrei avere indirizzi di fatturazione di aziende differenti e quindi avere differenti riferimenti per la fattura elettronica, se invece è tutto legato in un solo punto all'account non funziona nulla.

there is something i don't understand here on this code (override) in your module class TaxRulesTaxManager extends TaxRulesTaxManagerCore { /** * Return the tax calculator associated to this address. * * @return TaxCalculator */ public function getTaxCalculator() { static $tax_enabled = null; if ( isset( $this->tax_calculator ) ) { return $this->tax_calculator; } if ( null === $tax_enabled ) { $tax_enabled = Configuration::get( 'PS_TAX' ); } if ( $tax_enabled && $this->address ) { /** @var Vatchecker $vatchecker */ $vatchecker = Module::getInstanceByName('vatchecker'); if ( $vatchecker && $vatchecker->canOrderWithoutVat( $this->address ) ) { // Disable TAX. $tax_enabled = false; } } if ( ! $tax_enabled ) { return new TaxCalculator( array() ); } return parent::getTaxCalculator(); } } in BO config of the module you can select countries from EU where you can order without VAT (based on the note here) Looking inside the code if i disable a country TAXATION is not applied? Was mopre logical instead that if i dsable Spain flag in config i can order from there only if the customer as a VALID VAT number, because the UX and the message seems to indicate that i will forcing only VAT purcasing not liek i see in the code that is added or not the tax. There is something i still misunderstanding here? Thanks!

I've found 2 bugs, please take a look to the github ticket i opened: https://github.com/NKoonen/vatchecker/issues/27

if you use a child theme the translations related to the parent theme not appearing at all.

if you use child theme you will have problems on translations, i s a know bug that is not resolved yet. Using a child theme is like overriding the default one so if you not copy a css to the child theme it will use the parent css. This is working also with .tpl files, is the normal behaviour.

works also with 1.7.8.8 version? thanks

private $euVatFormats = array( 'AT' => '(AT)?U[0-9]{8}', # Austria 'BE' => '(BE)?0[0-9]{9}', # Belgium 'BG' => '(BG)?[0-9]{9,10}', # Bulgaria 'CY' => '(CY)?[0-9]{8}[A-Z]', # Cyprus 'CZ' => '(CZ)?[0-9]{8,10}', # Czech Republic 'DE' => '(DE)?[0-9]{9}', # Germany 'DK' => '(DK)?[0-9]{8}', # Denmark 'EE' => '(EE)?[0-9]{9}', # Estonia 'GR' => '(EL)?[0-9]{9}', # Greece 'ES' => '(ES)?[A-Z][0-9]{7}(?:[0-9]|[A-Z])', # Spain 'FI' => '(FI)?[0-9]{8}', # Finland 'FR' => '(FR)?[0-9A-Z]{2}[0-9]{9}', # France //'GB' => '(GB)?([0-9]{9}([0-9]{3})?|[A-Z]{2}[0-9]{3})', # United Kingdom // Brexit! 'HR' => '(HR)?[0-9]{11}', # Croatia 'HU' => '(HU)?[0-9]{8}', # Hungary 'IE' => '(IE)?[0-9]{7}[A-Z]{1,2}', # Ireland 'IE2' => '(IE)?[0-9][A-Z][0-9]{5}[A-Z]', # Ireland (2) 'IT' => '(IT)?[0-9]{11}', # Italy 'LT' => '(LT)?([0-9]{9}|[0-9]{12})', # Lithuania 'LU' => '(LU)?[0-9]{8}', # Luxembourg 'LV' => '(LV)?[0-9]{11}', # Latvia 'MT' => '(MT)?[0-9]{8}', # Malta 'NL' => '(NL)?[0-9]{9}B[0-9]{2}', # Netherlands 'PL' => '(PL)?[0-9]{10}', # Poland 'PT' => '(PT)?[0-9]{9}', # Portugal 'RO' => '(RO)?[0-9]{2,10}', # Romania 'SE' => '(SE)?[0-9]{12}', # Sweden 'SI' => '(SI)?[0-9]{8}', # Slovenia 'SK' => '(SK)?[0-9]{10}', # Slovakia ); in this list missing XI that is North Ireland and IE2 what is it? https://ec.europa.eu/taxation_customs/vies/#/vat-validation XI has same VAT syntax of GB VAT: (XI)?([0-9]{9}([0-9]{3})?|[A-Z]{2}[0-9]{3}) please avoid the VIES check if the VAT code is in the same country of the Shop.

yes there is no fix yet.. that is scandalous!

Northern Ireland VAT code is XI according to VIES check: https://ec.europa.eu/taxation_customs/vies/?locale=en GB must be removed from VIES check because UK is not in Europe anymore and VIES will fail if activated for GB vats

is there a solution for 1.7.6.x?

PS v1.7.6.7 the problem of price calculation (rounding) persist and give trouble when passed to paypal for payment because in return the payment receive an error. for example here is very evident that the total order is wrong:

è presente anche su 1.7.6.7 ed è piuttosto problematico visto che poi passa dei valori al gateway di pagamento come paypal sballati ricevendo indietro un errore di pagamento

seems not working in 1.7.6.7