Obieg dokumentów, który przeprowadził się do przeglądarki.
Aplikacja web (ASP.NET Core 8, Blazor Server)Interfejs działa w przeglądarce (Blazor Server). Logika zostaje w procedurach PL/SQL — tych samych, z których korzystała wersja desktopowa.
Obieg dokumentów w aplikacji desktopowej działa, dopóki wszyscy siedzą przy firmowych komputerach. Problem zaczyna się, gdy akceptacja czeka na osobę w delegacji, gdy nowy pracownik potrzebuje instalacji i uprawnień, gdy trzeba wejść z domu. Naturalna odpowiedź brzmi „kupmy nowy system obiegu”, ale to oznacza przepisanie od zera reguł, które przez lata dopracowano — i uczenie wszystkich od nowa.
Wcześniej obieg dokumentów działał jako aplikacja desktopowa. Przeniosłem go do przeglądarki, zostawiając reguły w procedurach Oracle. Firma korzysta więc z tych samych, sprawdzonych mechanizmów, tylko przez nowy interfejs. W komplecie skrzynka zadań, akceptacje z routingiem decyzji, moduł kancelaryjny i OCR czytający polskie skany.
Zadania z terminami płatności i licznikami, które są jednocześnie filtrami. Ustawienia filtrów można zapisać w przeglądarce.
Formularz korespondencji z pozycjami dekretów w dwóch układach: 24 i 280 kolumn.
Listę możliwych decyzji i odbiorców wyznaczają procedury Oracle — te same, co w wersji desktopowej.
Podgląd załącznika w dzielonym widoku z przesuwanym uchwytem. Tekst zaznacza się bezpośrednio na dokumencie.
Rejestracja przychodzącej korespondencji i praca na liście pism pogrupowanych po dniach.
Konta domenowe (AD/LDAP) z fallbackiem do Oracle, opcjonalnie SSO Kerberos. Cookie powstaje dopiero po jednorazowym bilecie z weryfikacji hasła.
Sprawdzam, co siedzi w procedurach Oracle i co da się zostawić nietknięte. Zwykle jest to większość logiki obiegu.
Buduję warstwę webową na tych samych procedurach. Reguły decyzji i odbiorców zostają tam, gdzie były.
Nowy interfejs działa obok starego na tych samych danych. Zespół przechodzi wtedy, kiedy jest gotowy, nie w wyznaczony piątek.
Po okresie równoległym wersja desktopowa zostaje wyłączona. Historia dokumentów zostaje w całości.
To projekt liczony w miesiącach, nie w tygodniach — ale liczony od interfejsu, a nie od nowego systemu. Reguły biznesowe nie są przepisywane, więc nie ma etapu, w którym trzeba je odtworzyć z pamięci.
Zastępuje desktopową część obiegu, zachowując procedury i schemat bazy Impulsa.
FAQ
Tak. To ten sam system — Impuls EVO jest dziś sprzedawany jako BPSC ERP, a fundament jest wspólny: baza Oracle i logika w .NET. Rozwiązanie dopasowuję do wersji i konfiguracji, którą masz u siebie.
Zależy od zakresu i od tego, co po Twojej stronie jest już gotowe. Drobne modyfikacje to kwestia dni, integracje i aplikacje — tygodni. Konkretny termin podaję na etapie wyceny, zanim cokolwiek ruszy.
Tak — to jeden z głównych priorytetów przy modyfikacjach rdzenia. Prowadzę je tak, żeby były odporne na kolejne aktualizacje Impuls EVO / BPSC ERP. Szerzej opisuję to w artykule Jak modyfikować Impuls EVO, żeby zmiany przetrwały aktualizacje systemu.
Twój. Rozwiązania robione na Twoje zlecenie przekazuję wraz z kodem źródłowym i prawami, zgodnie z umową.
Tak. Wdrożenie to nie koniec — zostaję do dyspozycji przy poprawkach i kolejnych zmianach, w miarę jak zmieniają się Twoje procesy.
Nie ma tu Twojego pytania? Zadaj je — odpowiadam też wtedy, gdy nic z tego nie wynika. Formularz jest tutaj albo napisz wprost na kontakt@bartoszolchowik.pl.
Paragony ze stacji zamieniane w faktury zbiorcze.
Narzędzie do agregacji paragonów w faktury: zaznaczasz paragony ze sprzedaży stacyjnej, powstaje z nich faktura zbiorcza. Obok kartoteki kontrahentów z GUS i Białą Listą oraz środki trwałe.
Operator stacji wpisuje ceny, a strona porównuje je z poprzednimi i przekazuje dalej.
Kilkaset pozycji z arkusza w systemie sprzedaży tego samego dnia.
Arkusz Excel zamieniony na plik CSV gotowy do wczytania w NoviCloud, z nadaniem kodów towarów, dopasowaniem kategorii i raportem błędów.