Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Krzysztof S.:
Przed aktualizacją było oddzielne API, które miało inny tryb obsługi transakcji. Transakcja miała 4 stany a nie 3 jak teraz.
Był zakup (program tego nie pobierał, 2 to było potwierdzenie formularza ale właśnie bez płatności i to już było to co Pan chce uzyskać, 3 to było anulowanie transakcji - program wtedy to anulował, 4 potwierdzenie płatności - program dopisywał informacje o płatności + rejestrował zaliczkę).

W nowym API wygląda to niestety inaczej i jest to trochę wybór między dżumą a cholerą i z tego co widzę po forum i po informacjach innych integratorów, każdy ma ten sam problem i każdy zaleca to co Allegro - najpewniejszy stan to ready_for_processing, pobieranie wcześniejszych stanów trochę na własną odpowiedzialność.
Teraz musimy to dokładnie zbadać i zobaczyć czy to się wpisuje w obecną logikę, być może trzeba dodać nowe parametry, które pobiorą transakcję i ją oznaczą ale nie wyślą zamówienia już do maga bo wtedy robi się seria kolejnych problemów do rozwiązania.

Tak jak wspominałem wcześniej, bez przerzucenia zamówień nieopłaconych do Aukcji nie jestem w stanie zapanować nad zwrotami prowizji do takich transakcji.
Zwrot prowizji jest jak najbardziej należny, jeśli zamówienie pozostaje nieopłacone. Traktujemy takie zamówienie jako anulowane, klient nie płacąc, rezygnuje z niego.
Dotychczas wszystkie wnioski o zwroty prowizji składaliśmy przez Aukcje. Teraz, przy założeniu, że tych zamówień nieopłaconych nie ma w Aukcje, to byłoby niemożliwe.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Michał S.:
Od wczoraj od godz. 18. synchronizacja zwraca komunikat błędu "nie można wstawić wartości NULL do kolumny "ID_AUKCJI" tabeli "URSUS.dbo.AUK_ALL_AUKCJE_AKCJE", ponieważ kolumna nie pozwala na wprowadzenie takich wartości. INSERT kończy się niepowodzeniem.", nie przechodzą nam zamówienia do Aukcji.

O 17.00 zainstalowałem przesłaną mi poprawkę - nie dała efektu. Nadal nie mogę przenieść transakcji do nieudanych.

Dodatkowo zauważyłem, że wszystkie aukcje w zakładce zakończonych mają status "T" trwające, nie mogę ich usunąć z programu.

Po wczorajszej interwencji udało się przywrócić jako tako synchronizację transakcji.
Pobierane są transakcje opłacone do Maga.
Pod koniec synchronizacji otrzymujemy komunikat o ucinaniu danych binarnych.
Nie na wszystkich aukcjach synchronizują się ilości dostępne z tymi dostępnymi w Magu.
Mieliśmy dzisiaj bardzo duże braków, których normalnie mieć nie powinniśmy.
Aukcje nie zakończyły się w momencie, w którym powinny z powodu zatrzymywania się synchronizacji.

Nadal występuje u nas problem z aukcjami tzn. aukcje zakończone mają status T trwające, przez co nie możemy zapanować nad procesem wystawiania. Filtry niewystawionych na koncie nie działają, bo wszystkie aukcje zakończone są traktowane jako trwające.
Przykładowo, dzisiaj mieliśmy dostawę, po której standardowo powinniśmy wystawić ok. 100 aukcji. Nie możemy ich wystawić grupowo, bo filtry niewystawionych nie działają.
Musielibyśmy przeglądać szczegóły każdego z towarów, aby wyłapać ręcznie te, które są niewystawione.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Z tego co wiem to wczoraj jak zapewne Pan widział analizowany był problem u Pana i obecnie komunikat obcinania znaków pojawia się jedynie u Pana na bazie. Była robiona synchronizacja na czystej bazie i problem nie występuje, więc bez Pana danych problem jest po naszej stronie nie do rozwiązania.
Nie wiem czy ma Pan jakieś dodatki doinstalowane, może były robione jakieś dedykowane zmiany o których już nikt nie pamięta ale ewidentnie problem jest w tej konkretnej konfiguracji i specyfikacji środowiska.
Z tego co wiem baza miała być wysłana i nie dotarła i ma ją Pan dowieźć pod koniec dnia, więc realnie pewnie problem przeciągnie się do poniedziałku.
Chętnie zbadamy problem jak będziemy mieli na czym.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Michał S.:

Krzysztof S.:
Przed aktualizacją było oddzielne API, które miało inny tryb obsługi transakcji. Transakcja miała 4 stany a nie 3 jak teraz.
Był zakup (program tego nie pobierał, 2 to było potwierdzenie formularza ale właśnie bez płatności i to już było to co Pan chce uzyskać, 3 to było anulowanie transakcji - program wtedy to anulował, 4 potwierdzenie płatności - program dopisywał informacje o płatności + rejestrował zaliczkę).

W nowym API wygląda to niestety inaczej i jest to trochę wybór między dżumą a cholerą i z tego co widzę po forum i po informacjach innych integratorów, każdy ma ten sam problem i każdy zaleca to co Allegro - najpewniejszy stan to ready_for_processing, pobieranie wcześniejszych stanów trochę na własną odpowiedzialność.
Teraz musimy to dokładnie zbadać i zobaczyć czy to się wpisuje w obecną logikę, być może trzeba dodać nowe parametry, które pobiorą transakcję i ją oznaczą ale nie wyślą zamówienia już do maga bo wtedy robi się seria kolejnych problemów do rozwiązania.

Tak jak wspominałem wcześniej, bez przerzucenia zamówień nieopłaconych do Aukcji nie jestem w stanie zapanować nad zwrotami prowizji do takich transakcji.
Zwrot prowizji jest jak najbardziej należny, jeśli zamówienie pozostaje nieopłacone. Traktujemy takie zamówienie jako anulowane, klient nie płacąc, rezygnuje z niego.
Dotychczas wszystkie wnioski o zwroty prowizji składaliśmy przez Aukcje. Teraz, przy założeniu, że tych zamówień nieopłaconych nie ma w Aukcje, to byłoby niemożliwe.

Również tak jak wspominałem powyżej - przenieść zawsze możemy ale bałaganu z ewentualnymi modyfikacjami jaki opisywałem powyżej nikt nie upilnuje.
Możemy się oczywiście wymieniać tu argumentami w jedną czy w drugą stronę natomiast proszę pamiętać, że zarówno my jak i Państwo jesteśmy tylko "beneficjentami" tego co dostarcza Allegro i to oni są właściwą stroną takich uwag. Z moich obserwacji wynika, że często nie do końca rozumieją jak wygląda logistyka po tym jak klient kupi coś za ich pośrednictwem i jakie procesy są po stronie sprzedającego. Trochę na zasadzie "my publikujemy to co mamy" a co Wy z tym zrobicie to już nie nasza sprawa.
Macie Państwo kontakt z opiekunami handlowymi po stronie Allegro (przynajmniej niektórzy) i warto takie uwagi i sugestie zgłaszać, my zgłaszamy od strony technicznej i efekt jest różny na wszystko wpływu nie mamy.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Krzysztof S.:
Z tego co wiem to wczoraj jak zapewne Pan widział analizowany był problem u Pana i obecnie komunikat obcinania znaków pojawia się jedynie u Pana na bazie. Była robiona synchronizacja na czystej bazie i problem nie występuje, więc bez Pana danych problem jest po naszej stronie nie do rozwiązania.
Nie wiem czy ma Pan jakieś dodatki doinstalowane, może były robione jakieś dedykowane zmiany o których już nikt nie pamięta ale ewidentnie problem jest w tej konkretnej konfiguracji i specyfikacji środowiska.
Z tego co wiem baza miała być wysłana i nie dotarła i ma ją Pan dowieźć pod koniec dnia, więc realnie pewnie problem przeciągnie się do poniedziałku.
Chętnie zbadamy problem jak będziemy mieli na czym.

Problem przesyłania bazy danych o tych parametrach zgłaszałem już kilka razy przy poprzednich usterkach. Nasze łącze przerywa wysyłkę bazy w trakcie. Obecnie baza ma rozmiar 30 gb przed spakowaniem, po spakowaniu jest to 9 gb, ale mimo wszystko taki rozmiar pliku nie przechodzi.
Dostarczenie bazy inną metodą zawsze wydłuża czas rozwiązania rzeczywistego problemu.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Krzysztof S.:

Michał S.:

Krzysztof S.:
Przed aktualizacją było oddzielne API, które miało inny tryb obsługi transakcji. Transakcja miała 4 stany a nie 3 jak teraz.
Był zakup (program tego nie pobierał, 2 to było potwierdzenie formularza ale właśnie bez płatności i to już było to co Pan chce uzyskać, 3 to było anulowanie transakcji - program wtedy to anulował, 4 potwierdzenie płatności - program dopisywał informacje o płatności + rejestrował zaliczkę).

W nowym API wygląda to niestety inaczej i jest to trochę wybór między dżumą a cholerą i z tego co widzę po forum i po informacjach innych integratorów, każdy ma ten sam problem i każdy zaleca to co Allegro - najpewniejszy stan to ready_for_processing, pobieranie wcześniejszych stanów trochę na własną odpowiedzialność.
Teraz musimy to dokładnie zbadać i zobaczyć czy to się wpisuje w obecną logikę, być może trzeba dodać nowe parametry, które pobiorą transakcję i ją oznaczą ale nie wyślą zamówienia już do maga bo wtedy robi się seria kolejnych problemów do rozwiązania.

Tak jak wspominałem wcześniej, bez przerzucenia zamówień nieopłaconych do Aukcji nie jestem w stanie zapanować nad zwrotami prowizji do takich transakcji.
Zwrot prowizji jest jak najbardziej należny, jeśli zamówienie pozostaje nieopłacone. Traktujemy takie zamówienie jako anulowane, klient nie płacąc, rezygnuje z niego.
Dotychczas wszystkie wnioski o zwroty prowizji składaliśmy przez Aukcje. Teraz, przy założeniu, że tych zamówień nieopłaconych nie ma w Aukcje, to byłoby niemożliwe.

Również tak jak wspominałem powyżej - przenieść zawsze możemy ale bałaganu z ewentualnymi modyfikacjami jaki opisywałem powyżej nikt nie upilnuje.
Możemy się oczywiście wymieniać tu argumentami w jedną czy w drugą stronę natomiast proszę pamiętać, że zarówno my jak i Państwo jesteśmy tylko "beneficjentami" tego co dostarcza Allegro i to oni są właściwą stroną takich uwag. Z moich obserwacji wynika, że często nie do końca rozumieją jak wygląda logistyka po tym jak klient kupi coś za ich pośrednictwem i jakie procesy są po stronie sprzedającego. Trochę na zasadzie "my publikujemy to co mamy" a co Wy z tym zrobicie to już nie nasza sprawa.
Macie Państwo kontakt z opiekunami handlowymi po stronie Allegro (przynajmniej niektórzy) i warto takie uwagi i sugestie zgłaszać, my zgłaszamy od strony technicznej i efekt jest różny na wszystko wpływu nie mamy.

W takim razie przekazuję informację do opiekunów Allegro.
Niemniej jednak liczę na to, że uda się znaleźć jakiś kompromis w kwestii zapanowania nad należnymi zwrotami prowizji i rezerwacją towarów pod zamówienia nieopłacone.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Wystarczyłoby gdyby nawet w allegro w ustawieniach swojego konta można było zaznaczyć opcję - nie zezwalaj na zmianę metody dostawy po zapisaniu formularza.
Forma płatności nie jest problemem ale grzebanie już w metodach dostawy i adresach to strzał w stopę na każdym etapie.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

My również napiszemy do swojego opiekuna w tej sprawie

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Nadal mamy problemy z aukcjami (dzisiaj nam zniknęły wszystkie profile, ok 2 tys.).
Profile to jedna z dwóch najważniejszych funkcjonalności programu obok synchronizacji.
Wykorzystujemy je do grupowego wystawiania aukcji z okna towarów.
Tą kwestię wyjaśniamy w oddzielnej korespondencji.

