Wszyscy kontrahenci spięci w jeden panel B2B

marek_banner

B2B contractor to moduł dystrybucyjny, wspierający sprzedaż na określonych warunkach kontraktowych. Pozwala on udostępnić kontrahentom indywidualny panel B2B, w celu umożliwienia im dokonywania zamówień. Zawarte są w nim wszelkie dokumenty dotyczące kontraktu i zamówień oraz dane kontrahenta, jego placówek i pracowników.

Panel B2B umożliwia utworzenie podmiotu gospodarczego (kontrahenta), który posiada warunki handlowe określone kontraktem ofertowym. Zarejestrowani pracownicy, powiązani z kontrahentem mają możliwość zakupu produktów w określonej cenie – zgodnie ze zdefiniowanymi warunkami kontraktu. Prócz powiązania Kontrahent – Pracownik, istnieje również możliwość dodania relacji agencyjnej pomiędzy placówką handlową a kontrahentem i pracownikiem. Dzięki temu, zarządzanie dostępem do informacji handlowych podmiotu odbywa się na poziomie konkretnego pracownika, placówki lub wszystkich danych kontrahenta.

Panel B2B w praktyce

iqsi-screenshot

Partnerem biznesowym (kontrahentem) dystrybutora kawy jest sieć kawiarni. Dystrybutor udostępnia jej swój panel sprzedażowy. Otrzymany dostęp do panelu sprzedażowego zapewnia dostęp do indywidualnej oferty cenowej produktów Sieć posiada dwie placówki, którymi zarządzają managerowie. Jedna zlokalizowana jest w Gdańsku, druga w Katowicach. Placówki nadzoruje  dyrektor w Warszawie, który jest administratorem panelu kontrahenta. Administrator posiada dostęp do wszystkich informacji handlowych, zamówieniowych i ofertowych kontrahenta. Managerowie placówek w Gdańsku i Katowicach kupują asortyment jedynie dla swoich lokalizacji. Mają oni także udostępniony widok wyłącznie zamówień ze swoich placówek. Panel B2B może być dostępny dla większej ilości pracowników którejś z placówek, po ówczesnej autoryzacji. Wówczas wszyscy pracownicy z dostępem widzą nawzajem swoje zamówienia. Wszystkie placówki kontrahenta mają te same ceny, określone w kontrakcie.

Dostępne są również rozwiązania komplementarne, wspierające działanie panelu B2B. Jednym z nich jest określenie minimum logistycznego zamówienia. Panel B2B może być również personalizowany pod konkretnego kontrahenta, poprzez dodanie jego kolorystyki oraz logo. Innymi rozwiązaniami są: obsługa zwrotów i reklamacji, możliwość negocjacji cen bezpośrednio przez system sprzedażowy oraz ustalanie odroczonych terminów płatności.

Dodatkową możliwością jest rozdzielenie asortymentu na grupy towarowe, z określonymi indywidualnymi cenami. Kolejną rzeczą jest możliwość wygenerowania oferty przez kontrahenta, dla jego klienta, bezpośrednio z panelu B2B.

Rozwiązanie umożliwia firmie spięcie wszystkich jej kontrahentów oraz ich danych w jeden system sprzedażowy, a kontrahentom daje zaś dostęp do panelu, z którego sami mogą dokonywać zamówień. Panel B2B zawiera również zindywidualizowane oferty oraz wszystkie dokumenty kontrahentów. Firma posiadająca system sprzedażowy B2B może mieć pewność, że wszyscy kontrahenci będą składać zamówienia po określonych w kontrakcie cenach, co oznacza, że nie trzeba będzie weryfikować tych zamówień ręcznie.
Zobacz inne rozwiązania B2B

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ę 😉