Kielce, dnia roku. HB Technology Hubert Szczukiewicz ul. Kujawska 26 / Kielce

Transkrypt

1 Kielce, dnia roku HB Technology Hubert Szczukiewicz ul. Kujawska 26 / Kielce Tytuł Projektu: Wdrożenie innowacyjnego systemu dystrybucji usług cyfrowych, poszerzenie kanałów sprzedaży i stworzenie usystematyzowanych protokołów wymiany danych w procesach biznesowych pomiędzy firmą HB TECHNOLOGY a jej Partnerami. Nr umowy: UDA-POIG /10-00 Załącznik nr 2 do Zapytania Ofertowego z dnia r. Tytuł Załącznika: Określenie zakresu reinżynierii procesów biznesowych zachodzących za pomocą automatycznej wymiany danych cyfrowych (EDI) przy wykorzystaniu Platformy Usługowej. Strona: 1

2 1. Słownik wykorzystanych pojęć i skrótów Źródła Wstęp Cel dokumentu Metodologia Specyfikacja procesów biznesowych wykorzystujących interfejs pomiędzy Platformą Usługową a systemami informatycznymi partnerów w celu dostosowania ich do automatycznej wymiany danych cyfrowych (EDI) Wstęp Proces 1 Odsprzedaż (Re-selling) usług cyfrowych świadczonych przez Platformę Usługową dla Partnerów Opis procesu Diagram procesu Kroki procesu związane z wymianą danych EDI Proces 2 Świadczenie usług cyfrowych na Platformie Usługowej Opis procesu Diagram procesu Kroki procesu związane z wymianą danych EDI Proces 3 Dokonywanie płatności za pośrednictwem Platformy Usługowej Opis procesu Diagram procesu Kroki procesu związane z wymianą danych EDI Proces 4 Wysyłanie okresowych zestawień i powiadomień do Partnerów przez Platformę Usługową Opis procesu Diagram procesu Kroki procesu związane z wymianą danych EDI Proces 5 Modyfikacja usług cyfrowych świadczonych przez Platformę Usługową Opis procesu Diagram procesu...36 Strona: 2

3 Kroki procesu związane z wymianą danych EDI Proces 6 Wycofanie/wprowadzenie usług cyfrowych świadczonych przez Platformę Usługową Opis procesu Diagram procesu Kroki procesu związane z wymianą danych EDI Analiza istniejących implementacji standardu EDI wykorzystywanych w Polsce i rekomendacja jednej z nich na potrzeby Platformy Usługowej Wstęp Integracja w standardzie EANCOM/EDIFACT Standard EANCOM/EDIFACT Struktura komunikatów EANCOM/EDIFACT Struktura wiadomości Struktura segmentu Komunikaty EANCOM/EDIFACT i kody GS Wiadomość PARTIN Wiadomość PRICAT Dokument faktury Wiadomość COMDIS Wiadomość CORINV Wiadomość CONFIRMATION CORRECTING INVOICE Wiadomość REMADV Integracja bezpośrednia Uwarunkowania prawne Koszty eksploatacji Zakres przesyłanych danych Integracja za pośrednictwem brokera EDI w standardzie EANCOM/EDIFACT Uwarunkowania prawne Koszty eksploatacji...60 Strona: 3

4 Zakres przesyłanych danych Integracja w standardzie XML ebxml oraz UBL GS1 XML XML/EDIFACT Rozwiązania producenckie Integracja bezpośrednia Uwarunkowania prawne Koszty eksploatacji Zakres przesyłanych danych Integracja za pośrednictwem brokera EDI Uwarunkowania prawne Koszty eksploatacji Zakres przesyłanych danych Rekomendacja implementacji standardu EDI w ramach Platformy Usługowej Podsumowanie zakresu danych Podział zakresu danych z punktu widzenia automatyzacji procesów biznesowych Podział zakresu danych z punktu widzenia możliwości przetwarzania w systemach informatycznych Zakres danych a standardowe komunikaty EDI Rekomendacja typów interfejsów dla poszczególnych zakresów danych Szczegółowa specyfikacja interfejsów udostępnianych przez Platformę Usługową do integracji z systemami informatycznymi partnerów Wstęp Interfejs WebServices/SOAP Technologia wykonania interfejsu Opis korzystania z interfejsu Metody uwierzytelniania klientów interfejsu Metody zabezpieczenia komunikacji przy wykorzystaniu interfejsu...90 Strona: 4

5 6.3. Interfejs Web/HTML Technologia wykonania interfejsu Opis korzystania z interfejsu Metody uwierzytelniania klientów interfejsu Metody zabezpieczenia komunikacji przy wykorzystaniu interfejsu Interfejs Technologia wykonania interfejsu Opis korzystania z interfejsu Metody uwierzytelniania klientów interfejsu Metody zabezpieczenia komunikacji przy wykorzystaniu interfejsu Określenie pełnego modelu wymiany danych cyfrowych w standardzie EDI dla zidentyfikowanych obszarów i procesów biznesowych realizowanych za pomocą udostępnianych za pomocą Platformy Usługowej interfejsów Wstęp Typy danych Typy obiektów Credentials Definicja typu Opis ResultStatus Definicja typu Opis InvoiceInfo Definicja typu Opis InvoiceInfoList Definicja typu Opis InvoiceConfirmationInfo...98 Strona: 5

6 Definicja typu Opis InvoiceConfirmationInfoList Definicja typu Opis InvoiceDocument Definicja typu Opis Invoice Definicja typu Opis InvoicesList Definicja typu Opis Informacje o kliencie (ClientInformation) Informacja o modyfikacji klienta (ClientModificationInformation) Informacje o doładowaniu (TopupInformation) Informacje o połączeniu (CDR) Zestawienie połączeń (BillingInformation) Informacja o niezapłaconych fakturach (OutstandingInvoiceInformation) Wykorzystanie środków pieniężnych (BalanceInformation) Informacje o modyfikowanej usłudze (ModifyServiceInformation) Informacje o nowej usłudze (NewServiceInformation) Informacje o usuwanej usłudze (DeleteServiceInformation) Operacje interfejs WebService/SOAP Operacja getcurrentinvoiceslist Dane wejściowe operacji (nazwa parametru, typ parametru, opis biznesowy parametry) 117 Strona: 6

7 Dane wyjściowe operacji (szczegółowy opis struktur danych zwracanych przez operacje interfejsu) Zachowanie w przypadku wystąpienia błędów Operacja gethistoricalinvoiceslist Dane wejściowe operacji (nazwa parametru, typ parametru, opis biznesowy parametry) Dane wyjściowe operacji (szczegółowy opis struktur danych zwracanych przez operacje interfejsu) Zachowanie w przypadku wystąpienia błędów Operacja confirmcurrentinvoice Dane wejściowe operacji (nazwa parametru, typ parametru, opis biznesowy parametry) Dane wyjściowe operacji (szczegółowy opis struktur danych zwracanych przez operacje interfejsu) Zachowanie w przypadku wystąpienia błędów Operacja getinvoices Dane wejściowe operacji (nazwa parametru, typ parametru, opis biznesowy parametry) Dane wyjściowe operacji (szczegółowy opis struktur danych zwracanych przez operacje interfejsu) Zachowanie w przypadku wystąpienia błędów Definicja dowiązań SOAP Definicja usługi sieciowej Operacje interfejs Web/HTML Powiadomienie o rejestracji nowego klienta Partnera Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o doładowaniu konta przez klienta Partnera Dane wejściowe operacji Dane wyjściowe operacji Strona: 7

8 Udostępnienie faktury wystawionej po doładowaniu konta klienta Partnera Dane wejściowe operacji Dane wyjściowe operacji Udostępnienie zestawienia wykonanych połączeń Dane wejściowe operacji Dane wyjściowe operacji Udostępnienie faktury za wykorzystane usługi Dane wejściowe operacji Dane wyjściowe operacji Udostępnienie faktury za wykonane połączenia Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o aktualnym wykorzystaniu środków pieniężnych Platformy Resellerskiej Partnera Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o planowanej modyfikacji istniejącej usługi Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o planowanym wprowadzeniu/usunięciu usługi Dane wejściowe operacji Dane wyjściowe operacji Operacje interfejs Powiadomienie o rejestracji nowego klienta Partnera Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o doładowaniu konta przez klienta Partnera Dane wejściowe operacji Dane wyjściowe operacji Strona: 8

9 Udostępnienie zestawienia wykonanych połączeń Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o aktualnym wykorzystaniu środków pieniężnych Platformy Resellerskiej Partnera Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o planowanej modyfikacji istniejącej usługi Dane wejściowe operacji Dane wyjściowe operacji Powiadomienie o planowanym wprowadzeniu/usunięciu usługi Dane wejściowe operacji Dane wyjściowe operacji Określenie wymagań niefunkcjonalnych dla komponentów integracyjnych Platformy Usługowej z punktu widzenia obowiązujących przepisów prawnych i rozporządzeń w zakresie elektronicznego obiegu dokumentów EDI Wymagania formalne Zgody i akceptacje Elektroniczna Wymiana Danych EDI Umowa o EDI Załącznik techniczny Faktury przesyłane drogą elektroniczną Pozyskanie identyfikatorów Wymagania odnośnie do okresu przechowywania Faktury Pozostałe dokumenty Wymagania odnośnie do tworzenia kopii zapasowych Strona: 9

10 1. Słownik wykorzystanych pojęć i skrótów Poniżej znajduje się wyjaśnienie występujących w dokumencie skrótów i pojęć: EDI Eletronic Data Interchange oznacza elektroniczną wymianę danych pomiędzy systemami informatycznymi współpracujących ze sobą przedsiębiorstw UN/EDIFACT standard EDI zawierający definicję ponad 400 komunikatów biznesowych. Standard UN/EDIFACT definiuje także zasady składni komunikatów w wymianie danych. UN/EANCOM standard EDI zawierający uzgodniony podzbiór komunikatów UN/EDIFACT zatwierdzony przez organizację GS1 ANSI X12 standard EDI, obecnie wykorzystujący język XML ebxml e-business XML standard EDI wykorzystujący język XML zatwierdzony przez organizację OASIS UBL Universal Business Language standard komunikatów EDI wykorzystujący język XML zatwierdzony przez organizację OASIS ecom standard EDI zatwierdzony przez organizację GS1 opisujący zasady wymiany komunikatów GS1 XML standard EDI zatwierdzony przez organizację GS1 zawierający definicje komunikatów biznesowych w języku XML RosettaNet standard EDI wykorzystujący język XML wykorzystywany w branży elektronicznej HB Technology - HB Technology Hubert Szczukiewicz Platforma Usługowa, PU - Rozwiązanie informatyczne o charakterze sprzętowoprogramowym umożliwiające partnerom HB Technology odsprzedaż na rzecz swoich klientów usług świadczonych przez HB Technology Moduł resellerski wydzielony logicznie, odrębny fragment Platformy Usługowej przeznaczony do świadczenia i zarządzania usługami określonego Partnera HB Technology Post-paid - Model rozliczeń, w którym płatności za usługi realizowane są z dołu, na podstawie wykazu wykonanych usług Strona: 10

11 Pre-paid - Model rozliczeń, w którym płatności za usługi realizowane są z góry, tj. w celu skorzystania z usługi, klient musi w pierwszej kolejności zasilić swoje konto przy pomocy dostępnych przez usługodawcę form płatności. Konto obciążane jest w czasie rzeczywistym zgodnie z cennikiem usług. IVR - Interactive Voice Response - system telekomunikacyjny umożliwiający interaktywną obsługę osoby dzwoniącej. System odczytuje użytkownikowi zapowiedzi głosowe, natomiast użytkownik dokonuje wyboru za pośrednictwem klawiszy w swoim telefonie (kody DTMF) lub za pomocą komend głosowych. System IVR wykorzystuje usługi sieci inteligentnej. http - Hypertext Transfer Protocol protokół przesyłania dokumentów hipertekstowych to protokół sieci WWW. Za pomocą protokołu HTTP przesyła się żądania udostępnienia dokumentów WWW i informacje o kliknięciu odnośnika oraz informacje z formularzy. Zadaniem stron WWW jest publikowanie informacji natomiast protokół HTTP właśnie to umożliwia. XML - Extensible Markup Language, w wolnym tłumaczeniu Rozszerzalny Język Znaczników uniwersalny język formalny przeznaczony do reprezentowania różnych danych w strukturalizowany sposób. Web Services - Usługa internetowa usługa świadczona poprzez sieć telekomunikacyjną, a w tym sieć komputerową, w szczególności przez Internet. Usługa internetowa jest w istocie składnikiem oprogramowania, niezależnym od platformy sprzętowej oraz implementacji, dostarczającym określonej funkcjonalności. Dane przekazywane są zazwyczaj za pomocą protokołu HTTP i z wykorzystaniem XML. API - Application Programming Interface, interfejs programowania aplikacji jest to sposób, rozumiany jako ściśle określony zestaw reguł i ich opisów, w jaki programy komunikują się między sobą. API definiuje się na poziomie kodu źródłowego dla takich składników oprogramowania jak np. aplikacje, biblioteki czy system operacyjny. Zadaniem API jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych. URL - Uniform Resource Locator oznacza ujednolicony format adresowania zasobów (informacji, danych, usług) stosowany w Internecie i w sieciach lokalnych. URL najczęściej kojarzony jest z adresami stron WWW, ale ten format adresowania służy do identyfikowania wszelkich zasobów dostępnych w Internecie. Strona: 11

