Mirakl dla Orbito — 0.2.14

Paczkomaty i świeży import po usunięciu (0.2.14)

Wymaga Zamówień 2.18.9. Punkt odbioru jest pobierany z shipping_pudo_id lub dodatkowego pola pickupcode; pickupintegration i nazwa usługi dostawy pozwalają odróżnić paczkomat od ogólnej nazwy przewoźnika. Sprzeczne kody punktu zatrzymują mapowanie. Brakujące punkty w istniejących zamówieniach są uzupełniane bez nadpisywania ręcznie wybranej usługi lub punktu.

„Synchronizuj teraz” tworzy nowy import zamówienia usuniętego w Orbito przez kontrakt orders.source.prepareReimport. Nowe ID oddziela stare wpłaty, historię, pakowanie, notatki i powiązania dokumentów. Dane i wpłata pochodzą z aktualnej odpowiedzi marketplace. Aktywne zamówienia pozostają bez duplikowania. Dawne zadania przesyłania dokumentów i wysyłki nie mogą wykonać się na nowym imporcie; niepewne operacje nie są powtarzane. Zwykła synchronizacja w tle nadal nie odtwarza usuniętych zamówień.

Wspólna historia systemowa jest rejestrem dopisywanym przez platformę, bez API kasowania. Pozostaje związana ze starym, usuniętym ID i nie jest historią nowego importu. Nie usuwamy wystawionych faktur ani nadań w innych modułach.

Poniższe sekcje opisują wcześniejsze wydania; przywracanie starego dokumentu z 0.2.12 zostało zastąpione świeżym importem.

Opis konfiguracji (0.2.13)

Poprawiono opis importu i płatności w konfiguracji, aby odpowiadał logice 0.2.12: automatyczna akceptacja, import opłaconych przedpłat oraz pobrań i płatności odroczonych, dalsza kontrola oczekujących płatności bez limitu siedmiu dni i przywracanie usuniętych zamówień podczas ręcznej synchronizacji. Zasady działania integracji pozostają bez zmian. Wymaga Zamówień 2.18.8.

Aktualny przebieg importu (0.2.12)

Wymaga Zamówień 2.18.8. Zastępuje wcześniejsze zasady importowania nieopłaconych zamówień i limit siedmiu dni opisane w historii wersji poniżej.

WAITING_ACCEPTANCE: akceptacja wszystkich oczekujących pozycji przez OR21. Dopiero kolejny odczyt OR11 potwierdza nowy stan; odpowiedź na akceptację nie oznacza zapłaty.
Przedpłata trafia do Orders dopiero po gotowości do realizacji i poprawnym customer_debited_date. PAY_ON_ACCEPTANCE samo nie jest dowodem zapłaty.
PAY_ON_DELIVERY i PAY_ON_DUE_DATE trafiają do Orders po akceptacji bez fikcyjnej wpłaty, z kodem pobrania lub płatności odroczonej.
Anulowane, odrzucone i zwrócone zamówienia nie są tworzone. Dla już istniejących dokumentów zachowane są kontrole zmian i anulowania.
Nieopłacone zamówienia pozostają w kolejce integracji i są ponownie sprawdzane bez limitu siedmiu dni. Pobieranie historii przeplata się z kontrolą oczekujących płatności.
„Synchronizuj teraz” ponownie przegląda zakres od ustawionej daty. Jawnie przywraca usunięte kwalifikujące się dokumenty przez orders.source.restoreRemoved, zachowując ID, ręczne korekty, wpłaty i pakowanie. Nie uruchamia ponownie automatyzacji utworzenia. Zwykły cykl w tle nie cofa ręcznego usunięcia.
Niejednoznaczny wynik akceptacji nie wywołuje ponownego OR21. Integracja odczytuje status; jeśli nadal oczekuje na akceptację, pokazuje problem do weryfikacji.

Dokumentacja: OR21, OR11.

Notatki i nazwy wpłat (0.2.10)

