Din iulie 2026, Shopify POS UI Extensions expune alocarea reducerilor direct la nivelul componentelor dintr-un bundle de produse. Magazinele care vand pachete compuse pot calcula corect reducerile, taxele si raportarile pe fiecare produs din pachet, nu doar pe linia parinte din cos.

Daca vinzi bundle-uri pe Shopify POS si ai avut vreodata o neconcordanta intre reducerea afisata la casa si ce apare in rapoarte, tocmai ai primit un update care rezolva problema la radacina.

Ce s-a schimbat concret in versiunea 2026-07

Shopify a lansat versiunea 2026-07 a POS UI Extensions API cu o adaugare punctuala, dar cu impact real pentru oricine lucreaza cu bunduri de produse la punctul de vanzare fizic sau in aplicatii de tip POS.

Pana acum, API-ul expunea alocarea reducerilor (discountAllocations) doar pe linia parinte din cos, adica pe intregul bundle. Componentele individuale ale unui bundle primeau informatii despre taxe, dar nu si despre reduceri. Asta crea o gaura de date: daca aplicai o reducere pe un pachet de trei produse, nu puteai sti cat din acea reducere revenea fiecarui produs in parte.

Incepand cu versiunea 2026-07, fiecare componenta dintr-un bundle are propriul camp discountAllocations. Accesul se face prin shopify.cartLineItem.components?.[0]?.discountAllocations, iar aceeasi structura este disponibila si prin shopify.cart.current.value.lineItems pentru aplicatiile care citesc starea cosului.

Sursa originala: Shopify Changelog.

De ce era o problema reala, nu doar tehnica

Sa luam un exemplu concret. Un retailer vinde un kit de demaraj pentru sport: tricou, pantaloni si sosete, grupate intr-un bundle la 299 de lei, cu o reducere de 50 de lei aplicata pe pachet. In sistemul vechi, cei 50 de lei apareau pe linia parinte, dar niciunul dintre cele trei produse componente nu stia cat ii revenea din reducere.

Consecintele practice erau multiple:

Primul efect era la nivel de raportare fiscala. Daca tricoul, pantalonii si sosetele au cote TVA diferite sau provin de la furnizori diferiti, distributia reducerii conteaza pentru calcule corecte. O reducere nedistribuita inseamna potential erori in declaratii.

Al doilea efect era in analytics. Daca folosesti rapoarte de profitabilitate pe SKU, un produs din bundle aparea la costul sau intreg, fara reducerea alocata. Marja calculata era falsa. Luai decizii de pret pe date gresite.

Al treilea efect era in aplicatiile de loialitate sau de comisioane. Daca o aplicatie calcula un bonus sau un comision bazat pe valoarea neta a unui produs vandut, folosea valoarea bruta in lipsa alocarii reducerii.

Toate astea nu erau probleme teoretice. Erau cazuri reale intalnite de orice operator Shopify POS care lucra cu bunduri si discounturi simultane.

Cum functioneaza tehnic noul camp

Schimbarea este aditionala, ceea ce inseamna ca nu strica nimic existent. Aplicatiile care ruleaza pe versiunea API 2026-04 sau mai veche nu trebuie sa faca nicio modificare. Continua sa functioneze ca inainte.

Aplicatiile care adopta versiunea 2026-07 pot accesa components[].discountAllocations pe orice componenta dintr-un bundle. Structura LineItem este aceeasi folosita in Cart API, deci consistenta datelor este garantata intre cele doua puncte de acces.

Un detaliu important de implementare: aplicatia trebuie sa trateze cazul in care campul lipseste sau este gol. Nu toate componentele unui bundle vor avea reduceri alocate, mai ales daca reducerea se aplica selectiv sau daca bundle-ul nu are nicio promotie activa. Codul care nu verifica absenta campului va genera erori la runtime.

Practic, logica corecta este: verifica daca discountAllocations exista, verifica daca are elemente, apoi proceseaza. Simplu, dar obligatoriu.

Ce inseamna pentru tine ca antreprenor sau marketer roman

Daca ai un magazin fizic pe Shopify POS si vinzi bundle-uri, probabil ai simtit deja problema, chiar daca nu ai identificat-o ca sursa de date API. Te-ai uitat in rapoarte si cifrele nu se potriveau. Ai recalculat manual. Sau ai ignorat discrepanta si ai mers mai departe.