12 TLS - Transport Layer Security przyjęte jako standard w Internecie rozwinięcie protokołu SSL (ang. Secure Socket Layer), zaprojektowanego pierwotnie przez Netscape Communications Corporation. TLS zapewnia poufność i integralność transmisji danych, a także uwierzytelnienie serwera, a niekiedy również klienta Strona: 12

13 2. Źródła Analiza Biznesowa i Funkcjonalna dla Platformy Usługowej Rozporządzenie Ministra Finansów z dnia 17 grudnia 2010 r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej Strona: 13

14 3. Wstęp 3.1. Cel dokumentu Celem niniejszego dokumentu jest określenie zakresu i sposobu wymiany danych pomiędzy Platformą Usługową a systemami informatycznymi partnerów HB Technology. Platforma Usługowa projektowana przez HB Technology oprócz swej roli jaką odgrywa z punktu widzenia użytkowników końcowych konsumentów usług jest także innowacyjnym przedsięwzięciem w zakresie relacji B2B. W założeniach będzie ona umożliwiać utrwalanie a także nawiązywanie nowych relacji pomiędzy HB Technology a Partnerami w oparciu o nowoczesny model biznesowy opierający się na hurtowej odsprzedaży usług komunikacyjnych świadczonych na platformie usługowej. Innowacyjność i atrakcyjność oferowanych usług jest tylko jednym z czynników warunkujących sukces przedsięwzięcia zarówno z punktu widzenia HB Technology jak i Partnerów. Równie ważne jest zapewnienie optymalnego przebiegu procesów biznesowych, w które zaangażowane są obie strony jak i wsparcie tych procesów przez współpracę systemów informatycznych. Systemy informatyczne umożliwiają automatyzację procesów biznesowych a także zmniejszają ryzyko występowania błędów wymagających uruchamiania procedur wyjaśniających i korygujących. W praktyce, wykorzystanie systemów informatycznych będzie zarówno dla HB Technology jak i dla jego Partnerów oznaczać możliwość koncentracji uwagi na kluczowych aspektach funkcjonowania swych przedsiębiorstw dzięki ograniczeniu do minimum czynności związanych z zarządzaniem oraz rozliczaniem. Ogólnie przyjętym standardem do komunikacji B2B pomiędzy partnerami biznesowymi jest EDI (Electronic Document Interchange) czyli Elektroniczna Wymiana Danych/Dokumentów. Elektroniczna wymiana danych w rozumieniu EDI jest to elektroniczna transmisja, z komputera do komputera, danych o komercyjnym i administracyjnym charakterze, z wykorzystaniem ustalonego standardu, który określa strukturę komunikatu EDI. Najpopularniejszym standardem komunikatów EDI jest standard UN/Edifact rozwijany pod patronatem Organizacji Narodów Zjednoczonych. W ramach standardu UN/Edifact zdefiniowanych zostało ponad 400 typów komunikatów obejmujących takie dziedziny jak: Handel Transport Strona: 14

15 Cło Bankowość Projektowanie Statystyka Ubezpieczenia Służba zdrowia Administracja Turystyka Standard UN/Edifact został znormalizowany pod normą ISO W Polsce rozwojem standardu EDI zajmuje się przede wszystkim Grupa Robocza EDI przy ECR Polska. Zespół ten zajmuje się ujednolicaniem i uzgadnianiem postaci komunikatów EDI stosowanych w transakcjach handlowych między dostawcami a sieciami handlowymi. Oprócz wymienionych wyżej organizacji, technologie EDI promowane i rozwijane są niezależnie przez operatorów EDI, tj. organizacje udostępniające klientom platformy B2B, najczęściej zintegrowane z systemami informatycznymi ERP i F/K produkowanymi przez te organizacje. Przykładem takiej organizacji jest firma Comarch, która udostępnia platformę Comarch EDI (dawniej ECOD) a także oprogramowanie ERP i F/K pod nazwą Comarch Optima. Organizacje, o których mowa najczęściej wykorzystują własne standardy EDI, w których komunikaty tworzone są w formacie XML, ze względu na powszechność stosowania tego standardu a także łatwość przetwarzania w systemach informatycznych. Z uwagi na fakt, że Platforma Usługowa na linii HB Technology Partnerzy jest platformą B2B, niezbędne jest zapewnienie elektronicznej wymiany danych pomiędzy tymi podmiotami. Niniejszy dokument zawiera specyfikację, wg której odbywać się będzie ta wymiana. Przy tworzeniu specyfikacji zostały uwzględnione poniższe czynniki: Wykorzystanie istniejących standardów EDI wszędzie tam, gdzie ma to uzasadnienie merytoryczne i ekonomiczne, Zapewnienie dla elektronicznej wymiany danych standardów bezpieczeństwa na poziomie wymaganym przez regulacje prawne związane z elektroniczną wymianą danych EDI, Strona: 15

16 Koszt wytworzenia i eksploatacji modułu elektronicznej wymiany danych Platformy Usługowej, Łatwość integracji pomiędzy Platformą Usługową a systemami informatycznymi Partnerów Metodologia Niniejszy dokument składa się, zgodnie z zapytaniem ofertowym, z następujących części: Specyfikacja procesów biznesowych wykorzystujących interfejs pomiędzy Platformą Usługową a systemami informatycznymi partnerów w celu dostosowania ich do automatycznej wymiany danych cyfrowych (EDI) o Opis procesu biznesowego o Diagram procesu biznesowego o Określenie kroków w procesach automatycznej wymiany danych EDI Platformą Usługową a systemami informatycznymi partnerów pomiędzy Analiza istniejących implementacji standardu EDI wykorzystywanych w Polsce i wybór jednego z nich na potrzeby Platformy Usługowej. Wybrana implementacja musi uwzględniać: o Uwarunkowania prawne o Koszt wytworzenia/korzystania o Zakres przesyłanych danych Szczegółowa specyfikacja interfejsów udostępnianych przez Platformę Usługową do integracji z systemami informatycznymi partnerów. Dla każdego udostępnianego interfejsu należy określić: o Technologię wykonania interfejsu o Opis korzystania z interfejsu o Metody uwierzytelniania klientów interfejsu o Metody zabezpieczenia komunikacji przy wykorzystaniu interfejsu Strona: 16

17 Określenie pełnego modelu wymiany danych w standardzie EDI dla zidentyfikowanych obszarów biznesowych realizowanych za pomocą udostępnianych interfejsów. Opis musi uwzględniać listę i opis udostępnianych operacji: o Dane wejściowe operacji (nazwa parametru, typ parametru, opis biznesowy parametry) o Dane wyjściowe operacji (szczegółowy opis struktur danych zwracanych przez operacje interfejsu) o Zachowanie w przypadku wystąpienia błędów Określenie wymagań niefunkcjonalnych dla komponentów integracyjnych Platformy Usługowej z punktu widzenia obowiązujących przepisów prawnych i rozporządzeń w zakresie elektronicznego obiegu dokumentów EDI. Strona: 17

18 4. Specyfikacja procesów biznesowych wykorzystujących interfejs pomiędzy Platformą Usługową a systemami informatycznymi partnerów w celu dostosowania ich do automatycznej wymiany danych cyfrowych (EDI) 4.1. Wstęp W niniejszym rozdziale zidentyfikowano procesy biznesowe zachodzące pomiędzy HB Technology a Partnerami, w których zachodzić będzie automatyczna wymiana danych pomiędzy systemami informatycznymi tych podmiotów. Głównym celem tej analizy jest określenie zakresu danych wymienianych w tych procesach. Zidentyfikowany zakres danych zostanie wykorzystany do określenia metod elektronicznej wymiany danych jakie zostaną zaimplementowane na Platformie Usługowej w odniesieniu do wszystkich danych bądź poszczególnych ich części Proces 1 Odsprzedaż (Re-selling) usług cyfrowych świadczonych przez Platformę Usługową dla Partnerów Opis procesu Pierwszym i podstawowym procesem biznesowym, który musi zostać zrealizowany w celu umożliwienia współpracy pomiędzy HB Technology a Partnerem w zakresie odsprzedaży usług cyfrowych świadczonych przez Platformę Usługową jest zawarcie umowy i uruchomienie tzw. modułu resellerskiego, czyli wydzielonego logicznie lub/i fizycznie fragmentu Platformy Usługowej przeznaczonego do świadczenia usług dla klientów końcowych Partnerów oraz zarządzania tymi usługami. Proces odsprzedaży zawiera wszystkie czynności, których wykonanie jest niezbędne do uzyskania przez Partnera gotowości do odsprzedaży usług na rzecz swoich klientów oraz do poprawnego świadczenia oraz rozliczania tych usług przez HB Technology. Diagram procesu został zaprezentowany w kolejnym podrozdziale. Poniżej znajduje się opis poszczególnych kroków procesu. Tabela. 1. Opis kroków procesu odsprzedaży usług na Platformie Usługowej Lp. azwa kroku/aktywności Opis Strona: 18

19 1 Pozyskanie nowego Partnera HB Technology w ramach działań marketingowych a także w oparciu o sieć istniejących Partnerów pozyskuje do współpracy Partnera 2 Podpisanie umowy HB Technology i Partner podpisują umowę o współpracy określającą zasady na jakich odbywać się będzie odsprzedaż, świadczenie oraz rozliczanie usług 3 Pozyskanie domeny W celu konfiguracji modułu resellerskiego udostępnianego przez HB Technology na Platformie Usługowej Partner powinien pozyskać domenę internetową, w której uruchomiona zostanie część usługowa oraz administracyjna modułu resellerskiego 4 Pozyskanie certyfikatu SSL W celu konfiguracji modułu resellerskiego udostępnianego przez HB Technology na Platformie Usługowej, Partner powinien pozyskać certyfikat SSL, którym zabezepieczony będzie dostęp jego klientów do modułu zarządzania usługami (tzw. panelu klienta). Powinien być to certyfikowany kwalifikowany, tj. zapewniający klientom Partnera pewność co do autentyczności właściciela serwisu 5 Konfiguracja modułu resellerskiego 6 Konfiguracja modułu EDI przy systemie F/K HB Technology, po podpisaniu umowy oraz pozyskaniu przez Partnera niezbędnych komponentów technologicznych konfiguruje na Platformie Usługowej dedykowany moduł resellerski dla Partnera. W ramach modułu resellerskiego udostępniane są Partnerowi zasoby Platformy Usługowej niezbędne do świadczenia usług, panel administracyjny służący do zarządzania tymi zasobami oraz klientami Partnera a także panel kliencki przeznaczony dla klientów Partnera W ramach przygotowań do uruchomienia, Partner powinien skonfigurować po stronie swoich systemów informatycznych (finansowo-księgowych) niezbędne interfejsy w celu zapewnienia elektronicznej wymiany danych z Platformą Usługową Strona: 19

20 7 Testy W ramach testów przeprowadzane są testy: Działania usług dla klientów końcowych Działania interfejsów administracyjnych i zarządzania Poprawnego naliczania opłat za usługi Poprawnej wymiany danych pomiędzy systemami HB Technology oraz Partnera W szczególności, w ramach testów przeprowadzone zostaną testy automatycznej wymiany danych, zgodnie ze zdefiniowanym interfejsem pomiędzy Platformą Usługową a systemami Partnera 8 Testy modułu EDI Przeprowadzone zostaną testy wszystkich przepływów danych pomiędzy Platformą Usługową a systemami informatycznymi Partnera zakres danych i przypadków użycia testowanych w ramach tej czynności będzie zgodny ze specyfikacją interfejsów określonych w niniejszym dokumencie dla poszczególnych procesów biznesowych 9 Uruchomienie produkcyjne Po przeprowadzeniu testów i weryfikacji poprawności działania modułu resellerskiego oraz mechanizmów wymiany danych, moduł resellerski przechodzi do fazy produkcyjnej, w której Partner uzyskuje gotowość do rejestracji nowych klientów oraz odsprzedaży na ich rzecz usług świadczonych na Platformie Usługowej Diagram procesu Strona: 20

21 act Odsprzedaż usług HB Technology Partner Start Podpisanie umowy Pozyskanie now ego Partnera do współpracy, przygotowanie umowy Pozyskanie domeny Pozyskanie certyfikatu SSL Konfiguracja modułu EDI przy systemie F/K Konfiguracja modułu resellerskiego Testy modułu EDI Testy Uruchomienie produkcyjne Koniec Schemat 1. Proces odsprzedaży usług na Platformie Usługowej Kroki procesu związane z wymianą danych EDI Poniższe kroki procesu związane są z wymianą danych EDI: Testy modułu EDI w ramach testów wymieniane będą wszystkie dane we wszystkich przepływach procesów, które zachodzić będą po uruchomieniu modułu resellerskiego. Procesy te i dane określone są w dalszej części niniejszego dokumentu Proces 2 Świadczenie usług cyfrowych na Platformie Usługowej Opis procesu Świadczenie usług cyfrowych na Platformie Usługowej składa się z kilku niezależnych podprocesów. Rozpoczyna się ono z chwilą udanej rejestracji klienta w module resellerskim Partnera. Po udanej rejestracji, użytkownik może, pod warunkiem, że posiada na koncie wystarczające środki, rozpocząć korzystanie z usług może wykonywać połączenia telefoniczne oraz konfigurować i korzystać z usług dodanych. Powiadomienia wysyłane do systemów informatycznych Partnera mogą być zgodnie z podprocesem rejestracji wysyłane także na etapie realizacji innych procesów związanych z kontem klienta, takich jak: Modyfikacja danych konta klienta Usunięcie konta klienta Poniżej znajduje się opis kroków związanych z tym podprocesem rejestracji: Strona: 21

