Integrări Torgsoft: marketplace-uri, CRM și magazine online

1. Cum se organizează schimbul și cine este responsabil pentru ce

Adaptorul — un program separat sau un modul al site-ului care convertește fișierele Torgsoft în solicitări către API-ul serviciului extern și pregătește fișierele noilor comenzi pentru Torgsoft. API-ul platformei oferă operațiuni permise cu produsele, comenzile sau contactele sale. **Feed-ul** — un fișier de catalog pe care serviciul îl descarcă printr-un link sau îl acceptă prin propriul său mecanism de import.

Conexiunea este formată din două părți. Integratorul configurează exportul și importul în Torgsoft. Dezvoltatorul creează sau instalează un modul compatibil pe partea site-ului, CRM-ului sau marketplace-ului. Activarea opțiunii oferă capabilitățile Torgsoft în limitele documentației sale; serviciul terț de schimb efectuează conversia datelor și lucrează cu API-ul platformei selectate.

O singură persoană poate îndeplini mai multe roluri. În specificația tehnică pentru fiecare secțiune, executorul și rezultatul prin care se verifică munca sunt totuși definite.

Direcțiile de transmitere a datelor

Trei metode de conectare

1. Integrare standard. Proprietarul activează opțiunea sau modulul TOM, integratorul îl configurează conform instrucțiunilor. Lista de operațiuni este definită de documentația conexiunii.
2. Adaptor terț. Integratorul pregătește schimbul de fișiere Torgsoft, dezvoltatorul lucrează cu API-ul sau feed-ul platformei și formează fișierele de comenzi.
3. Conectare prin site sau CRM. Torgsoft schimbă date cu un singur sistem care are conectori către alte canale. Dezvoltatorul determină ruta comenzilor, sursa stocurilor și regulile de rezervare pentru toate verigile.

Pentru fiecare canal este definită o singură rută de primire a comenzii în Torgsoft. De exemplu, comenzile din marketplace sunt transmise printr-un adaptor direct sau prin CRM. Importul simultan prin ambele rute necesită un mecanism comun pentru eliminarea duplicatelor.

2. Ce trebuie pregătit în Torgsoft și cum se citesc fișierele sale

Baza adaptorului este formatul de sincronizare a magazinului online cu Torgsoft. Setările sunt descrise în instrucțiunile opțiunii. Înainte de dezvoltare, integratorul transmite dezvoltatorului fișierul real de produse, setările de export și numărul versiunii bazei de date.

2.1. Pregătirea obiectului de sincronizare

1. Activați «Sincronizarea cu magazinul online» și deschideți Depozit → Sincronizare cu magazinul online.
2. Creați un obiect cu numele canalului. Selectați centrele de evidență pentru export și centrul din care sunt plasate comenzile.
3. Determinați sursa prețului pentru factură: Torgsoft sau magazinul online. Pentru a salva prețul de achiziție pe platformă, bifați «Pentru produsele de pe factură, se iau prețurile din».
4. Conveniți asupra rezervării, procesării cantităților lipsă și contului sau casei de marcat pentru plăți.
5. Setați câmpurile, numele fișierelor, codificarea, transferul clienților și metoda de livrare a fotografiilor.
6. Configurați adresa de schimb, transferați manual produsele de testare și descărcați o singură comandă.
7. După verificare, activați programul și notificările pentru angajatul responsabil.

În fila «Clienți», se verifică căutarea după numărul de telefon, crearea de clienți noi și actualizarea datelor acestora. Dezvoltatorul transmite numărul de telefon în formatul internațional convenit. Căutarea după numărul de telefon nu înlocuiește cheia comenzii și nu protejează împotriva creării repetate a documentului.

2.2. Livrarea fișierelor: FTP cu TLS sau directorul serverului web

Tipul «Server web» funcționează cu fișiere într-un director specificat. Nu creează un API REST universal pentru Torgsoft. SFTP este un alt protocol; suportul său în Make, n8n sau un marketplace nu înseamnă suport în metoda de livrare selectată în Torgsoft.

