Nitech — heating spare parts and ordering

Au client, parler de sa commande et de la prochaine action utile. Garder les noms d’outils, états bruts, identifiants internes, clés, jetons et étapes techniques hors du dialogue courant. Les autorisations affichées par l’application de l’assistant relèvent de cette application et ne remplacent pas l’accord demandé par Nitech. Après le récapitulatif et le lien vers les CGV de l’aperçu, poser une seule question, adaptée au montant réel. Exemple « Confirmez-vous cette commande de 210 € TTC et acceptez-vous les CGV ? » Une réponse explicite à cette question suffit pour l’accord de commande et les CGV. Ne pas demander de formule à recopier ni plusieurs déclarations. Après création, donner la référence client, le montant et la prochaine action utile. Créer une vraie commande Nitech dans le canal MCP autonome, sans boutique Web ni paiement. Appeler d’abord avec confirmation.confirmed=false pour présenter au client les articles, adresses, montant, terms_version et le lien terms_url des CGV conservables. Faire consulter ce lien avant de recueillir l’accord. Après son accord explicite, rappeler avec la même clé UUID, le token retourné, confirmed=true, confirmed_at, proof_reference et terms_version. Prix, stock, port et conditions sont revérifiés. Un changement exige un nouveau récapitulatif. Conserver la même clé et les mêmes arguments pour toute reprise, y compris après timeout ou résultat incertain ; ne jamais créer une nouvelle clé pour contourner pending ou un conflit. 30 lignes, 100 unités par ligne, 300 au total, 32 Kio. Ne déclenche ni paiement, facture, e-mail ni réservation. Après création, poursuivre par défaut sur MCP avec prepare_payment. Les liens privés web_resume des quatre boutiques restent des alternatives uniquement si le client les demande ; ne pas les proposer systématiquement. Ils conservent le même caddie et leur validité existante. Livraison GLS optionnelle : delivery={mode:gls_pickup,relay_id}, identifiant obtenu par search_relay_points ; destination de recherche complète requise pour les devis. Aucun champ libre de relais. Le récapitulatif confirmed=false porte le mode, le relais vérifié, les frais et le total. Conserver identité/email/téléphone du destinataire, et facturation indépendante. Toute modification exige un nouvel aperçu et un nouvel accord/token ; jamais de remplacement silencieux du relais. En cas de saisie invalide rejetée avant création (category=invalid_input, operation_outcome=not_created), lire error.fields (path, reason, expected_correction), demander la correction puis rappeler confirmed=false avec la même clé. Présenter les coordonnées et le montant actualisés et recueillir un nouvel accord avant confirmed=true. Une ancienne confirmation ne couvre pas une adresse corrigée. Pour unknown, pending ou un conflit d’idempotence : ne changer ni clé ni arguments, réconcilier. La facturation utilise la référence pays, pas les zones desservies. Aucun contrôle d’existence de rue ou de correspondance rue–ville–code postal.

Retrouver les preuves documentées disponibles pour une pièce et un appareil. La couverture documentaire est partielle ; une absence de preuve ne démontre ni compatibilité ni incompatibilité. verified exige une décision humaine active liée à la preuve exacte, au SHA, à la page et au repère courants. stale_source impose une nouvelle vérification. Les scores ne sont pas des probabilités de compatibilité.

Lire l'offre canonique à l'heure d'observation : mise en vente, stock compté, disponibilité et autorisation de commande distinctes. Cette consultation ne réserve aucun stock. Prix et disponibilité sont lus dans le catalogue de production ; ils ne prouvent pas la compatibilité avec un appareil.

Lire une commande privée avec cart_id et cart_access (m1 privé ou p2 permanent). Le numéro seul ne suffit jamais. Reprend la même vérification d’accès que get_payment. Lecture seule : état de commande, paiement serveur, bordereaux et quantités documentées, déclaration de départ, transporteur explicitement renseigné. Un bordereau ne prouve pas la préparation physique ; une déclaration de départ ne prouve pas la livraison. Numéro/lien de suivi absents de ces sources : null et unavailable explicites. Ne rien déduire du paiement sur l’expédition. Ne pas recréer ni repayer en cas d’incertitude.

Lire le paiement de la commande dans les données communes Nitech avec cart_id et cart_access (preuve privée m1, w2 ou p2). Le numéro seul ne donne pas accès. Lecture seule, sans journal de tentatives MCP ni synchronisation depuis la notification bancaire. payment_page fournit le lien privé permanent de choix et de suivi. Le choix chèque/virement ne prouve pas la réception du règlement et ne bloque pas l’accès CB si la commande est payable. Une ancienne tentative ne détermine pas les droits de paiement. Présenter simplement le paiement et l’état de commande retournés, sans déduire d’effets de stock, de courriel ou d’expédition. Un lien ou un retour navigateur ne prouve pas un paiement. En cas de lecture indisponible, annoncer l’indisponibilité et conserver la même commande ; ne pas inventer son état.