22 Tabela. 2. Opis kroków procesu świadczenia usług na Platformie Usługowej - rejestracja Lp. azwa kroku/aktywności Opis 1 Rejestracja nowego Klienta na Platformie Usługowej Klient, za pośrednictwem witryny Partnera wypełnia formularz rejestracyjny. Podaje swoje podstawowe dane a także dokonuje wyboru podstawowych opcji związanych z usługą (np. numer telefonu) 2 Weryfikacja konta Platforma Usługowa w pierwszej kolejności sprawdza czy dane służące do identyfikacji klienta (adres , pesel, nip, etc.) znajdują się już w bazie danych. Na tym etapie dane klienta przechowywane są w obszarze danych tymczasowych konto klienta nie jest jeszcze tworzone. Jeżeli klient jest nowym klientem Partnera, na jego adres /telefon komórkowy wysyłana jest specjalna wiadomość weryfikacyjna. Klient musi wykorzystać te informacje do zweryfikowania swojej tożsamości wobec Partnera. 3 Utworzenie konta Klienta w module resellerskim Partnera 4 Wysłanie powiadomienia o nowym kliencie Po pozytywnej weryfikacji, na Platformie Usługowej, a ściślej w module resellerskim Partnera tworzone jest nowe konto klienta. Do systemu informatycznego Partnera wysyłane jest powiadomienie o utworzeniu nowego konta klienta Tabela. 3. Opis kroków procesu świadczenia usług na Platformie Usługowej połączenia telefoniczne Lp. azwa kroku/aktywności Opis 1 Rozpoczęcie połączenia telefonicznego 2 Weryfikacja stanu konta klienta i wyznaczenie maksymalnego czasu trwania dla połączenia Klient jest zalogowany do swojego konta usługowego na Platformie Usługowej (konto SIP) i inicjuje połączenie wychodzące wybierając numer telefonu. Platforma Usługowa po otrzymaniu żądania wykonania połączenia sprawdza konfigurację biznesową usługi w tym przypadku weryfikowane jest to jaka jest opłata za Strona: 22

23 połączenie. Na tej podstawie wyliczany jest maksymalny czas połączenia na jaki pozwalają aktualne środki na koncie klienta. Jeżeli środki nie pozwalają na realizację połączenia, żądanie zestawienia połączenia jest odrzucane. 3 Zestawienie połączenia Po pozytywnej weryfikacji Platforma Usługowa zestawia połączenie wychodzące. 4 Aktualizacja salda klienta Połączenie kończy się albo w wyniku zakończenia rozmowy przez rozmówców albo po upływie wyznaczonego wcześniej maksymalnego czasu trwania rozmowy. Po zakończeniu rozmowy saldo klienta jest aktualizowane, tj. odejmowana od niego jest faktyczna opłata za zrealizowane połączenie. Tabela. 4. Opis kroków procesu świadczenia usług na Platformie Usługowej usługi dodane Lp. azwa kroku/aktywności Opis 1 Konfiguracja usługi dodanej (dodanie/przywrócenie) 2 Weryfikacja konfiguracji biznesowej Proces rozpoczyna się gdy klient konfiguruje/zamawia/wznawia usługę dodaną. Platforma Usługowa sprawdza, czy w związku z żądaniem klienta uruchomienia usługi dodanej powinna zostać pobrana opłata. 3 Weryfikacja stanu konta klienta W przypadku gdy opłata będzie pobierana, weryfikowane jest to, czy na koncie klienta znajdują się wystarczające środki. Jeżeli środki nie pozwalają na przeprowadzenie transakcji jest ona anulowana i usługa nie jest uruchamiana. 4 Aktualizacja salda Od salda konta klienta odejmowana jest kwota określona w konfiguracji usługowej usługi za korzystanie z niej przez określony okres czasu. 5 Aktywacja usługi Platforma Usługowa aktywuje dla klienta usługę dodaną. Od tej chwili użytkownik może z niej korzystać przez Strona: 23

24 określony w konfiguracji biznesowej usługi okres czasu. 6 Realizacja usługi W okresie kiedy usługa jest aktywna Platforma Usługowa realizuje wszystkie żądania związane z korzystaniem przez klienta z usługi 7 Deaktywacja usługi Konfiguracja biznesowa usługi określa okres ważności dla danej usługi dodanej. Po upływie tego okresu Platforma Usługowa automatycznie aktualizuje saldo na koncie klienta odejmując od niego kwotę za kolejny okres korzystania z usługi. Jeżeli na koncie nie ma wystarczających środków, usługa jest dezaktywowana. 8 Aktualizacja salda Automatyczne wznowienie usługi kończy się pobraniem z salda klienta opłaty za kolejny okres korzystania z usługi. Proces powtarzany jest cyklicznie każdorazowo po upływie aktualnego terminu ważności usługi Diagram procesu act Świadczenie usług HB Technology Partner Klient końcowy Start Rejestracja nowego klienta Partnera na platformie Weryfikacja konta Koniec [NIE] [TAK] Konto zweryfikowane? Wysłanie powiadomienia o nowym kliencie Utworzenie konta klienta Partnera Koniec Schemat 2. Proces świadczenia usług na Platformie Usługowej rejestracja Strona: 24

25 act Świadczenie usług - połączenia HB Technology Partner Klient końcowy Start Rozpoczęcie połączenia telefonicznego Weryfikacja stanu konta klienta i wyznaczenie maksymalnego czasu trwania dla połączenia Koniec [NIE] [TAK] Wystarczające środki? Zestawienie połączenia Zakończenie połączenia Upływ maksymalnego czasu połączenia Aktualizacja salda klienta Koniec Schemat 3. Proces świadczenia usług na Platformie Usługowej połączenia telefoniczne act Świadczenie usług - usługi dodane HB Technology Partner Klient końcowy Start Konfiguracj a usługi dodanej (dodanie/przywrócenie) Skorzystanie z usługi Koniec - usługa nie działa [NIE] Weryfikacj a stanu konta klienta [TAK] Czy wystarczające środki? Aktualizacj a salda [TAK] Weryfikacja konfiguracj i biznesowej Aktywacja usługi [NIE] Upływ okresu wznowienia usługi Realizacj a usługi Wystarczające środki na koncie? [NIE] [TAK] Deaktywacja usługi Aktualizacja salda Czy wymagana płatność? Koniec - usługa działa Schemat 4. Proces świadczenia usług na Platformie Usługowej usługi dodane Kroki procesu związane z wymianą danych EDI Poniższe kroki procesu związane są z wymianą danych EDI: Wysłanie powiadomienia o nowym kliencie w ramach tego kroku Platforma Usługowa przekazuje do systemów informatycznych Partnera następujące informacje: o Dane identyfikacyjne klienta (imię, nazwisko, adres, adres , numer telefonu kontaktowego, nazwa i NIP firmy, informacja o chęci otrzymywania faktur papierowych, numer klienta nadany w module resellerskim) Strona: 25

26 4.4. Proces 3 Dokonywanie płatności za pośrednictwem Platformy Usługowej Opis procesu Platforma Usługowa będzie zintegrowana z jedną z oferujących swoje usługi na rynku polskim organizacją obsługującą płatności elektroniczne. W ten sposób klienci końcowi będą mogli dokonywać płatności za usługi cyfrowe w modelu pre-paid przy użyciu dowolnego z kanałów płatności obsługiwanych przez usługodawcę e-płatności. Na podstawie zweryfikowanych pozytywnie wpłat, Platforma Usługowa wygeneruje i udostępni systemom informatycznym partnera fakturę elektroniczną wystawioną dla klienta końcowego. Oczywiście faktura dostępna będzie także dla klienta końcowego. Należy zwrócić uwagę, że Platforma Usługowa nie będzie brała udziału w przepływie środków finansowych. Będzie ona pełnić rolę pośredniczącą pomiędzy klientem końcowym, dostawcą e- płatności oraz Partnerem w zakresie przekazywania zleceń płatności oraz dokumentów finansowych faktur. Fizyczny obieg środków finansowych będzie odbywał się pomiędzy klientem końcowym, dostawcą e-płatności oraz Partnerem. W szczególności żądania wysyłane przez Platformę Usługową do systemu e-płatności będą odbywać się w kontekście danych autoryzacyjnych pozyskanych przez partnera, który musi posiadać w systemie e-płatności własne konto. Poniżej znajduje się opis kroków procesu. Tabela. 5. Opis kroków procesu płatności na Platformie Usługowej Lp. azwa kroku/aktywności Opis 1 Zlecenie doładowania konta na Platformie Usługowej 2 Przekazanie żądania do systemu e-płatności Klient loguje się do panelu klienta udostępnionego w module resellerskim Partnera. Po wybraniu odpowiedniej kwoty doładowania generuje zlecenie do systemu e- płatności. Platforma Usługowa wykorzystując unikalne dane Partnera zapisane w module resellerskim (tzw. klucz aplikacji) wysyła żądanie do systemu e-płatności. Klient końcowy jest następnie przekierowywany na stronę systemu e-płatności, gdzie wybiera formę płatności oraz podaje dane niezbędne do jej przeprowadzenia (np. dane karty kredytowej). System płatności przeprowadza Strona: 26

27 weryfikację transakcji i jej rezultat prezentowany jest klientowi końcowemu a także zwracany do Platformy Usługowej. Po otrzymaniu informacji o negatywnej weryfikacji, Platforma Usługowa informuje klienta końcowego, że transakcja nie przebiegła pomyślnie i saldo na jego koncie nie uległo zmianie. 3 Aktualizacja salda konta klienta Po otrzymaniu pozytywnej weryfikacji transakcji, Platforma Usługowa aktualizuje saldo konta klienta zgodnie z wpłaconą przez niego kwotą oraz informuje klienta o pozytywnym rezultacie operacji. Aktualizacja salda konta klienta (zarówno w wyniku doładowania konta jak i obciążenia konta związanego z naliczeniem opłaty za usługę) może wygenerować powiadomienie do systemu informatycznego Partnera. 4 Wygenerowanie faktury Po pozytywnej weryfikacji płatności klienta, Platforma Usługowa generuje fakturę i zapisuje ją w repozytorium faktur Partnera a jej kopię w formacie HTML lub PDF w obszarze danych klienta (skąd klient może ją pobrać za pośrednictwem panelu klienta). Wygenerowana faktura przekazywana jest do systemu informatycznego Partnera. 5 Powiadomienie o aktualizacji salda Ostatnim etapem procesu jest powiadomienie klienta końcowego przez Platformę Usługową o zaktualizowanym stanie salda klienta za pośrednictwem panelu klienta Diagram procesu Strona: 27

28 act Płatności HB Technology Partner Klient końcowy Start Zlecenie doładowania konta na platformie usługowej Przkezanie żądania do systemu płatności Powiadomienie o błędzie Autoryzacja pozytywna? Koniec Powiadomienie o doładowaniu (opcjonalne) Aktualizacja na saldzie konta Przekazanie faktury do systemu F/K Partnera Wygenerowanie faktury od: "Partner" do: "Klient końcowy" w systemie Pow iadomienie o aktualizacji salda Koniec Schemat 5. Proces dokonywania płatności na Platformie Usługowej Kroki procesu związane z wymianą danych EDI Poniższe kroki procesu związane są z wymianą danych EDI: (3) Powiadomienie o doładowaniu w tym kroku Platforma Usługowa przesyła do systemu informatycznego następujące informacje: numer klienta, nazwę klienta, informację, czy klient chce otrzymywać faktury w formie papierowej, kwota doładowania, data doładowania, kod operacji z systemu e-płatności (4) Wygenerowanie faktury po wygenerowaniu faktury przez Platformę Usługową jest ona przekazywana do systemu informatycznego Partnera. Faktura zawiera: dane wystawcy/sprzedawcy Partnera, dane odbiorcy/kupującego klienta końcowego, kwotę doładowania netto, stawkę i kwotę podatku, kwotę brutto Proces 4 Wysyłanie okresowych zestawień i powiadomień do Partnerów przez Platformę Usługową Opis procesu Zgodnie z założeniami dotyczącymi modelu biznesowego współpracy pomiędzy HB Technology a jej Partnerami, rozliczanie opłat za usługi, z których korzystają klienci końcowi Partnera odbywać się będzie w modelu post-paid co określony czas (w praktyce będzie to miesięczny okres rozliczeniowy). Po zakończeniu okresu rozliczeniowego, Platforma Usługowa automatycznie wygeneruje zestawienia wykorzystanych usług, wykonanych połączeń oraz wystawi faktury osobno za usługi oraz za Strona: 28

