Egy klasszikus problemas mintazat: a ceg ERP-jeben a termek SKU-12345-as kod alatt fut, 18 attributummal. A webshopon ugyanennek a terméknek 24 attributuma van (mas SEO-cim, hosszabb leiras, kepkollekcio). A Marketing-CMS-ben harmadszor is letezik, mert oda hand-curated content kell. Harom helyen 3 sor, 60 attribuum osszesen, es az integracios szinkron heti 4 oraban van — meg igy is forrasi adatkonfliktusok vannak. A Netorigo modellben EGY hely van.
A 10 attributum, 8 storefront, egy admin
A Netorigo katalogus single source of truth. Egy termek (peldaul NIT-AI-ASSISTANT-PRO) az products tablaban egy soron all, kb. 10 attributummal:
id,sku,slugname,description— ezekproduct_translationstablan keresztul tobb locale-ban (HU, EN, DE)base_price,currencycategory_idimage_url(main thumbnail) +product_mediatabla a galleryhoztags(JSONB)metadata(JSONB — domain-specifikus extras)
Ez a 10 attributum az igazsag. Minden mas — SEO-cim, hosszu marketing-szoveg, store-specifikus kategoria-elhelyezes — vagy ezekbol szarmazik, vagy egy storefront-specifikus override-tablaban van.
A storefront-specifikus override
A storefront_product_overrides tabla a kompromisszum. Egy sor itt egy (storefront_domain, product_id) paron felulirhat egy mezőt:
display_name(peldaul atravelium.hu-n „Barcelona 4 ej” helyett „Barcelona varosnezo csomag”)display_description(hosszabb, marketing-szoveg)display_price(csak akkor, ha a tenant megengedi a storefront-szintu arazas-felulirast —netorigo-kftnem)visibility(visible/hidden)category_position(a kategorialistaban hol jelenjen meg, integer 0-100)seo_title,seo_meta_description
Ha nincs sor itt, akkor a default products ertekeit hasznaljuk. Ez a „opt-in override” mintazat: nem 8 sornyi felulir-egy-storefront-ert duplazas, hanem csak akkor van uj sor, ha valoban egyedi a megjelenites.
A „Vazlat → Aktiv” rolling release
A products tabla rendelkezik egy status mezovel: draft, active, archived. A draft allapotu termek nem lathato semelyik storefronton — de a Catalog modul admin UI-jan szerkesztheto.
A fontos resz a published_at mezo. Egy terméket active-ra varhat, de csak egy jovobeli idopontban válik kihirdetté. Igy a marketing-csapat ket hettel egy kampany előtt elkesziti az osszes new termeket, mind draft-on, kepekkel + leirasokkal, majd a publish-datumot beallitva, kampany napjan automatikusan elindulnak az osszes storefronton egyszerre.
Egy konkret pelda: 80 termek bekerul az 5 storefrontra
A legutobbi nagy kampanyunk: 80 uj AI-tanacsadasi csomag (NC-* SKU-prefix) az osszes 5 megfelelő storefronton (nortinia.com, mediaorigo.hu, netorigo.com, meta-architects.hu, lunda.eu). Az osszes adatfelvitel egy admin UI-ban tortent:
- CSV-import a Catalog modulba: 80 sor, 10 oszlop. → 80 db
productsrekord, minddraft. - AI-keptenezetes (Style A 3D-isometric): 80 PNG generalva, R2-be feltoltve,
image_urlmezok kitoltve. - AI-forditas: HU forrasleirasokbol EN + DE forditas. → 240 db
product_translationsrekord. - Storefront-specifikus override (csak 8 termek esetében, ahol a
mediaorigo.hu-n mas SEO-cimet akartunk). - Publish — egy gombbal mind a 80 termek
active, a 5 storefronton egyszerre megjelennek.
Klasszikus 3-rendszeres ERP-ben ez 4-5 nap melo, sok kezi adatfelvitellel. Itt 1 nap volt.
A fejlesztoi tanulság
Ha egy uj storefrontot epitesz, NE huzd at a katalogust a sajat DB-dbe. Olvasd a Catalog modul publikus API-jat (GET /api/products?storefront_domain=X), es csak akkor irj storefront_product_overrides-t, ha az adott storefront valamit valoban felulirni akar. A katalogus a forras — minden egyeb csak megjeleniteni szervet.
Vegszo
10 attributum, 8 (sokszor 13) storefront, EGY admin. A Netorigo katalogus single source of truth az, hogy a vasarlo a travelium.hu-n vagy a nortinia.com-on ugyanazt a terméket latja, csak a kontextusnak megfelelo megjelenitessel. Ez a multi-storefront ERP lenyege, es ez az, ami egy 3 rendszer-szinkronizalassal kuszkodo ceget az okoszisztemaba huz.