Czy integracja enova365 z portalem B2B wymaga dodatkowych licencji?

Tak. Moduł Soneta WebAPI to osobny płatny dodatek — nie ma go w pakiecie podstawowym enova365. Dostępny jako licencja wieczysta albo subskrypcja miesięczna. Zanim zaczniesz cokolwiek planować, zadzwoń do resellera i potwierdź, że moduł jest aktywny. Bez niego zostajesz przy wymianie plikowej albo bezpośrednim dostępie do MS SQL — oba rozwiązania kosztują więcej w utrzymaniu niż cena modułu.

Ile trwa pełna integracja enova365 z portalem B2B?

3–5 dni roboczych dla pełnej dwukierunkowej integracji: katalog produktów, ceny indywidualne, stany magazynowe, składanie zamówień, pobieranie faktur. Łączny czas kalendarzowy to 2–3 tygodnie — i prawie zawsze tę różnicę robi czekanie na IT. Dostęp sieciowy do serwera WebAPI nie pojawia się od ręki.

Czy enova365 może wysyłać aktualizacje do portalu, zamiast portal odpytywał ERP?

Tak, przez Harmonogram Zadań. enova365 może wysyłać wychodzące powiadomienia HTTP, gdy coś się dzieje — zmiana statusu zamówienia, aktualizacja stanów. To wyraźnie redukuje obciążenie synchronizacją. Nie każda instalacja enova365 ma to skonfigurowane — zapytaj resellera lub administratora, zanim zaprojektujesz architekturę opartą na webhookach.

Czy portal B2B powinien sam liczyć ceny, czy pobierać je z enova365?

Zawsze z enova365. Nie odtwarzaj logiki cenowej w portalu. Polskie ceny hurtowe mają zbyt wiele warstw — grupy cenowe, indywidualne rabaty per klient, progi ilościowe, promocje czasowe — i każda rozbieżność między tym, co pokazuje portal, a tym, co wystawia ERP na fakturze, niszczy zaufanie klienta. Niech enova365 liczy; portal tylko wyświetla.

Integracja enova365 z portalem B2B przez Soneta WebAPI — praktyczny przewodnik

Dlaczego enova365 integruje się najłatwiej ze wszystkich polskich ERP-ów

Jeśli kiedyś robiłeś integrację portalu B2B z Subiektem GT albo Comarch Optimą, wiesz, o czym mówię: gonienie IT za regułami firewalla, obchodzenie SDK, które nigdy nie miało działać w cloudzie, debugowanie cichych błędów importu XML w środku nocy przed uruchomieniem. enova365 to inne doświadczenie.

Soneta — firma stojąca za enova365 — zbudowała porządne REST API. Udokumentowane, wersjonowane, spójne między wydaniami, pokrywające wszystko, czego potrzebuje hurtowy portal B2B. Porównując harmonogramy integracji różnych polskich ERP-ów, enova365 regularnie wychodzi na 3–5 dni roboczych dla pełnej dwukierunkowej konfiguracji. Subiekt GT przez Sferę — 5–7. Comarch Optima przez wymianę plikową — 7–10.

Ta różnica nie wynika ze złożoności portalu. Wynika z tego, ile walki toczysz po stronie ERP. Przy enova365 tej walki prawie nie ma.

Artykuł jest dla firm, które już działają na enova365 i chcą podłączyć hurtowy portal B2B. Jeśli dopiero wybierasz ERP, artykuł porównawczy o integracji portali B2B z Subiektem GT, Optimą i enova365 daje pełny obraz. A jeśli chcesz wiedzieć, co portal B2B robi poza warstwą integracji ERP, zajrzyj na stronę portalu hurtowego.

Soneta WebAPI: co to jest i co robi

Soneta WebAPI to oficjalny moduł integracyjny rozwijany przez Sonetę. Działa jako osobny proces serwera — niezależny od aplikacji desktopowej enova365 — i udostępnia dane enova365 przez HTTP/HTTPS.

Dostępne są dwa warianty:

WebAPI Server (REST) — obecny standard. JSON przez HTTP, prosty w obsłudze z każdego języka i platformy. To tego używasz przy nowych integracjach.

WebWCF Server (SOAP) — wariant legacy, utrzymywany dla wstecznej kompatybilności. Jeśli zaczynasz od zera — nie dotykaj. Jeśli przejmujesz integrację zbudowaną na WebWCF, warto zaplanować migrację do REST, ale nie ma pośpiechu.