29 połączenia dla Partnera. Przygotowane dane zostaną następnie przekazane do systemów informatycznych Partnera. Poniżej znajduje się opis kroków procesu. Tabela. 6. Opis kroków procesu wysyłania okresowych zestawień na Platformie Usługowej Lp. azwa kroku/aktywności Opis 1 Przygotowanie zestawienia usług Proces uruchamiany jest automatycznie wraz z zakończeniem okresu rozliczeniowego. W pierwszej kolejności Platforma Usługowa określa liczbę usług określonego typu wraz z ich kosztem, które zostały wykorzystane przez Partnera w zakończonym okresie rozliczeniowym. 2 Wystawienie faktury za usługi Na podstawie wygenerowanego zestawienia usług, Platforma Usługowa generuje fakturę za te usługi i przekazuje ją do systemu informatycznego Partnera. 3 Przygotowanie zestawienia połączeń Również wraz z zakończeniem okresu rozliczeniowego Platforma Usługa analizuje repozytorium rekordów bilingowych (CDR) i przygotowuje szczegółowe zestawienie wykonanych połączeń telefonicznych wraz z ich kosztem. Przygotowane zestawienie przekazywane jest do systemu informatycznego Partnera. 4 Wystawienie faktury za połączenia 5 Akceptacja powiadomienia przez Partnera Na podstawie przygotowanych zestawień Platforma Usługowa generuje dokument faktury za połączenia i przekazuje go do systemu informatycznego Partnera. Po akceptacji przez Partnera, informacja o akceptacji powiadomienia trafia do Platformy Usługowej gdzie aktualizowany jest status danego powiadomienia. Ponadto, w ramach okresowych powiadomień, Platforma Usługowa będzie z częstotliwością większą niż czas trwania okresu rozliczeniowego wysyłać do Partnera powiadomienia o aktualnym Strona: 29

30 wykorzystaniu środków pieniężnych Platformy Resellerkiej Partnera. Uwzględnione w przesyłanym zestawieniu informacje to: Kwota brutto niezapłaconych faktur za połączenia telefoniczne Kwota brutto niezapłaconych faktur za usługi dodatkowe Kwota brutto należna z tytułu wykonanych rozmów telefonicznych na dzień powiadomienia Kwota brutto zadłużenia ogółem na dzień powiadomienia Powiadomienia tego typu będą wymagały akceptacji ze strony Partnera. Poniżej znajduje się opis kroków procesu. Tabela. 7. Opis kroków procesu wysyłania okresowych powiadomień o wykorzystaniu środków pieniężnych Platformy Resellerskiej Partnera Lp. azwa kroku/aktywności Opis 1 Przygotowanie zestawienia połączeń wykonanych od początku bieżącego okresu roliczeniowego Proces uruchamiany jest automatycznie wraz z upływem okresu określonego w konfiguracji częstotliwości wysyłania powiadomień o wykorzystaniu środków pieniężnych dla danego Partnera. Platforma Usługowa analizuje wszystkie rekordy bilingowe wygenerowane w module resellerskim Partnera od rozpoczęcia bieżącego okresu rozliczeniowego i wylicza ich łączny koszt brutto. 2 Weryfikacja statusu płatności faktur wystawionych Partnerowi 3 Wygenerowanie powiadomienia o aktualnym wykorzystaniu środków pieniężnych 4 Akceptacja powiadomienia przez Partnera Jednocześnie, Platforma Usługowa weryfikuje status opłacenia wszystkich faktur wystawionych dla danego Partnera i określa łączną kwotę brutto zobowiązań Partnera wobec HB Technology w podziale na usługi telefoniczne i dodatkowe. Na podstawie informacji zebranych przez Platformę Usługową w krokach 1 i 2 generowane jest powiadomienie i wysyłane do systemu informatycznego Partnera. Po akceptacji przez Partnera, informacja o akceptacji powiadomienia trafia do Platformy Usługowej gdzie Strona: 30

31 aktualizowany jest status danego powiadomienia Diagram procesu act Okresow e zestawienia HB Technology Partner Start Koniec okresu rozliczeniowego Przekazanie okresowego zestawienia połączeń Przygotow anie zestawienia połączeń Przekazanie faktury za połączenia Wystawienie faktury za połączenia Akceptacja zestawienia Przekazanie faktury za usługi Koniec Przygotowanie zestawienia usług Wystawienie faktury za usługi Schemat 6. Proces wysyłania okresowych zestawień do Partnerów przez Platformę Usługową act Okresowe zestawienia HB Technology Partner Start Upływ skonfigurowanego na Platformie Usługowej okresu co jaki wysyłane jest powiadomienie o wykorzystaniu środków Przygotowanie zestawienia połączeń wykonanych od początku bieżącego okresu roliczeniowego Weryfikacj a statusu płatności faktur wystawionych Partnerowi Przekazanie powiadomienia Wygenerowanie powiadomienia o aktualnym wykorzystaniu środków pieniężnych Akceptacja powiadomienia przez Partnera Koniec pieniężnych Partnera Schemat 7. Proces wysyłania okresowych powiadomień o wykorzystaniu środków pieniężnych Platformy Resellerskiej Partnera Kroki procesu związane z wymianą danych EDI Strona: 31

32 Poniższe kroki procesu związane są z wymianą danych EDI: Proces wysyłania okresowych zestawień: (3) Przygotowanie zestawienia połączeń Platforma Usługowa przekaże do systemu informatycznego Partnera następujące dane: o Identyfikator powiadomienia o Dla każdego połączenia Numer klienta Numer A Numer B Grupa taryfowa Data i czas rozpoczęcia połączenia Czas trwania połączenia Typ naliczania (jednostki taryfikacyjnej) Cena jednostkowa Cena netto za połączenie Cena brutto za połączenie o Łączna cena za połączenia netto o Łączna cenna za połączenia brutto (5) Akceptacja powiadomienia przez Partnera do Platformy Usługowej przekazane zostaną: o Identyfikator powiadomienia o Informacja o akceptacji (2) Wystawienie faktury za usługi po wygenerowaniu faktury Platforma Usługowa przekaże ją/je do systemu informatycznego Partnera. Zakres przekazywanych danych to: o Dane sprzedawcy/wystawcy HB Technology o Dane kupującego/odbiorcy Partner Strona: 32

33 o Data wystawienia o Data sprzedaży o Numer faktury o Dla każdego typu usługi Nazwa i oznaczenie usługi Cena jednostkowa netto Liczba usług danego typu Łączna cena netto za usługi danego typu Stawka podatku za usługi danego typu Wartość podatku VAT za połączenia Łączna cena za połączenia brutto o Podsumowanie Łączna cena netto Łączna wartość podatku w poszczególnych stawkach podatkowych Łączna cena brutto o Forma i termin płatności (4) Wystawienie faktury za połączenia po wygenerowaniu faktury Platforma Usługowa przekaże ją/je do systemu informatycznego Partnera. Zakres przekazywanych danych to: o Dane sprzedawcy/wystawcy HB Technology o Dane kupującego/odbiorcy Partner o Data wystawienia o Data sprzedaży o Numer faktury o Łączna cena za połączenia netto Strona: 33

34 o Stawka podatku za połączenia o Wartość podatku VAT za połączenia o Łączna cena za połączenia brutto o Forma i termin płatności Proces wysyłania okresowych powiadomień o wykorzystaniu środków pieniężnych Platformy Resellerskiej Partnera (3) Wygenerowanie powiadomienia o aktualnym wykorzystaniu środków pieniężnych Platforma Usługowa przekaże do systemu informatycznego Partnera następujące dane: o Identyfikator powiadomienia o Kwota brutto niezapłaconych faktur za połączenia telefoniczne o Kwota brutto niezapłaconych faktur za usługi dodatkowe o Kwota brutto należna z tytułu wykonanych rozmów telefonicznych na dzień powiadomienia o Kwota brutto zadłużenia ogółem na dzień powiadomienia (4) Akceptacja powiadomienia przez Partnera do Platformy Usługowej przekazane zostaną: o Identyfikator powiadomienia o Informacja o akceptacji 4.6. Proces 5 Modyfikacja usług cyfrowych świadczonych przez Platformę Usługową Opis procesu Usługi świadczone na Platformie Usługowej mogą ulegać modyfikacji. Modyfikacja ta może mieć charakter biznesowy (np. zmiana cen za usługi), techniczny (np. dodatkowe parametry opisujące konfigurację usługi) bądź jednocześnie biznesowy i techniczny (najbardziej typowa sytuacja wraz z rozwojem usług na Platformie Usługowej może wzrastać ich cena). Ponieważ zmiany tego typu rzutują bezpośrednio zarówno na zakres i rodzaj usług odsprzedawanych przez Partnera swoim Strona: 34

35 klientom końcowym jak i rozliczenia pomiędzy Partnerem a HB Technology, przed ich wprowadzeniem wymagana jest akceptacja tych zmian przez Partnera. Poniżej znajduje się opis kroków procesu. Tabela. 8. Opis kroków procesu modyfikacji usług cyfrowych świadczonych na Platformie Usługowej Lp. azwa kroku/aktywności Opis 1 Rozpoczęcie procesu Proces rozpoczyna się z chwilą wprowadzenia na Platformie Usługowej modyfikacji technicznej istniejącej usługi lub w związku z zaplanowaną zmianą biznesową usługi przez HB Technology. Modyfikacje usług nie są automatycznie wprowadzane w modułach resellerskich. 2 Podpisanie aneksu do umowy Jeżeli z jakiegoś powodu wprowadzenie modyfikacji w module resellerskim Partnera wymaga podpisania aneksu do umowy o współpracy pomiędzy HB Technology a Partnerem, strony uzgadniają treść aneksu i podpisują go. Aneks powinien m.in. określać datę wprowadzenia modyfikacji usług. Data powinna zostać uzgodniona pomiędzy stronami w taki sposób, by Partner mógł powiadomić o planowanych zmianach swoich klientów. 3 Powiadomienie o zmianach w istniejących usługach HB Technology generuje w panelu administracyjnym Platformy Usługowej powiadomienie do wszystkich Partnerów z informacją o zakresie zmian w istniejących usługach oraz o planowanym terminie uruchomienia tych zmian w modułach resellerskich (dotyczy to również dat obowiązywania zmian w cennikach usług/połączeń, regulaminów usług, opisu nowych parametrów konfiguracyjnych, etc.). Powiadomienie przekazywane jest do systemów informatycznych Partnerów. 4 Uruchomienie zmian w Po otrzymaniu powiadomienia o zmianach i w celu ich wprowadzenia Partner musi wyrazić na te zmiany zgodę. Strona: 35

36 usługach dla Partnera Akceptacja zmian przekazywana jest do Platformy Usługowej. Po otrzymaniu informacji o akceptacji zmian przez Partnera, wprowadzane są w konfiguracji modułu resellerskiego niezbędne zmiany w dacie określonej przez HB Technology a następnie uzgodnionej z Partnerem Diagram procesu act Modyfikacja usług HB Technology Partner Zmiana konfiguracji technicznej usługi Zmiana konfiguracji biznesowej usługi Podpisanie aneksu [TAK] [NIE] Przekazanie informacji o zmianach w istniejących usługach Otrzymanie akceptacji zmian Pow iadomienie o zmianach w istniejących usługach Data wprowadzenia zmian Uruchomienie zmian w usługach dla Partnera Koniec Wymagany aneks do umowy? Start Schemat 8. Proces modyfikacji usług cyfrowych świadczonych przez Platformę Usługową Kroki procesu związane z wymianą danych EDI Poniższe kroki procesu związane są z wymianą danych EDI: (3) Powiadomienie o zmianach w istniejących usługach HB Technology za pośrednictwem Platformy Usługowej przekaże do systemu informatycznego Partnera następujące informacje: o Zmiana konfiguracji technicznej Identyfikator zmiany Planowana data wprowadzenia zmiany Zmiana regulaminu usługi (jeżeli wymagana) Dla każdego nowego parametru konfiguracji Nazwa parametru Opis funkcji parametru Strona: 36

37 Informację o możliwych wartościach parametru Lokalizację parametru w aplikacji administracyjnej Czy parametr może być zmieniany przez klienta Lokalizację parametru w panelu klienta o Zmiana konfiguracji biznesowej Identyfikator zmiany Planowana data wprowadzenia zmiany Regulamin usługi (jeżeli zmieniane) Dla każdego zmienianego/nowego parametru biznesowego: Nazwa parametru biznesowego (np. cena) Opis parametru Dotychczasowa wartość parametru Nowa wartość parametru Lokalizacja parametru w aplikacji administracyjnej Czy parametr może być zmieniany przez klienta Lokalizacja parametru w panelu klienta (4) Uruchomienie zmian w usługach dla Partnera Akceptacja warunków modyfikacji istniejących usług przez Partnera zostanie przesłana do HB Technology za pośrednictwem Platformy Usługowej. Przekazywane dane to: o Identyfikator zmiany o Akceptacja TAK Partner zaakceptował zmiany w warunkach świadczenia usług bez uwag NIE Partner nie wyraził zgody na zmianę dalsze postępowanie w takim przypadku jest poza zakresem niniejszej analizy (możliwe scenariusze to np. Strona: 37

38 pozostawienie niezmienionej konfiguracji usług, rozwiązanie umowy o współpracy w przypadku braku akceptacji zmian cennika usług, itp.) 4.7. Proces 6 Wycofanie/wprowadzenie usług cyfrowych świadczonych przez Platformę Usługową Opis procesu Wraz z rozwojem Platformy Usługowej możliwe będzie uruchamianie na niej przez HB Technology nowych usług cyfrowych, z których korzystać będą mogli także Partnerzy i ich klienci końcowi. Ponadto, możliwe jest także, że na skutek braku zainteresowania lub możliwości osiągnięcia satysfakcjonującego poziomu rentowności HB Technology będzie decydować o usunięciu istniejących usług w celu zwolnienia zasobów na rzecz nowych usług o większym potencjale sprzedażowym. W takich przypadkach, podobnie jak w procesie modyfikacji istniejących usług niezbędne jest uzyskanie zgody Partnerów na wprowadzenie zmian w wykorzystywanych przez nich modułach resellerskich. Poniżej znajduje się opis kroków procesu. Tabela. 9. Opis kroków procesu dodawania/usuwania usług cyfrowych świadczonych na Platformie Usługowej Lp. azwa kroku/aktywności Opis 1 Rozpoczęcie procesu Proces rozpoczyna się z chwilą wprowadzenia na Platformie Usługowej nowej usługi lub zaplanowania przez HB Technology usunięcia usługi istniejącej. Nowe usługi nie są automatycznie wprowadzane w modułach resellerskich ani też nie są z nich usuwane. 2 Podpisanie aneksu do umowy Jeżeli z jakiegoś powodu wprowadzenie nowej usługi lub usunięcie istniejącej w module resellerskim Partnera wymaga podpisania aneksu do umowy o współpracy pomiędzy HB Technology a Partnerem, strony uzgadniają treść aneksu i podpisują go. Aneks powinien m.in. określać datę wprowadzenia nowej usługi lub/i usunięcia istniejącej. Data powinna zostać uzgodniona pomiędzy stronami w taki sposób, by Partner mógł powiadomić o planowanych Strona: 38

