Sincronizzazione di WooCommerce con 1C: gestione commerciale in tempo reale

Circa tre mesi fa mi ha chiamato un conoscente: gestisce un negozio online di prodotti chimici industriali, circa quattromila SKU, due manager, un magazzino nella regione di Mosca. La voce è stanca, in sottofondo si sente qualcuno che impreca nel magazzino. "Ascolta", dice, "ho bisogno di aiuto. Abbiamo venduto di nuovo ciò che era esaurito. Il cliente ha pagato, l'ordine è stato elaborato e lo scaffale era vuoto. Questa è la terza volta in una settimana. Il direttore dice che in 1C i saldi sono stati aggiornati ieri sera, ma sul sito web risulta ancora in stock. Rovinerò l'attività in questo modo." Gli ho chiesto come hanno impostato la connessione tra 1C e il sito web. Si è scoperto che si trattava di uno schema standard: caricamento tramite CommerceML una volta al giorno, di notte, secondo un programma. Se sei fortunato, lo scambiatore non si bloccherà, il file verrà analizzato e i prodotti verranno aggiornati. Se sei sfortunato, e non lo sei regolarmente, i manager scoprono al mattino che metà dei prezzi sono vecchi, non ci sono nuovi articoli e per qualche motivo i prodotti rimossi sono tornati sul sito.

