Metis — Zaawansowany Model Finansowy dla Importu B2B i E-Commerce

Metis to zaawansowany Cyfrowy Bliźniak (Digital Twin) struktury finansowo-operacyjnej, dedykowany skomplikowanym przedsiębiorstwom importowym z wielokanałową sprzedażą w modelu B2B oraz E-Commerce. Oblicza i rozdziela każdy element kosztu związanego z przepływem towaru i utrzymaniem infrastruktury magazynowej: od pojedynczej faktury zakupowej w walucie obcej, przez cło, transport i ubezpieczenie, aż po wynagrodzenia zespołu, leasing floty i obsługę zadłużenia inwestycyjnego przypisane do konkretnej lokalizacji. System nie operuje na uśrednionych kosztach ogólnych — każda pozycja kosztowa ma swój klucz alokacji, swoje źródło danych i swoje miejsce w strukturze magazynu, co pozwala liczyć koszt jednostkowy zapasu (WAC) i pełny koszt utrzymania magazynu z precyzją niemożliwą do osiągnięcia przy ręcznym, uśrednionym budżetowaniu.

Warstwa obliczeniowa systemu Metis zbudowana jest w Excelu jako sieć powiązanych formuł operujących na współdzielonych kluczach — identyfikatorze magazynu, identyfikatorze produktu, dacie okresu rozliczeniowego. Formuły nie liczą w izolacji: koszt zapasu w danym miesiącu zależy od kosztu z miesiąca poprzedniego (kalkulacja rekurencyjna), a koszt magazynu zależy od struktury zespołu przypisanego do jego dywizji oraz kluczy alokacji zdefiniowanych centralnie dla całej sieci magazynów. Zmiana jednej wartości źródłowej — kursu waluty, procentu alokacji, składu zespołu — propaguje się przez wszystkie powiązane moduły. Poniższe opisy modułów należy czytać jako elementy jednego systemu naczyń połączonych, nie jako niezależne funkcje.

Architektura systemu Metis opiera się na tej samej zasadzie co w pozostałych systemach rodziny — każdy komponent robi to, w czym jest najlepszy. Excel zapewnia krystaliczną jakość wyliczeń wraz z pełną kontrolą modelu i przejrzystością formuł. Wyniki obliczeń zapisywane są do bazy danych NoSQL, skąd dystrybuowane są dalej w firmie jako budżety, scenariusze i dane do analiz porównawczych. Python obsługuje logikę integracji i przetwarzania danych źródłowych. React buduje dashboardy. Modele językowe wspierają interpretację już wyliczonych, pewnych danych liczbowych — LLM nie liczy, tylko nadaje liczbom z Metis narrację.

AGENTS — Metis jako źródło danych, reguł i dyrektyw dla agentów Quantis

Metis nie tylko liczy na potrzeby raportów — jest źródłem danych, reguł i dyrektyw dla agentów działających w ramach Quantis, tego samego silnika, który w warstwie prognostycznej stoi za FORECAST: Adaptive Demand Engine. W tej roli działają obecnie dwa agenty; poniżej opisany jest jeden z nich — agent odpowiedzialny za generowanie propozycji zamówień uzupełnień stocku.

AGENTS: Replenishment Recommendation Agent

Generuje propozycje zamówień uzupełniających zapas na podstawie danych operacyjnych i finansowych dostarczanych przez Metis, które pełnią dla agenta podwójną rolę — są jednocześnie celami, do których dąży, i ograniczeniami, których nie może przekroczyć. Dzięki temu, że Metis dynamicznie liczy marżę kontrybucyjną i ma dokładnie rozpoznane koszty magazynowania, zamówień i pozostałych składowych kosztu, agent formułuje propozycje dopasowane do rzeczywistej rentowności danego SKU, a nie tylko do samego poziomu zapasu. Rekomendacje uwzględniają też plany finansowe firmy — Metis udostępnia agentowi planowany cash flow i CapEx, więc propozycja zamówienia nie powstaje w oderwaniu od tego, czy firma w danym okresie faktycznie ma na nią przestrzeń finansową. Dodatkowo Metis definiuje twarde ograniczenia w postaci budżetów przypisanych do stocku oraz priorytetów porządkujących kolejność, w jakiej agent powinien traktować konkurujące ze sobą potrzeby zamówieniowe.

Korzyści:

• Rekomendacje zamówień uwzględniają rentowność produktu, nie tylko sam poziom zapasu — priorytet naturalnie dostają zamówienia, które faktycznie się opłacają.
• Agent nie zarekomenduje zamówienia, na które firma nie ma pokrycia finansowego — planowany cash flow i CapEx działają jako twardy filtr, nie tylko sugestia w tle.
• Budżety i priorytety zdefiniowane centralnie w Metis pozwalają agentowi rozstrzygać konflikty między konkurującymi potrzebami zamówieniowymi w sposób spójny z polityką firmy, a nie doraźnie, przypadek po przypadku.
• Dane, na których pracuje agent, to te same liczby, które widać w modułach źródłowych Metis — rekomendacja jest w każdej chwili możliwa do prześledzenia do konkretnej pozycji kosztowej czy prognozy, która ją uzasadnia.