39 zmianach swoich klientów. 3 Powiadomienie o nowych usługach/usunięciu istniejących usług HB Technology generuje w panelu administracyjnym Platformy Usługowej powiadomienie do wszystkich Partnerów z informacją nowych/usuwanych usługach oraz o planowanym terminie dodania/usunięcia tych usług w modułach resellerskich. Powiadomienie przekazywane jest do systemów informatycznych Partnerów. 4 Uruchomienie nowych Po otrzymaniu powiadomienia o nowych/usuwanych usługa/usunięcie istniejących usługach w celu rekonfiguracji modułu resellerskiego, usług w module resellerskim Partnera Partner musi wyrazić zgodę. Akceptacja przekazywana jest do Platformy Usługowej. Po otrzymaniu informacji o akceptacji nowych/usuwanych usług Partnera, wprowadzane są w konfiguracji modułu resellerskiego niezbędne zmiany w dacie określonej przez HB Technology a następnie uzgodnionej z Partnerem Diagram procesu act Dodanie/Usunięcie usługi HB Technology Partner Uruchomienie na platformie nowej usługi Planowane usunięcie istniejącej usługi Podpisanie aneksu [TAK] [NIE] Wymagany aneks do umowy? Przekazanie informacji o nowych/usuwanych usługach Powiadomienie o nowych/usuwanych usługach Otrzymanie akceptacji na uruchomienie nowych/usunięcie istniejących usług Uruchomienie nowej usługi/usunięcie istniejącej usługi dla partnera Koniec Data uruchomienia/usunięcia Start usługi Schemat 9. Proces dodania/usunięcia usług cyfrowych świadczonych przez Platformę Usługową Kroki procesu związane z wymianą danych EDI Poniższe kroki procesu związane są z wymianą danych EDI: Strona: 39

40 (3) Powiadomienie nowych usługach/usunięciu istniejących usług HB Technology za pośrednictwem Platformy Usługowej przekaże do systemu informatycznego Partnera następujące informacje: o Dodanie nowej usługi Identyfikator akcji dodania nowej usługi Nazwa usługi Opis usługi Regulamin usługi Planowana data uruchomienia nowej usługi Lista parametrów technicznych usługi. Dla każdego parametru technicznego przekazane zostaną: Nazwa parametru Opis funkcji parametru Informację o możliwych wartościach parametru Lokalizację parametru w aplikacji administracyjnej Czy parametr może być zmieniany przez klienta Lokalizację parametru w panelu klienta Lista parametrów biznesowych usługi. Dla każdego parametru biznesowego przekazane zostaną: Nazwa parametru biznesowego (np. cena) Opis parametru Dotychczasowa wartość parametru Nowa wartość parametru Lokalizacja parametru w aplikacji administracyjnej Czy parametr może być zmieniany przez klienta Strona: 40

41 Lokalizacja parametru w panelu klienta o Usunięcie istniejącej usługi Identyfikator akcji usunięcia istniejącej usługi Nazwa/oznaczenie istniejącej usługi Planowana data usunięcia usługi Powód decyzji o usunięciu usługi (4) Uruchomienie nowej usługi/usunięcie istniejącej usługi w module resellerskim Partnera Akceptacja warunków nowych usług/usunięcia istniejących usług przez Partnera zostanie przesłana do HB Technology za pośrednictwem Platformy Usługowej. Przekazywane dane to: o Identyfikator akcji dodania/usunięcia usługi o Akceptacja TAK Partner zaakceptował warunki dodania/usunięcia usługi bez uwag NIE Partner nie wyraził zgody na zmianę dalsze postępowanie w takim przypadku jest poza zakresem niniejszej analizy (możliwe scenariusze to np. pozostawienie usuwanej usługi w module resellerskim itp.) Strona: 41

42 5. Analiza istniejących implementacji standardu EDI wykorzystywanych w Polsce 5.1. Wstęp W niniejszym rozdziale analizie poddane zostały dostępne w Polsce implementacje EDI. Przeprowadzona analiza miała na celu scharakteryzowanie implementacji pod kątem możliwości wykorzystania każdej z nich w ramach projektu realizowanego przez HB Technology. Z uwagi na fakt, że standard EDI jest specyfikacją o charakterze otwartym, konkretne implementacje znacząco się od siebie różnią w zależności od (1) obszaru funkcjonalnego w jakim się go wykorzystuje jak i (2) obszaru dziedzinowego, tj. rodzaju rynku, na jakim prowadzi działalność przedsiębiorstwo implementujące EDI. Należy jednocześnie zwrócić uwagę na fakt, że EDI nie opiera się na żadnym konkretnym standardzie w zakresie: Formatu danych Struktury komunikatów Protokołów komunikacyjnych Zgodnie z zalecenie Komisji Europejskiej w sprawie EDI, podmioty wdrażające EDI mogą skorzystać z dowolnych standardów w wyżej wymienionych obszarów pod warunkiem, że spełniają one podstawowe założenia EDI dotyczące weryfikacji autentyczności/pochodzenia oraz integralności przesyłanych danych Integracja w standardzie EANCOM/EDIFACT Standard EANCOM/EDIFACT Elektroniczna wymiana danych pomiędzy współpracującymi ze sobą podmiotami w oparciu o standard EANCOM/EDIFACT powinna odbywać się w oparciu o komunikaty zatwierdzone przez krajowy podmiot należący do międzynarodowej organizacji GS1. W Polsce rolę tę pełni Instytut Logistyki i Magazynowania. GS1 tworzy i rozwija standardy w zakresie wymiany dokumentów handlowych w postaci elektronicznej. EANCOM jest jednocześnie podstandardem UN/EDIFACT i metodologią wdrażania komunikatów EDIFACT, uwzględniającą dodatkowo międzynarodowe numery identyfikacyjne GS1. Przy opracowywaniu szczegółowych projektów komunikatów przyjęto trzy podstawowe zasady: Strona: 42

43 prostota - przedstawienie standardu UN/EDIFACT w sposób zrozumiały i łatwy do wdrożenia, wykorzystanie numerów GS1 do identyfikacji produktów i miejsc lokalizacji, celem ułatwienia automatycznego przetwarzania danych, stałość wydania - każde wydanie EANCOM jest oparte tylko na jednym katalogu UN/EDIFACT (ang. UN/EDIFACT directory) W Polsce uzgadnianiem i ujednolicaniem postaci komunikatów EDI stosowanych w transakcjach handlowych między dostawcami a sieciami handlowymi zajmuje się Grupa ds. EDI. Grupa ds. EDI powstała z inicjatywy członków Porozumienia ECR Polska. Grupa ma charakter otwarty i jej członkami mogą być przedstawiciele każdej firmy, która aktywnie zaangażowana jest we wdrażanie rozwiązań EDI lub planuje tego typu przedsięwzięcia w niedalekiej przyszłości Struktura komunikatów EANCOM/EDIFACT Standard EDIFACT określa strukturę wymiany danych na kilku poziomach: Wymiany danych Grupy powiązanych komunikatów (np. komunikatów tego samego typu, przykładowo faktur) Wiadomości Segmentów Najmniejszym elementem składowym komunikatu jest segment to z nich składa się komunikat EDIFACT. Może być to segment związany ze strukturalnym podziałem komunikatu, zwany również segmentem usługowym (service segment), bądź też segment zawierający dane użytkownika, związany z konkretną wiadomością: Schemat 10. Segmenty usługowe w komunikacie EDIFACT Jak widać na powyższym schemacie, niektóre z segmentów usługowych są opcjonalne inne zaś obowiązkowe. Strona: 43

44 Struktura wiadomości Wiadomość, czyli część komunikatu zawarta pomiędzy segmentami UNH i UNT podzielona jest na 3 sekcje: Sekcję nagłówka segmenty zawarte w tej sekcji dotyczą całej wiadomości Sekcję szczegółów segment znajdujący się w tej sekcji związany jest tylko ze szczegółowymi informacjami wiadomości Sekcję podsumowania tylko segmenty zawierające informacje kontrolne lub informacje zbiorcze (np. łączna liczba linii zamówień, łączna kwota faktury) mogą znajdować się w tej sekcji Omawiana struktura została zaprezentowana na schemacie poniżej: Schemat 11. Struktura wiadomości w komunikacie EA COM/EDIFACT Ogólnie rzecz biorąc, ten sam typ segmentu może występować w kilku sekcjach, a także więcej niż jeden raz w danej sekcji. Niektóre segmenty mogą być powtórzone określoną liczbę razy w danym miejscu wiadomości. Maksymalna liczby tych powtórzeń, a także status danego segmentu (tj. czy jest on obowiązkowy czy opcjonalny/warunkowy) określona jest w strukturze konkretnej wiadomości. Oprócz pojedynczych segmentów, powtarzane mogą być także grupy segmentów, czyli zbiory funkcjonalnie powiązanych ze sobą segmentów. Ponadto, segmenty mogą być zagnieżdżane w innych segmentach, pod warunkiem, że zostaną zachowane zasady związane z zagnieżdżaniem Struktura segmentu Strona: 44

45 Segment, czyli najmniejsza jednostka, z jakich składa się komunikat złożony jest z: Identyfikatora segmentu, określającego typ segmentu Separatorów elementów danych Elementów danych (prostych, złożonych i składowych) Zakończenia segmentu Elementy danych mogą posiadać stałą lub zmienną długość. Złożone elementy danych zawierają dwa lub więcej składowe elementy danych. Składowy element danych jest prostym elementem danych wykorzystywanym w złożonym elemencie danych. Elementy danych mogą zawierać odwołania do innych elementów danych zwanych kwalifikatorami poprzez kody, którym odpowiada określone, uzgodnione znaczenie. Poniżej zaprezentowano przykładowy segment wraz z jego opisem: DTM+137: :102' DTM = Identyfikator segmentu; + = Separator; 137 = Kwalifikator/kod określający rodzaj elementu danych; : = separator elementów danych w ramach złożonego element danych; = data; : = separator elementów danych w ramach złożonego element danych; 102 = Kwalifikator określający format daty (RRRRMMDD); ' = Zakończenie segmentu. Graficznie strukturę komunikatu EDIFACT zaprezentowano poniżej: Strona: 45

46 Schemat 12. Struktura komunikatu EDIFACT Przykładowy komunikat EDIFACT zawierający trzy awiza wysyłki oraz 2 faktury został zaprezentowany poniżej: UNA:+.? ' UNB+UNOA: : : : EANCOMREF52'... UNH DESADV:D:96A:UN:EAN006'...treść awiza dostawy... UNT ' UNH DESADV:D:96A:UN:EAN006'...treść awiza dostawy... UNT ' UNH+1588+INVOIC:D:96A:UN:EAN009'...treść faktury... UNT ' UNH+2063+INVOIC:D:96A:UN:EAN009'...treść faktury.. UNT ' UNH DESADV:D:96A:UN:EAN006'...treść awiza dostawy... UNT '... UNZ ' Komunikaty EANCOM/EDIFACT i kody GS1 Strona: 46

47 W ramach prac prowadzonych przez Grupę ds. EDI zostały uzgodnione następujące komunikaty EANCOM/EDIFACT: AWIZO WYSYŁKI / DESADV KATALOG/CENNIK / PRICAT ODPOWIEDŹ NA ZAMÓWIENIE / ORDRSP INFORMACJA ADRESOWA / PARTIN POTWIERDZENIE PRZYJĘCIA / RECADV ZAMÓWIENIE / ORDERS AWIZO PRZELEWU / REMADV ZAWIADOMIENIE O ZWROTACH / RETANN POTWIERDZENIE FAKTURY KOREKTY / CORRECTING INVOICE CONFIRMATION FAKTURA / INVOIC FAKTURA KOREKTA / CORRECTING INVOICE RAPORT O ZAPASACH / INVRPT NOTA KSIĘGOWA / ACCNOT NOTA KORYGUJĄCA / COMDIS INSTRUKCJE TRANSPORTOWE / IFTMIN STATUSY w TRANSPORCIE / IFTSTA Specyfikacje powyższych komunikatów znajdują się na stronie Grupy ds. EDI przy Porozumieniu ECR Polska. Komunikaty te są w pełni zgodne ze standardem EANCOM, tj. specyfikacje tych komunikatów powołują się na standard GS1 w zakresie identyfikatorów występujących w komunikatach. Najważniejsze identyfikatory to: Identyfikatory GTIN są to unikalne identyfikatory jednostek handlowych Identyfikatory GLN są to unikalne identyfikatory organizacji lub przedsiębiorstwa jako osoby prawnej Strona: 47

