Czego potrzebujesz, by łatwiej przejść na REST API Allegro

[TomekKaczmarek]

Jak wiecie wygaszamy WebAPI, tym samym wszystkie rozwiązania, które z niego korzystają muszą przejść na REST API Allegro.

Zastanawiamy się, czy i jak możemy Was w tym temacie wesprzeć. W komentarzach do tego posta podzielcie się swoimi pomysłami. Co możemy Wam dostarczyć, by ułatwić przejścia na nowe API - poradników, narzędzi, czegokolwiek, co ułatwi Wam ten proces.

Jeśli widzicie pomysł, który Wam się podoba - dajcie łapkę w górę.

Listę Waszych pomysłów przeanalizujemy i na jej podstawie podejmiemy decyzję, co i w jakiej formie możemy Wam dodatkowo dostarczyć.

Zachęcamy do komentowania!

[MartaNowaczyk]

Dziękujemy za wszelkie sugestie i opisane potrzeby. Mamy je na uwadze, jednak na ten moment nie mogę nikomu obiecać, że ten dziennik będzie szybciej. Cały czas jesteśmy w trakcie prac. Jak coś ustalimy na pewno o tym poinformujemy.

[TimothyKoval]

To nie wyłączajcie starej metody

[ghost]

@TimothyKoval @MartaNowaczyk dokładnie tak jak napisał @TimothyKoval to nie to że my nie chcemy przejść na nowe, bo chcemy, tylko utrudniają nam pewne braki :) Trzymamy kciuki za informację, na pewno się przypomnę :)

[jakubmaguza]

A może by tak... Zasób do zmiany ilości sztuk w aukcji dla kilku ofert na raz? Wiem, jest coś w tym stylu, tylko że przy obecnym zasobie mogę tylko ustawić wszystkie oferty na taką samą ilość. Gdyby tak można było podać ID oferty i nową ilość :)

[qls-api]

W ofercie typu licytacja przez www (WebApi również) jest możliwość zaznaczenia „Wznawianie oferty – po zakończeniu wystaw ponownie ofertę, jeśli nie zostanie sprzedana”, mają kilka tysięcy oferty nie sprawdzamy czy towar się sprzedał czy nie. Allegro automatycznie wystawia ponownie taką licytację. Czy zostanie ta funkcjonalność dodana do RestApi ?

[MartaNowaczyk]

@jakubmaguza dodałam do sugestii :) @gls-api opcji wznawiania ofert nie planujemy, ale sprawdzę jeszcze czy nie mamy czegoś w zamian w planach.

[neldh]

Rozważamy też wystawienie mappera stary-nowy id płatności.

I jak tam rozważania? wdrożycie? kiedy? Będzie też mapowanie po id formularza dostawy? (również potrzebne bo wasze API gada po id formularza, a nie id płatności) W zasadzie to wystarczyło by po id formularza, bo id płatności jest dostępne po pobraniu danych formularza, no ale...

W tej chwili mapowanie tego o czym piszę, ale wychodzące od lineItemId <=> dealId jest niby możliwe, ale mocno, ale to mocno nieoptymalne.

Brak takiej podstawowej rzeczy skutecznie utrudnia migrowanie.

[PawelTaberski]

Wiemy o tej potrzebie, jak tylko otrzymamy informacje, że coś takiego wdrożymy z jakąś przybliżoną datą to na pewno o tym poinformujemy w dedykowanym komunikacie. Potrzebę tej metody zgłaszamy już od dłuższego czasu z wysokim priorytetem.

[barthoos]

Czy na podobienstwo WebAPI w RestAPI bedzie do pobrania wersja pol formularza / parametrow? Trzymam te dane offline i aktualizuje jak wykryje, ze wersja sie zminila. Jak mam to robic teraz? Co dany interwal czasu przeleciec kazda kategorie? Zdecydowanie bardzo brakuje..

[PawelTaberski]

Obecnie nie ma takiego wersjonowania, przekazałem Twoje spostrzeżenie jako sugestię, jeśli zdecydujemy się wdrożyć takie rozwiązanie, to poinformujemy o tym w dedykowanym komunikacie.

[barthoos]

To za ciosem. W WebAPI pobieramy FIDy. Jezeli dany FID jest rownoczesnie parametrem to dostaje rowniez jego param.id. W RestAPI natomiast dostajemy same parametry - brak jest informacji o FIDzie. I tak parametr stan dla kategorii ID = 8875 oraz 90034, RestAPI odpowie mi praktycznie tak samo z ta roznica, ze slownikowych wartosci dla parametry stan dla jednej kategorii bedzie 5x (nowy/uzywany/po zwrocie/powystawowy/uszkodzony) a dla drugiej kategorii tylko 2x (nowy/uzywany).

W takim przypadku nie mam jak rozroznic tych parametrow i nie moge efektywnie tego zapisac offline. Brakuje FIDa. W polaczeniu z brakiem wersjonowania to jak rozumiem rekomendacja Allegro jest, zeby dzialac online z parametrami? Krok mocno wstecz imo. Spowolni to i u mnie i u Was..

[barthoos]

W ogole strasznie brakuje mi informacji o FIDach. Przykladowo przez WebAPI moge poprac informacje o FIDach:

4 (Czas trwania) -> do wyboru sposrod opcji (3|5|7|10|14|20|30|Do wyczerpania) 28 (Sztuki / Komplety / Pary) -> do wyboru sposrod opcji (Sztuk|Kompletów|Par)

W RestAPI odpowiadaja im odpowiednio:

publication/duration -> dostepne opcje ( null (do wyczerpania zapasów), P3D (3 dni); P5D (5 dni); P7D (7 dni); P10D (10 dni); P20D (20 dni); P30D (30 dni)

stock/unit -> dostepne opcje (UNIT (sztuki); SET (komplety); PAIR (pary))

Tylko ze wartosci do podania w RestAPI "pobieram" z poradnika jak wystawic oferte. Nie mam mozliwosci pobrania definicji tego pola. Co jesli w przyszlosci to sie zmieni (w czasie trwanai dojdzie np opcja 60dni, albo w unitach "zestawy")? Wtedy musze robic reczny backengeenering?

Ze nie wspomne o przypadkach, kiedy jakies pole nagle dojdzie. Dotychczas pobieralem kompletna strukture FIDow i kategorii i odpowiednio generowalem (w sposob automatyczny) wszystkie konieczne FIDy do uzupelnienia wraz z dostepnymi wartosciami. Teraz zmiany mam sledzic recznie?

[Onixarts]

Trzymam te dane offline i aktualizuje jak wykryje, ze wersja sie zminila.

Jeśli już macie zamiar wprowadzić wersjonowanie to na pewno nie w postaci takiej jak na starym API. Zmienia się jedna literka w kategorii i już nowa wersja kategorii i pobieranie całego drzewa kategorii. Zupełny bezsens. Lepiej już aby wraz z kolejnymi wersjami pojawiała się lista zmienionych poddrzew kategorii, żeby można było zaktualizować tylko fragment drzewa.

RestAPI odpowie mi praktycznie tak samo z ta roznica, ze slownikowych wartosci dla parametry stan dla jednej kategorii bedzie 5x (nowy/uzywany/po zwrocie/powystawowy/uszkodzony) a dla drugiej kategorii tylko 2x (nowy/uzywany).

Absolutnie żadnych więcej FIDów. To było największe zło starego API. Przecież parametry są zwracane w kontekście kategorii najniższego poziomu, więc zamiast FIDa masz numer kategori + id parametru. To wystarczy aby jednoznacznie zidentyfikować właściwy parametr.

W polaczeniu z brakiem wersjonowania to jak rozumiem rekomendacja Allegro jest, zeby dzialac online z parametrami? Krok mocno wstecz imo.

Nie ma to znaczenia. Rekomentacja jest na online, ale w offline pracuje się równie dobrze, a nawet lepiej niż przy starych parametrach, które miały całą masę zbędnych wartości.

Jedyny problem z jakim my się spotkaliśmy to konwersja danych użytkownika ze starych danych na nowe.

Tylko ze wartosci do podania w RestAPI "pobieram" z poradnika jak wystawic oferte. Nie mam mozliwosci pobrania definicji tego pola.

To jest minus nowego API, ale dane te powinny być uzupełnione w dokumentacji a nie w poradniku. Nie zmianiają się one tak często a na deva nie spada konieczność stworzenia synchronizacji tych danych, ich sprawdzania, przechowywania w bazie itp. Jeśli Allegro doda 60 dni, to dev dopisze to sobie w programie w 1 linii i wyda nową wersję softu. Z perspektywy czasu takie rozwiązanie jest znacznie lepsze niż utrzymywanie całego modułu synchronizacji pól, które nie zmieniły się od 10 lat.

[PawelTaberski]

Przekazałem wasze uwagi zwłaszcza odnośnie listy zmian w danym fragmencie drzewa. Jeśli zdecydujemy się na taka zmianę poinformujemy o tym w dedykowanym komunikacie.

[barthoos]

@Onixarts Dzieki wielkie. masz sporo racji z FIDami. Moj bol tylka wynika z faktu, ze napisalem sobie bardzo ladna klase do wyswietlania, walidowania, ustawiania, itp pol formularza na podstawie tabelki offline z FIDami i bardzo, ale to bardzo chcialbym zmappowac nowe na stare ;) Nic. Pracujemy z tym co mamy.

A z migracji uzytkownikow WebAPI -> RestAPI to w ogole zrezygnowalem. Carte blanche.

[FromAnyHole]

Najważniejsza sugestia na dziś: przesunąć wygaszanie metod WebAPI na czas po wakacjach !

[Onixarts]

Również bym o to prosił. Zmian w aplikacjach jest dość sporo a termin się mocno zbliża. Czy jest możliwe odłożenie czerwcowego armagedonu?

@barthoos my również mamy coś podobnego. Co do migracji to nie wyobrażam sobie reakcji użytkowników jeśli każemy im zacząć od nowa :). A to jest jedna z trudniejszych operacji.

[PawelTaberski]

Obecnie nie planujemy wydłużenia tego terminu. Jeśli otrzymam jakieś informacje, że ten termin ma ulec zmianie, to na pewno o tym poinformujemy w dedykowanym komunikacie.

[barthoos]

Wy wiecie, ze my wiemy, ze Wy wiecie, co my wiemy, ze musicie przedluzyc ten termin ;) Brak pelnego odwzorowania funkcjonalnosci webapi > restapi + gro metod w wersji beta. To sie po prostu nie klei...

[FromAnyHole]

https://github.com/allegro/allegro-api/issues/1534

[pokash]

Eh... wygaszacie stare API, a REST API jest nadal nie gotowe... W dalszym ciągu trzeba się posiłkować WebAPI, bo nie wszystkie metody zostały przeniesione... Co możecie zrobić, to nie zmieniać (usuwać) informacji, które były przekazywane przez stare API... dlaczego? Bo w wielu przypadkach rozwala to procesy zaprogramowane pod konkretne warunki dla konkretnych informacji przekazywanych przez API. To jedna sprawa. Druga, to taka, że wygaszacie stare API, a poprzez nowe nie można pobierać informacji dotyczących konkretnych kosztów danej oferty (doMyBilling lub doMyBillingItem). Czy ktokolwiek w Allegro przez przystąpieniem do pracy prowadzi analizy? Sprzedawcy, aby cokolwiek zarobić muszą przecież analizować koszty... nie mając pełnych danych, lecą na fali a później dokładają do nierentownego interesu... Już pomijam fakt, że dużo metod jest nadal w wersji beta... Pozdrawiam, Łukasz

[jakubmaguza]

Jeśli dobrze widzę, tych metod akurat nie wygaszają. Wygaszają tylko te które są dostępne w REST.