Nowe zamówienia nie otrzymują automatycznych notatek pracownika. Uwagi importu pozostają w diagnostyce integracji. Istniejące notatki są czyszczone partiami wyłącznie z dokładnie rozpoznanych wierszy wygenerowanych przez importer; pozostała treść jest zachowywana.

Mapowanie nazw obejmuje metodę zamówienia oraz nazwę istniejącej wpłaty o identyfikatorze transakcji tego źródła. Kwoty, daty, status opłacenia i ręczne korekty pozostają bez zmian. Wymaga Zamówień 2.18.4; najpierw zaktualizuj dostawcę zamówień.

Dane fakturowe zgodne z wyborem klienta (0.2.3)

Zwykły adres rozliczeniowy osoby prywatnej nie jest prośbą o fakturę. Bez takiej prośby import i późniejsza synchronizacja pozostawiają dane fakturowe puste. Jawne „nie” ma pierwszeństwo przed danymi firmy i NIP. Jawne „tak” pozwala pobrać również dane do faktury dla osoby prywatnej.

Naprawa dostawy w starszych importach (0.2.2)

Przy odroczonym ujawnieniu danych odbiorcy integracja odtwarza rzeczywiste wartości początkowe zagnieżdżonego importu, bez dopisywania imienia i nazwiska z danych klienta. Naprawia także zapisane wcześniej podstawy porównania, gdy cały lokalny adres nadal odpowiada pustemu importowi. Uzupełnienie zachowuje ręczne korekty, flagę wymagania faktury i dane finansowe.

Nazwy płatności w konfiguracji Mirakl (0.1.18)

Ustawienia → Moduły → wybrana instancja Mirakl (np. Castorama) → Konfiguracja → Nazwy płatności. Każde pole pokazuje nazwę otrzymaną z API: payment_type, a gdy jest puste — payment_workflow. Wpisz własną nazwę zamówienia albo pozostaw pole puste, aby zachować nazwę oryginalną. Przypisania są osobne dla każdej instalacji marketplace.

Nazwy są wykrywane z zapisanych i nowo pobranych zamówień. Po zapisaniu konfiguracji najbliższy cykl synchronizacji aktualizuje istniejące zamówienia partiami, także historię, bez ponownego importu ani dodatkowego żądania do marketplace. Ręczna korekta nazwy w zamówieniu ma pierwszeństwo. Usunięcie przypisania przywraca nazwę źródłową tam, gdzie nie zmieniono jej ręcznie.

Od 0.2.10 mapowanie obejmuje nazwę metody w zamówieniu i nazwę zaimportowanej wpłaty. Nie zmienia kodu metody, pobrania, kwot, dat ani statusu opłacenia; ręczne korekty nazw są zachowywane. Nazwa nie jest pobierana z modułu księgowego. Autouzupełnianie danych z wersji 0.1.17 pozostaje aktywne. Wspólne wydanie: Zamówienia 2.14.18, Mirakl 0.1.18; wFirma 1.13.8 wycofuje poprzednie powiązanie wyświetlania nazw.

Uzupełnianie danych ujawnionych po imporcie (0.1.17)

Wymaga Zamówień 2.14.17 do automatycznego uzupełniania danych. Zaktualizuj najpierw Zamówienia, następnie instancje Mirakl (np. Castorama, Leroy Merlin i Media Expert).

Kolejny odczyt API uzupełnia brakujące pola adresu dostawy, danych faktury i kontaktu w tym samym zamówieniu. Dotyczy również istniejących zamówień zaimportowanych z pustymi danymi w WAITING_DEBIT_PAYMENT, także oznaczonych już jako wymagające uwagi. Domyślne PL przy braku kraju może zostać zastąpione krajem ujawnionym przez marketplace. Pierwotna odpowiedź API pozostaje zapisana do diagnostyki.