Questa storia non fa eccezione. Direi addirittura che questa è la regola. Ogni secondo proprietario di un negozio online in Russia che tiene i registri in 1C (e questo, secondo varie stime, dal settanta all'ottanta per cento) prima o poi affronta il fatto che la sincronizzazione dei dati tra il sistema contabile e il sito si trasforma in un mal di testa separato. Non un compito secondario, ma un problema che consuma tempo, nervi e denaro. E ciò che è più offensivo è che questo problema è stato risolto tecnicamente già da tempo. È solo che la stragrande maggioranza utilizza ancora strumenti vecchi di quindici anni, perché “beh, in qualche modo funziona” e “c’è qualcos’altro?”

Sì, esiste. E voglio parlare in dettaglio di come abbiamo affrontato questo compito durante lo sviluppo del modulo di integrazione 1C nel nostro plugin COS WP Woo, del motivo per cui abbiamo scelto un percorso fondamentalmente diverso e di cosa questo ha offerto in pratica ai nostri clienti. Non sotto forma di opuscolo pubblicitario, ma onestamente, con il rastrello che abbiamo raccolto, con soluzioni che si sono rivelate non ovvie e con risultati misurabili.

Perché CommerceML è un protocollo del secolo scorso

Dirò ora una cosa che può sembrare categorica, ma sono convinto della sua correttezza: CommerceML come formato di scambio dati tra 1C e un negozio online è diventato obsoleto circa dieci anni fa. È stato progettato all'inizio degli anni 2000, quando un negozio online era una vetrina con un catalogo e un pulsante “ordina”, l'aggiornamento dei cartellini dei prezzi una volta alla settimana era considerata la norma e l'idea della sincronizzazione in tempo reale sembrava un capriccio. Poi CommerceML ha risolto perfettamente il problema: ha generato un file XML con prodotti e prezzi, lo ha messo in una cartella su FTP, il CMS lo ha preso, lo ha analizzato e ha aggiornato il catalogo. Semplice, affidabile, comprensibile.

Ma il mondo è cambiato. Oggi il cliente si aspetta che se vede “5 pezzi in stock” sul sito, allora ci sono davvero cinque pezzi in stock. Non erano lì ieri, non erano lì tre ore fa, ma proprio adesso. Perché allo stesso tempo lo stesso prodotto può essere venduto attraverso un altro canale: attraverso il gestore che ha effettuato l'ordine telefonicamente, attraverso il marketplace, attraverso un punto vendita. E se la tua sincronizzazione funziona una volta ogni ora (o, come il mio amico, una volta al giorno), stai vendendo aria. E poi chiama il cliente e dì: "Siamo spiacenti, si è verificato un errore, non c'è prodotto, restituiamo i tuoi soldi". Ciascuna di queste chiamate non è solo una vendita persa. Questa è una fiducia infranta. Questa è una recensione negativa. Questo è un cliente che non verrà più da te.

Conosco aziende che impiegano una persona separata, in realtà un "responsabile della sincronizzazione", che controlla ogni mattina se lo scambio è andato a buon fine, corregge manualmente gli errori, chiama il dipartimento 1C e si occupa delle merci duplicate. Questo, per un secondo, è uno stipendio da quaranta a sessantamila rubli al mese. Solo per garantire che i dati da un sistema fluiscano correttamente in un altro. Assurdo? No, questa è la realtà di migliaia di negozi online russi.

Elenchiamo onestamente i problemi di CommerceML che ho riscontrato personalmente, in progetti reali e non in discussioni teoriche. I prodotti duplicati sono un classico del genere. CommerceML identifica i prodotti in base al GUID interno di 1C e, se qualcosa è andato storto con il tuo database, se hai ripristinato un backup, se 1C ha rifatto la directory degli articoli, tutto qui, i GUID sono scomparsi, sul sito appaiono dei duplicati. Anche la perdita di immagini è una storia comune: CommerceML trasferisce immagini come allegati binari in XML e, con una directory di grandi dimensioni, il file di scambio cresce fino a centinaia di megabyte, PHP si blocca a causa di un timeout o di memoria insufficiente durante l'analisi. L'impossibilità di trasferire campi personalizzati è un'altra seccatura: se il tuo prodotto in 1C ha venti dettagli aggiuntivi (viscosità, punto di scorrimento, certificati, approvazioni del produttore), lo scambiatore CommerceML semplicemente non sa cosa farne. Massimo: scaricherà la "descrizione" in un campo di testo. E, forse, la cosa più spiacevole: se lo scambio si interrompe a metà (e con un catalogo di grandi dimensioni ciò accade sempre), ottieni un catalogo semi-aggiornato, dove alcuni prodotti hanno nuovi prezzi e altri hanno vecchi prezzi. E nessun registro, nessun modo per capire cosa è stato aggiornato esattamente e cosa no.

Quando ho capito tutto questo dalla mia esperienza - e ho sperimentato l'integrazione di 1C con il sito in diversi progetti negli ultimi anni - ho capito che era necessario un approccio fondamentalmente diverso. Non “CommerceML migliorato”, non “CommerceML v2 con le stampelle”, ma un’architettura di scambio dati completamente diversa.

OData: quando 1C parla HTTP

E qui arriviamo a una tecnologia che, in senso stretto, esiste in 1C da molto tempo - dalla versione 8.3 - ma che per qualche motivo la stragrande maggioranza degli sviluppatori di negozi online ignora ostinatamente. Sto parlando dell'interfaccia OData che 1C fornisce immediatamente. Il punto è semplice: il tuo database 1C diventa un server API REST. Puoi accedervi tramite HTTP, ricevere dati in formato JSON, filtrare, ordinare, impaginare: tutto ciò che è diventato da tempo uno standard nel mondo dello sviluppo web. Nessun file XML su FTP. Nessun “caricamento programmato”. Collegamento diretto, in tempo reale, ai dati live del tuo sistema contabile.

Onestamente, quando ho provato per la prima volta l'interfaccia 1C OData, ho provato una strana sensazione: un misto di gioia e irritazione. Delizia - perché funziona davvero. Effettui una richiesta HTTP GET al tuo 1C e ricevi JSON con prodotti, prezzi, saldi, caratteristiche: tutto ciò che è nel database. Fastidio: perché questa funzionalità esiste da anni e abbiamo lottato con CommerceML per tutto questo tempo. Perché? Penso che per diversi motivi. In primo luogo, OData riguarda la programmazione e non il "premi un pulsante: ottieni un file". Devi comprendere le richieste HTTP, devi essere in grado di lavorare con l'API REST, devi scrivere codice. In secondo luogo, la documentazione 1C su OData, per usare un eufemismo, è tutt'altro che ideale. Prova a trovare una descrizione chiara di come ottenere ulteriori dettagli sull'articolo tramite OData: ci ho dedicato due giorni. In terzo luogo, la maggior parte dei “nick 1C” sono persone che vivono nel mondo 1C e hanno poca idea di come funziona il web moderno. E la maggior parte degli sviluppatori web, di conseguenza, evita 1C come qualcosa di incomprensibile. La connessione tra i due mondi è qualcosa che manca gravemente.

Abbiamo risolto questo problema durante lo sviluppo del modulo 1C in COS WP Woo. L'idea era semplice: creare un ponte che, da un lato, dialogasse con 1C nella sua lingua (interrogazioni OData all'interfaccia standard) e, dall'altro, con WooCommerce nella sua lingua (API WordPress, hook WooCommerce, tabelle personalizzate). E fallo in modo tale che il proprietario del negozio non abbia bisogno di comprendere OData, API REST o richieste HTTP. Ho configurato la connessione e funziona.

Ecco come appare tecnicamente, senza alcuna semplificazione. Il nostro modulo OnecSync si connette all'interfaccia OData di 1C: Trade Management (1C:UT) tramite HTTP standard. L'indirizzo di connessione assomiglia a un normale URL, qualcosa come http://tuo-server/tuo-database/odata/standard.odata. Autorizzazione: autenticazione di base, standard per HTTP. Nessun connettore speciale, oggetto COM, elaborazione dei download: tutto funziona tramite normali richieste HTTP, che WordPress può inviare tramite wp_remote_get/wp_remote_post. Questo è un punto di fondamentale importanza: il tuo hosting non ha bisogno di particolari estensioni PHP, di moduli COM, di librerie di terze parti. Se il tuo WordPress può effettuare richieste HTTP (e può sempre farlo), l’integrazione funzionerà.

