Programming 01 Maj 2026 ★ Featured

System ewidencji w Obsidian

Dostępne też w:

Obsidian jako system zarządzania projektem — jak zbudowałem swój vault ewidencji

Jeśli robisz cokolwiek własnoręcznie w większej skali — elektronikę, stolarkę, szycie, druk 3D, organizujesz warsztaty — to prędzej czy później dopadnie Cię ten sam problem: nie wiesz, co masz, gdzie to leży i czego Ci brakuje.

Arkusze kalkulacyjne robią się za duże - z resztą są tak naprawdę średnio wygodne. Notatki w telefonie nie są dostępne na komputerze. Pamięć zawodzi przy setnej śrubie M3. A gdy za tydzień masz warsztaty dla dwunastu osób, chciałbyś po prostu wiedzieć — czy masz wszystkie materiały, czy musisz coś kupić.

Przez dłuższy czas szukałem rozwiązania, które byłoby elastyczne, lokalne, nie wymagało subskrypcji i po prostu działało.
Myślałem już nawet, że sam stworzę apkę do tego. Jak się okazało, nie musiałem - znalazłem je w miejscu, w którym już i tak od niedawna prowadziłem notatki: w Obsidianie.


Problem: zarządzanie projektami w chaosie

Dla hobbysty czy małego wytwórcy „zarządzanie projektem" zazwyczaj brzmi poważnie jak na potrzeby. Ale w praktyce chodzi o kilka prostych pytań:

  • Ile mam diod 5mm na stanie i gdzie leżą?
  • Do jakich projektów są potrzebne i ile łącznie?
  • Jeśli chcę zbudować 5 sztuk lampki, czego mi brakuje i gdzie to kupię?
  • Na warsztaty w przyszłym miesiącu — czy mam wystarczająco kleju i papieru ściernego?

Żadne z tych pytań nie jest skomplikowane. Ale żeby na nie odpowiedzieć, potrzebujesz spójnej bazy danych powiązanych ze sobą informacji — a nie kolejnego folderu z plikami PDF i żółtych karteczek.

W moim przypadku prowadzę Teatr Tancerzy Ognia Arta Foc. Buduję wiele sprzętów i wykorzystuję mnóstwo technik od elektroniki, poprzez druk 3d do spawania włącznie. Potrzebowałem więc ewidencji na moje projekty (części, filamenty) + materiały eksploatacyjne na pokazy (paliwa, materiały pirotechniczne).


Rozwiązanie: Obsidian + Dataview

Obsidian to lokalny edytor notatek oparty na zwykłych plikach Markdown. Każda notatka może zawierać metadane w formacie YAML (tzw. frontmatter) — ustrukturyzowane pola, które możesz odczytywać i przetwarzać programatycznie.

Plugin Dataview zamienia te metadane w żywą bazę danych: możesz pisać zapytania SQL-like lub skrypty JavaScript, które skanują cały vault, zbierają dane i renderują je jako interaktywne tabele bezpośrednio w notatce.

Połączenie tych dwóch narzędzi daje coś nieoczekiwanego: arkusz kalkulacyjny, który rozumie kontekst.


Architektura systemu

System opiera się na kilku typach notatek, które są ze sobą powiązane przez linki wewnętrzne Obsidiana. Oto jak to wygląda:

Komponent ──────────────────────────► Lokalizacja
    │                                    (gdzie leży)
    │ wchodzi w skład
    ▼
Podprojekt ──────────────────────────► Projekt
    │                                    (moduł projektu)
    │ projekt jest źródłem
    ▼
Egzemplarz                           Zdarzenie
    (konkretna sztuka)                   │
                                         │ wymaga
                                    Typ zdarzenia
                                         │ materialy
                                         ▼
                                    Materiał eksploatacyjny

Każdy węzeł tego grafu to zwykły plik Markdown. Relacje między nimi to linki wewnętrzne (<span class="text-amber-500/50" title="Nieznany link">[[Nazwa_notatki]]</span>) zapisane w YAML.