W tym miejscu chciałem opisać przykład problemu z brakiem zamówień o statusie płatności rozpoczętej.
Klientka zakupiła towar, płatność rozpoczęła na Allegro, nie dokończyła jej.
Towar nie został zarezerwowany.
Klientka odzywa się dlaczego towar nie został wysłany.
Nie mamy zamówienia w Magu, ani w Aukcjach.
Towaru brak, w międzyczasie się sprzedał.
Klientka zapłaciła za zamówienie przelewem tradycyjnym, na nasze konto, bez udziału Allegro.
Nie ma możliwości wprowadzenia zamówienia przez program Aukcje.
Jedyne rozwiązanie to wprowadzać zamówienie ręcznie.Ten post został edytowany przez Autora dnia 22.01.20 o godzinie 16:24

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Opisywałem tą sytuację już przez kilka dni

Też mamy ten sam problem. Po kilka zamówień dziennie jest takich w których brakuje nam stanu magazynowego z powodu płatności rozpoczętych a nie zakończonych lub opłacanych np. przekazem pocztowym bo i takie się jeszcze trafiają.

My na tą chwilę staramy się kontrolować menadżera sprzedaży i ręcznie wbijać takie zamówienia do maga. Jak klient zapłaci w międzyczasie to zamówienie się dubluje wtedy więc i z tym jest problem. Nie wyobrażam sobie jednak takiego działania na dłuższą metę.

Sprzedajemy bardzo dużo towaru specjalistycznego którego nie mamy dużych zapasów magazynowych a w takim przypadku problem jest jeszcze większy.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Panowie, nie kręćmy się w koło bo temat już wyjaśniliśmy - wiemy, że jest to problematyczne ale tak jak pisałem to nie jest widzi mi się WAPRO tylko logika proponowana przez Allegro.

Badam temat po stronie Allegro przekazałem zmiany do testów w dniu dzisiejszym i zobaczymy co będzie działało nie tak jak zakładam pierwotnie bo na pewno coś wyjdzie.

Polecam lekturę z oficjalnego poradnika implementacji, żeby zrozumieć jaka mądra logika została zaimplementowana
https://developer.allegro.pl/orders/
oraz dyskusję na githubie wyjaśniającą Wasze potrzeby zespołowi Allegro bo ja odnoszę wrażenie, że nie każdy rozumie po co API dane wystawia i co Wy jako sprzedawcy z nimi potem robicie
https://github.com/allegro/allegro-api/issues/2700

Ogólnie dane są zwracane w sposób losowy bo np, zdarzenia o zakupie mogą być zwrócone totalnie w odwrotnej kolejności (najpierw status gotowe do przetworzenia czyli de facto finalna postać, potem w środku zdarzenie o uzupełnieniu formularza a na końcu dopiero status początkowy, że ktoś coś kupił).
Dodatkowo na rynku jak samo Allegro napisało mogą być aplikacje mobilne, których użytkownicy nie zaktualizowali i one mogą powodować powstawanie statusów, które de facto powinny być ignorowane czyli BOUGHT (wg informacji od nich w starych aplikacjach to status, że po prostu ktoś kliknął KUP TERAZ) - takich statusów nie będziemy importować do Aukcji.
Wg Allegro losowość danych nie jest niczym nadzwyczajnym i nie jest to błąd jaki muszą poprawiać, więc cały ciężar szeregowania danych jest po naszej stronie i chyba nie muszę tłumaczyć czym to grozi w momencie kiedy prześlecie transakcje na zamówienie do maga a potem to się pozmienia.
Ciekawostka dodatkowa jest taka, że jak klient rozpocznie 2 zakupy i ich nie zakończy, w międzyczasie Wy to pobierzecie do programu a klient potem zakończy zakup to oni po swojej stronie kasują te 2 pierwotne zamówienia i wysyłają zupełnie nowe, ale nie informują, że stare zostały skasowane i powołane do życia nowe.
Nie muszę chyba ponownie rozpisywać dokładnie co się u Was zadzieje w magazynie jeśli zaczniecie przesyłać to na zamówienie a potem wpadnie nowe.
Takie podejście po ich stronie uruchamia lawinę przypadków i efekt kuli śnieżnej generujące kolejne wyjątki i problemy, nad którymi trzeba zapanować i na pewno wszystkich sensownie obsłużyć się nie da.
Polecam lekturę, żeby dokładnie zrozumieć istotę problemu i podejście po drugiej stronie.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Witam