[pokash]

@jakubmaguza póki co, ale biorąc pod uwagę niekonsekwencję przenoszenia starego API i wycinania pewnych informacji nie mamy pewności, czy akurat ta metoda zostanie przeniesiona do nowego API przed całkowitym wyłączeniem WebAPI... Teraz jest to totalny kataklizm... Nie można aplikacji przeportować w całości na nowe API, gdyż części funkcji nadal w nowym nie ma. To jest kłopot...

[jakubmaguza]

Kłopot jest połowiczny, bo po zalogowaniu w nowym API jesteś też zalogowany w starym. Niestety nie wiem czy będzie odbicie wszystkich metod, ale raczej powiedziałbym że będzie :)

[pokash]

@jakubmaguza oczywiście jest metoda w WebAPI pozwalająca na logowanie się za pomocą tokenu wygenerowanego z RestAPI (ale i tak dorzucasz w wywołaniu webapiKey)... To łatka na łatce... W aplikacjach procesowych jest to niepożądane (popatrz na Windows'a, który jest non stop łatany)... Allegro wprowadzając na szybko RestAPI powoduje, że programy (w moim przypadku zarządzające procesami) będą narażone na błedy (gdy w pewnym momencie Allegro wyłączy metodę, bez uprzedniego przeportowania w pełni funkcjonalności do RestAPI) Już teraz jest kłopot z cennikami, które nie zwracają informacji o czasie spedycji, która jest podana w Allegro... (oczywiście można pobrać te informacje ze starego API, ale nie 1:1, gdyż nie ma możliwości ich zmapowania)

[grojanteam]

Każde zmiany niosą za sobą obawy. Jak do tej pory wprowadzam metody z Rest API, czegoś nie ma to biorę z WebAPI, jak czegoś nie ma to od tego jest to miejsce żeby zgłaszać. WebAPI key to client id więc dodatkowych danych trzymać nie musisz.

[pokash]

@grojanteam WebApiKey to clientId? Od kiedy?

webapiKey | string | wymagany Klucz WebAPI użytkownika. Zgłoszenia o potrzebach są... analizowane... od miesiąca, gdyż nie widzą zasadności przekazywania czasu dostawy poprzez API. Sami regulują odgórnie te informacje, ale nie dają do nich dostępu poprzez nowe API...

[pokash]

@grojanteam Sorry, zauważyłem dopiero teraz w nagłówku, że Client ID / klucz WebAPI 👍 Masz rację :) Moja nieuwaga

[grojanteam]

@pokash nie ma sprawy też miewam takie sytuacje :)

[Radeq]

1. Informacji co się stanie z aukcjami wystawionymi przez WebApi które nie mają cennika wysyłki ( offer.delivery.shippingRates null):
   • czy aukcje zostaną zakończone?
   • czy będzie można modyfikować/wznawiać aukcję nie podając offer.delivery.shippingRates ?

[pokash]

@Radeq z tego co zauważyłem, możesz mieć nieprzypisany cennik w ofercie. Przy pobieraniu danych nie zwraca Ci w tym przypadku obiektu z cennikiem (to musisz brać pod uwagę jeżeli tworzysz aplikację Windowsową). Większym problemem jednak jest obsługa zamówienia, gdyż Allegro zwraca jedynie wybraną formę dostawy - bez cennika. Oczywiście gdy mamy relacyjną bazę danych to nie kłopot, ale gdy forma wysyłki przyjmuje wartość "Inny sposób dostawy", a w cennikach nie istnieje taka forma dostawy tworzy się problem. Stąd moje pytanie do @PawelTaberski i zespołu Allegro. Po co w takim razie ustalamy w cenniku dostawy, że w przypadku zakupu różnych przedmiotów z różnymi przesyłkami. Mam zaznaczoną na koncie opcję: "Klient zapłaci kwotę najdroższej dostawy, jeśli kupujący wybrał przedmioty z ofert o różnych kosztach dostawy." i każdy przedmiot ma przypisany cennik. W takim przypadku jest to co najmniej nielogiczne i przysparza więcej pracy, gdyż teraz muszę zakodować w programie opcję, która będzie musiała wybrać przewoźnika - bo "Inny sposób dostawy" nie istnieje jako przewoźnik :)