Aktualizacja porównuje cały zestaw danych odbiorcy z zapisaną podstawą importu i zachowuje ręczne korekty. Nie zastępuje znanych adresów nowymi, nie zmienia pozycji, kwot, VAT, flagi faktury ani statusu realizacji. Zatwierdzenie wcześniejszego konfliktu i danych finansowych pozostaje oddzielną czynnością. Notatka oraz ostrzeżenia z chwili importu pozostają historycznym zapisem. Zamówienia anulowane i zakończone nie są w ten sposób uzupełniane.

Naprawa następuje podczas zwykłej synchronizacji, gdy API zwróci pełniejsze dane; można zlecić „Odśwież synchronizację” w szczegółach zamówienia. Nie należy usuwać ani importować zamówienia ponownie.

Moduł core/mirakl łączy Orbito z kontem sprzedawcy na platformie Mirakl przez klucz API. Każda instalacja ma własny adres marketplace, ID sklepu, klucz, ustawienia, historię importu i kolejkę operacji. Można zainstalować go wielokrotnie, np. dla Media Expert, Leroy Merlin i Castoramy. Nie ma zaszytych adresów ani wspólnych kluczy tych operatorów.

Stan wydania: implementacja i testy lokalne; połączenie z rzeczywistym kontem oraz upload do poszczególnych operatorów wymagają testu wdrożeniowego. Paczka nie włącza synchronizacji automatycznie.

Pierwsza wersja

Import nowych zamówień, także nieopłaconych i oczekujących na akceptację (STAGING, WAITING_ACCEPTANCE, WAITING_DEBIT, WAITING_DEBIT_PAYMENT, SHIPPING), z pozycjami, adresem, dostawą i danymi fakturowymi.
Potwierdzanie przedpłaty przez 7 dni od created_date Mirakl. Wpłata aktualizuje ten sam rekord Orbito przez payments.upsert; bez potwierdzenia zamówienie pozostaje nieopłacone.
Przekazywanie numeru nadania i kodu przewoźnika z rejestru przesyłek Orbito.
Potwierdzenie wysyłki dopiero po ustawieniu wybranego statusu fizycznej wysyłki w Orbito.
Przesyłanie wygenerowanej etykiety PDF, jeśli operator udostępnia odpowiedni typ dokumentu.
Przesyłanie wystawionej faktury PDF z centralnego rejestru dokumentów Orbito.
Panel połączenia, błędów i ręcznego ponowienia zadań oraz blok informacyjny na zamówieniu.

Etykiety i faktury generują dotychczasowe moduły Orbito. Mirakl przekazuje ich PDF do marketplace. Typy dokumentów i kody przewoźników pobiera osobno z każdej platformy. Samo dopuszczenie PDF w słowniku nie przesądza, że operator akceptuje dany typ jako etykietę wysyłkową — trzeba wybrać typ zgodnie z jego wymaganiami.

Uruchomienie

Szczegółowa instrukcja: docs/URUCHOMIENIE.md. Warunki techniczne i poprawka routingu wielu instalacji: deploy/README.md.

Zainstaluj paczkę jako osobną instancję i nadaj administratorowi uprawnienie mirakl.manage.
W konfiguracji zapisz nazwę, adres HTTPS panelu Mirakl, ID sklepu i jego klucz API. Klucz wpisuj bezpośrednio w pole sekretu.
Uruchom „Sprawdź połączenie”. Sprawdź potwierdzoną nazwę sklepu, listę przewoźników i typów załączników.
Ustaw statusy, dzień początku importu w kalendarzu oraz wybierz przewoźników z listy. Typ faktury jest pobierany ze słownika marketplace. Dane produktów i VAT ustala moduł Zamówienia z katalogu Orbito. Integracja nie ma własnych ustawień stawek VAT.
Włącz synchronizację i wykonaj test jednego zamówienia według instrukcji. Dla kolejnego marketplace dodaj kolejną instalację modułu.

