Kto jest właścicielem którego pola: sklep, ERP czy PIM

Każdy sklep, który łączy się z systemem ERP, ostatecznie ustala, kto jest właścicielem numeru magazynowego. Odpowiedź brzmi prawie zawsze ERP lub system magazynowy, ponieważ to właśnie tam towary są rezerwowane i tam fizycznie się przemieszczają, a gdy ta zasada jest już ustalona, błędy synchronizacji stają się mechaniczne.

Potem to samo pytanie wraca dla każdego innego pola i ta prosta odpowiedź przestaje działać. Stan magazynowy to jedna liczba o jednym znaczeniu. Cena to jedna liczba na witrynę internetową, rynek lub firmę klienta. Tekst produktu to jedna wartość na język. Obraz to jeden plik, ale jego tekst alternatywny to zdanie na język. O to, kto jest właścicielem stanu magazynowego, nikt długo się nie spiera. To w pozostałej części rekordu kwestia własności pozostaje otwarta.

Ten wpis podaje regułę własności pole po polu dla cen, atrybutów, mediów, treści dla poszczególnych języków, cen B2B i kluczy URL, a następnie sprawdza każdą regułę pod kątem tego, co Magento i Shopify faktycznie mogą wyrazić, gdzie zatrzymują się systemy ERP używane w Europie Środkowej i kiedy PIM zaczyna się opłacać. Platformowa połowa tego tekstu to Magento i Shopify; czeski lub słowacki sklep co najmniej równie często działa na Shoptet, a kwestia własności pola jest tam taka sama, mimo że mechanizmy są inne. Każdy fakt dotyczący dostawcy sprawdzono względem jego własnej dokumentacji 4 sierpnia 2026 roku, a te nośne opatrzono linkiem; tam, gdzie czegoś nie udało się zweryfikować, piszemy o tym wprost.

Jeden właściciel na pole, w jednym zakresie

Zasada z wpisu o stanach magazynowych wciąż obowiązuje: jeden system rekordów na fakt. Zmienia się natomiast to, że pole nie jest faktem, dopóki nie nazwie się również jego zakresu. „ERP jest właścicielem ceny” to nie reguła, którą można wdrożyć w integracji. „ERP jest właścicielem ceny katalogowej na witrynę, a nikt nie jest właścicielem ceny na widok sklepu, bo platforma nie umie jej tak przechowywać”, to już reguła.

Słownictwo do opisu tego zjawiska jest starsze niż e-commerce. Pat Helland w tekście Data on the Outside versus Data on the Inside (CIDR 2005) formułuje tę zasadę w jednym zdaniu: „Dane referencyjne to rodzaj informacji tworzonych lub zarządzanych przez jedną usługę i publikowanych dla innych usług do ich użytku (…) Dla każdego elementu istnieje dokładnie jedna usługa publikująca”.

Literatura z zakresu zarządzania danymi mówi to samo innymi słowami i warto je zapożyczyć, bo nazywają dwie role, jakie odgrywają systemy sklepu. DAMA-DMBOK, drugie wydanie, rozdział 10 (Dane referencyjne i podstawowe) definiuje System of Record jako „system autorytatywny, w którym dane są tworzone lub przechwytywane, oraz utrzymywane zgodnie z określonym zestawem reguł i oczekiwań”, a System of Reference jako „system autorytatywny, w którym odbiorcy danych mogą uzyskać wiarygodne dane do obsługi transakcji i analiz, nawet jeśli informacje nie pochodzą z tego systemu”. Jedną z sześciu zasad przewodnich dotyczących danych referencyjnych i podstawowych jest Autorytet: „wartości danych podstawowych powinny być replikowane wyłącznie z systemu rekordów”. Kolejną jest Własność, którą literatura ta opisuje na poziomie organizacji, a nie pola. Twój storefront jest systemem odniesienia dla większości rekordu produktowego, a tym, czego dotyczy ten wpis, jest właśnie pytanie, który system jest rekordem dla każdego pola.

