Ewidencja palet w Excelu - granica opłacalności arkusza

Ewidencja palet w Excelu - co arkusz obsłuży bez problemu

Arkusz kalkulacyjny jest najczęstszym pierwszym narzędziem do rozliczania nośników. Nie wymaga osobnej licencji, nie potrzebuje wdrożenia i pozwala zbudować kartotekę w jedno popołudnie. Ewidencja palet w Excelu ma więc uzasadnienie tak długo, jak długo skala pracy mieści się w możliwościach pliku, a ten warunek da się zmierzyć zamiast go zgadywać.

Pojedynczy skoroszyt dobrze znosi kilku kontrahentów i kilkadziesiąt operacji miesięcznie, o ile dane wprowadza jedna osoba. W takim układzie nie ma konfliktów edycji, historia zmian nie jest potrzebna nikomu poza autorem, a uzgodnienie salda sprowadza się do jednego filtra. Limit techniczny samego programu leży daleko, bo arkusz Excela mieści 1 048 576 wierszy. Problemem nie jest więc pojemność, tylko organizacja pracy wokół pliku.

Struktura pliku, którą da się zaimportować

Arkusz prowadzony z myślą o przyszłej zmianie narzędzia trzyma jedną operację w jednym wierszu. Każda kolumna ma stały sens i stały format, a nazwy kontrahentów pochodzą ze słownika, bo dwa zapisy tej samej firmy rozbijają saldo na dwie pozycje.

• Data operacji - jeden format zapisu w całej kolumnie, bez dat wpisywanych jako tekst.
• Kontrahent - wartość wybierana z listy, nigdy wpisywana ręcznie.
• Typ nośnika i ilość - rodzaj palety w osobnej kolumnie od liczby sztuk.
• Numer dokumentu - identyfikator kwitu lub dokumentu magazynowego, do którego da się wrócić.

Saldo kontrahenta liczy wtedy jedna formuła, która sumuje wydania i odejmuje przyjęcia dla wskazanej nazwy. W polskich ustawieniach regionalnych argumenty rozdziela średnik.

=SUMIFS(Ruch!D:D; Ruch!B:B; A2; Ruch!C:C; "W") - SUMIFS(Ruch!D:D; Ruch!B:B; A2; Ruch!C:C; "P")

Formuła jest czytelna, ale każda zmiana słownika typów nośników wymaga poprawienia zakresów we wszystkich zestawieniach. Tam, gdzie zestawień jest kilka, a plik trafia do kilku osób, taka poprawka prędzej czy później zostaje pominięta.

Progi opłacalności arkusza

Zmiana narzędzia bywa odkładana, bo arkusz nie zawodzi nagle. Traci użyteczność stopniowo, a koszt tej straty rozkłada się na godziny pracy i spory, których nikt nie sumuje. Trzy progi pozwalają ocenić moment przejścia na podstawie liczb.

Liczba kontrahentów i liczba sald

Liczba sald do pilnowania to iloczyn liczby kontrahentów i liczby rodzajów nośników. Dziesięciu kontrahentów i trzy rodzaje nośników dają trzydzieści pozycji, z których każda wymaga osobnego uzgodnienia. Przy kilku kontrahentach osoba prowadząca ewidencję pamięta stan rozliczeń. Przy kilkudziesięciu uzgodnienia stają się cykliczną pracą, w której każda korekta wymaga ponownego zestawienia i wysyłki.

Częstość operacji i liczba osób w pliku

Drugi próg dotyczy pracy zmianowej. Gdy dane wprowadza kilka osób na różnych stanowiskach, pojawiają się kopie pliku z dopiskami w nazwie i rozbieżne wersje tej samej ewidencji. Współedycja w chmurze ogranicza ten problem, ale nie usuwa go całkowicie: arkusz nie ma kluczy obcych, nie odrzuci wiersza z nieistniejącym kontrahentem i nie zablokuje ujemnej ilości.

Tabela w bazie danych egzekwuje takie reguły na poziomie struktury. Klucze główne i obce w SQL Server odrzucają błędny zapis w chwili wprowadzania, a nie w chwili, gdy ktoś zauważy różnicę w saldzie.

Potwierdzenia sald i wartość dowodowa

Trzeci próg ma charakter dowodowy. Kontrahent potwierdza saldo na określony dzień, a firma musi wykazać, z jakich operacji ono wynika. Arkusz nie rejestruje, kto i kiedy zmienił wartość w komórce, więc przy sporze dokument ma ograniczoną wartość jako podstawa roszczenia. Metody uzgadniania i typowe źródła rozbieżności opisuje artykuł o rozliczaniu palet z kontrahentami.