Directoarele pentru feed-ul de produse, comenzi, contacte și certificate sunt separate prin drepturi de acces. În spatele adresei URL publice a sistemului de publicitate sunt plasate doar fișierul de produse permis și imaginile.

2.3. Produse, prețuri, stocuri și fotografii

TSGoods.trs — denumirea tipică pentru un CSV cu separatorul ;. Câmpurile, numele, ordinea lor, antetul și numele fișierului sunt personalizabile. Un format alternativ este YML, un catalog XML cu o structură corespunzătoare de etichete.

Parserul CSV este configurat în funcție de exportul real: separator, antete, codificare, ghilimele și numere. Caracterele speciale sunt verificate pe un fișier de test. În modul UTF-8, Torgsoft generează un CSV de produs cu un BOM — un marcaj de codificare de serviciu la începutul fișierului; adaptorul trebuie să-l proceseze.

YML-ul Torgsoft nu este un feed gata făcut pentru fiecare serviciu. Dezvoltatorul verifică elementul rădăcină, etichetele obligatorii, caracteristicile, limbile și ID-ul destinatarului. De exemplu, Hotline folosește propria structură XML, iar marketplace-urile necesită coduri de categorie și valori ale caracteristicilor.

2.4. Formatul noii comenzi

Torgsoft acceptă fișiere text .sal. Începând cu versiunea de bază de date 493, sunt suportate și XML și JSON în UTF-8. Pentru SAL, se utilizează codificarea obiectului de sincronizare; în modul UTF-8 este necesar BOM. Numele fișierului este compus din caractere ASCII: litere latine, numere și separatori siguri.

Datele API sunt convertite în schema Torgsoft: cumpărătorul ajunge în Client, parametrii — în Options, pozițiile — în Goods. Câmpuri obligatorii: Client.Name, Options.OrderNumber, Options.SaleType și GoodID, Price, Count pentru fiecare produs.

Exemplu de JSON cu date condiționale pentru o precomandă:

{
  "Client": {
    "Name": "Cumpărător de test",
    "MPhone": "+380670000000",
    "EMail": "buyer@example.com"
  },
  "Options": {
    "OrderNumber": "SHOP-A-100042",
    "SaleType": "1",
    "OrderDate": "2026-10-05 12:00:00",
    "CurrencyInternationalCode": "UAH",
    "Comment": "Comandă de test de la canal extern"
  },
  "Goods": [
    { "GoodID": "201", "Price": "1290.00", "Count": "1" },
    { "GoodID": "202", "Price": "350.00", "Count": "2" }
  ]
}

Înainte de încărcare, integratorul înlocuiește GoodID-urile reale din baza de date de test și verifică documentele în program. Dezvoltatorul formează un OrderNumber stabil din codul canalului, magazin, și ID-ul extern. Numerele comenzilor diferite și ale magazinelor nu trebuie să coincidă.

Câmpurile suplimentare transmit adresa, livrarea, data rezervării, codul valutar, tipul comerțului și centrul de evidență. Disponibilitatea depinde de versiunea bazei de date. WarehouseID este preluat din Torgsoft; codul depozitului marketplace-ului necesită mapare. Scopul WarehouseID în parametrii generali și în rândul de produs este descris în formatul de schimb.

2.5. SaleType: ce documente creează importul

Pentru SaleType 2–5, documentația presupune prezența întregii cantități necesare în centrul de evidență. În absența produsului, vânzarea poate trece pe minus. Înainte de crearea automată a documentelor, se verifică cantitatea și regulile de acțiune în caz de deficit.

Comentariul «plătit» nu procesează plata. SaleType nu returnează fondurile în serviciul de plată. Dezvoltatorul și integratorul convin asupra evenimentului de pe platformă, tipului de document, contului de încasare și acțiunilor ulterioare ale angajatului.

2.6. Clienți, prețuri en-gros și certificate

Conform setărilor, Torgsoft exportă TSClients.trs: numele complet, contactele, adresa, cardul clientului, reducerea, suma pentru calculul acesteia și bonusurile acumulate. Dezvoltatorul determină cheia de mapare și transmite destinatarului doar câmpurile necesare. Istoricul cumpărăturilor nu este inclus în acest fișier.