I dati che prendiamo da 1C passano attraverso un sistema di componenti. OnecDataFetcher è responsabile della ricezione dei dati grezzi: prodotti, prezzi, saldi, caratteristiche. OnecProductImporter prende questi dati e li converte in strutture WooCommerce: crea o aggiorna prodotti, imposta prezzi, lega categorie e attributi. OnecAttributeMapper è un componente separato che confronta gli attributi 1C (dettagli aggiuntivi dell'articolo) con le tassonomie di WooCommerce. OnecCategoryMapper, di conseguenza, fa lo stesso per le categorie. Tutto questo è racchiuso in un'unica facciata OnecSync, che coordina il lavoro dei componenti e garantisce la transazionalità: se qualcosa va storto nel mezzo di un'importazione, il sistema sa cosa è già stato elaborato e cosa non è ancora stato elaborato.

Diciannovemila prodotti: come funziona nella pratica

Sai, parlare di architettura è una cosa. Ma mostrare come funziona su una directory reale è completamente diverso. Ti parlerò della nostra esperienza, perché abbiamo integrato 1C:UT con WooCommerce per il nostro cliente, un negozio online di lubrificanti con un catalogo di diciannovemiladuecentodue prodotti. Questo non è un piccolo negozio di prova con venti posizioni: è un catalogo industriale a tutti gli effetti con dozzine di categorie, centinaia di marchi e molte caratteristiche per ogni prodotto: viscosità, punto di infiammabilità, punto di scorrimento, approvazioni dei produttori di automobili, certificati di conformità GOST e TU.

La prima cosa che abbiamo riscontrato è stato il volume. Non è possibile scaricare 19.000 prodotti con una sola richiesta. L'interfaccia 1C OData supporta l'impaginazione (parametri $top e $skip), ma anche con l'impaginazione, l'elaborazione simultanea di un tale volume è un'attività che non può essere risolta nell'ambito di una normale richiesta HTTP di WordPress. Il timeout standard di PHP è di trenta secondi, a volte sessanta sull'hosting. E importare diciannovemila beni con caratteristiche, prezzi e saldi richiede minuti, se non decine di minuti.

È qui che entra in gioco Action Scheduler, un sistema di attività in background integrato in WooCommerce. Suddividiamo l'importazione in blocchi di trecento prodotti e impostiamo ogni blocco come attività in background separata. Action Scheduler prende queste attività dalla coda e le esegue in sequenza, ciascuna all'interno della propria richiesta HTTP, con il proprio timeout. Se un blocco cade, quello successivo verrà comunque elaborato. Se il server si riavvia, la coda viene salvata nel database, l'elaborazione riprenderà da dove era stata interrotta. Questa è una differenza fondamentale rispetto all’approccio CommerceML, dove se lo scambio viene interrotto a metà, basta ricominciare da capo. Da noi ogni prodotto ha il proprio stato di lavorazione e quando riprendono le importazioni vengono lavorati solo i prodotti che non sono stati ancora lavorati.

La seconda sfida principale è la mappatura degli attributi. In 1C:UT, un prodotto può avere dozzine di dettagli aggiuntivi e ogni dettaglio ha il proprio tipo, il proprio nome e il proprio insieme di valori accettabili. In WooCommerce, gli attributi sono tassonomie, con il proprio sistema di slug, term_id e altre caratteristiche di WordPress. Legarli l'uno all'altro con le mani è un lavoro che richiede giorni, se non settimane. Pertanto, abbiamo effettuato la mappatura automatica (auto-discover): quando ti connetti per la prima volta a 1C, il modulo analizza tutti i dettagli aggiuntivi dell'articolo e crea automaticamente le tassonomie corrispondenti in WooCommerce. Nel nostro caso reale, su quattrocentonovanta attributi 1C, novantanove sono stati automaticamente mappati su centoventuno tassonomie WooCommerce. La differenza nei numeri è spiegata dal fatto che alcuni attributi 1C sono suddivisi in diverse tassonomie WooCommerce (ad esempio, le "Approvazioni del produttore" da 1C si trasformano in tassonomie separate per ciascun produttore). Gli attributi rimanenti non sono stati mappati deliberatamente: si tratta di dettagli del servizio 1C che non hanno significato sul sito.

Ricordo la prima volta che abbiamo lanciato l'importazione completa in tempo reale. Mi sono seduto e ho aggiornato la pagina del dashboard ogni trenta secondi, guardando il contatore dei prodotti lavorati crescere: trecento, seicento, novecento... Quando ha raggiunto i tremila, mi ero già rilassato: era diventato chiaro che il sistema era stabile, non c'erano errori, ogni pezzo veniva elaborato in sette-dieci secondi. Mancava circa un'ora alla fine. Sono andato a bere un caffè. Quando sono tornato, diciannovemiladuecentodue prodotti erano in WooCommerce, con prezzi, saldi, categorie e attributi. Non un solo duplicato, non una sola immagine perduta (beh, a dire il vero, le immagini erano una storia a parte, di cui vi racconterò più avanti), non un singolo prodotto con il prezzo sbagliato. Sai, vale la pena scrivere codice per momenti come questi.

Ma l'importazione è solo metà del compito. Importare merci una volta è come trasferirsi in un nuovo appartamento: il lavoro principale è ancora avanti. Successivamente, è necessario mantenere aggiornati i dati. Ogni giorno in 1C i prezzi cambiano, le merci arrivano al magazzino, le merci lasciano il magazzino, compaiono nuovi articoli, alcuni vengono interrotti. E tutti questi cambiamenti dovrebbero riflettersi sul sito, non in un giorno o in un'ora, ma idealmente in pochi minuti.

Modello webhook: lascia che sia 1C stesso a dirti cosa è cambiato

È qui che arriviamo a una delle decisioni chiave sull'architettura che distingue il nostro approccio dal novanta per cento delle integrazioni esistenti. La maggior parte dei plugin di sincronizzazione funziona secondo il principio del polling: ogni N minuti (cinque, dieci, trenta, sessanta) WordPress invia una richiesta a 1C e controlla se è cambiato qualcosa. È come se chiamassi il magazzino ogni cinque minuti e chiedessi: "Bene, hai portato qualcosa di nuovo?" Dopo dieci chiamate di questo tipo, il negoziante smetterà di rispondere al telefono e avrà ragione.

Il problema con l'approccio polling è la scala. Se hai mille prodotti, controllarli tutti ogni cinque minuti è un onere relativamente piccolo. Ma cosa succede se hai ventimila prodotti? Centomila? Ad ogni iterazione del polling, il tuo WordPress invia dozzine di richieste a 1C, 1C le elabora, restituisce i dati, WordPress li confronta con ciò che è nel database - e nel novantacinque per cento dei casi scopre che nulla è cambiato. Tutto questo scambio di dati è inutile. Questo è il carico sul server 1C, il carico sull'hosting WordPress, traffico sprecato, risorse del server sprecate. E con tutto ciò, c'è un ritardo fino a cinque minuti tra un cambiamento reale in 1C e la sua riflessione sul sito. Per molte aziende questo è fondamentale.

Abbiamo preso una strada diversa. Il nostro modulo implementa un modello webhook: 1C stesso notifica al sito le modifiche. Si è verificata una modifica nel prezzo di un prodotto: 1C invia una richiesta HTTP al tuo sito Web con informazioni su quale prodotto è cambiato e cosa è cambiato esattamente. Una spedizione è arrivata al magazzino: 1C invia un webhook con i saldi aggiornati. È stato creato un nuovo prodotto: 1C lo segnala al sito. Il sito riceve una notifica ed elabora solo i prodotti che sono effettivamente cambiati. Nessuna ricerca a vuoto di ventimila posizioni. Nessun carico su 1C da richieste costanti.

Capisco che uno sviluppatore 1C esperto potrebbe ora avere una domanda: "Come viene implementato sul lato 1C?" Questa è una domanda valida e rispondere è uno dei momenti in cui è necessario essere onesti riguardo alle complessità. L'interfaccia 1C OData pronta all'uso non supporta gli abbonamenti webhook nello stesso modo in cui è implementata, ad esempio, in Stripe o GitHub. Per un modello webhook completo, sono necessarie modifiche sul lato 1C: sottoscrizione agli eventi e invio di una richiesta HTTP quando i dati cambiano. Ciò può essere implementato tramite abbonamenti a eventi, tramite processi in background, tramite estensioni di configurazione. Il nostro modulo OnecWebhookHooks sul lato WordPress riceve queste notifiche e le elabora. Sul lato 1C, forniamo l'elaborazione che configura l'invio di webhook. Sì, ciò richiede una certa configurazione sul lato 1C, ma si tratta di una configurazione una tantum che qualsiasi specialista 1C competente può eseguire in un paio d'ore.

Per quei casi in cui il modello webhook è impossibile (ad esempio, il client non vuole o non può modificare 1C), abbiamo un fallback: il componente OnecStockSync, che funziona secondo una pianificazione, ma lo fa in modo più intelligente rispetto al normale polling. Invece di esaminare tutti i prodotti, richiede a 1C solo le modifiche per l'ultimo periodo. OData supporta il filtraggio per data di modifica: interroghiamo solo i record che sono cambiati dall'ultima sincronizzazione. Questo è molto più efficace di una ricerca completa: invece di ventimila prodotti, vengono elaborati da dieci a venti che sono effettivamente cambiati.

Ma lascia che ti parli di un'altra cosa che sembra una piccola cosa, ma che in pratica fa risparmiare un'enorme quantità di nervi: una tabella di mappatura. Quando colleghi due cataloghi - in 1C e in WooCommerce - hai bisogno di un modo affidabile per determinare quale prodotto in 1C corrisponde a quale prodotto sul sito. Sembrerebbe che il compito sia banale: prendiamo l'articolo, troviamo il prodotto in entrambi i sistemi e il gioco è fatto. Ma in pratica tutto è più complicato. Gli articoli possono differire nell'ortografia (spazi, maiuscole e minuscole, caratteri speciali). Alcuni prodotti potrebbero non avere numeri di articolo. Un prodotto in 1C può avere più articoli (principale e fornitore). Potrebbe non esserci alcun articolo, solo un nome e un codice interno.

Pertanto, abbiamo creato una tabella di mappatura separata - wpaic_1c_map - che memorizza la relazione tra i prodotti 1C e WooCommerce. La connessione può essere per articolo, per UUID (Ref_Key in 1C), per codice a barre o per abbinamento manuale. Quando si importa per la prima volta, il sistema tenta di abbinare automaticamente i prodotti per SKU. Quelli che non possono essere mappati automaticamente possono essere mappati manualmente nell'interfaccia di amministrazione. Una volta installata, la mappatura viene salvata per sempre: durante le successive sincronizzazioni, il sistema sa esattamente quale prodotto 1C corrisponde a quale prodotto WooCommerce e lo aggiorna senza ricerche e confronti inutili. Nel nostro caso con diciannovemila prodotti, la migrazione della mappatura (dal vecchio plugin che memorizzava la relazione nel postmeta) ha richiesto diversi minuti, dopodiché ogni sincronizzazione avviene senza intoppi: il sistema non "indovina" la corrispondenza, ma la prende dalla tabella.

E ora parliamo di qualcosa che a prima vista sembra contraddittorio: la protezione SEO durante l'importazione. Sembrerebbe che se sincronizziamo i dati da 1C, sincronizziamo tutto: nome, descrizione, prezzo, saldi, caratteristiche. Ma in pratica questo è un errore catastrofico. Il nome del prodotto in 1C è un nome interno per la contabilità, spesso illeggibile: "Olio motore sintetico. Shell Helix HX8 5W30 A3/B4 tanica da 4 l." Sul sito web, lo stesso nome è ottimizzato per la ricerca e la percezione umana: "Olio motore Shell Helix HX8 5W-30 - sintetico, 4 litri, approvazione A3/B4". Se durante ogni sincronizzazione il nome 1C sovrascrive il nome del sito: addio ottimizzazione SEO. Addio a tutto il lavoro svolto dal marketer per migliorare i titoli. Addio alle parole chiave negli slug URL indicizzati da Google e Yandex.

Pertanto, il nostro modulo dispone di update_fields personalizzati, un elenco di campi che vengono aggiornati durante la sincronizzazione. Per impostazione predefinita, vengono aggiornati solo i prezzi e i saldi: ciò che realmente deve essere aggiornato in tempo reale. Il titolo, la descrizione e lo slug sono protetti dalla sovrascrittura. Se vuoi aggiornare anche loro, devi abilitarlo esplicitamente nelle impostazioni. Ma ti avvisiamo: se hai dedicato del tempo all'ottimizzazione SEO delle schede prodotto, non abilitare gli aggiornamenti di titolo e descrizione durante la sincronizzazione con 1C. Lascia che il sistema contabile gestisca ciò che gestisce bene: prezzi e saldi, e il contenuto del sito rimane sotto il controllo del professionista del marketing.

Variazioni, caratteristiche e principali insidie di 1C

Un argomento separato e molto non banale riguarda le variazioni del prodotto. In WooCommerce, una variazione è un prodotto variabile con varianti secondarie, ciascuna con i propri attributi, prezzo e saldo. Un tipico esempio: una maglietta con una scelta di taglia e colore. In 1C, un analogo delle variazioni sono le caratteristiche dell'articolo: una directory subordinata che è legata al prodotto (o al tipo di articolo) e descrive specifiche varianti di esecuzione.

Ed è qui che inizia il divertimento. La struttura delle caratteristiche in 1C:UT è forse uno degli aspetti più non banali dell'intera integrazione. Le caratteristiche possono essere legate ad un prodotto specifico (Ref_Key dell'articolo), oppure possono essere comuni all'intera tipologia di articolo (Type of Item_Key). Cioè, se si dispone del tipo "Oli motore" e questo tipo ha le caratteristiche di "Volume" definite (1L, 4L, 5L, 20L, 208L), tutti i prodotti di questo tipo ereditano queste caratteristiche. Ma un prodotto specifico può avere caratteristiche proprie che non sono correlate alla tipologia. Abbiamo implementato quella che io chiamo “ricerca doppio proprietario”: quando si importa un prodotto, il sistema controlla le caratteristiche prima tramite Ref_Key del prodotto stesso, poi tramite Item Type_Key. Questo copre entrambi gli scenari.