Kontrolery dynamiczne i statyczne

Tu enova365 robi się naprawdę ciekawe. WebAPI oferuje dwa typy endpointów:

Kontrolery dynamiczne są automatycznie generowane z modelu danych enova365. Soneta mapuje większość standardowych obiektów — produkty, kontrahentów, dokumenty, magazyny — na endpointy REST bez żadnego kodu po stronie enova. Dostajesz działające API dla zdecydowanej większości potrzeb portalu B2B od razu.

Kontrolery statyczne to niestandardowe integracje osadzone w serwerze WebAPI. Piszesz je, gdy potrzebujesz logiki biznesowej po stronie enova365 — złożonej kalkulacji, wieloetapowego workflow lub transformacji danych, której kontrolery dynamiczne nie obsłużą. Przy standardowych integracjach portali B2B rzadko są potrzebne.

Autoryzacja

WebAPI używa tokenów JWT. Przepływ jest prosty:

Portal wysyła dane uwierzytelniające do endpointu autoryzacji WebAPI
enova365 waliduje i zwraca podpisany token JWT
Portal dołącza token do nagłówka każdego kolejnego żądania
Token wygasa; portal automatycznie go odświeża

Standardowe zarządzanie tokenami w stylu OAuth. Każdy framework backendowy obsługuje to natywnie — nic egzotycznego.

Wymagania licencyjne i infrastrukturalne

Zanim dotkniesz jednej linii kodu, potwierdź dwie rzeczy:

Licencja: WebAPI to osobny płatny moduł — nie ma go w pakiecie podstawowym enova365. Reseller aktywuje go na Twojej licencji jako dodatek wieczysty lub subskrypcję miesięczną. Zadzwoń, podaj NIP i zapytaj wprost: "Czy moduł WebAPI jest aktywny na naszej licencji?" Jeśli nie jest — dokup go przed startem projektu. Koszt modułu jest prawie zawsze niższy niż koszt zbudowania i utrzymania synchronizacji plikowej jako alternatywy.

SQL Server: enova365 działa na Microsoft SQL Server — wersje 2016, 2017, 2019, 2022 lub 2025, Standard lub Express. Serwer WebAPI musi mieć dostęp do instancji SQL Server. Zazwyczaj to ta sama maszyna albo ta sama sieć LAN, więc w praktyce nie stanowi to problemu.

Dostęp sieciowy: Serwer WebAPI musi być osiągalny z Twojego portalu. Dwie opcje:

Otwarcie portu na serwerze enova365 i wpisanie IP portalu na whitelist
Tunel VPN między środowiskiem cloudowym portalu a siecią serwera enova365

Oba działają. VPN dodaje trochę latencji, ale nie wystawia portu na otwarty internet. Ogarnij to z IT przed startem prac — "skonfigurujemy firewall" to zdanie, które rutynowo dodaje dwa tygodnie do projektów.

WebAPI enova365 działa zarówno na Windows, jak i na Linux, więc cloudowy deployment komponentu WebAPI jest możliwy, jeśli chcesz trzymać wszystko w jednym środowisku.

Jakie dane przepływają między enova365 a portalem B2B

To standardowa mapa danych dla polskiego hurtowego portalu B2B. Każda pozycja jest obsługiwana przez kontrolery dynamiczne enova365 WebAPI.

Zasób	Termin w enova365	Kierunek	Częstotliwość
Produkty	Towary	ERP → Portal	Co 60 min lub przy zmianie
Ceny per klient	Ceny per kontrahent	ERP → Portal	Co 15 min
Grupy cenowe	Grupy cenowe	ERP → Portal	Raz dziennie
Stany magazynowe	Stany magazynowe	ERP → Portal	Co 5–15 min
Zamówienia sprzedaży	ZS	Portal → ERP	W czasie rzeczywistym
Status zamówienia	Status ZS	ERP → Portal	Co 15–30 min lub webhook
Faktury	FS (faktury sprzedaży)	ERP → Portal	Przy wygenerowaniu
PDF faktury	PDF faktury	ERP → Portal	Na żądanie
Kontrahenci	Kontrahenci	ERP → Portal	Raz dziennie
Limity kredytowe	Limity kredytowe	ERP → Portal	Raz dziennie
Warunki płatności	Warunki płatności	ERP → Portal	Raz dziennie
Dokumenty WZ	WZ (wydania zewnętrzne)	ERP → Portal	Przy wygenerowaniu

