Rozwiązania eCommerce w B2B – zarządzanie należnościami

zarządzanie należnościami

Zarządzanie należnościami to proces, którego głównym celem jest zapobieganie powstawaniu przeterminowanych należności. Skuteczne zarządzanie należnościami łączy w sobie działania obejmujące prewencję, monitoring i windykację. Dokładnie takie zadania wykonuje moduł ARMS, który sprawdza się nie tylko w systemach B2B. Dzięki niemu poprawia się płynność finansowa firmy, a koszty związane z obsługą należności ulegają redukcji. Usprawnia się również praca całego zespołu odpowiedzialnego za finanse firmy.

Działanie i architektura

Za skrótem ARMS kryją się słowa Account Receivable Management System. To autorski moduł odpowiadający za monitorowanie należności i sprawne reagowanie. Rozwiązanie ARMS daje możliwość dowolnego definiowania zadań. Każde zadanie zawiera własny warunek oraz działanie. Warunkiem może być liczba dni po terminie płatności, a działaniem wysłanie powiadomienia w formie maila. W tym wypadku, jeśli kontrahent zalega tydzień z płatnością, automatycznie wysyłany jest do niego mail z przypomnieniem. Liczba dni, forma powiadomienia, treść maila i inne zmienne mogą być dowolnie edytowalne.

zarządzanie należnościami

Schemat w uproszczeniu pokazuje proces działania modułu ARMS. Codziennie o zdefiniowanej wcześniej godzinie, moduł rozpoczyna swoja pracę. Następnie weryfikuje płatność względem statusu wiarygodności klienta. Jeśli płatność spełnia warunki zadania (np. brak płatności w ciągu tygodnia po wystawieniu faktury), moduł podejmuje kolejne, wcześniej określone działania. Wszystkie czynności są zapisywane w postaci rejestru logów. W panelu głównym modułu ARMS widzimy dokładną historię wykonania zadań oraz ich rezultat. Przykładowymi zadaniami w module ARMS mogą być:

– wysłanie maila do klienta z podziękowaniem w dniu wystawienia dokumentu (faktury lub zamówienia),

– dodanie do kalendarza zadania dla pracownika, aby skontaktował się z klientem trzy dni po terminie płatności,

– automatyczne zablokowanie możliwości składania zamówień przez kontrahenta w momencie przekroczenia określonych termninów,

– wysłanie do klienta przypomnienia w formie maila na dwa dni przed terminem płatności.

Segmentacja klientów poprzez stopień zaufania

Definiowanie zadań można również połączyć ze statusem wiarygodności jaki został przypisany do konkretnego klienta. W ramach ustawień w systemie dostępne są trzy statusy wiarygodności kontrahenta: zielony, żółty i czerwony. Dla każdego statusu możliwe jest zdefiniowanie dowolnej liczby zadań. Przykładowa lista zadań dla klienta najbardziej zaufanego (zielonego), może ograniczać się tylko do mailowego przypomnienia o nieopłaconej fakturze dwa dni po terminie płatności. Z kolei klienci żółci, czyli posiadający średni stopień zaufania, mogą być dodatkowo informowani telefonicznie na jeden dzień przed terminem płatności. Stopień wiarygodności klienta nie jest przypisany na stałe. Widząc terminową i rzetelną spłatę należności klienta oznaczonego kolorem żółtym, po miesiącu dobrej współpracy, możemy “przenieść” go do koloru zielonego.

Moduł ARMS do zarządzania należnościami sprawdzi się w każdym rodzaju sprzedaży. Jego funkcje nie ograniczają się tylko do windykacji. Kładzie on duży nacisk na prewencyjny monitoring płatności. Możliwość połączenie z innymi modułami i rozwiązaniami sprawia, że jest on gwarantem zachowania płynności finansowej całej firmy.

Zobacz również artykuły o podobnej tematyce

B2E, czyli skuteczne wsparcie organizacji pracy
B2E banner

Jak sprawić, by organizacja efektywnie funkcjonowała na współczesnym rynku? Każdy kto prowadzi firmę wie, że kwestia ta potrafi spędzać sen...

Aplikacja mobilna brakującym ogniwem omnichannel?
aplikacja mobilna