Opțiunea «Politica de prețuri en-gros» adaugă un XML cu praguri de cantitate și prețuri. Pentru certificate este prevăzut CSV-ul TSGiftCertificate.trs. Destinatarul trebuie să implementeze regulile corespunzătoare de preț sau de fidelitate.

Bonusurile și certificatele utilizate sunt transmise în comandă prin BonusPay și GiftCertificate. Integratorul activează opțiunile și setările necesare; dezvoltatorul, înainte de plată, verifică datele actuale conform procesului convenit. Echipa verifică deducerea finală în Torgsoft și regulile de anulare a achiziției.

Exportul bonusurilor și certificatelor este o captură la momentul formării. Pentru a utiliza fidelitatea în mai multe canale, este necesar un proces convenit de verificare și deducere. Fișierul în sine nu blochează reutilizarea unui certificat în alt magazin.

2.7. Program, mesaje POST și confirmarea importului

Produsele și comenzile pot avea sarcini separate. Integratorul selectează tipul de sincronizare și executorul: Torgsoft sau serverul de sarcini automate. Pentru lansarea prin program, este necesar ca programul să fie deschis pe computerul specificat de utilizatorul specificat. Pentru lucrul în fundal, se verifică serviciul, versiunea acestuia, drepturile și accesul la fișiere.

Intervalul se stabilește conform recomandărilor din secțiunea de ajutor: nu mai des de o dată la 10 minute, luând în considerare celelalte obiecte. Dezvoltatorul configurează separat frecvența solicitărilor către API. Interogarea frecventă a platformei nu accelerează importul fișierului în Torgsoft în afara programului.

«Trimitere solicitare POST după sincronizare» notifică site-ul despre finalizarea schimbului. Dezvoltatorul furnizează URL-ul, numele și valoarea parametrului; integratorul le setează în program. Pentru solicitare, se specifică timeout-ul final, User-Agent permis și redirecționarea. Un timeout de 0 înseamnă așteptare nelimitată.

Acest mesaj nu este un flux al tuturor evenimentelor de vânzare sau retur. După acesta, adaptorul citește fișierele gata făcute. Webhook-urile platformei externe sunt primite de propriul handler HTTP al adaptorului.

În scenariul FTP, fișierul de comandă se descarcă local și se șterge de pe FTP, apoi se procesează de program și, după importul cu succes, se șterge local. Dispariția fișierului de pe FTP nu confirmă crearea documentului. Un fișier eronat în directorul local poate împiedica importul ulterior; integratorul verifică jurnalul și documentele.

3. Integrări standard și capacitățile TOM

Pentru aceste scenarii, se utilizează funcțiile Torgsoft sau opțiuni specializate. Proprietarul obține acces la serviciul extern, integratorul configurează modul. Suportul acoperă operațiunile documentate de conectare.

Documentație: integrările Torgsoft, ajutorul programului, extrase bancare.

Module gata făcute Torgsoft Online Market

Torgsoft Online Market, TOM — o platformă de magazin online care lucrează împreună cu Torgsoft. Accesele, plățile, feed-urile și resursele externe sunt configurate în panoul TOM. Integrările sale se referă la datele magazinului și nu creează un API pentru toate documentele Torgsoft.

4. Platforme pentru magazine online

Pentru CMS este nevoie de un modul care mapează articolele site-ului cu produsele Torgsoft, actualizează câmpurile convenite și transmite comenzile noi. Proprietarul oferă acces la magazin și definește stocul. Integratorul pregătește schimbul de fișiere. Dezvoltatorul instalează un conector compatibil sau creează un adaptor pentru API-ul platformei.

Înainte de lansare, stabiliți cine creează cardurile de produse și gestionează descrierile. Pentru un site deja completat, se pot transmite doar prețurile și stocurile. Dacă adaptorul va crea cardurile, are nevoie suplimentar de categorii, caracteristici, variante, fotografii și reguli de publicare.

5. Marketplace-uri și servicii de anunțuri

