In my web site in Drupal10.2.5 using commerce-invoice 8.x-2.0-rc3 and symfony_mailer 1.4.1 the pdf invoices were attached correctly to the emails.
Now I updated my web using Composer to Drupal 10.3.5, commerce-invoice 8.x-2.0-rc5 and symfony_mailer 1.5.0.
After this update, the pdf invoices are not attached to the e-mail anymore. I get the same error message as mentioned by #9:
RuntimeException: Failed to start the session because headers have already been sent by "/home/my-website/vendor/symfony/http-foundation/Response.php" at line 431. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /home/my-website/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
I have applied the commerce_invoice_no_invoice_duplicate_mail.patch indicated in #22 but now I get following error message:
Connection to "process /usr/sbin/sendmail -bs" has been closed unexpectedly.
Is there a problem with the patch as I applied it on version 8.x-2.0-rc5 and not on 8.x-2.0-rc1?
Or could the symfony_mailer 1.5.0 be the cause of the initial problem after update and should I downgrade back to 1.4.1?
Or can it have anything to do with the mailer configuration of my website (although it worked before and I didn't change anything?)
Any comments are welcome!
henkpotman → created an issue.
For another website where I need to accept VAT numbers from three different countries (Spain, Portugal and Andorra) I decided to completely cancel the taxnumber verification by modifying the EuropeanUnionVat.php in commerce/modeles/tax/scr/Plugin/Commerce/TaxNumberType.
Line 35:
public function validate($tax_number) {
$patterns = $this->getValidationPatterns();
$prefix = substr($tax_number, 0, 2);
if (!isset($patterns[$prefix])) {
return FALSE;
}
$number = substr($tax_number, 2);
if (!preg_match('/^' . $patterns[$prefix] . '$/', $number)) {
return FALSE;
}
return TRUE;
}
Modified into:
public function validate($tax_number) {
return TRUE;
}
The taxnumber verification is now always returning TRUE independently of the taxnumber format. This website is substituting a previous website that has been operative 15 years without taxnumber verification and I never had any problems.
I thinks it's very important to let customers enter their tax number in the format they prefer (without country code, also some will put space or dash between letters and numbers) without getting an error message that might lead to a missed sale. Any wrong taxnumber you can correct later in your accounting but in my experience this is occurring very rarely.
The modification I did in #4 is working fine, the site is online now since 3 months and there have been no issues.
I'm working on another site now where I will need to accept VAT numbers from three different countries. I will look into this matter again next month to see how to do this.
The patch #6 is working fine for regular order created in the store by customers.
However for admin created orders the patch does not seem to work. I don't know if there is a solution for this situation. I our store we get frequently phone calls from customers and admins have to create orders manually.
Finally I could achieve it using {{ invoice_entity.get('field_numero_de_factura').value }}
This is what worked:
{{ invoice_entity.get('field_numero_de_factura').value }}
I hope it will help someone.
Hi NYG, if possible, can you share your solution? I'm having a similar problem.
Thanks so much!
I now installed the Twig Field Value module which should be suitable for this.
However I tried things like {{ invoice_entity.field_numero_de_factura|field_value }} but no success.
Any suggestion or help is welcome!
henkpotman → created an issue.
henkpotman → created an issue.
I managed to modify the EuropeanUnionVat.php in commerce/modeles/tax/scr/Plugin/Commerce/TaxNumberType.
Line 35:
public function validate($tax_number) {
$patterns = $this->getValidationPatterns();
$prefix = substr($tax_number, 0, 2);
if (!isset($patterns[$prefix])) {
return FALSE;
}
$number = substr($tax_number, 2);
if (!preg_match('/^' . $patterns[$prefix] . '$/', $number)) {
return FALSE;
}
return TRUE;
}
Modified into:
public function validate($tax_number) {
$patterns = $this->getValidationPatterns();
$prefix = substr($tax_number, 0, 2);
$number = substr($tax_number, 0);
if (!preg_match('/^' . $patterns['ES'] . '$/', $number)) {
return FALSE;
}
return TRUE;
}
It's working fine when entering local Spanish tax numbers (without ES prefix) with VIES verification turned off. It just checks the length and structure.
This might be useful for stores selling in one country only.
After further testing I noticed that the verification actually is disabled when unchecking the checkbox. However even if disabled, for European tax number it still requires the country code ('ES' for Spain) before the taxnumber. Without the ES the tax number is rejected.
Is there a way that the ES prefix is not requested? Local people are not used to indicate the country code before the tax number. This is the same for all european countries.
Thanks very much for your extensive comments and information!
I found my mistake. I placed the custom templates in the commerce_order_document/templates folder. According to your indications it should be places in the theme templates folder. I did and now it's working fine!
I think your module is great, just what many people will need to make any type of document (packing slips, proforma invoice, invoice..).
You made my day! Again, thanks a lot for your time and help!
henkpotman → created an issue.
henkpotman → created an issue.
I encountered this same error after deleting all old orders that were imported from an imported Drupal 7 Ubercart store. After I deleted the old orders, when visiting the Order page I encountered this same error message.
In PhpMyadmin I found the old orders where still there in the commerce_order table. Next I emptied (truncated) the commerce_order table and this solved the problem. I can view the Order page again and all old orders were deleted.
henkpotman → created an issue.