Commerce Weavers bierze na siebie budowę modułu finansowego Open Mercato. Pierwsza iteracja obejmuje plan kont i księgę główną. To od nich zaczynamy, ponieważ kolejne obszary księgowości potrzebują wspólnego miejsca zapisu danych finansowych. W tym artykule wyjaśniamy, dlaczego wybraliśmy taką kolejność, jak nowy fundament ma współpracować z istniejącymi modułami i co znajduje się w dalszym zakresie prac. To pierwsza część cyklu o module finansowym Open Mercato – w kolejnych będziemy opisywać postępy prac nad następnymi obszarami.
Open Mercato zapisuje zdarzenia zachodzące w firmie, takie jak sprzedaż, wystawienie faktury, wysyłka czy przyjęcie towaru do magazynu. Nie ma jednak jeszcze wspólnego miejsca, w którym można ująć ich skutki finansowe w księgach rachunkowych.
Dziś zespoły wdrażające Open Mercato rozwiązują kwestię księgowości we własnym zakresie. Budują potrzebne funkcje albo przechowują dane w osobnym systemie księgowym i integrują ze sobą oba rozwiązania. Takie wdrożenia już istnieją i działają. Tworząc wspólny moduł finansowy w open-source'owym rdzeniu Open Mercato, chcemy sprawić, by kolejni użytkownicy nie musieli za każdym razem projektować tego samego fundamentu.
To odpowiada założeniu, na którym opiera się Open Mercato: platforma dostarcza około 80% funkcjonalności wspólnych dla firm, a pozostałe 20% można dobudować pod potrzeby konkretnej organizacji. Proporcje te opisują podejście do rozwoju, a nie stały zakres każdego wdrożenia. Księgowość należy do potrzeb wspólnych, dlatego dokładamy jej podstawy do części rozwijanej na poziomie Open Mercato.
Zastanawiasz się nad wdrożeniem Open Mercato? Sprawdź, jak możemy pomóc → wdrożenie Open Mercato: dedykowany CRM i ERP bez licencji per użytkownik.
Pierwsza iteracja modułu finansowego Open Mercato obejmuje dwa elementy: plan kont i księgę główną. To na nich mają opierać się kolejne funkcje księgowe.
Plan kont to uporządkowana, ponumerowana lista, na której ujmuje się wszystkie operacje gospodarcze firmy. Ma ona strukturę hierarchiczną: od ogólnych kont syntetycznych (np. „Środki pieniężne w drodze”), po uszczegóławiające je konta analityczne (np. subkonta dla poszczególnych bramek płatności, takich jak Stripe czy Tpay).
Firma zwykle zaczyna od standardowego planu kont i dostosowuje go do swojej działalności. Struktura określa również sposób grupowania danych w raportach finansowych. Domyślny plan kont utworzony we współpracy z incro także będzie częścią naszej kontrybucji.
Księga główna to centralny rejestr wszystkich zapisów księgowych. Jej fundamentem jest zasada podwójnego zapisu – każda operacja musi się bilansować, co oznacza, że suma kwot po jednej stronie (Winien) zawsze równa się sumie po drugiej (Ma), nawet jeśli pojedynczy zapis obejmuje wiele różnych kont.
W świecie finansów obowiązuje też żelazna zasada niezmienności (dla programistów: to klasyczna baza typu append-only). Raz zaksięgowanej operacji nie można po prostu nadpisać czy usunąć. Aby zachować pełen ślad rewizyjny, błędy koryguje się osobnym wpisem i właśnie dlatego w backlogu modułu finansowego Open Mercato przewidzieliśmy obsługę tzw. storna, czyli systemowego mechanizmu do wprowadzania takich korekt.
Za tą kolejnością stoją trzy powody. Pierwszy dotyczy wspólnego sposobu zapisywania danych finansowych. Drugi wynika z funkcji, które Open Mercato już ma. Trzeci wiąże się z polskim modułem, który trzeba uwzględnić podczas projektowania nowego fundamentu.
Faktury sprzedaży i zakupu, wyciągi bankowe, amortyzacja, rozliczanie przychodu w czasie czy naliczenia podatkowe wiążą się z operacjami, które trzeba ująć w księgach. Księga główna jest wspólnym miejscem dla zapisów finansowych pochodzących z różnych obszarów.
Gdybyśmy budowali kolejne funkcje przed księgą główną, każda musiałaby rozwiązać kwestię zapisu danych finansowych we własnym zakresie. Później trzeba byłoby połączyć te rozwiązania. Dlatego zaczynamy od fundamentu, na którym będzie można oprzeć dalsze prace.
Nie oznacza to, że od razu powstaną połączenia ze wszystkimi procesami biznesowymi. Zakres zaplanowanych funkcji i integracji wyznacza obecny backlog.
Open Mercato obsługuje już wystawianie faktur sprzedaży i zaawansowane zarządzanie stanami magazynowymi. Nie musimy budować tych funkcji ponownie. Potrzebujemy natomiast wspólnej księgi, do której będzie można kierować zapisy księgowe będące konsekwencją tych operacji.
Księgowanie faktur sprzedaży jest zaplanowane jako osobny obszar backlogu. Wystawianie faktury już działa, ale jej ujęcie na odpowiednich kontach jest dopiero przed nami.
Inaczej wygląda sytuacja z dokumentami magazynowymi. Choć Open Mercato świetnie radzi sobie z procesami magazynowymi, ich automatyczne księgowanie nie znajduje się w naszym obecnym backlogu dla modułu finansowego. Jeśli jednak komuś zależy na tej integracji już teraz – gorąco zapraszamy do kontaktu i współtworzenia tego obszaru.
Open Mercato posiada już działający moduł polskich finansów, choć obecnie funkcjonuje on niezależnie od powstającej księgi głównej. Z powodzeniem wysyła faktury do KSeF, odbiera faktury zakupowe oraz generuje i składa JPK. Nie potrzebuje nowego modułu finansowego, by realizować te zadania.
Ponieważ w platformie nie ma jeszcze dedykowanego modułu zakupów, polski moduł przechowuje własną ewidencję zakupów. W kodzie to on jest tymczasowym źródłem prawdy dla tego obszaru – to świadome rozwiązanie, pozwalające obsłużyć istniejące procesy.
Powstanie księgi głównej oznacza jednak konieczność połączenia dwóch obszarów: dotychczasowej ewidencji w module polskim i nowych zapisów księgowych. Nie chcemy utrzymywać dwóch niezależnych miejsc przechowywania tej samej informacji finansowej. Docelowo moduł polski i księga główna mają tworzyć zintegrowany mechanizm.
To również powód, dla którego kontrakty między modułami muszą uwzględniać obecny stan platformy. Pierwotny plan zakładał, że warstwa polska powstanie na podstawie gotowych kontraktów rdzenia finansowego. Życie zweryfikowało tę kolejność: moduł polski powstał wcześniej i ma już własne tabele, migracje oraz działające procesy.
Nie projektujemy więc kontraktów od zera, w oderwaniu od istniejącego rozwiązania. Musimy uwzględnić to, co już działa, oraz zgodność wsteczną z istniejącymi danymi i wdrożeniami.
To nie są tylko teoretyczne założenia. W backlogu znajdują się zadania dotyczące zadeklarowania zależności modułu polskiego od księgi głównej, udostępnienia wspólnego kontraktu podatkowego oraz przeniesienia ewidencji zakupowej na zapisy księgowe. Są to zaplanowane prace, a nie funkcje, które już działają.
Nie chcemy budować kolejnych funkcji księgowych jako osobnych rozwiązań, które dopiero później trzeba będzie ze sobą połączyć. Zaczynamy od planu kont i księgi głównej, żeby ustalić wspólne zasady zapisu danych finansowych. Jednocześnie projektujemy ten fundament z myślą o tym, co już działa w Open Mercato, zwłaszcza o module polskim. To pozwoli nam rozwijać księgowość jako spójną część platformy.
Plan kont i księga główna to pierwsza iteracja, a nie kompletny moduł księgowy. Backlog obejmuje także kolejne elementy fundamentu: obsługę dokumentów i operacji gospodarczych, raportowanie, rozliczanie w czasie oraz automatyzację dekretacji.
Poniższy zakres opisujemy według stanu backlogu na 21 września 2026 r. Dzielimy go na trzy grupy tematyczne, żeby pokazać zależności między obszarami. Nie jest to szczegółowy harmonogram ani deklaracja, że wszystkie funkcje z danej grupy pojawią się jednocześnie.
W tej grupie znajdziemy absolutny rdzeń systemu: silnik księgi głównej i domyślny plan kont. Backlog obejmuje również zapisy księgowe, storno, okresy obrachunkowe wraz z ich zamykaniem i ponownym otwieraniem, wymiary analityczne na pozycjach zapisów oraz salda kont.
Zaplanowany jest także bilans próbny, czyli zestawienie obrotów i sald (ZOiS). Służy do sprawdzania danych księgi i nie jest tym samym co bilans stanowiący część rocznego sprawozdania finansowego.
W backlogu znajduje się ponadto usługa zbiorczego odczytu księgi dla innych modułów oraz eksport audytowy.
Dalsze prace obejmują rejestr kontrahentów z weryfikacją w GUS, VIES i na białej liście oraz procesem akceptacji. Zaplanowano też obsługę faktur zakupowych, w tym ich zatwierdzanie, oraz księgowanie faktur sprzedaży, których wystawianie już działa w Open Mercato.
W backlogu są również płatności za faktury zakupowe i paczki przelewów, obsługa wyciągów bankowych oraz ich parowanie z rozrachunkami. Osobny obszar stanowią środki trwałe wraz z amortyzacją, odpisami i likwidacją. Warto podkreślić, że amortyzacja to integralna część obsługi księgowej środków trwałych, a nie jedynie prosty mechanizm automatyzujący.
Każdy z tych obszarów ma odrębny zakres zadań. Nie oznacza to, że wszystkie wymienione procesy będą dostępne wraz z pierwszą iteracją planu kont i księgi głównej.
W backlogu znajduje się również generowanie rocznego sprawozdania finansowego obejmującego bilans oraz rachunek zysków i strat (RZiS) w obu wariantach (kalkulacyjnym i porównawczym). Zaplanowano również JPK ksiąg rachunkowych (JPK_KR_PD) oraz wspólny kontrakt podatkowy spinający warstwę polską.
Warto podkreślić, że JPK_KR_PD jest planowaną funkcją i nie należy go utożsamiać z obsługą rejestrów JPK_V7, która już działa w module polskim.
Dalszy zakres obejmuje wielowalutowość i wycenę bilansową, rozliczanie przychodu w czasie (RMK) oraz silnik reguł księgowania z kontem 490 i miejscami powstawania kosztów (MPK). Reguły mają automatyzować dekretację powtarzalnych operacji, jednak w przypadku braku automatyzacji, system oczywiście pozwoli księgowemu na ręczną dekretację.
Prace rozpoczęliśmy od całodniowego warsztatu event stormingowego, który odbył się 5 września 2026 r. w Katowicach. Facylitował go Mariusz Gil, a ekspertem domenowym był Mateusz Duda z incro, kontroler finansowy, wcześniej księgowy. W warsztacie uczestniczyli także zespół deweloperski i core team Open Mercato. Dziękujemy także bardzo zespołowi Iteo za biuro i ich gościnność.
Pierwsza iteracja obejmuje plan kont i księgę główną, a nie pełną obsługę księgowości. Pozostałe funkcje opisane w tym artykule są ujęte w backlogu i będą wprowadzane w czasie. Pierwszą iterację chcielibyśmy opublikować na przełomie października i listopada. Do tego czasu księgowość w Open Mercato każde wdrożenie musi rozwiązać we własnym zakresie.
| Obszar | Stan |
|---|---|
| Wystawianie faktur sprzedaży | działa |
| Procesy magazynowe | działają |
| KSeF i JPK_V7 (moduł polski) | działają |
| Plan kont i księga główna | pierwsza iteracja – przełom października i listopada 2026 r. |
| Księgowanie faktur sprzedaży i zakupu | w backlogu |
| Bilans próbny, okresy obrachunkowe, storno | w backlogu |
| Sprawozdanie finansowe, JPK_KR_PD | w backlogu |
| Księgowanie dokumentów magazynowych | poza obecnym backlogiem |
Stan backlogu na 21 września 2026 r.
Za budowę modułu finansowego Open Mercato odpowiada Commerce Weavers. Pierwsza iteracja obejmuje plan kont i księgę główną.
Nie. Open Mercato obsługuje już procesy sprzedażowe i magazynowe, a moduł polskich finansów realizuje zadania związane z KSeF i JPK. Wspólna księga główna jest elementem tworzonego modułu finansowego.
Do czasu udostępnienia modułu finansowego każde wdrożenie rozwiązuje księgowość we własnym zakresie. Zespoły budują potrzebne funkcje albo integrują Open Mercato z osobnym systemem księgowym. Pierwsza iteracja modułu, obejmująca plan kont i księgę główną, ma pojawić się na przełomie października i listopada 2026 r.
Księgowanie faktur sprzedaży znajduje się w backlogu jako osobny obszar prac. Samo wystawianie faktur sprzedaży już działa w Open Mercato.
Obecnie nie ma go w backlogu modułu finansowego. Choć Open Mercato obsługuje procesy magazynowe, automatyczna dekretacja tych dokumentów nie jest częścią zapowiadanych tutaj prac.
Pierwszą iterację, obejmującą plan kont i księgę główną, chcemy opublikować na przełomie października i listopada 2026 r. Kolejne funkcje z backlogu będą wprowadzane stopniowo.
Tak. Moduł polskich finansów wysyła faktury do KSeF, odbiera faktury zakupowe oraz generuje i składa JPK_V7. Działa niezależnie od tworzonej księgi głównej. JPK ksiąg rachunkowych (JPK_KR_PD) jest dopiero planowany.
Wybór frameworka może wyglądać jak decyzja czysto techniczna. W praktyce wpływa jednak na znacznie więcej niż sposób, w ...
Czytaj więcej →
AI w developmencie e-commerce coraz mocniej wchodzi do codziennej pracy zespołów developerskich. Pomaga generować kod, p...
Czytaj więcej →
Decyzja o migracji do Sylius 2 to dopiero początek. W praktyce powodzenie upgrade'u zależy dużo bardziej od przygotowani...
Czytaj więcej →