INTEGRATIONS — Metis jako źródło planu dla systemów zewnętrznych

INTEGRATIONS: Echo Operational Cash Flow Source

Metis pełni rolę źródła planu i danych dla Echo — komponentu odpowiedzialnego za zarządzanie operacyjnym cash flow. Echo uzupełnia obraz płynności firmy o informacje, których fizycznie nie ma jeszcze na fakturach: płatności, które są znane i pewne, zanim jeszcze pojawi się dokumentująca je faktura. Metis dostarcza Echo plan oraz dane źródłowe potrzebne do tego uzupełnienia, dzięki czemu zarządzanie cash flow operacyjnym opiera się nie tylko na tym, co już zostało zafakturowane, ale też na tym, co zaplanowane i pewne, a jeszcze niezaksięgowane.

Korzyści:

• Obraz płynności firmy nie jest opóźniony o cykl fakturowania — znane, pewne płatności są widoczne w cash flow, zanim jeszcze wpłynie faktura.
• Planowanie płynności operacyjnej opiera się na tych samych, spójnych danych planistycznych co reszta modelu finansowego, a nie na osobnym, ręcznie prowadzonym arkuszu prognoz płatności.

STOCK — wycena zapasów magazynowych

STOCK: Purchase Order Costing

Przelicza każde zamówienie zakupowe na wartość w PLN, traktując zaliczkę i dopłatę jako osobne zdarzenia płatnicze z osobnymi kursami walut. Dla każdej płatności moduł najpierw sprawdza, czy podano kurs rzeczywisty (bankowy) — jeśli tak, używa go zamiast kursu tabelarycznego; jeśli nie, sięga do tabeli kursów wg miesiąca danej płatności. Ta sama logika stosowana jest osobno do kosztu transportu, z kursem dobieranym wg daty płatności za transport, nie wg daty zakupu towaru. Moduł zasila STOCK: Weighted Average Cost Engine wartością i ilością zakupu przypisaną do danego produktu i okresu.

Korzyści:

• Koniec z jednym uśrednionym kursem dla całej faktury — każda płatność rozliczana po realnym kursie z dnia jej wykonania.
• Zespół finansowy nie musi ręcznie pilnować, który kurs zastosować przy zaliczce, dopłacie czy transporcie.
• Zakupy w EUR, USD, GBP i CNY liczone tym samym, spójnym mechanizmem — bez wyjątków i ręcznych korekt.

STOCK: Customs & NBP Rate

Nalicza cło do podstawy kosztu zapasu. Podstawa celna — suma wartości towaru, transportu i ubezpieczenia — przeliczana jest odrębnym, urzędowym kursem NBP, zgodnie z praktyką rozliczeń celnych, niezależnie od kursu transakcyjnego zastosowanego do zaksięgowania faktury. Stawka procentowa cła dobierana jest z centralnej tabeli stawek na podstawie identyfikatora taryfy przypisanego do zamówienia oraz okresu rozliczeniowego. Brak zdefiniowanej stawki dla danej pozycji skutkuje naliczeniem cła zerowego, a nie błędem kalkulacji. Wynik modułu wchodzi bezpośrednio do wartości zakupu liczonej przez STOCK: Purchase Order Costing.

Korzyści:

• Podstawa celna liczona zgodnie z praktyką urzędową (kurs NBP), więc wycena zapasu jest zgodna z tym, jak faktycznie rozlicza się cło.
• Brak zdefiniowanej stawki nie wywraca raportu błędem — system po cichu przyjmuje 0 i idzie dalej.
• Cło nie jest osobnym, ręcznie doklejanym kosztem — jest integralną częścią kosztu jednostkowego produktu od pierwszego dnia.

STOCK: Weighted Average Cost Engine

Rdzeń wyceny zapasów — liczy koszt jednostkowy każdego produktu metodą kroczącej średniej ważonej (WAC), osobno dla każdego okresu rozliczeniowego. Mechanizm działa dwuetapowo: najpierw dolicza zakup bieżącego okresu do stanu z okresu poprzedniego i przelicza nową średnią ważoną, dopiero potem tą zaktualizowaną średnią wycenia sprzedaż z tego samego okresu — co odróżnia go od prostszych modeli liczących rozchód po cenie sprzed dostawy. Zapas wyprzedany do zera lub poniżej w danym okresie nie przerywa kalkulacji: moduł przenosi jako koszt bazowy ostatnią zaktualizowaną średnią. Wynik każdego okresu staje się punktem startowym dla okresu następnego — stąd kalkulacja ma charakter rekurencyjny wzdłuż osi czasu.

Korzyści:

• Koszt sprzedanego towaru (COGS) zawsze uwzględnia najświeższą dostawę z tego samego okresu, nie cenę sprzed miesiąca — solidna podstawa do liczenia prawdziwej marży, zamiast przybliżenia.
• Wyprzedaż całego stanu nie psuje raportu — system nie dzieli przez zero, tylko sensownie kontynuuje na ostatniej znanej cenie.
• Jeden spójny mechanizm dla całego katalogu produktów, niezależnie od tego, jak często dany SKU jest kupowany czy sprzedawany.

STOCK: New Product Fallback

Obsługuje przypadek produktu bez żadnej historii magazynowej — brak stanu z okresu poprzedniego i brak zakupu w okresie bieżącym. Zamiast zerowej wyceny, moduł sięga do kartoteki produktów po cenę katalogową i przelicza ją na PLN właściwym kursem waluty. Zapobiega to sytuacji, w której nowo wprowadzony produkt raportowany jest z zerowym kosztem zapasu mimo realnie istniejącej wartości.

Korzyści:

• Nowe produkty pojawiają się w raporcie z realną wyceną od pierwszego dnia, nie z zerem, które sztucznie zawyża marżę.
• Wdrożenie nowego SKU do asortymentu nie wymaga ręcznego „doszacowania" kosztu przez zespół finansowy.

STOCK: Warehouse Cost Allocation by Volume

Rozkłada koszt magazynu z WAREHOUSE: Cost Matrix Output na pojedynczy produkt (SKU), proporcjonalnie do zajmowanej przez niego objętości. Mechanizm: koszt całego magazynu dzielony jest przez sumę objętości wszystkich produktów przypisanych do tego magazynu, dając koszt jednostkowy za m³, który następnie mnożony jest przez objętość konkretnego SKU. To domyka łańcuch kosztowy Metis na najniższym poziomie szczegółowości — łączy koszt lokalizacji (WAREHOUSE) z kosztem konkretnego produktu (STOCK), będąc bezpośrednim wsadem do marży kontrybucyjnej per SKU.

Korzyści:

• Koszt magazynowania przestaje być kosztem „ogólnym" doliczanym ryczałtem — produkt zajmujący więcej miejsca ponosi proporcjonalnie wyższy koszt magazynowy.
• Koszt przechowywania staje się osobną, policzalną składową kosztu produktu — gotową do uwzględnienia w marży kontrybucyjnej per SKU, obok kosztu zakupu.
• Produkty nieopłacalne pod względem zajmowanej przestrzeni magazynowej stają się widoczne, nawet jeśli sama marża handlowa na nich wygląda dobrze.

FORECAST — prognozy sprzedaży

FORECAST: Adaptive Demand Engine

Metis pobiera historyczne dane sprzedażowe i prognozę popytu z Quantis. Prognozuje sprzedaż na poziomie pojedynczego SKU, wykorzystując silnik Quantis przebudowany o warstwę funkcji adaptacyjnych. Punktem wyjścia jest obserwacja, że żadna pojedyncza metoda prognostyczna nie sprawdza się jednakowo dobrze dla całego asortymentu — produkt sezonowy, produkt o stabilnym popycie i produkt nowo wprowadzony wymagają różnych modeli statystycznych. Moduł analizuje historyczny wzorzec sprzedaży każdego SKU (sezonowość, trend, zmienność, długość historii) i na tej podstawie dobiera metodę prognozy właściwą dla danego produktu, zamiast narzucać jeden model całemu katalogowi. Wynik prognozy — ilość sprzedaży per SKU per okres — zasila bezpośrednio STOCK: Weighted Average Cost Engine jako sales_qty, co oznacza, że jakość doboru metody prognostycznej przekłada się wprost na dokładność wyceny rozchodu zapasu.

Korzyści:

• Koniec z jedną metodą prognozy „na siłę" dla całego katalogu — produkt sezonowy i produkt stabilny liczone są inaczej, tak jak faktycznie się zachowują.
• Dokładniejsza prognoza sprzedaży to dokładniejsza wycena rozchodu zapasu i bardziej wiarygodny wynik finansowy okresu.
• Mniej czasu zespołu planistycznego na ręczne dobieranie modelu prognostycznego per produkt.

FORECAST: Pattern Classification

Warstwa adaptacyjna dobudowana nad silnikiem Quantis — klasyfikuje SKU do wzorców sprzedażowych na podstawie zachowania historycznego szeregu czasowego. Klasyfikacja decyduje, która metoda prognostyczna zostanie zastosowana w FORECAST: Adaptive Demand Engine dla danego produktu w danym okresie. Ponieważ wzorzec sprzedaży produktu może się zmieniać w czasie (np. produkt wychodzący z fazy wprowadzenia na rynek zmienia charakterystykę popytu), moduł nie przypisuje metody raz na stałe, tylko weryfikuje dopasowanie cyklicznie wraz z napływem nowych danych sprzedażowych.

Korzyści:

• Metoda prognozy nadąża za produktem, nawet gdy jego charakter sprzedaży zmienia się w czasie (np. produkt wychodzi z fazy wprowadzenia na rynek).
• Brak ryzyka, że raz dobrana metoda „zestarzeje się" niezauważona i zacznie cicho psuć jakość prognoz.

TEAM — kartoteka i koszt zatrudnienia

TEAM: Employee Master Registry

Centralna kartoteka pracowników i współpracowników — jeden wiersz na osobę, będący źródłem prawdy o tym, kto, na jakich warunkach i od kiedy jest związany z firmą. Obejmuje dane identyfikacyjne, stanowisko, dział, sieć/lokalizację (Retail Network), datę rozpoczęcia i zakończenia zatrudnienia, formę zatrudnienia (etat, kontrakt B2B i inne), status ubezpieczenia społecznego oraz stawkę składki pracodawcy do PPK. To ten sam rejestr, do którego odwołuje się WAREHOUSE: Wages & Payroll Contributions Allocation, budując klucz pracownika i przypisując go do dywizji przy alokacji kosztu na magazyny.

Korzyści:

• Jedno miejsce prawdy o zatrudnieniu — status, forma współpracy i przynależność organizacyjna nie rozjeżdżają się między działem kadr a modelem finansowym.
• Rozróżnienie formy zatrudnienia (etat vs. kontrakt) wprost w rejestrze pozwala inaczej traktować podatkowo i kosztowo różne typy współpracy bez ręcznych wyjątków w formułach.

TEAM: Remuneration Timeline

Śledzi historię wynagrodzenia każdej osoby, a nie tylko jego aktualną wartość. Oprócz stawki bazowej rejestruje do dwóch podwyżek wraz z datami ich wejścia w życie, walutę wynagrodzenia, stawkę VAT dla współpracowników rozliczających się na fakturze, prowizję, premię oraz źródło wypłaty. Dzięki dacie powiązanej z każdą zmianą stawki moduł pozwala odtworzyć, ile dana osoba zarabiała w dowolnym miesiącu przeszłości — nie tylko dziś — co jest warunkiem koniecznym poprawnego przeliczenia kosztu wynagrodzeń wstecz w WAREHOUSE: Wages & Payroll Contributions Allocation.

Korzyści:

• Pełna historia podwyżek per pracownik widoczna bez przeszukiwania archiwalnych list płac — podstawa do analizy polityki wynagrodzeń w czasie.
• Koszt wynagrodzeń w raportach historycznych jest dokładny dla każdego miesiąca z osobna, nie liczony wstecz po aktualnej stawce.
• Współpracownicy B2B rozliczani poprawnie względem VAT, bez ręcznego rozróżniania ich od etatowych w kalkulacji kosztu.

TEAM: Total Employment Cost (Benefits Basket)

Rozszerza koszt zatrudnienia poza samo wynagrodzenie o pełny koszyk świadczeń pozapłacowych przypisany indywidualnie do każdej osoby: sprzęt (laptop, telefon), koszt stanowiska biurowego, narzędzia SaaS, kartę sportową, budżet team-buildingowy, wsparcie wellness/zdrowia psychicznego, budżet szkoleniowy i certyfikacyjny, parking, pakiet relokacyjny, kartę komunikacji miejskiej, pakiet medyczny, wsparcie na opiekę nad dzieckmi, ubezpieczenie D&O oraz dodatkowe premie uznaniowe. Każda pozycja jest osobnym polem, więc koszt całkowity zatrudnienia (total cost of employment) danej osoby można rozbić na dokładnie te składniki, z których się realnie składa.

Korzyści:

• Prawdziwy, pełny koszt zatrudnienia — nie tylko pensja brutto — widoczny per osoba, dział i magazyn, bez pomijania „drobnych" świadczeń, które w sumie bywają istotną kwotą.
• Łatwo policzyć, ile firma faktycznie wydaje na benefity per pracownik i porównać to między działami czy lokalizacjami.
• Decyzje o standaryzacji lub cięciu konkretnego świadczenia (np. karty sportowej) można oprzeć na realnej sumie jego kosztu w całej organizacji, nie na wyczuciu.

TEAM: Termination Cost Modeling

Liczy ekspozycję kosztową związaną z zakończeniem zatrudnienia. Na podstawie okresu wypowiedzenia i stawki wynagrodzenia moduł pozwala oszacować koszt odejścia danej osoby lub grupy osób — z uwzględnieniem zaplanowanej daty zakończenia zatrudnienia tam, gdzie jest już znana. To bezpośrednie wsparcie decyzji restrukturyzacyjnych: redukcja zespołu w danym dziale lub magazynie ma od razu policzalny, a nie szacowany koszt.

Korzyści:

• Koszt ewentualnej redukcji zatrudnienia znany z góry, zanim decyzja zostanie podjęta — nie jako niespodzianka na liście płac.
• Planowanie restrukturyzacji zespołu (np. zamknięcie magazynu) można oprzeć na realnym koszcie okresów wypowiedzenia całej dotkniętej grupy.

