Factures ne se génèrent plus depuis 06/12 [RÉSOLU]
-
Ajoute cette ligne (18165):
-
Alors incompréhensible, hier soir les factures se génèrent à nouveau. MAIS (y'a un 'mais'), dans la journée je suis allé dans le BO vérifier les différentes permissions des employés (j'ai créé le week-end dernier des profils pour chacun des employés, ça n'avait jusqu'à présent pas été fait) et ajouter des droits (voir, modifier) sur les modules commandes & CA, alertes par email, paypal, payplug pour l'employé qui envoie les mails (en fait, ce n'est pas l'employé mais son mail qui est dans la conf smtp du BO). Donc ce matin je vois que les factures se génèrent (je verrais pour les dernières factures ce matin si ça suit le mouvement). Chose étrange, auparavant lors des changements de statut, il était indiqué le nom du superadmin à côté. Maintenant, c'est celui du dernier employé créé (== dernier profil aussi).
-
Non, concernant les changements de statuts, il y a un nom qui apparait QUE si c'est un employé qui a changé ce statut. Si c'est un changement automatique effectué par le code il n'y a pas de nom.
Et ce n'est pas le le dernier employé mais celui du contexte en cours. -
Dans OrderHistory:
-
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
? -
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.
-
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...)
-
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. -
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.
-
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. -
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é).
-
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.
-
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.
-
Curieux, la classe PDF n'a pas été modifiée récemment.
Peux-tu retester stp ? -
Je relance un cron, il lui faudra bien 3 minutes.
-
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
-
Peux-tu retester stp (et si tu es dispo sur Skype ce serait pas mal)
-
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).