Altro dettaglio non banale: la directory subordinata Catalog_CharacteristicsNomenclature in 1C non supporta i parametri OData standard $select e $filter. Lo abbiamo scoperto sperimentalmente: una richiesta con $filter restituisce HTTP 400 e la documentazione 1C non avvisa da nessuna parte di questo. La soluzione è scaricare interamente tutte le caratteristiche e filtrarle sul lato PHP. Non è perfetto in termini di prestazioni, ma funziona in modo affidabile e per noi l'affidabilità è più importante dell'eleganza.

Ho pensato a lungo se valesse la pena parlare di tali sfumature tecniche in un articolo destinato a un pubblico aziendale. Ho deciso che ne valeva la pena, per un semplice motivo. Quando scegli un plugin per sincronizzare 1C e WooCommerce, ti viene detto: "Abbiamo l'integrazione con 1C!" Ma l’integrazione è diversa. Un'integrazione può trasferire nomi e prezzi. L'altro funziona completamente con caratteristiche, variazioni, prezzi multipli, saldi di magazzino e attributi personalizzati. E la differenza tra loro è la differenza tra "il nostro sito mostra in qualche modo i dati di 1C" e "il nostro sito riflette pienamente la realtà del sistema contabile e possiamo fidarci di esso".

Lascia che ti parli di un'altra trappola che abbiamo scoperto già in produzione, con dati reali e clienti reali. Deduplicazione durante l'importazione di merci con caratteristiche. Immagina: in 1C c'è un prodotto "Shell Helix HX8 5W-30 Oil" con caratteristiche (variazioni) in volume: 1 litro, 4 litri, 20 litri. Ma storicamente, sul sito web di WooCommerce, questo prodotto non era elencato come un prodotto variabile, ma come tre semplici prodotti separati: “Shell Helix HX8 5W-30 Oil (1 l.)”, “Shell Helix HX8 5W-30 Oil (4 l.)”, “Shell Helix HX8 5W-30 Oil (20 l.)”. Questa è una situazione molto comune: molti negozi inizialmente elencavano i prodotti come una "lista piatta", senza variazioni. Se, durante l'importazione da 1C, creiamo un prodotto variabile “Shell Helix HX8 5W-30 Oil” con varianti, sul sito saranno presenti duplicati: sia i vecchi prodotti “piatti” che uno nuovo e variabile. Con URL diversi, con peso SEO diverso, con potenziali conflitti nel carrello.