Tym, czego literatura nie precyzuje, jest granularność. Drugie wydanie nazywa samo oznaczenie i wymienia reguły dopasowania, scalania, przetrwania i zaufania wśród reguł biznesowych potrzebnych do zarządzania danymi podstawowymi, ale odnosi się do encji i elementów danych w ogólności, a nie do konkretnego pytania, który system jest właścicielem tekstu alternatywnego storefrontu w języku polskim. Cztery style MDM, zwykle przywoływane jako rejestr, konsolidacja, współistnienie i transakcja, są powszechnie przypisywane firmie Gartner; własne strony Gartnera odrzuciły każdego klienta, z którym próbowaliśmy się skontaktować, a otwarcie dostępne źródło, które znaleźliśmy, przypisuje te style konsultantom do zarządzania danymi i dostawcom MDM, a nie Gartnerowi, więc traktujemy je jako wspólnie przyjęty opis, a nie jako definicję.

Propagacja ma wzorce nazwane lepiej. Kanał push to konsument sterowany zdarzeniami, a zadanie nocne to konsument odpytujący; tolerowanie powtórzonej wiadomości to Idempotent Receiver, którego dwie udokumentowane drogi to jawna deduplikacja i semantyka czyniąca ponowne przetworzenie nieszkodliwym; a przywracanie porządku w strumieniu, który dotarł w niewłaściwej kolejności, to Resequencer. Helland w tekście Life beyond Distributed Transactions (CIDR 2007) formułuje wymaganie, któremu te wzorce mają odpowiadać: „aplikacja musi tolerować ponowne wysyłanie wiadomości i przychodzenie niektórych wiadomości w nieuporządkowanej kolejności”.

Co może wyrazić twoja platforma

Jeśli platforma nie umie wyrazić reguły własności, nie da się jej wdrożyć, więc sprawdź regułę względem modelu danych, zanim uzgodnisz ją z kimkolwiek.

Magento ustala zakresy według hierarchii sklepu. Adobe dokumentuje kaskadę: globalny, witryna, sklep i widok sklepu, ale atrybut produktu ma zakres tylko w trzech z tych czterech poziomów: poziom sklepu nosi kategorię główną, a nie wartości atrybutów, więc atrybut jest globalny, przypisany do witryny albo do widoku sklepu. O większości pytań o własność decydują dwa ograniczenia. Cena nie ma swobodnego zakresu: ustawienie Catalog Price Scope oferuje wyłącznie poziom Global lub Website, strona wprost stwierdza, że „Commerce nie pozwala ustawić ceny produktu dla każdego sklepu osobno”, a panel administracyjny udostępnia to ustawienie tylko w zakresie Default Config, czyli jest to jeden przełącznik dla całej instalacji. Niektórych atrybutów nie da się przekonfigurować co do zakresu wcale: Magento blokuje selektor zakresu dla sku i category_ids w eav_attributes.xml i wyłącza go dla sku oraz media_gallery w konfiguracji formularza panelu administracyjnego (2.4-develop, sprawdzono 4 sierpnia 2026 roku). Atrybut użyty jako opcja konfigurowalna musi być globalny, choć etykiety jego opcji pozostają tłumaczalne dla każdego widoku sklepu.