Mieliśmy dzisiaj dostawę towaru który mamy wystawiony na allegro. Przyjąłem towar na stan i wznowiłem aukcje. Jednak stan się nie zsynchronizował na aukcjach. Ma ktoś też taką sytuację czy to tylko u mnie ?

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Aukcje na allegro wznowiłem wczoraj po południu. Do dzisiaj się nie zsynchronizowały

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Wyjdzie zaraz do tego aktualizacja online.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Dziękuję za informację.

Zainstalowałem. Stany się zaktualizowały do poprawnych wielkości. Czyli jest ok.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Przeanalizowaliśmy temat tych statusów i tak jak pisałem wejdzie zmiana do kolejnej wersji. Pisze od razu jednak tutaj przed wydaniem jakie są konsekwencje pracy z takimi transakcjami bo przy takiej dowolności jak jest teraz można sobie wygenerować niezły bałagan.
Rozpiszę to na przykładzie dla lepszego zrozumienia materii.

1. Załóżmy, że klient X wykonał zakup 1 szt towaru ABC w poniedziałek o 10.00 nie płacąc za nią ze wskazaniem odbioru w punkcie Paczkomaty.

2. Następnie o 10.15 wykonana została synchronizacja - program pobiera kontrahenta X i zakłada w nim adres dostawy bo taki adres dla tego typu zamówienia będzie podany.

3. Klient X wykonuje kolejny zakup bez płacenia za towar XYZ w poniedziałek o 13.00 wybiera, że chce fakturę przesyłke kurierska na adres do firmy.

4. O 14.00 uruchamiamy kolejną synchronizację, wpada nowe zamówienie nieopłacone do aukcji, nadpisywany jest adres kontrahenta bo ten chce fakturę więc ma wyższość nad poprzednim adresem domowym tego klienta

5. O 16.00 klient orientuje się, że nie płacił za te zakupy i robi zapłatę za obydwa w jednej płatności znowu zaznaczając, że chce fakturę i zmienia dane na zupełnie inne (podaje celowo abstrakcyjny przypadek, żeby pokazać mnogość dziwnych przypadków jakie mogą wystąpić).

6. O 17.00 uruchamiamy synchronizację danych i pojawiają się schody.

Program nie otrzyma informacji z Allegro, że to zamówienie, które teraz importuje to są de facto 2 poprzednie zamówienia. Może to ustalić jedynie na podstawie identyfikatora zakupu pojedynczej pozycji z tego zamówienia.
Mamy tu dwa przypadki jakie zdecydowałem się uwzględnić, jeden zakłada, że zamówienia nieopłacone z 10.00 oraz z 13.00 zostały przeniesione na zamówienia.
To jest przypadek Pana Tomasza gdzie chce uzyskać rezerwację towaru. Jest to przypadek bardziej skomplikowany.

W takim przypadku program przy włączeniu opcji automatycznego tworzenia zamówienia do maga z transakcji wykryje, że przyszło zamówienie na nowego kontrahenta (znowu mamy dane do faktury, więc wygenerowany zostanie nowy kontrahent na te dane. Poprzednie dane też były do faktury więc program ich nie nadpisze).
Ale transakcja nie przeniesie się na zamówienie kolejne bo nastąpi zdublowanie rezerwacji i potencjalny problem z towarami. Nie można też skasować poprzednich transakcji i zamówień bo nie wiadomo co pracownicy z nimi zrobili. Nie można zmienić w nich kontrahenta bo rozjadą się wydruki i ewentualne eksporty, które mogły być po drodze wykonane.
Program zatem zostawi tą transakcję w aukcjach i oznaczy ją w NOWEJ KOLUMNIE wykrzyknikiem, że wymaga ona ingerencji operatora systemu. Sam on podejmie czy anuluje poprzednie zamówienia i tworzy nowe na finalne dane, czy korzysta ze schowka pozycji i przenosi pozycje czy też realizuje po prostu 2 poprzednie na fakturę/paragon.