Pozdrawiam, Łukasz

[jakubmaguza]

@pokash Może po prostu "Przesyłka kurierska"?

[pokash]

@jakubmaguza to propozycja dla mnie czy dla zespołu Allegro? :) Ja sobie oczywiście poradzę odpowiednią funkcją wyliczającą na poziomie bazy danych, tylko po co tak komplikować z danymi wysyłanymi z API? :( dane powinny być jak najłatwiej implementowalne i interpretowalne :)

Pozdrawiam, Łukasz

[jakubmaguza]

@pokash Dla Ciebie. Taka opcja jest dostępna ;)

[MartaNowaczyk]

@Radeq

Informacji co się stanie z aukcjami wystawionymi przez WebApi które nie mają cennika wysyłki ( offer.delivery.shippingRates null):

1. czy aukcje zostaną zakończone?
2. czy będzie można modyfikować/wznawiać aukcję nie podając offer.delivery.shippingRates ?

1. Nie, chyba, że je ktoś zakończy.
2. Nie będzie można bez uzupełnienia shippingRates.

[alekskuc]

Witam, do przejścia na rest api niezbędne jest powiązanie id transakcji i id płatności pomiędzy rest api i web api.

Uwzględniając ten scenariusz, to powiązanie za pomocą lineItemId <=> dealId nie jest uciążliwe, a niemożliwe, ponieważ będą się duplikowały na potęgę transakcje u setek Klientów.

Manager sprzedaży Allegro posiada takie powiązanie ponieważ informuje o starych i nowych formatach id transakcji.

Przede wszystkim brakuje mapowań id związanych z transakcjami między starym i nowym api. lineItemId <=> dealId jest niewystarczające. Trzeba się mocno natrudzić, żeby dokopać się z tego do powiązań id całych płatności (patrz niżej). Rozumiem, że w nowym systemie nie jest to jeden do jeden ze starym, ale mimo wszystko mapowania brak, a jest niezbędne do przejścia ze starego api na nowe w przypadku systemów obsługujących transakcje.

Brakuje przede wszystkim mapowań: postBuyFormId <=> payment.id postBuyFormId <=>surcharges.*.id Co jest o tyle dziwne, że w panelu allegro na "karcie płatności" obie wersje id (stara i nowa) są wyświetlane obok siebie bezproblemowo. Dodatkowo, w przypadku gdy klient wykona kilka dopłat, spięcie id dopłaty z webapi z restowym id dopłaty jest w tej chwili niemożliwe do zrealizowania jednoznacznie. Trzeba posługiwać się kolejnością/wartościami kwot (da się zrobić, ale trochę zgadywania jest).

Przydałoby sie też takie cudo, bo wasze nowe api w wielu miejscach wykorzystuje checkoutFormId, ale da się żyć bez tego (wiem, że nie będzie to mapowanie jeden do jeden, ale zawsze byłoby pomocne): postBuyFormId <=> checkoutFormId

Idealnie byłoby mieć podane te stare idki na tacy we wszystkich odpowiedziach, np w bloku "deprecatedIds" (w środku wyszczegolnione stare odpowiedniki, np "postBuyFormId": []), a blok ten mógłby zniknąć np po całkowitym wyrzuceniu przez was starego api, albo metod starego api, które te id wykorzystują. Wtedy płynne przejście na działającym systemie byłoby dużo prostsze.

@MartaNowaczyk @PawelTaberski proszę o informację kiedy będzie możliwa pełna konwersja id transakcji INT z WebAPI do UUID RestAPI?

[PawelTaberski]