Pierwszy udany test przypisuje instalację do konkretnego adresu i sklepu. Można wymienić klucz po ponownym teście. Rozłączenie zatrzymuje synchronizację i usuwa zapisany klucz, zachowując historię oraz przypisanie konta.

Granice wersji 0.1.1

Jedno aktywne nadanie i jedna paczka na zamówienie. Przesyłki częściowe, wiele nadań i Mirakl Multiple Shipments wymagają dalszego rozszerzenia.
Faktury typu „Faktura” lub „Faktura VAT” pobierane z centralnego rejestru Orbito dla tego zamówienia. Kwota, numer i PDF pochodzą z Orbito; integracja nie porównuje ich z historyczną kwotą marketplace. Proformy i korekty nie są automatycznie przekazywane.
Zamówienia oczekujące na akceptację/płatność są importowane bez czekania na gotowość do wysyłki. Przekazywanie trackingu i PDF jest wstrzymane do gotowości Mirakl. Moduł nie wykonuje akceptacji w imieniu sprzedawcy. Zamówienia już wysłane przed pierwszym importem trafiają do Orbito jako historia.
Anulowanie, zwrot lub zmiana danych realizacji na marketplace zatrzymuje przekazywanie danych i kieruje istniejące zamówienie do statusu wyjątku. Konflikt pozostaje zablokowany; ta wersja nie ma automatycznego scalania ani przycisku pomijania konfliktu.
Brak danych i rozbieżności kwot są zapisywane jako uwagi przy zaimportowanym zamówieniu. Niepełne kwoty i VAT wymagają zatwierdzenia w Orbito przed fakturowaniem.
Oferty, ceny, stany magazynowe, zwroty, refundacje i OAuth/Mirakl Connect są poza zakresem tego wydania. Użycie klucza przez dystrybuowany moduł należy uzgodnić z operatorem odpowiednio do modelu współpracy.

Import korzysta z OR11 z paginacją; to nie jest implementacja masowego eksportu historycznego. Domyślny cykl wynosi 15 minut. Odczyty kolejnych stron i aktualizacje znanych zamówień mają wspólny limit jednego OR11 na minutę. Duży zaległy import wydłuża oczekiwanie na odświeżenie i operacje wychodzące.

Rozwój i sprawdzenie

Wymagany Node.js 20+ oraz dostęp do rejestru npm Orbito dla @orbito/api-lib@3.11.0.

npm ci --ignore-scripts
npm test
npm run check
node scripts/check-frontend.js /sciezka/do/orbito-front
omm pack --dry-run
omm pack -o /sciezka/do/core-mirakl-0.1.1.zip

Test frontendu korzysta z istniejącego checkoutu z zainstalowanymi zależnościami i obsługą instanceId; uruchamia jego kopię tymczasową. Nie zmienia checkoutu ani nie instaluje zależności.

Testy używają syntetycznych danych i atrap API. Obejmują izolację kont, płatności, sumy/VAT, paginację przy zmianie wyników, utratę odpowiedzi, brak uprawnień do dokumentów, konfigurację i rzeczywisty renderer interfejsu Orbito. Nie zastępują testu HTTP przez produkcyjny backend Orbito.

Źródła kontraktu

Mirakl Marketplace — Seller API.
Oficjalna kolekcja Postman Mirakl — również multipart OR74, którego brakuje w aktualnym eksporcie OpenAPI.
Media Expert — klucz API.

Opis implementacji i obsługi awarii: docs/ARCHITEKTURA.md.

Import od wersji 0.1.5

