II Opis techniczny e-Planus Retail^®

1. Serwisy e-Planus^® Retail

c. Zarządzanie cenami

Ceny w systemie są również zarządzane przez serwisy asynchroniczne, co daje wielokrotną możliwość użycia tych samych procedur, niezależnie od źródła zmiany cen (wewnętrzne lub zewnętrzne). Zarówno sprzedaż jak i przesyłanie cen są zarządzane przez ten sam mechanizm.

W e-Planus proces centralnego zarządzania cenami polega na okresowym sprawdzaniu kalendarzy cen i publikowanie startów i zakończeń zmian cen (daty i kwoty) dla docelowych grup obiektów. Zmiany cen mogą być zarządzane na następujących poziomów:

• Cała organizacja,
• Formuła,
• Grupa obiektów,
• Pojedyńczy obiekt.

Każdy obiekt, zależnie od konfiguracji, subskrybuje odpowiednie kanały publikacji. Przychodzące komunikaty są przetwarzane przez osobne obiekty równolegle dla każdego sklepu. Każdy sklep posiada swój własny stos cenowy. Oznacza to, że tylko zmiany cen są publikowane w systemie i komponent warstwy sklepu decyduje jaka zmiana będzie obowiązująca po zakończeniu obowiązywania ostatnio używanej ceny. Takie podejście daje możliwość implementacji skomplikowanych schematów zarządzania cenami bez ryzyka przeciążenia systemu.

d. Generacja zamówień

Serwis generowania zamówień jest używany zarówno z interfejsu końcowego użytkownika (umożliwienie na żądanie wygenerowania propozycji zamówienia) jak i przez serwis pracujący w tle oparty na kalendarzu zamówień. Algorytm generowania zamówień może być korygowany przez informacje o sezonowości. System uwzględnia dwa schematy sezonowości:

• Sezonowość typu I - podczas okresów sezonowych, wyliczana w oparciu o wysokość średniej sprzedaży, ilość towaru do zamówienia ulega zwiększeniu lub zmniejszeniu o zdefiniowany procent. Taki schemat ma zastosowanie dla zamawiania napojów, lodów i innych towarów sprzedawanych przez cały rok, na które jednak popyt wzrasta w pewnych okresach.
• Sezonowość typu II - schemat ma zastosowanie dla towarów, które praktycznie są sprzedawane w krótkich okresach (np. ozdoby choinkowe). Dla takich towarów wyliczanie średniej sprzedaży na początku jak i na końcu okresu sprzedaży jest bezcelowe. Dla takich towarów ilość do zamówienia obliczana jest na początku okresu sprzedaży, a po jego zakończeniu towary te praktycznie przestają być zamawiane.

e. Obsługa systemu kasowego (Front Office)

System może obsługiwać różne systemy kasowe w tej samej instalacji. Każdy sklep może posiadać inny system kasowy. Wszystkie systemy kasowe są obsługiwane przez taki sam mechanizm, różnice mogą dotyczyć:

• Formatu plików,
• Zakresu informacji wymienianych z systemem Back Office,
• Poziomu agregacji informacji o sprzedaży (paragony i dzienna sprzedaż).

Standardowa instalacja może obsługiwać następujące systemy kasowe:

• System e-Planus^® Retail Front Office,
• IBM SA,
• Siemens Position.

Inne interfejsy obsługi systemów kasowych mogą zostać przygotowane na żądanie użytkownika.

Poniżej opisana została komunikacja z systemem kasowym na podstawie e-Planus^® Front Office. SKG zapewnia własny system kasowy, oparty na Linux, którego jednym z głównych założeń jest zmniejszenie liczby urządzeń pracujących w sklepie do minimum. Każda kasa jest samodzielnym urządzeniem, pracującym niezależnie od innych urządzeń i komunikującym się z centralnym systemem Back Office jeśli jest to potrzebne. Jeśli nie, dane są gromadzone w lokalnej bazie danych i czekają na możliwość przesłania do systemu centralnego.

Z systemem e-Planus^® Back Office kasy komunikują się przez serwis Web, używając protokołu SOAP. Komponent umożliwiający pracę serwisu Web współpracuje z serwisem e-Planus^® opartym o komunikaty. Każda kasa posiada własną kolejkę ładowania danych. Procesy na kasie wysyłają zapytanie do serwisu Web, czy nie oczekują tam dla nich w kolejce jakikolwiek komunikaty. Kanał ten może być używany nie tylko do ładowania danych, ale także do przesyłania różnych poleceń do kasy a nawet aktualizacji wersji oprogramowania kasowego. Komunikaty są odczytywane z kolejki w dwóch fazach, w trybie potwierdzenia. W pierwszym etapie zawartość komunikatu jest przekazywana do kasy, ale jeszcze czeka w kolejce na potwierdzenie procesu. Po pozytywnym zatwierdzeniu sygnał jest przesyłany do serwisu Web i komunikat jest na stałe usuwany z kolejki. Jeżeli komunikat nie zostaje potwierdzony (np. kasa może być restartowana podczas procesu) zostanie on przesłany w następnym poleceniu. Jeżeli kasa nie pracuje przez dłuższy czas, wszystkie wysłane komunikaty czekają w kolejce i są gotowe do wysłania, gdy kasa rozpocznie pracę.


Podobna technika została zastosowana do wysyłania informacji z kasy do systemu Back Office. Dla takiego procesu istnieje wspólna kolejka w sklepie, która jest ładowana poprzez serwis Web ze wszystkich kas w sklepie. Informacja jest odczytywana z kolejki przez konfigurowalną liczbę wątków, umożliwiając właściwą regulację ładowania systemu. Paragony odczytane z kolejki są składowane w bazie paragonów do dalszej obsługi i w tym samym procesie agregowane do jednego dokumentu sprzedaży dla sklepu. Także informacja o płatnościach z paragonów jest agregowana w przepływie dokumentów kasowych umożliwiając automatyczne przygotowanie raportów przepływu gotówki.