MaDevo - automatyzacja B2B i agenci AI

Problem biznesowy: Wprowadzanie nowych wariantów produktów do systemu e-commerce było wysoce powtarzalnym wąskim gardłem. Dział handlowy spędzał wiele godzin na żmudnym przypisywaniu zdjęć do kodów SKU oraz kopiowaniu opisów. Powielanie tych samych tekstów (Duplicate Content) dodatkowo obniżało pozycjonowanie ofert.

Zbudowaliśmy system, który całkowicie zautomatyzował ten proces, zachowując pełną kontrolę nad integralnością danych.

Architektura i przepływ danych (data flow)

Wdrożyliśmy hybrydowe rozwiązanie (Smart Frontend + Agentic Backend), aby zachować niezawodność także przy masowym przetwarzaniu (batch processing):

1. Smart queueing (ochrona przed rate limits): Użytkownik ładuje CSV i paczkę zdjęć w panelu webowym. Frontend kolejkuje żądania i wysyła je sekwencyjnie, zamiast strzelać wszystkimi requestami naraz (HTTP 429).

2. Edge security: Przepływ n8n zaczyna się od webhooka, który natychmiast weryfikuje zaszyfrowane hasło ukryte w payloadzie. Nieautoryzowany ruch jest odrzucany zanim dotknie logiki biznesowej i limitów API.

3. Walidacja stanu magazynowego: Przed uruchomieniem AI system wykonuje zapytanie GET do BaseLinkera, szuka produktu referencyjnego po SKU i przy braku referencji od razu przerywa wątek, wysyłając alert błędu na firmowego Discorda.

Czysty JavaScript > ślepe low-code

Wizualne workflow engines świetnie orkiestrują API, ale przy skomplikowanej transformacji danych gotowe bloki bywają kruche. Największym wyzwaniem było bezbłędne przypisanie dziesiątek zdjęć do właściwych wariantów.

AI jako silnik SEO (LLM)

Jeśli pracownik aktywował flagę AI, surowe parametry produktu trafiały do modelu GPT-4o. Model nie decydował o logice biznesowej - działał jako wyspecjalizowany copywriter. Na bazie rygorystycznego promptu generował unikalny tytuł i bogaty opis HTML.

Na końcu komplet danych (nowe SKU, mapowanie zdjęć z JS i kod HTML z AI) trafiał do BaseLinkera przez addInventoryProduct, tworząc ofertę gotową do sprzedaży.

Problem biznesowy: Fakturowanie stałych zleceń B2B polegało na ręcznym kopiowaniu opisów z kart w Trello do systemu księgowego wFirma. Przy zamówieniach wielopozycyjnych handlowiec spędzał nawet 15 minut nad jedną fakturą. Przy nadchodzącym KSeF najdrobniejszy błąd w numerze NIP lub kwocie generuje poważne ryzyko prawne i konieczność korekt.

Rozwiązanie: agent AI analizujący nieustrukturyzowany tekst, spięty z twardą walidacją w rejestrach państwowych i API księgowym.

Architektura danych: od chaosu do JSON-a

System opiera się na paradygmacie Human-in-the-loop: AI odbiera większość czarnej roboty, ale ostateczne „wyślij” zostaje u człowieka.

1. Event-driven trigger: zmiana statusu karty w Trello na „Do wystawienia FV” natychmiast wysyła webhook do n8n.

2. Ekstrakcja danych AI (Gemini / GPT-4o): LLM czyta chaotyczne opisy z Trello, wyciąga NIP i pozycje zamówienia, zwracając czystą tablicę JSON (nazwa produktu + cena netto).

JS guardrail: dlaczego nie ufamy AI w finansach?

Modele językowe świetnie radzą sobie z kontekstem, ale bywają słabe w matematyce i precyzji. W księgowości nie ma miejsca na halucynacje.

Walidacja GUS i księgowanie (wFirma API)

Zanim wygenerujemy dokument, dane kontrahenta muszą być legalne i aktualne:

1. API Ministerstwa Finansów (GUS): zapytanie do białej listy podatników VAT po NIP; pobieramy oficjalną nazwę i adres, nadpisując literówki z karty Trello.

2. wFirma REST API: iteracja po oczyszczonej tablicy produktów (np. .map()) i utworzenie jednej faktury wielopozycyjnej.

3. Status draft: dokument w stanie normal_draft (szkic); pracownik dostaje powiadomienie na Discordzie i etykietę w Trello, weryfikuje szkic w wFirma i klika akceptację.

Automatyzacja potrafi być pułapką: gdy system działa stabilnie, firma przetwarza więcej transakcji. Przy wejściu KSeF biura rachunkowe zaczęły naliczać opłaty za przetworzenie każdego dokumentu (np. ok. 0,80 zł / fakturę). Osobna faktura na każde drobne zlecenie z Trello dla stałych klientów B2B generowała niepotrzebny narzut.

Rozwiązanie wymagało zmiany architektonicznej: z paradygmatu event-driven na batch processing.

Bufor relacyjnej bazy (PostgreSQL)

Zamiast natychmiast uderzać do API wFirmy przy zamknięciu karty w Trello, zaprojektowaliśmy buforowanie stanu w bazie:

1. Storage (odkładanie w czasie): po zamknięciu karty n8n nadal wyciąga dane (AI), ale zamiast faktury zapisuje wiersz w tabeli PendingOrders w PostgreSQL ze statusem „Oczekuje”. Trello dostaje odpowiednią etykietę.

2. Zadanie cykliczne (CRON): ostatniego dnia miesiąca o 15:00 serwer uruchamia proces wsadowy.

Jeden strzał do API

Po agregacji w SQL workflow wykonuje jeden strzał do API wFirmy na kontrahenta: jedna faktura zbiorcza z wieloma pozycjami (np. 20 zleceń z miesiąca). Rekordy w bazie przechodzą w status „Zafakturowane”.

Budowanie agencji automatyzacji (AIAA) i komercyjnych wdrożeń B2B zmieniło moje podejście do inżynierii. Klienci nie płacą za „czysty kod’’ ani za to, który framework jest modny - płacą za niezawodność, odzyskany czas i uszczelniony budżet.

Key takeaways

01 - Nigdy nie ufaj ślepo AI (data sanitization)

Modele LLM (Gemini, GPT-4o) świetnie czytają nieustrukturyzowany tekst, ale bywają słabe w precyzyjnej matematyce. W obiegu dokumentów finansowych AI musi być domknięte twardymi ramami walidacji w kodzie - np. weryfikacja sum w JavaScript.

02 - API to fundament, low-code to orkiestrator

Narzędzia w stylu n8n nie zastępują inżyniera - przyspieszają składanie systemów. Żeby zbudować niezawodny obieg dokumentów, nadal trzeba rozumieć kontrakty REST API, nagłówki autoryzacji, paginację i rate limiting. Gdy gotowe bloki nie starczają, potrzebny jest własny kod i SQL.

03 - Human-in-the-loop jako tarcza bezpieczeństwa

W procesach krytycznych (ERP, fakturowanie) automatyzacja nie powinna wyeliminować człowieka - ma dać mu przewagę. Dokumenty w statusie draft (szkic) skracają pracę z 15 minut do ok. 10 sekund, ale odpowiedzialność zostaje po stronie człowieka.