Prom.ua, Rozetka și Satu.kz sunt discutate printre opțiunile standard. Pentru platformele din acest tabel, este descrisă funcționarea unui adaptor terț. Mai întâi, proprietarul înregistrează contul de vânzător și accesul la operațiunile necesare. Dezvoltatorul verifică permisiunile aplicației, cerințele categoriilor, formatul de preț și cantitate, iar integratorul pregătește schimbul Torgsoft.

Transmiterea doar a articolului, numelui și prețului este suficientă pentru a actualiza o parte din ofertele deja create. Pentru a publica un card nou, sunt necesare toate atributele obligatorii ale platformei. Datele lipsă din fișierul de produse sunt stocate în tabelul de corespondențe sau directoarele adaptorului.

Corespondențe obligatorii pentru marketplace

• Produs: GoodID Torgsoft → SKU vânzător → ID-ul ofertei și variantei sale. Pentru un set se salvează compoziția și regula de recalculare a cantității.
• Depozit: centrul de evidență → warehouse/location/storefront-ul platformei. Vânzările din depozitele marketplace-ului sunt separate de cele proprii.
• Comandă: canal + contul vânzătorului + ID extern → OrderNumber. Numărul se folosește invariabil la toate primirile repetate.
• Preț: valuta, taxele, prețul promoțional și prețul efectiv de cumpărare. Comisionul platformei nu reduce automat suma produselor din comandă.
• Stare: ce statusuri permit importul, rezervarea, plata, expedierea și anularea manuală. Statusurile diferitelor sisteme au propriile semnificații.

6. Cataloage de produse și canale de publicitate

Aceste servicii primesc date despre produse pentru a afișa oferte. Comanda se plasează în canalul de vânzări desemnat, de unde se transmite către Torgsoft. Proprietarul pregătește contul de afaceri și site-ul; dezvoltatorul creează feed-ul sau folosește un modul de magazin gata făcut; marketerul verifică diagnosticul și publicitatea.

Feed-ul se publică integral: dezvoltatorul verifică structura, numărul de poziții și disponibilitatea linkurilor, apoi înlocuiește versiunea de lucru. Un fișier gol sau incomplet este blocat până la clarificarea cauzei, pentru ca serviciul extern să nu retragă din publicare ofertele actuale.

7. CRM și vânzări multicanal

CRM-ul poate uni comenzile de pe site-uri și marketplace-uri. Pentru o astfel de schemă este nevoie de o punte separată între CRM și Torgsoft. Prezența conectorilor către canale în CRM nu configurează automat această punte.

Proprietarul determină sursa stocurilor și ordinea de rezervare. Dezvoltatorul colectează comenzile, salvează canalul sursă și ID-ul, mapează produsele și creează fișierul Torgsoft. Integratorul verifică documentele rezultate. Până când comanda nu este importată și nu a afectat stocul contabil, adaptorul sau CRM-ul o iau în considerare în rezerva convenită a canalului.

Cum se distribuie statusurile

Dezvoltatorul menține un tabel de corespondențe: status CRM, condiția de import, SaleType și acțiunea managerului. De exemplu, o comandă neplătită confirmată poate crea o factură fără expediere. După plata efectivă a unei facturi deja create, managerul sau un mecanism separat suportat înregistrează plata. Importul repetat al aceleiași comenzi ca o factură nouă este exclus.

Anulările și retururile după import ajung în coada de reconciliere. Angajatul responsabil modifică documentele Torgsoft și confirmă finalizarea operațiunii. Automatizarea acestei etape se include doar cu o metodă specifică suportată de lucru cu documentul.

8. Mailing, telefonie și mesagerii

Pentru SMS, Viber, e-mailuri și telefonie, se verifică mai întâi setările standard Torgsoft din secțiunea 3. Pentru platformele de marketing, dezvoltatorul folosește exportul permis de contacte. Proprietarul determină scopul transmiterii, baza legală pentru trimiterea mesajelor și procedura de dezabonare.

Webhook-ul mesageriei este primit de adaptor. Acesta verifică evenimentul, îl salvează în jurnal și răspunde platformei. Fișierul pentru Torgsoft este creat după verificarea comenzii. Acest lucru permite reprocesarea evenimentului fără a recrea documentul.