48 Ogólny przepływ informacji przy wykorzystaniu najpopularniejszych komunikatów standardu EANCOM/EDIFACT został zaprezentowany poniżej: Schemat 13. Model przepływu komunikatów EA COM/EDIFACT Z zaakceptowanych przez Grupę ds. EDI dokumentów, realne znaczenie w przypadku komunikacji pomiędzy HB Technology a jego Partnerami mogłyby mieć następujące typy wiadomości: INFORMACJA ADRESOWA / PARTIN KATALOG/CENNIK / PRICAT FAKTURA / INVOIC NOTA KORYGUJĄCA / COMDIS FAKTURA KOREKTA / CORRECTING INVOICE Strona: 48

49 POTWIERDZENIE FAKTURY KOREKTY / CORRECTING INVOICE CONFIRMATION AWIZO PRZELEWU / REMADV Wiadomość PARTIN Wiadomość PARTIN służy do wymiany danych na temat kontrahentów. Wymieniane informacje obejmują: Nazwa partnera Adres partnera Numery kont partnera Numery REGON, NIP Dane kontaktowe i kanały komunikacyjne Harmonogram dostaw Komunikat PARTIN wykorzystywany jest najczęściej w przypadku dostawców i odbiorców posiadających dużą liczbę kontrahentów (sieci handlowe, linie lotnicze, hotele). W przypadku gdy liczba kontrahentów jest ograniczona, dane na temat partnera mogą zostać wprowadzone w systemach informatycznych ręcznie - jest to czynność jednorazowa, która może być przeprowadzona na etapie nawiązywania współpracy z partnerem Wiadomość PRICAT Komunikat umożliwiający transmisję informacji dotyczących cen i szczegółów katalogowych, na temat towarów i usług oferowanych nabywcy przez sprzedawcę. Ponadto, kupujący może przesłać komunikat sprzedawcy, podając wymagania specjalne, takie jak umieszczenie etykiet nabywcy lub szczegóły pakowania, albo odpowiedzieć na poprzednio otrzymany Katalog/cennik. Wiadomość PRICAT zawiera między innymi: Datę obowiązywania cennika Informacje o grupach towarów/usług (np. wg ceny, producenta, rodzaju) do których należy produkt Numer PKWiU produktu Opis słowny produktu Strona: 49

50 Wymiary i waga produktu Termin przydatności do spożycia Informacje o podatkach Cena i okres jej obowiązywania Informacje o opakowaniu, jego wymiarach i wadze W komunikacji pomiędzy HB Technology a Partnerami, wiadomość PRICAT mogłaby być wykorzystywana do wymiany informacji na temat cen poszczególnych usług jednostkowych takich jak: Opłaty stałe, jak np. opłata miesięczna za każde konto klienta Partnera lub opłata za udostępnienie przez HB Technology modułu resellerskiego Partnerowi Minuta połączenia telefonicznego na poszczególne kierunki Usługi dodane, jak np. Wirtualny FAX, IVR, itp. Należy przy tym pamiętać, że wymiana informacji przy pomocy wiadomości PRICAT służy jednak przede wszystkim do zapewnienia aktualnych informacji na temat produktów i ich cen pomiędzy kontrahentami pomiędzy którymi dochodzi do składania i realizacji zamówień. W przypadku HB Technology i Partnerów do takiej relacji wprost dochodzić nie będzie, tj. Partnerzy nie będą decydowali o ilości wykorzystywanych przez siebie usług w sposób deterministyczny wykorzystanie usług będzie zależeć od tego jak dużo klientów Partnerów będzie z nich korzystać Dokument faktury Dokument faktury wystawiany jest przez sprzedawcę towarów i usług i wysyłany do kupującego, w celu uzyskania zapłaty za dostarczone towary i zrealizowane usługi. Najczęściej wiadomość INVOIC poprzedzona jest wymianą komunikatów ORDER (zamówienie), ORDRSP (odpowiedź na zamówienie), DESADV (awizo wysyłki) oraz RECADV (potwierdzenie odbioru wysyłki). Dokument faktury ma przede wszystkim znaczenie finansowe i prawne, ponieważ jest dokumentem którego wystawienie powoduje powstanie zobowiązań podatkowych oraz stanowi podstawę do zapłaty dla odbiorcy faktury. Faktura w standardzie EANCOM/EDIFACT posiada następującą strukturę: Początek komunikatu Strona: 50

51 o UNH nagłówek komunikatu o BGM początek komunikatu o DTM data komunikatu o DTM data oryginalnej faktury w przypadku duplikatu o DTM data sprzedaży o DTM data dostawy o FTX tekst wolny o FTX tekst wolny oznaczenie sądu rejestrowego i numeru rejestru oraz wysokość kapitału zakładowego i kapitału wpłaconego o SG 1 RFF numer zamówienia nadany przez nabywcę o SG 1 DTM data zamówienia o SG 1 RFF numer dokumentu dostawy nadany przez sprzedawcę o SG 1 DTM data dokumentu dostawy o SG 1 RFF numer dokumentu potwierdzenia odbioru o SG 1 DTM data dokumentu potwierdzenia odbioru o SG 2 NAD identyfikacja dostawcy o SG 2 FII numer konta dostawcy SG 2 SG 3 RFF NIP dostawcy SG 2 SG 3 RFF dodatkowa identyfikacja dostawcy wg nabywcy SG2 SG 3 RFF numer rejestrowy z rejestru Głównego Inspektora Ochrony Środowiska o SG 2 NAD identyfikacja siedziby dostawcy o SG 2 NAD identyfikacja nabywcy o SG 2 FII numer konta nabywcy SG 2 SG 3 RFF NIP nabywcy Strona: 51

52 o SG 2 NAD identyfikacja miejsca dostawy o SG 2 NAD identyfikacja płatnika o SG 2 FII numer konta płatnika SG 2 SG 3 RFF NIP płacącej instytucji finansowej o SG 2 NAD identyfikacja odbiorcy faktury o SG 2 FII numer konta odbiorcy faktury SG 2 SG 3 RFF NIP odbiorcy faktury o SG 2 NAD identyfikacja odbiorcy płatności o SG 2 FII numer konta odbiorcy płatności SG 2 SG 3 RFF NIP odbiorcy płatności o SG 2 NAD kraj wysyłki o SG 7 CUX identyfikacja waluty o SG 8 PAT warunki płatności o SG 8 DTM data płatności o SG12 TOD warunki dostawy Część szczegółowa o SG 25 LIN identyfikacja pozycji towarowej o SG 25 PIA dodatkowa identyfikacja towaru wg nabywcy o SG 25 PIA dodatkowa identyfikacja towaru wg dostawcy o SG 25 PIA Numer towaru wg PKWiU o SG 25 PIA kod celny towaru o SG 25 IMD opis słowny lub kodowany o SG 25 MEA waga towaru o SG 25 QTY ilość fakturowana Strona: 52

53 o SG 25 QTY ilość (jednostki zbiorcze) o SG 25 QTY ilość (liczba jednostek w jednostce zbiorczej) o SG 25 QTY ilość (rzeczywista ilość sztuk) o SG 25 QTY ilość (zawartość czystego składnika) o SG 25 ALI kraj pochodzenia towaru o SG 25 DTM data dostawy o SG 25 FTX kwota opłaty utylizacyjnej SG 25 SG 26 MOA wartość pozycji towarowej lub kwota kaucji za towary kaucjonowane SG 25 SG 28 PRI kwota kaucji za opakowanie zwrotne SG 25 SG 28 PRI cena jednostkowa netto pozycji towarowej SG 25 SG 29 RFF numer dokumentu dostawy nadany przez sprzedawcę SG 25 SG 29 DTM data dokumentu dostawy SG 25 SG 29 RFF numer zamówienia SG 25 SG 29 DTM data dokumentu zamówienia SG 25 SG 29 RFF numer dokumentu potwierdzenia odbioru SG 25 SG 29 DTM data dokumentu potwierdzenia odbioru SG 25 SG 32 LOC lokalizacja dostawy SG 25 SG 32 QTY ilość dostarczona SG 25 SG 33 TAX podatek VAT, stawka podatku lub oznaczenie opłaty - kaucja SG 25 SG 33 MOA kwota podatku o SG 34 NAD identyfikacja miejsca dostawy o SG 34 NAD kraj wysyłki o SG46 TOD warunki dostawy Strona: 53