@alekskuc Przekazałem Twoją sugestię do odpowiedniego zespołu, jeśli zdecydujemy się na wdrożenie takiego rozwiązania to poinformujemy o nim. Obecnie udostępniliśmy jedno mapowanie dealId i lineItemId, więcej na ten temat znajdziesz tutaj. Dzięki niemu jesteś w stanie połączyć oba środowiska m.in. w sposób jaki opisał jeden z użytkowników w wątku #1559

[alekskuc]

@alekskuc Przekazałem Twoją sugestię do odpowiedniego zespołu, jeśli zdecydujemy się na wdrożenie takiego rozwiązania to poinformujemy o nim. Obecnie udostępniliśmy jedno mapowanie dealId i lineItemId, więcej na ten temat znajdziesz tutaj. Dzięki niemu jesteś w stanie połączyć oba środowiska m.in. w sposób jaki opisał jeden z użytkowników w wątku #1559

Witam, jeśli chodzi o to "rozwiązanie":

(..,)Podczas calego tego procesu gromadzisz lineItems.id dla kolejnych checkout formów i następnie używasz końcowki do mapowania dealId na lineItemId. W ten sposob uzyskasz numery dealId dla kolejnych checkout formow. (...)

To nie zadziała ze względu na to w jaki sposób działają dzienniki zgodnie z dokumentacją:

Z uwagi na uwarunkowania techniczne, w pojedynczych przypadkach zdarzenia mogą pojawić się w nieoczekiwanej kolejności; to znaczy, że jest możliwość by np. zdarzenie ze statusem READY_FOR_PROCESSING pojawiło się przed FILLED_IN; nie traktujemy tego jako błąd.

Zatem absolutnie nie można bazować na kolejności checkout formów i zbieraniu lineItems.id.

Dodatkowo samo w sobie zbieranie w setkach bazach danych checkout formów i lineItems.id dla setek Klientów i ich tysięcy zamówień tylko po to żeby zrobić proste mapowanie INT na UUID jest nie do zaakceptowania.

Kompleksowo problem by rozwiązało zwrócenie w rest api na checkout formie starego transactionId INT z webAPI razem z UUID.

[PawelTaberski]

@alekskuc Oczywiście Twoją sugestię przekazałem, jeśli otrzymam informacje że wdrożymy takie rozwiązanie, to oczywiście poinformujemy o tym w dedykowanym komunikacie.

[neldh]

@alekskuc Sugerowałem to (albo ktoś inny) tak chyba ze trzy miesiące temu. Odpowiedź identyczna. W moim rozwiązniu potrzebowalem tylko checkout formów w statusie READY_FOR_PROCESSING. Możliwe, że u Ciebie się tak nie da. @PawelTaberski Naprawdę. Weźcie zróbcie te mapowania i po problemie... Nie wiem co was powstrzymuje. Masa integracji zawala was na pewno setkami nadmiarowych żądań, które mają na celu tylko zmapować to id.

[PawelTaberski]

@neldh Tak, jak pisałem sugestię oczywiście przekazałem, jak tylko otrzymam informacje, że wdrożymy to oczywiście o tym poinformujemy.

[pokash]

@PawelTaberski wielokrotnie już chyba proszono o mapowanie formularza dostawy checkoutformid <=> dealtransactionid, czy możliwe byłoby wdrożenie takiej metody jak ma to miejsce w lineitemid <=> dealid? Dzięki wdrożeniu takiego mapowania nie byłoby konieczności korzystania już z WebApi, aby w 💯 % obsługiwać zamówienia. Tak na prawdę już na tą chwilę takiej konieczności by nie było, gdyby API InPost honorowało nowy typ zapisu identyfikatora transakcji, no ale cóż, jeżeli tak nie jest, to chociaż może Allegro pozwoliłoby całkowicie rozwiązać ten problem i utworzyć takie mapowanie :) na ten moment, niestety trzeba się posiłkować starą metodą z WebApi. No i sprawa jeszcze z czasem dostawy. Czy dołączycie do metody listy sposobów dostawy, czas dostawy? Nie wiem jak inni, ale my korzystamy z tych informacji m.in. sprawdzając status przesyłki (czy dotarła do klienta, czy nie było opóźnień itp.) no i dodatkowo w treści maila wysyłamy przedział czasowy (zgodny z tym co jest w ofercie) gdyż spora część klientów nie rozumie różnicy pomiędzy czasem wysyłki, a czasem dostawy... Uważają, że czas wysyłki oznacza czas, w którym przesyłka będzie już pod jego drzwiami... Wiem, mogę skorzystać z funkcji starego API (w którym te dane są zwracane), ale po co komplikować życie? :)