Binotel este utilizat în cadrul scenariului standard de telefonie. Pentru legarea unui apel cu un CRM sau un bot separat, se definește o rută proprie și drepturi de acces la datele conversațiilor. Numărul de telefon al cumpărătorului nu este un identificator al comenzii sale.

9. Plăți și livrare

9.1. Plata online și extrasul bancar

Modulele TOM pentru LiqPay, Portmone și monobank, precum și extrasele bancare standard sunt prezentate în secțiunea 3. Pentru un alt site, furnizorul de plăți este conectat pe partea site-ului. Dezvoltatorul confirmă rezultatul plății, iar integratorul aprobă afișarea acesteia în Torgsoft.

Dacă o nouă comandă este primită deja cu plata integrală confirmată, pentru aceasta se poate conveni SaleType=2. Pentru expedierea contabilă automată, este necesar un scenariu separat aprobat SaleType=3. Dacă factura este deja creată în Torgsoft, o plată ulterioară nu este un motiv pentru a descărca această comandă din nou ca fiind una nouă.

Plățile parțiale, rambursul, comisioanele, returnările și discrepanțele de sumă sunt procesate după reguli separate. Integratorul specifică contul de încasare, managerul reconciliază suma vânzării cu plata, contabilul — cu plata furnizorului. Comisionul reținut și suma primită la bancă nu modifică automat prețul produselor achiziționate.

9.2. Transmiterea datelor de livrare

Documentul de vânzare și avizul de transport (AWB) au destinații diferite. Pentru livrare, proprietarul configurează un cont la transportator. Dezvoltatorul transmite datele adresei și identificatorii externi; integratorul determină unde se creează AWB-ul și cum îl vede angajatul în Torgsoft.

Câmpurile Nova Poshta care trebuie mapate

În NewPostDeliveryOptions, se transmit RecepientType, Numele complet și telefonul. Pentru livrarea la sucursală se utilizează WarehouseRef sau orașul și numărul sucursalei. Dacă se transmite WarehouseRef, orașul și numărul sucursalei nu sunt necesare pentru această căutare. Pentru livrarea la adresă se completează câmpurile corespunzătoare pentru stradă, clădire și apartament.

Dacă este completat DeclarationNumber, celelalte câmpuri din acest bloc sunt ignorate: se utilizează AWB-ul (TTN) existent. Încărcarea acestuia este prevăzută pentru importul cu un aviz de însoțire a mărfii la ieșire — SaleType 3 sau 4 — sau după generarea unei facturi dintr-o precomandă. Integratorul verifică acest proces în scenariul său.

10. Analitică și automatizare a fișierelor

Către serviciul analitic se transmite un set definit de date: catalog, stocuri, clienți sau un raport exportat. Dezvoltatorul și analistul convin asupra denumirilor câmpurilor, datei instantaneului (snapshot), valutei și perioadei. Fișierul de produse nu se folosește ca sursă pentru istoricul complet al vânzărilor.

Pentru exportul regulat al raportului, integratorul determină separat metoda sa de formare în Torgsoft. Dezvoltatorul nu planifică accesul automat la nicio dată din baza de date doar pe baza prezenței sincronizării de fișiere.

11. Cum să asigurați fiabilitatea, securitatea și mentenanța

11.1. Stocarea mapărilor separat de numele produsului

Dezvoltatorul creează o stocare permanentă a corespondențelor. Numele produsului se poate schimba, iar codul de bare nu este întotdeauna unic pentru toate înregistrările. Înainte de maparea primară, integratorul verifică directorul; coincidențele neaprobate nu sunt unite automat.

11.2. Definirea unei reguli unice pentru stocuri

Integratorul arată dezvoltatorului ce conține exact cantitatea exportată: stocul fizic sau disponibilitatea deja redusă de rezervele luate în calcul. Dezvoltatorul documentează calculul pentru fiecare canal.

Pentru un set format din mai multe produse, dezvoltatorul calculează cantitatea de seturi în funcție de compoziția setului. Pentru un produs fracționar, verifică unitatea de măsură și precizia admisă de platformă. Cantitatea zero înseamnă o acțiune convenită cu disponibilitatea, iar ștergerea cardului se efectuează doar conform unei reguli separate.