Komponenty i BOM

Każdy komponent to osobna notatka z informacjami o stanie magazynowym, lokalizacji i cenie:

---
typ: elektronika
kategoria: pasywny
producent: Generic
lokalizacje:
  - lokalizacja: "<span class="text-amber-500/50" title="Nieznany link">[[Pudełko_Diody]]</span>"
    ilosc: 85
cena_szt: 0.15
---

Projekt z kolei definiuje listę komponentów (BOM — Bill of Materials):

---
typ: projekt
status: gotowy
komponenty:
  - komponent: "<span class="text-amber-500/50" title="Nieznany link">[[Dioda_LED_5mm_czerwona]]</span>"
    ilosc: 3
  - komponent: "<span class="text-amber-500/50" title="Nieznany link">[[Rezystor_220ohm]]</span>"
    ilosc: 3
podprojekty:
  - podprojekt: "<span class="text-amber-500/50" title="Nieznany link">[[Sterownik_LED]]</span>"
    ilosc: 1
---

Skrypt resolve_komponenty.js rekurencyjnie przechodzi przez podprojekty i spłaszcza całe drzewo zależności do jednej listy. Jeśli jeden projekt używa podprojektu, który sam używa kolejnego — system to rozumie i mnoży ilości przez odpowiednie współczynniki.

Lokalizacje jako hierarchia

Lokalizacje tworzą zagnieżdżoną hierarchię: pomieszczenie → szafka → pojemnik. Każda lokalizacja to osobna notatka z linkiem do rodzica:

---
typ: pojemnik
lokalizacja: "<span class="text-amber-500/50" title="Nieznany link">[[Regał_Elektroniki]]</span>"   # Szafka, która jest w Warsztacie.
---

Dzięki temu możesz otworzyć notatkę pomieszczenia i zobaczyć wszystko, co się w nim znajduje — nie tylko bezpośrednio, ale też w szafkach i pojemnikach wewnątrz. Skrypt spis_elementow_lokalizacji.js robi to rekurencyjnie.


Jak to działa w praktyce

Dodaję nowy komponent

Tworzę nową notatkę w Komponenty/Elektronika/ ze szablonu. Wypełniam: typ, gdzie leży, ile mam, ile kosztuje. Jedna notatka, dwie minuty.

Od tej chwili ten komponent jest "widoczny" dla całego systemu: pojawi się w tabeli zapotrzebowania, gdy projekt go użyje, w spisie lokalizacji w Warsztacie, i w profilu projektu który go zawiera.

Buduję projekt

W YAML projektu linkuję komponenty. Gdy mam skomplikowany projekt z modułami — tworzę podprojekty, łączę je linkami, podaję mnożniki. Otwierany widok projektu pokazuje automatycznie wyliczoną pełną listę BOM z uwzględnieniem całej hierarchii.

Przy każdym komponencie widzę, ile mam na stanie i czy to wystarczy. Czerwona ikonka ⚠️ sygnalizuje brak.

Planuję zakupy

Otwieram Zapotrzebowanie.md i w YAML wpisuję, ile egzemplarzy chcę zbudować:

cele_produkcyjne:
  - projekt: "<span class="text-amber-500/50" title="Nieznany link">[[Lampka_Nastrojowa]]</span>"
    sztuk: 5

Tabela poniżej automatycznie oblicza sumaryczne zapotrzebowanie, porównuje ze stanem magazynowym i pokazuje, czego brakuje — z linkiem do sklepu.

To jest dosłownie jedna zmiana w pliku. Bez formuł, bez ręcznego liczenia.

Planuję warsztaty

Tworzę "typ zdarzenia" — recepturę, która mówi, jakich materiałów potrzeba na jedno spotkanie. Potem tworzę konkretne zdarzenie z datą i linkiem do typu. Otwarcie Nadchodzace_Zdarzenia.md pokazuje kalendarz wszystkich nadchodzących zdarzeń i zbiorczy bilans — ile materiałów w sumie potrzebujesz na wszystkie z nich.

