W lipcu 2026 IdoSell wprowadził 55 zmian. Przeszedłem je po kolei w panelu i opisuję, co każda oznacza w praktyce: gdzie znaleźć nową opcję, co trzeba ustawić i co sprawdzić u siebie w sklepie.
Z początkiem lipca 2026 zaczęły obowiązywać nowe stawki VAT OSS. Zaktualizowaliśmy matrycę stawek w module podatków i rozliczeń, tak aby była zgodna z aktualnymi wartościami.
Niestety nie znalazłem konkretów co zostało zmienione, więc wysłałem kilku agentów AI aby zbadali za mnie ten temat. Raport znajduje się poniżej:
Co weszło 1 lipca 2026 w krajach unijnych: Austria obniżyła stawkę na wybraną żywność podstawową z 10% na 4,9% (bezterminowo), a Łotwa z 21% na 12% na chleb, świeże mleko, świeże mięso drobiowe i jaja w skorupkach (czasowo, do 30 czerwca 2027).
Obie te zmiany dotyczą stawek obniżonych, a IdoSell dobiera je po kodzie CN/TARIC z sekcji Podstawowe na karcie towaru. Bez kodu CN system poda wyłącznie stawkę podstawową kraju dostawy, czyli Austrii 20%, a Łotwie 21%. Aktualizacja matrycy sama z siebie nie zmieni Ci nic.
Ręcznie zdefiniowane stawki w Produkty (PIM) > Kategorie mają pierwszeństwo przed matrycą. Wyjątek wpisany kiedyś na sztywno przeżyje każdą aktualizację i dalej będzie blokował nową wartość.
Zależy od ustawienia w Ustawienia > Podatki i rozliczenia. Przy Wyliczaj wartość VAT od ceny: netto zmieni się cena brutto widoczna dla klienta. Przy od ceny brutto cena na witrynie zostaje, a przeliczy się netto, czyli obniżka stawki wchodzi po cichu w Twoją marżę. Przy zmianie w drugą stronę ten sam mechanizm marżę zjada.
Stawkę konkretnego towaru sprawdzisz poprzez kliknięcie Stawka VAT na karcie towaru jak pokazano na fotce poniżej:
Poprawiliśmy przekazywanie wartości sprzedaży w plikach XML faktur zaliczkowych i końcowych wysyłanych do KSeF. Wcześniej w scenariuszu z dwiema pozycjami o zerowym VAT kwoty bywały zawyżane o koszt transportu. Po zmianie wartości w pliku XML są zgodne z rzeczywistą sprzedażą.
Stawka 0% w Polsce nie dotyczy powszechnej żywności, tylko transakcji międzynarodowych i wąskich kategorii wymienionych w ustawie. Jeśli wystawiasz faktury zaliczkowe z takimi pozycjami, porównaj wartość sprzedaży w pliku XML z wartością zamówienia. To tam doliczał się koszt transportu.
Poprawiliśmy fakturę końcową (rozliczeniową) wysyłaną do KSeF tak, aby prawidłowo pomniejszała kwotę do zapłaty o wartość wykazaną wcześniej na fakturze zaliczkowej. W niektórych sytuacjach kwota na fakturze końcowej nie była pomniejszana o wszystkie wcześniejsze wpłaty, przez co suma faktury zaliczkowej i końcowej przewyższała wartość zamówienia. Po zmianie suma obu dokumentów jest zgodna z wartością zamówienia.
Jeśli rozliczasz zaliczki, zsumuj fakturę zaliczkową i końcową z dokumentów z przełomu czerwca i lipca. Suma ma się zgadzać z wartością zamówienia.
Doczekaliśmy się aktualizacji KSEF i sądząc po ilości napływach komunikatów z propozycjami zmian ten moduł będzie jeszcze przechodził kolejne iteracje zmian.
Na karcie zamówienia możliwe jest pobranie faktury KSeF w strukturze FA(3), na podstawie aktualnych danych z zamówienia. Wygenerowany dokument można zaimportować w Aplikacji Podatnika, jeśli zajdzie potrzeba ręcznego wystawienia dokumentu.
Na karcie zamówienia, w sekcji Dokumenty, przy zarejestrowanej fakturze masz teraz linki XML [pobierz] i UPO [pobierz].
Plik wychodzi w strukturze FA(3), czyli tej, która od 1 lutego 2026 zastąpiła FA(2) i obowiązuje dla wszystkich faktur ustrukturyzowanych. Możesz go wczytać w Aplikacji Podatnika KSeF, jeśli musisz wystawić albo poprawić dokument poza sklepem. Obok XML-a pobierzesz też UPO.
Udostępniliśmy widoczność wszystkich utworzonych dokumentów oraz możliwość pobrania pliku XML do każdego z nich.
W sekcji Dokumenty na karcie zamówienia widzisz wszystkie wystawione dokumenty sprzedaży i przy każdym pobierzesz plik XML: fakturę VAT, fakturę zaliczkową i korektę. To dokumenty, które trafiają do KSeF.
Zmieniliśmy moment udostępnienia faktury klientowi. Wizualizacja dokumentu zostaje wysłana (EDI) oraz pokazana w podsumowaniu zamówienia na stronie sklepu dopiero po uzyskaniu numeru KSeF.
Krótko mówiąc zanim zostanie przedstawiona klientowi faktura w mailu lub w szczegółach złożonego zamówienia najpierw musi zostać zaakceptowana przez KSEF.
Przed wygenerowaniem dokumentu automatycznie weryfikujemy poprawność i kompletność ustawień integracji. Niepoprawna konfiguracja nie pozwoli na wystawienie faktury.
Zanim system wygeneruje dokument, sprawdza kompletność ustawień integracji. Niepoprawna konfiguracja zatrzymuje wystawienie faktury zamiast wypuścić ją do KSeF i odebrać odrzucenie.
Jeśli KSeF nie zarejestruje faktury z powodu błędu, możliwe jest poprawienie danych zamówienia i klienta bez wystawiania faktury korygującej, a następnie ponowne wygenerowanie dokumentu i ponowienie próby przekazania dokument do KSeF pod tym samym numerem wewnętrznym.
Poprawiasz dane zamówienia i klienta, generujesz dokument ponownie i wysyłasz go pod tym samym numerem wewnętrznym. Wcześniej było wymagane wystawienie faktury korygującej co było mega uciążliwe.
Dodaliśmy kompleksową obsługę trzeciego odbiorcy w przypadku jednostek samorządu terytorialnego. Na karcie klienta możliwe jest ustawienie odpowiedniej roli odbiorcy (Podmiot3), a system automatycznie dodaje wymagane oznaczenie w strukturze faktury FA(3).
Na karcie klienta, w sekcji Dane firmy, doszła opcja Oznaczenie JST dla Podmiot3 w KSeF z wyborem nie/tak.
W strukturze FA(3) „Podmiot3" to rola trzeciej strony transakcji. Przy jednostkach samorządu terytorialnego nabywcą jest gmina, a odbiorcą faktury bywa jej jednostka podległa, na przykład szkoła. Zaznaczenie opcji sprawia, że system sam dodaje wymagane oznaczenie w pliku faktury.
W ustawieniach integracji KSeF dodaliśmy wybór pól, które są przekazywane do faktury KSeF.
W Ustawienia > Podatki i rozliczenia > Integracja z KSeF doszła sekcja Informacje na fakturze przekazywane do KSeF z dziewięcioma polami do wyboru.
Do wyboru masz: adres e-mail sklepu, numer telefonu sklepu, adres e-mail klienta, numer telefonu klienta, numer konta bankowego sklepu, numer BDO, numer REGON, KRS i numer EORI. Zaznaczasz tylko to, co faktycznie ma iść do KSeF.
Naprawiliśmy zapisywanie konfiguracji synchronizacji dla dostawców typu „idosell". Wcześniej link do pliku XML nie zapisywał się mimo komunikatu o powodzeniu. Po zmianie konfiguracja zapisuje się poprawnie.
Ustawienie znajdziesz w konfiguracji dostawców: przy Synchronizuj towary od dostawcy: tak pojawia się pole Adres URL oferty w formacie IOF 3.0.
Jeśli kiedykolwiek wkleiłeś tam link, dostałeś komunikat o powodzeniu, a po powrocie na ekran było pusto.
W szczególnym scenariuszu zdarzało się, że klienci mający już aktywne konto w sklepie i składający wcześniej zamówienia otrzymywali przy kolejnych zakupach wiadomości przeznaczone dla nowych klientów — takie jak powitanie w sklepie czy potwierdzenie założenia konta. Zadbaliśmy o to, aby tego typu wiadomości trafiały wyłącznie do osób, które rzeczywiście dopiero zakładają konto. Dzięki temu komunikacja e-mail jest lepiej dopasowana do etapu relacji z klientem.
Sprawdziłem to na nowym koncie w sklepie testowym. Przy pierwszym zamówieniu dostałem powitanie w sklepie, przy drugim już tylko potwierdzenie zamówienia. Wcześniej klienci z aktywnym kontem potrafili dostawać wiadomości przeznaczone dla nowych przy każdym kolejnym zakupie.
W ustawieniach panelu dodaliśmy nową opcję „Tryb wyszukiwania numerów paczek”, pozwalającą wybrać sposób wyszukiwania zamówień po numerze paczki lub przesyłki. W trybie Szybkim system znajduje zamówienia zawierające pełny wpisany numer lub zaczynające się od niego — dzięki temu wyszukiwanie działa znacznie szybciej, nawet przy bardzo dużej liczbie zamówień. W trybie pełnym wpisana fraza może być dowolną częścią numeru paczki lub przesyłki (dotychczasowe zachowanie), kosztem dłuższego czasu wyszukiwania. Merchant sam decyduje, który tryb lepiej odpowiada jego potrzebom.
Samo wyszukiwanie po fragmencie numeru u mnie działa, ale opcji Tryb wyszukiwania numerów paczek w ustawieniach panelu nie znalazłem.
Udostępniliśmy w szablonach formularza zwrotu zmienną KZS (kod zewnętrznego systemu). Można ją teraz umieścić w szablonie wydruku zwrotu i prezentować tę informację na formularzu.
Literał, którego potrzebujesz, to [iai:product_code2], opisany na liście zmiennych jako Kod zewnętrznego systemu.
Ważne, gdzie ją umieścisz: zmienna działa wewnątrz listy produktów, czyli między [iai:foreach_return_products_list-begin] a [iai:foreach_return_products_list-end]. Poza tą pętlą nie ma dostępu do danych pojedynczego towaru.
Poprawiliśmy wyliczanie kwoty do zwrotu, gdy waluta płatności różni się od waluty rozliczeniowej zamówienia. Wcześniej kwota i waluta wypłaty mogły się nie zgadzać, co wprowadzało w błąd obsługę i klienta. Po zmianie kwota do zwrotu jest wyliczana w prawidłowej walucie.
Dotyczy sklepów, w których klient płaci w innej walucie niż waluta rozliczeniowa zamówienia, na przykład w euro przy rozliczeniu w złotówkach. Przy najbliższym takim zwrocie sprawdź, czy kwota i waluta wypłaty się zgadzają.
Zoptymalizowaliśmy skrypt przypisujący i odpisujący klientów do grup rabatowych. Wcześniej jego długie działanie potrafiło blokować proces tworzenia zamówień subskrypcyjnych. Po zmianie oba procesy działają płynniej, bez wzajemnego blokowania.
Efekt jest po stronie serwera: skrypt grup rabatowych nie blokuje już tworzenia zamówień subskrypcyjnych.
Dość ciekawa zmiana tego miesiąca. Nie było tego w changelogu, ale IdoSell ogłosił moduł osobnym wpisem 23 lipca 2026.
Znajdziesz go w Zamówienia → Automatyzacje.
Reguła składa się z trzech części. Wybierasz zdarzenie, które ją uruchamia, dokładasz warunki, które zamówienie musi spełnić, i wskazujesz akcje do wykonania. Na zrzucie widać gotowy przykład: zamówienie o wartości większej niż 1000 ustawia prowadzącego i dopisuje notatkę „Do obsługi przez Handlowca".
Liczby warunków i akcji w jednej regule nie są ograniczone.
| Zdarzenie |
|---|
| Zamówienie zostało dodane |
| Zamówienie zostało zmienione |
| Zamówienie zostało opłacone |
| Dokument sprzedaży został wystawiony |
| Dokument EDI został wysłany |
| Klient odebrał dokument EDI |
| Została osiągnięta „Wybrana przez klienta data doręczenia / odbioru zamówienia" |
| Została osiągnięta „Planowana data pakowania zamówienia" |
| Została osiągnięta „Planowana data wysłania / odbioru zamówienia" |
| Przypisany został numer nadania paczki |
| Został osiągnięty termin preferowanej daty wysłania / odbioru |
| Przypisany został numer seryjny towarów |
| Zamówienie zmieniło status |
| Zamówienie zostało zweryfikowane |
| Zamówienie istnieje określoną liczbę dni |
| W statusie przez określoną liczbę dni |
| Nie zostało opłacone przez określoną liczbę dni |
| Zamówienie dropshipping zmieniło status |
| Wystąpił błąd generowania etykiety kurierskiej |
| Towar został przyjęty na magazyn realizujący |
| Zaksięgowano zaliczkę |
Stan na sierpień 2026. IdoSell zastrzega, że lista zdarzeń, warunków i akcji jest otwarta i rozbudowywana. Dokumentacja wymienia już warunki, których w moim panelu nie było, między innymi dane punktu odbioru, załączniki do zamówienia, parametry produktów i prowadzącego zamówienie.
Pogrupowałem je, żeby dało się to przeczytać. W panelu siedzą w jednej długiej liście, uporządkowanej nie po polskich nazwach, tylko po technicznych nazwach pól. Dlatego „Ulica (billingowy)" wypada między „Nazwiskiem" a „NIP-em". Dopiski (billingowy) i (dostawy) zostawiam poniżej tylko w nagłówkach grup, ale w panelu ma je każda pozycja.
| Grupa | Warunki |
|---|---|
| Dane billingowe | Miasto, Nazwa firmy, Kraj, Imię, Nazwisko, Ulica, NIP, Kod pocztowy |
| Dane dostawy | Miasto, Nazwa firmy, Kraj, Imię, Nazwisko, Ulica, Kod pocztowy |
| Klient | Adres e-mail, Typ klienta, Klient znajduje się na czarnej liście, Uwagi od klienta, Inne niezrealizowane zamówienia tego klienta |
| Zamówienie | Status, Typ zamówienia, Źródło zamówienia, Sklep, Waluta, Data utworzenia, Zamówienie jest zweryfikowane |
| Pieniądze | Wartość zamówienia, Wartość samych produktów, Koszt przesyłki, Zamówienie jest opłacone, Wpłata do zamówienia, Rodzaj płatności |
| Dokumenty | Wystawiony dokument sprzedaży, Prośba o wystawienie faktury, Odebrany dokument EDI |
| Towary | Ilość towarów w zamówieniu, Ilość pozycji (SKU) w zamówieniu, Typ towaru, Towary oznaczono jako spakowane, Towary mają przypisane numery seryjne, Towary znajdują się na magazynie realizującym, Towary znajdują się na wskazanym magazynie, Magazyn realizujący zamówienie |
| Wysyłka | Kurier, Przypisany numer nadania paczki, Status przesyłki kurierskiej, Status dostawcy dropshipping |
| Czas | Zamówienie istnieje określoną liczbę dni, W statusie przez określoną liczbę dni, Nieopłacone prze [sic] określoną liczbę dni, Liczba dni do planowanej daty pakowania, Liczba dni do planowanej daty wysłania / odbioru zamówienia, Liczba dni do wybranej przez klienta daty doręczenia / odbioru zamówienia |
Uwaga na warunki liczone w dniach. Według dokumentacji „Zamówienie istnieje określoną liczbę dni" i „W statusie przez określoną liczbę dni" działają wyłącznie w trybie „równa się X dni", bez zakresów w rodzaju „więcej niż 5 dni". Reguła „przypomnij po tygodniu" musi więc trafić dokładnie w siódmy dzień.
| Akcja |
|---|
| Dodaj notatkę |
| Ustaw prowadzącego zamówienie |
| Zmień status zamówienia |
| Wystaw dokument sprzedaży |
| Wygeneruj dokument własny |
| Przekaż zamówienie do realizacji u dostawcy dropshipping |
| Wygeneruj przesyłkę do zamówienia |
| Wyślij dokument EDI |
| Przekaż zamówienie do realizacji Fulfillment |
| Oznacz towary jako spakowane |
Większość z nich wynika z dokumentacji modułu i z wpisu zapowiadającego. Punkt trzeci to mój wniosek: dokumentacja o działaniu wstecz nie wspomina w ogóle. Żadnej z tych rzeczy nie zobaczysz, patrząc na sam formularz.
System wykrywa zapętlenia i taka reguła dostaje status „Błąd" zamiast kręcić się w kółko, a każde wykonanie zapisuje się w historii zamówienia. Moduł mieści się w dotychczasowych planach abonamentowych, bez dopłat, i wymaga uprawnień operatora do modułów Administracja i ustawienia oraz Zamówienia.
Dodaliśmy webhooki dla zdarzeń związanych z subskrypcjami — utworzenia nowej i edycji istniejącej — wraz z podstawowymi danymi z karty subskrypcji. Wcześniej takie zdarzenia nie były udostępniane przez webhooki. Po zmianie merchant może zintegrować subskrypcje z zewnętrznymi narzędziami.
| Zdarzenie | Kiedy leci |
|---|---|
subscriptionCreated | powstaje nowa subskrypcja |
subscriptionUpdated | zmieniają się dane istniejącej |
subscriptionCancelled | subskrypcja zostaje anulowana |
subscriptionOrderCreated | z subskrypcji powstaje kolejne zamówienie |
Anulowanie i cykliczne zamówienie to z punktu widzenia integracji dwa najważniejsze zdarzenia w zestawie, bo na nich stoi rozliczanie i pozwala wysyłać zdarzenia do innych systemów jeśli subskrybcja jest anulowana.
Jest warunek, o którym changelog nie wspomina, a panel owszem: „Brak dostępu do modułu. Aby umożliwić wysyłanie zdarzeń zaktualizuj uprawnienia klucza API." Dopóki klucz nie ma uprawnień do modułu subskrypcji, zaznaczenie zdarzeń niczego nie da. Uprawnienia ustawisz w konfiguracji tego samego klucza.
Sama sprzedaż subskrypcyjna w IdoSell wymaga aktywnych płatności kartowych IdoPay i szablonu, który ją obsługuje.
Naprawiliśmy domyślny wybór osoby prowadzącej przy dodawaniu reklamacji z poziomu karty zamówienia. Wcześniej zawsze podpowiadany był ostatni użytkownik panelu. Po zmianie lista operatorów jest ujednolicona, a wybór prowadzącego działa poprawnie.
Lista operatorów jest teraz posortowana alfabetycznie. Wcześniej system podpowiadał ostatniego użytkownika panelu, co przy większym zespole oznaczało przypisywanie reklamacji przypadkowej osobie.
Naprawiliśmy anulowanie należności w raporcie nieopłaconych i przeterminowanych należności z kredytem kupieckim. Wcześniej zamówienie potrafiło pozostawać w raporcie mimo próby anulowania. Po zmianie należności można prawidłowo anulować.
Przycisk [Anuluj] przy zadeklarowanej wpłacie działa poprawnie, więc zamówienie znika z raportu nieopłaconych i przeterminowanych należności.
Uzupełniliśmy raport „Lista sprzedanych towarów” o kody/numery seryjne sprzedanych towarów. Wcześniej kolumna z numerami seryjnymi pozostawała pusta. Po zmianie merchant może sprawdzić, w którym zamówieniu sprzedał się towar o danym numerze seryjnym.
Kolumna Numer seryjny jest w raporcie, numery dają się też wybrać przy jego tworzeniu. Na pokazanym zrzucie poniżej jest u mnie pusta, gdyż w panelu testowym nie maj jej uzupełnionej.
Numery seryjne nadaje się aplikacją IdoSell Scanner, w jej menu Zamówienia > Przypisz numery seryjne (F3), skanując kod towaru przy pakowaniu. Wtedy raport pokaże, w którym zamówieniu wyszedł konkretny egzemplarz.
Zapytałem na szybko AI, do czego służą numery seryjne. Poniżej masz odpowiedź:
Ustabilizowaliśmy wystawianie ofert wielorozmiarowych, pobieranie zamówień i automatyczną aktualizację na TikTok Shop, a nieaktywne konto nie blokuje już edycji parametrów na karcie towaru. Dzięki temu sprzedaż na TikTok Shop działa stabilnie, a zamówienia trafiają do panelu bez zakłóceń.
Dodaliśmy obsługę kuriera DHL w Allegro One Box oraz nowe usługi Allegro One dla Słowacji i Czech, w tym opcję pobrania (COD) dla Słowacji. Dzięki temu sprzedawcy mogą zaoferować kupującym więcej metod dostawy i płatność przy odbiorze.
Na liście metod dostawy potwierdzam część czesko-słowacką: automaty paczkowe, kurier i odbiór w punkcie, wszystkie z dopiskiem One.
Dodaliśmy nowe metody dostawy Allegro International na Ukrainę (kurier, punkt odbioru, automaty paczkowe) z płatnością z góry. Dzięki temu sprzedawcy obsługują zamówienia wysyłane na Ukrainę bezpośrednio w panelu.
Allegro International dorzuciło trzy metody wysyłki na Ukrainę z płatnością z góry i wszystkie trzy są w panelu.
Konkretnie: Allegro International Automaty Paczkowe Ukraina, Allegro International Kurier Ukraina i Allegro International Odbiór w Punkcie Ukraina, wszystkie w domenie allegro.ua. Jeśli sprzedajesz przez Allegro i miałeś klientów z Ukrainy odbijających się od braku wysyłki, to jest zmiana dla Ciebie.
Poprawiliśmy działanie przycisku ręcznego wysłania e-paragonu (Wyślij do EDI) do Allegro. Dzięki temu ręczne przekazanie e-paragonu do serwisu przebiega bez błędów.
Dotyczy przycisku Wyślij do EDI na karcie zamówienia, którym ręcznie przekazujesz e-paragon do Allegro.
Przywróciliśmy pobieranie kodu EAN (GTIN) z Allegro do pola kodu producenta na karcie towaru. Ułatwia to sprzedawcom identyfikację i mapowanie produktów.
Kod trafia do pola kod producenta na karcie towaru. Jeśli zaciągasz oferty z Allegro do panelu, sprawdź, czy pole się uzupełnia.
Poprawiliśmy przekazywanie listy produktów do wyceny dynamicznej (Dynamic pricing) w Allegro. Dzięki temu ceny ofert dostosowują się zgodnie z ustawieniami sprzedawcy.
Jeśli korzystasz z Dynamic pricing na Allegro, sprawdź, czy ceny ofert nadążają za Twoimi ustawieniami.
Umożliwiliśmy sprzedawcom samodzielną edycję nazwy kuriera przekazywanej do feedu Amazona. Dzięki temu przewoźnik wskazany w Amazon odpowiada rzeczywistej wysyłce.
Możesz sam ustawić nazwę przewoźnika przekazywaną do feedu Amazona, zamiast godzić się na to, co system wyśle domyślnie. Nazwa jest brana z profilu dostawy wskazanego w konfiguracji integracji Amazon. Nazwy przekazywane w konfiguracji dostaw pobierane są z Konfiguracji kurierów.
Amazon pokazuje kupującemu przewoźnika, a rozjazd między deklaracją a rzeczywistością psuje wskaźniki jakości obsługi konta. Potwierdzenie mam od kilku klientów zintegrowanych z Amazon przez moduł w IdoSell.
Dodaliśmy notatkę informującą o nieodnalezieniu towaru dla zamówień z Amazon. Dzięki temu sprzedawca od razu wie, że zamówienie wymaga jego uwagi.
Naprawiliśmy przypadki samoczynnego wznawiania ofert, których nie dało się zamknąć. Dzięki temu zamknięcie oferty jest trwałe, a sprzedawca zachowuje kontrolę nad jej statusem.
Dodaliśmy walidację identyfikatora towaru i rozmiaru przy mapowaniu ofert, gdy podany rozmiar nie istnieje. Dzięki temu oferty mapują się na właściwe warianty produktu.
Przy mapowaniu ofert doszła walidacja identyfikatora towaru i rozmiaru, dzięki czemu oferta nie przypnie się do nieistniejącego wariantu. Mapowanie znajdziesz w Marketplaces > Sprzedaż przez marketplaces > [serwis] > Mapowanie ofert na istniejące towary
Rozszerzyliśmy moduł diagnostyki marketplace na dashboardzie o kolejne serwisy, w tym Amazon. Dzięki temu sprzedawca szybciej wychwytuje w jednym miejscu problemy z połączeniem kont.
Wszedłem na stronę główną panelu w nowym dashboardzie i takiego modułu tam nie ma.
Możliwe, że chodzi o inny ekran niż strona startowa panelu, ale changelog nie precyzuje, o który dashboard chodzi. Również nie znalazłem takiego dashboardu w zakładce Marketplaces - stan na 21.08.2026
Naprawiliśmy odrzucanie ofert przy tworzeniu produktów na Kauflandzie, gdy serwis zwracał przejściowy status przetwarzania - system cyklicznie sprawdza przez 7 dni utworzenie produktu zamiast kończyć proces błędem. Dzięki temu produkty i oferty poprawnie zostają wystawianie na Kaufland.
Kaufland przy tworzeniu produktu potrafi zwrócić status „jeszcze przetwarzam", a IdoSell traktował to jak błąd i kończył proces. Teraz system dopytuje cyklicznie przez siedem dni, aż produkt się utworzy.
Wdrożyliśmy zbiorczą aktualizację cen i stanów magazynowych w InPost oraz poprawiliśmy zapis danych po udanej aktualizacji. Dzięki temu duże asortymenty aktualizują się szybciej i pewniej.
Zamiast pojedynczych wywołań jest aktualizacja zbiorcza, do tego poprawiony zapis danych po udanej aktualizacji. Potwierdzenie mam od klienta korzystającego z tej integracji. Przy dużym asortymencie różnica między aktualizacją pojedynczą a zbiorczą decyduje o tym, czy stany nadążają za sprzedażą.
Poprawiliśmy pobieranie zamówień eMag z voucherami i bez waluty rozliczeniowej oraz odblokowaliśmy generowanie etykiet za pobraniem. Dzięki temu zamówienia trafiają poprawnie do panelu i można je normalnie obsłużyć.
Wiadomość o porzuconym koszyku (e-mail, SMS, ManagoAI) jest teraz wysyłana wcześniej – odliczanie startuje od chwili, gdy kupujący doda lub zmieni towar w koszyku, a nie dopiero gdy przejdzie do ostatniego kroku zamówienia. Dzięki temu sklep szybciej dociera do klienta, który wahał się z zakupem, co zwiększa szansę na odzyskanie sprzedaży.
Mam do tej pozycji wątpliwość. Reguła w Ustawienia > Wiadomości wyzwalane i tak każe odczekać zadany czas, więc przy klasycznym e-mailu wysyłanym po godzinie nic się nie zmienia. Zysk widać zapewne w integracji z ManagoAI, gdzie zdarzenie trafia do zewnętrznego systemu od razu.
W konfiguracji marketing automation (zakładka ManagoAI) pojawił się nowy przełącznik umożliwiający wyłączenie nocnej synchronizacji kontaktów z ManagoAI. Dzięki temu sklep lub support mogą samodzielnie zablokować automatyczne wysyłanie danych do MA w nocy.
Przełącznik jest dokładnie tam, gdzie zapowiedziano: Marketing > Automatyzacja marketingu zakładka Manago AI.
Nocna synchronizacja wypycha kontakty ze sklepu do ManagoAI. Przy migracji, czyszczeniu bazy albo diagnozowaniu rozjazdu danych zatrzymasz ją teraz sam, bez zgłoszenia do supportu.
Funkcja Google Tag Gateway jest teraz automatycznie aktywna u każdego klienta korzystającego z Google Ads by Idosell, nie trzeba jej już włączać ręcznie w ustawieniach. Dzięki temu dane o konwersjach trafiają do Google przez serwer sklepu (server-side), co poprawia dokładność pomiarów kampanii i uniezależnia śledzenie od blokad przeglądarek czy adblockerów.
Wszedłem na konta klientów korzystających z reklam Google prowadzonych przez IdoSell i nie znalazłem ani przełącznika, ani komunikatu, ani żadnego nowego ustawienia.
Wyjaśnienie jest w osobnym wpisie IdoSella o tej integracji: dla klientów usługi Reklamy Google od IdoSell integracja została uruchomiona po stronie platformy, bez żadnego elementu w panelu. Nie ma czego szukać, bo nie ma czego klikać. Sklepy prowadzące reklamy samodzielnie albo przez agencję dostaną tę funkcję później i wtedy będą ją włączać u siebie.
Google Tag Gateway serwuje tagi Google z domeny Twojego sklepu zamiast z domen Google, więc rzadziej łapią je blokery i ograniczenia dotyczące ciasteczek third-party. To nie to samo co pełne server-side tagging, bo pomiar dalej wykonuje się w przeglądarce. Zmienia się adres, spod którego idzie.
Moduł przekierowań obsługuje teraz adresy zawierające podwójny ukośnik „//" w środku ścieżki np. stare linki blogowe czy adresy powstałe po migracji. Dzięki temu sklep może poprawnie przekierować takie adresy kodem 301, zamiast serwować błąd 404, co chroni pozycję w wyszukiwarkach i zapewnia użytkownikom płynne przejście na właściwą stronę.
Zmiana, którą zweryfikujesz w dziesięć sekund. Adres https://zooart.com.pl/////-ciekawostki-bloglist-pol-11.html//// odpowiada kodem 301 i prowadzi na /blog/pies/pies-ciekawostki z kodem 200 mimo tego, że przekierowanie jest dodane bez aż tylu znaków "///"
Przekierowania konfigurujesz w Ustawienia > Domeny, SSL i przekierowania > Przekierowania i otwieranie stron w ramce. Po migracji z innej platformy przejrzyj logi 404 pod kątem takich adresów. Do tej pory nie dało się ich uratować regułą.
W konfiguracji stref rekomendacji na karcie towaru pojawiła się nowa opcja: wyświetlanie produktów, których ID są zapisane jako wartości wybranego parametru. Dzięki temu można tworzyć kilka niezależnych zestawów polecanych produktów dla różnych sklepów czy kontekstów, bez ograniczenia do jednej listy „Polecane z tym towarem". Wystarczy wskazać odpowiedni parametr w konfiguracji hotspotu, a rekomendowane towary uzupełniać na karcie edycji produktu.
W konfiguracji stref rekomendacji na karcie towaru doszła opcja produkty, których identyfikatory są wymienione jako wartości parametru.
Co to zmienia: do tej pory karta towaru miała w praktyce jedną listę „Polecane z tym towarem". Teraz możesz mieć kilka niezależnych zestawów, bo każdy siedzi w innym parametrze.
Konfiguracja jest dwuetapowa: w Sklep > Strefy produktów rekomendowanych > Karta towaru wskazujesz parametr, a same identyfikatory towarów wpisujesz na karcie produktu, w wartości tego parametru podane jako osobne wartości, tak jak przedstawiono na fotce poniżej:
Zmienna [iai:newsletter_removelink] generuje teraz prawidłowy link rezygnacji z newslettera nawet wtedy, gdy została wklejona w edytorze wizualnym panelu. Wcześniej edytor zamieniał nawiasy kwadratowe na znaki zakodowane (np. %5B), przez co system nie rozpoznawał zmiennej i link nie działał – klient klikał „wypisz mnie", ale trafiał na nieistniejącą stronę. Teraz wypisanie działa za pierwszym kliknięciem, bez względu na sposób wstawienia zmiennej w kreacji.
Jeśli wysyłasz newsletter z kreacji budowanej w edytorze wizualnym, kliknij link wypisu we własnej wiadomości testowej. Wcześniej edytor kodował nawiasy zmiennej [iai:newsletter_removelink] na %5B i %5D, przez co klient trafiał na nieistniejącą stronę.
Mechanizm przypisywania kodów rabatowych w programie partnerskim został poprawiony – kody są teraz generowane wyłącznie dla klientów z aktywnym statusem Partnera. Wcześniej system przydzielał kody również zwykłym klientom składającym zamówienie, co powodowało zamieszanie i utrudniało kontrolę nad programem. Po uzupełnieniu puli kodów w kampanii trafiają one teraz prawidłowo do właściwych kont partnerskich.
Sprawdziłem na dwóch kontach: partnerskie ma przypisane kody, zwykłe klienckie nie ma żadnych. Wcześniej system potrafił przydzielić kod każdemu klientowi składającemu zamówienie, co robiło bałagan w kampanii i w rozliczeniach.
Gdzie to zobaczysz: na karcie klienta, w sekcji Program partnerski, pozycja Kody rabatowe dostępne do rozdania w programie partnerskim pokazuje liczbę przypisanych kodów. Samą pulę i kampanię ustawiasz w Promocje i rabaty > Program partnerski.
Jeśli prowadzisz program partnerski, sprawdź przy okazji parametr Minimalna ilość zrealizowanych zamówień dopuszczająca do udziału w programie. To on decyduje, kto w ogóle zostaje Partnerem: przy zerze partnerem jest każde założone konto, przy jedynce wystarczy jedno zrealizowane zamówienie.
Trzynaście pozycji, w większości naprawy. Kilka z nich dotyczy pieniędzy, więc warte są sprawdzenia u siebie.
Oferta specjalna nie obniżała ceny towaru, mimo że w koszyku pojawiała się informacja o jej nałożeniu. Naprawiliśmy przeliczanie walut, dzięki czemu oferta obniża cenę prawidłowo także wtedy, gdy waluta towaru jest inna niż waluta panelu.
Jeśli prowadzisz sklep wielowalutowy z ofertami specjalnymi, dodaj testowy towar do koszyka i porównaj cenę z deklarowaną. Błąd polegał na tym, że koszyk pokazywał informację o nałożonej ofercie, ale cena nie spadała.
Na karcie towaru z progami rabatowymi, po zmniejszeniu ilości z wcześniej osiągniętego najwyższego progu, wyświetlana cena była niższa niż ta naliczana po dodaniu towaru do koszyka. Poprawiliśmy przeliczanie progów w API, dzięki czemu cena na karcie towaru odpowiada rzeczywistej cenie zakupu.
Scenariusz był taki, że klient hurtowy schodził z ilością z osiągniętego wcześniej progu, karta towaru dalej pokazywała niższą cenę, a koszyk naliczał wyższą. Poprawka poszła w API przeliczające progi.
Progi rabatowe konfigurujesz w Promocje i rabaty > Rabaty, w sekcji przedziałów dla klientów detalicznych i hurtowych.
Rabat z tą opcją nie był naliczany także wtedy, gdy żaden inny rabat w koszyku nie obowiązywał. Poprawiliśmy mechanizm — w sklepach z tą konfiguracją rabaty zaczną być naliczane.
Rabat nie naliczał się nawet wtedy, gdy w koszyku nie obowiązywał żaden inny, czyli w sytuacji, w której z definicji był wyższy od zera.
Zwróć uwagę na skutek uboczny: w sklepach z taką konfiguracją rabaty zaczną się naliczać po tej zmianie. Jeśli ktoś przywykł, że dany rabat „i tak nie działa", i zbudował na tym kalkulację marży, warto to przejrzeć.
W XML brakowało tagów sekcji bez nazwy oraz szerokości i wysokości zdjęć i wideo, a kolejność sekcji nie odpowiadała tej z panelu. Uzupełniliśmy zwracane dane i uporządkowaliśmy kolejność, dzięki czemu opis zbudowany z sekcji można wiernie odtworzyć w szablonie sklepu.
Sprawdziłem opisy budowane w edytorze sekcji: wracają w <sections_description> poprawnie sformatowane, z kompletem wymienionych elementów.
To zmiana dla wszystkich, którzy odtwarzają opis produktu w szablonie sklepu albo w integracji. Bez wymiarów zdjęć nie da się zarezerwować miejsca w układzie, a bez kolejności sekcji opis rozjeżdża się względem tego, co widać w panelu.
Wywołanie bramki z niekompletnie określonym sortowaniem kończyło się błędem. Dodaliśmy walidację parametrów sortowania, dzięki czemu bramka odpowiada poprawnie również w takim przypadku.
Zacząłem od punktu odniesienia. Poprawne sortowanie rosnąco zwróciło produkty o ID 9, 10, 11, malejąco 23550, 23549 i dalej w dół. Skoro wyniki się różnią, sortowanie realnie działa i mam z czym porównywać.
Potem psułem parametr sortowania na wszystkie sposoby: brakujący kierunek, brakujące pole, puste obiekty, wartości null, liczby zamiast tekstu, tablica zamiast obiektu, pole o długości 2000 znaków, 500 reguł sortowania naraz, zagnieżdżone tablice. Ani jedno z 57 zapytań nie zwróciło błędu. Wszystkie odpowiedziały kodem 200 i kompletną listą produktów, tyle że w kolejności, o którą nikt nie prosił. Działa tak samo na v5, v6, v7 i v8.
Trzy rzeczy przy okazji na plus. Biała lista pól faktycznie filtruje: spacja, apostrof czy długi ciąg znaków w nazwie pola są odrzucane, więc nie da się wstrzyknąć śmieci do zapytania. Walidacja jest granularna, czyli jedna zepsuta reguła sortowania nie kładzie drugiej, poprawnej. Kierunek sortowania jest odporny na wielkość liter.
Bramka nigdy nie mówi, że dostała bzdurę. Porównałem odpowiedź na kompletnie bezsensowne zapytanie z odpowiedzią na poprawne: są strukturalnie identyczne. Ten sam zestaw pól, żadnego error, ani jednego słowa ostrzeżenia.
Jeśli integracja prosi o „50 najdroższych produktów", ale w zapytaniu zabraknie kierunku sortowania, dostanie 50 przypadkowych produktów i pełne 200 OK. Bez info, że sortowanie nie zadziałało. Wcześniej dostałaby błąd i od razu byłoby wiadomo, że coś jest nie tak.
Jeśli budujesz na tej bramce integrację, waliduj parametry po swojej stronie, bo API Ci nie pomoże. Dozwolone wartości kierunku to ASC i DESC, w dowolnej wielkości liter, a elementName musi pochodzić z zamkniętej listy pól w dokumentacji bramki.
Karta towaru przypisanego do bardzo dużej liczby węzłów menu działała skrajnie wolno, a przypisywanie towarów do menu bywało praktycznie zablokowane. Zoptymalizowaliśmy ten mechanizm — edycja takich towarów, zarówno z panelu, jak i przez API, wykonuje się teraz szybko.
Zmiana, którą część agencji odczuje z ulgą.
Sam pamiętam zgłoszenia od klientów przy pracach nad szablonami. Długo wyglądało to na błąd po naszej stronie, a było ograniczenie systemowe.
W sklepach z towarami o bardzo dużej liczbie wariantów generowanie danych oferty i stref hotspot mogło przekraczać dostępną pamięć, co skutkowało błędami wczytywania stron. Zoptymalizowaliśmy ten proces, dzięki czemu strony z takimi towarami wczytują się stabilnie.
Boczna wyszukiwarka towarów przy filtrowaniu po dacie zwracała wszystkie towary z panelu, niezależnie od ustawionego zakresu. Naprawiliśmy filtrowanie i zablokowaliśmy wybór daty z przyszłości.
Boczna wyszukiwarka filtruje po dacie poprawnie, a wybór daty z przyszłości jest zablokowany.
Do wyboru jest sześć rodzajów daty: stworzenia towaru, skończenia się towaru, wznowienia towaru, modyfikacji towaru, modyfikacji stanów magazynowych i modyfikacji cen.
Wejście na kartę towaru w niektórych językach, takich jak ukraiński, mogło kończyć się błędem i nieotwarciem strony. Naprawiliśmy ten błąd, dzięki czemu karty towaru otwierają się poprawnie we wszystkich językach sklepu.
Jeśli sprzedajesz na rynki wschodnie, to pozycja dla Ciebie, zwłaszcza w zestawie z nowymi dostawami Allegro na Ukrainę opisanymi wyżej.
Po włączeniu regulaminu domyślnego w sklepie mógł ładować się tylko jego pierwszy fragment zamiast pełnej treści. Zmieniliśmy mechanizm aktualizacji tak, aby zapisywał kompletną treść regulaminu niezależnie od wybranego trybu, dzięki czemu regulamin domyślny wyświetla się w całości.
Sprawdzenie zajmuje chwilę: w Sklep > Regulamin i polityka, przy Treść podstrony: wygeneruj automatycznie, otwórz podgląd i przewiń do końca.
Synchronizacja danych z panelem uruchamiana z menu Narzędzia kończyła się błędem. Naprawiliśmy ten błąd, synchronizacja przebiega teraz poprawnie.
W Konfiguratorze sklepu zagranicznego nie dawało się przejść do drugiego kroku dodawania kraju. Naprawiliśmy ten błąd i dodawanie nowego kraju sprzedaży działa poprawnie.
Komunikat wysyłany po aktualizacji regulaminów i polityk dostarczanych przez IdoSell podawał kraj, język, nazwę dokumentu i zakres zmian w jednym ciągu tekstu. Rozdzieliliśmy te informacje na osobne pola, dzięki czemu od razu widać, czego dotyczy zmiana.
Przywróciliśmy widoczność liczby punktów programu lojalnościowego. Wcześniej naliczone punkty nie były pokazywane ani w panelu na karcie klienta, ani na koncie klienta w sklepie. Po zmianie punkty są prawidłowo widoczne w obu miejscach. Zarezerwuj bezpłatną konsultację Nasi specjaliści dobiorą do Ciebie najlepsze rozwiązania oraz odpowiedzą na Twoje pytania. Umów spotkanie
Punkty widać w obu miejscach: na karcie klienta w panelu i na koncie klienta w sklepie.
Wcześniej punkty naliczały się, ale nie były pokazywane poprawnie w obu miejscach. Klient wiedział co innego a co innego było w panelu IdoSell.
Na blogu IdoSella, w kategorii Changelog. Wersja za lipiec 2026 jest pod adresem changelog-idosell-lipiec-2026 i została opublikowana 10 sierpnia 2026. Nowe funkcje bywają ogłaszane osobno, poza changelogiem.
Nic na to nie wskazuje. Moduł jest wyzwalany zdarzeniami, a dokumentacja nie opisuje żadnego trybu przetwarzania zamówień historycznych. Pojedyncze zamówienie można przepuścić przez regułę przyciskiem Testuj, ale to nie jest symulacja: akcje wykonają się naprawdę, więc rób to na zamówieniu testowym.
Nie. Oba mechanizmy działają równolegle i nic się nie migruje automatycznie. Jeśli w starym module masz automat robiący to samo co nowa reguła, wyłącz jeden z nich, bo mogą się wzajemnie nadpisywać.
Nic ponad to, co już płacisz. Funkcja mieści się w dotychczasowych planach abonamentowych. Do jej obsługi operator potrzebuje uprawnień do modułów Administracja i ustawienia oraz Zamówienia.
Sprawdź, czy towary sprzedawane do Unii mają uzupełnione kody CN w sekcji Podstawowe na karcie towaru. Bez nich system poda stawkę podstawową kraju dostawy, więc żadna zmiana stawki obniżonej Cię nie obejmie. Przejrzyj też własne nadpisania stawek w Produkty (PIM) > Kategorie, bo mają pierwszeństwo przed matrycą i przeżywają każdą aktualizację.
Najprawdopodobniej klucz API nie ma uprawnień do modułu subskrypcji. Panel wyświetla wtedy komunikat o braku dostępu, a zaznaczone zdarzenia i tak nie polecą. Uprawnienia ustawia się w konfiguracji tego samego klucza API.
Na razie nie ma czego włączać. Integracja została uruchomiona automatycznie tylko dla klientów usługi Reklamy Google od IdoSell, bez żadnego przełącznika w panelu. Sklepy prowadzące kampanie samodzielnie albo przez agencję mają dostać opcję do samodzielnego uruchomienia w kolejnym kroku, o czym IdoSell zapowiada odrębną komunikację.
Cześć, tu Przemek,
W godz. 9.00 - 15.00 z reguły oddzwaniam w 15 minut ^^
Przemysław Kuś z IdoMods.pl
Kliknij, podaj swój numer i oddzwonię
Sprawdź nas, jak szybko oddzwaniamy
lub po prostu zadzwoń: +48 733 721 168
Cześć, tu Przemek,
W godz. 9.00 - 15.00 z reguły oddzwaniam w 15 minut ^^
Tak czy inaczej o maila zapytam,
więc możesz go podać od razu:
