Shopify POS 11.15: reducerile procentuale returnează altă valoare

Shopify POS 11.15 schimbă ce returnează Discount.amount pentru reducerile procentuale: acum dă procentul, nu suma de bani. Concret, o reducere de 25% pe o linie de 200 de dolari returnează 25, în timp ce POS 11.14 și versiunile anterioare returnau 50, adică suma dedusă efectiv. Extensiile care foloseau această valoare ca sumă monetară trebuie să își actualizeze logica.

Este o corecție de contract, nu o funcție nouă. Sursele oficiale arată clar că schimbarea aliniază comportamentul la contractul Cart API. Problema reală nu e tehnică în sine, ci de business: orice extensie care afișa economii, calcula puncte de loialitate sau sincroniza reduceri cu un sistem extern poate afișa acum cifre greșite dacă tratează amount ca bani.

Ce s-a schimbat exact

Diferența sună minoră până când o pui în context. O valoare de 25 poate însemna 25% sau 25 de dolari, iar extensia decide singură cum o interpretează. POS 11.15 alege procentul. Versiunile anterioare alegeau suma.

Schimbarea acoperă:

• reduceri procentuale la nivel de coș și la nivel de linie;
• reduceri manuale, aplicate de aplicații și automate, expuse cu type: 'Percentage';
• starea curentă și abonamentele din Cart API, lineItems[].discounts, cartDiscount, cartDiscounts și API-ul contextual cartLineItem.

Există și un efect secundar important: corecția împiedică reinterpretarea alocării monetare a unei reduceri procentuale ca procent atunci când o extensie trimite starea coșului înapoi prin bulkCartUpdate. Practic, se închide o buclă în care procentul și suma se puteau amesteca.

Reducerile FixedAmount și Code rămân neschimbate, inclusiv codurile de reducere bazate pe procente expuse cu type: 'Code'. Aici e o capcană de citire rapidă: dacă vezi un cod de reducere procentual, nu înseamnă că se aplică aceeași regulă. Tipul contează.

Cine este afectat, fără scăpare prin versiune

Cel mai important detaliu pentru operatori: schimbarea se aplică tuturor versiunilor API pentru extensiile POS UI. Păstrarea unei versiuni api_version mai vechi nu păstrează comportamentul anterior. Nu există un comutator comod prin care să eviți subiectul.

Ce înseamnă asta în practică:

• Dacă extensia ta citește Discount.amount și presupune că e bani, ai o problemă de logică, nu de mediu.
• Dacă afișezi în interfață „ai economisit X”, X poate deveni brusc „25” în loc de „50”, ceea ce pentru un client la raft arată ca o eroare de preț sau ca o reducere mult mai mică.
• Dacă trimiți valoarea mai departe către un CRM, un program de loialitate sau un sistem ERP, ajungi cu date poluate în locuri în care nimeni nu se uită zilnic.

Recomandarea din documentație este explicită: verifică Discount.type înainte de a interpreta amount și actualizează afișările de monedă, calculele de economii, punctele de loialitate și integrările care tratează valorile Percentage ca sumă de bani.

Ce verifici înainte să te liniștești

Nu te baza pe faptul că „la noi merge”. Testează pe POS 11.15 sau mai nou, pe cazuri concrete:

1. Reducere procentuală la nivel de coș.
2. Reducere procentuală la nivel de linie.
3. Reducere procentuală automată.
4. Fluxuri bulkCartUpdate care duc starea coșului dus-întors.
5. Reduceri FixedAmount și Code, ca să confirmi că nu s-au stricat.

Dacă extensia trebuie să funcționeze și pe POS 11.14 sau mai vechi, gestionează ambele comportamente până când acele dispozitive sunt actualizate. Asta înseamnă cod defensiv, nu presupuneri: citește tipul, apoi decide cum interpretezi valoarea.