Shopify rozdziela ceny i tłumaczenia, i są to różne mechanizmy. Wariant ma jedną cenę bazową w rekordzie produktu; ręcznie ustawiona cena dla danego rynku leży całkowicie poza produktem, w cenniku przypisanym do katalogu przypisanego do rynku. Rynek może też różnić się od ceny bazowej bez żadnego cennika, przez przeliczanie walut i zasady zaokrąglania. Magento nie ma tu odpowiednika: ręcznie ustawiona cena dla danego rynku oznacza witrynę na rynek, przy czym widoki sklepu pod tą witryną tę cenę dzielą. Tłumaczenie to osobna warstwa, a w samym zasobie produktu jest ona wąska: tłumaczalne są tylko tytuł, treść, uchwyt (handle), typ produktu, meta title i meta description, a tagów zasobu nie da się przetłumaczyć wcale. Nazwy opcji, wartości opcji i publicznie dostępne metapola też są tłumaczalne, jako własne typy zasobów. Tłumaczenie można też ograniczyć do jednego rynku przez marketId na wejściu tłumaczenia, dzięki czemu ten sam język może być czytany różnie na dwóch rynkach. Uchwyty URL są wyjątkiem: Shopify wprost stwierdza, że nie można ich dostosować dla poszczególnych rynków. Dla tego, kto zarządza ścieżką zapisu, znaczenie mają dwa mechanizmy: zapisanie tłumaczenia wymaga translatableContentDigest z treści źródłowej, a Translation.outdated raportuje, czy treść oryginalna zmieniła się od chwili zapisania tłumaczenia. Dzięki temu nieaktualność jest wykrywalna, ale nie jest tym samym rozwiązywana. A productSet uzgadnia pola listowe z przesłanym payloadem: dla wariantów, metapól i kolekcji tworzy i aktualizuje to, co jest w payloadzie, a usuwa to, czego w nim nie ma, co czyni naiwne, częściowe zadanie „zsynchronizuj wszystko” destrukcyjnym. Opisane wyżej zachowanie dotyczy Admin API w wersji 2026-07, sprawdzono 4 sierpnia 2026 roku.

Odpowiedź pole po polu

Dwa wiersze wymagają rozwinięcia: media i klucze URL.

Obraz jest globalny, jego tekst alternatywny nie. Adobe stwierdza, że „nowe zdjęcia produktów są zawsze wgrywane i widoczne we wszystkich widokach sklepu, nawet jeśli do wgrywania nie użyto zakresu All Store Views” (obrazy i wideo produktu, sprawdzono 4 sierpnia 2026 roku), a galeria przechowuje jeden plik na obraz, bez kolumny sklepu. DAM jest więc właścicielem zestawu zasobów dla wszystkich lokalizacji jednocześnie. Tym, co jest przypisane do widoku sklepu, jest wiersz przy każdym obrazie: etykieta, pozycja i flaga wyłączenia, co sprawia, że tekst alternatywny, kolejność obrazów i to, który obraz jest ukryty, są polami dla widoku sklepu. Jedno zastrzeżenie komplikuje ten uporządkowany podział: role obrazu (base, small, thumbnail, swatch) to atrybuty w zakresie widoku sklepu, przechowujące ścieżkę do pliku, więc to, który z globalnych plików wyświetla dana witryna, może się różnić dla lokalizacji. Shopify wyznacza tę granicę w tym samym miejscu, ale z drugiej strony: w obrazie multimedialnym jedynym tłumaczalnym polem jest alt. Dokumentacja Translate & Adapt wymienia obrazy produktu wśród typów treści, których aplikacja nie może przetłumaczyć, natomiast inne obrazy i filmy w przetłumaczonym zasobie można podmienić dla języka, wgrywając plik alternatywny (sprawdzono 4 sierpnia 2026 roku).

Ten podział ma większe znaczenie, niż się wydaje, bo tekst alternatywny nie jest polem technicznym. European Accessibility Act obejmuje usługi e-commerce sprzedawane konsumentom, a państwa członkowskie muszą stosować jej środki od 28 czerwca 2025 roku. Sama dyrektywa wymaga, by te usługi były postrzegalne, funkcjonalne, zrozumiałe i solidne, nie wymienia natomiast tekstu alternatywnego z nazwy; konkretny wymóg alternatywy tekstowej wyraża norma EN 301 549, która wskazuje na WCAG. Warto zauważyć, że obowiązująca wersja, V3.2.1, została zharmonizowana na podstawie dyrektywy o dostępności stron internetowych, a nie na podstawie Accessibility Act, a wersja V4.1.0, odnosząca się do EAA, w chwili sprawdzania wciąż nie była przywołana w Dzienniku Urzędowym. Wyłączenie dla mikroprzedsiębiorstw jest węższe, niż się wydaje, a osobna ocena nieproporcjonalnego obciążenia jest otwarta dla każdego dostawcy. Tekst alternatywny to treść dla języka, z przypisanym do niej reżimem zgodności, tworzona wszędzie tam, gdzie tworzona jest reszta tekstów. Żadna z platform nie pyta o niego dla lokalizacji w swojej ścieżce wgrywania.