Acum ai o solutie la nivel de platforma, dar ea nu se activeaza singura. Daca ai o aplicatie personalizata sau lucrezi cu un dezvoltator care a construit extensii POS pentru magazinul tau, trebuie sa-i ceri explicit migrarea la versiunea 2026-07 si implementarea noului camp.

Daca folosesti aplicatii din Shopify App Store care gestioneaza bunduri, verifica cu furnizorul daca au planificat update-ul. Alegerea aplicatiilor dupa criterii corecte, nu doar dupa rating, este o discutie separata pe care am abordat-o in articolul despre cum se schimba selectia aplicatiilor Shopify dupa noile reguli privind recenziile.

Din perspectiva de marketing si performance, acest update are relevanta directa pentru raportarile de ROAS si CPA pe categorii de produse. Daca un bundle contine produse din campanii diferite sau cu atributii diferite, distribuirea corecta a reducerii la nivel de componenta iti da o imagine mai clara a profitabilitatii reale pe fiecare linie de produs. Nu mai esti nevoit sa faci aproximari.

Pentru magazinele care au si componenta de comert online, nu doar POS, merita sa verifici daca aceeasi logica este replicata si in extensiile web. Shopify tinde sa alinieze comportamentul API-urilor intre canale, dar nu intotdeauna simultan.

Implicatii pentru raportare, taxe si conformitate

In Romania, subiectul distributiei reducerilor pe componente are si o dimensiune de conformitate fiscala. Atunci cand un bundle combina produse cu cote TVA diferite (de exemplu, un supliment alimentar cu 9% si un accesoriu sport cu 19%), alocarea corecta a reducerii la nivel de componenta nu este optionala. Este necesara pentru calculul corect al bazei de impozitare.

Pana la acest update, o aplicatie POS trebuia fie sa estimeze distributia reducerii pe baza de reguli proprii, fie sa ignore problema si sa aplice reducerea uniform. Ambele abordari puteau genera erori in casa de marcat electronica si, implicit, in raportarile ANAF.

Cu discountAllocations la nivel de componenta, o aplicatie bine implementata poate prelua direct de la Shopify distributia calculata de platforma si o poate transmite mai departe catre sistemele fiscale sau de contabilitate. Asta reduce riscul de discrepante si simplifica reconcilierile lunare.

FAQ

Trebuie sa migrez toate aplicatiile POS la versiunea 2026-07?

Nu obligatoriu si nu imediat. Aplicatiile pe versiunea 2026-04 sau mai veche continua sa functioneze fara modificari. Migrarea la 2026-07 este necesara doar daca vrei sa accesezi discountAllocations la nivel de componenta. Daca nu lucrezi cu bunduri sau nu ai nevoie de aceasta granularitate, nu e urgenta.

Cum stiu daca aplicatia mea POS foloseste deja noua versiune API?

Intreaba direct dezvoltatorul sau furnizorul aplicatiei care versiune API este declarata in manifestul extensiei. Versiunea API se seteaza explicit la momentul dezvoltarii si nu se actualizeaza automat.

Aceasta schimbare afecteaza si magazinele online Shopify, nu doar POS-ul?

Schimbarea este specifica POS UI Extensions. Totusi, structura LineItem este consistenta cu Cart API, deci aplicatiile care citesc starea cosului prin shopify.cart.current.value.lineItems beneficiaza de aceleasi date noi. Pentru storefront-ul online, verifica documentatia Storefront API separat.

AI, om, agentie: cum arata fluxul corect

Un model AI poate citi documentatia tehnica, poate identifica implicatiile unui update API si poate genera rapid o lista de actiuni recomandate. Asta e valoros si il folosim si noi in analiza initiala.

Dar decizia de a migra sau nu o aplicatie, de a prioritiza un update fata de altul, de a renegocia cu un furnizor de aplicatii sau de a construi o solutie custom, aceasta decizie ramane la media buyer-ul sau managerul de ecommerce care cunoaste contextul magazinului, bugetul si obiectivele reale.

Executia tehnica, implementarea efectiva, testarea in mediu de productie si validarea datelor fiscale sunt facute de oameni cu experienta in Shopify POS, nu de un algoritm.

La ALLSoft Agency lucram cu magazine pe Shopify care vand atat online, cat si la punctul de vanzare fizic. Stim diferenta dintre un update API care necesita actiune imediata si unul care poate astepta. Daca ai bunduri pe POS, reduceri active si rapoarte care nu se potrivesc, da-ne un semnal. Facem mai intai un audit, nu o promisiune.