Am scris în trecut despre ce decide marja reală într-un business de comerț, în Produs nou sau brand nou? Ce decide marja în 2026. Aici e același principiu la nivel de execuție: o cifră afișată greșit la punctul de vânzare nu rămâne doar o problemă tehnică, ajunge în percepția clientului și în raportul de marjă.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Să spunem că ai un lanț mic de retail cu 5 magazine și folosești o extensie POS personalizată care afișează clientului „economisești 50 de lei” la o reducere de 25% pe un produs de 200 de lei. După update, dacă logica nu e corectată, pe ecran poate apărea „25”. Clientul vede altă cifră decât se aștepta. Casierul nu are explicație. Se creează o discuție la tejghea care costă timp și încredere.

Al doilea scenariu, mai costisitor: ai un program de loialitate care acordă puncte proporțional cu valoarea reducerii. Dacă integrarea tratează amount ca bani, punctele devin greșite. Nu e o pierdere dramatică per tranzacție, dar se acumulează pe sute de vânzări și devine o discrepanță pe care o descoperi târziu, când reclamă clienții.

Al treilea scenariu, cel mai frecvent în echipele mici: nimeni nu verifică pentru că „nu am atins noi codul”. Corecția vine din platformă, nu din codul tău, deci se aplică indiferent de ce ai făcut tu. Ăsta e riscul real al dependenței de contracte de API pe care nu le monitorizezi.

Recomandarea mea practică: pune pe lista de verificat, în această săptămână, tot ce atinge reduceri în POS. Nu pentru că e dramatic, ci pentru că e ieftin de verificat acum și scump de reparat după ce clienții semnalează.

Ce facem noi, la modul concret

Dacă lucrezi cu echipe de dezvoltare, cere-le un inventar simplu: unde se citește Discount.amount și ce presupune fiecare loc despre tipul reducerii. Apoi un test pe POS 11.15 cu cele cinci cazuri de mai sus.

Dacă lucrezi cu agenții sau integratori externi, cere-le confirmarea scrisă că au verificat, nu un „da, e ok”. O verificare incompletă nu dovedește absența problemei. Nu avem dovezi aici despre pierderi de bani sau efecte pe vânzări, și nu o să inventăm una. Avem doar un contract schimbat și o listă clară de verificat.

Dacă ai un magazin online și nu folosești POS, subiectul te poate părea irelevant. Nu e complet. Multe magazine cu prezență fizică au acum un flux unic de date între vânzarea la raft și raportarea din ecommerce. Ceea ce se strică la POS se vede în dashboard-ul de marketing câteva zile mai târziu, sub formă de cifre care nu se leagă. Despre genul acesta de decizie, luată pe date parțiale, am scris în Multi-location SEO: un singur adevăr per locație, executat corect. Aici e aceeași logică aplicată la datele de vânzare.

FAQ

Trebuie să actualizez ceva dacă extensia mea nu citește Discount.amount? Nu pentru această schimbare. Dacă nu atingi valoarea respectivă, nu ești afectat direct. Verifică totuși dacă vreo integrare externă primește date din cart state.

Păstrarea unei versiuni API vechi mă protejează? Nu. Schimbarea se aplică tuturor versiunilor API pentru extensiile POS UI. Documentația oficială spune explicit că o versiune mai veche nu păstrează comportamentul anterior.

Ce fac dacă suport și POS 11.14 sau mai vechi? Gestionează ambele comportamente până când dispozitivele sunt actualizate. Practic, cod defensiv: citește tipul reducerii și interpretează valoarea în funcție de context, nu presupune că e mereu același lucru.

Concluzia ALLSoft Agency

AI-ul te ajută aici într-un mod limitat, dar util: poți cere unui asistent să caute în cod toate locurile unde se folosește Discount.amount, să grupeze cazurile și să îți pregătească o listă de testat. Poate face și un plan de verificare pe cele cinci scenarii.

Dar decizia despre cum interpretezi valoarea, ce afișezi clientului și ce trimiți mai departe către loialitate sau ERP rămâne umană. Un media buyer sau un operator senior știe că o cifră afișată greșit la punctul de vânzare nu se rezolvă cu un fix tehnic izolat. Pasul concret îl face ALLSoft Agency: inventar de integrări, plan de testare și prioritizare pe impact real în vânzări. Fără hype, fără promisiuni pe cifre pe care nu le avem.