Klucz URL zwykle należy do sklepu, ale nie dlatego, że nikt inny nie rości sobie do niego prawa. Większość systemów ERP nie ingeruje w adresy URL witryny, co skłania do wniosku, że pole to nie ma konkurującego kandydata. Taki kandydat jednak istnieje. Własna dokumentacja e-Sklepu Comarch ERP Optima daje systemowi ERP zakładkę Pozycjonowanie, zawierającą tytuł strony, dedykowane pole Link do budowania adresów URL, słowa kluczowe i meta description, i to zarówno dla grup produktów, jak i pojedynczych pozycji (Pomoc Comarch Optima, wersja 2026_5, sprawdzono 4 sierpnia 2026 roku). Konektory i systemy PIM też zapisują uchwyty, niezależnie od tego, co dokumentuje jądro ERP.

Reguła operacyjna jest lepsza niż argument o zakresie, bo Comarch pokazuje, że ERP potrafi wyrazić to pole. Kto jest właścicielem klucza URL, przejmuje wszystkie konsekwencje jego zmiany, a te konsekwencje pojawiają się poza systemem, który tę zmianę wprowadził. Decyzją, która się liczy, jest więc to, co ma się stać przy zmianie nazwy. Magento ma na to ustawienie, „Create Permanent Redirect for URLs if URL Key Changed”, a kto jest właścicielem klucza, dziedziczy rosnącą tabelę przekierowań.

Pozwolenie zewnętrznemu systemowi na dowolne zmienianie tego pola ma bezpośredni koszt. Specyfikacja pliku Heureka oznacza cztery elementy jako bezwarunkowo obowiązkowe: nazwę produktu, identyfikator pozycji, cenę z VAT i adres URL, i stwierdza, w języku czeskim, że gdy w XML zmienią się adresy URL, nazwy lub kategorie produktów, wszystkie produkty zostają odłączone od swoich kart produktowych Heureka i czekają na ponowne sparowanie, co według tej specyfikacji może zająć około czterech dni roboczych. PIM, który regeneruje uchwyty z nazw produktów, na kilka dni odłącza więc cały katalog od porównywarki, choć w samym sklepie nic nie wygląda na zepsute.

Gdzie kończy się ERP: treść dla poszczególnych języków

W sklepie sprzedającym po czesku, słowacku, niemiecku i polsku granicę między „ERP może być właścicielem tekstów produktowych” a „musi zająć się tym coś innego” zwykle wyznacza liczba języków, które przewiduje model danych ERP, a liczba ta jest niższa niż liczba rynków, na które sprzedaje sklep tej wielkości.

ABRA Flexi jest właścicielem treści wielojęzycznych w swoim głównym obiekcie cennikowym, ale jako stała liczba kolumn, a nie lista: jedna podstawowa nazwa i opis plus trzy dodatkowe, widoczne w opublikowanym schemacie pól tego obiektu (sprawdzono 4 sierpnia 2026 roku, gdzie firma demonstracyjna oznacza je jako angielski, niemiecki i francuski). To cztery sloty językowe w obiekcie głównym, a własny artykuł pomocy ABRA potwierdza, że więcej języków jest możliwych tylko przez dodanie niestandardowych pól dla każdego języka, co jest pracą integracyjną, nie konfiguracyjną. Money udostępnia zlokalizowane nazwy i opisy przez widoki PLUS swojego konektora e-commerce, a Comarch ERP Optima przechowuje nazwy i opisy dla języka na tej samej zakładce e-Handel, na której znajdują się pola SEO. Business Central eksportuje tłumaczenia pozycji do Shopify w jedną stronę i był jedynym systemem w tej grupie, którego dokumentacja opisywała mostek niestandardowych pól, mapujący jego pola na metapola Shopify. Dla SAP Business One i InsERT nie znaleźliśmy udokumentowanego eksportu tekstów produktowych w wielu językach, choć portal dokumentacji SAP renderuje treści tylko dla klienta JavaScript i nie mogliśmy odczytać całości, więc traktujemy to jako niepotwierdzone, a nie jako nieistniejące.