Wymaga Produktów 1.1.42, Zamówień 2.14.13 i Fakturowania 0.12.3. Importuje wszystkie stany zamówień w ustawionym zakresie dat, w tym zakończone i anulowane. Brak NIP, adresu, SKU, VAT lub niespójne kwoty nie wykluczają rekordu z Orbito. Uwagi są zapisane przy zamówieniu. Historia oraz zamówienia z nieustalonymi kwotami/VAT nie uruchamiają automatyzacji nowej sprzedaży. Pozostałe nowe zamówienia, również z brakami NIP lub adresu, podlegają zwykłym automatyzacjom i walidacji odpowiednich modułów Orbito. Niezatwierdzone kwoty i VAT nie są przekazywane do katalogu ani fakturowania; Orbito pokazuje je jako wymagające uzupełnienia. Po korekcie pozycji użytkownik zatwierdza dane w szczegółach zamówienia.

Aktualizacja jednokrotnie odczytuje ponownie skonfigurowany zakres, uwzględniając dotychczas pominięte zamówienia bez tworzenia duplikatów. Sklepy nadal mają odrębne powiązania. Jeśli platforma nie udostępnia typu etykiety PDF, konfiguracja pokazuje wyjaśnienie zamiast pustej listy. Typy systemowe potwierdzeń dostawy, załączników wiadomości i zwrotów nie są zamiennikami etykiety przewozowej.

Własne logo źródła

W panelu wybranego marketplace (Ustawienia → Zamówienia → nazwa integracji) sekcja „Logo źródła zamówień” umożliwia wgranie, zmianę i usunięcie obrazu PNG/JPG/WebP do 5 MB. Moduł przygotowuje miniaturę i zapisuje ją w konfiguracji konkretnej instalacji oraz natywnym profilu źródła Orbito. Logo wyświetla się również przy starszych zamówieniach. Ustawienie przetrwa aktualizację i ponowne połączenie. Paczka modułu nie zawiera logotypów firm.

Granice odpowiedzialności

Marketplace: fakty transakcji, SKU, ilość, brutto sprzedaży, kupujący, adres, płatność i status zewnętrzny.
core/products: dane podstawowe produktów, VAT i skład zestawów.
core/orders: powiązanie pozycji z katalogiem, wyliczenia i zapis danych zamówienia; lokalne poprawki nie są nadpisywane kolejnym odczytem marketplace.
core/invoicing: wystawianie, rejestr i PDF faktur. Mirakl tylko przekazuje gotowy dokument powiązany z zamówieniem.
core/shipping: tworzenie przesyłek, przewoźnik, tracking i PDF etykiety. Mirakl tylko przekazuje wynik.

Nowy kontrakt nie przelicza automatycznie wcześniej zapisanych zamówień ani wystawionych dokumentów.

Systemowe formy płatności (0.1.13)

Forma płatności jest kodem słownika core/orders payment.codes; etykietę nadaje Orbito. Marketplace pozostaje wyłącznie źródłem zamówienia. Rozpoznawane są znane kody instrumentów płatniczych oraz workflow pobrania/odroczonego terminu. Brak jednoznacznej metody daje unknown — potwierdzenie obciążenia ani status realizacji nie pozwalają zgadywać karty lub przelewu. Stan opłacenia wynika osobno z natywnego rejestru wpłat.

Istniejące zamówienia są porządkowane partiami na podstawie zapisanego snapshotu, również historia i rekordy po zakończeniu 7-dniowego monitorowania. Natywne payment.normalizeSource weryfikuje wywołującą instancję i identyfikator konta/zamówienia, zmienia tylko stare etykiety/kod i flagę COD. Nie zmienia kwot, dat, statusu opłacenia ani automatyzacji. Znane natywne kody i ręcznie poprawione etykiety pozostają bez zmian; synchronizacja nie odtwarza ani nie nadpisuje istniejącej wpłaty o tym samym identyfikatorze transakcji. Kontrolna metoda payment.inspect przyjmuje remoteId i zwraca wyłącznie informacje o klasyfikacji i stanie płatności.

Stabilizacja po audycie (0.1.14)

Najpierw zaktualizuj core/orders do 2.14.13, następnie tę instalację Mirakl. Konfiguracja kont, zakres dat, kursor importu, powiązania zamówień i ukończone zadania pozostają zachowane. Nie wykonujemy ponownego importu całej historii ani czyszczenia wpłat. Nie trzeba podawać ponownie kluczy API.

