Un raport zilnic de stoc WooCommerce în n8n trebuie să citească toate paginile de produse și variații, să distingă stocul necunoscut de zero și să limiteze retrimiterile. Exemplul din acest ghid citește magazinul prin GET, trimite un e-mail cu produsele sub prag și păstrează într-un tabel separat starea raportului pentru fiecare zi.
Nu modifică stocuri și nu plasează comenzi de reaprovizionare. Raportul este un ajutor pentru operator: vânzările pot continua între cererile API, așa că verifici cantitatea curentă înainte să comanzi marfă. O automatizare de citire este un prim pas util înaintea oricărei scrieri comerciale.
Importă workflowul și conectează credențialele
Descarcă pachetul cu workflow JSON, schema SQL și testele. Exportul are 14 noduri standard, vizează n8n 2.x și rămâne inactiv după import. Nu include secrete sau date ale unui magazin. Ai nevoie de acces HTTPS la WooCommerce, SMTP și o bază PostgreSQL separată pentru evidența rapoartelor.
- În WooCommerce > Settings > Advanced > REST API, creează o cheie cu permisiunea Read. Alege un utilizator cu accesul necesar și limitează cheia la această integrare. Pașii de creare și autentificarea sunt descrise în documentația oficială.
- Importă
workflow.jsonîn editorul n8n. În nodurile Products și Variations selectează același credential HTTP Basic Auth: consumer key ca utilizator și consumer secret ca parolă. Păstrează validarea TLS activă; nu pune cheile în URL. - În nodul Config, înlocuiește adresa demonstrativă cu URL-ul HTTPS al magazinului, fără slash final. Completează expeditorul, destinatarul și pragul numeric. Valoarea implicită este 5, inclusiv.
- Aplică
schema.sqlîntr-o bază pentru integrare. În Claim day și Mark sent selectează credentialul PostgreSQL. Nu modifica tabelele interne n8n și nu acorda workflowului acces de scriere în baza magazinului. - În Send report selectează credentialul SMTP. Configurează un destinatar de test autorizat și un expeditor permis de furnizor. Atașează un error workflow care alertează operatorul.
Pentru instanța n8n poți porni de la ghidul de configurare a automatizărilor. Conexiunile către magazin, PostgreSQL și SMTP trebuie verificate separat; existența aplicației nu înseamnă că toate credențialele sunt funcționale.
Citește și pagina a doua, inclusiv pentru variații
API-ul WooCommerce folosește page și per_page, iar antetul X-WP-TotalPages indică numărul paginilor. Workflowul cere câte 100 de rezultate și păstrează răspunsul complet, inclusiv antetele.
Nodul Products citește produsele publicate. Pentru fiecare produs de tip variable, Variations citește separat /wp-json/wc/v3/products/{id}/variations, tot paginat. Faptul că ai descărcat toate produsele nu înseamnă că ai și toate combinațiile de mărime, culoare sau alt atribut.
În HTTP Request, paginarea actualizează parametrul page cu {{ $pageCount + 1 }}. Condiția de oprire compară pagina cu antetul totalului. Agregarea verifică numărul paginilor și identificatorii duplicați înainte să construiască raportul.
Există o limită de siguranță de 500 de pagini pentru fiecare listă. Dacă magazinul o depășește sau lipsesc antetele, execuția trebuie investigată; exemplul nu trimite intenționat un raport trunchiat ca și cum ar fi complet. Pentru cataloage mari, mărește controlat limita și verifică memoria și durata execuției.
Exportul include pauze între pagini și reîncercări limitate pentru aceste citiri GET. Ajustează-le dacă magazinul aplică rate limiting. Nu aplica aceeași politică fără analiză unor viitoare operațiuni de scriere. Răspunsurile 401, 403 sau erorile persistente nu trebuie transformate într-un raport cu zero produse.
Chiar cu paginare corectă, citirea nu este o fotografie atomică. O comandă nouă sau modificarea catalogului între pagini poate influența rezultatul. Ordonarea după ID și verificarea dublurilor reduc unele probleme de colectare, dar nu blochează magazinul și nu garantează o cantitate la un singur moment.
Definește ce înseamnă „stoc mic”
Documentația distinge manage_stock, stock_quantity și stock_status; variațiile pot folosi și valoarea parent pentru gestiunea stocului. Regula numerică se aplică numai unei cantități urmărite și valide. null nu devine zero prin conversie.
| Situație | Tratamentul din exemplu |
|---|---|
| Stoc urmărit, cantitate cel mult egală cu pragul | Intră în lista de reaprovizionare, inclusiv zero și valori negative. |
| Stoc urmărit, cantitate null sau nevalidă | Intră la „Date de verificat”, fără cantitate inventată. |
| Stoc neurmărit, produs outofstock | Apare ca indisponibil, cu cantitate necunoscută. |
| Stoc neurmărit, produs instock | Nu primește o avertizare numerică. |
| Variații care moștenesc stocul părintelui | Stocul comun este raportat o singură dată. |
Variațiile cu stoc propriu sunt evaluate independent. Pentru un tricou cu un stoc comun și mai multe variații care îl moștenesc, nu aduni aceeași cantitate de mai multe ori. În schimb, dacă fiecare mărime este gestionată separat, operatorul trebuie să vadă exact variația care a ajuns sub prag.
Produsele external și grouped nu sunt tratate drept produse simple cu stoc fizic. Exemplul folosește un prag comun, ușor de revizuit. Dacă ulterior ai praguri pe SKU, definește-le într-o sursă controlată și testează lipsa unui prag, fără să ascunzi produsele neconfigurate.
Raportul include SKU-ul sau ID-ul când SKU-ul lipsește. Este text simplu, astfel încât numele produselor nu devin HTML executabil în e-mail. Starea de backorder rămâne vizibilă în contextul stocului; posibilitatea de a vinde la comandă nu elimină necesitatea unei decizii de aprovizionare.
Trimite un raport zilnic fără să ascunzi eșecurile
Programarea este 0 8 * * *, cu fusul Europe/Bucharest în workflow. Ziua folosită pentru deduplicare este calculată în același fus. Verifică ora după import și publică workflowul numai după proba cu destinatarul de test.
Cheia unică a tabelului este perechea magazin–zi. Nodul Claim day rezervă atomic trimiterea prin INSERT ... ON CONFLICT DO NOTHING. Astfel, două execuții simultane nu câștigă ambele dreptul de trimitere. Nodul Postgres folosește parametri SQL, conform documentației n8n.
Rezervarea are inițial starea pending. După răspunsul SMTP reușit, Mark sent o schimbă în sent. Dacă SMTP eșuează ori procesul cade între acești pași, rândul rămâne pending și blochează retrimiterea automată. Acesta nu este un mecanism de livrare „exactly once”.
Monitorizează obligatoriu rândurile pending mai vechi decât durata normală a fluxului, folosind interogarea din pachet, și alertează o persoană. Nu lăsa simpla rezervare să mascheze un raport lipsă. Error workflow-ul n8n ajută la excepții, iar monitorizarea stării acoperă și execuțiile întrerupte.
La recuperare, verifică execuția și furnizorul SMTP. Dacă mesajul a fost acceptat, marchează trimiterea în registru. Dacă este confirmat că nu a fost acceptat, extrage textul salvat, retrimite-l manual o singură dată și înregistrează rezultatul. Dacă statutul este necunoscut, decizia de retrimitere aparține operatorului și poate produce un duplicat. Nu șterge cheia pentru a relansa orbește fluxul.
Un răspuns SMTP reușit nu dovedește prezența în inbox. Verifică și recepția reală în perioada de introducere. Raportul este trimis inclusiv când nu există produse sub prag, ceea ce ajută la observarea unei zile fără execuție.
Verifică exemplele înainte să conectezi magazinul
În pachet, test-workflow.mjs execută codul real din nodurile Code cu date sintetice. Rulează-l cu Node.js 22 sau mai nou:
node test-workflow.mjsTestele acoperă 101 produse pe două pagini, pagini lipsă, ID-uri duplicate, stoc comun și propriu, null, cantități negative, egalitatea cu pragul și schimbarea zilei în București. Verifică și faptul că exportul nu conține credențiale și că solicitările către WooCommerce sunt GET.
Într-un PostgreSQL local izolat, schema și rezervarea din export au fost verificate cu 12 cereri concurente: una singură a obținut rezervarea zilei. Aceste verificări nu reprezintă o execuție completă n8n cu magazin și SMTP reale. După import, folosește un magazin de staging cu peste 100 de produse și peste 100 de variații pentru un produs, ca să verifici ambele paginări și asocierea răspunsurilor în runtime.
Păstrează separat magazinul și evidența notificărilor
Revocă cheia WooCommerce când dezafectezi integrarea și limitează cine poate edita workflowul. Răspunsurile API și textul rapoartelor pot conține informații comerciale; stabilește cât păstrezi istoricul execuțiilor. Pentru WordPress și automatizări, consultă și ghidul WordPress cu n8n.
Fă backup tabelului de trimitere și configurației. După restaurarea unei copii vechi, oprește programarea și reconciliază zilele lipsă cu furnizorul de e-mail înainte de reluare: cheile pierdute din registru pot permite retrimiterea unor rapoarte deja acceptate. Pentru infrastructură și copii, vezi administrat versus găzduire proprie și backup PostgreSQL în S3.
Întrebări frecvente
De ce nu consideri null drept stoc zero?
Poate însemna că nu este urmărită cantitatea sau că informația lipsește. Zero este o cantitate cunoscută. Conflarea lor produce alerte greșite și poate ascunde o configurare incompletă.
Este suficient endpointul de produse?
Nu pentru cantitățile tuturor variațiilor. Exemplul le citește separat și le paginează, apoi distinge stocul propriu de cel moștenit.
Workflowul poate modifica magazinul?
Cererile incluse sunt numai GET, iar cheia se configurează Read. El scrie doar în tabelul integrării și trimite e-mail; nu actualizează produse sau stocuri.
De ce nu reîncearcă automat orice e-mail eșuat?
Unele erori apar după acceptarea mesajului. O retrimitere oarbă poate dubla raportul. Starea pending și revizuirea explicită fac această incertitudine vizibilă.
Pentru găzduirea fluxului, consultă n8n administrat DanubeData. Configurarea regulilor magazinului, a destinatarilor și a verificărilor de livrare rămâne parte din integrarea ta.
Documentație și exemplu complet
- WooCommerce REST API v3
- n8n HTTP Request
- n8n Postgres
- n8n Send Email și tratarea erorilor
- Workflow JSON, SQL, instrucțiuni și teste