11.3. Verificarea comenzii înainte de publicarea fișierului

1. Verificați sursa, contul, ID-ul extern și statusul permis.
2. Găsiți GoodID pentru fiecare poziție. Pentru un SKU necunoscut, trimiteți toată comanda în coada de corectare.
3. Verificați cantitatea, unitățile, valuta, prețurile și reducerile. Calculați totalul și comparați-l cu datele platformei.
4. Conveniți afișarea livrării, a suprataxelor și a cadourilor. Dacă se utilizează un serviciu separat, GoodID-ul acestuia și comportamentul contabil sunt verificate de integrator.
5. Verificați cumpărătorul, adresa și parametrii transportatorului necesari pentru scenariul ales.
6. Selectați SaleType conform tabelului aprobat și generați fișierul de schemă suportat de versiunea bazei de date.

Un fișier cu o poziție omisă sau un produs necunoscut nu se publică ca o comandă parțială fără un proces convenit separat. Datele erorii sunt salvate pentru corectare; după aceasta se utilizează același ID extern.

11.4. Protejarea importului de duplicate

Dezvoltatorul creează o cheie unică «canal + cont + ID extern» în jurnal. Un eveniment repetat actualizează starea acestei înregistrări. Înainte de o nouă publicare, adaptorul verifică dacă fișierul a fost deja trimis și dacă documentul este confirmat în Torgsoft.

Stările practice ale jurnalului: primit → verificat → fișier pregătit → publicat → import confirmat. Erorile și înregistrările ce necesită reconciliere se țin separat. Confirmarea ultimei stări se determină prin mecanismul real disponibil al integrării specifice sau prin verificarea angajatului responsabil.

Acceptarea de către serverul FTP, HTTP 200 și ștergerea fișierului nu sunt considerate o confirmare universală a documentului. După un eșec la limita de transmisie, adaptorul oprește republicarea acestei comenzi până la reconciliere. Valoarea însăși a OrderNumber nu este o garanție documentată de protecție împotriva tuturor importurilor repetate.

11.5. Publicarea doar a fișierelor finalizate

Fișierul de intrare pentru produse se citește după finalizarea generării și verificarea structurii. Mesajul POST, programul sau gateway-ul se utilizează conform rutei configurate. Adaptorul controlează integritatea fișierului și respinge înregistrările incomplete.

Rezultatul adaptorului este mai întâi scris într-un director de serviciu, verificat și apoi publicat ca fișier finalizat. Pentru comenzi, fișierul temporar are o extensie pe care importatorul nu o procesează. Redenumirea se efectuează în cadrul sistemului de fișiere sau printr-un mecanism verificat al serverului; atomicitatea acestui pas este verificată de administrator.

Feed-ul de lucru pentru produse este păstrat până la verificarea cu succes a versiunii următoare. Se compară numărul de produse, proporția de stocuri zero, câmpurile obligatorii și dimensiunea fișierului. Pragurile de anomalii se convin cu proprietarul, astfel încât o retragere planificată a sortimentului să nu fie blocată fără explicații.

11.6. Separarea erorilor și a reîncercărilor

• Autorizare: opriți ruta corespunzătoare, notificați administratorul, reînnoiți accesul conform regulilor platformei.
• Limita API sau indisponibilitate temporară: salvați sarcina și repetați cu o întârziere controlată și respectarea Retry-After, dacă acesta este transmis.
• Date incorecte: trimiteți înregistrarea pentru corectare; nu republicați în mod repetat un fișier eronat nemodificat.
• Rezultat parțial al lotului: citiți răspunsurile pentru fiecare produs și repetați doar operațiunile neexecutate permise.
• Rezultat nedefinit al importului: reconciliați documentul înainte de repetare.

Monitorizarea arată ultima actualizare reușită, vârsta stocurilor, numărul și vârsta comenzilor netransmise, erorile SKU și confirmările întârziate. Proprietarul desemnează un angajat pentru fiecare tip de notificare. O solicitare API cu un cod HTTP de succes este verificată suplimentar pentru erori de afaceri în corpul răspunsului.