54 o UNS separator o CNT segment kontrolny liczba pozycji towarowych w komunikacie Zakończenie o SG 48 MOA kwota do zapłaty o SG 48 MOA kwota netto o SG 48 MOA kwota podatku VAT o SG 48 MOA kwota podlegająca opodatkowaniu o SG 48 MOA kwota wartości kaucji opakowań zwrotnych o SG 50 TAX stawka podatku VAT o SG 50 MOA kwota netto o SG 50 MOA kwota podatku o SG 50 TAX stawka podatku VAT o SG 50 MOA kwota podlegająca opodatkowaniu o SG 50 MOA kwota brutto sprzedaży o SG 51 ALC bonifikaty lub obciążenia o SG 51 MOA kwota do zapłaty po doliczeniu kaucji za towary kaucjonowane o SG 51 MOA kwota netto po doliczeniu kaucji za towary kaucjonowane o UNT zakończenie komunikatu Wiadomość COMDIS Nota korygująca może być wystawiona jedynie przez odbiorcę faktury Nabywca towaru lub usługi, który otrzymał fakturę lub fakturę korygującą, zawierającą pomyłki dotyczące jakiejkolwiek informacji, wiążącej się zwłaszcza ze sprzedawcą lub nabywcą lub oznaczeniem towaru lub usługi (z pewnymi wyjątkami, wskazanymi poniżej), może wystawić fakturę nazwaną notą korygującą ( 18 ust. 1 rozporządzenia Ministra Finansów z dnia 28 marca 2011 r. w sprawie zwrotu podatku niektórym podatnikom, wystawiania faktur, sposobu ich przechowywania oraz listy towarów i Strona: 54

55 usług, do których nie mają zastosowania zwolnienia od podatku od towarów i usług (Dz.U nr 68 poz. 360). Nota korygująca może odnosić się tylko do jednego dokumentu (nie ma możliwości wystawienia zbiorczej noty korygującej). Nota korygująca NIE MOŻE korygować następujących informacji: 1. Jednostki miary i ilości sprzedanych towarów, 2. Rodzaj wykonanych usług, 3. Ceny jednostkowe netto towaru / usługi, 4. Wartości sprzedaży netto (wartości towarów lub wykonanych usług, których dotyczy sprzedaż bez kwoty podatku), 5. Stawki podatku, 6. Sumy wartości sprzedaży netto towarów / wykonanych usług, 7. Kwoty podatku od sumy wartości sprzedaży netto towarów (usług), 8. Wartości sprzedaży brutto (wartości sprzedaży towarów lub wykonanych usług wraz z kwotą podatku), 9. Kwoty należności ogółem wraz z należnym podatkiem wyrażona cyframi i słownie. Notą korygującą poprawia się jedynie treści formalne faktury, czyli te, które nie wiążą się z prawem do rozliczenia podatku od towarów i usług, przy czym jedną notą można poprawić nawet kilka błędów zawartych w jednej fakturze Wiadomość CORINV Wiadomość CORINV reprezentuje dokument faktury-korekty, wystawiany przez sprzedawcę w przypadku zaistnienia okoliczności wymuszających dokonanie korekty wystawionej już faktury. Pod względem struktury wiadomość CORINV wygląda bardzo podobnie do wiadomości INVOICE. Różnica polega na wprowadzeniu dodatkowych segmentów specyfikujących wartości BYŁO oraz POWINNO BYĆ w odniesieniu zarówno do poszczególnych pozycji na fakturze jak i wartości zbiorczych. Warto zwrócić uwagę, że w nagłówku wiadomości, wiadomość CORINV ma ten sam typ komunikatu (INVOIC) natomiast inną wartość w segmencie BGM (384 zamiast 380). Strona: 55

56 Wiadomość CONFIRMATION CORRECTING INVOICE Za pomocą tej wiadomości odbiorca faktury potwierdza fakturę-korektę lub fakturę korygowaną Wiadomość REMADV Komunikat Remittance Advice (REMADV) jest wysyłany pomiędzy kupującym a dostawcą i dostarcza szczegółowych informacji związanych z płatnościami lub innymi formami rozrachunków finansowych wykonywanymi w wyspecyfikowanym momencie czasowym za dostarczenie towarów i/lub usług opisanych w awizie. Komunikat REMADV jest zawiadomieniem o płatności, która zostanie wykonana. Jeden komunikat REMADV może dotyczyć jednej lub wielu transakcji handlowych i powiązanych transakcji finansowych i wykorzystanych dokumentów takich, jak: faktury, noty kredytowe, noty debetowe itd. Wartości przelewów dla całego dokumentu REMADV, dla każdego dokumentu wymienionego w komunikacie i dla każdej linii dokumentu odwołania musza być wszystkie wyrażone w tej samej walucie, co waluta płatności. Każdy komunikat REMADV powinien odnosić się tylko do jednej daty rozliczenia Integracja bezpośrednia W przypadku integracji bezpośredniej, kontrahenci przygotowują swoje systemy informatyczne w taki sposób by mogły zarówno generować jak i odbierać komunikaty zgodne ze standardem EANCOM/EDIFACT. Partnerzy muszą w pierwszej kolejności uzgodnić to, jakie typy wiadomości będą między nimi wymieniane, a także określić protokoły wymiany wiadomości. Typy wiadomości, z których mogą skorzystać polscy kontrahenci zostały omówione wcześniej w niniejszym opracowaniu. Pamiętać należy przy tym, że kontrahenci nie są w żaden sposób ograniczeni co do typów jak i zawartości wymienianych komunikatów. W tym wypadku postępowanie zgodnie z ustalonymi zasadami i wykorzystywanie uzgodnionych komunikatów będzie procentować wtedy, gdy baza partnerów będzie się powiększać ryzyko niezgodności i niekompatybilności w procesie integracji z nowym partnerem będzie wówczas znacznie mniejsze niż w sytuacji gdy wykorzystywane są niestandardowe komunikaty. Jeżeli chodzi o protokoły wymiany wiadomości, do dyspozycji partnerów są takie technologie jak: WebServices Strona: 56

57 HTML (strony WWW) FTP AS2 a także starsze, powoli wychodzące z użycia: o X400 o General Electric Uwarunkowania prawne Zgodnie z wytycznymi Komisji Europejskiej, partnerzy handlowi wdrażający EDI powinni zawrzeć w tym celu stosowną umowę, w której określą zasady elektronicznej wymiany danych oraz jej techniczne aspekty. O ile umowa modelowa pozostawia partnerom pewną elastyczność w zakresie implementacji EDI, należy pamiętać, że wymaga ona by strony umowy: wzajemnie zobowiązały się do akceptowania dokumentów wymienianych elektronicznie z tym samym skutkiem co ich odpowiedników papierowych zapewniały w wymianie danych autentyczność pochodzenia zapewniały integralność wymienianych danych zapewniały przechowywanie wymienianych danych przez uzgodnione w umowie okresy retencji Polskie prawo nie reguluje zasad wymiany dokumentów drogą elektroniczną poza fakturami. Zgodnie z polskim prawem faktury mogą być przesyłane drogą elektroniczną w szczególności przy wykorzystaniu elektronicznej wymiany danych EDI. Należy przy tym wziąć pod uwagę, że dla faktur elektronicznych określone są przez polskie prawo zasady i okresy retencji jak i wymagania dotyczące udostępniania tych dokumentów organom państwowym, które należy wziąć pod uwagę przez partnerów handlowych. Z punktu widzenia zaleceń KE w sprawie EDI jak i polskich regulacji odnośnie do faktur elektronicznych, integracja bezpośrednia oznacza dla obydwu partnerów: Konieczność wykorzystania technologii zapewniających zarówno autentyczność pochodzenia jak i integralność przesyłanych danych Strona: 57

58 Konieczność przechowywania wymienianych danych przez uzgodnione i wymagane prawem okresy retencji Koszty eksploatacji Koszty eksploatacji w przypadku integracji bezpośredniej można podzielić zasadniczo na dwie kategorie: Jednorazowe koszty początkowe o Koszty zakupu lub produkcji oprogramowania do odczytu i tworzenia wiadomości zgodnych ze standardem EANCOM/EDIFACT. Są to koszty relatywnie wysokie z uwagi na trudność przetwarzania składni tych komunikatów. W większości przypadków dostosowanie wykorzystywanego oprogramowania do tego by mogło przetwarzać te komunikaty jest niemożliwe bez zaawansowanej wiedzy informatycznej i powoływania dedykowanego projektu. o Koszty implementacji rozwiązań sieciowych i protokołów wymiany danych. Koszty te mogą być różne w zależności od wykorzystanego protokołu. Najwyższe będą wówczas, gdy kontrahenci będą wykorzystywać dedykowane łącza fizyczne pomiędzy swoimi środowiskami informatycznymi. Najmniej zaś zapłacą jeśli zdecydują się wykorzystać do komunikacji sieć internet, natomiast pamiętać należy wówczas o tym, że będą musieli bądź wykupić usługi hostingowe, w celu wprowadzenia elementu pośredniczącego, bądź zapewnić odpowiednie środki bezpieczeństwa jeśli komunikować się będą ze sobą bezpośrednio urządzenia znajdujące się w ich sieciach prywatnych (firewall e, certyfikaty, rozwiązania NAT). Część protokołów wymiany ma ponadto charakter zamknięty i korzystanie z nich wiąże się z koniecznością zakupu dodatkowego oprogramowania (np. GSX General Electric) o Koszty zakupu rozwiązań zapewniających retencję danych (w tym tworzenie kopii zapasowych) Rekurencyjne koszty stałe o Koszty rekurencyjne są w tym przypadku stosunkowo niewielkie w praktyce są to koszty eksploatacji wykorzystywanego, dedykowanego sprzętu. o W przypadku dedykowanych łącz komunikacyjnych należy liczyć się z istotnym dodatkowym kosztem Strona: 58

59 o Korzystanie z zamkniętych, objętych licencjami technologii również może oznaczać ponoszenie stałych miesięcznych kosztów Zakres przesyłanych danych W przypadku bezpośredniej integracji pomiędzy kontrahentami, zakres przesyłanych może być zupełnie dowolny zależeć on będzie w głównej mierze od potrzeb obydwu komunikujących się ze sobą stron, pamiętać jednakże należy, że obydwie strony będą musiały być wyposażone w odpowiednie oprogramowanie zdolne do obsługi wszystkich uzgodnionych komunikatów Integracja za pośrednictwem brokera EDI w standardzie EANCOM/EDIFACT W tym przypadku kontrahenci zamiast integrować swoje systemy informatyczne bezpośrednio korzystają z usług świadczonych przez tzw. brokerów EDI udostępniających swoje platformy wymiany danych B2B. Do najpopularniejszych platform EDI wspierających standard EANCOM/EDIFACT w Polsce należą: Comarch EDI firmy Comarch EDInet firmy Infinite Platforma B2B firmy Xtrade Platforma Edison firmy Edison Każda z wyżej wymienionych platform komercyjnie (odpłatnie) udostępnia swój serwer komunikatów czynny 24 godziny na dobę przez 365/366 dni w roku. Partnerzy wykupują na nim "skrzynki komunikatów", do których, o dowolnym czasie, nadawcy mogą przesyłać dokumenty wychodzące. Również o dowolnym czasie, abonent może sprawdzić stan swojej skrzynki i pobrać nadesłane dokumenty. Oprócz przechowywania, providerzy mogą udostępniać też inne usługi, np: Transformowanie formatów dokumentów przychodzących do formatu wymaganego przez odbiorcę-abonenta, Archiwizowanie dokumentów wybranych typów przez określony czas, np. faktur przez 5 lat, Usługi integracji systemów informatycznych z platformą EDI Usługi integracji z innymi operatorami EDI dzięki czemu partner może skorzystać z globalnych sieci partnerów biznesowych Strona: 59

60 Uwarunkowania prawne W przypadku integracji z udziałem operatora EDI uwzględniane są te same aspekty co w przypadku integracji bezpośredniej. Różnica polega na tym, że większość wymagań określonych w zaleceniach KE jak i wymogów polskiego prawa spełnia operator EDI. W dalszym ciągu jednak, zaleca się by strony podpisały umowę o EDI, podając w niej niezbędne dane związane z wykupioną przez siebie usługą u operatora EDI Koszty eksploatacji W odróżnieniu od integracji bezpośredniej, partnerzy wdrażający EDI za pośrednictwem operatora EDI nie ponoszą istotnych nakładów związanych z zakupem dedykowanego sprzętu. W dalszym ciągu problemem może być sam standard EANCOM/EDIFACT. Należy natomiast pamiętać, że w zamian za bezinwestycyjną możliwość uruchomienia EDI, operatorzy EDI żądają miesięcznych opłat za korzystanie z platformy Zakres przesyłanych danych W przypadku gdy obie strony wykorzystują ten sam standard komunikatów EANCOM/EDIFACT, nie ma konieczności translacji dokumentów do/z innych formatów. W tym przypadku operator EDI pełni jedynie rolę listonosza zapewniając skierowanie komunikatów do właściwego adresata. Podobnie zatem jak w przypadku integracji bezpośredniej, kontrahenci mogą wymieniać dowolne komunikaty, wg uzgodnionej specyfikacji. W przypadku, gdy kontrahenci korzystaliby z innych standardów w zakresie komunikatów niezbędne byłoby dokonanie translacji do formatów obsługiwanych przez drugiego partnera. W tym wypadku, tylko standardowe dokumenty mogłyby być bezproblemowo skonwertowane w przypadku komunikatów niestandardowych niezbędne byłoby utworzenie dedykowanych map translacji (dodatkowa płatna usługa operatora EDI) Integracja w standardzie XML Z uwagi na gigantyczną popularność standardu XML jako formatu służącego do zapisu i wymiany informacji, implementacje EDI w oparciu o ten format cieszą się coraz większą popularnością. Do sukcesu XML w obszarze EDI przyczyniły się także takie czynniki jak: Powszechność szybkich łączy internetowych dzięki temu, większa niż w przypadku standardu EDIFACT objętość komunikatów nie stanowi problemu Łatwość automatycznego przetwarzania zarówno samych komunikatów jak i dokumentów opisujących komunikaty (XML Schema, Transformacje XSL) Strona: 60

61 O wiele większa czytelność komunikatów Dostępność narzędzi i oprogramowania obsługującego XML Istnieje kilka standardów wymiany informacji pomiędzy partnerami wykorzystujących dokumenty w języku XML. Najważniejsze z nich zostały zaprezentowane krótko w kolejnych podrozdziałach ebxml oraz UBL ebxml (Electronic Business XML) jest standardem rozwijanym pod auspicjami organizacji OASIS oraz UN/CEFACT. Standard UBL jest specyfikacją towarzyszącą, komplementarną w stosunku do ebxml. Sam standard ebxml powstał z myślą o rozwiązaniu problemu jakim był brak uniwersalnych narzędzi, za pomocą których z elektronicznej wymiany danych mogły zacząć korzystać dowolne przedsiębiorstwa, niezależnie od wielkości jak i rodzaju prowadzonej działalności czy charakteru produkowanych towarów. ebxml jest w gruncie rzeczy zbiorem standardów, których cechą wspólną jest wykorzystanie języka XML oraz pokrewnych technologii (takich jak np. XML Schema). Standard ebxml cechuje bardzo duży stopień elastyczności wynikający z zastosowania technik obiektowych do modelowania informacji biznesowych. W odróżnieniu od standardu UN/EDIFACT, w którym struktura wiadomości, poszczególnych segmentów i pól danych jest bardzo ścisła, a przez to w niektórych sytuacjach nieelastyczna, ebxml promuje podejście obiektowe, w którym ustanowiono zasady opisywania informacji biznesowych oraz podstawowe komponenty służące do ich utworzenia, pozostawiając jednocześnie strukturę konkretnej wiadomości biznesowej kwestią otwartą, która powinna zostać rozwiązana na etapie analizy procesu biznesowego i zakończyć się opracowaniem jej specyfikacji (np. w formacie XML Schema dla dokumentów XML). Prace standaryzacyjne nad technologią ebxml zaowocowały powstaniem kilku standardów, łącznie zatwierdzonych jako norma ISO 15000, spośród których najistotniejsze elementy to: ISO : ebxml Collaborative Partner Profile Agreement standard ten opisuje sposób tworzenia oraz zawartość dokumentów określających profil, wymagania i preferencje danej organizacji w zakresie elektronicznej wymiany danych: o Informacje identyfikacyjne identyfikatory stron i role poszczególnych podmiotów o Informacje dotyczące bezpieczeństwa np. wymagalność podpisów elektronicznych i rodzaje algorytmów szyfrujących o Informacje dotyczące wykorzystywanych protokołów komunikacyjnych Strona: 61

62 o Definicje punktów dostępu do usług, czyli ścieżki URL oraz nazwy i specyfikacje usług dostępnych pod poszczególnymi adresami o Reguły postępowania w odniesieniu do potwierdzeń wiadomości i występowania wiadomości zduplikowanych ISO : ebxml Messaging Service Specification określa protokół wymiany danych oparty na standardize SOAP with Attachments. Protokół został przewidziany jako neutralny w stosunku do użytego protokołu komunikacyjnego, jakkolwiek najczęściej wykorzystywane w tym charakterze są protokoły http/https oraz SMTP. Sam protokół wykorzystuje zestaw metadanych umieszczonych w wiadomości SOAP, których zadaniem jest zapewnienie wymiany dokumentów w sposób gwarantujący niezawodność oraz bezpieczeństwo jego działanie można porównać do usługi pocztowej, w przypadku której istotne jest zapewnienie dostarczenia wiadomości od nadawcy do odbiorcy przy zachowaniu określonych wymagań w zakresie bezpieczeństwa i czasu dostawy. Standard ten nie określa natomiast w żaden sposób formatu wiadomości przesyłanych przy jego użyciu format ten może być dowolny i wiadomości biznesowe przesyłane są w postaci załączników zgodnie ze standardem SOAP with Attachments. Przykładowo, wiadomości mogą stanowić zarówno dokumenty zgodne ze standardem UBL jak i UN/EDIFACT. Strona: 62

63 Schemat 14. Struktura wiadomości użytkownika w standardzie ebxml/ebms ISO : ebxml Core Components Technical Specification (CCTS) standard opisuje podstawowe typy danych oraz reguły tworzenia typów złożonych a także metodologię tworzenia na ich podstawie standardowych bibliotek typów danych do wykorzystania przy budowie wiadomości wymienianych pomiędzy organizacjami. Standard ten nie opisuje konkretnych wiadomości, lecz reguły jakich należy przestrzegać przy ich tworzeniu. Standardem bazującym na CCTS i oferującym gotowy zestaw dokumentów opisanych za pomocą dokumentów XML Schema jest standard UBL. Zawiera on definicje 31 gotowych do wykorzystania wiadomości pokrywających szereg typowych procesów biznesowych: Strona: 63

64 Schemat 15. Procesy biznesowe wspierane przez standard UBL Wszystkie wiadomości biznesowe wyspecyfikowane w standardzie UBL opisane są przy pomocy dokumentów XML Schema. Dla przykładu poniżej zaprezentowano dokument faktury w standardzie UBL: <Invoice xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:qualifieddatatypes- 2"xmlns:ccts="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters- 2" xmlns:stat="urn:oasis:names:specification:ubl:schema:xsd:documentstatuscode- 1.0"xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents- 2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:commonaggregatecomponents- 2"xmlns:udt="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule:2" xmlns="urn:o asis:names:specification:ubl:schema:xsd:invoice-2"> <cbc:ublversionid>2.0</cbc:ublversionid> <cbc:customizationid> urn:oasis:names:specification:ubl:xpath:invoice-2.0:sbs-1.0-draft Strona: 64

65 </cbc:customizationid> <cbc:profileid> bpid:urn:oasis:names:draft:bpss:ubl-2-sbs-invoice-notification-draft </cbc:profileid> <cbc:id>a </cbc:id> <cbc:copyindicator>false</cbc:copyindicator> <cbc:uuid>849fbbce-e081-40b4-906c-94c5ff9d1ac3</cbc:uuid> <cbc:issuedate> </cbc:issuedate> <cbc:invoicetypecode>salesinvoice</cbc:invoicetypecode> <cbc:note>sample</cbc:note> <cbc:taxpointdate> </cbc:taxpointdate> <cac:orderreference> <cbc:id>aeg012345</cbc:id> <cbc:salesorderid>con </cbc:salesorderid> <cbc:uuid>6e09886b-dc6e-439f-82d1-7ccac7f4e3b1</cbc:uuid> <cbc:issuedate> </cbc:issuedate> </cac:orderreference> <cac:accountingsupplierparty> <cbc:customerassignedaccountid>co001</cbc:customerassignedaccountid> <cac:party> <cac:partyname> <cbc:name>consortial</cbc:name> </cac:partyname> <cac:postaladdress> <cbc:streetname>busy Street</cbc:StreetName> <cbc:buildingname>thereabouts</cbc:buildingname> <cbc:buildingnumber>56a</cbc:buildingnumber> <cbc:cityname>farthing</cbc:cityname> <cbc:postalzone>aa99 1BB</cbc:PostalZone> <cbc:countrysubentity>heremouthshire</cbc:countrysubentity> <cac:addressline> <cbc:line>the Roundabout</cbc:Line> </cac:addressline> <cac:country> <cbc:identificationcode>gb</cbc:identificationcode> </cac:country> </cac:postaladdress> <cac:partytaxscheme> <cbc:registrationname>farthing Purchasing Consortia</cbc:RegistrationName> <cbc:companyid> </cbc:CompanyID> <cbc:exemptionreason>n/a</cbc:exemptionreason> <cac:taxscheme> <cbc:id>vat</cbc:id> <cbc:taxtypecode>vat</cbc:taxtypecode> </cac:taxscheme> </cac:partytaxscheme> <cac:contact> <cbc:name>mrs Bouquet</cbc:Name> <cbc:telephone> </cbc:Telephone> <cbc:telefax> </cbc:Telefax> </cac:contact> </cac:party> </cac:accountingsupplierparty> <cac:accountingcustomerparty> <cbc:customerassignedaccountid>xfb01</cbc:customerassignedaccountid> <cbc:supplierassignedaccountid>gt </cbc:supplierassignedaccountid> <cac:party> <cac:partyname> <cbc:name>iyt Corporation</cbc:Name> </cac:partyname> <cac:postaladdress> <cbc:streetname>avon Way</cbc:StreetName> <cbc:buildingname>thereabouts</cbc:buildingname> <cbc:buildingnumber>56a</cbc:buildingnumber> <cbc:cityname>bridgtow</cbc:cityname> <cbc:postalzone>zz99 1ZZ</cbc:PostalZone> <cbc:countrysubentity>avon</cbc:countrysubentity> <cac:addressline> <cbc:line>3rd Floor, Room 5</cbc:Line> </cac:addressline> <cac:country> <cbc:identificationcode>gb</cbc:identificationcode> </cac:country> </cac:postaladdress> <cac:partytaxscheme> Strona: 65

66 <cbc:registrationname>bridgtow District Council</cbc:RegistrationName> <cbc:companyid> </cbc:companyid> <cbc:exemptionreason>local Authority</cbc:ExemptionReason> <cac:taxscheme> <cbc:id>uk VAT</cbc:ID> <cbc:taxtypecode>vat</cbc:taxtypecode> </cac:taxscheme> </cac:partytaxscheme> <cac:contact> <cbc:name>mr Fred Churchill</cbc:Name> <cbc:telephone> </cbc:Telephone> <cbc:telefax> </cbc:Telefax> </cac:contact> </cac:party> </cac:accountingcustomerparty> <cac:delivery> <cbc:actualdeliverydate> </cbc:actualdeliverydate> <cbc:actualdeliverytime>11:30:00.0z</cbc:actualdeliverytime> <cac:deliveryaddress> <cbc:streetname>avon Way</cbc:StreetName> <cbc:buildingname>thereabouts</cbc:buildingname> <cbc:buildingnumber>56a</cbc:buildingnumber> <cbc:cityname>bridgtow</cbc:cityname> <cbc:postalzone>zz99 1ZZ</cbc:PostalZone> <cbc:countrysubentity>avon</cbc:countrysubentity> <cac:addressline> <cbc:line>3rd Floor, Room 5</cbc:Line> </cac:addressline> <cac:country> <cbc:identificationcode>gb</cbc:identificationcode> </cac:country> </cac:deliveryaddress> </cac:delivery> <cac:paymentmeans> <cbc:paymentmeanscode>20</cbc:paymentmeanscode> <cbc:paymentduedate> </cbc:paymentduedate> <cac:payeefinancialaccount> <cbc:id> </cbc:id> <cbc:name>farthing Purchasing Consortia</cbc:Name> <cbc:accounttypecode>current</cbc:accounttypecode> <cbc:currencycode>gbp</cbc:currencycode> <cac:financialinstitutionbranch> <cbc:id> </cbc:id> <cbc:name>open Bank Ltd, Bridgstow Branch</cbc:Name> <cac:financialinstitution> <cbc:id> </cbc:id> <cbc:name>open Bank Ltd</cbc:Name> <cac:address> <cbc:streetname>city Road</cbc:StreetName> <cbc:buildingname>banking House</cbc:BuildingName> <cbc:buildingnumber>12</cbc:buildingnumber> <cbc:cityname>london</cbc:cityname> <cbc:postalzone>aq1 6TH</cbc:PostalZone> <cbc:countrysubentity>london</cbc:countrysubentity> <cac:addressline> <cbc:line>5th Floor</cbc:Line> </cac:addressline> <cac:country> <cbc:identificationcode>gb</cbc:identificationcode> </cac:country> </cac:address> </cac:financialinstitution> <cac:address> <cbc:streetname>busy Street</cbc:StreetName> <cbc:buildingname>the Mall</cbc:BuildingName> <cbc:buildingnumber>152</cbc:buildingnumber> <cbc:cityname>farthing</cbc:cityname> <cbc:postalzone>aa99 1BB</cbc:PostalZone> <cbc:countrysubentity>heremouthshire</cbc:countrysubentity> <cac:addressline> <cbc:line>west Wing</cbc:Line> </cac:addressline> <cac:country> <cbc:identificationcode>gb</cbc:identificationcode> </cac:country> Strona: 66

67 </cac:address> </cac:financialinstitutionbranch> <cac:country> <cbc:identificationcode>gb</cbc:identificationcode> </cac:country> </cac:payeefinancialaccount> </cac:paymentmeans> <cac:paymentterms> <cbc:note> Payable within 1 calendar month from the invoice date </cbc:note> </cac:paymentterms> <cac:allowancecharge> <cbc:chargeindicator>false</cbc:chargeindicator> <cbc:allowancechargereasoncode>17</cbc:allowancechargereasoncode> <cbc:multiplierfactornumeric>0.10</cbc:multiplierfactornumeric> <cbc:amount currencyid="gbp">10.00</cbc:amount> </cac:allowancecharge> <cac:taxtotal> <cbc:taxamount currencyid="gbp">17.50</cbc:taxamount> <cbc:taxevidenceindicator>true</cbc:taxevidenceindicator> <cac:taxsubtotal> <cbc:taxableamount currencyid="gbp">100.00</cbc:taxableamount> <cbc:taxamount currencyid="gbp">17.50</cbc:taxamount> <cac:taxcategory> <cbc:id>a</cbc:id> <cac:taxscheme> <cbc:id>uk VAT</cbc:ID> <cbc:taxtypecode>vat</cbc:taxtypecode> </cac:taxscheme> </cac:taxcategory> </cac:taxsubtotal> </cac:taxtotal> <cac:legalmonetarytotal> <cbc:lineextensionamount currencyid="gbp">100.00</cbc:lineextensionamount> <cbc:taxexclusiveamount currencyid="gbp">90.00</cbc:taxexclusiveamount> <cbc:allowancetotalamount currencyid="gbp">10.00</cbc:allowancetotalamount> <cbc:payableamount currencyid="gbp">107.50</cbc:payableamount> </cac:legalmonetarytotal> <cac:invoiceline> <cbc:id>a</cbc:id> <cbc:invoicedquantity unitcode="kg">100</cbc:invoicedquantity> <cbc:lineextensionamount currencyid="gbp">100.00</cbc:lineextensionamount> <cac:orderlinereference> <cbc:lineid>1</cbc:lineid> <cbc:salesorderlineid>a</cbc:salesorderlineid> <cbc:linestatuscode>nostatus</cbc:linestatuscode> <cac:orderreference> <cbc:id>aeg012345</cbc:id> <cbc:salesorderid>con </cbc:salesorderid> <cbc:uuid>6e09886b-dc6e-439f-82d1-7ccac7f4e3b1</cbc:uuid> <cbc:issuedate> </cbc:issuedate> </cac:orderreference> </cac:orderlinereference> <cac:taxtotal> <cbc:taxamount currencyid="gbp">17.50</cbc:taxamount> <cbc:taxevidenceindicator>true</cbc:taxevidenceindicator> <cac:taxsubtotal> <cbc:taxableamount currencyid="gbp">100.00</cbc:taxableamount> <cbc:taxamount currencyid="gbp">17.50</cbc:taxamount> <cac:taxcategory> <cbc:id>a</cbc:id> <cbc:percent>17.5</cbc:percent> <cac:taxscheme> <cbc:id>uk VAT</cbc:ID> <cbc:taxtypecode>vat</cbc:taxtypecode> </cac:taxscheme> </cac:taxcategory> </cac:taxsubtotal> </cac:taxtotal> <cac:item> <cbc:description>acme beeswax</cbc:description> <cbc:name>beeswax</cbc:name> <cac:buyersitemidentification> <cbc:id> </cbc:id> </cac:buyersitemidentification> Strona: 67

68 <cac:sellersitemidentification> <cbc:id> </cbc:id> </cac:sellersitemidentification> <cac:iteminstance> <cac:lotidentification> <cbc:lotnumberid> </cbc:lotnumberid> <cbc:expirydate> </cbc:expirydate> </cac:lotidentification> </cac:iteminstance> </cac:item> <cac:price> <cbc:priceamount currencyid="gbp">1.00</cbc:priceamount> <cbc:basequantity unitcode="kg">1</cbc:basequantity> </cac:price> </cac:invoiceline> </Invoice> GS1 XML Standard GS1 XML rozwijany przez organizację GS1 pod wieloma względami przypomina standard ebxml oraz UBL. Podobieństwa występują w szczególności w warstwie biznesowej, gdzie zdefiniowano określony katalog komunikatów biznesowych, gotowych do wykorzystania przez partnerów. Najważniejszą różnicą w stosunku do ebxml/ubl jest to, że komunikaty GS1 XML zawierają wszystkie niezbędne informacje do przesłania i przetworzenia wiadomości, podczas gdy ebxml/ubl przesyła część informacji niezbędnych do poprawnego rutingu wiadomości i zapewnienia bezpieczeństwa/integralności danych w nagłówkach SOAP a dokument biznesowy w odrębnym pojemniku (SOAP body lub MIME attachment). Tymczasem w przypadku standardu GS1 XML wszystkie te informacje zawarte są w jednym dokumencie XML. Komunikaty XML w standardzie GS1 XML mają następującą strukturę: Schemat 16. Struktura komunikatu XML w standardzie GS1 XML Poniżej przedstawiono przykładowy dokument faktury elektronicznej: <?xml version="1.0" encoding="utf-8"?><invoice:invoicemessage xmlns:invoice="urn:gs1:ecom:invoice:xsd:3" xmlns:eanucc="urn:ean.ucc:2" Strona: 68