Pozdrawiam, Łukasz

[PawelTaberski]

Pracujemy nad wdrożeniem dodatkowej metody do mapowania, niedługo powinna się pojawić. Twoją sugestię odnośnie czasów dostawy oczywiście przekazałem.

[pokash]

@PawelTaberski, czy planujecie może wdrożenie metody do pobierania informacji o zarejestrowanych zwrotach? Pytam, gdyż zauważyłem problem w tym obszarze. Identyfikacja przesyłek jest uciążliwa (przede wszystkim jeżeli są to przesyłki InPost) na koncie można ręcznie wyszukiwać co to jest, ale absorbuje to dużo czasu, dlatego chciałem wprowadzić w tym obszarze automatyzację. Dzięki temu klient znacznie szybciej otrzyma zwrot pieniędzy na konto, a więc i jakość obsługi to podniesie. Jeżeli jest już taki zasób, to najwidoczniej go przeoczyłem i przepraszam, ale jedynie na co natrafiłem, to tylko wątek na githubie utworzony 10 miesięcy temu :)

Pozdrawiam, Łukasz

[PawelTaberski]

Obecnie nie ma takiego zasobu, niewykluczone, że w przyszłości pojawi się taki zasób. W planach odnośnie zwrotów są zasoby do zwrotu prowizji. Więcej informacji znajdziesz w naszym harmonogramie.

[pokash]

@PawelTaberski, zwroty prowizji to poboczna kwestia :) jak już jest zwrot, lub nieodebrana przesyłka, to na podstawie danych z systemu jesteśmy wstanie wyciągnąć listę i wnieść o zwrot prowizji... Jednakże odkąd Allegro wdrożyło możliwość zlecania zwrotów poprzez portal, to stała się masakra :) identyfikacja paczki skąd, od kogo itd zajmuje mnóstwo czasu... Bo w paczce znajduje się jedynie przedmiot (czasami bez dokumentu sprzedaży, bez formularze odstąpienia od umowy) a na etykiecie adresowej jedynie dane paczkomatu, z którego nastąpiło nadanie... I bądź tu mądry :)

Może warto wstawić dodatkową wartość do zasobu checkout-forms? Zasób z tego co widzę, nadal jest w wersji beta. Dzięki temu nie będzie konieczności tworzenia nowego zasobu, a jednocześnie informacje dotyczące konkretnej transakcji będą zebrane w jednym miejscu :)

[MartaNowaczyk]

@pokash rozumiem, że chodzi o opcję zwrotu jaką klient wyklika przez panel allegro. Przekażę sugestię do zespołu, który zajmuje się zamówieniami.

[ghost]

@MartaNowaczyk @PawelTaberski Czy możemy dostać update co się dzieje w temacie odpowiednika: doGetSiteJournals Bardzo nas to boli, kiedy możemy się spodziewać?

[PrzemyslawLukanowski]

@SebastianOzdoba Nowy zasób do pobierania informacji o zmianach na własnych ofertach w wersji beta przewidziany jest na połowę lipca.

[grojanteam]

Witam a czy planujecie przenieść na REST metode z WebAPI doGetItemsInfo ?? https://allegro.pl/webapi/documentation.php/show/id,52#method-output nie wiem może pytałem, ale aktualnie na REST tego nie ma, a chciałbym już tą metodę całkiem odpiąć z mojej aplikacji i przejść całkowicie na REST