Abbiamo risolto questo problema attraverso un controllo preliminare: prima di importare un prodotto con caratteristiche, il sistema controlla se sul sito sono presenti prodotti confezionati con il nome corrispondente. Se viene trovata una corrispondenza, il prodotto principale non viene importato come duplicato, ma viene collegato alle posizioni esistenti. È una piccola cosa, ma una piccola cosa che previene seri problemi su siti con una lunga storia di contenuti.

Ora parliamo dello scambio bidirezionale, la parte che molte persone dimenticano. La sincronizzazione non è solo “da 1C al sito”. Anche questo è “dal sito in 1C”. Quando un cliente effettua un ordine sul sito web, questo ordine deve entrare in 1C per un'ulteriore elaborazione: emissione di una fattura, prenotazione di merci, generazione di documenti di spedizione. Il nostro modulo OnecOrderHooks intercetta gli eventi WooCommerce - creazione di ordini, modifica di stato, pagamento - e genera i documenti corrispondenti in 1C. Ordine sul sito web = ordine dell'acquirente in 1C:UT. Pagamento sul sito = ricezione dei fondi. Ciò evita ai manager di trasferire manualmente gli ordini, lavoro che richiede diverse ore con cinquanta ordini al giorno.

So che molte persone sono preoccupate per il problema della sicurezza: se apriamo l'interfaccia 1C OData per le richieste HTTP, il database diventa vulnerabile? Questa è una preoccupazione legittima e la prendiamo sul serio. Per una connessione OData, viene creato un utente 1C separato con diritti minimi, che legge solo le directory e i registri necessari per la sincronizzazione. Questo utente non può modificare la configurazione, eliminare dati o eseguire codice arbitrario. La connessione può essere limitata dall'IP, consentendo l'accesso solo dall'indirizzo IP del tuo hosting WordPress. Tutti gli scambi possono essere effettuati tramite HTTPS, quindi i dati vengono crittografati durante il transito. Infine, l'utente OData dispone di un meccanismo di blocco per più tentativi di autenticazione falliti: protezione contro la forza bruta della password. A proposito, lo abbiamo riscontrato in pratica: durante il debug abbiamo commesso un errore con la password un paio di volte e l'account OData è stato bloccato per quindici minuti. È spiacevole, ma è un vantaggio per la sicurezza.

