allegro
[NEWS] Historia operacji - wpłaty, wypłaty, zwroty
Udostępniliśmy nowy zasób GET /payments/payment-operations, dzięki któremu pobierzesz historię operacji na saldzie zalogowanego sprzedającego.
Możesz skorzystać z sortowania i filtrowania wyników wyszukiwania, aby uzyskać interesujące cię dane.
Przykładowy request, dla którego otrzymasz wpłaty z 12.06.2019:
GET /payments/payment-operations?occurredAt.gte=2019-06-12T00:00:00.000Z& occurredAt.lte=2019-06-12T23:59:99.999Z&group=INCOME
Więcej na ten temat znajdziesz w naszej dokumentacji.
Udostępniliśmy nowy zasób GET /payments/payment-operations, dzięki któremu pobierzesz historię operacji na saldzie zalogowanego sprzedającego.
Pytanie: Ze wskazanej dokumentacji wynika że nie ma payment.id w odpowiedzi, a jest tylko w "filtrach" zapytania. Czy to jest przeoczenie dokumentacji, czy też tak na prawdę jest?
Bez payment.id ten zasób nie wygląda na bardzo użyteczny...
Nie widzę też participant.login. Przeoczenie?
@pkrzemo przy odpowiednich typach operacji, w dokumentacji jak i w odpowiedzi jest payment.id oraz participant.login. Sprawdź dla innego typu niż CORRECTION.
@pkrzemo przy odpowiednich typach operacji, w dokumentacji jak i w odpowiedzi jest payment.id oraz participant.login. Sprawdź dla innego typu niż CORRECTION.
@MartaNowaczyk OK, dzięki!
Poprawcie model w dokumentacji getPaymentsOperationHistory gdyż wprawadzacie ludzi w błąd, Jest tam pokazany tylko częściowy model. obiekty typu payment oraz participant są nieuwzględnione. Patrząc na dokumentacje to ten zasób jest dla mnie BEZUŻYTECZNY.
@AssAssIn1909 modele różnią się w zależności od wybranego "Type of the operation." Dla którego typu operacji model jest nieodpowiedni?
tytuł przelewu i powiązanie historią wypłat
stara metoda do pobierania listy wypłat zawierała id wypłaty, które pasowało do tytułu przelewu bankowego, np. tytuł przelewu: Wypłata PayU CODE(133147)IdT(148206662) - metoda doGetMyPayouts zwracała w payTransId wartość 148206662 - dzięki czemu mogliśmy dopasować przelew to danych o transakcji wypłaty
pomijając fakt, że w dokumentacji nie macie poprawnie opisanego modelu nowe metody są znacznie mniej wygodne w użyciu (musimy się bawić i samodzielnie 'składać' informację o wypłacie a nie jak uprzednio kiedy po prostu dostawaliśmy transakcje dotyczące danej wypłaty) to z tego co widzimy nie zawierają danych które możemy powiązać z tytułem przelewu
nawet gdy znajdujemy wiersz mówiący o wypłacie ((p.type == "PAYOUT" && p.group == "OUTCOME" && p.wallet.paymentOperator == "PAYU") to wiersz ten w payment.id ma po prostu null - zamiast np. id które jest w tytule przelewu
wg harmonogramu niebawem usuniecie stare metody czyli doGetMyPayouts oraz doGetMyPayoutsDetails - ale nowa metoda pobierania jest gorsza niż to co jest więc prosimy o poprawki, najlepiej gdyby była metoda, którą możemy pobrać dane dotyczące poszczególnej wypłaty, a jeżeli nie to chociaż prosimy o dodanie payment.id które jest w tytułach przelewów
zwróćcie Państwo uwagę na fakt, że nowa metoda wymusza od nas pobieranie tych samych danych wielokrotnie aby mieć pewność, że nic nie przeoczymy, np. transakcje z danego dnia musimy pobierać przez cały dzień, nie ma żadnego licznika, który nam powie które transakcje już pobraliśmy
skoro wysyłacie emailem listę z informacjami o wypłacie to dodajcie również zasób którym możemy taką listę odczytać a nie tylko udostępniliście zasób, żeby odhaczyć, że zrobione a potem niech się inni martwią jak tego użyć...
poprawka w dokumentacji
proszę uzupełnijcie też dokumentację
-
max limit = 100 (nie wiemy czemu nie 1000 jak w innych metodach?)
-
zwracany model wygląda (na szczęście) tak:
public class Balance
{
public string amount { get; set; }
public string currency { get; set; }
}
public class Wallet
{
public string paymentOperator { get; set; }
public string type { get; set; }
public Balance balance { get; set; }
}
public class Value
{
public string amount { get; set; }
public string currency { get; set; }
}
public class Payment
{
public string id { get; set; }
}
public class Address
{
public string street { get; set; }
public string city { get; set; }
public string postCode { get; set; }
}
public class Participant
{
public string id { get; set; }
public object companyName { get; set; }
public string login { get; set; }
public string firstName { get; set; }
public string lastName { get; set; }
public Address address { get; set; }
}
public class PaymentOperation
{
public string type { get; set; }
public string group { get; set; }
public Wallet wallet { get; set; }
public DateTime occurredAt { get; set; }
public Value value { get; set; }
public Payment payment { get; set; }
public Participant participant { get; set; }
}
public class PaymentOperations
{
public List<PaymentOperation> paymentOperations { get; set; }
public int count { get; set; }
public int totalCount { get; set; }
}
@Zbigniew-L Dziękuję za sugestie - przekazałem je do działu odpowiedzialnego za rozwój REST API.
Uwzględniając logikę pobierania zdarzeń o statusie READY_FOR_PROCESSING nie dostajemy zamówień, w których użytkownik wybrał formę płatności Płacę przelew tradycyjnym? Jeśli chciałbym pobierać płatności od zamawiających zamiast zdarzeń żeby obsłużyć przypadki przelewu tradycyjnego albo zaniechania zapłaty to w jaki sposób powinno wyglądać zapytanie żeby pobrać płatności od wskazanego payment.id oraz zjak rozpoznawać ich statusy? Jak wygląda struktura zwracanych obiektów? Widzę, że struktura jest inna niż ta w dokumentacji.
@BartekWroclaw Przelew tradycyjny to przelew realizowany poprzez PayU lub P24 - dlatego finalnie pomyślnie zrealizowana wpłata otrzyma status READY_FOR_PROCESSING. W Allegro nie ma już dostępnej opcji "zwykły przelew", który był realizowany bezpośrednio na rachunek sprzedającego.
Rozumiem. W jakich scenariuszach może wystąpić płatność częściowa? Jeśli wystąpi to płatność choćby częściowa to zdarzenie ma status READY_FOR_PROCESSING, prawda?
@BartekWroclaw Co rozumiesz pod pojęciem "płatność częściowa"?
Odnoszę się do: "Nadpłaty i niedopłaty W niektórych przypadkach klient może wpłacić nieodpowiednią kwotę za zakupione przedmioty. Wtedy w zamówieniu może wystąpić nadpłata lub niedopłata." Chodzi mi o niedopłatę. W sumie nadpłatę również. W jakich scenariuszach one mogą nastąpić?
@BartekWroclaw Przelew tradycyjny jest obarczony taką możliwością - kupujący dokonuje wpłaty i sam podaje kwotę zlecając przelew na rachunek PayU/P24. W tym momencie często kupujący zaokrąglają kwoty i tak powstają nadpłaty/niedopłaty. Można je w łatwy sposób wyliczyć np. poprzez porównanie wartości z pól summary.totalToPay.amount i payment.paidAmount.amount.
@BartekWroclaw Przelew tradycyjny jest obarczony taką możliwością - kupujący dokonuje wpłaty i sam podaje kwotę zlecając przelew na rachunek PayU/P24. W tym momencie często kupujący zaokrąglają kwoty i tak powstają nadpłaty/niedopłaty. Można je w łatwy sposób wyliczyć np. poprzez porównanie wartości z pól summary.totalToPay.amount i payment.paidAmount.amount.
W takim przypadku zdarzenie będzie miało oznaczenie READY_FOR_PROCESSING jak rozumiem?
Nie wiem dlaczego BartekWrocław pisałeś w tym wątku, który dotyczy całkowicie innego tematu... przetwarzanie zamówień nie ma wiele wspólnego z pobieraniem danych o wypłatach Allegro... czy mógłbyś może utworzyć nowy wątek na poruszony przez Ciebie temat? w tym wątku próbuję ustalić z Allegro czy będą w stanie podać nam dane o wypłatach Allegro w taki sposób aby księgowe mogły je jakoś powiązać z transakcjami bankowymi...
Nie wiem dlaczego BartekWrocław pisałeś w tym wątku, który dotyczy całkowicie innego tematu... przetwarzanie zamówień nie ma wiele wspólnego z pobieraniem danych o wypłatach Allegro... czy mógłbyś może utworzyć nowy wątek na poruszony przez Ciebie temat? w tym wątku próbuję ustalić z Allegro czy będą w stanie podać nam dane o wypłatach Allegro w taki sposób aby księgowe mogły je jakoś powiązać z transakcjami bankowymi...
Wątek dotyczy zasobu: GET /payments/payment-operations i ja o niego pytam. Nawiązałem do zdarzeń bo interesuje mnie powiązanie między płatnościami od klientów a zdarzeniami. Jak dla mnie to pasuje do tego wątku.
@MartaNowaczyk piszesz, że można go sortować. Próbuję na każdy możliwy sposób i nic z tego. Jesteś pewna, że sortowanie (interesuje mnie po dacie) jest możliwe?
@przestrzal tak, powinno to być możliwe. Widać to dobrze w dokumentacji i naszym poradniku. W każdym razie możesz podesłać przez nasz formularz kontaktowy pełnego cURL-a z requestem i responsem z dopiskiem GitHub #1826. Sprawdzę w czym jest problem.
@MartaNowaczyk już wysyłam. Rozumiem, że sortowanie po dacie zaistnienia zdarzenia powinno wyglądać w URLu następująco?
sort=occurredAt
Tutaj jeszcze tak dla porównania. W dokumentacji metody GET /sale/offers rzeczywiście piszecie o możliwości sortowania.
W przypadku GET /payments/payment-operations żadnej wzmianki na temat sortowania nie ma.
🤷♂️
Dziękuję za wyjaśnienie. Teraz wszystko jasne - ja piszę o filtrowaniu, ty o sortowaniu. Filtrować po dacie można i dostaniesz wtedy wyniki posortowane od najnowszych. Samego sortowania nie ma dla tego zasobu.
Dziękuję za wyjaśnienie. Teraz wszystko jasne - ja piszę o filtrowaniu, ty o sortowaniu. Filtrować po dacie można i dostaniesz wtedy wyniki posortowane od najnowszych. Samego sortowania nie ma dla tego zasobu.
a zostanie sortowanie dodane do tego zasobu? przydało by się, potrzebuje pobrać /payments/payment-operations od najstarszych w celu zapisu postępu pobierania
