15 · Integració amb PrestaShop

◀ Tornar a l'índex

La integració amb PrestaShop permet que Factuzam sigui l'origen dels preus i de l'estoc de la botiga en línia quan se n'autoritza expressament la sincronització. Els canvis s'anoten en una cua i s'envien en segon pla mitjançant l'API directa de PrestaShop.

La integració també pot donar d'alta un article que encara no existeixi a la botiga: famílies, producte, combinacions de talla i color, preus i imatge principal. Tot producte creat per Factuzam comença inactiu a PrestaShop. Només es pot activar al final d'una alta o sincronització correctes si el perfil ho autoritza expressament, o posteriorment de manera manual.

Regla de publicació: marcar En web a Factuzam fa que l'article sigui elegible per a la integració configurada. Amb Activar artículos en PrestaShop al marcar En web desmarcat, no en canvia la visibilitat. Amb la casella marcada, Factuzam sol·licita l'activació únicament com a últim pas, després de completar correctament l'alta o la sincronització autoritzada.

Regla en desmarcar En web: Factuzam pregunta què cal fer. Sí desactiva el producte a PrestaShop i deixa de sincronitzar-lo; No només atura la sincronització i en conserva l'estat remot; Cancelar no desa el canvi. Cap opció esborra el producte, en canvia el preu ni envia estoc zero.

1. Estat de la integració

Aquest capítol s'actualitza a mesura que es completa la integració. Convé distingir què està disponible i què encara requereix implantació i proves.

La integració actualitza el catàleg remot, però no importa automàticament a Factuzam els canvis fets manualment a les fitxes de PrestaShop. Abans d'activar-la cal decidir quin sistema és responsable de cada dada.

L'opció Ventas Mayor ▸ Pedidos ▸ Importar de PrestaShop llegeix l'URL i la clau API efectives de Parámetros del entorno. La finestra no té credencials pròpies ni mostra la clau. L'empresa i el magatzem s'obtenen de la sessió. Si es canvia la configuració amb la finestra oberta, és obligatori tornar a connectar i llistar abans d'importar.

Aquesta reutilització encara és parcial: l'importador no envia l'Id. tienda en consultar orders. S'ha d'utilitzar una clau limitada a una sola destinació i no es considera apte per a multibotiga. El procediment, les columnes, la creació de clients i articles, el servei GASTOS_T i tots els límits operatius es detallen a Ventas Mayor ▸ Pedidos ▸ Importar comandes de PrestaShop.

Situació de validació: encara no hi ha una decisió GO per utilitzar la integració completa en producció. Hi ha evidència parcial del catàleg i de la cua al laboratori, però continuen pendents la bateria completa de comandes, importació, concurrència, servei, escombratge i cicle fins a la factura. Mantén desactivades les escriptures d'estoc absolut i fes les proves únicament contra una instal·lació controlada.

2. Visió general

Cambio en artículo, tarifa o stock
               |
               v
      Cola de PrestaShop
               |
               +---- reference única ----> verifica; actualiza si se autoriza
               |
               +---- ninguna reference --> alta inicialmente inactiva, si se autoriza
               |
               `---- varias reference ---> ERROR inmediato, sin POST

Tras completar sin error el alta o la sincronización
               |
               `---- activación final, solo si N->S y el perfil la autoriza

Les caselles són independents. Sincronizar stock y precios autoritza les modificacions dels productes existents. Crear artículos en PrestaShop al darlos de alta sol·licita actuar quan falta el producte. Activar artículos en PrestaShop al marcar En web permet canviar active a 1 únicament al final del procés iniciat pel pas d'En web de No a Sí. Factuzam valida el conjunt local abans del primer POST i tot producte nou es crea amb active=0. Una referència ambigua sempre és una incidència i mai no provoca una altra alta ni cap activació.

Els esdeveniments són el mecanisme principal. La recuperació de pendents es comprova sempre cada 60 a 120 segons, encara que Hacer barrido periódicamente estigui desmarcat. Aquesta casella només habilita una reconciliació completa, cada cert nombre d'hores, per detectar un canvi que no hagués arribat a la cua a causa d'una incidència o una importació antiga.