Co zazwyczaj nie wchodzi w zakres pierwszej fazy: zdjęcia produktów (zarządzane osobno w PIM lub wgrywane ręcznie), pola niestandardowe dodane przez enova365 dodatki — chyba że są wprost wymagane — oraz konfiguracje wielofirmowe, gdy enova365 obsługuje kilka podmiotów prawnych.

Architektura integracji krok po kroku

To architektura, której używam w integracjach portali B2B z enova365. Pokrywa pełny dwukierunkowy przepływ.

1. Autoryzacja

Backend portalu ma w tle manager tokenów. Przy starcie uwierzytelnia się wobec serwera WebAPI i przechowuje JWT. Zadanie odświeżania działa co N minut — przed wygaśnięciem tokena. Wszystkie żądania wychodzące do enova365 przechodzą przez jeden klient HTTP, który wstrzykuje aktualny token.

Danych uwierzytelniających enova365 nigdy nie wstawiaj do kodu frontendowego. Frontend portalu wywołuje własny backend; backend wywołuje enova365. Dane i tokeny zostają po stronie serwera.

2. Synchronizacja katalogu produktów

Zaplanowane zadanie działa co 60 minut — lub jest wyzwalane webhookiem, jeśli instalacja to obsługuje. Wywołuje endpoint Towarów, porównuje odpowiedź z tym, co już jest w bazie portalu, i wykonuje upsert zmian. Nowe produkty są dodawane; zmienione opisy, jednostki lub kategorie aktualizowane; produkty usunięte z enova365 oznaczane jako nieaktywne w portalu.

Nie pobieraj pełnego katalogu za każdym razem, chyba że jest mały. Pytaj o rekordy zmodyfikowane po danym znaczniku czasu — WebAPI obsługuje filtrowanie. Na katalogu 10 000 SKU różnica między pełnym pobieraniem a deltą jest odczuwalna.

3. Synchronizacja cen

Ceny indywidualne to najważniejsze dane w portalu B2B. Kontrahenci są przypisani do grup cenowych w enova365 i mogą mieć indywidualne nadpisania cen per produkt. Portal musi to odzwierciedlać dokładnie.

Zadanie synchronizacyjne działa co 15 minut. Dla każdego aktywnego kontrahenta pobiera jego aktualne ceny z enova365. Cena zapisana w portalu to cena końcowa wyliczona przez enova365 — nigdy cena bazowa z lokalnie zastosowanym rabatem.

To wystarczająco ważne, żeby powiedzieć wprost: kalkulacja cen dzieje się w enova365, nie w portalu. Jeśli pozwolisz portalowi odtworzyć logikę rabatową, w końcu trafisz na przypadek, gdy portal i ERP się rozjeżdżają, a klient dostaje fakturę na inną kwotę niż zamawiał. Ta rozmowa jest nieprzyjemna.

4. Synchronizacja stanów magazynowych

Synchronizacja stanów działa co 5–15 minut, zależnie od rotacji towaru. Endpoint zwraca stany per lokalizacja — możesz agregować po magazynach lub wyświetlać dostępność per magazyn, zależnie od wymagań portalu.

W szczytowych okresach — wyprzedaż, koniec miesiąca, duże zamówienia — rozważ skrócenie interwału do 2–3 minut. WebAPI to wytrzyma. Wąskim gardłem jest zazwyczaj przepustowość aktualizacji własnej bazy portalu, nie enova365.

5. Składanie zamówień

Gdy klient potwierdza zamówienie w portalu, backend natychmiast tworzy Zamówienie Sprzedaży (ZS) w enova365 przez POST do endpointu zamówień. Żądanie zawiera:

Identyfikator kontrahenta (wewnętrzne ID enova365, nie tylko NIP)
Pozycje: ID produktu, ilość i cena potwierdzona przez portal
Adres dostawy i metodę wysyłki, jeśli dotyczy
Uwagi do zamówienia

enova365 zwraca ID i numer utworzonego dokumentu. Przechowaj oba. Numer dokumentu (np. ZS/2026/04/1234) widzi klient; wewnętrzne ID używasz we wszystkich kolejnych wywołaniach API dotyczących tego zamówienia.

Ważne: pozwól enova365 przydzielić numer dokumentu. Nigdy nie generuj ani nie sugeruj numerów po stronie portalu. Sekwencje numerowania enova365 są powiązane z jej wewnętrznym stanem — zewnętrzna numeracja tworzy luki i korupcję danych.