Dwa kolejne ograniczenia po stronie ERP po cichu psują integracje, bo oba są sztywnymi pułapami, a nie błędami. ABRA Flexi koduje poziomy ilościowe jako stałe kolumny, a nie wiersze, co ogranicza ceny wolumenowe do pięciu poziomów. Helios wyraża każdy poziom cenowy w maksymalnie sześciu walutach, jednej krajowej i pięciu zagranicznych. Siatka poziomów lub lista walut, która przerasta możliwości ERP, przestaje być wyrażalna w systemie rekordów, bez zgłoszenia błędu.

Warto znaleźć w pierwszej kolejności: flagę, która decyduje, jakie SKU może zobaczyć storefront. Każdy system ma taką flagę i każdy nazywa ją inaczej: isInternet na karcie towarowej POHODA, exportNaEshop na pozycji cennikowej ABRA Flexi, opisane w opublikowanym schemacie pól i używane jako filtr we własnym przewodniku integracyjnym ABRA. Kto jest właścicielem tej flagi, kontroluje katalog, niezależnie od tego, co mówi na ten temat reszta projektu. Helios ustala kierunek autorytatywności inaczej, poprzez zakres swojego API: z siedemnastu ścieżek w opublikowanym opisie API eShop zapis przyjmują tylko zamówienia i klienci. Produkty, kategorie, cenniki i stany magazynowe są tylko do odczytu, co z definicji czyni ERP systemem autorytatywnym.

Pola dodane przez prawo

Niektóre z kwestionowanych pól są nowe i pojawiły się z regulacji, a nie z merchandisingu, więc żaden system nie był zaprojektowany, by je posiadać.

General Product Safety Regulation (rozporządzenie (UE) 2023/988, obowiązujące od 13 grudnia 2024 roku) wymaga, by oferta sprzedaży na odległość zawierała nazwę producenta oraz jego adres pocztowy i elektroniczny, to samo dla osoby odpowiedzialnej producenta spoza UE, informacje identyfikujące produkt, w tym zdjęcie i jego rodzaj, a także wszelkie ostrzeżenia lub informacje dotyczące bezpieczeństwa „w języku łatwo zrozumiałym dla konsumentów, określonym przez państwo członkowskie, w którym produkt jest udostępniany na rynku”. Ten ostatni zapis czyni tekst o bezpieczeństwie polem treści właściwym dla każdego rynku, a wybór języka należy do docelowego państwa członkowskiego, nie do ciebie. Rozporządzenie wymaga też, by za każdy produkt odpowiadał podmiot gospodarczy ustanowiony w UE.

Etykietowanie energetyczne dodaje kolejne wymagania. Rozporządzenie (UE) 2017/1369 wprost wymienia sprzedaż internetową na odległość w obowiązku sprzedawcy dotyczącym wyświetlania etykiety (art. 5 ust. 1 lit. a); karta informacyjna produktu musi być udostępniona klientom na podstawie kolejnego punktu, już bez tego zastrzeżenia. Artykuł 6 lit. a) odrębnie wymaga, by wizualna reklama konkretnego modelu zawierała zarówno klasę efektywności, jak i zakres klas dostępnych na etykiecie. Baza EPREL wymaga od dostawców rejestracji każdego nowego modelu od 1 stycznia 2019 roku. Konsekwencje sięgają pliku produktowego: Google Merchant Center od kwietnia 2025 roku wymaga kodu rejestracyjnego EPREL w atrybucie certyfikacji dla produktów objętych tym obowiązkiem, kierowanych na rynek UE, i obecnie ogranicza swój atrybut klasy efektywności energetycznej do Szwajcarii, Norwegii i Wielkiej Brytanii.