Una fila de la cua representa l'article complet. Si canvia el preu d'un SKU, Factuzam torna a calcular l'article i totes les seves combinacions, però només envia una modificació per als recursos el valor remot dels quals sigui diferent.

3. Configuració per àmbit

La configuració es troba a Otros ▸ Parámetros del entorno, dins de PrestaShop. Es desa com els altres paràmetres: es pot definir per a un usuari, per a un grup o per a Todos. El valor efectiu s'obté en aquest ordre:

Configuració efectiva de PrestaShop per àmbit; la clau API i l'URL romanen ocultes.

1. Valor específic de l'usuari.
2. Valor del seu grup, si l'usuari no l'ha definit.
3. Valor de Todos, si tampoc no hi ha un valor de grup.

Un perfil més específic substitueix el general. Així, dues empreses poden utilitzar usuaris o grups amb empreses, tarifes, magatzems i botigues PrestaShop diferents. Cada sessió només processa la seva configuració efectiva; no recorre les configuracions dels altres perfils.

Les dues caselles que autoritzen el manteniment del catàleg neixen desmarcades i es poden combinar així. Activar artículos en PrestaShop al marcar En web i Hacer barrido periódicamente també neixen desmarcades, però no canvien aquesta matriu: la primera decideix la visibilitat al final d'un procés i la segona quan cal cercar divergències completes.

Si el canvi En web ha estat de No a Sí i la casella d'activació està marcada, la petició active=1 s'afegeix després de completar correctament l'acció indicada a la matriu. Si hi ha un error anterior, el producte no s'activa. Amb la casella desmarcada, un producte nou roman inactiu i un producte ja existent conserva la seva visibilitat.

Abans de marcar Sincronizar stock y precios, cal configurar i comprovar expressament l'URL. Una instal·lació nova no pressuposa cap destinació.

Les claus antigues appPrestaShopActivo i appPrestaShopStockActivo, si continuen desades després d'actualitzar una instal·lació, ja no governen el treballador ni activen res de manera implícita. S'han d'utilitzar els controls explícits descrits a la taula anterior.

Si diversos perfils compatibles comparteixen la mateixa instal·lació i botiga però sol·liciten intervals d'escombratge diferents, s'aplica materialment la cadència més freqüent. Tots comparteixen el mateix marcador remot per evitar recorreguts duplicats del catàleg.

La cua separa cada destinació per l'URL normalitzat i l'identificador de botiga. Si es canvia d'una botiga de proves a producció, no es reutilitzen els identificadors remots de la instal·lació anterior. Per a dues empreses amb botigues diferents s'han de configurar destinacions diferents.

Diversos perfils actius poden compartir el mateix URL normalitzat i Id. de botiga quan l'empresa, la tarifa i les opcions de sincronització siguin idèntiques. Cada perfil pot decidir si participa en l'escombratge periòdic. Si el treballador detecta que alguna de les dades funcionals és diferent, considera que la destinació és contradictòria, n'atura el processament i registra un avís. No es reprèn fins que es corregeixin els perfils perquè siguin compatibles o se'ls assignin destinacions diferents.

Permisos de la clau API

La clau només ha de tenir els permisos necessaris:

Els permisos de comandes només són de lectura. Si aquesta funció no s'utilitza, no s'han de concedir. La clau destinada a l'importador ha de quedar limitada a una única botiga mentre la consulta d'orders no apliqui id_shop.

No s'ha de concedir permís d'esborrament tret que es dissenyi i autoritzi una operació administrativa concreta. Una recuperació automàtica no ha d'esborrar mai una categoria, talla o color compartits amb altres productes.

4. Selecció d'articles i magatzems

Articles

A Archivo ▸ Artículos, la casella En web decideix si l'article participa en la integració.

• En marcar-la, s'encua una comprovació completa de l'article.
• Factuzam cerca el producte mestre per coincidència exacta de la seva reference.
• Si existeix una sola coincidència, el verifica i només actualitza el producte i els seus SKU quan està marcat Sincronizar stock y precios.
• Si no n'existeix cap i està autoritzat Crear artículos, valida i executa l'alta completa i inactiva.
• Si la creació no està autoritzada, l'absència acaba en una incidència.
• Si hi ha diverses coincidències, registra una incidència ERROR sense triar-ne cap ni crear-ne una tercera.
• Si la marca passa de No a Sí i està autoritzat Activar artículos en PrestaShop al marcar En web, l'activació només se sol·licita després que acabi correctament l'alta o la sincronització aplicable.
• En desmarcar-la, Factuzam mostra un diàleg abans de desar.