6. Odpytywanie statusu zamówień

Po złożeniu zamówienia portal odpytuje o aktualizacje statusu. Standardowe statusy enova365 mapują się na stany portalu mniej więcej tak:

Status enova365	Stan w portalu
Nowe / W realizacji	W toku
Zatwierdzone	Potwierdzone
Zrealizowane	Zrealizowane
Anulowane	Anulowane

Odpytuj co 15–30 minut dla aktywnych zamówień. Zamówienia zakończone — zrealizowane lub anulowane — oznacz jako terminalne i przestań je odpytywać. Nie ma powodu bić w API dla zamkniętych dokumentów.

7. Pobieranie faktur

Gdy zamówienie przechodzi do stanu zafakturowanego, enova365 wygenerowała Fakturę Sprzedaży (FS). Portal pobiera metadane faktury i przechowuje link. Gdy klient chce pobrać PDF, portal pobiera go z enova365 na żądanie — albo buforuje przez konfigurowalny czas. Faktury zostają w ERP, gdzie należą dla celów księgowych.

Webhooki przez Harmonogram Zadań

Architektura opisana powyżej jest oparta na odpytywaniu: portal pyta enova365 "czy jest coś nowego?" według harmonogramu. Działa niezawodnie, ale generuje zbędne obciążenie, gdy nic się nie zmieniło.

Harmonogram Zadań to mechanizm enova365 do powiadomień wychodzących. Skonfigurowany przez administratora, może wysyłać żądania HTTP POST do endpointu webhookowego portalu przy określonych zdarzeniach:

Zmiana statusu zamówienia — najbardziej przydatna
Spadek stanu magazynowego poniżej progu
Wygenerowanie nowej faktury
Aktualizacja danych kontrahenta

Payload webhooka zawiera ID zmienionego obiektu. Portal go odbiera, natychmiast odpytuje WebAPI o aktualne dane i odzwierciedla zmianę — zazwyczaj w ciągu sekund od momentu, gdy nastąpiła w enova365.

Nie każda instalacja enova365 ma Harmonogram Zadań skonfigurowany do wychodzących webhooków. Zapytaj administratora lub resellera przed zaprojektowaniem architektury wokół tego mechanizmu. Jeśli jest — używaj: redukuje odpytywanie i sprawia, że portal reaguje wyraźnie szybciej. Jeśli nie ma — samo odpytywanie działa dobrze, jest po prostu nieco mniej efektywne.

Do używania webhooków portal potrzebuje publicznie dostępnego endpointu HTTPS. Serwer enova365 musi móc go osiągnąć, więc konfiguracje tylko przez VPN wymagają dodatkowego routingu.

Ceny w enova365: dlaczego ERP musi być jedynym źródłem prawdy

Polskie ceny hurtowe są wielowarstwowe. Typowa konfiguracja enova365 ma:

Cennik bazowy — podstawowa lista cenowa, zazwyczaj koszt plus marża lub ceny rynkowe
Grupy cenowe — grupy, do których przypisani są kontrahenci (np. Hurt A, Hurt B, Detalista)
Rabaty per klient per produkt — indywidualne rabaty przypisane do konkretnych kontrahentów
Progi ilościowe — kup 50+, dostań dodatkowe 3%
Promocje okresowe — rabaty czasowe, które aktywują się i wygasają w określonych datach

Interakcja między tymi warstwami podlega regułom priorytetu wbudowanym w silnik cenowy enova365. Precyzyjne odwzorowanie ich w zewnętrznym kodzie jest trudniejsze niż wygląda — i reguły mogą się zmienić, gdy ktoś zaktualizuje grupę cenową lub skoryguje promocję.

Jedyne solidne podejście: wywołaj endpoint cenowy enova365 z konkretnym kontrahentem i produktem. Pobierz cenę końcową. Wyświetl ją. Nie buforuj cen dłużej niż 15 minut dla aktywnych sesji — zmiana ceny między wyświetleniem katalogu a złożeniem zamówienia to realny scenariusz.

Przy potwierdzeniu zamówienia ponownie zwaliduj cenę wobec enova365, zanim utworzysz dokument ZS. Jeśli cena zmieniła się między "klient dodał do koszyka" a "klient kliknął potwierdź" — pokaż mu różnicę. Nie składaj zamówienia po cichu ze starą ceną. Faktura przyjdzie z nową i klient do Ciebie zadzwoni.

5 rzeczy do sprawdzenia przed startem integracji