Core nadaje nowym importom stabilną tożsamość i odzyskuje zapis po utracie odpowiedzi. Istniejące duplikaty, usunięte zamówienia i ponowna instalacja tego samego konta wymagają rozstrzygnięcia; nie powstaje automatycznie kolejna kopia.
Potwierdzenie płatności uzupełnia tylko brakującą kwotę w natywnym rejestrze. Istniejące skorygowane transakcje oraz ręczne usunięcia są respektowane. Po ręcznym usunięciu wpłaty importer nie uzupełnia salda automatycznie; dalszą korektę wykonuje użytkownik w Orbito. Historycznych nadpłat nie kasujemy.
Limit 7 dni dotyczy monitorowania płatności, a nie ponawiania importu ani dokumentów. Zdarzenie Orbito może odświeżyć stan realizacji bez wznowienia monitorowania i dopisywania spóźnionej wpłaty.
Anulowane przesyłki nie są przekazywane. Gotowy PDF etykiety nie zależy od mapowania przewoźnika. Zmiana wcześniej wysłanej etykiety jest sygnalizowana i wymaga zatwierdzenia przekazania nowej wersji.
Ponowienie niewysłanego zadania korzysta z aktualnej konfiguracji. Upload o nieznanym wyniku nadal wymaga sprawdzenia, czy dokument już dotarł.
Po sprawdzeniu zmiany adresu/pozycji można ją zatwierdzić w szczegółach zamówienia. Nie zmienia to statusu realizacji i nie odblokowuje anulowania ani zwrotu.
Faktury „Faktura (bez VAT)” i „Faktura VAT marża” są obsługiwane. Proformy i korekty pozostają poza automatycznym przekazywaniem.
Nowe połączenie zamówień zachowuje wymóg zatwierdzenia danych finansowych. Wspólne faktury i przesyłki agregatu nadal wymagają ręcznego przekazania; panel wskazuje powiązane zamówienie. Nie rozszerzamy automatycznie zakresu dokumentu na różne transakcje/marketplace.

Przebudowa układu ustawień jest osobnym etapem. Stare mappery pozostają wyłącznie dla zgodności istniejących testów; aktywny import korzysta z mapImport.

Surowe płatności i nazwa przewoźnika (0.1.15)

Wymagane Zamówienia 2.14.14. Nowa zasada zastępuje wcześniejsze tłumaczenie etykiet z 0.1.13: paymentMethod zawiera surowy payment_workflow, np. PAY_ON_ACCEPTANCE, PAY_ON_DELIVERY, PAY_ON_SHIPMENT. Jeśli workflow nie ma, zachowuje payment_type, a przy braku obu pól zapisuje „Nieznana”. Kody systemowe i stan opłacenia pozostają niezależne. Pobranie wynika z jawnych danych płatności; dla importów zewnętrznych core nie wnioskuje go po nazwie przewoźnika.

delivery.carrierName to shipping_company, ewentualnie nazwa ze słownika dla shipping_carrier_code. Nie używa etykiety ani kodu sposobu dostawy, nazwy marketplace czy domysłów na podstawie adresu/punktu. Brak danych daje puste pole; późniejszy odczyt może uzupełnić przewoźnika. Sam odczyt nazwy nie tworzy przesyłki ani etykiety.

Istniejące zamówienia są uzupełniane partiami z zapisanych odpowiedzi, także historia. Nadpisywane są wyłącznie rozpoznane dotychczasowe etykiety integracji; odmienne ręczne wartości pozostają zachowane. Kwoty i stare wpisy wpłat nie są zmieniane. Nie ma ponownego importu historii.

Mapowanie nazw dla zamówień należy do konfiguracji tej instancji Mirakl. Ustawienia metod dokumentów księgowych są niezależne od tego mapowania.

Dane źródłowe płatności, dostawy i NIP (0.1.16)

