Wiedząc jak działa program (w tym przypadku moduł Homebankingu, który identyfikuje kontrahenta tylko i wyłącznie na podstawie rachunku bankowego) odpowiedź jest oczywista - nikt sobie nie poradził, gdyż program nie posiada takiej funkcjonalności.

Przy takiej skali nikt nie robi z tego problemu, ale zdarza się, że niektóre firmy mają bardzo dużo transakcji kartami, gdzie jest potrzeba określenia kontrahenta końcowego i na taką okoliczność realizowałem rozwiązania, które mapują kontrahenta na podstawie tytułu płatności.

Wspomnę również o płatnościach masowych, które pozwalają identyfikować kontrahentów na podstawie rachunku na który jest dokonywana wpłata, a nie z którego jest wykonywana, ale to wymaga co najmniej dodatkowego parsera.

I co jest złego w rozwiązaniach dodatkowych skoro pozwalają oszczędzać czas i pieniądze ?

Nic Panie Danielu

Jednak czasem niekoniecznie trzeba od razu płacić, jak jest opcja darmowa. Dodatkowo zawsze się czegoś nowego można nauczyć

Ale skąd założenie, że za wszystkie rozwiązania dodatkowe trzeba płacić ? Oferuję przecież kilka rozwiązań za darmo, są opublikowane na naszej stronie, co jakiś czas staram się dodawać nowe, wiele innych udostępniam na zasadach "dobrej współpracy", ale z czegoś też muszę żyć, więc naturalnie większość jest odpłatna...

Zawsze też proponuję w pierwszej kolejności rozwiązania dostępna w standardzie zanim zaproponuję rozwiązanie płatne.

Jednak w tym miejscu zapytam o Pańskie autorskie rozwiązanie: jak ono sobie teraz radzi, przy tych split paymentach? Nie gubi się?

Ale to nie ma żadnego związku - identyfikacja kontrahenta i rodzaju operacji bankowej to dwa różne tematy. Nie rozumiem też co może się gubić, nie znam problemów w tym obszarze, Insert większość sowich parserów już dostosowała, nasze aktualizujemy po zgłoszeniach od klientów i otrzymaniu przykładowych danych.