Te pięć punktów eliminuje najczęstsze opóźnienia i niespodzianki, jakie widziałem w integracjach enova365:

1. Moduł WebAPI jest aktywny w licencji. Nie "wydaje nam się" — potwierdź u resellera, miej to na piśmie. Sprawdź też, która wersja enova365 jest zainstalowana — dokładny numer builda, nie "jakaś enova365". Zachowanie niektórych endpointów zmieniło się między głównymi wersjami.

2. Ścieżka sieciowa z portalu do serwera WebAPI istnieje. Wyślij testowe żądanie HTTP z serwera portalu do serwera WebAPI zanim napiszesz jakikolwiek kod integracyjny. Jeśli to żądanie się nie uda, nic innego też nie zadziała. Rozwiąż to przed startem.

3. Zdobądź realny eksport danych zanim zaczniesz pisać logikę synchronizacji. Poproś o CSV aktualnego katalogu produktów, cenników i aktywnych kontrahentów. Użyj go do zrozumienia rzeczywistych danych — pola dodatkowe z enova365 dodatki, niestandardowe struktury produktów, kontrahenci z wyjątkowymi warunkami płatności. Dokumentacja mówi, co jest możliwe; eksport mówi, co faktycznie jest w użyciu.

4. Zrozum obieg zamówień. Jak zamówienie przechodzi od ZS przez WZ do FS w tej konkretnej instalacji? Nie podręcznikowy przepływ — rzeczywisty, z niestandardowymi statusami lub etapami zatwierdzania. Każde przejście statusu musi być zmapowane na stan portalu.

5. Zidentyfikuj pola dodatkowe wcześnie. Instalacje enova365 z dodatkami branżowymi często mają niestandardowe pola na produktach, kontrahentach lub dokumentach. Kontrolery dynamiczne je eksponują, ale musisz wiedzieć, że istnieją, żeby uwzględnić je w modelu danych. Poproś administratora enova365 o listę pól dodatkowych przed fazą mapowania danych.

Harmonogram i koszty

Czas developmentu: 3–5 dni roboczych dla standardowej pełnej dwukierunkowej integracji — konfiguracja autoryzacji WebAPI, synchronizacja produktów i cen, synchronizacja stanów, składanie zamówień i odpytywanie statusów, pobieranie faktur.

Czas kalendarzowy: łącznie 2–3 tygodnie. Delta między dniami roboczymi a tygodniami to prawie zawsze to samo: czekanie na dostęp sieciowy. Serwer WebAPI musi być osiągalny ze środowiska portalu. Jeśli IT musi otworzyć port firewalla lub skonfigurować VPN, zgłoszenie trafia do kolejki. Wyślij IT dokładne wymagania — docelowe IP, numer portu, protokół — zanim zaczniesz development.

Koszt modułu WebAPI: zależy od pakietu enova365 i resellera. Typowy zakres to od kilkuset do kilku tysięcy PLN rocznie, zależnie od poziomu licencji. Zapytaj resellera o wycenę — to nie są ceny publiczne. Prawie zawsze jest to tańsze niż utrzymanie synchronizacji plikowej, która wymaga więcej czasu developerskiego i ciągłych poprawek.

Kiedy dodać drugą fazę: po uruchomieniu i stabilizacji integracji podstawowej popularne rozszerzenia to powiadomienia webhookowe przez Harmonogram Zadań, wyświetlanie stanów per magazyn i śledzenie zamówień po stronie portalu z integracją przewoźnika.

Gotowy podłączyć enova365 do portalu B2B?

Soneta WebAPI sprawia, że enova365 jest najczystszym celem integracyjnym na polskim rynku ERP. Architektura jest przejrzysta, pokrycie danych kompletne, a harmonogram przewidywalny — pod warunkiem, że kwestia dostępu sieciowego zostanie rozwiązana przed startem prac.

Jeśli działasz na enova365 i rozważasz portal B2B albo masz istniejący portal, który musi się z enova365 połączyć, napisz do mnie — ocenię Twoją konkretną konfigurację i powiem wprost, co integracja będzie wymagać po Twojej stronie.

Jak enova365 wypada na tle Subiekta GT i Comarch Optimy — znajdziesz w porównaniu integracji ERP. O tym, co zawiera portal B2B poza warstwą ERP, przeczytasz na stronie portalu hurtowego albo na stronie usługi integracji ERP z B2B.

Integracja enova365 z portalem B2B — jak działa Soneta WebAPI w praktyce