Drugi przypadek bardziej podstawowy Pana Michała ,zakłada tylko import takiej transakcji do aukcji celem ewentualnej obsługi zwrotów prowizji bez tworzenia zamówienia z rezerwacją.
W tym przypadku program wykryje, że owszem ma poprzednie transakcje ale nie przenoszone zostały do maga, więc wykona anulowanie poprzednich transakcji (przy założeniu, że żadna z nich nie jest przeniesiona do maga).
I w miejsce 2 poprzednich wstawi tą nową transakcje.
Zasada tworzenia kontrahentów i ich adresów w obydwu przypadkach jest taka sama.

Jak widać na powyższym jeśli ktoś chce importować takie stany pośrednie to będzie miał taką opcję (domyślnie jest ona wyłączona). Ale w tym przypadku nie można oczekiwać podejmowania w 100% przypadków automatycznych działań programu w każdym przypadku bo co firma to będą inne pomysły.
Indywidualne zachowania będzie można sobie oprogramować poprzez gniazda i wtedy każdy zrealizuje dalszą logikę wg swoich procesów w firmie.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Według nas lepszym rozwiązaniem jest nawet zdublowanie się zamówienia w magu i podwójna rezerwacja niż zupełny jej brak. Zawsze takie zamówienie można ręcznie usunąć lub zmodyfikować ewentualnie przenieść do anulowanych. Jeżeli oznaczane byłyby wykrzyknikiem to rozwiązuje wtedy problem.

Pracownicy obsługujący do momentu zapłaty przecież nic z nim nie będą robić - bo czekają aż nastąpi zapłata. Nie będzie tutaj nic się działo i nie będzie to generowało żadnych pomyłek.

W momencie podwójnej rezerwacji zawsze zakończoną aukcję można ponownie wystawić. Natomiast jak brakuje towaru do spakowania paczki to już nielada problem . W takich przypadkach klienci straszą negatywnymi komentarzami , zgłaszają do allegro itp.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Dalej będę się upierał że klient który wypełni formularz dostawy nie może go w allegro w żaden sposób zmienić. Takie zamówienie może tylko opłacić lub nie. Gdyby chciał zmienić adres dostawy to musi złożyć kolejne zamówienie . W momencie kiedy klient chce dokonać zmiany adresu dostawy to do nas pisze, dzwoni lub składa kolejne zamówienie już z poprawnymi danymi..

Nie da się również w chwili obecnej złożyć zamówienia na allegro bez podania danych o płatności i dostawie - takie zamówienie na allegro się nie utworzy. Jakiś czas temu było to możliwe lecz zostało zablokowane przez allegro. Od jakiegoś czasu nie mamy zamówień w samym allegro w których nie ma wypełnionego formularza dostawy.

W chwili obecnej są tylko zamówienia pobraniowe, opłacone oraz nieopłacone. Nie ma zamówień niepełnych - czyli bez FOD.

Przypadek który Pan opisuje nie może więc wystąpić na tą chwilę w allegro.

Mamy czasami takie przypadki że klient składa 2 zamówienia z różnymi adresami dostawy lub różnym rodzajem dostarczenia.
Z reguły opłaca tylko jedno.

W takim przypadku i tak potrzebna jest ingerencja operatora z naszej strony aby ustalić które zamówienie jest właściwe i dlaczego klient go nie opłacił . Kontaktujemy się z nim w celu wyjaśnienia i realizujemy to które jest właściwe.

Temat: Aukcje 8.50.2 - błąd po aktualizacji ?

Nie ma Pan racji - można to zrobić bo robimy to codziennie w testach do tego co tu opisuje.
Przypadek bardzo prosty
1. Robię zakup zaznaczam płatność online
2. Na ekranie płatności jej nie opłacam (albo anuluję, albo wybieram blik i czekam aż wygaśnie).
3. Allegro przez 5 minut blokuje zmiany
4. Po 5 minutach odblokowuje się to i moge wybrać ponowienie
5. Przy ponowieniu mogę zmienić forme dostawy a tym samym adres i jej koszty

Wszystko co to opisałem było przez nas w ostatnich dniach kilkadziesiąt razy powtarzane, więc to nie jest żaden wymysł. Owszem wymagane jest zakończenie ale nie jest zablokowane anulowanie płatności a jeśli anuluje i odczekam to mogę to sobie zmienić - to jest największy problem tych scenariuszy.