Canviar En web requereix el permís Permisos ▸ Artículos ▸ Activar/desactivar web. Sense aquest permís, la casella queda en només lectura i el desament tampoc no pot modificar la marca.

En desmarcar En web, el diàleg ofereix tres decisions:

• Sí: desa En web = No, deixa de sincronitzar i sol·licita la desactivació remota (active=0).
• No: desa En web = No i només deixa de sincronitzar. El producte roman en l'estat de visibilitat que ja tenia a PrestaShop.
• Cancelar: no desa el canvi; l'article continua En web.

En els dos primers casos es cancel·len els canvis pendents de preu i estoc. La retirada no fa cap altra modificació:

• no s'envia estoc zero;
• no es canvia l'últim preu enviat;
• no s'elimina el producte;
• no s'eliminen combinacions, categories ni imatges.

Si es torna a marcar En web, Factuzam encua una comprovació completa. El preu i l'estoc vigents només s'envien quan el perfil efectiu té marcat Sincronizar stock y precios. L'activació final només se sol·licita quan també està marcat Activar artículos en PrestaShop al marcar En web.

Un SKU d'un article web no s'esborra físicament: es marca com a inactiu a Factuzam per conservar-ne la referència. La integració deixa d'enviar-ne el preu i, amb la sincronització habilitada, envia quantitat zero. PrestaShop no ofereix cap camp active propi a la combinació, per la qual cosa aquesta operació no «desactiva» remotament l'SKU ni l'elimina.

Magatzems

A Archivo ▸ Almacenes, la casella En web selecciona els magatzems l'estoc dels quals se suma per a la botiga en línia. Se'n pot marcar un o diversos, però cada perfil només utilitza els que pertanyen a la seva empresa configurada. Un magatzem marcat d'una altra empresa no participa en aquella destinació.

A més de la marca, el magatzem ha de ser:

• actiu;
• físic;
• de tipus d'ús ESTANDAR.

Els magatzems de tares, dipòsits i altres usos no estàndard en queden fora encara que algú intenti marcar-los. Les altes de magatzems comencen amb la casella desmarcada.

En marcar o desmarcar un magatzem s'encuen els articles afectats per recalcular el total web. No cal recórrer-los manualment des de la pantalla.

5. Cua, esdeveniments, recuperació i escombratge opcional

Els canvis de preus i d'estoc als principals processos de Factuzam criden l'encuador dins de la mateixa unitat de treball sempre que és possible. Diverses crides per al mateix article s'agrupen en una sola fila. Quan l'operació queda confirmada, el mateix procés que ha generat el pendent desperta el consumidor. El senyal és acumulatiu: cent canvis d'un lot provoquen un únic buidatge de la cua, no cent cicles independents. Aquests senyals no reinicien ni ajornen la data límit monotònica de la recuperació. Encara que arribin canvis contínuament, el torn de seguretat continua vencent cada 60–120 segons i no pot quedar bloquejat per l'activitat normal de la cua.

Si l'article canvia mentre s'està enviant, el nou canvi n'incrementa la versió però no allibera la reclamació en curs. En acabar l'enviament anterior, la fila torna a PENDIENTE. Així s'evita que dos treballadors escriguin versions antigues i noves en ordre invers.

En desmarcar En web i triar No, el mateix control de versió deixa buits tots dos indicadors de canvi. Si es tria Sí, a més queda sol·licitada la desactivació remota. Una petició que ja estigués en curs pot acabar; després s'aplica, quan correspongui, la decisió de visibilitat i no es reclamen noves versions de preu o estoc. Cancelar no desa el canvi ni modifica la cua.

Cada 60 a 120 segons sempre es fa una comprovació de recuperació per si un procés s'ha tancat després d'encuar o ha quedat una reclamació interrompuda. La base de dades concedeix aquesta comprovació a una sola instància de Factuzam per destinació. El procés guanyador recupera les reclamacions caducades i buida els pendents; els altres no repeteixen la feina. Desmarcar Hacer barrido periódicamente no desactiva aquest mecanisme. Els senyals rebuts entre dos torns tampoc no en desplacen el pròxim venciment.

Quan Hacer barrido periódicamente està marcat i han transcorregut les hores configurades, una única sessió habilitada executa la reconciliació completa i torna a encuar els articles En web que ho necessitin. Aquest arbitratge és independent del guanyador de la recuperació, perquè un perfil amb la casella desmarcada no impedeixi l'escombratge sol·licitat per un altre perfil compatible. Amb la casella desmarcada no recorre tot el catàleg, però continua rescatant i processant la cua cada 60–120 segons. Una fallada de la reconciliació completa tampoc no impedeix que es continuïn processant els esdeveniments.

Cada sessió només reclama la cua de la destinació resultant del seu perfil efectiu. Les destinacions queden aïllades per URL normalitzat i identificador de botiga.

Abans de buidar la cua, el treballador torna a llegir de la base de dades el perfil efectiu amb l'herència usuari → grup → Todos. Per tant, un canvi o una desactivació desats a l'usuari, el seu grup o Todos arriben als terminals que ja estan oberts sense reiniciar l'aplicació.

Finestra de seguiment

La cua es pot revisar a Otros ▸ Colas de envíos ▸ PrestaShop. La llista mostra la botiga, el codi i el nom de l'article, els indicadors de preu i estoc pendent o reclamat, l'estat, els intents, les dates de pròxim intent, últim canvi i últim enviament, i l'error general de la fila.

Treballs de catàleg amb el seu estat i l'historial d'operacions HTTP de l'article seleccionat.

En seleccionar una fila es mostra el seu historial d'operacions HTTP, amb intent, ordre, mètode, recurs relatiu, codi i text d'estat HTTP, resultat, instant d'inici i durada. En seleccionar una operació es carreguen, sota demanda, les pestanyes Petición, Respuesta del servidor i Error. D'aquesta manera, els cossos extensos no es llegeixen en obrir o recórrer la llista principal.

La pestanya Respuesta del servidor mostra el cos segur registrat per a l'operació HTTP seleccionada.

L'historial es comença a conservar des de la instal·lació d'aquesta versió. Les operacions realitzades anteriorment no es reconstrueixen retroactivament.

L'historial és de diagnòstic. No desa la clau API, capçaleres d'autorització, contingut binari, dades en base64 ni rutes locals completes. En una pujada d'imatge només conserva una descripció segura, com ara el nom, la mida i l'empremta. Els textos que superen el límit d'emmagatzematge es retallen amb una marca visible de truncament.

La finestra és de només lectura i no permet editar, esborrar ni reintentar una fila. Només permet actualitzar la consulta, exportar-la quan existeixi el permís i anar a l'article relacionat. Els permisos separats Consultar, Excel i Ver petición/respuesta controlen l'accés a la llista, l'exportació i el detall, respectivament. Un administrador pot consultar totes les destinacions; els altres usuaris veuen exclusivament la botiga resolta per la seva configuració efectiva.

La graella mostra l'Id. tienda, però no cap etiqueta d'instal·lació. Si se supervisen diverses instal·lacions que reutilitzen el mateix identificador de botiga, aquesta dada per si sola no permet distingir-les; contrasta la destinació efectiva abans d'interpretar o exportar la fila.

Tancament de Factuzam durant un enviament

Si s'intenta tancar Factuzam mentre aquesta instància està processant un article, primer es bloquegen noves reclamacions i s'ofereixen tres opcions:

• Esperar: acaba únicament l'article actual i després tanca.
• Cerrar de todos modos: no interromp a mig fer la petició HTTP que ja està en curs. Espera que retorni, torna a deixar l'article pendent sense consumir cap intent i després tanca.
• Cancelar cierre: manté Factuzam obert, desbloqueja les reclamacions i reprèn el consum de la cua.

El tancament forçat pot trigar fins que acabi l'operació de xarxa actual. La fila alliberada conserva els canvis de preu, estoc o visibilitat i aquesta o una altra instància podrà reclamar-la al cicle següent.

6. Preus de producte i de SKU

PrestaShop desa els preus sense impostos:

• products.price és el preu base del producte;
• combinations.price és l'impacte de la combinació sobre la base;
• el preu efectiu d'un SKU és la suma de tots dos.