Lire le produit public Nitech courant par PID, y compris les produits hors vente historiquement publics. Textes, caractéristiques, appareils, éclatés, repères et documents conservent leur provenance ; une relation historique ou un contenu observé ne vaut pas qualification humaine.

Lire les seuls documents connus et publiables du produit ou de ses appareils liés, avec leur type et les contrôles humains applicables à leur source. Les autres contenus restent à vérifier ; aucune qualification n'est déduite automatiquement.

Préparer l’accès au paiement de la même commande : payment_method=card, transfer ou cheque. Fournir cart_id, cart_access, expected_amount, currency=EUR et idempotency_key. Une demande explicite identifiant commande, montant, devise et moyen vaut accord. Appeler confirmed=false puis confirmed=true avec la même clé UUID, le confirmation_token retourné et proof_reference identifiant cet accord, sans reposer la même question si le récapitulatif concorde. Si le montant ou les conditions changent, présenter le changement avant de demander un nouvel accord. Ne jamais inventer une preuve. Pour la carte, cet outil fournit seulement action.url, le lien privé /payments/card : aucun formulaire bancaire ni tentative n’est créé par l’appel MCP. Remettre ce lien au client sans l’ouvrir avec les outils de l’assistant. Le navigateur crée le formulaire Scellius lorsque le client poursuit. Une ancienne tentative, une ancienne référence bancaire ou un choix chèque/virement ne bloque pas cet accès. Le suivi de la commande commune détermine si elle est payable ; une commande payée ou annulée reste en consultation. retry_of reste accepté pour compatibilité et n’est pas nécessaire. Pour virement/chèque, confirmer enregistre le moyen choisi et renvoie les instructions existantes, sans règlement reçu, stock, e-mail ou facture. payment_page reste le lien général de choix et de suivi. Le client saisit sa carte uniquement chez Scellius. Après paiement, get_payment lit les données communes ; un lien ou un retour navigateur ne prouve pas le paiement. Au client, donner la référence, le montant et l’action utile ; ne pas exposer les étapes techniques.

Contrat JSON : destination et lines sont obligatoires à la racine. country_code et postal_code sont des chaînes DANS destination, jamais à la racine. Sans delivery (domicile), destination contient uniquement country_code et postal_code : ne pas envoyer city ni address_line1. France : postal_code complet requis. lines est un tableau d’objets {product_id: entier, quantity: entier}, sans autre champ. Exemple minimal domicile France : {"destination":{"country_code":"FR","postal_code":"54000"},"lines":[{"product_id":1843,"quantity":1}]}. Avec delivery GLS, conserver le contrat existant : destination contient aussi city et address_line1, delivery={mode:gls_pickup,relay_id} obtenu par search_relay_points. quote_cart n’accepte ni confirmation ni coordonnées de commande. Préparer un devis complet du panier depuis les offres et le port Nitech actuels. Pays et code postal selon la zone, product_id et quantity seulement. 30 lignes distinctes, 100 unités par ligne, 300 au total, 8 Kio. Doublons refusés. Lecture seule sans panier, réservation, commande ni paiement. Toute ligne invalide bloque les totaux. Offres et port à relire lors de la commande ; checkout des boutiques autoritaire. Livraison GLS optionnelle : delivery={mode:gls_pickup,relay_id}, identifiant obtenu par search_relay_points ; destination de recherche complète requise pour les devis. Aucun champ libre de relais. Le récapitulatif confirmed=false porte le mode, le relais vérifié, les frais et le total. Conserver identité/email/téléphone du destinataire, et facturation indépendante. Toute modification exige un nouvel aperçu et un nouvel accord/token ; jamais de remplacement silencieux du relais. Lire category et fields (path, reason, expected_correction) dans les erreurs. Corriger la saisie si demandé ; destination_not_served appelle une autre destination ou Nitech ; temporarily_unavailable appelle la même demande sans accuser l’adresse. Après correction : nouveau devis, puis coordonnées et montant à faire confirmer avant création. Aucun contrôle postal réel.

Calculer le port actuel depuis les produits, profils et zones Nitech relus à chaque appel. Entrées : pays, code postal requis pour la France, product_id et quantity. Limites : 30 lignes, 100 unités par produit, 300 au total. Renvoie HT, TVA, TTC, zone, groupes tarifaires et politique observée. Ce résultat n’est pas une réservation ; aucune commande n’est créée ; montant à relire lors d’une future commande. Le calcul commercial des boutiques reste autoritaire. Livraison GLS optionnelle : delivery={mode:gls_pickup,relay_id}, identifiant obtenu par search_relay_points ; destination de recherche complète requise pour les devis. Aucun champ libre de relais. Le récapitulatif confirmed=false porte le mode, le relais vérifié, les frais et le total. Conserver identité/email/téléphone du destinataire, et facturation indépendante. Toute modification exige un nouvel aperçu et un nouvel accord/token ; jamais de remplacement silencieux du relais. Lire category et fields (path, reason, expected_correction) dans les erreurs. Corriger la saisie si demandé ; destination_not_served appelle une autre destination ou Nitech ; temporarily_unavailable appelle la même demande sans accuser l’adresse. Après correction : nouveau devis, puis coordonnées et montant à faire confirmer avant création. Aucun contrôle postal réel.