Wymaga Zamówień 2.14.15. Źródłowa nazwa płatności pochodzi z nieprzetłumaczonego payment_type; przy pustej wartości z payment_workflow, a przy braku obu z UNKNOWN. Przykład: CARD ma pierwszeństwo przed PAY_ON_ACCEPTANCE. Workflow nadal niezależnie określa pobranie/odroczony termin; stan opłacenia pochodzi z potwierdzonych wpłat. Od 0.1.18 nazwę w zamówieniu można przypisać w konfiguracji tej instancji Mirakl.

Dostawa korzysta z shipping_company lub słownika przewoźników. Gdy przewoźnik nie jest jeszcze udostępniony, pokazuje nazwę sposobu dostawy z API. Znany przewoźnik ma pierwszeństwo i pozostaje zapisany także przy późniejszej niepełnej odpowiedzi.

NIP jest odczytywany z organizacji klienta, skonfigurowanego dodatkowego pola, jawnych pól podatkowych adresu fakturowego i rozpoznanych kodów dodatkowych pól, np. nip, customer-nip, invoice-nip, vat-number. billing_address.company_2 jest używane tylko dla numeru z oznaczeniem NIP/VAT/TAX ID lub polskiego NIP z poprawną sumą kontrolną. Numer rejestrowy organizacji nie jest traktowany jako NIP. Sprzeczne automatyczne pola wymagają wskazania właściwego kodu w konfiguracji.

Aktualizacja uzupełnia starsze zamówienia partiami po 40 z zapisanego snapshotu, również historię. NIP jest dopisywany tylko do pustego pola przy zgodnej nazwie nabywcy. Zmiany ręczne, wpłaty, kwoty i statusy opłacenia pozostają zachowane; nie jest odtwarzany import ani uruchamiane automatyzacje nowej sprzedaży. Pola udostępnione dopiero później zostaną odczytane podczas zwykłej synchronizacji.

0.2.1 — wybór statusów przy wielu instalacjach

Lista statusów w konfiguracji jest pobierana przez hook podczas otwierania sekcji i przekazywana jako gotowe opcje. Wyszukiwanie nazw działa również przy kilku instalacjach Mirakl w jednej firmie. Zapisane identyfikatory statusów pozostają bez zmian. Gdy lista jest niedostępna, konfiguracja pokazuje komunikat zamiast samej pustej listy.

0.2.4 — dane produktu i VAT z marketplace

Wymaga Zamówień 2.18.3. Import zachowuje product_title, zdjęcie z product_medias oraz podatki pozycji i dostawy. Jeśli Mirakl nie przekazuje podatku, używa sync.defaultTax (domyślnie 0.23, wybór w konfiguracji instancji). Jawne 0% pozostaje 0%; sprzeczne dane nadal wymagają weryfikacji. Katalog uzupełnia brakujące dane i zarządza zestawami, ale importer nie zapisuje do katalogu.

Usunięto wkład views.orderDetails. Diagnostyka, odświeżenie i zatwierdzanie pozostają w panelu tej integracji. Podczas ponownego odczytu zamówienia hook orders.source.repairImportedProducts może naprawić wyłącznie niezatwierdzone starsze pozycje techniczne (SKU jako nazwa, brak powiązania z katalogiem), o niezmienionej kwocie, ilości i niezmienionych technicznych danych pozycji i kosztu dostawy. Naprawa zachowuje status, wpłaty, dane pakowania i ręczne notatki; nie uruchamia automatyzacji sprzedaży.

0.2.5 — naprawa bez oczekiwania na następne pobranie

Przy starcie integracja przegląda partiami zapisane, niezatwierdzone importy. Jeśli aktualny odcisk transakcji zgadza się z oryginalnym snapshotem i techniczne dane pozycji i kosztu dostawy nie zostały zmienione, ta sama chroniona ścieżka hooka uzupełnia produkt i VAT z tego snapshotu. Nie wymaga dodatkowego wywołania API Mirakl ani powtórzenia operacji na marketplace.

