[Skip to main content](#vessel-content) # Profile for laurent ## [![laurent's Avatar](https://www.hikashop.com/media/kunena/core/svg/person.svg)](/forum/user/268-laurent "View laurent's Profile") **[ Offline](/forum/user/268-laurent)** - **User Type:** User - **Register Date:** 09 Nov 2010 - **Last login:** 1 week 3 days ago - **Time Zone:** UTC +0:00 - **Local Time:** 08:03 - **Posts:** 262 - **Profile views:** 1812 - **Thank you received:** 9 - **Location:** [Paris](https://maps.google.com?q=Paris) - **Gender:** Unknown - **Birthdate:** Unknown [](skype:lcollong "SKYPE") - Posts # laurent's recent posts (262 messages ) All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year | [ ](#forumbottom) | Subject | Replies / Views | Last Post | [ ](#forumtop) | |---|---|---|---|---| | [](/forum/30-integrations/910804-pdf-invoice-plugin-4-1-3---logo-not-rendered-with-the-default-invoice-layout#373311) | [PDF invoice plugin 4.1.3 — logo not rendered with the default invoice layout](/forum/30-integrations/910804-pdf-invoice-plugin-4-1-3---logo-not-rendered-with-the-default-invoice-layout#373311 "Hello, The store logo renders correctly with flat_invoice and corporate_invoice, but shows as a pink placeholder box with the default invoice layout. Environment: HikaShop Business 6.5.2, PDF invoice plugin 4.1.3, Joomla 5.4.8, PHP 8.2. The cause is the quoting of the src attribute. In invoice.php: php img src="<?php echo $image_address_path; ?>" style=""> flat_invoice.php and corporate_invoice.php use single quotes instead: php img src='<?php echo $image_address_path; ?>' style=''> _preprocessImages() correctly replaces the URL with the local temp file path, but something afterwards — hikashop_absoluteURL() or the rendering — only handles the single-quoted form. With double quotes, the final HTML sent to html2pdf contains: html The site domain prepended to an absolute filesystem path. With single quotes, the same code produces the correct src='/home/lact/htdocs/lact.fr/tmp/hk_inv_img_lWUWzU.png' and the logo appears. Switching to single quotes in our layout override fixed it. It looks like invoice.php just needs the same quoting as the other layouts. Two side notes while testing: The security hardening in spipu/html2pdf rejects any remote path because the allowed hosts list is never populated — we had to add $html2pdf->getSecurityService()->addAllowedHost(...) after the Html2Pdf instantiation to get past Unauthorized path host. _preprocessImages() leaves the zero-byte stub created by tempnam() behind, since the shutdown function unlinks $tmp . '.png' rather than $tmp. Minor, but they accumulate.") Category: [Integrations](/forum/30-integrations "Informations on all the different integrations available for Hikashop") Topic started 1 month 3 weeks ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/30-integrations/910804-pdf-invoice-plugin-4-1-3---logo-not-rendered-with-the-default-invoice-layout#373315 "Hello, Thank you for the report, and for the precise diagnosis. Your analysis was right, and it led us straight to the cause. The quoting is the symptom rather than the cause. What actually happens is that _getPDFInvoice() calls hikashop_absoluteURL() a second time, on the content assembled after each invoice has already been through it and through _preprocessImages(). By that point the src holds the local temp file that _preprocessImages() wrote, and the second pass puts the site address in front of it. hikashop_absoluteURL() only rewrites double-quoted attributes, which is exactly why invoice.php was the only layout affected and why your single-quote override worked around it. We removed that second call rather than changing the quoting, so all four layouts print the logo without an override. Your two side notes were both real, and are fixed as well: The allowed hosts list of html2pdf is now filled with the addresses of the shop, so an image read from an address no longer stops the invoice with "Unauthorized path host". This one came in with html2pdf 5.3.3, which the plugin picked up in 4.0.9. On top of that, the plugin now also strips the folder Joomla is installed in when it maps an image address onto a file on the server, so the logo is found locally in more cases and the question does not come up at all. tempnam() creates the file under the name it returns, so appending '.png' meant the stub was never the file being deleted. Both names are removed now, in _preprocessImages() and for the Factur-X XML. We've published version 4.1.4 of the plugin with the fixes. We tested it here on the four bundled layouts, with a logo read from a file and with a logo read from an address, and the logo is in the PDF in all of them.") 1 month 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:1 Views:272 | [Last Post](/forum/30-integrations/910804-pdf-invoice-plugin-4-1-3---logo-not-rendered-with-the-default-invoice-layout#373315 "Hello, Thank you for the report, and for the precise diagnosis. Your analysis was right, and it led us straight to the cause. The quoting is the symptom rather than the cause. What actually happens is that _getPDFInvoice() calls hikashop_absoluteURL() a second time, on the content assembled after each invoice has already been through it and through _preprocessImages(). By that point the src holds the local temp file that _preprocessImages() wrote, and the second pass puts the site address in front of it. hikashop_absoluteURL() only rewrites double-quoted attributes, which is exactly why invoice.php was the only layout affected and why your single-quote override worked around it. We removed that second call rather than changing the quoting, so all four layouts print the logo without an override. Your two side notes were both real, and are fixed as well: The allowed hosts list of html2pdf is now filled with the addresses of the shop, so an image read from an address no longer stops the invoice with "Unauthorized path host". This one came in with html2pdf 5.3.3, which the plugin picked up in 4.0.9. On top of that, the plugin now also strips the folder Joomla is installed in when it maps an image address onto a file on the server, so the logo is found locally in more cases and the question does not come up at all. tempnam() creates the file under the name it returns, so appending '.png' meant the stub was never the file being deleted. Both names are removed now, in _preprocessImages() and for the Factur-X XML. We've published version 4.1.4 of the plugin with the fixes. We tested it here on the four bundled layouts, with a logo read from a file and with a logo read from an address, and the logo is in the PDF in all of them.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 1 month 3 weeks ago | | [](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247) | [Pas de facture pdf générée (invoice pdf plugin) si total à payer à zéro ?](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonjour, Nous facturons des formations. Dans certains cas elles sont prises en charge par le CPF. Nous voudrions que le processus d'achat et de commande confirmée soit conservé via un coupon qui ramène le total à payer à zéro pour ces cas-là. Il faudrait qu'il n'y ait pas de facture émises (pdf et n° de facture "consommé") dans ce cas-là (total à payer strictement égal à zéro). Cela doit être possible via la création de statuts mais nous avons beaucoup de process qui dépendent du passage de la commande en statut "confirmed". Il faudrait donc que ces commandes à "zéro" soient "confirmées" mais sans avoir de pdf généré, de n° de facture consommé ou de pièce jointe au mail de commande. Merci pour votre retour. Cordialement, Laurent") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 5 months 2 days ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") 4 months 2 weeks ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:5 Views:324 | [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 4 months 2 weeks ago | | [](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372237) | [Pas de facture pdf générée (invoice pdf plugin) si total à payer à zéro ?](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372237 "Bonjour, Nous facturons des formations. Dans certains cas elles sont prises en charge par le CPF. Nous voudrions que le processus d'achat et de commande confirmée soit conservé via un coupon qui ramène le total à payer à zéro pour ces cas-là. Il faudrait qu'il n'y ait pas de facture émises (pdf et n° de facture "consommé") dans ce cas-là (total à payer strictement égal à zéro). Cela doit être possible via la création de statuts mais nous avons beaucoup de process qui dépendent du passage de la commande en statut "confirmed". Il faudrait donc que ces commandes à "zéro" soient "confirmées" mais sans avoir de pdf généré, de n° de facture consommé ou de pièce jointe au mail de commande. Merci pour votre retour. Cordialement, Laurent") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 5 months 2 days ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") 4 months 2 weeks ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:5 Views:324 | [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 4 months 2 weeks ago | | [](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372147) | [Pas de facture pdf générée (invoice pdf plugin) si total à payer à zéro ?](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372147 "Bonjour, Nous facturons des formations. Dans certains cas elles sont prises en charge par le CPF. Nous voudrions que le processus d'achat et de commande confirmée soit conservé via un coupon qui ramène le total à payer à zéro pour ces cas-là. Il faudrait qu'il n'y ait pas de facture émises (pdf et n° de facture "consommé") dans ce cas-là (total à payer strictement égal à zéro). Cela doit être possible via la création de statuts mais nous avons beaucoup de process qui dépendent du passage de la commande en statut "confirmed". Il faudrait donc que ces commandes à "zéro" soient "confirmées" mais sans avoir de pdf généré, de n° de facture consommé ou de pièce jointe au mail de commande. Merci pour votre retour. Cordialement, Laurent") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 5 months 2 days ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") 4 months 2 weeks ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:5 Views:324 | [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 4 months 2 weeks ago | | [](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372130) | [Pas de facture pdf générée (invoice pdf plugin) si total à payer à zéro ?](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372130 "Bonjour, Nous facturons des formations. Dans certains cas elles sont prises en charge par le CPF. Nous voudrions que le processus d'achat et de commande confirmée soit conservé via un coupon qui ramène le total à payer à zéro pour ces cas-là. Il faudrait qu'il n'y ait pas de facture émises (pdf et n° de facture "consommé") dans ce cas-là (total à payer strictement égal à zéro). Cela doit être possible via la création de statuts mais nous avons beaucoup de process qui dépendent du passage de la commande en statut "confirmed". Il faudrait donc que ces commandes à "zéro" soient "confirmées" mais sans avoir de pdf généré, de n° de facture consommé ou de pièce jointe au mail de commande. Merci pour votre retour. Cordialement, Laurent") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 5 months 2 days ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") 4 months 2 weeks ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:5 Views:324 | [Last Post](/forum/5-support-en-francais-french-support-/910566-pas-de-facture-pdf-generee-invoice-pdf-plugin-si-total-a-payer-a-zero#372247 "Bonsoir, Le comportement est plus adapté. Cela ne permet plus de générer une "fausse" facture pdf. Cela affiche un poup avec la commande en html insérée au sein d'une page du site. Ce n'est pas "top" mais c'est beaucoup plus adapté. A priori, on clôture ce post. Mais idéalement, il serait bien de pouvoir "imprimer" un document propre depuis l'espace "mes commandes" dans le front. Soit Html, soit pdf avec un libellé comme l'actuel ("Commande n° xxx"). Soit avec quelque chose de plus formel ("récipissé de commande") puisque la commande est soldée/confirmée. Merci. Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 4 months 2 weeks ago | | [](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370930) | [Let main product description always visible](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370930 "Hi, When using variants, the variant's description is displayed and the main product description is hidden as soon as you select a variant, as long as the variant's description exists. This is the expected behavior. However, we would like the main product description to always be displayed (above or below) the selected variant description. In our case, the main description does not change much from one variant to another, so it would be simpler not to have to copy, paste and maintain the same description for each variant. Apparently the main description is always present in the DOM (display:none) and is changed via JavaScript upon the variant selection event. Is there a simple way to always keep the main description visible? Thanks. Laurent") Category: [Product & Category Display](/forum/26-product-category-display "Questions about product and category display. You can't find how to make Hikashop looks incredible? The answer is here!") Topic started 7 months 3 weeks ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370930 "Hello, Sorry for the delay. It works very well. Thank you. For now, I let it "as is" but I'll go further for the case where variant has no description. If we need it. Regards, Laurent") 7 months 1 week ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:2 Views:309 | [Last Post](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370930 "Hello, Sorry for the delay. It works very well. Thank you. For now, I let it "as is" but I'll go further for the case where variant has no description. If we need it. Regards, Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 7 months 1 week ago | | [](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370773) | [Let main product description always visible](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370773 "Hi, When using variants, the variant's description is displayed and the main product description is hidden as soon as you select a variant, as long as the variant's description exists. This is the expected behavior. However, we would like the main product description to always be displayed (above or below) the selected variant description. In our case, the main description does not change much from one variant to another, so it would be simpler not to have to copy, paste and maintain the same description for each variant. Apparently the main description is always present in the DOM (display:none) and is changed via JavaScript upon the variant selection event. Is there a simple way to always keep the main description visible? Thanks. Laurent") Category: [Product & Category Display](/forum/26-product-category-display "Questions about product and category display. You can't find how to make Hikashop looks incredible? The answer is here!") Topic started 7 months 3 weeks ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370930 "Hello, Sorry for the delay. It works very well. Thank you. For now, I let it "as is" but I'll go further for the case where variant has no description. If we need it. Regards, Laurent") 7 months 1 week ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:2 Views:309 | [Last Post](/forum/26-product-category-display/910176-let-main-product-description-always-visible#370930 "Hello, Sorry for the delay. It works very well. Thank you. For now, I let it "as is" but I'll go further for the case where variant has no description. If we need it. Regards, Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 7 months 1 week ago | | [](/forum/26-product-category-display/893427-how-to-link-directly-to-a-variante-of-the-product#370767) | [How to link directly to a variante of the product](/forum/26-product-category-display/893427-how-to-link-directly-to-a-variante-of-the-product#370767 "Hi, I'm wondering if it is possible to call a variante with an URL, rather than the general product itself ? If that's possible, how to do it -i.e find the URL to the variante- ? Thanks, Garl") Category: [Product & Category Display](/forum/26-product-category-display "Questions about product and category display. You can't find how to make Hikashop looks incredible? The answer is here!") Topic started 8 years 9 months ago, by [flyingplanet](/forum/user/32015-flyingplanet "View flyingplanet's Profile") [Last Post](/forum/26-product-category-display/893427-how-to-link-directly-to-a-variante-of-the-product#370768 "Hi, Not with the "Characteristics dynamic display" setting activated at the moment. However, that's something we're looking into for the next release of HikaShop. Thanks for your feedback.") 7 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:14 Views:1902 | [Last Post](/forum/26-product-category-display/893427-how-to-link-directly-to-a-variante-of-the-product#370768 "Hi, Not with the "Characteristics dynamic display" setting activated at the moment. However, that's something we're looking into for the next release of HikaShop. Thanks for your feedback.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 7 months 3 weeks ago | | [](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369754) | [Rendre les factures non modifiables](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369754 "Bonjour, Normalement, une fois qu'une facture a été émise elle ne devrait plus pouvoir être modifiée. Nous utilisons le plugin "attachinvoice" pour générer et envoyer une facture PDF à nos clients. Or depuis le back-office, il est tout à fait possible de modifier une commande, même confirmée. Sauf erreur, pour régénerer le pdf, il faut la repasser en "créée" puis de nouveau en "confirmée" (c'est le changement d'état qui déclenche la création de la facture). Toutes ces manipulations entraînent des distorsions possibles entre les factures pdf originelles envoyées en compta et celle (ou celles) envoyées aux clients suite à des "manips". Dans notre cas, ces manips sont parfois rendues nécessaires si le client se trompe de produit. D'un autre côté, il est souhaitable de pouvoir continuer à modifier des commandes qui ne sont pas encore confirmées. Quelles sont vos préconisations en la matière ? Comment permettre à un administrateur de pouvoir modifier une commande sauf si elle est en statut "confirmée" ? Est-il possible de générer un avoir quand on annule une commande ? L'opérateur devrait pouvoir modifier une commande si pas encore confirmée (créée sans doute) mais aussi pouvoir annuler une commande confirmée. La question se pose aussi encore plus crument dans la perspective de la facture électronique à venir. Merci pour votre retour. Cordialement, Laurent") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 11 months 1 week ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369754 "Bonsoir, Merci pour le retour. On surveillera les nouveauté d'Hikashop ! :-) En attendant, je vais essayer d'implémenter l'override pour "cacher" les possibilités d'édition. Les personnes qui ont accès au backend ne sont, en principe, pas mal-intentionnées. Cela ne présente donc pas un gros risque pour nous. Laurent") 10 months 2 weeks ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:6 Views:432 | [Last Post](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369754 "Bonsoir, Merci pour le retour. On surveillera les nouveauté d'Hikashop ! :-) En attendant, je vais essayer d'implémenter l'override pour "cacher" les possibilités d'édition. Les personnes qui ont accès au backend ne sont, en principe, pas mal-intentionnées. Cela ne présente donc pas un gros risque pour nous. Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 10 months 2 weeks ago | | [](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369747) | [Rendre les factures non modifiables](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369747 "Bonjour, Normalement, une fois qu'une facture a été émise elle ne devrait plus pouvoir être modifiée. Nous utilisons le plugin "attachinvoice" pour générer et envoyer une facture PDF à nos clients. Or depuis le back-office, il est tout à fait possible de modifier une commande, même confirmée. Sauf erreur, pour régénerer le pdf, il faut la repasser en "créée" puis de nouveau en "confirmée" (c'est le changement d'état qui déclenche la création de la facture). Toutes ces manipulations entraînent des distorsions possibles entre les factures pdf originelles envoyées en compta et celle (ou celles) envoyées aux clients suite à des "manips". Dans notre cas, ces manips sont parfois rendues nécessaires si le client se trompe de produit. D'un autre côté, il est souhaitable de pouvoir continuer à modifier des commandes qui ne sont pas encore confirmées. Quelles sont vos préconisations en la matière ? Comment permettre à un administrateur de pouvoir modifier une commande sauf si elle est en statut "confirmée" ? Est-il possible de générer un avoir quand on annule une commande ? L'opérateur devrait pouvoir modifier une commande si pas encore confirmée (créée sans doute) mais aussi pouvoir annuler une commande confirmée. La question se pose aussi encore plus crument dans la perspective de la facture électronique à venir. Merci pour votre retour. Cordialement, Laurent") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 11 months 1 week ago, by [laurent](/forum/user/268-laurent "View laurent's Profile") [Last Post](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369754 "Bonsoir, Merci pour le retour. On surveillera les nouveauté d'Hikashop ! :-) En attendant, je vais essayer d'implémenter l'override pour "cacher" les possibilités d'édition. Les personnes qui ont accès au backend ne sont, en principe, pas mal-intentionnées. Cela ne présente donc pas un gros risque pour nous. Laurent") 10 months 2 weeks ago by [laurent](/forum/user/268-laurent "View laurent's Profile") | Replies:6 Views:432 | [Last Post](/forum/5-support-en-francais-french-support-/909930-rendre-les-factures-non-modifiables#369754 "Bonsoir, Merci pour le retour. On surveillera les nouveauté d'Hikashop ! :-) En attendant, je vais essayer d'implémenter l'override pour "cacher" les possibilités d'édition. Les personnes qui ont accès au backend ne sont, en principe, pas mal-intentionnées. Cela ne présente donc pas un gros risque pour nous. Laurent") by [laurent](/forum/user/268-laurent "View laurent's Profile") 10 months 2 weeks ago | [](/forum/topics/feed/mode-topics?format=feed&type=rss) Time to create page: 0.092 seconds [Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)