Kanały już zamodelowały te pola. API Allegro prowadzi osoby odpowiedzialne i odpowiedzialnych producentów jako osobne zasoby, informacje o bezpieczeństwie dla oferty oraz flagę dla produktów wprowadzonych na rynek przed obowiązkiem GPSR. Heureka dokumentuje dedykowane pola na adres pocztowy i elektroniczny producenta. Te pola potrzebują więc systemu rekordów, który może je poświadczyć dla rynku i dla języka, a często żaden istniejący system go nie ma: ERP rejestruje dostawcę, nie osobę odpowiedzialną, a storefront rejestruje treść, nie atest. Praktycznym miejscem na to jest metapole albo zestaw atrybutów dla rynku w witrynie sklepowej, wypełniany przy wdrażaniu dostawcy, nie przy wystawianiu oferty, z kontrolą pustego pola stosowaną do produktów nowych i edytowanych, nie retroaktywnie. Uruchamiaj to jako bramkę dla nowych ofert i jako raport dla istniejącego katalogu: zastosowana do katalogu liczącego tysiące SKU od dziesiątek dostawców, twarda blokada wycofuje sklep z publikacji tego samego dnia, kiedy ją włączysz.

Ceny B2B to inny mechanizm na każdej platformie

Adobe umieszcza ceny B2B w katalogach współdzielonych, które są częścią modułu Adobe Commerce B2B, a więc niedostępne w Magento Open Source czy Mage-OS. Ich włączenie dodaje opcję Shared Catalog do selektora grup klientów na stronie Advanced Pricing produktu, dzięki czemu ta sama siatka poziomów jest edytowana z jednego miejsca dla obu stron.

Shopify prowadzi B2B przez tę samą maszynerię katalogów i cenników co rynki, przy czym katalog jest przypisany do lokalizacji firmy. Ograniczeniem są limity planu. Dokumentacja katalogów B2B Shopify podaje, że w planach Basic, Grow i Advanced „można przypisać do 3 aktywnych katalogów łącznie na wszystkich rynkach B2B”, podczas gdy plan Plus daje ich nieograniczoną liczbę i przypisanie bezpośrednio do firm i lokalizacji (sprawdzono 4 sierpnia 2026 roku). Gdy do jednej lokalizacji firmy odnosi się kilka katalogów, wyświetlana jest najniższa cena. Dokumentacja konektora Business Central Microsoftu podaje, że synchronizacja cen B2B wymaga subskrypcji Shopify Plus, a przynależność do katalogu jest zarządzana w panelu administracyjnym Shopify, nie w ERP.

Wynikająca z tego reguła własności jest taka sama w obu przypadkach: ERP jest właścicielem tego, na co dany klient uzgodnił cenę w kontrakcie, a platforma jest właścicielem tego, do jakiego katalogu ten klient jest przypisany. Dalszy podział oznacza wpisanie warunków kontraktu do narzędzia merchandisingowego.

Kiedy PIM się opłaca

PIM jest wart swojej ceny w punkcie, w którym wartości dla lokalizacji i dla kanału przestają mieścić się w platformie. Obie wiodące opcje modelują to bezpośrednio, a ich licencjonowanie różni się na tyle, że decyduje o wyborze wcześniej niż same funkcje.

Mechanizm Akeneo to dwie niezależne flagi na każdym atrybucie: localizable i scopable. Wartość produktu to trójka: lokalizacja, zakres i dane, a kanał grupuje lokalizacje, waluty, drzewo kategorii i jednostki przeliczeniowe dla jednego miejsca publikacji. Community Edition jest open source na licencji OSL-3.0 i jest aktywnie rozwijane, z wydaniem v2026.3 oznaczonym datą 30 marca 2026 roku, a Akeneo ogranicza swoją tabelę końca wsparcia do wersji płatnych, nie do Community. Zastrzeżenie dotyczy aktualizacji: Community przeszło na wersjonowanie kalendarzowe, a Akeneo nie gwarantuje zgodności wstecznej między żadnymi dwiema wersjami. Komercyjnie sprzedaje trzy poziomy SaaS, a jego strona porównawcza renderuje ceny za pomocą skryptów po stronie klienta, a nie jako statyczny tekst, więc nie podajemy stąd żadnej liczby. W obiegu są zewnętrzne szacunki cen Akeneo; żadne nie jest potwierdzone na stronie Akeneo, więc ich nie powtarzamy.