Reguła: jeden przekroczony próg wymaga obserwacji, dwa przekroczone progi uzasadniają wdrożenie systemu.

Porównanie arkusza i systemu paletowego

Zestawienie obejmuje kryteria, które decydują o wiarygodności danych, a nie o wygodzie obsługi. Kolumna z systemem opisuje mechanizmy, jakie zapewnia baza relacyjna pod ewidencją, na przykładzie modułu Studio PWS.net z zakresem funkcji opisanym w tym serwisie.

Co system dodaje do ewidencji

Studio PWS.net rejestruje ruch palet między kontrahentami i magazynami, prowadzi konta paletowe kontrahentów i generuje kwity paletowe. Sposób prowadzenia sald w programie opisuje materiał o ewidencji palet w systemie PWS.net, a zasady pracy z dokumentem potwierdzającym wydanie i przyjęcie - artykuł o kwitach paletowych.

• Automatyzacja przyjęć i wydań - system generuje dokumenty i aktualizuje stan palet, bez ręcznego przepisywania.
• Stan techniczny palety - sprawna lub uszkodzona, z historią zmian i lokalizacją w magazynie.
• Integracja z WMS - dane paletowe łączą się z dokumentami magazynowymi, więc ruch nośnika powstaje razem z dostawą.
• Zestawienia sald - saldo kontrahenta oraz koszty użytkowania dostępne bez ręcznej analizy pliku.

Rejestr zdarzeń zamiast tabeli stanów

Największa różnica między arkuszem a systemem nie leży w wyglądzie ekranu. Arkusz zwykle pokazuje stan bieżący, a historia jest w nim opcjonalna. System zapisuje zdarzenia, a stan wylicza z ich sumy, więc saldo na dowolny dzień wstecz jest zwykłym zapytaniem.

Przykład schematu w T-SQL

Poniższy szkic pokazuje zasadę na przykładowej tabeli, która nie jest schematem żadnego produktu. Ograniczenia CHECK odrzucają kierunek spoza zbioru i ilość niedodatnią, a saldo powstaje z jednego zapytania z filtrem daty.

CREATE TABLE dbo.RuchPalet (
    RuchId       int IDENTITY(1,1) PRIMARY KEY,
    KontrahentId int          NOT NULL,
    TypNosnika   varchar(10)  NOT NULL,
    Kierunek     char(1)      NOT NULL CHECK (Kierunek IN ('W', 'P')),
    Ilosc        int          NOT NULL CHECK (Ilosc > 0),
    DataRuchu    datetime2(0) NOT NULL,
    DokumentNr   varchar(40)  NOT NULL,
    Operator     varchar(50)  NOT NULL
);

DECLARE @NaDzien datetime2(0) = '2026-06-30T23:59:59';

SELECT KontrahentId, TypNosnika,
       SUM(CASE Kierunek WHEN 'W' THEN Ilosc ELSE -Ilosc END) AS Saldo
FROM dbo.RuchPalet
WHERE DataRuchu <= @NaDzien
GROUP BY KontrahentId, TypNosnika;

Ten sam wynik w arkuszu wymaga osobnej kopii skoroszytu z każdego dnia rozliczeniowego. Dla tabel zmieniających wartości w czasie SQL Server oferuje dodatkowo mechanizm opisany w dokumentacji jako tabele temporalne, który zachowuje poprzednie wersje wiersza bez dodatkowego kodu w aplikacji.

Analiza przyczyn ubytków

Rejestr zdarzeń pozwala pytać o przyczyny, a nie tylko o wartości. Jeżeli różnice koncentrują się u jednego przewoźnika, na jednej zmianie albo przy jednym rodzaju nośnika, wniosek nasuwa się z grupowania. Z arkusza pokazującego wyłącznie stan bieżący takiej informacji nie da się wyprowadzić. Zasady rejestrowania przyjęcia razem z dostawą opisuje artykuł o awizo dostawy palet.

Rachunek kosztów jako wzór

Poniższy rachunek nie zawiera cen ani stawek, ponieważ zależą od firmy i od oferty dostawcy. Każdy symbol ma odpowiednik w danych, które firma już ma: w ewidencji czasu pracy i w księgowości.

Koszt utrzymania arkusza

Koszt roczny arkusza składa się z pracy ludzi i wartości utraconych nośników, a do tego dochodzą spory o salda. Pierwszy składnik to 52 tygodnie pomnożone przez h i s. Drugi to iloczyn u i N, pomnożony przez c. Trzeci, Sp, trzeba oszacować, a jego pominięcie prawie zawsze zaniża wynik, bo czas kierownictwa na rozstrzyganie różnic nikt nie księguje osobno.