11.7. Protejarea acceselor și a datelor cu caracter personal

• Pentru FTP-ul Torgsoft, activați SSL/TLS și verificați criptarea efectivă. Interfețele HTTP externe ale adaptorului funcționează prin HTTPS.
• Păstrați cheile și parolele în setări protejate. Nu le adăugați la URL-urile feed-urilor publice, repository-uri, mesaje și jurnale.
• Emiteți drepturi minime. Utilizați accese separate pentru mediul de producție și pentru teste.
• Verificați semnătura webhook-ului și actualitatea autorizării conform instrucțiunilor furnizorului. Salvați evenimentul într-un depozit de încredere înainte de a confirma acceptarea acestuia.
• Separați directorul public de fișierele clienților, comenzilor, bonusurilor și certificatelor. Limitați perioada de păstrare și accesul angajaților.
• În jurnale mascați datele de contact și de plată inutile. Transmiterea contactelor pentru publicitate trebuie coordonată cu regulile de consimțământ și dezabonare.

11.8. Verificarea lansării manuale și de fundal separat

Administratorul și integratorul verifică versiunea actuală a Torgsoft, serverul de sarcini automate și bibliotecile furnizate pentru această conexiune. Bibliotecile SSL incompatibile nu sunt înlocuite cu DLL-uri întâmplătoare de pe site-uri terțe.

O comandă de control se lansează manual și prin serviciul efectiv. Se verifică utilizatorul serviciului, drepturile, directoarele, setările de limbă și regionale, accesul la rețea și rezultatul după repornire. Importul manual cu succes nu confirmă funcționarea sarcinii de fundal.

După modificarea versiunii programului, a schemei de fișiere, a prețurilor, a modulelor site-ului sau API-ului, testele cheie sunt repetate. Dezvoltatorul menține versiunile adaptorului și ale contractului de schimb; proprietarul determină persoana responsabilă pentru actualizări.

12. Plan de testare și acceptare a integrării

Cele 30 de zile gratuite ale opțiunii pot fi folosite pentru a verifica schimbul cu serviciul ales. Mai întâi, proprietarul configurează accesele și aprobă scenariul; după aceasta, integratorul activează opțiunea, iar dezvoltatorul lansează adaptorul pregătit. Aprobarea aplicației de către platforma externă, tarifele acesteia și dezvoltarea se iau în considerare separat.

Ce trebuie să fie gata înainte de prima lansare

Secvența lucrărilor

1. Verificarea acceselor. Dezvoltatorul execută citirea permisă a catalogului și comenzilor, verifică autorizarea și operațiunile necesare.
2. Testul catalogului. Integratorul exportă produsele de control; dezvoltatorul verifică cardurile noi și cele existente, variantele, prețurile și cantitatea zero.
3. Testul comenzii. Dezvoltatorul transmite fișierul; integratorul verifică cumpărătorul, fiecare GoodID, cantitatea, prețul, valuta și documentele create.
4. Plăți și livrare. Managerul și integratorul verifică tipurile de plată convenite, rezerva, expedierea și AWB-ul (TTN).
5. Eșecuri și repetări. Echipa testează evenimentele repetate, pierderea accesului, un fișier incomplet, un SKU necunoscut și repornirea serviciului.
6. Lansare limitată. Proprietarul admite sortimentul și canalul convenit; echipa observă câteva cicluri complete și reconciliază rezultatul.
7. Acceptare. Proprietarul primește instrucțiunile, jurnalul de teste, accesele la monitorizare și procedura de mentenanță.

Teste de control

Pentru fiecare test, echipa înregistrează în jurnal rezultatul efectiv, ID-ul extern, OrderNumber și documentul Torgsoft. Un exemplu de JSON și verificarea sintaxei acestuia nu înlocuiesc importul în versiunea instalată a programului.

Înainte de transmiterea în lucru, proprietarul primește lista operațiunilor automatizate, a excepțiilor manuale, intervalele de actualizare și responsabilii. Separat, se fixează tarifele platformelor, opțiunile necesare, termenul de suport al adaptorului, procedura de actualizări și recuperare după eșec.