Pimcore, z siedzibą w Salzburgu, zmieniło licencję w sposób, który ma bezpośrednie znaczenie dla czytelnika tego artykułu. Od wersji platformy 2025.1 nie jest już open source: publicznie dostępny kod jest objęty Pimcore Open Core Licence, licencją typu source-available, a jego własny plik composer.json w aktualnej gałęzi deklaruje licencję jako proprietary. Tekst licencji udziela bezpłatnego użycia produkcyjnego wyłącznie organizacjom, których łączny globalny przychód nie przekracza 5 milionów euro rocznie, na zasadzie samocertyfikacji podlegającej audytowi z opłatami retroaktywnymi, zakazuje oferowania Pimcore jako usługi hostowanej lub zarządzanej, zakazuje uruchamiania równolegle Pimcore na licencji GPLv3 i zawiera klauzulę dotyczącą telemetrii, w którą licencjobiorca zobowiązuje się nie ingerować. Jego opublikowane ceny katalogowe to 9900 dolarów rocznie za wersję Professional i 29 900 dolarów za wersję Enterprise, obie w modelu on-premises, z ceną PaaS podawaną na zapytanie. Dla sklepu o przychodach powyżej 5 milionów euro Pimcore oznacza zakup licencji komercyjnej.

Procedura

Zanim wybierzesz jakiekolwiek narzędzie, spisz listę pól. Dla każdego pola nazwij system, który tworzy i utrzymuje wartość, zakres, w jakim platforma może ją przechowywać, oraz co się dzieje, gdy obie strony się nie zgadzają. Kierunek wynika z tego pierwszego: system rekordów zapisuje, a wszystko inne odczytuje, więc pole z dwoma autorami zapisu nie ma właściciela. Sprawdź następnie trzy rzeczy, które wychwytują większość błędnych projektów: czy zakładany zakres w ogóle istnieje (cena dla widoku sklepu nie istnieje w Magento), czy model danych właściciela pomieści potrzebny zasięg (pięć walut, pięć poziomów, trzy dodatkowe lokalizacje), oraz czy nic innego nie zapisuje tego samego pola bez twojej wiedzy. Dwustronna edycja jednego pola w dwóch systemach to projekt, którego należy unikać, a zwykle powstaje on przez zaniedbanie, nie z wyboru.

Następnie zdecyduj o propagacji, pamiętając, że pierwsze wczytanie danych i stan ustabilizowany to dwa różne systemy. Początkowe wczytanie katalogu to zadanie zbiorcze: operacje zbiorcze Shopify przyjmują JSONL i działają asynchronicznie, a Magento ma asynchroniczny bulk REST i importer CSV. Stan ustabilizowany to delta, a mechanizm dyktuje to, co jest w stanie wysłać właściciel danych. ERP, który udostępnia jedynie nocny eksport plikowy, nie może przesyłać danych push, niezależnie od tego, jak zaprojektowano integrację, więc delta staje się zaplanowanym odpytywaniem z filtrem „zmienione od”, a świeżość danych w storefroncie jest ograniczona interwałem eksportu, niezależnie od tego, co komukolwiek obiecano. Uzgadnianie (reconciliation) to trzecie zadanie, nieopcjonalne: okresowe pełne porównanie, które wychwytuje to, czego nie wychwyciła delta, bo plik, którego nikt nie audytuje, dryfuje bezgłośnie.

W Shopify z tego, jak synchronizuje się productSet, wynika jeszcze jedna reguła: w polu listowym, które wysyłasz, usuwa on wpisy, które pominiesz, więc częściowa lista wariantów usuwa warianty, których w niej nie umieszczono. Używaj go tylko tam, gdzie system wysyłający jest właścicielem całej listy, którą wysyła, a tam, gdzie własność jest podzielona, używaj mutacji celowanych.

Mapowanie tej listy pól i budowanie integracji, które ją obsługują, to zakres naszej usługi integracji, a prace niestandardowe wykraczające poza model danych platformy to custom development. Niezależnie od wybranych narzędzi, to lista pól jest podstawą, na której budowana jest integracja.