E visto che parliamo di cose pratiche, parlerò del logging. Questo è ciò che distingue uno strumento professionale da uno artigianale. Ogni operazione di sincronizzazione - ogni richiesta a 1C, ogni prodotto elaborato, ogni errore - viene registrata nella tabella wpaic_1c_sync_log. Nella dashboard del modulo puoi vedere la cronologia completa: quando è stata l'ultima sincronizzazione, quanti prodotti sono stati elaborati, quanti errori e quali prodotti hanno causato problemi. Se il manager chiama e dice "il prodotto X ha il prezzo sbagliato": apri il registro, trovi questo prodotto, vedi quando è stato aggiornato l'ultima volta, quale prezzo proviene da 1C e capisci qual è il problema. Senza registrazione, qualsiasi integrazione è una scatola nera: i dati vanno da qualche parte, provengono da qualche parte e, se qualcosa va storto, puoi solo indovinare in quale fase si è verificato l'errore.

Ricordo che, in una delle prime fasi dello sviluppo, lanciammo la sincronizzazione senza registrazione dettagliata e due giorni dopo scoprimmo che duecento prodotti avevano prezzo zero. Si è scoperto che in 1C per questi beni il prezzo era registrato nel registro "Prezzi articolo" con il tipo di prezzo "Al dettaglio" e abbiamo richiesto il tipo "Prezzo al dettaglio SITO" (così veniva chiamato nelle impostazioni). Duecento prodotti che non avevano un record con il tipo di prezzo richiesto hanno ricevuto uno zero. Se avessimo avuto un log, avremmo visto l’avviso “prezzo non trovato per il prodotto X” e avremmo capito il problema in cinque minuti e non in due giorni. Dopo questo incidente, abbiamo reso la registrazione quanto più dettagliata possibile, con avvisi per ogni situazione anomala. Ora il sistema avvisa sui prodotti senza prezzo, sui prodotti senza categoria, sui prodotti con saldo zero, sulle incoerenze nella mappatura, su tutto ciò che potrebbe rappresentare un potenziale problema.