W 2018 r. strategia omnichannel wydaje się standardem. Wszystkie liczące się marki posiadające sieć sklepów stacjonarnych połączyły w większym lub...

Czy człowiek może być kolorem? Kapitał ludzki, jako największa wartość w organizacji
ludzie-1

Chcąc prowadzić innowacyjną i ponadczasową firmę należy bacznie obserwować indywidualne predyspozycje pracowników. Nie każdy z nich nadaje się do pracy...

Zobacz więcej wpisów
  • http://oferownik.pl Robert Marketingowiec

    Nie da się być mocnym we wszystkich kanałach komunikacji, trzeba sobie wypracować te które najbardziej się wybijają i się ich trzymać.

  • Marcin

    „Dawno temu skupialiśmy się na ważnych rzeczach, czyli rozwiązywaniu problemów i logice biznesowej. Dzisiaj jesteśmy prawie całkowicie skoncentrowani na abstrakcji i generalizacji.” – i to wszystko wina frameworków? Czy to wina cegieł i zaprawy że murarze krzywo wybudowali mur, czy jednak problemem było nieprofesjonalne podejście fachowców, którzy ubzdryngoleni przyszli do pracy? Nie możemy zrzucać winy na narzędzia, za to że źle tworzymy aplikacje. Powinniśmy raczej starać się dostrzec fakt, że problem leży w nas samych i spróbować go zrozumieć… oraz coś z nim zrobić. I na pewno nie jest metodą na ów problem podejście, że „powinniśmy używać PHP, a nie architektury do budowania aplikacji” – taki tok rozumowania jest idealnym dowodem na to jak wiele osób nie rozumie czym jest architektura. Architektura to nie framework! Posłużę się kolejnym odwołaniem do budownictwa: czy patrząc na kościół pierwsze co widzimy to to, z czego jest on zbudowany czy raczej jakie jest jego przeznaczenie. Albo: czy widząc bramę pierwszą naszą myślą jest „użyli cegieł z Castoramy i wkrętarki boscha” czy raczej „to jest brama – służy do tego by gdzieś wejść lub skądś wyjść”?
    To prawda – we współczesnym programowaniu zapominamy o logice biznesowej, ale nie jest to wina architektury, tylko raczej braku dyscypliny w nas samych – nie interesuje nas to, nas jara głównie fakt że piszemy np. w kotlinie bo to jest teraz modne. „Zrobię to na symfony, zapytania puszczę doctrinem a obiekty będę serializować jms’em” – to nie jest opis architektury, to lista zakupów – jakich narzędzi potrzebuję by zrealizować cel. Szkoda tylko, że przez to cel ląduje na drugim (albo i nawet dziesiątym) miejscu – a celem jest np. zbudowanie aplikacji do przechowywania dokumentów. Ale to nie decyzja twórców bibliotek/frameworków, że cel staje się dla nas mało istotny. To nie Fabien Potencier każe nam całą logikę wrzucać do akcji w kontrolerze, to nie Jonathan Wage podpowiada nam, by nasze biznesowe obiekty bezpośrednio wywoływały doctrine’a! To my, my programiści sami doprowadzamy do tego, że nasze aplikacje przypominają niestrawione resztki pokarmu które codziennie zostawiamy w porcelanowym ekspresie. I póki nie nauczymy się odseparowywać logiki biznesowej od narzędzi to dalej będziemy tworzyć legacy code.
    Co do argumentu, że niektóre z zależności mogą zostać po kilku latach porzucone i nie będą dalej rozwijane… serio? I proponujesz phpti jako alternatywę do twiga albo smarty? Wszystko może zostać po kilku latach porzucone, to do obowiązków programisty należy m.in. nie pozwolić na to, by moduły/komponenty nie były sprzężone z innymi elementami czy zewnętrznymi bibliotekami.
    A co do bogactwa wiedzy i tego co się dzieje pod maską – ogólnie nie powinno się używać narzędzi, których się nie rozumie: jak działają, dlaczego tak działają itp. By potem nie było sytuacji w stylu senior piszący od 5 lat w laravelu nie potrafi odpowiedzieć na rozmowie kwalifikacyjnej na pytanie „Co robi funkcja die()?”…

    TL;DR: nie zgadzam się 😉