Przykład jednego z moich pojemników.
Przykład jednego z moich pojemników.

Co jest w szablonie

Repozytorium zawiera gotowy do użycia zestaw:

15 skryptów DataviewJS — logika systemu: rekurencja BOM, interaktywne tabele z filtrowaniem i sortowaniem, bilanse materiałów, spis lokalizacji.

10 szablonów Markdown — gotowe wzorce dla każdego typu notatki, z wypełnionymi kluczami YAML i osadzonymi wywołaniami skryptów.

14 przykładowych notatek — kompletny przykład: warsztat z regałami i pojemnikami, kilka komponentów elektronicznych i mechanicznych, projekt lampki LED z podprojektem-sterownikiem, zaplanowane warsztaty z bilansem materiałów.

5 dashboardów — gotowe widoki agregujące informacje z całego vaultu.


Dla kogo to jest?

System sprawdzi się wszędzie tam, gdzie masz:
- Zestawy fizycznych komponentów lub materiałów do śledzenia.
- Projekty składające się z wielu części (BOM).
- Kilka miejsc przechowywania (lokalizacje).
- Powtarzalne zdarzenia wymagające określonego zestawu materiałów (warsztaty, targi, spotkania).

Dosłownie w każdej branży: elektronika, stolarstwo, szycie i krawiectwo, ceramika, biżuteria, gotowanie (przepisy jako "typy zdarzeń", składniki jako materiały), gry planszowe (komponenty zestawu), cosplay, modelarstwo i wiele innych.

Część samoaktualizującej się tabeli z filamentami.
Część samoaktualizującej się tabeli z filamentami.

Ograniczenia i kiedy NIE używać

System oparty na Obsidianie i Dataview ma swoje granice:

  • Nie jest systemem ERP — nie ma historii transakcji, rozliczeń, faktur.
  • Nie ma synchronizacji w chmurze - chyba że używasz Obsidian Sync albo jak ja - przez Dropbox.
  • Skrypty działają tylko w Obsidianie — eksport do HTML nie renderuje DataviewJS.
  • Przy bardzo dużej liczbie notatek (tysiące) Dataview może spowalniać, choć ja jeszcze tego nie doświadczyłem.

Jeśli zarządzasz magazynem z tysiącami SKU i potrzebujesz systemu do fakturowania — to nie jest właściwe narzędzie. Jeśli prowadzisz warsztat, hobby lub małą pracownię — system działa naprawdę świetnie.


Zaczynasz

  1. Pobierz lub sklonuj repozytorium.
  2. Skopiuj folder obsidian-ewidencja-pl do swojego vaultu.
  3. Zamień Arta na nazwę swojego vaultu (jeden sed lub find-replace).
  4. Otwórz przykładowe notatki i przejrzyj, jak wyglądają.
  5. Stwórz pierwszy komponent ze szablonu, dodaj do projektu, sprawdź Zapotrzebowanie.md

Cała konfiguracja zajmuje około 10 minut. Reszta to dodawanie własnych notatek w tempie, który Ci odpowiada.


Podsumowanie

Obsidian to zwykły edytor Markdown. Dataview to silnik zapytań. Razem tworzą coś, czego nie daje żadna gotowa aplikacja: elastyczny, lokalny, w pełni własny system informacyjny, który rośnie razem z Twoimi projektami i nie narzuca żadnego modelu danych poza tym, co sam zdefiniujesz.

Szablon Ewidencji to punkt startowy — gotowy do działania od pierwszej minuty, ale zaprojektowany tak, żebyś mógł go rozbudowywać i dostosowywać dokładnie do swojej dziedziny.


Szablon dostępny na Bitbucket: link do repozytorium

Stworzyłem jeszcze wersję w języku angielskim i hiszpańskim! Są dostępne w moim projekcie link do Inventory.

Licencja: MIT