Factuzam obté el preu final vigent de la tarifa i l'empresa del perfil efectiu. Si la tarifa inclou IVA, el divideix per 1 + tipus d'IVA / 100 abans d'enviar-lo. En els productes que ja existeixen, la integració actual no canvia ni valida id_tax_rules_group: l'administrador ha de comprovar que la regla fiscal remota sigui correcta. A l'alta s'utilitza l'identificador configurat per al tipus d'IVA local; no n'hi ha prou que tots dos sistemes mostrin el mateix percentatge.

Exemple amb un IVA del 21 %:

No s'ha d'enviar 29,95 directament com a combinations.price, perquè PrestaShop el tornaria a sumar al preu base.

Quan només canvia un SKU, a PrestaShop 9 se'n pot modificar únicament la combinació. Tot i així, Factuzam recalcula i verifica totes les combinacions de l'article. Si canvia el preu base, recalcula tots els impactes perquè els preus efectius dels altres SKU continuïn sent correctes.

Aquest comportament es va verificar a la botiga local PrestaShop 9.1.4 amb un producte de tres combinacions. En modificar únicament un impacte, el preu base i les altres dues combinacions van conservar els seus valors. La prova també va confirmar que combinations.price és un impacte i no el preu final de l'SKU.

7. Alta d'un article inexistent

La casella Crear artículos en PrestaShop al darlos de alta està disponible, comença desmarcada i és independent de Sincronizar stock y precios. Una reference inexistent només inicia l'alta quan aquesta casella està marcada. Una referència ambigua acaba en ERROR i mai no provoca una alta.

L'alta no és una sola petició. El treballador executa aquesta seqüència contra diversos recursos de PrestaShop:

1. Validar totes les dades locals sense crear res encara.
2. Resoldre o crear la ruta de categories de la família sota l'arrel configurada.
3. Resoldre o crear els grups d'atributs, com Color i Talla.
4. Resoldre o crear els valors utilitzats pels SKU.
5. Crear el producte mestre amb active=0.
6. Crear una combinació per cada SKU actiu i triar una sola combinació predeterminada de manera determinista.
7. Pujar una fotografia general real si el producte encara no en té cap.
8. Continuar amb la sincronització del preu i l'estoc només si està autoritzada.
9. Si el procés prové de marcar En web i el perfil ho autoritza, activar el producte únicament després que tots els passos anteriors acabin correctament.

El producte sempre es crea complet i inicialment inactiu. Amb appPrestaShopActivarArticulosAlMarcarWeb=False, roman així fins a la revisió manual. Amb el paràmetre a True, la mateixa tasca el pot activar com a últim pas. Una alta parcial o una sincronització amb error mai no ha de deixar visible el producte.

Validació prèvia

Abans del primer POST s'han de comprovar, com a mínim:

• codi d'article i referències de SKU no buits ni duplicats;
• article, família, tarifa i atributs actius;
• jerarquia de famílies completa i sense cicles;
• nom i descripció vàlids per als límits de PrestaShop;
• preu base vigent i preu efectiu de cada SKU;
• correspondència de l'IVA amb un grup fiscal remot;
• un valor vàlid per cada eix de variació necessari;
• fotografia real registrada, existent i llegible;
• absència inequívoca del producte i de les seves referències a PrestaShop.

Si falta algun requisit, l'article queda en ERROR amb una causa concreta i la validació local evita començar l'alta.

Revisió de l'administrador

L'administrador entra al back office de PrestaShop i comprova:

1. Nom, descripció i categoria.
2. Tipus i regla d'IVA.
3. Talles, colors i combinació predeterminada.
4. Preu final de diverses combinacions, incloses les d'impacte negatiu.
5. Fotografia de portada i imatges per color.
6. Política d'estoc i disponibilitat per a comandes.

Només aleshores activa les categories noves necessàries. Si l'activació automàtica està desmarcada, també activa el producte manualment. Si està marcada, comprova que la tasca hagi acabat sense errors i que el producte només s'hagi fet visible al final.

8. Famílies i categories

A l'alta, la família de Factuzam es transforma en una categoria de PrestaShop. El paràmetre heretable Niveles de familia a crear (0 = todos) (appPrestaShopNivelesFamiliaAlta) determina quina part de la jerarquia local s'exporta:

• 0: tota la jerarquia local, des de l'arrel fins a la família fulla;
• N > 0: els últims N nivells, comptats des de la família fulla cap amunt.

El subconjunt triat es conserva i crea en ordre arrel → fulla: els pares van abans que els fills. La categoria arrel configurada a PrestaShop només és el punt remot sota el qual es penja el subconjunt i no compta com un d'aquests nivells. Per exemple, DEMO-CAMISA només pertany a la família local ROPA; per tant, 0, 1 o qualsevol valor superior només exporten aquest nivell local.

Una categoria ja existent conserva el seu estat. A la implementació actual, les categories noves es creen actives. El producte es crea amb active=0 i només es pot activar posteriorment, com a últim pas, segons el paràmetre d'activació.

La identitat no es pot basar només en el nom. Dues branques poden contenir una categoria amb el mateix nom. La implementació cerca la combinació de pare i enllaç normalitzat abans de crear:

tienda + categoría padre + enlace normalizado -> id_category remoto

El producte utilitza la família fulla com a id_category_default i també la inclou entre les associacions de categories. La categoria arrel sota la qual s'exporten les famílies ha de ser configurable a cada botiga.

9. Talles, colors i combinacions

Els atributs locals d'una variació es converteixen així:

Cada combinació conservarà com a reference el codi exacte de l'SKU local i associarà tots els seus valors, per exemple Color: Azul i Talla: L. Només es crearan SKU actius. Després es marcarà com a predeterminada una única combinació: la primera segons l'ordre estable d'atributs i referència.

Les talles i els colors són recursos compartits. Abans de crear es cerca el grup o valor remot corresponent. Si hi ha diverses coincidències i no es pot saber quina és la correcta, l'alta s'atura perquè es revisi en lloc de triar-ne una a l'atzar.

10. Fotografies reals

Factuzam registra les fotos per article, per prefix de SKU —habitualment el color— o per SKU complet. La integració utilitza la resolució real:

<appDirFotos>\real\<nombre registrado>.png

L'extensió d'origen desada a la base de dades és informativa. El fitxer operatiu que genera Factuzam és PNG.

A la implementació actual es tria la fotografia general principal i només es puja quan el producte remot no té cap imatge. PrestaShop genera automàticament les mides derivades. Les galeries, la substitució d'una foto ja pujada i l'associació de fotos per color queden fora del flux actual i s'han de fer manualment.

En una instal·lació on fza_articulos_fotos estigui buida, l'existència de fitxers solts a la carpeta no és suficient. Primer cal relacionar les fotos amb els seus articles o SKU. Aquesta relació no s'endevina pel nom del fitxer.

11. Seguretat de l'estoc

L'estoc web es calcula sumant només els magatzems elegibles i limitant el resultat mínim a zero. El magatzem de tares no hi participa mai.

Tanmateix, el Webservice estàndard de PrestaShop rep una quantitat absoluta. Si una venda web encara no està reservada automàticament a Factuzam, un moviment local posterior podria tornar a escriure una quantitat que reposés unitats ja venudes.

Per aquest motiu:

• Sincronizar stock y precios roman desmarcat per defecte;
• la casella vigent autoritza conjuntament el preu i l'estoc: no hi ha una autorització separada de l'estoc al treballador actual;
• no s'ha de marcar en producció fins a disposar d'ingestió o reserva automàtica de comandes web i proves completes de concurrència;
• els serveis, tares, dipòsits i magatzems no estàndard en queden exclosos.

L'estoc compartit entre botigues tampoc no està admès actualment. El client exigeix una fila stock_available que pertanyi exactament a la botiga configurada i falla de manera segura si PrestaShop utilitza id_shop=0 amb un grup de botigues. Aquest mode necessitarà validar abans share_stock i el grup efectiu.

Aquesta precaució no impedeix l'alta de famílies, producte, combinacions, preus o imatge principal. Amb la sincronització desmarcada, el producte nou queda preparat i inactiu sense publicar l'estoc local.

12. Reintents i prevenció de duplicats

L'API no ofereix una transacció única per crear tot el catàleg. L'alta es tracta com una seqüència que es pot reprendre:

VALIDAR -> CATEGORIAS -> ATRIBUTOS -> PRODUCTO_INACTIVO
        -> SKU -> IMAGEN_PRINCIPAL -> SINCRONIZACION_AUTORIZADA
        -> ACTIVACION_FINAL_OPCIONAL

Abans de cada alta es cerca el recurs remot per la seva identitat. Si es talla la xarxa, l'intent següent torna a cercar i reutilitza allò que ja existeixi. La bateria funcional ha de verificar aquesta idempotència, especialment amb dos treballadors concurrents, perquè la cerca i el POST no formen una transacció única.

Regles de seguretat:

• una referència ambigua no provoca mai una alta nova;
• el producte i els SKU es resolen per referència exacta i relació pare;
• les categories i els atributs es cerquen dins del seu pare o grup;
• una imatge no es torna a pujar si el producte ja en té alguna;
• una fallada no activa mai el producte;
• els recursos compartits no s'esborren com a compensació automàtica.

13. Diagnòstic d'incidències

Els missatges d'error i els registres no han d'incloure mai la clau API.

14. Llista de comprovació per a una implantació

1. Aplica la migració de la base de dades i comprova les marques En web.
2. Configura primer una botiga de proves de la mateixa versió que la botiga real; no utilitzis producció per a la validació inicial.
3. Crea una clau API de privilegi mínim. Si s'importen comandes, afegeix-hi només lectura sobre orders, customers, addresses, states, carriers, order_states, customer_threads i customer_messages.
4. Configura l'àmbit correcte —usuari, grup o Todos—, URL, botiga, empresa i tarifa amb les quatre caselles desmarcades.
5. Mentre la importació no filtri per id_shop, utilitza una clau exclusiva per a una sola botiga i no habilitis el flux en una instal·lació multibotiga.
6. Revisa Niveles de familia a crear (0 = todos): utilitza 0 per a tota la jerarquia local o un nombre positiu comptat des de la família fulla.
7. Marca únicament els magatzems estàndard que aportaran estoc web.
8. Revisa famílies, IVA, SKU, atributs, preus i fotos reals.
9. Prova un article amb diversos colors, talles i preus per SKU.
10. Confirma que una reference ambigua deixa un ERROR immediat sense crear recursos.
11. Mantén Crear artículos en PrestaShop al darlos de alta desmarcat fins que se superi la bateria funcional del laboratori.
12. Entra amb l'empresa i el magatzem correctes; importa al laboratori una comanda amb ports i una altra sense. Revisa client, productes, SKU, IVA, totals i la línia de servei GASTOS_T.
13. Repeteix el mateix ID PS, provoca un error intermedi i comprova que no es duplica la comanda i que les següents seleccionades continuen. No executis dues importacions concurrents de la mateixa comanda.
14. Serveix la comanda de prova fins a albarà i factura: GASTOS_T ha de conservar el tipus SERVICIO, la base i l'IVA sense moure estoc; les línies físiques sí que l'han de moure.
15. Prova les opcions de tancament Esperar, Cerrar de todos modos i Cancelar cierre amb un enviament real controlat.
16. Comprova una ingestió o reserva automàtica de comandes web, diferent de la importació manual, abans d'autoritzar quantitats absolutes.
17. Mantén Sincronizar stock y precios desmarcat mentre no hi hagi una decisió GO documentada per a la bateria completa.
18. Amb l'activació automàtica desmarcada, repeteix l'alta per comprovar que conserva els ID, no duplica recursos i deixa el producte complet però inactiu.
19. Al laboratori, marca Activar artículos en PrestaShop al marcar En web i comprova que active=1 només se sol·licita al final d'un procés correcte; provoca un error previ i confirma que no s'activa.
20. Prova les tres respostes en desmarcar En web: Sí desactiva, No només deixa de sincronitzar i Cancelar no desa.

Les proves de desenvolupament es fan únicament contra la instal·lació local actual de PrestaShop. No es fan altes ni modificacions de prova a la botiga de producció.

15. Referències tècniques oficials

• Creació completa d'un producte amb Webservice
• Recurs products
• Recurs combinations
• Grups d'atributs
• Valors d'atributs
• Gestió d'imatges

◀ Arquitectura i desenvolupament · Índex