OPIS PRZEDMIOTU ZAMÓWIENIA Założenia podstawowe systemu B2B Projekt polegał będzie na stworzeniu i zintegrowaniu nowoczesnego systemu finansowo-księgowego, który umożliwiał będzie zarówno objęcie nim dowolnej formy ewidencji księgowej, jak i dostosowanie go do indywidualnych wymogów (w tym potrzeb podmiotów zagranicznych i ich krajowego ustawodawstwa), a następnie zintegrowaniu go z systemami Partnerów i własnymi służącymi do: a) generowania informacji zarządczej (system Partnera) typu business intelligence, b) zarządzania komunikacją biznesową (system Partnera oraz własny) c) obsługi projektowo-rozliczeniowej rynku deweloperskiego (system Partnera). W wyniku połączenia tych systemów powstaną dwa rozwiązania działające w chmurze (cloud computing): 1) pierwsze rozwiązanie stanowiące połączenie raportowania busienss intelligence z systemem finansowo-księgowym - rozwiązanie dające zaawansowane narzędzie do zarządzania rentownością, płynnością, informacją zarządczą i ewidencją księgowo-podatkową oraz 2) drugie rozwiązanie - rozwiązanie analogiczne jak powyżej dedykowane dla branży developerskiej. Główne cele projektowanego systemu finansowo-księgowego to: a) uporządkowanie i organizacja obiegu dokumentów, w tym wielopoziomowej weryfikacji, b) automatyzacja księgowania dokumentów, c) automatyzacja komunikacji z Partnerami poprzez przyjmowanie dokumentów i danych wejściowych oraz automatyczne wysyłanie informacji, rozliczeń, wiadomości, d) umożliwienie śledzenia dokumentów i uzyskania szczegółowych raportów dotyczących dokumentów, e) umożliwienie łatwego dostępu do wszystkich danych księgowych za pomocą Internetu. 1
Założenia funkcjonalne systemu B2B Procesy biznesowe objęte systemem B2B: 1. proces tworzenia rozwiązań wspólnych dla różnych form ewidencyjnych ( typu zakładanie kontrahenta) 2. proces księgowości pełnej 3. proces księgowości uproszczonej 4. proces księgowości zryczałtowanej Moduły księgowości odpowiadają wybranej przez Partnera formie opodatkowania: a) pełnej księgowości b) księgowości uproszczonej c) księgowości zryczałtowanej. Moduły Pełnej Księgowości, Księgowości Uproszczonej i Księgowości Zryczałtowanej powinny zapewnić współpracę z modułem Konfiguracji Klienta (w funkcjonalności Konfiguracji Partnera), z tą różnicą, że powinny uwzględniać uwarunkowania wynikające z wymagań odnoszących się do wskazanych typów księgowości. Moduły te będą obejmować procesy wprowadzania poszczególnych dokumentów księgowych, ich weryfikację oraz automatyczne księgowanie. 5. proces zarządzania dokumentami Moduł repozytorium powinien pozwolić na wyszukiwanie, śledzenie i agregację wszystkich procesów oraz dokumentów księgowych Partnera z zakresu świadczonych usług na podstawie zgromadzonych w Systemie dokumentów oraz uruchomionych procesów, według zadanych kryteriów. Repozytorium dokumentów będzie zapewniało do nich dostęp zgodnie z przypisanymi uprawnieniami dla poszczególnych grup użytkowników Systemu po stronie Partnera i Beneficjenta. Repozytorium Dokumentów ma być narzędziem służącym do zarządzania dokumentami - plikami i powiązanymi z nimi polami informacyjnymi. Przy czym poprzez dokument rozumie się nie tylko plik (załącznik), ale również całość atrybutów opisujących dokument Moduł repozytorium powinien w szczególności zapewnić realizację następujących użyteczności: a) obliczanie zobowiązań podatkowych i informowania o nich Partnera (po wyeksportowaniu widoku z listą dokumentów do pliku xls) b) przygotowanie wymaganych raportów finansowych przez pracowników 2
c) controlling i analizę finansową z możliwością uwzględniania filtrowania danych według założonych warunków. 6. proces konfiguracji Partnera (lub Klienta) przez Partnera 7. proces konfiguracji Partnera (lub Klienta) przez administratora Moduł powinien posiadać funkcjonalność pozwalającą na konfigurację Partnera. Użytkownik ma mieć możliwość zarządzania informacjami dotyczącymi firmy będącej Partnerem. Możliwe będzie konfigurowanie: a) Płatności b) Użytkowników c) Danych firmy d) Kontrahentów 8. proces zarządzania płatnościami System powinien realizować proces przygotowania listy niezrealizowanych zobowiązań i rejestracji dokonania płatności. System realizuje proces controllingu i analizy finansowej z możliwością uwzględniania filtrowania danych wg założonych warunków. Moduł Płatności wyświetla spis nierozliczonych faktur zakupu oraz dokumentów sprzedaży. Jest to lista faktur dokumentów Partnera, których status płatności nie został określony przez Partnera jako zapłacony. Moduł Płatności wyświetla wprowadzone ręcznie przez pracownika wartości następujących opłat: a) Podatek dochodowy - w zależności od formy opodatkowania PIT-5/5L PIT -4/8A Ryczałt CIT-2 b) Podatek VAT - dla płatników VAT c) Płatności ZUS Społeczne Zdrowotne FP i FGŚP Użytkownik powinien mieć możliwość wygenerowania do wydruku uzupełnionego formularza przelewu do wyżej wymienionych płatności. 3
9. proces raportowania systemowego Raporty dostępne będą wyłącznie dla Administratora oraz Kierownika. Moduł raportów systemowych powinien realizować proces weryfikacji i obliczania czasu wykorzystania Systemu przez pracowników, przeznaczonego na obsługę poszczególnych Partnerów. Dzięki zastosowaniu tego modułu Partner na podstawie zestawień czasu poświęcanego na obsługę swoich Partnerów będzie mógł ocenić rentowność każdego z obsługiwanych podmiotów. Moduł będzie również prezentował Dziennik Zdarzeń, w którym Administrator będzie miał dostęp przeglądu wszystkich akcji podejmowanych w systemie przez Księgowych i Kierowników w zakresie: a) Dodawania, edycji, usuwania, akceptacji, odrzucania i komentowania dokumentów b) Udzielania odpowiedzi Partnerom c) Zalogowanie do systemu d) Informacje te będą wyświetlane w formacie: e) Pracownik f) Data g) Godzina h) Partner i) Akcja W ramach tej funkcjonalności zakłada się, że System zapewniał będzie: a) Integrację zgodnie ze standardem xml/edi b) Gromadzenie i zabezpieczanie dokumentów z wykorzystaniem podpisu elektronicznego 10. funkcjonalność integracji (standard XML/EDI) Moduł ten powinien umożliwiać: a) szeroką parametryzację i pozwolić w krótkim czasie przystosować moduł do kolejnego formatu transferowego, b) definiowanie niestandardowych formatów wymiany informacji, c) przesyłanie przez Partnera do Systemu faktur wystawionych w formie elektronicznej (z systemów finansowych, magazynowych Partnera). d) dołączenie innych systemów nie obsługujących xml poprzez zastosowanie dodatkowych adapterów 4
11. funkcjonalność bezpieczny podpis elektroniczny Moduł ten powinien umożliwiać przechowywanie faktur w wersji elektronicznej i ich udostępnianie organom podatkowym oraz organom kontroli skarbowej dokonującym kontroli dokumentacji Partnerów, zgodnie z obowiązującymi przepisami prawa. Moduł umożliwia też potwierdzanie przekazywania dokumentów i/lub transferu danych między Partnerami lub między Partnerami a Klientami. 12. mobilny dostęp do systemu System powinien być dostępny dla Partnera również z poziomu urządzeń mobilnych (POA, Smartfony) i umożliwiać przynajmniej następujące funkcje: a) Przeglądanie Systemu: modułu księgowego, modułu repozytorium, modułu płatności, modułu konfiguracji Partnera, stron pomocy b) Akceptację dokumentów c) Odznaczanie zapłaconych faktur d) Komunikację z pracownikami poprzez wysłanie zapytania do Księgowego lub Kierownika 13. Zaawansowane raportowanie (funkcjonalność business inteligence) jako konsekwencja integracji systemów Tworzenie raportów na podstawie danych gromadzonych w innych systemach (w tym przypadku na bazie tworzonego systemu). Pozwala na przygotowywanie szablonów raportów w ramach których można wskazać dane potrzebne do raportu w oparciu o wykorzystanie zasad analogicznych jak przy tworzeniu baz danych. Również w formie pulpitu menedżerskiego, czyli danych wyświetlanych zainteresowanym i uprawnionym osobom. Podsumowując System B2B składać się będzie z następujących modułów: 1. moduł księgowości wspólnych dla różnych form ewidencyjnych 2. moduł księgowości pełnej 3. moduł księgowości uproszczonej 4. moduł księgowości zryczałtowanej 5. moduł repozytorium dokumentów 6. moduł konfiguracji Partnera (lub Klienta) przez Partnera 7. moduł konfiguracji Partnera (lub Klienta) przez administratora 8. moduł zarządzania płatnościami 5
9. moduł raportowania systemowego 10. funkcjonalność integracji (standard XMLlEDI) 11. funkcjonalność bezpieczny podpis elektroniczny 12. funkcjonalność wersja mobilna systemu Założenia techniczne systemu B2B Do budowy Sytemu B2B planuje się użycie technologii ASP.NET oraz bazy danych na MS SQL Server. Zewnętrzne biblioteki to m.in. EOPDF, jouery, jquery.ui. [PM]. System wspomagający obieg dokumentów księgowych oraz informacji z Partnerami powinien zostać stworzony w technologii Microsoft ASP.NET z dodatkowym użyciem technologii AJAX. Technologia ASP.NET - framework (szkielet budowy aplikacji) aplikacji internetowych stworzony przez Microsoft, służy do budowania dynamicznych stron internetowych, aplikacji internetowych i XML-owych usług sieciowych. ASP.NET jest częścią platformy.net i następcą technologii ASP. Jest oparty na CLR (Środowisko Uruchomieniowe Wspólnego Języka, w skrócie CLR), pozwalając programistom na używanie dowolnego języka dostępnego w platformie.net (na przykład CH/CLI, C#, J#, Delphi 8). Planowany System powinien wykorzystywać system zarządzania bazą danych, SQL Server (MS SOL), który jest rozpowszechniony przez korporację Microsoft. Jest to główny produkt bazodanowy tej firmy, który charakteryzuje się tym, iż jako język zapytań używany jest przede wszystkim Transact- SQL (czyli rozszerzenie języka SQL umożliwiające tworzenie konstrukcji takich jak pętle, instrukcje warunkowe oraz zmienne), który stanowi rozwinięcie standardu ANSI (American National Standards Institute instytucja ustalająca normy techniczne obowiązujące w USA)/ISO (Międzynarodowa Organizacja Normalizacyjna). Przygotowywanie i funkcjonowanie Systemu powinno opierać się na działaniu 3 oddzielnych serwerów, co zwiększa bezpieczeństwo realizowanych procesów programowania, pozwala na utrzymanie przejrzystości w budowie architektury systemu oraz pozwala na przyszłe modyfikowanie systemu. Wykorzystane powinny zostać następujące serwery: a) serwer aplikacyjny produkcyjny, b) aplikacyjny przedprodukcyjny, c) baz danych 6
Dzięki zastosowaniu wyżej opisanych technologii System będzie dostępny z każdego miejsca na świecie o dowolnym czasie z poziomu 3 urządzeń: a) przeglądarki internetowej, b) telefonu komórkowego, c) urządzenia przenośnego typu POA Interfejs wymiany danych Każde z wdrożonych rozwiązań informatycznych powinno zostać wyposażone zostanie również w uniwersalny interfejs komunikacyjny, mający umożliwić wymianę danych pomiędzy stosowanymi u Beneficjenta i Partnerów systemami informatycznymi. Interfejs ten powinien umożliwić pobieranie informacji specyficznych dla danego systemu źródłowego, np.: lista osób danego typu, dane osobowe, dane adresowe, dane finansowe, lista dokumentów danego typu, lista zadań, lista obiektów danego typu. Interfejsy komunikacyjne pozwolą także na wymianę plików danych, dokumentów tekstowych. W interfejsie powinna zostać zaprojektowana funkcja o ogólnej postaci, którą można będzie (na etapie integracji z danym systemem zewnętrznym) skonfigurować w dowolny sposób (tzn. do przekazywania zdefiniowanego zbioru atrybutów). Lista funkcji zawartych w tym interfejsie może wyglądać następująco: a) PobierzListeOsob(Typ) b) PobierzSzczegolyOsoby(ID) c) PobierzListeOokumentow(Typ) d) PobierzSzczegolyOokumentu(ID) e) PobierzListeObiektow(Typ) f) PobierzSzczegolyObiektu(ID) g) WysljListęObiektow(Typ) h). Celem EDl jest wyeliminowanie wielokrotnego wprowadzania danych oraz przyspieszenie i zwiększenie dokładności przepływu informacji dzięki połączeniu odpowiednich aplikacji komputerowych między firmami uczestniczącymi w wymianie. Użycie EDl pozwala poprawić czasową dostępność informacji i zmniejszyć pracochłonność procesu. Systemy biorące udział w wymianie danych będą komunikowały się przez paczki komunikatów o ustalonej strukturze. Ze względu na 7
niedostępność komunikatów EDIFACT w obecnej strukturze teleinformacyjnej przedsiębiorstwa, zdecydowano się na wybór komunikatów w formacie SOAP/XML lub CSV, UTF8, wspieranym przez wszystkie kluczowe systemy, które będą brały udział w wymianie danych. Medium wymiany komunikatów może być protokół SFTP, FTP, HTTPS, HTTP lub inny równoważny. Format wymiany danych pomiędzy systemami obejmuje dowolną ilość komunikatów przekazywanych w formacie SOAP/XML lub CSV, UTF8, z nazwami pól w pierwszym wierszu i datami w formacie ISO YYYYMMDD. Wszystkie komunikaty podlegają logowaniu w postaci plików. Każdy komunikat jest jedną linią w pliku wymiany, z rozkodowanymi słownikami i identyfikatorami własnymi służącymi do synchronizacji danych. Kolejność pól komunikatu może być dowolna i musi się zgadzać z kolejnością pól w nagłówku komunikatu. Sprawdzenie poprawności danych i eskalowanie informacji o błędach należy do systemu odbierającego dane. Tym samym zaprojektowany interfejs powinien być równoważny z rozwiązaniami EDI/EDIFACT (standardu najczęściej stosowanego w UE), czyli powinien przekazywać dane o określonej strukturze, poprzez uzgodnione standardowe komunikaty, z jednej aplikacji komputerowej do drugiej, środkami elektronicznymi, bez lub z minimalną interwencją człowieka. Przy projektowaniu finalnego rozwiązania pod uwagę powinny być brane stosowne normy: a) podstawowa norma UN/EDIFACT - zasady składni, które zostały przyjęte także przez Międzynarodową Organizację Standardów ISO jako norma ISO 9735.CEN (Europejski Komitet Normalizacji) przyjął ją jako normę europejską EN 29735, b) Polska Norma PN-90/T-20091 - Elektroniczna Wymiana Danych dla Administracji, Handlu i Transportu (EDIFACT) - zasady składni dla warstwy zastosowań. Podpis elektroniczny W celu realizacji funkcjonalności bezpiecznego podpisu elektronicznego powinna zostać zainstalowana na serwerze aplikacyjnym usługa wystawcy certyfikatów jako "autonomiczny główny urząd certyfikacji". Za pomocą tej usługi będą wystawiane certyfikaty dla użytkowników portalu. Każdy użytkownik operujący na stacji roboczej, z której łączy się z portalem zobligowany zostanie do zainstalowania otrzymanego certyfikatu oraz dodania certyfikatu głównego urzędu certyfikacji. Na stacji roboczej zostanie także zainstalowany komponent CAPI COM firmy Microsoft, za pomocą którego przeprowadzana będzie procedura elektronicznego podpisywania danych oraz weryfikacja podpisów elektronicznych. 8
W przypadku takiej potrzeby (na żądanie Partnerów lub Klientów) można zastosować rozwiązanie alternatywne lub uzupełniające w postaci mobilnej. Innowacyjność wdrożenia Polkomtel, MobiCert i MobiTrust to przede wszystkim sama implementacja techniczna, oraz kwestie organizacyjne, związane z dystrybucją certyfikatów. Sama architektura mobilnego podpisu jest opisana obszernie w literaturze fachowej i uznanych standardach. Bezpieczeństwem urządzeń do składania podpisu elektronicznego zajmuje się znany wszystkim specjalistom w tej dziedzinie dokument CWA 14355 ("Guidelines for the implementation ot Secure Signature-Creation Oevices" - dokument European Committee For Standardization - Europejski Komitet Normalizacyjny, CEN w 2004). W dokumencie tym - mającym charakter rekomendacji - urządzenia oparte o telefon komórkowy są traktowane jak każde inne urządzenie do składania podpisu elektronicznego i ich bezpieczeństwo jest szczegółowo analizowane. W przypadku mobilnego podpisu usługi te są zdefiniowane przez standardy opracowane z kolei przez Europejski Instytut Standardów Telekomunikacji (ETSI), a konkretnie przez standardy z grupy "Mobile Signature Service" (ETSI TS 102 204 oraz TR 102 206). W Mobilnym epodpisie nie zmienia się rola klucza prywatnego - nadal jest on generowany i przechowywany w karcie kryptograficznej, zaś poświadczeniem certyfikatu zajmuje się kwalifikowane centrum certyfikacji. W tym zakresie dostawcą usług certyfikacyjnych dla Mobitrust jest MobiCert. Podpisany dokument jest wysyłany do instytucji publikującej formularz automatycznie. Następnie może ona udostępnić na tej samej stronie np. poświadczenie odbioru, formularz płatności lub inne dane przewidziane w procesie biznesowym. 9