0.2.7 — kontrola pól naprawianych

Naprawa porównuje pozycje i koszt dostawy, zachowując niezależne uzupełnienia przewoźnika, odbiorcy i faktury. Ręcznie zmienione ceny, ilości, VAT i koszt dostawy nadal wykluczają naprawę. Podatek przekazany jako sama kwota musi potwierdzać skonfigurowaną stawkę domyślną.

0.2.8 — miniatury JPG

Obsługa skróconych formatów mediów (JPG, PNG) oraz pełnych typów MIME. Hook naprawy obsługuje imagesOnly: uzupełnia wyłącznie puste zdjęcia pozycji marketplace, zachowując wszystkie pozostałe dane i istniejące miniatury. Zapisane snapshoty są przeglądane partiami bez dodatkowego pobierania zamówień.

Puste dane osoby w adresie (0.2.11)

Wypełniacze złożone wyłącznie z podkreśleń i myślników nie są imieniem ani nazwiskiem. Import pomija je w danych odbiorcy i osoby na fakturze; istniejące niezmienione wypełniacze osoby na fakturze są czyszczone przez kontrakt źródła. Nazwa firmy i NIP pozostają danymi źródłowymi — nazwa podobna do imienia i nazwiska nie jest automatycznie przenoszona. Wymaga Zamówień 2.18.6.

Błąd pojedynczego starego powiązania nie zatrzymuje aktualizacji pozostałych opisów. Błędne rekordy są odkładane na godzinę, a problem pozostaje w diagnostyce. Metody administracyjne source.inspect i sync.presentation przyjmują remoteId: pierwsza porównuje zapisane dane źródła i lokalnego nabywcy, druga odświeża wyłącznie opisy z zapisanego źródła, bez ponownego importu lub dopisywania wpłat.

Brakujące kartoteki produktów (0.2.11)

Import korzysta z tworzenia brakujących SKU przez właściciela zamówień. Starsze zamówienia są uzupełniane hookiem orders.source.syncCatalog partiami po 40. Poprawne dane źródłowe tworzą kartotekę z nazwą, zdjęciem, ceną i VAT oraz łączą pozycję przez productId. Istniejące kartoteki nie są aktualizowane danymi historycznej sprzedaży. Pozycje wymagające weryfikacji finansowej czekają na poprawę. sync.presentation uzupełnia również brakujące kartoteki wskazanego zamówienia.

Synchronizacja przekazuje sourcePrices: true: dopisuje konto Mirakl jako źródło również do istniejących SKU, zachowując ręczne dane katalogowe. Wersja synchronizacji katalogu 2 ponownie przetwarza wcześniejsze mapowania oznaczone wersją 1. Wymaga flag możliwości idempotentSourceCatalogPrices i sourceProductMetadata u dostawcy zamówień.

EAN pochodzi z product_references oferty OF22 (GET /api/offers/{offer_id}, z ID bieżącego sklepu), po sprawdzeniu ID oferty, shop_sku, opcjonalnego product_sku i sumy kontrolnej EAN/GTIN. SKU nie jest traktowane jako EAN. Sprzeczne kody wymagają weryfikacji; brak kodu lub błąd API nie zatrzymuje importu. Maksymalnie 5 nowych odczytów ofert na przebieg, cache jest oddzielny dla konta i tożsamości oferty. Poprawny kod jest przechowywany przez 24 godziny, brak lub błąd przez godzinę. Starszym pozycjom uzupełniane są wyłącznie puste EAN-y, bez zmian kwot, pakowania i składników BOM. Surowy snapshot zamówienia pozostaje bez zmian. source.inspect zwraca EAN-y i productMetadataWarnings; sync.presentation uruchamia również tę synchronizację dla wybranego zamówienia.

Mirakl (Media Expert, Leroy Merlin, Castorama)