Ai 1C în contabilitate și un magazin online. Amândouă cred că știu ce stoc ai. Cineva le împacă manual, de obicei seara, de obicei greșit.
Integrarea nu e grea din punct de vedere tehnic. E grea fiindcă începe cu o întrebare la care nu răspunde un programator.
Întrebarea care se pune prima
Pentru fiecare câmp, care sistem are dreptate?
Stocul: 1C sau magazinul? Dacă un client cumpără online și în același timp un vânzător scoate marfa din depozit prin 1C, care număr câștigă?
Prețul: se schimbă în 1C și coboară în magazin, sau invers? Ce se întâmplă cu promoțiile care există doar online?
Descrierile și pozele: aproape sigur în magazin, fiindcă 1C nu e făcut pentru ele — dar atunci un produs nou creat în 1C ajunge în magazin fără text, și cineva trebuie să știe că e treaba lui să-l scrie.
Comanda: se creează în magazin și se trimite în 1C, dar statusul ei se schimbă apoi în 1C. Deci pentru comenzi, direcția se inversează la jumătatea drumului.
Asta e o decizie de business înainte să fie una tehnică, iar dacă nu o iei tu, o ia implicit cel care scrie codul — și o va lua greșit, fiindcă nu știe cum lucrează depozitul tău.
Când răspunsurile există, restul e execuție.
Trei căi de intrare, în ordinea preferinței
1. Interfața REST/OData, dacă versiunea o permite
Din platforma 8.3.5, 1C generează singur o interfață REST peste baza ta, pe protocol OData. Nu se programează nimic în 1C: se publică baza pe un server web și se bifează opțiunea în Configurator, la Administrare → Publicare pe serverul web → Publicarea interfeței standard OData.
E varianta cea mai curată: citire și scriere pe obiectele configurației, în timp real, fără fișiere intermediare și fără o a doua copie a datelor care poate rămâne în urmă.
2. Servicii HTTP scrise în 1C
Când interfața standard nu ajunge — vrei o operațiune care înseamnă cinci pași în 1C, nu o citire simplă — se scrie un serviciu HTTP direct în configurație.
Asta cere pe cineva care lucrează în interiorul lui 1C. De obicei partenerul tău 1C, nu noi. E o graniță care merită stabilită de la început: noi ne ocupăm de tot ce e în afara lui 1C, ei de ce e înăuntru.
3. Schimb de fișiere, dacă instalarea e veche
CommerceML e formatul XML standard prin care 1C exportă catalogul, prețurile, stocurile și comenzile. Merge pe instalări unde nici REST-ul nici serviciile HTTP nu sunt disponibile sau nu sunt permise.
E cea mai lentă cale și singura care nu e în timp real: schimbul se face pe program, la câteva minute sau la câteva ore. Pentru stoc, asta înseamnă că vei vinde uneori ceva ce tocmai s-a terminat. Se compensează cu o rezervă — nu arăți online ultimele două bucăți — dar compensarea e o decizie, nu o soluție.
Ce ne trebuie ca să începem
Lista e scurtă și fiecare punct blochează dacă lipsește.
Ce configurație și ce versiune. „1C" nu e un singur produs. Управление торговлей, Бухгалтерия și o configurație modificată de cineva acum șase ani sunt trei lucruri diferite, cu obiecte diferite.
O cale de intrare. Una din cele trei de mai sus. Dacă baza rulează pe o mașină din biroul tău, fără acces din exterior, ne trebuie un VPN sau un agent care iese el în afară.
Deciziile pe câmpuri. Cele de la începutul articolului, scrise. Nu trebuie să fie un document formal, dar trebuie să fie explicit.
O copie de test a bazei. Nu cea vie. Prima rulare a unei integrări scrie lucruri greșite — asta e normal — iar locul unde le scrie contează.
Cineva de partea ta care poate modifica în 1C. Chiar dacă alegem calea care nu cere programare în 1C, va veni un moment când ceva trebuie publicat, un drept trebuie acordat sau un câmp trebuie adăugat.
Ce se strică de obicei
Amândouă sistemele scriu același câmp. Cel mai frecvent, și cel care apare abia în lună a doua: stocul se sincronizează în ambele direcții, iar la o suprapunere de câteva secunde câștigă cine a scris ultimul. Se rezolvă cu regula de la începutul articolului, nu cu cod mai deștept.
1C nu răspunde noaptea. Multe instalări se închid sau se blochează la închiderea de zi. O integrare care presupune că 1C e mereu disponibil va pierde comenzi exact în intervalul în care nu se uită nimeni.
Codurile de produs nu se potrivesc. În 1C produsul are un cod intern, în magazin are altul, iar cineva le-a legat cândva după denumire. Prima redenumire rupe legătura tăcut. Legătura se face pe un identificator stabil, nu pe text.
Prețul cu TVA și fără. 1C ține de obicei prețul fără TVA, magazinul îl arată cu. Dacă cele două nu se pun de acord de la început, diferența apare pe factură, nu în cod.
Cât durează și cât costă
Partea de cod, pentru o sincronizare obișnuită — produse, prețuri, stocuri, comenzi — e muncă de zile, nu de luni.
Ce mărește durata sunt lucrurile din afara codului: obținerea accesului la bază, o configurație modificată în care obiectele nu mai sunt unde ar trebui, și așteptarea deciziilor pe câmpuri. Am văzut integrări în care jumătate din timp a fost consumat de întrebarea „cine deține stocul", pusă abia la mijloc.
Cel mai bun lucru pe care îl poți face înainte să ceri o ofertă e să răspunzi singur la întrebările din primul capitol. Cu ele scrise, oferta pe care o primești e un preț. Fără ele, e o estimare.