PrestaShop fournit des documents de commande et un bouton d'impression navigateur. Ce qu'il ne fournit pas, c'est un ticket qui apparaît en réserve à la seconde où un client paie : cela suppose de relier le cycle de vie de la commande à une imprimante joignable par internet.
Réponse courte : accrochez actionOrderStatusPostUpdate, vérifiez que le nouveau statut signifie « payé », construisez le ticket et envoyez-le. Un module prêt à l'emploi le fait avec des réglages plutôt qu'avec du code ; un petit module maison le fait exactement à votre façon. Aucun des deux n'exige d'ordinateur allumé en boutique.
Deux voies
| Module | Hook personnalisé | |
|---|---|---|
| Mise en place | Installer et configurer | ~20 lignes de PHP |
| Contrôle de la mise en page | Réglages de gabarit | Total |
| Multiboutique | Pris en charge | À votre charge |
| Adapté à | La plupart des boutiques | Routage ou logique spécifique |
Le connecteur PrestaShop couvre la première voie ; la documentation du module détaille l'installation et les réglages du ticket.
La voie du hook
PrestaShop déclenche actionOrderStatusPostUpdate après que le statut d'une commande a changé et a été persisté. C'est le bon moment : le hook antérieur actionOrderStatusUpdate se déclenche avant la validation du changement.
public function hookActionOrderStatusPostUpdate($params)
{
/** @var OrderState $newStatus */
$newStatus = $params['newOrderStatus'];
$order = new Order((int) $params['id_order']);
// N'imprimer qu'une fois le paiement accepté ; `paid` couvre les états standards.
if (!$newStatus->paid) {
return;
}
$lignes = [
'COMMANDE ' . $order->reference,
date('d/m/Y H:i'),
'',
];
foreach ($order->getProducts() as $product) {
$lignes[] = (int) $product['product_quantity'] . 'x ' . $product['product_name'];
}
$lignes[] = '';
$lignes[] = 'TOTAL : ' . number_format($order->total_paid, 2) . ' ' . $this->context->currency->iso_code;
$ch = curl_init('https://www.expedy.fr/api/v2/printers/' . Configuration::get('MYMOD_PRINTER_UID') . '/print');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 5,
CURLOPT_HTTPHEADER => [
'Authorization: ' . Configuration::get('MYMOD_API_SID') . ':' . Configuration::get('MYMOD_API_TOKEN'),
'Content-Type: application/json',
],
CURLOPT_POSTFIELDS => json_encode([
'printer_msg' => implode("\n", $lignes),
'origin' => 'ps-' . $order->id,
]),
]);
curl_exec($ch);
curl_close($ch);
}
Les pièges propres à PrestaShop
Les changements de statut ne sont pas uniques. Un module de paiement peut poser deux fois le même statut payé, et un marchand peut le réappliquer manuellement depuis le back-office. Stockez un drapeau (une ligne de méta de commande ou une table dédiée), et sortez si la commande a déjà été imprimée. Sans cela, chaque ré-enregistrement produit un ticket de plus.
newOrderStatus->paid est le test fiable. Coder en dur des identifiants de statut casse le jour où quelqu'un ajoute un statut personnalisé ou où vous déployez sur une boutique configurée autrement. Le drapeau paid est ce que posent réellement les modules de paiement.
Le multiboutique demande une imprimante par boutique. Dans une installation multiboutique, lisez l'identifiant d'imprimante depuis le contexte de boutique plutôt que depuis une valeur de configuration globale, sinon toutes les boutiques impriment sur la même machine.
Les timeouts bloquent le client. Le hook s'exécute dans la requête qui confirme la commande. Un CURLOPT_TIMEOUT de cinq secondes est un plafond sur le temps d'attente possible du client si l'API est injoignable : gardez-le bas, et traitez les échecs de livraison de façon asynchrone plutôt que de faire dépendre la commande d'une imprimante.
Les noms de produits contiennent n'importe quoi. Les caractères accentués passent ; les émojis et symboles inhabituels non. Translittérez avant de construire le ticket : c'est la première cause d'imprimante qui « s'arrête au hasard ».
Mise en page du ticket
Titres en gras, logo, QR code vers la commande, code-barres, découpe automatique : tout est balisé dans printer_msg. Voyez la référence de mise en page et, pour un ticket de type facture, les codes-barres EAN-13.
Commencez par un ticket de test
Avant même de toucher à PrestaShop, créez un compte gratuit et imprimez un ticket avec un simple curl. Vérifier la chaîne d'impression indépendamment fait qu'en cas de problème plus tard, vous savez déjà s'il faut regarder du côté de PrestaShop ou de l'imprimante.
À lire aussi : Shopify et WooCommerce suivent le même schéma avec d'autres hooks.
FAQ
Quel hook PrestaShop utiliser pour imprimer une commande ?
actionOrderStatusPostUpdate, qui se déclenche après la persistance du changement de statut. Testez newOrderStatus->paid plutôt que de coder en dur des identifiants de statut, pour que les statuts personnalisés et les boutiques configurées autrement continuent de fonctionner.
Pourquoi la même commande s'imprime-t-elle deux fois ?
Les modules de paiement peuvent appliquer plusieurs fois le même statut payé, et les marchands peuvent le réappliquer manuellement. Stockez un drapeau d'impression sur la commande et sortez s'il est déjà posé.
Cela fonctionne-t-il en multiboutique ?
Oui, mais lisez l'identifiant d'imprimante depuis le contexte de boutique plutôt que depuis une valeur de configuration globale, sinon toutes les boutiques impriment sur la même machine.
Faut-il un ordinateur dans la boutique ?
Non. Une imprimante cloud se connecte seule en 4G, Wi-Fi ou Ethernet, et une imprimante USB existante est joignable via un adaptateur Raspberry Pi.