Nitech — catalogue et commande

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 et conditions. 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. Si web_resume.status=available, proposer au client le choix parmi les quatre liens privés de boutique, valables sept jours : ils ouvrent le même caddie et conservent son origine MCP. La reprise Web est facultative.

Préparer le moyen de paiement du même caddie MCP : payment_method=card, transfer ou cheque. Pour virement/chèque, confirmer enregistre seulement c_stat=3 et c_moyp=3/2 et renvoie les instructions existantes : aucun règlement reçu, stock, e-mail ou facture. Une carte en cours/incertaine ou une commande déjà prise en compte interdit un autre moyen. Pour la carte, préparer le paiement autonome Scellius. Appeler avec confirmed=false, cart_access, expected_amount, currency=EUR et une clé UUID pour présenter le montant au client. Uniquement après son accord explicite, rappeler confirmed=true avec confirmation_token et proof_reference. Renvoyer payment_page ou action.url au client : URL stable sans expiration (expires_at=null). La préparation UNISSUED peut attendre ; le formulaire bancaire est daté et marqué ISSUED seulement au départ explicite du client. Les confirmations temporaires sont renouvelées derrière la page. Une session ISSUED ou LEGACY_UNKNOWN reste protégée jusqu'au résultat authentifié ; ne jamais inventer une expiration bancaire. Le client saisit sa carte uniquement chez Scellius. Aucun envoi de carte ou authentification via MCP. Répétitions et clés différentes retrouvent la même tentative ; aucun nouvel essai automatique après un refus, une expiration ou une incertitude. Après REFUSED, ABANDONED ou EXPIRED authentifié par le serveur, demander un nouveau récapitulatif avec une nouvelle clé et retry_of=attempt_id, puis recueillir un nouvel accord explicite. get_payment donne la preuve serveur et les effets métier. Un lien ne valide pas le paiement.

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.

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.

Retrouver les preuves publiables pièce/appareil du pilote. 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 ; la qualification métier de la fiche reste séparée.

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.

Retrouver le même caddie MCP, son montant accepté, les trois moyens card/transfer/cheque, le moyen choisi, les instructions et son état bancaire Scellius. payment_page fournit une URL privée stable du caddie, sans date d'expiration, commune aux trois moyens ; elle reste consultable après paiement. Le jeton p2 de cette page peut remplacer le jeton mcp_resume pour les appels suivants. awaiting_receipt signifie attente du règlement et ne prouve aucun paiement. Fournir cart_id et cart_access : le jeton mcp_resume privé obtenu dans un lien web_resume de create_order ou du BO. Ne jamais fournir un simple numéro comme preuve d’accès. NOT_PREPARED et PREPARED ne prouvent aucun paiement. Pour le client, AUTHORISED, AUTHORISED_TO_VALIDATE et CAPTURED se présentent simplement comme Paiement accepté ; ne pas détailler les étapes bancaires internes. business_effects et status signalent les réconciliations. Ne pas payer à nouveau en cas d’incertitude.

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.

Rechercher dans le catalogue actif par PID, référence observée, ancienne référence, désignation, marque ou appareil lié. Résultats courts et bornés ; conserver les incertitudes, puis appeler get_product par PID.