TEAM: Vehicle & Asset Assignment

Przypisuje pracownika do konkretnego aktywa flotowego poprzez identyfikator EFAR. To bezpośrednie połączenie między kartoteką zespołu a EFAR: Asset Activity Profiles — koszt utrzymania danego pojazdu (paliwo, serwis, części) można prześledzić nie tylko do magazynu czy dywizji, ale do konkretnej osoby, której ten pojazd służy.

Korzyści:

• Koszt floty rozliczalny na poziomie „kto z niej korzysta", nie tylko „ile kosztuje flota jako całość".
• Łatwiej ocenić zasadność przypisania konkretnego pojazdu do konkretnego stanowiska, patrząc na jego rzeczywisty koszt utrzymania.

CONTROL — sterowanie oknem aktywności kosztów

OpEx: Activation Window Gate

Warstwa kontrolna nadrzędna nad modułami kosztowymi systemu Metis. Zanim jakikolwiek moduł policzy koszt dla danego okresu, sprawdza w rejestrze OpEx przypisaną mu bramkę aktywacji — datę początkową i końcową, w których dany koszt w ogóle może wystąpić. To pojedynczy, współdzielony mechanizm obsługujący jednocześnie kilka różnych zjawisk biznesowych: kampanię aktywną tylko w określonym przedziale czasu, koszt cykliczny występujący w konkretnych powtarzalnych oknach, oraz koszt sezonowy ograniczony do części roku. Zamiast każdy moduł kosztowy budował własną logikę „czy w tym miesiącu w ogóle powinienem coś policzyć", odpytuje jedną wspólną bramkę w OpEx — co oznacza, że zmiana okresu aktywności danego kosztu (np. przesunięcie kampanii, wygaszenie kontraktu) jest jedną zmianą w jednym miejscu, widoczną natychmiast we wszystkich modułach, które z tego kosztu korzystają.

Korzyści:

• Włączanie i wyłączanie kosztów w czasie (kampanie, kontrakty sezonowe, umowy terminowe) sterowane z jednego miejsca, bez modyfikowania formuł w modułach docelowych.
• Ten sam mechanizm obsługuje trzy różne z natury zjawiska — ograniczenie czasowe, cykliczność i sezonowość — bez potrzeby osobnej logiki dla każdego z nich.
• Błąd „koszt naliczył się w miesiącu, w którym nie powinien" jest do zdiagnozowania w jednym miejscu (bramka w OpEx), a nie w każdym module z osobna.

TRAFFIC — koszty pozyskania ruchu (WebTraffic)

TRAFFIC: Prospecting Cost Engine

Liczy koszt pozyskania nowego ruchu dla danej kampanii w danym miesiącu — iloczyn liczby odwiedzin (traffic) i kosztu za kliknięcie (CPC), każdy z osobną, roczną korektą procentową (np. wzrost stawek CPC rok do roku). Kampania ma zdefiniowany zamknięty przedział aktywności (data startu i końca), poza którym koszt nie jest naliczany. Korekta roczna pozwala modelować zmianę cen ruchu (aukcje reklamowe, inflację CPC) bez ręcznej rewizji bazowej tabeli miesięcznej — wystarczy jeden współczynnik na rok.

Korzyści:

• Prognoza kosztu pozyskania ruchu na kilka lat do przodu bez ręcznego wypełniania osobnej tabeli miesięcznej dla każdego roku — wystarczy jeden wskaźnik korekty rocznej.
• Zmiana strategii cenowej platformy reklamowej (wzrost CPC) modelowana jednym parametrem, natychmiast widoczna w prognozie kosztów marketingu.
• Kampanie o ograniczonym czasie trwania (np. sezonowa promocja) automatycznie przestają generować koszt po dacie zakończenia, bez ręcznego wygaszania.

TRAFFIC: Remarketing Pool Engine

Liczy koszt remarketingu — czyli ponownego dotarcia do osób, które odwiedziły stronę w niedawnej przeszłości, ale jeszcze nie skonwertowały. Mechanizm buduje „pulę" potencjalnych odbiorców remarketingu jako sumę ruchu z ostatnich N miesięcy wstecz (N wynika z okresu retencji kampanii, przeliczonego z dni na miesiące), gdzie ruch z każdego historycznego miesiąca korygowany jest właściwym dla siebie współczynnikiem rocznym — nie współczynnikiem bieżącego okresu. Z tej puli tylko część (Match Rate) jest realnie dopasowywalna do odbiorcy (ograniczenia platform reklamowych w dopasowaniu użytkowników), a koszt dotarcia do dopasowanej części liczony jest osobną stawką CPC remarketingowego, również korygowaną rocznie.

Korzyści:

• Koszt remarketingu rośnie i maleje naturalnie wraz z wielkością ruchu z poprzednich miesięcy, zamiast być stałą, oderwaną od rzeczywistości kwotą budżetową.
• Różne kampanie mogą mieć różny okres retencji (jak długo odwiedzający pozostaje „w puli" remarketingowej) i różny Match Rate, odzwierciedlając rzeczywiste różnice między platformami i grupami odbiorców.
• Poprawne naliczanie korekty rocznej per miesiąc historyczny (nie per miesiąc bieżący) zapobiega zniekształceniu kosztu przy kampaniach rozciągniętych na kilka lat.

WAREHOUSE — alokacja kosztów magazynu

WAREHOUSE: Allocation Keys

Centralny rejestr kluczy alokacji dla całej sieci magazynów. Dla każdego magazynu definiuje, jakie dywizje pracownicze i jakie pozycje kosztowe (CapEx, OpEx, zobowiązania finansowe) są do niego przypisane oraz jaki procent danej pozycji lub danej dywizji na niego przypada. Jedna dywizja lub jedna pozycja kosztowa może być przypisana do wielu magazynów jednocześnie z różnym procentem dla każdego — odzwierciedlając rzeczywistość operacyjną, w której zespół lub kontrakt leasingowy obsługuje więcej niż jedną lokalizację. Wszystkie pozostałe moduły WAREHOUSE odczytują z tego rejestru swój klucz alokacji.

Korzyści:

• Jedno miejsce do zarządzania kluczami alokacji dla całej sieci magazynów — zmiana procentu w jednym miejscu aktualizuje wszystkie powiązane raporty.
• Odzwierciedla rzeczywistość operacyjną, w której jeden zespół czy jeden kontrakt obsługuje kilka lokalizacji naraz, zamiast sztucznie przypisywać koszt do jednego magazynu.

WAREHOUSE: Wages & Payroll Contributions Allocation

Liczy pełny koszt osobowy przypisany do magazynu. Dla każdego pracownika buduje unikalny klucz (imię, nazwisko, data zatrudnienia) na podstawie TEAM: Employee Master Registry i dopasowuje go do siedmiu niezależnych rejestrów płacowych: wynagrodzenie zasadnicze (zgodne z historią stawek z TEAM: Remuneration Timeline), ubezpieczenie wypadkowe, ubezpieczenie rentowe, ubezpieczenie emerytalne, Fundusz Pracy, FGSP i PPK. Wartości wszystkich pracowników należących do danej dywizji sumowane są jednocześnie (mnożenie macierzowe zamiast pętli po pracownikach), a suma dywizji mnożona jest przez procent alokacji z WAREHOUSE: Allocation Keys. W przeciwieństwie do pozostałych modułów WAREHOUSE, klucz alokacji działa tu na poziomie struktury organizacyjnej (dywizja), nie pojedynczej pozycji kosztowej — koszt osobowy z natury nie daje się przypisać pozycja po pozycji.

Korzyści:

• Pełny koszt zatrudnienia (nie tylko pensja, ale też składki i fundusze) trafia do właściwego magazynu automatycznie, bez ręcznego liczenia „kto ile czasu spędza gdzie".
• Rachunek kosztów magazynu przestaje pomijać największy zwykle pojedynczy koszt operacyjny — pracę ludzi.
• Zmiana składu zespołu (nowe zatrudnienie, odejście) od razu przekłada się na zaktualizowany koszt magazynu, bez osobnej aktualizacji raportu.

WAREHOUSE: CapEx Allocation

Rozdziela na magazyn udział w kosztach kapitałowych rozliczanych centralnie — flota, sprzęt, infrastruktura inwestycyjna. Dla każdej pozycji przypisanej do magazynu moduł przeszukuje pięć niezależnych rejestrów źródłowych (paliwo, serwis, części zamienne, energia, dane gotówkowe CapEx), zakładając że dana pozycja występuje w dokładnie jednym z nich. Znalezioną wartość mnoży przez procent alokacji z WAREHOUSE: Allocation Keys. To najbardziej pośredni z czterech typów kosztu magazynu — pozycja CapEx nie jest generowana przez magazyn bezpośrednio, tylko rozliczana na niego z puli wspólnej. Cztery z pięciu przeszukiwanych rejestrów (paliwo, serwis, części zamienne, energia) oraz dane gotówkowe CapEx pochodzą z EFAR — modułu opisanego niżej, który liczy te koszty u źródła, na poziomie pojedynczego aktywa.

Korzyści:

• Koszty inwestycyjne firmy przestają być „niewidzialne" dla poszczególnych magazynów — każdy widzi swój realny udział.
• Automatyczne przeszukanie pięciu rejestrów źródłowych eliminuje ręczne szukanie, w którym systemie zaksięgowano daną pozycję.
• Podstawa do świadomych decyzji o inwestycjach we flotę czy infrastrukturę per lokalizacja, a nie na poziomie całej firmy.

WAREHOUSE: OpEx Allocation

Rozdziela koszty operacyjne bieżące — jedyny typ kosztu w module WAREHOUSE pobierany z pojedynczego, dedykowanego rejestru zamiast przeszukiwania wielu źródeł. Odzwierciedla to charakter OpEx jako kosztu bardziej bezpośrednio związanego z danym magazynem niż CapEx czy zobowiązania finansowe. Mechanizm dopasowania pozycji i mnożenia przez procent alokacji jest identyczny jak w pozostałych modułach kosztowych.

Korzyści:

• Koszty bieżące magazynu widoczne osobno od kosztów wspólnych firmy — łatwo ocenić, co magazyn faktycznie generuje sam z siebie.
• Prosta, przewidywalna struktura danych ułatwia szybkie zamknięcie miesiąca bez ręcznego uzgadniania pozycji.

WAREHOUSE: Financial Liabilities Allocation

Rozdziela na magazyn udział w obsłudze zadłużenia zaciąganego centralnie — raty leasingu, odsetki od kredytów inwestycyjnych. Struktura identyczna z WAREHOUSE: OpEx Allocation: jeden rejestr źródłowy, dopasowanie pozycji i miesiąca, mnożenie przez procent alokacji. Razem z CapEx stanowi drugi typ kosztu pośredniego w macierzy magazynu — koszt generowany przez decyzje finansowe firmy, nie przez bieżącą działalność samego magazynu.

Korzyści:

• Koszt finansowania widoczny per magazyn, a nie tylko jako jedna zbiorcza pozycja w bilansie całej firmy.
• Jasność, ile z rentowności magazynu „zjada" obsługa zadłużenia zaciągniętego na poziomie centrali.

WAREHOUSE: Cost Matrix Output

Składa wyniki wszystkich czterech modułów kosztowych (Wages, CapEx, OpEx, Financial Liabilities) w jedną tabelę: pozycja lub dywizja kosztowa × kategoria × procent alokacji × wartość w każdym miesiącu okresu raportowego. To wynikowy dokument dla danego magazynu — bezpośredni wsad do rachunku wyników per lokalizacja, pozwalający rozróżnić koszty bezpośrednie (OpEx) od pośrednich (Wages, CapEx, Financial Liabilities) na pierwszy rzut oka.

Korzyści:

• Jedna tabela zamiast czterech osobnych raportów — zarząd widzi pełny koszt magazynu bez ręcznego zestawiania danych z różnych źródeł.
• Gotowa, spójna podstawa kosztowa do porównania magazynów między sobą — ten sam sposób liczenia dla każdej lokalizacji.
• Rozróżnienie kosztów stałych (pośrednich) i zmiennych (bezpośrednich) ułatwia decyzje o skalowaniu sieci magazynowej.

EFAR — koszty aktywów w rozbiciu na aktywność

EFAR: Asset Activity Profiles

Liczy koszty utrzymania majątku firmy (flota, maszyny, wyposażenie) na poziomie pojedynczego aktywa, a nie zbiorczej puli kosztowej. Każde aktywo ma własny profil zużycia — paliwo lub energię, koszty serwisowe, części zamienne — rozbity miesiąc po miesiącu, niezależnie od tego, do którego magazynu lub której dywizji zostanie ostatecznie zaalokowane. To podejście oparte na aktywności (activity-based) odpowiada na te same ograniczenia, które w klasycznym budżetowaniu prowadzą do rozmycia kosztu: zamiast jednej sumy „koszty floty" na cały miesiąc, EFAR wie, ile konkretnie kosztowało konkretne aktywo w konkretnym miesiącu i z jakiego tytułu. Wynik zasila WAREHOUSE: CapEx Allocation jako jedno z pięciu przeszukiwanych źródeł — pozycja kosztowa z tabeli alokacji dopasowywana jest do profilu aktywa, którego dotyczy.

Korzyści:

• Koniec z jedną zbiorczą sumą „koszty floty" — wiadomo dokładnie, które aktywo generuje jaki koszt i z jakiego tytułu.
• Łatwiej zidentyfikować aktywa, które przestały się opłacać (np. rosnące koszty serwisowe starzejącego się pojazdu).
• Podstawa do świadomych decyzji o wymianie sprzętu, opartych na realnych, a nie szacowanych kosztach utrzymania.

EFAR: CapEx Cash Data

Prowadzi ewidencję przepływów gotówkowych związanych z inwestycjami kapitałowymi — nabyciem aktywów, ratami, wkładem własnym — oddzielnie od kosztów bieżącego utrzymania liczonych w EFAR: Asset Activity Profiles. Rozróżnienie to ma znaczenie księgowe i płynnościowe: wydatek inwestycyjny wpływa na cash flow w innym rytmie niż koszt operacyjny utrzymania tego samego aktywa. Dane z tego modułu są jednym z pięciu rejestrów źródłowych odpytywanych przez WAREHOUSE: CapEx Allocation.

Korzyści:

• Wydatek inwestycyjny nie miesza się z kosztem bieżącego utrzymania tego samego aktywa — płynność i rentowność liczone poprawnie, osobno.
• Jasny obraz zobowiązań gotówkowych wynikających z inwestycji, przydatny przy planowaniu cash flow firmy.

ECON — trendy ekonomiczne

ECON: Currency & Rate Trends

Centralna, aktualizowana tabela kursów walutowych (EUR/PLN, USD/PLN, GBP/PLN, CNY/PLN) w układzie miesięcznym, będąca jedynym źródłem kursu dla całego systemu Metis. Każdy moduł przeliczający wartości obcowalutowe — STOCK: Purchase Order Costing, STOCK: Customs & NBP Rate, EFAR: Asset Activity Profiles — odpytuje ten sam rejestr, dobierając kurs wg miesiąca właściwego zdarzenia (płatności, transportu, zakupu aktywa), a nie wg jednej daty odniesienia dla całej transakcji. Ta jedność źródła kursu eliminuje ryzyko, że dwa moduły policzą tę samą transakcję walutową po różnych kursach.

Korzyści:

• Jedno źródło prawdy dla kursów walut w całym modelu — zero ryzyka, że dwa raporty pokażą inną wartość tej samej transakcji.
• Aktualizacja tabeli kursów raz w miesiącu wystarcza, żeby cały system przeliczył się poprawnie, bez ręcznego wchodzenia w każdy arkusz.

ECON: Financial Cost Indices

Tabela stóp procentowych i wskaźników kosztu finansowania (np. WIBOR, marże kredytowe, warunki leasingowe) w układzie miesięcznym, analogicznym do tabeli kursów walut. Stanowi źródło danych dla WAREHOUSE: Financial Liabilities Allocation — koszt obsługi zadłużenia magazynu nie jest wartością stałą wpisaną raz, tylko przeliczany na bieżąco wg aktualnej lub prognozowanej stopy z tego rejestru.

Korzyści:

• Koszt finansowania magazynu odzwierciedla rzeczywiste, aktualne warunki rynkowe, a nie założenie sprzed roku wpisane raz do budżetu.
• Zmiana stopy procentowej widoczna w wyniku magazynu od razu, bez czekania na ręczną rewizję modelu.

ECON: Fuel & Electricity Price Trends

Tabela cen paliwa i energii elektrycznej w układzie miesięcznym, zasilająca EFAR: Asset Activity Profiles oraz — dla magazynów o podwyższonym zużyciu energii, np. magazynów chłodzonych — bezpośrednio koszt operacyjny magazynu w WAREHOUSE: OpEx Allocation. Metis jest modelem uniwersalnym: nie zakłada jednolitego profilu zużycia energii dla całej sieci, tylko pozwala każdemu magazynowi mieć własny, faktyczny udział kosztu energetycznego, zależny od jego charakterystyki operacyjnej (np. chłodnia zużywa nieporównanie więcej energii niż magazyn suchy tej samej wielkości).

Korzyści:

• Magazyny chłodzone i inne lokalizacje energochłonne mają swój rzeczywisty koszt energii odzwierciedlony w wyniku, zamiast uśrednionej stawki dla całej sieci.
• Wzrost cen paliwa czy energii widoczny w kosztach magazynu i floty automatycznie, bez ręcznej rewizji budżetu po każdej podwyżce.

ECON: Forward-Looking Sensitivity

Rejestry ECON przechowują nie tylko wartości bieżące, ale też planowane zmiany na przyszłe okresy — podwyżkę stopy procentowej, wzrost ceny energii, zmianę kursu walutowego. Ponieważ każdy moduł kosztowy odpytuje ECON per okres, a nie per jedna stała wartość, zaplanowana zmiana w dowolnym rejestrze automatycznie propaguje się przez cały łańcuch obliczeniowy w miesiącu, którego dotyczy — bez ręcznej aktualizacji formuł w modułach kosztowych. Ta sama logika stosowana jest po stronie przychodowej: FORECAST: Adaptive Demand Engine śledzi zarówno bieżące, jak i planowane ceny sprzedaży produktów, tym samym mechanizmem co ECON śledzi ceny kosztowe. Efektem jest natychmiastowa widoczność wpływu dowolnej zaplanowanej zmiany — kosztowej lub przychodowej — na marżę kontrybucyjną (contribution margin) produktu i magazynu w okresie, w którym zmiana zacznie obowiązywać, zanim jeszcze faktycznie nastąpi.

Korzyści:

• Zarząd widzi wpływ zaplanowanej podwyżki cen energii, stóp procentowych czy kursu waluty na marżę, zanim ta podwyżka faktycznie wejdzie w życie.
• Decyzje cenowe i kosztowe podejmowane z wyprzedzeniem, na podstawie liczb, a nie przeczucia.
• Jeden mechanizm obsługuje zarówno stronę kosztową, jak i przychodową — scenariusze „co jeśli" liczone spójnie w całym modelu.