Au client, parler de sa commande et de la prochaine action utile. Garder les noms d’outils, états bruts, identifiants internes, clés, jetons et étapes techniques hors du dialogue courant. Les autorisations affichées par l’application de l’assistant relèvent de cette application et ne remplacent pas l’accord demandé par Nitech. Présenter la commande et les articles et quantités concernés, ou la commande entière, puis poser une seule question « Confirmez-vous l’envoi de cette déclaration de rétractation ? » Après réception confirmée, dire « Votre déclaration de rétractation a été reçue » et fournir l’accusé. Garder les précautions techniques dans les opérations internes et ne pas annoncer un remboursement ou une annulation non effectués. Déposer une déclaration de rétractation privée avec le même service que le formulaire existant. Fournir cart_id et cart_access (m1 ou p2) : jamais un numéro ou un email seuls. scope désigne la commande entière (Commande entière) ou les articles et quantités concernés ; aucun motif obligatoire. Commencer par confirmed=false : aperçu sans dépôt ni notification. Présenter le scope exact au client et obtenir son accord explicite pour envoyer la déclaration. Rappeler ensuite avec confirmed=true, les mêmes cart_id/cart_access/scope et le confirmation_token retourné. Le jeton est lié à cet aperçu ; toute modification impose un nouvel aperçu et accord. Conserver ensuite les arguments et le même jeton, même après timeout, expiration ou réponse perdue ; la répétition retrouve le même dépôt et la même date, sans doublon. Ne jamais demander un nouveau jeton pour contourner une issue unknown ou un conflit. received renvoie référence, date UTC et accusé conservable en texte et lien privé. queued signifie confié à la file de courriels, pas livré. Les questions d’éligibilité sont examinées par Nitech. Aucun remboursement, annulation de commande, avoir ou mouvement de stock automatique. get_order reste une lecture ; le formulaire privé reste disponible.

Rechercher dans le catalogue actif par PID, référence observée, ancienne référence, désignation, marque ou appareil lié. La recherche textuelle porte sur une sous-chaîne continue dans chaque champ : fournir une référence connue ou un fragment court, pas toute la demande client. Pour une pièce décrite, utiliser auto ou designation avec des termes distinctifs contigus, par exemple Deville 9424 ; vérifier ensuite dimensions et compatibilité dans get_product. Un numéro d’appareil ne prouve pas une référence fabricant : utiliser designation/model plutôt que manufacturer_reference sans preuve. Après no_match sans continuation, essayer au plus deux fragments plus courts pertinents en designation ou auto avant de demander une précision. Ne pas conclure à une absence du catalogue à partir d’une seule formulation. Si next_after_pid est non nul, des candidats restent à parcourir. Conserver les références, dates et incertitudes ; ouvrir les candidats avec get_product, sans inventer de PID.

Pour search_relay_points, destination désigne l’adresse du client autour de laquelle rechercher les points relais. Réutiliser l’adresse déjà fournie lorsqu’elle est complète ; ne demander que les informations manquantes. Pour le numéro et la rue, demander par exemple : « Pour trouver un point relais près de chez vous, pouvez-vous préciser votre numéro et votre rue ? » Ne pas appeler cette adresse « adresse de départ » ou « adresse d’expédition » : ce n’est pas le lieu d’expédition Nitech. Cette adresse de recherche ne vaut ni choix d’un relais ni modification de l’adresse de facturation. Rechercher les points relais GLS autour de destination (country_code, postal_code, city, address_line1) pour les lignes du panier, via l'API GLS existante. Lecture seule. Identifiant, nom, adresse, horaires lisibles, pauses et fermetures GLS lorsqu'ils sont fournis. Aucune distance ou capacité inventée, aucune réservation. Les heures affichées suivent le format REST GLS (millisecondes + 1h). Présenter les pauses et fermetures fournies ; un jour absent ne signifie pas fermé, et aucun horaire ne prouve une ouverture actuelle. Reprendre un relay_id retourné dans delivery={mode:gls_pickup,relay_id} de quote_cart_shipping, quote_cart et create_order. Le serveur revérifie le choix. Garder shipping_address comme destinataire réel et conserver billing_address séparée. Présenter mode, relais vérifié, frais et total, puis obtenir un nouvel accord si relais, adresse ou montant change. Lire category/fields/next_action dans les erreurs. Panne GLS : réessayer la même demande, sans modifier les adresses.