getPaymentsOperationHistory dodatkowy atrybut ID Zamówienia

[ricarderobl]

Z metody payments/payment-operations mogę pobrać tylko id płatności i nic więcej jeżeli chodzi o identyfikator zdarzenia. A chcę płatności łączyć z konkretnymi zamówieniami, bo one są do konkretnych zamówień tj. wpłaty są do konkretnych i zwroty są do konkretnych zamówień, a nie same z siebie w osobnym jakby to ująć bycie.

Przykład. Kupujący Client:111111111 zamówił towar dnia 2024-02-01 na 100zł, a potem wykonał zwrot 2024-02-03 za 40zł. Następnie kupił dnia 2024-02-04 za kwotę 150zł i zwrócił w dniu 2024-02-04 za 100zł (przed wysyłką rozmyślił się i zrezygnował z jednego produktu). Oprócz niniejszego klienta są jeszcze wiadomo inni, ale próbujemy ustalić czy wysokości zwrotów jak i zaksięgowane wpłaty są poprawne. Nie mogę łączyć na loginie, bo mam już 4 operacje płatnicze a dla każdej login ten sam, a są to 4 inne zdarzenia. Nie mogę też mieszać do tego daty, bo data nie jest identyfikatorem.

Mamy teraz 4 operacje płatnicze - dwie wpłaty za zamówienia i dwa zwroty wpłat. O ile jeszcze zamówienia można by było tak sprawdzić, że wziąć to z GET /order/checkout-forms ID płatności i po nim połączyć potem tabelę z listą historii płatniczych (tabela tworzona z użyciem metody payments/payment-operations). W ten sposób tak, miałbym połączenie ID Zamówienia z ID Płatności i byłoby to unikalne połączenie.

To rozwiąże tylko połowę problemów więc niniejsze rozwiązanie jest marnym rozwiązaniem. Natomiast sam login nie jest unikatowy, bo kupujący może wykonać kilka zamówień w danym okresie i kilka zwrotów i wtedy jak mam to połączyć z odpowiednimi zamówieniami i zwrotami?

Gdyby dodać atrybut ORDER_ID do metody getPaymentsOperationHistory wtedy można by było wygodnie spiąć do zamówień zarówno zwroty jak i wpłaty, gdyż większość operacji w zakładce tyczy się konkretnych zamówień.

Dodatkowo moim zdaniem byłaby to niezwykle przydatna i bardzo łatwa do wprowadzenia funkcja. Starczy tylko dodać ten jeden atrybut w JSON w odpowiedzi na zapytanie getPaymentsOperationHistory i rozwiązałoby to wszystkie problemy.

Innymi słowy dopóki nie będę miał ID Zamówienia z metody getPaymentsOperationHistory nie mam klucza obcego w tabeli z danymi pobranymi tą metodą przez co nie mogę poprawnie analizować wpłat, zwrotów i dopłat.

[ricarderobl]

Dodam jeszcze, że niniejsza zmiana nie byłaby nijak inwazyjna, bo dodanie atrybutu do JSON'a jest proste. Sama struktura polecenia też nie uległaby zmianie, jedynie odpowiedź byłaby o dodatkowe pole, co nie wpłynęłoby nijak na tych co już używają tego endpointu.