Koszt systemu i warunek zmiany

Po stronie systemu koszt roczny to opłata L i część kosztu wdrożenia rozłożona na okres T. Pracy i strat nie zakłada się jako zerowych, bo ewidencja nadal wymaga obsługi, tylko krótszej i mniej podatnej na błąd. Zmiana ma sens, gdy spełniony jest warunek podany poniżej.

K_arkusz = 52 * h * s + u * N * c + Sp
K_system = L + W / T + 52 * h' * s + u' * N * c

zmiana opłacalna, gdy K_arkusz > K_system, czyli
52 * (h - h') * s + (u - u') * N * c + Sp > L + W / T

Reguła: u' i h' wpisuje się ostrożnie, na podstawie testu na części kontrahentów, a nie na podstawie obietnic z oferty.

Cykl uzgadniania sald w arkuszu i w systemie

Koszt ewidencji najlepiej widać w cyklu uzgodnień, bo to on zamienia jednorazową operację w powtarzalną pracę. Każdy okres rozliczeniowy powtarza ten sam ciąg czynności, a różnica między narzędziami polega na tym, ile z nich wykonuje człowiek.

Uzgodnienie w arkuszu

W arkuszu osoba prowadząca ewidencję filtruje wiersze dla kontrahenta i kopiuje wynik do osobnego pliku. Po dopisaniu salda wysyła zestawienie. Odpowiedź kontrahenta trafia do skrzynki pocztowej, a rozbieżność wymaga porównania dwóch list wiersz po wierszu. Przy jednym kontrahencie zajmuje to kilkanaście minut. Przy trzydziestu pozycjach salda ta sama procedura zajmuje dzień roboczy, a każda kolejna korekta cofa proces do początku.

Uzgodnienie w systemie

W systemie zestawienie salda na wskazany dzień jest raportem z parametrem, a rozbieżność sprowadza się do listy dokumentów, które kontrahent zna, a firma nie ma, albo odwrotnie. Zestawienie można wygenerować dla wszystkich kontrahentów jednocześnie i porównać po numerach kwitów. Sprawdzone porównanie kończy się wpisem korekty z datą i autorem, a nie zmianą wartości w komórce.

Zasady prowadzenia rozliczeń i częste źródła sporów opisuje artykuł o rozliczaniu palet w systemie paletowym. Im więcej kontrahentów, tym większa część pracy przypada na obsługę wyjątków, a nie na samo liczenie, i tu różnica między narzędziami jest największa.

Przejście z arkusza do systemu

Przejście nie musi być jednorazowe, a jego koszt zależy głównie od jakości danych wyjściowych. Arkusz prowadzony według opisanych wyżej zasad importuje się w kilka godzin, a plik prowadzony swobodnie trzeba wcześniej uporządkować. Podobny problem migracji z arkusza do modułu magazynowego opisuje artykuł o programie do magazynu i migracji z Excela.

Saldo startowe i uzgodnienie

Do systemu wprowadza się saldo otwarcia na ustalony dzień, a nie całą historię z arkusza. Warunkiem jest uzgodnienie tego salda z kontrahentami przed startem, bo od tej chwili system jest źródłem prawdy, a każda różnica wraca jako spór o dane, których nikt już nie potrafi odtworzyć. Kolejność dokumentów w łańcuchu dostaw opisuje artykuł o rozliczaniu poolingu i dokumentach palet.

Etapowe uruchomienie

Uruchomienie dla najważniejszych kontrahentów przy pozostawieniu arkusza dla pozostałych pozwala sprawdzić rozwiązanie na ograniczonej skali. Warunkiem jest data zakończenia okresu przejściowego, bo równoległe prowadzenie dwóch ewidencji na stałe jest gorsze od każdego z rozwiązań osobno. Zakres modułu i przykłady sald kontrahentów opisuje strona salda palet w programie PWS, a ogólny obraz rozwiązania - opis aplikacji Studio PWS.net.

Kontrola po uruchomieniu

Przez pierwsze okresy rozliczeniowe warto porównywać salda z systemu z ostatnią wersją arkusza. Różnica wskazuje albo błąd importu, albo operację, której arkusz nigdy nie zarejestrował. Wnioski z takiego porównania nadają się do uzupełnienia założeń w rachunku kosztów, a zasady oceny nośników i innych procesów w gospodarce paletowej porządkuje artykuł o gospodarce paletowej w systemach informatycznych. Miejsce ewidencji palet w układzie WMS opisuje artykuł o palecie w systemie magazynowym.