WIR Hurtownia Artykułów Przemysłowych

Cały katalog i całe zamówienie mieszczą się w arkuszu, a system nie ma ani jednej tabeli w bazie danych - tak działa portal zamówień B2B, który hurtownia kosmetyczno-chemiczna WIR postawiła obok swojej strony firmowej. Kontrahent otwiera katalog w przeglądarce, składa zamówienie w koszyku i dostaje potwierdzenie mailem.

Arkusz jako źródło katalogu

Hurtownia co miesiąc przygotowuje gazetkę: arkusz z nazwą towaru, grupą handlową, symbolem, kodem EAN i ceną jednostkową. Ten sam plik, bez żadnej konwersji ani kroku pośredniego, jest źródłem katalogu w portalu. Parsuje go SheetJS po stronie przeglądarki, a nie serwer.

Wygląda to na oszczędność. Bliżej temu do dopasowania się do organizacji. Aktualizacja oferty nie wymaga panelu administracyjnego, importu ani szkolenia. Osoba, która i tak co miesiąc składa gazetkę, podmienia plik i katalog jest gotowy. Nie ma drugiego miejsca, w którym cennik mógłby się rozjechać z tym, co hurtownia wysyła kontrahentom.

Cena jest w portalu jedna, ta z arkusza. Warunki indywidualne ustala dział sprzedaży przy potwierdzaniu zamówienia, więc aplikacja nie próbuje ich odtwarzać.

Zamówienie wraca tam, gdzie pracuje sprzedaż

Koszyk powstaje w całości w przeglądarce. Kontrahent filtruje katalog po grupach handlowych, dokłada pozycje, sprawdza podsumowanie i podaje adres dostawy razem z uwagami. Gotowe zamówienie idzie do endpointu w PHP, zbudowanego na PHPMailer, który składa je w tabelę i wysyła: kontrahentowi jako potwierdzenie, hurtowni jako zlecenie do realizacji. Ta sama tabela jedzie w załączniku, więc zamówienie da się odłożyć jako osobny plik, nie tylko jako treść wiadomości. Niezależnie od maila kontrahent może pobrać swoje zamówienie z aplikacji jako arkusz, w tym samym formacie, w którym hurtownia wydaje katalog.

Zamówienie ląduje więc w skrzynce, czyli w narzędziu, którego dział sprzedaży używa od lat. Nie trzeba się logować do kolejnego systemu, żeby zobaczyć, co przyszło. Ten sam rachunek robimy przy oprogramowaniu na zamówienie. Pytanie otwierające brzmi, w jaki obieg pracy system ma wejść.

Backend pozostaje bezstanowy. Nie prowadzi historii zamówień, bo historia zamówień hurtowni żyje w jej systemie sprzedaży, a nie w portalu, który zamówienia zbiera.

Frontend i strona firmowa

Portal napisany jest w Angularze z TypeScriptem, na komponentach PrimeNG, z testami jednostkowymi w Karma i Jasmine. Stos jest celowo konwencjonalny: framework z gotowym zapleczem komponentów skraca drogę od makiety do działającego katalogu, a testy pilnują parsowania arkusza, czyli jedynego miejsca, w którym błąd po cichu zmieniłby cenę.

Strona firmowa hurtowni stoi osobno, na WordPressie. Wybór był świadomy i należał do klienta: treści miały zostać po stronie firmy, bez pośrednika przy każdej zmianie. Portal zamówień jest odrębną aplikacją pod własnym adresem, więc jedno nie blokuje drugiego przy aktualizacji.

Co z tego wynika

Zamówienie składa się w przeglądarce, zamiast przez telefon i mail z listą pozycji w treści. Kontrahent widzi symbol, kod kreskowy i cenę, a dział sprzedaży dostaje komplet w jednym formacie, z adresem dostawy i uwagami na miejscu.

Miesięczna gazetka nie wymaga drugiej wersji dla portalu. Ten sam arkusz, który idzie do kontrahentów, jest katalogiem.

Konstrukcja ma swój sufit. Skrzynka pocztowa działa jak kolejka do momentu, w którym zamówień robi się na tyle dużo, że przestaje się w niej mieścić dzień pracy.