Factures ne se génèrent plus depuis 06/12 [RÉSOLU]

[Olivier75009]

Je viens de checker d'anciennes commandes, et en effet la plupart n'ont pas de nom. Du coup je ne vois pas en quoi les modifs que j'ai faites ont pu affecter la génération des factures.

Édith : il se trouve que j'ai aussi modifié le comportement d'un changement de statut, à savoir l'envoi d'un mail avec la facture. Est-ce ça qui peut déclencher la génération de facture
?

[eolia]

Ah bah oui, la facture est générée et envoyée en pièce-jointe pour chaque email dont l'option "facture" est cochée.

[Olivier75009]

Oui mais si on ne souhaite pas envoyé la facture dans l'email, celle-ci n'est donc pas générée ? (Donc est-ce à nous de configurer la génération d'une facture, n'est-ce pas fait automatiquement lors d'un changement de statut particulier - renvoi par le mode de paiement (accepté) /paypal/payplug...)

[eolia]

Ben non.
Le code est purement logique hein.
Facture cochée => on génère et on envoie la facture en pièce jointe
Facture pas cochée => on ne génère rien.

[Olivier75009]

Bon ben il persiste un problème alors, un des changement de statut opéré par le retour du module de notre logisticien (préparation en cours) indique un des employés à côté. J'ai contacté l'employé en question qui n'a pourtant touché à rien.

[eolia]

Ah ben ça c'est connu, c'est votre module qui est écrit avec les pieds^^
Il prend le dernier employé trouvé dans la table ps_employee.
J'avais corrigé le module SoColissimo à l'époque en lui créant un employé spécifique et en mettant son id dans le module.

[Olivier75009]

Ok, du coup je vais joindre leur dev'. (Plusieurs mises à jour de leur module dernièrement, même si auparavant on n'avait pas d'employé qui figurait à côté).

[Olivier75009]

En effet, le dev a intégré le paramètre ID employee dans la conf de son module. Il a fallut créer un nouvel employé du coup. J'attends la fin de journée pour voir la génération des factures et je marque résolu.

[Olivier75009]

Bonjour Pierre,
Je reviens vers toi car j'ai à nouveau ce même soucis lorsque je souhaite générer un pdf depuis une tâche cron (cellspacingx undefined variable... à la ligne 18272 et 18420). Je ne suis pourtant pas en mode debug (mais je logue la tâche pour savoir de quoi il en retourne). Le pdf n'est pas généré. Si j'appelle la page depuis mon navigateur, je n'ai qu'une page html avec un tableau (html/body/table/th/td). Si je génère une facture depuis une commande, le pdf se génère bien. J'ai un override sur pdfgenerator :

<?php
class PDFGenerator extends PDFGeneratorCore
{
	
    /*
    * module: alinkmodpantones
    * date: 2023-05-25 09:02:05
    * version: 1.0
    */
    public function writePage()
    {
        
        $this->SetHeaderMargin(10);
        $this->SetFooterMargin(21);
        $this->setMargins(10, 40, 10);
        $this->AddPage();
        $this->writeHTML($this->content, true, false, true, false, '');
    }
    /*
    * module: alinkmodpantones
    * date: 2023-05-25 09:02:05
    * version: 1.0
    */
    public function Header()
    {
        $this->writeHTML($this->header);
        $this->SetLineStyle( array( 'width' => 2, 'color' => array(246, 216, 190)));
		$this->Line(5, 5, $this->getPageWidth()-5, 5); 
		$this->Line($this->getPageWidth()-5, 5, $this->getPageWidth()-5,  $this->getPageHeight()-5);
		$this->Line(5, $this->getPageHeight()-5, $this->getPageWidth()-5, $this->getPageHeight()-5);
		$this->Line(5, 5, 5, $this->getPageHeight()-5);
    }
    /*
    * module: alinkmodpantones
    * date: 2023-05-25 09:02:05
    * version: 1.0
    */
    public function createContent($content)
    {
        $font = TCPDF_FONTS::addTTFfont(_PS_MODULE_DIR_.'alinkmodpantones/views/fonts/Arial.ttf', 'TrueTypeUnicode', '', 32);
        $this->FontFamily = 'Arial';
        $this->content = $content;
    }
    /*
    * module: alinkmodpantones
    * date: 2023-05-25 09:02:05
    * version: 1.0
    */
    public function Footer()
    {
        $this->writeHTML($this->footer);
        $this->FontFamily = self::DEFAULT_FONT;
    }
}

Celui-ci fonctionnait bien jusqu'à présent.

[eolia]

Curieux, la classe PDF n'a pas été modifiée récemment.
Peux-tu retester stp ?

[Olivier75009]

Je relance un cron, il lui faudra bien 3 minutes.

[Olivier75009]

J'ai ça dans cron_error.log :

--2024-10-22 09:59:01--  https://www.monsite.com/pdfnuancier
Resolving www.monsite.com (www.monsite.com)... IPV6, IPV4
Connecting to www.monsite.com (www.monsite.com)|IPV6|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/var/www/clients/client3/web3/web/ftp/nuancier_pdf.pdf’

     0K .......... .......... .......... .......... .......... 90.4M
    50K .......... .......... .......... .......... ..........  148M
   100K .......... .......... .......... .......... ..........  118M
   150K .......... .......... .......... .......... ..........  111M
   200K .......... .......... .......... .......... ..........  111M
   250K .......... .......... .......... .......... .........   130M=0.003s

2024-10-22 10:00:04 (115 MB/s) - ‘/var/www/clients/client3/web3/web/ftp/nuancier_pdf.pdf’ saved [306447]

J'ai un fichier généré, mais c'est du html

[eolia]

Peux-tu retester stp (et si tu es dispo sur Skype ce serait pas mal)

[Olivier75009]

Fait merci ! Tutto bene !
Pour ceux qui seraient intéressés, il sagit d'une mauvaise implémentation dans le code du module, en appelant une méthode de la mauvaise manière : new PDF->render(filename, output) alors qu'il aurait fallu render(true).