Quindici minuti prima della prima importazione: procedura guidata per le impostazioni

Una delle cose di cui sono particolarmente orgoglioso è il Mago. Ho pensato a lungo al motivo per cui l'integrazione con 1C è considerata "un compito complesso che richiede un programmatore". E sono giunto alla conclusione che non è una questione di complessità tecnica in sé, ma di come questo compito viene presentato all'utente. Un'istruzione tipica per la configurazione di 1C e dello scambio WooCommerce è un documento di dieci pagine con i termini "URL di pubblicazione di Infobase", "Parametri del servizio HTTP", "impostazione di un piano di scambio". Una persona che non è uno sviluppatore 1C chiude queste istruzioni nella seconda pagina.

Abbiamo creato una procedura guidata passo passo che guida l'utente attraverso l'intero processo di configurazione. Il primo passo è inserire l'indirizzo e le credenziali del server 1C. Il sistema controlla la connessione e mostra: "Connessione stabilita. Base: Gestione commerciale, versione 11.5.16, organizzazione: LLC "La tua azienda". Il secondo passaggio consiste nel selezionare un catalogo prodotti e un tipo di prezzo. Il sistema mostra i cataloghi disponibili e le tipologie di prezzi da 1C, l'utente seleziona quelli di cui ha bisogno. Il terzo passaggio è l'impostazione della mappatura: il sistema abbina automaticamente i prodotti per articolo e mostra il risultato. Il quarto passaggio consiste nel selezionare i campi per la sincronizzazione e nell'impostare una pianificazione. E il quinto passo è un giro di prova su dieci prodotti per assicurarsi che tutto funzioni correttamente. L'intero processo dura dai dieci ai quindici minuti. Non dieci ore, non tre giorni, quindici minuti. A condizione, ovviamente, che tu abbia già configurato l'interfaccia OData sul lato 1C. Se non è configurato, è un’altra mezz’ora di lavoro per l’amministratore 1C; forniamo istruzioni dettagliate per questo.

Sapete cosa ho notato in pratica? La domanda più comune quando si configura l'integrazione non è tecnica. Non “come configurare OData” e non “come mappare gli attributi”. La domanda più comune: "Sei sicuro che sul sito non si romperà nulla?" Le persone temono che l’integrazione sovrascriva i dati esistenti, rompa il catalogo ed elimini i prodotti. E questo è un timore comprensibile: molti hanno avuto esperienze negative con CommerceML, quando dopo uno scambio fallito hanno dovuto ripristinare il database da un backup. Ecco perché abbiamo creato diversi livelli di protezione. Modalità "Sola visualizzazione" (esecuzione di prova): il sistema mostra cosa verrà fatto, ma non apporta modifiche. Testa l'importazione su dieci prodotti per assicurarti che la mappatura sia corretta. La protezione contro la sovrascrittura dei campi SEO è disabilitata per impostazione predefinita. E, naturalmente, registrando ogni azione in modo che se succede qualcosa puoi tornare indietro.

Sento spesso dai concorrenti: "Il nostro plugin fa la stessa cosa." Permettimi di non essere d'accordo. Quando acquisti un "plug-in di integrazione 1C e WooCommerce", guarda attentamente cosa fa effettivamente. Supporta OData o funziona solo tramite CommerceML? Elabora le caratteristiche degli articoli e crea varianti o importa solo articoli semplici? Esiste un rilevamento automatico degli attributi o è necessario registrare manualmente la corrispondenza di ciascun campo? Come vengono gestiti gli errori: vengono inghiottiti silenziosamente o registrati con i dettagli? Esiste una protezione dalla duplicazione? Funziona la sincronizzazione inversa (ordini dal sito web in 1C)? Tutte queste domande non sono “belli extra”, ma requisiti fondamentali per la normale integrazione.

Sapete cosa mi sorprende di più di questa storia? Quanto tempo e denaro le aziende spendono per risolvere un problema tecnicamente risolto. L'interfaccia 1C OData esiste da molti anni. WordPress può effettuare richieste HTTP fin dal primo giorno. WooCommerce fornisce hook per la creazione e l'aggiornamento dei prodotti. Action Scheduler risolve il problema dei grandi volumi. Tutti i mattoncini sono a posto da molto tempo: devi solo assemblarli correttamente. Ma “corretto” è la parola chiave. Correttamente significa tenere conto delle caratteristiche reali di 1C (e non di quelle teoriche), con l'elaborazione di tutti i casi limite (duplicati, imballaggi, prezzi mancanti), con protezione da azioni distruttive e con registrazione dettagliata. Questo è esattamente ciò che abbiamo fatto in COS WP Woo.

Tornando al mio amico con un negozio online di prodotti chimici industriali, lo abbiamo aiutato a passare da CommerceML all'integrazione OData. Ci sono voluti due giorni: un giorno per configurare OData sul lato 1C (avevano già uno specialista 1C a tempo pieno) e un giorno per configurare il modulo in COS WP Woo. La prima importazione completa è avvenuta durante la notte: quattromila merci con prezzi e saldi. Successivamente, la sincronizzazione dei saldi ha iniziato a funzionare tramite webhook: una modifica in 1C significa un aggiornamento sul sito in pochi secondi. Nel primo mese dopo la transizione, il numero di situazioni di “venduto qualcosa che non c’è” è sceso da tre o quattro a settimana a zero. Completamente zero. Un manager che prima passava due ore al mattino a controllare lo scambio, ora passa cinque minuti ad aprire il dashboard, assicurarsi che tutto sia verde e mettersi al lavoro. A proposito, lo stesso manager ora elabora gli ordini, un'attività più utile e produttiva della riconciliazione manuale quotidiana dei dati tra due sistemi. Il risparmio solo nel tempo di lavoro è di circa quindici ore al mese, e questa è una stima prudente.

Non sto dicendo che la nostra soluzione sia perfetta. Ha dei limiti. Funziona con 1C: Trade Management (1C:UT), la configurazione più comune per le società commerciali. Se disponi di 1C:Accounting o di un'altra configurazione non standard, saranno necessarie alcune modifiche. L'interfaccia OData deve essere configurata e pubblicata sul lato 1C: si tratta di un'operazione una tantum ma necessaria che richiede un amministratore 1C. Il modello Webhook richiede miglioramenti lato 1C (elaborazione per l'invio di notifiche). Infine, per i cataloghi di grandi dimensioni (più di diecimila prodotti), la prima importazione completa richiede tempo, da trenta minuti a diverse ore, a seconda della velocità del server 1C e del volume dei dati.

Ma tutte queste restrizioni sono risolvibili. E sono incomparabilmente minori rispetto ai problemi che si riscontrano rimanendo su CommerceML: duplicati, perdita di dati, ritardi di un giorno, mancanza di feedback, incapacità di trasferire campi personalizzati. Ho visto abbastanza progetti per dire che l'integrazione di OData tramite uno strumento normale non è un lusso o una "opzione avanzata". Questa è una necessità per qualsiasi negozio online che lavori seriamente con 1C e desideri che il suo sito Web rifletta la realtà e non una sua copia obsoleta.

A volte mi sembra che il problema dell'integrazione di 1C e dei siti Web non sia affatto un problema tecnico. Questo è il problema del divario tra due mondi: il mondo dei sistemi contabili (dove vivono i soprannomi 1C) e il mondo dello sviluppo web (dove vivono gli “sviluppatori di siti”). Ogni mondo conosce i propri strumenti, parla la propria lingua e capisce poco l'altro. CommerceML era il ponte tra questi mondi: goffo, obsoleto, ma comprensibile da entrambe le parti. OData è un ponte di nuova generazione: più veloce, più affidabile, più flessibile, ma richiede che entrambe le parti siano disposte a fare un passo l'una verso l'altra. Il nostro modulo in COS WP Woo è un tentativo di rendere questo passaggio il più semplice possibile. Mago, che ti condurrà per mano. Individuazione automatica, che gestirà gli attributi stessi. Protezione SEO che ti impedirà di rompere ciò che già funziona. E un registro dettagliato che mostrerà cosa succede esattamente durante ogni sincronizzazione.

Se adesso sei seduto e pensi: "Ho quattrocento prodotti, CommerceML può gestirli, perché ho bisogno di tutto questo?" - Risponderò in questo modo. Se la tua attività non cresce, se non aggiungi nuovi canali di vendita, se ai clienti non interessa se i saldi sul sito sono aggiornati, allora non ce n’è davvero bisogno. Ma se hai intenzione di crescere, se il catalogo aumenterà, se hai bisogno di vendere attraverso più canali contemporaneamente (sito web, marketplace, social network) e avere dati aggiornati ovunque, allora il passaggio alla normale integrazione tramite OData non è “se”, ma “quando”. Ed è meglio farlo prima di iniziare a vendere aria e perdere clienti, e non dopo. Perché riconquistare la fiducia di un cliente a cui hai venduto un prodotto inesistente costa molto di più che dedicare due giorni a predisporre una normale integrazione.

Prova COS WP Woo - 14 giorni gratis.Il modulo integrazione 1C è compreso in tutte le tariffe. La procedura guidata di configurazione ti porterà dall'installazione del plug-in all'importazione dei prodotti per la prima volta in quindici minuti. Non è richiesta alcuna conoscenza speciale: se hai 1C: Trade Management e WooCommerce, tutto funzionerà. E se hai domande, il nostro team ti aiuterà con la configurazione di OData sul lato 1C e con la prima importazione.