· Web viewjest ogólnie znany. Po pierwsze, wynika z samej natury zaokrągleń i działań na liczbach zaokrąglonych – jest to sfera matematyki i nie dotyczy wyboru tego czy

Obszar wydruku SAP IS-U

- rekomendacje

Warszawa, maj 2015

str. 1

Spis treści

ZAŁOŻENIA DLA WYCENY I REALIZACJI PROJEKTU 3

1. WSTĘP 5

1.1 Zakres Projektu 5

2. ANALIZA TECHNICZNA I FUNKCJONALNA FORMULARZY 7

2.1 Zagadnienia globalne dotyczące większej liczby formularzy 72.1.1 Rekomendacja w zakresie wyłączenia nieużywanych formularzy 72.1.2 Rekomendacja w zakresie zmiennych i flag dla layoutu 122.1.3 Rekomendacja w zakresie informacji o zgodach marketingowych 16

2.2 Formularze faktur MO / WO / TPA 192.2.1 Rekomendacja w zakresie nazwy produktu 192.2.2 Rekomendacja w zakresie odsetek 232.2.3 Rekomendacja w zakresie różnic groszowych 272.2.4 Rekomendacja w zakresie kwot w podsumowaniach 352.2.5 Rekomendacja w zakresie parametryzacji formularzy 372.2.6 Rekomendacja w zakresie formatowania danych 402.2.7 Rekomendacja w zakresie utworzenia nowego formularza faktury 41

2.3 Zlecenie serwisowe i windykacyjne 452.3.1 Rekomendacja w zakresie wydruku informacji o liczniku 46

2.4 Wydruki SD 472.4.1 Rekomendacja w zakresie sposobu wydruku blankietu wpłaty 472.4.2 Rekomendacja w zakresie sterowania stopką wydruku 482.4.3 Rekomendacja w zakresie miejsca dostarczania energii 482.4.4 Rekomendacja w zakresie harmonizacji formularza 49

3. ANALIZA NAJCZĘSTSZYCH BŁĘDÓW I WYJĄTKÓW 51

3.1 Ocena błędów i wyjątków 513.1.1 Rekomendacja po stronie aplikacyjnej 513.1.2 Rekomendacja po stronie danych źródłowych 51

3.2 Ogólne zalecenia w zakresie obsługi procesu 543.2.1 Rekomendacja w zakresie wprowadzania zmian developerskich 54

4. ANALIZA SEGMENTACJI KLIENTÓW 55

4.1 Wsparcie segmentacji w ramach SAP IS-U 554.1.1 Rekomendacja w zakresie reorganizacji zmiennych segmentacyjnych 554.1.2 Rekomendacja w zakresie utworzenia raportu 56

str. 2

Założenia dla wyceny i realizacji projektu

Zakłada się realizację w ramach projektu GTS Printing, tj równolegle z upgrade i rozszerzeniem funkcjonalności Streamserve. Niemniej jednak założeniem projektu jest generowanie dotychczasowego zakresu zmiennych RDI, chyba że konkretna rekomendacja opisana w niniejszym dokumencie stanowi inaczej.

Zakłada się realizację wszystkich rekomendacji równolegle i jeden Go Live.

Zakłada się że Go Live nastąpi na początku 2016 roku, prosimy o zawarcie propozycji harmonogramu prac w ofercie uwzględniając okres wsparcia po stracie 10 tygodni po Go Live.

Prosimy o wyszczególnienie kosztu realizacji poszczególnych rekomendacji w ramach oferty.

Zestawienie rekomendacji dla poszczególnych formularzy prezentuje poniższa grafika.

str. 3

Zestawienie rekomendacji dla formularzy SAP IS-U

str. 4

1. Wstęp

1.1 Zakres Projektu

Szczegółowa lista formularzy objętych Projektem:

a) Formularze AKTYWNE:

Lp. Nazwa dokumentu Nazwa formularza aplikacji (PWB) Nazwa formularza (SapScript)

1 Faktury MO Z_RWS_BI_BILL_MO ZRWS_FORM02

2 Faktury WO Z_RWS_BI_BILL_WO ZRWS_FORM_WO

3 Faktury TPA Z_RWS_BI_BILL_TPA ZRWS_FORM_TPA

4 Zestawienia zbiorcze Z_RWS_BI_BILL_COVER ZRWS_BI_BILL_COV

5 Faktury zagregowane Z_RWS_BI_BILL_AGGR ZRWS_FORM_GUD

6 Faktury GUD Sprzedaż Z_RWS_BI_BILL_GUD_S ZRWS_FORM_GUD_S

7 Faktury GUD Z_RWS_BI_BILL_GUD_BILLFORM Z_IS_U_BI_BILL

11 Zestawienie informacji o koncie Z_RWS_CA_ACCTINFO_MO ZRWS_FORM35

12 Zestawienie należności Z_RWS_CA_PAYFORM_MO ZRWS_FORM13

13 Raty WO Z_RWS_CA_SLDOCUMENT ZRWS_FORM27

14 Zestawienie rat WO Z_RWS_CA_SLDOCUMENT_COV ZRWS_FORM36

15 Pismo powitalne Z_RWS_CS_MOVE_IN ZRWS_FORM19

16 Pismo pożegnalne Z_RWS_CS_MOVE_OUT ZRWS_FORM18

17 Niestosowane w wydruku Z_RWS_DM_DOWNLOAD Z_RWS_MR_DOWNLOA

18 Niestosowane w wydruku Z_RWS_DM_DOWNLOAD_ADO Z_RWS_MR_DOWNAD1

16 Zestawienia ROR ABAP: /RWS/CA_DTA_LISTE_1R ZRWS_FORM05

str. 5

17 Zlecenia windykacyjne IT4M ABAP: /RWS/WYDRUK_ZLECENIA_WINDYK ZRWS_FORM44

18 Zlecenia serwisowe IT4M ABAP: /RWS/ISU_ORDER_FROM ZRWS_ORDER_FROM

19 Zawiadomienia serwisowe ABAP: ZRWS_REPRSN00 ZRWS_FORM23

20 Faktury SD / Rachunki / Noty obciążeniowe ABAP: ZRWS_SDST_INV003 ZRWS_SDST_INV003

b) Formularze NIEUŻYWANE – do wyłączenia:

Lp. Nazwa formularza aplikacji (PWB) Nazwa formularza (SapScript)

1 Z_RWS_BI_BILL_SK ZRWS_BI_BILL_SK

2 Z_RWS_BI_BILL_ZA ZRWS_FORM40

3 Z_RWS_BI_COLLBI ZRWS_BI_COLLBI

4 Z_RWS_CA_ACCTINFO ZRWS_CA_ACINF

5 Z_RWS_CA_BALANOTE ZRWS_CA_BANO

6 Z_RWS_CA_BALANOTE_MO ZRWS_FORM34

7 Z_RWS_CA_CASHPAYMENT ZRWS_FORM09

8 Z_RWS_CA_CASHPAYMENT_MO ZRWS_FORM42

9 Z_RWS_CA_SLDOCUMENT_K ZRWS_FORM28

10 Z_RWS_CA_SLDOCUMENT_MO ZRWS_FORM04

11 Z_RWS_CS_DISC_ORDER ZRWS_FORM21

12 Z_RWS_CS_DISC_ORDER_MO ZRWS_FORM32

13 ABAP: /RWS/MD_UMOWY_V03 ZRWS_FORM29

Lista formularzy z założenia nieobjętych Projektem / analizą:

str. 6

Lp. Nazwa dokumentu Nazwa formularza aplikacji (PWB) Nazwa formularza (SapScript)

1 Monity / upomnienia WO Z_RWS_CA_DUNNING ZRWS_FORM07

2 Monity / upomnienia MO Z_RWS_CA_DUNNING_MO ZRWS_FORM08

3 Monity / upomnienia GUD Z_RWS_CA_DUNNING_GUD ZRWS_FORM45

4 Potwierdzenie salda Z_RWS_CA_GPARTBALA ZRWS_FORM12

5 Plany ratalne Z_RWS_CA_INSTPLAN ZRWS_FORM10

6 Noty odsetkowe MO Z_RWS_CA_INTEREST_MO ZRWS_FORM14

7 Noty odsetkowe WO Z_RWS_CA_INTEREST ZRWS_FORM37

2. Analiza techniczna i funkcjonalna formularzy

W wyniku analizy techniczno-funkcjonalnej formularzy zwrócono uwagę na wiele istotnych problemów.

Poniżej opisano rekomendacje dotyczące najważniejszych kwestii. Tam, gdzie uważano za zasadne, zaproponowano szczegółowe rozwiązanie. Określono również priorytety opisujące wagę poruszanych kwestii, istotne zarówno z punktu widzenia prawidłowego działania funkcjonalności, jak i dalszego rozwoju formularzy oraz utrzymania po stronie suportowej.

2.1 Zagadnienia globalne dotyczące większej liczby formularzy

Niektóre dane przekazywane do StreamServe’a dotyczą większej liczby formularzy. Poniżej opisano najważniejsze rekomendacje w tym obszarze.

2.1.1 Rekomendacja w zakresie wyłączenia nieużywanych formularzy

str. 7

Zgodnie z wymaganiami Strony Biznesowej poniższe formularze powinny zostać wyłączone, jako nieaktualne:

Nazwa formularza Stan aktualny Rekomendacja Priorytet

Z_RWS_BI_BILL_SK

Możliwość błędnego skorzystania

z nieaktualnych formularzy

Wyłączenie nieaktualnych formularzy

Wysoki

Z_RWS_BI_BILL_ZA

Z_RWS_BI_COLLBI

Z_RWS_CA_ACCTINFO

Z_RWS_CA_BALANOTE

Z_RWS_CA_BALANOTE_MO

Z_RWS_CA_CASHPAYMENT

Z_RWS_CA_CASHPAYMENT_MO

Z_RWS_CA_SLDOCUMENT_K

Z_RWS_CA_SLDOCUMENT_MO

Z_RWS_CS_DISC_ORDER

Z_RWS_CS_DISC_ORDER_MO

ZRWS_FORM29 / ABAP: /RWS/MD_UMOWY_V03

Stan obecny

Obecnie istnieje możliwość wydruku dokumentu również na nieaktualnych formularzach.

Przykład: Z_RWS_BI_BILL_SK – formularz wydruku faktur Wielkiego Odbioru funkcjonował przed projektem „Nowa Faktura”, w jego miejsce powstał nowy formularz Z_RWS_BI_BILL_WO, natomiast „stary” program wciąż jest dostępny, dlatego zdarzają się przypadki wykorzystania formularza (FV 221013738456 / KU 88000229852).

str. 8

Realizacja

12 formularzy z powyższej listy, to formularze aplikacji (PWB). Natomiast ostatni – SapScript ZRWS_FORM29 uruchamiany jest przez program ABAP: /RWS/MD_UMOWY_V03.

a) Dezaktywacja formularza aplikacji (PWB) w systemie SAP IS-U

W celu dezaktywacji formularza aplikacji w systemie SAP IS-U należy usunąć referencję do danego formularza na mandancie, na którym ten formularz jest używany. (Uwaga: niedozwolone jest usuwanie formularza na mandantach 000/050).

W celu usunięcia referencji, należy postępować następująco:

1. Uruchomić transakcję EFRM (Opracowanie formularza aplikacji).

2. Wybrać odpowiedni formularz, dla przykładu Z_RWE_BI_BILL_SK.

3. Na ekranie opracowania formularza wybrać opcję „Usuń”:

4. Usunąć referencję:

str. 9

5. W ten sposób referencja zostanie usunięta.

6. Po usunięciu referencji wskazany formularz nie będzie widoczny na liście wyboru w transakcjach korzystających ze słownika formularzy, dla przykładu CAA3 (Wyświetlanie konta umowy).

Widok przed usunięciem referencji:

str. 10

Po usunięciu referencji:

UWAGI:

W kontekście każdego dezaktywowanego formularza należy przeprowadzić analizę wpływu na dane podstawowe (np. przypisanie formularza faktury na koncie umowy) oraz konfigurację SPRO wraz z kodem ABAP.

W celu masowego odpięcia formularzy można wykorzystać standardowy program EFG_DELETE_LINKS (Środowisko wydruku: Usuwanie odsyłaczy).

Dodatkowo proponuje się wziąć pod uwagę wyłączenie nieużywanych formularzy aplikacji Z_RWS_DM_DOWNLOAD (SapScript Z_RWS_MR_DOWNLOA) oraz Z_RWS_DM_DOWNLOAD_ADO (SapScript Z_RWS_MR_DOWNAD1).

b) Propozycja dezaktywacji formularza SapScript ZRWS_FORM29 i programu ABAP /RWS/MD_UMOWY_V03:

usunięcie transakcji /RWS/MD_UMOWY_V03 z systemu SAP IS-U, aby raport nie pojawił się już w rolach i uprawnieniach Użytkowników,

usunięcie programu z drzewka raportów /RWS/STOENMENU (Menu STOEN),

można również rozważyć modyfikację programu, która uniemożliwi uruchomienie z poziomu transakcji SE38, a dodatkowo zainicjuje wyświetlenie informacji w postaci okna typu popup.

UWAGA: przed wykonaniem powyższych działań proponuje się uzyskanie zgody osoby odpowiedzialnej za obszar Danych Podstawowych po Stronie Biznesowej, ponieważ Użytkownicy zgłaszają potrzebę sporadycznego korzystania z programu.

str. 11

2.1.2 Rekomendacja w zakresie zmiennych i flag dla layoutu

Proponuje się standaryzację sposobu wyznaczania zmiennych i flag przeznaczonych dla layoutu (StreamServe’a), polegającą na przeniesieniu logiki z formularzy do modułu funkcyjnego /RWS/GET_LAYOUT_FLAG.


Z_RWS_BI_BILL_MO

Niezgodna ze standardem obsługa zmiennych i flag

dla layoutu

Poprawa obsługi zmiennych i flag dla

layoutuŚredni

Z_RWS_BI_BILL_WO

Z_RWS_BI_BILL_TPA

Z_RWS_BI_BILL_AGGR

Z_RWS_BI_BILL_GUD_S

Z_RWS_BI_BILL_COVER

Z_RWS_CA_SLDOCUMENT

Z_RWS_CA_SLDOCUMENT_COV

Z_RWS_CA_ACCTINFO_MO

Z_RWS_CA_PAYFORM_MO

Z_RWS_CS_MOVE_IN

Z_RWS_CS_MOVE_OUT

ZRWS_FORM05

ZRWS_SDST_INV003

ZRWS_FORM44

ZRWS_ORDER_FROM

ZRWS_FORM23

Opcjonalnie: Z_RWS_BI_BILL_GUD_BILLFORM

str. 12

Stan obecny

Formularze przekazują do StreamServe’a kilkanaście zmiennych i flag (znaczników), które nie są drukowane na dokumentach, natomiast – oprócz formatowania tekstu, wyboru odpowiedniej grafiki, poddruku i kopertowania – służą do określenia danych adresowych Sprzedawcy, czy też do segmentacji i działań marketingowych.

Lista zmiennych i flag zdefiniowanych dla potrzeb layoutu i StreamServe’a:

G_RWS_PRZES G_RWS_PLIK G_TPA G_ZALICZKA_ZB G_RWS_ECO G_CHKL G_SPRZEDAWCA G_VIP G_RODZ_UMOWY G_RODZAJ_ODBIORU G_NAMED_CLERK G_MARKETING_APPR WA_DOCMON_D-DOC_UID WA_DOCMON_S-SPOOL_UID

Cześć z powyższych zmiennych nie znajduje się w systemie (nie jest przechowywana w bazie danych), natomiast zostaje wyznaczona ad hoc. Wartości ustalane są w wielu miejscach poszczególnych formularzy. Logika wyboru danych wymaga uporządkowania.

Przykładowe wartości zmiennej G_CHKL („charakter klienta”) wyznaczane w formularzu Z_RWS_BI_BILL_MO (include Z_RWS_BI_BILL_MO_EXIT_050 i sekcja globalna ZRWS_AF_FORM_TOP):

str. 13

Fragment kodu określającego wartość zmiennej G_SPRZEDAWCA:

Wysoka parametryzacja zmiennej G_RODZ_UMOWY:

str. 14

Realizacja

Top include ZRWS_AF_FORM_TOP zawiera deklarację większości zmiennych i flag dla layoutu. Odwołują się tu formularze:

Z_RWS_BI_BILL_MO Z_RWS_BI_BILL_COVER Z_RWS_BI_BILL_AGGR Z_RWS_CA_ACCTINFO_MO Z_RWS_CA_PAYFORM_MO Z_RWS_CA_SLDOCUMENT Z_RWS_CA_SLDOCUMENT_COV Z_RWS_CS_MOVE_IN Z_RWS_CS_MOVE_OUT

Natomiast top include Z_RWS_NF_WO_ZBIOR_FORM_TOP zawiera deklarację zmiennych do których odwołują się formularze:

Z_RWS_BI_BILL_WO Z_RWS_BI_BILL_TPA Z_RWS_BI_BILL_GUD_S

Zmienne trafiają do Spoola i pliku RDI poprzez wspólną sekcję danych globalnych Z_RWS_STRD_GLOBAL_DATA. Proponuje się pozostawienie prezentacji zmiennych w sekcji, natomiast logika wyboru powinna być przeniesiona do jednego wspólnego modułu funkcyjnego, np. /RWS/GET_LAYOUT_FLAG.

str. 15

Jednocześnie proponuje się rozważyć możliwość przeniesienia „wybranych pól” z formularzy na stałe do systemu, np. na poziom PH/KU. Dzięki temu Użytkownik miałby możliwość pełnej weryfikacji informacji, które nie tylko wpływają na treść i wygląd faktury, ale również sterują korespondencją.

Więcej na temat zmiennych służących segmentacji można przeczytać w Rozdziale 4. Analiza segmentacji Klienta.

UWAGA:

Planowana jest zmiana logiki wyboru SPOOL_UID w systemie SAP IS-U. Dlatego do chwili ustalenia szczegółów dopuszcza się niewłączanie zmiennych WA_DOCMON_D-DOC_UID i WA_DOCMON_S-SPOOL_UID do nowego modułu funkcyjnego. Temat opisany zostanie w odrębnym punkcie dot SPOOL_UID.

Modyfikacja formularza Z_RWS_BI_BILL_GUD_BILLFORM jest opcjonalna, zależna od bieżących potrzeb layoutu.

Do StreamServe’a przekazywane są również zmienne związane ze zgodami marketingowymi, które odpowiedzialne są m.in. za obsługę e-faktury. Więcej informacji poniżej w: Rekomendacja w zakresie informacji o zgodach marketingowych.

2.1.3 Rekomendacja w zakresie informacji o zgodach marketingowych

Proponuje się zmianę sposobu wyznaczania zmiennych/zgód marketingowych, polegającą na przeniesieniu logiki z formularzy do modułu funkcyjnego.


Z_RWS_BI_BILL_MO

Niezgodna ze standardem obsługa zmiennych/zgód marketingowych

Poprawa obsługi zmiennych/zgód marketingowych

Średni

Z_RWS_BI_BILL_WO

Z_RWS_BI_BILL_TPA

Z_RWS_BI_BILL_GUD_S

Z_RWS_BI_BILL_COVER

Z_RWS_BI_BILL_AGGR

Z_RWS_CA_SLDOCUMENT

str. 16


Z_RWS_CA_PAYFORM_MO

Inne w zależności od potrzeb

Stan obecny

Dla potrzeb obsługi formularzy po stronie StreamServe’a przekazywane są informacje o zgodach marketingowych oznaczonych w systemie SAP IS-U na poziomie PH/KU, np. „Zgoda na emisję elektroniczną faktur” (000001). Wybór danych odbywa się w kilku miejscach. Sytuacja dotyczy wielu formularzy. Konieczna jest standaryzacja tego obszaru.

Przykładowe zmienne marketingowe przekazywane do StreamServe’a:

G_RWS_ECO – odpowiada zgodzie marketingowej 000001 AKC_ZGODA – odpowiada zgodzie marketingowej 000004 AGRE – odpowiada zgodzie marketingowej 000005 AGRE7 – zmienna wyznaczana na podstawie zgody marketingowej 000007

Fragment formularza Z_RWS_BI_BILL_MO / Z_RWS_BI_BILL_MO_EXIT_050:

Realizacja

W celu standaryzacji obszaru, proponuje się przeniesienie logiki wyboru powyższych zmiennych marketingowych z formularzy do modułu funkcyjnego, np. /RWS/GET_AGRE_FORMS.

Główne obiekty techniczne do modyfikacji:

a) wspólne sekcje globalne:

ZRWS_AF_FORM_TOP

str. 17

Z_RWS_NF_WO_ZBIOR_FORM_TOP

b) user exity:

Z_RWS_BI_BILL_AGGR_EXIT_050

Z_RWS_BI_BILL_COVER_EXIT_050

Z_RWS_BI_BILL_GUDSF01

Z_RWS_BI_BILL_GUD_S_EXIT_050

Z_RWS_BI_BILL_MO_EXIT_050

Z_RWS_BI_BILL_TPAF01

Z_RWS_BI_BILL_TPA_EXIT_050

Z_RWS_BI_BILL_WOF01

Z_RWS_CA_PAYFORM_MO_EXIT_050

Z_RWS_CA_SLDOC_COV_EXIT_050

Z_RWS_CA_SLDOC_EXIT_050

Z_RWS_CA_SLDOC_K_EXIT_050

Z_RWS_CA_SLDOC_MO_EXIT_050

UWAGI:

1) Realizacja rekomendacji wymaga przeniesienia logiki wyboru zmiennych marketingowych z formularzy do modułu funkcyjnego. Proponuje się, aby utworzyć dedykowany moduł dla potrzeb obsługi zgód marketingowych, np. /RWS/GET_AGRE_FORMS. Jednocześnie dopuszcza się, aby zmienne włączyć do /RWS/GET_LAYOUT_FLAG, co również będzie lepszym rozwiązaniem od stanu obecnego.

2) W ramach wdrożenia niniejszej rekomendacji proponuje się rozważyć możliwość uporządkowania nazewnictwa zmiennych (G_RWS_ECO, AKC_ZGODA, AGRE, AGRE7). Jednakże należy przy tym pamiętać, że realizacja pociągnie za sobą również konieczność dostosowania programu po stronie StreamServe.

3) Powyżej wskazano listę formularzy dla których modyfikacja będzie zalecana, natomiast inne formularze w zależności od potrzeb (modyfikacja sekcji globalnych typu ZRWS_AF_FORM_TOP będzie pośrednio widoczna w wielu różnych formularzach, np. Z_RWS_CA_ACCTINFO_MO – Należności płatnika MO, chociaż formularz nie obsługuje funkcjonalności zgód marketingowych).

str. 18

2.2 Formularze faktur MO / WO / TPA

2.2.1 Rekomendacja w zakresie nazwy produktu

Proponuje się zmianę sposobu wyznaczania nazwy produktu – przeniesienie logiki z formularzy do modułu funkcyjnego /RWS/GET_PRODUKT_NAME.


Z_RWS_BI_BILL_MO

Niezgodny ze standardem sposób wyboru produktu

Przeniesienie logiki do modułu funkcyjnego, np. /RWS/GET_PRODUKT_NAME

WysokiZ_RWS_BI_BILL_WO

Z_RWS_BI_BILL_TPA

Przykład nazwy produktu na fakturze (usunięto nazwisko Klienta):

str. 19

Stan obecny

Drukowane na fakturach MO/WO/TPA nazwy produktów posiadają stosunkowo skomplikowaną, rozmytą logikę. Konieczna jest standaryzacja tego obszaru, w szczególności zweryfikowanie i przeniesienie logiki wyznaczania nazwy produktu z formularzy do modułu funkcyjnego /RWS/GET_PRODUKT_NAME.

Realizacja

Celem jest zweryfikowanie i przeniesienie logiki wyznaczania nazwy produktu z formularzy do modułu funkcyjnego /RWS/GET_PRODUKT_NAME, wykonywanego podczas eventu np. R436 – „IS-U INV: Wypełnianie pól klienta” w procesie tworzenia dokumentu wydruku. Znaleziony produkt zostanie zapisany w tabeli DBERDL (Linie dokumentu wydruku) w stworzonym do tego celu polu /RWS/PROD_NAME. Z tego miejsca nazwa produktu będzie pobierana w procesie wydruku formularza.

Propozycja działania procesu wyznaczenia nazwy produktu na dokumencie wydruku:

A. Pozyskanie danych podstawowych.

1. Sprawdzamy przypisany formularz aplikacji.

2. Wyznaczamy datę dokumentu wydruku (tabele ERCH/ERHC), instancję, konto umów, umowy i taryfy.

3. Dla umowy kompleksowej korzystamy z instalacji sprzedażowej.

4. Dla kont umów z zaznaczonym parametrem ZZINVLEVEL (Poziom fakturowania / Faktura dla KU) należy wyszukać produkt dla każdej umowy osobno (przykład z systemu produkcyjnego SP1: FV 220003955266).

B. Produkty rabatowe. Ustalenie nazwy produktu z projektu Godzilla Rabaty/Paczki

5. Dla pozycji dokumentu rozliczeniowego w strukturze ERDZ o typie BELZART równym XPROD (ID produktu –rabaty –nieaktualny) lub ZPROD (ID produktu –rabaty) pobieramy ID produktu z pola I_ZAHL1.

6. Jeśli wiersze typu XPROD lub ZPROD nie zostaną znalezione, to przechodzimy do punktu C.

7. Na podstawie ID produktu przeprowadzamy selekcję nazwy produktu z tabeli /RWS/BL_RAB_PROD (ISU/Rabaty: Produkty).

8. Jeśli nazwa produktu nie znajduje się w tabeli /RWS/BL_RAB_PROD, to przechodzimy do punktu C.

str. 20

C. Produkty rabatowe dla zaliczek.

9. Sprawdzamy czy istnieją pozycje dokumentu rozliczeniowego w strukturze ERDZ o typie BELZART równym BBP (Poz. Zaliczki/faktury częściowe).

10. Dla konkretnej umowy wyznaczamy daty z planu zaliczkowego (EABP). Gdy nie znajdujemy wpisu, daty wyznaczamy z okresu rozliczeniowego.

11. Gdy w tabeli ETTIFN istnieje operand FAC-IDPROD (ISU/Rabat: ID produktu) w dany przedziale czasu i jest aktywny, to pobieramy pole WERT1.

12. Z wartością pola WERT1 wykonujemy selekcję w tabeli /RWS/BL_RAB_PROD.

D. Produkty pozataryfowe – Ceny ofertowe. Ustalenie nazwy produktu przy pomocą zdarzenia funkcyjnego /RWS/CENNIK_GET_PRODUKT_NAME (przykład z systemu testowego SQ1: FV 220003672035).

13. Cennik znajduje się w tabelach /RWS/CO_CENY oraz /RWS/CEN_PRODT. Dane są wybierane na podstawie wierszy ze struktury ERDZ, pola I_ZAHL1 (cennik), I_ZAHL2 (cena), gdy pole BELZART (Rodzaj pozycji dokumentu) jest równe XCEOF1-6 (Cena ofertowa) lub gdy pole BELZART jest równe BBP i pole TVORG jest równe 1036.

14. Sprawdzane są wszystkie wiersze konkretnej faktury w strukturze ERDZ. Jeśli na podstawie informacji z ww. wierszy dokumentu rozliczeniowego ustalona zostanie nazwa produktu, wówczas proces jest zakończony, a jeśli nie – przechodzimy do punkt E.

E. Produktu z oferty indywidualnej. Oferta indywidualna z tabeli sterującej ZRWS_OFIND_FORM

15. Na podstawie typu formularza wyszukujmy operandy w tabeli ZRWS_OFIND_FORM.

16. Wyszukujemy aktualne operandy dla instalacji zawartych w dokumentach rozliczeniowych dokumentu wydruku.

17. Sprawdzamy czy istnieją w instalacji operandy takie jak znalezione w tabeli ZRWS_OFIND_FORM.

18. Jeśli takie operandy zostaną znalezione, produkt nazywamy Oferta indywidualna.

F. Produkty taryfowe. Sprawdzany jest aktualny typ taryfy (pole TARIFTYP) na datę wystawienia faktury

19. Typ taryfy zostanie ustalony na poziomie instalacji lub z wierszy dokumentu rozliczeniowego. Informacja z instalacji ma pierwszeństwo przed wierszami.

str. 21

20. Na podstawie typu taryfy oraz daty zakończenia aktualnego okresu rozliczeniowego przeprowadzona zostanie selekcja z tabeli ZRWS_BI_TTTE (Przykład z SQ1: FV 999001383247).

21. Jeśli faktura zawiera wiersz z typem taryfy TPA i TC1, nazwa produktu zostanie wybrana z VIEW V_ETTA (standard rate category) z pola TTYPBEZ.

22. Sprawdzamy czy jest to taryfa budowlana. Jeśli pole ZZBRANZ w umowie jest równe 46 i taryfa dla pozycji dokument rozliczeniowego 02_TPA21 lub 02_TPA22 lub 02_EC11 lub 02_EC12A lub 02_EC12B lub TC1, wówczas produkt nazywamy Budowlana.

Podczas tworzenia korekt dokumentu wydruku, nazwę produktu należy pobrać z pola /RWS/PROD_NAME tabeli DBERDL korygowanego dokumentu. Gdy pole jest puste, moduł funkcyjny /RWS/GET_PRODUKT_NAME wyznacza produkt dla korekty dokumentu wydruku. Nazwa produktu korekty może, w niektórych przypadkach, różnić się od nazwy produktu dokumentu korygowanego ze względu na zmianę logiki wyznaczania nazwy produktu, np. Dystrybucja 10+14, Energia non stop, itd. W tym celu zalecane jest uzupełnienie pola /RWS/PROD_NAME dla każdego dokumentu wydruku.

2.2.2 Rekomendacja w zakresie odsetek

Proponuje się zmianę rozliczania odsetek i wydruku odsetek na poniższych formularzach:


Z_RWS_BI_BILL_MO

Niezgodna ze standardem obsługa odsetek

Zmiana rozliczania i wydruku odsetek

WysokiZ_RWS_BI_BILL_TPA


Stan obecny

W procesie wydruku formularza, dla zaliczek z planu zaliczkowego i faktury rozliczeniowej system zapisuje tabele /RWS/CA_OD_MIG (Migrierte Zinsbelege für Drucksteuerung) danymi w kombinacji: numer noty odsetkowej (dokument OD) / numer faktury rozliczeniowej / numer faktury zaliczkowej. Wskazując tym samym na której zaliczce zostały uwzględnione odsetki

str. 22

w danym okresie rozliczeniowym. Noty odsetkowe przypisane są obecnie do wszystkich dokumentów zaliczek.

Podczas projektu Nowa Faktura dane z innych procesów były zapisywane do powyższej tabeli, co doprowadziło do wielu błędów. W następstwie zmieniono formularz MO i TPA w taki sposób, że do ww. tabeli zapisywane były tylko dane dotyczące odsetek, a reszta danych została zapisana w „nowej wersji” tabeli MIG, tj. /RWS/CA_OD_NF (Migrierte Zinsbelege für Drucksteuerung).

Po stronie FI-CA tabela wykorzystywana jest w ramach rozliczania i automatycznego rozliczania wpłat bankowych. Podczas clearingu program kontroluje w tabeli /RWS/CA_OD_MIG kombinacje faktury rozliczeniowej, odsetki oraz zaliczki. Proces wykorzystuje funkcjonalność zawartą w grupie funkcyjnej /RWS/CA_FIND_DOCS.

Przykłady dokumentów w systemie SQ1:

222008171284 – Faktura rozliczeniowa

222008790762 – Faktura zaliczkowa 1 / 222008809299 – Faktura zaliczkowa 2 / 221012299478 – Faktura zaliczkowa 3

301606349861 – Plan rozliczenia zaliczek

50201945453, 50201945452 – Noty odsetkowe

Przykład odsetek na fakturze rozliczeniowej (usunięto nazwisko Klienta):

Przykład odsetek na fakturze zaliczkowej:

str. 23

Przykładowe dane w tabeli /RWS/CA_OD_MIG:

Realizacja

Realizacja w ramach odrębnego projektu 15.029 i 15.005 Poprawa naliczania odsetek, będzie on zakończony w momencie startu prac wdrożeniowych niniejszych rekomendacji musi to zostać uwzględnione w ramach prac. W razie potrzeby weryfikacji zależności RWE prześle specyfikację obecnie wykonywanych prac.

2.2.3 Rekomendacja w zakresie różnic groszowych

Proponuje się weryfikację i możliwą zmianę sposobu zaokrąglania i prezentacji wartości liczbowych w formularzach.


str. 24

Z_RWS_BI_BILL_MO

Różnice groszowe na wydrukach

Zmiana sposobu zaokrąglania i prezentacji kwot

WysokiZ_RWS_BI_BILL_WO


Stan obecny

Problem różnic groszowych jest ogólnie znany. Po pierwsze, wynika z samej natury zaokrągleń i działań na liczbach zaokrąglonych – jest to sfera matematyki i nie dotyczy wyboru tego czy innego systemu liczącego. Druga przyczyna natomiast wiąże się już z działaniem konkretnych programów drukujących / formularzy. Formularze SAP IS-U nie tylko „układają” dane dla potrzeb prezentacji (layoutu) na wydruku, ale również wykonują bardzo dużo „dodatkowych” działań – pobierają dane, przetwarzają, formatują i zaokrąglają wartości. Wykonują wreszcie wiele działań rachunkowych, w tym wyliczanie kwot Netto/Vat/Brutto, wielkości akcyzy, wartości zarówno w pozycjach, jak i w podsumowaniach – sprzedaży i dystrybucji energii, w fakturach rozliczeniowych, w fakturach korygujących czy też kolejnych korektach. Wszystkie te czynności składają się na to, że pozornie błahy problem niespójności groszowych prezentowanych na wydrukach w rzeczywistości nie jest trywialny.

Problem zresztą został zauważony już na etapie realizacji projektu Nowa Faktura, gdy nie tylko modyfikowano dotychczasowe programy drukujące, ale również przygotowywano nowe formularze, np. WO czy TPA.

Ważne punkty z koncepcji Nowej Faktury:1

1) W przypadku faktur zaliczkowych, z uwagi na sposób wyliczania podatku VAT (oddzielnie od sprzedaży i dystrybucji) ukazany podatek VAT może różnić się od kwoty wyliczonej ręcznie (czyli od kwoty netto ukazanej na fakturze).

2) Uwzględniając sposób wyliczania podatku VAT w ISU (od sumy wszystkich składników obrotu oraz od wszystkich składników dystrybucji) – podsumowanie podatku VAT oraz wartości brutto może różnić się od sumy poszczególnych składników.

3) Podatek VAT dla poszczególnych składników oraz wartość brutto będą wyliczane bezpośrednio „na formularzu” SAP I-SU i zaokrąglane do 2 miejsc po przecinku (co do grosza).

Po wdrożeniu Nowej Faktury miały miejsce próby rozwiązania problemu, m.in. w ramach działań stabilizacyjnych (NFS, SUS), jak również w ramach Requestów (np. CR14.056). Niektóre sytuacje zostały w ten sposób naprawione.

1 Specyfikacja funkcjonalna projektu Nowa Faktura DO bez TPA jest dostępna w formie elektronicznej pod adresem: http://wiki/download/attachments/19759769/2013-07-24+Nowa_Faktura+DO_bez_TPA_specyfikacja_ver7.1.pdf?version=1&modificationDate=1374676763000

str. 25

Globalny sposób rozwiązania kwestii „różnic groszowych” wymagałby przeniesienia punktu ciężkości wyliczania wartości liczbowych bliżej obszaru billingu, aby formularz wydruku posiadał więcej (wszystkie) gotowych do wydruku danych. To wymagałoby wprowadzenia dużej zmiany po stronie procesu i organizacji danych billingowych. Dlatego zamiast radykalnego rozwiązania sięgającego obszaru Billingu, proponuje się weryfikację sposobu wyboru i przetwarzania danych w poszczególnych formularzach i usunięcie niespójności w aktualnych algorytmach.

Realizacja

Przypadek 1

Formularz: Z_RWS_BI_BILL_WO

Na fakturze rozliczeniowej (w formularzu na pierwszej stronie) zostaje błędnie rozbita wartość zaliczki na kwoty Netto, VAT – niezgodnie z oryginalnym dokumentem zaliczki.

Przykład

Przykładem jest KU 70000045702 – Faktura VAT nr 221011816801 z dnia 01.08.2014, Faktura VAT nr 330000471409 z dnia 10.06.2014.

W oryginale zaliczka: netto 5 691,06; vat 1 308,94; brutto 7 000,00.

Na fakturze rozliczeniowej: netto 5 691,05; vat 1 308,95; brutto 7 000,00.

str. 26

Faktura VAT nr 330000471409 z dnia 10.06.2014:

Pozycja JG Konto KG Kwota Suma1 1000 3587101 673,17

1308,942 2000 3587101 635,773 2000 4000109 2764,23

5691,064 1000 4000805 2926,83

Analiza

Błąd wynika z obliczania podatku VAT jako sumy podatków VAT obliczanych dla pojedynczych pozycji.

W pierwszym kroku dla wszystkich rozliczeń pobierane są wartości brutto, następnie obliczane kwoty podatku i kwota netto wykorzystując poniższy moduł funkcyjny:

CALCULATE_TAX_FROM_GROSSAMOUNT.

str. 27

Przekazując do funkcji kwotę brutto 1700 zł otrzymujemy kwotę netto 1382,11 oraz podatek 317,89. Drugą wartością jest 1900 zł brutto, co po obliczeniu daje wartość 1544,71 netto oraz 355,29 podatku.

Po zsumowaniu wartości otrzymujemy 2926,82 netto oraz 673,18 podatku, co w porównaniu do Faktury VAT jest różne o jeden grosz. Pociąga to za sobą kolejne błędy związane z podsumowaniami.

Rozwiązanie

1) Zastosowanie modułu funkcyjnego RATA_WO_DFKKOPK w celu pobrania poprawnych wartości netto i brutto bezpośrednio z dokumentu zaliczki z bazy danych. Moduł funkcyjny należy wstawić w pętle w linii 345.

str. 28

Obiekty techniczne:

Include: Z_RWS_BI_BILL_WO_EXIT_050

Klasa: /RWS/CL_NFWO_FAKTURA

Metoda: CREATE_AMOUNT_PAGE1

Moduł funkcyjny: /RWS/NF_WO_GET_AMOUNT_PAGE1

Pętla, linia 92 do 335 – pobieranie wartości

Linia 345 – należy wstawić form naprawczy RATA_WO_DFKKOPK

Przypadek 2

(opisana tu sytuacja została naprawiona w ramach CR 14.056, aktualnie nie znaleziono podobnego przykładu niespójności, zaleca się weryfikację)

Formularz: Z_RWS_CA_SLDOCUMENT

W pozycji ,,Należność wg faktury FV nr (...)“ przywołane są wartości niezgodne z oryginałem faktury korygowanej oraz wartością zaksięgowaną — niezgodność w wartości netto i VAT.

Przykład

Korygowana Faktura VAT nr 330000439541 z dnia 15/10/2013 — wartość netto wynosiła 10 243,90 zł.

Wystawiona faktura korygująca nr 79010007926 z dnia 15/10/2013 wystawiona jest na kwotę netto 10 243,88 zł.

Analiza

str. 29

Błąd został naprawiony poprzez zastosowanie modułu UZUPELNIJ_ANFRE_KOR, który kwoty netto i brutto pobiera z tabeli DFKKOPK przy kluczu Numer dokumentu, Jednostka gospodarcza (również bez jednostki moduł funkcyjny działa poprawnie ponieważ zastosowano drugi SELECT), kod podatku i automatyczne księgowanie = MWS.

Wartości netto i brutto obliczone na wcześniejszym etapie programu są nadpisywane wartościami z bazy danych. Chyba że nie zostaną odnalezione rekordy w tabeli DFKKOPK. W takim przypadku obliczone wartości będą prezentowane na wydruku.

Rozwiązanie

Problem rozwiązany poprzez moduł funkcyjny UZUPELNIJ_ANFRE_KOR.

Include: ZRWS_CA_SLDOC_F01

Moduł funkcyjny może być zastosowany dla poprawki różnic groszowych przy dokumentach korekty. Wywołanie modułu funkcyjnego CALCULATE_TAX_FROM_GROSSAMOUNT można przenieść do ostatniego warunku IF. Proponuje się weryfikację konieczności wywołania modułu funkcyjnego przy każdym wywołaniu UZUPELNIJ_ANFRE_KOR.

Przypadek 3

Formularz: Z_RWS_BI_BILL_MO

Faktura korygująca rozliczenie: formularz Z_RWS_BI_BILL_MO i Z_RWS_BI_BILL_WO

Na fakturze korygującej rozliczenie w pozycji ,,Należność wg faktury FV nr (...)“ przywołane są wartości niezgodne z fakturą korygowaną. Występuje różnica pomiędzy wartością Brutto i VAT.

Przykład

„Faktura korygująca VAT nr 220003557531 — dokument korygowany: w pozycji Skorygowana należność — wartość Brutto wynosi 181,45 zł, wartość VAT 33,94 zł.

str. 30

Faktura korygująca VAT nr 220003587549 — dokument korygujący: w pozycji Należność wg FV wartość Brutto wynosi 181,44 zł, wartość VAT 33,93 zł.

str. 31

Obiekty techniczne:

Include: Z_RWS_BI_BILL_MO_EXIT_050

Form: PRINT_REBTR

Linia: 3543

Analiza

W przypadku braku wartości zmiennej TAX_CHANGE, kwota brutto i podatek są obliczane na podstawie stawki podatkowej rozwiązanie to zostało wprowadzone poprzez CR 7.337 Nowa faktura.

str. 32

W rezultacie kwoty obliczane na podstawie stopy procentowej są obarczone błędem zaokrągleń. Jeśli warunek nie byłby brany pod uwagę i kwoty byłyby przypisywane na podstawie:

wa_rebtr-taxbtr = lv_rebtr_sum_s-taxbtr. wa_rebtr-totbtr = lv_rebtr_sum_s-totbtr.

Wartości kwoty netto i podatku byłyby poprawne ponieważ są pobierane bezpośrednio z bazy danych i tabeli zawierającej informacje o fakturach już zaksięgowanych.

Dla przypadków 1, 2 i 3 można zastosować Form korygujący wartości, który w niektórych formularzach jest już wykorzystywany. Dodatkowo proponuje się optymalizację działania tego obszaru.

2.2.4 Rekomendacja w zakresie kwot w podsumowaniach

Proponuje się poprawę nieprawidłowości kwot prezentowanych w podsumowaniach, w szczególności w wartości netto i wartości podatku na formularzu.


Z_RWS_BI_BILL_MONieprawidłowości w kwotach podsumowań

Poprawa wyliczania i prezentacji w podsumowaniach

Wysoki

Stan obecny

Stwierdzono, że w niektórych przypadkach podsumowania kwot w sekcjach Sprzedaży i Dystrybucji energii są niepoprawne.

str. 33

Formularz: Z_RWS_BI_BILL_MO

Przykład

Faktura korygująca VAT nr 220003470502 Kwota podsumowania dystrybucji i sprzedaży energii elektrycznej jest nieprawidłowa. Wartości są zupełnie inne niż suma pozycji pojedynczych.

Analiza

W szczególności w formularzu Z_RWS_BI_BILL_MO (Form: PRINT_BTRER, Linia 7115) poprawne dane są nadpisywane błędnymi z tabeli DBERDL. W pierwszej kolejności pobierane są wartości dla kwot Netto i Brutto. Jeżeli różnica pomiędzy kwota brutto obliczoną wcześniej (poprawnie) a kwotą brutto pobraną z tabeli DBERDL (błędna) jest mniejsza od 5 groszy, to obliczone dane program nadpisuje danymi z tabeli.

str. 34

Realizacja

W sytuacji „różnic groszowych” można zastosować zoptymalizowany Form korygujący wartości, który w pewnych formularzach jest już wykorzystywany. Natomiast w przypadku nieprawidłowości w podsumowaniach widać, że Form został wywołany poprzez implementację IM8066454, dlatego zalecana jest weryfikacja podstaw takiego działania oraz zakresu zmiany. Ewentualnie proponuje się dokonanie poprawek w tym fragmencie.

2.2.5 Rekomendacja w zakresie parametryzacji formularzy

Proponuje się ograniczenie i ustandaryzowanie logiki oznaczania cech / „typów faktur” związanych z takimi parametrami jak cykl rozliczeniowy, taryfa, itp. dla potrzeb layoutu. Jest to przykład wysokiej parametryzacji formularza, gdzie wygląd dokumentu zależy od konkretnych wartości danych.


Z_RWS_BI_BILL_MOWysoka parametryzacja formularza

Standaryzacja formularza i ograniczenie parametryzacji

ŚredniInne formularze opcjonalnie

Stan obecny

Dla potrzeb layoutu faktur MO, w formularzu Z_RWS_BI_BILL_MO wyznaczany jest parametr WA_BILL-TYPE00 związany w znacznym stopniu z cyklem rozliczeniowym, mówiący o tym, czy mamy do czynienia z fakturą rozliczaną miesięcznie, półrocznie, taryfą pracowniczą, itp.

str. 35

Layout wydruku, a nawet sposób wyboru danych zależą od wielu zmiennych w formularzach. Logika wyboru nie jest jednoznaczna. Wpływ poszczególnych pól i wartości na wariant drukowanego dokumentu zazwyczaj nie jest znany Użytkownikowi, co może generować błędy w wyglądzie dokumentu przy rozszerzeniu słownika po stronie danych.

Poniżej fragmenty kodu formularza MO:

str. 36

Realizacja

Proponuje się weryfikację warunków oznaczania rodzaju faktury / rozliczenia dla potrzeb layoutu. Obecnie parametr WA_BILL-TYPE00 wyznaczany jest w oparciu o wybrane grupy umów WA_DOC_HEADER-PORTION(2) = TP, HT, ZP oraz długość okresu w miesiącach TE420-PERIODEW, np. 1, 6.

Obiekty: Z_RWS_BI_BILL_MO_EXIT_050 / Form USER_EXIT_DOC_HEADER_B.

UWAGI:

Jednocześnie rekomenduje się utworzenie tablicy konfiguracyjnej dla potrzeb oznaczania typu faktury/rozliczenia MO.

Należy zauważyć, że definiowanie nowych grupy umów w systemie (Master Data, Billing) może mieć wpływ na layout wydruku. Stąd konieczność weryfikacji i testów.

Ponieważ potrzeba wyznaczania WA_BILL-TYPE00 ma podłoże historyczne, wyznaczanie zmiennej w nowym formularzu MO możne okazać się zbyteczne dla nowego layoutu.

Powyższy sposób wyznaczania „typów” faktury w formularzu MO stanowi jeden z przykładów wysokiej parametryzacji formularza. Poniżej przykłady wyznaczania jednostek energii, dat (w tym daty wystawienia dokumentu) oraz layoutu wg jednostek gospodarczych i rodzaju pozycji dokumentu – wszystkie tego typu działania powinny być ograniczane w formularzach.

str. 37

2.2.6 Rekomendacja w zakresie formatowania danych

Proponuje się ustandaryzowanie przyjętych założeń w zakresie prezentacji danych wg specyfiki danego kraju.


Z_RWS_BI_BILL_MO

Niezgodne ze standardem domyślne formatowanie danych

Ustandaryzowanie formatowania danych, właściwe dla danego kraju

Niski

Z_RWS_BI_BILL_WO

Z_RWS_BI_BILL_TPA

Z_RWS_BI_BILL_COVER

Z_RWS_BI_BILL_GUD_S

Z_RWS_CA_PAYFORM_MO


str. 38

Stan obecny

Dla potrzeb odpowiedniej prezentacji wartości liczbowych na wydrukach (np. separatory tysięcy) założono, że formatowanie danych w niektórych formularzach będzie się odbywało jak dla kraju o kodzie ZW. Jednocześnie język ww. formularzy przyjęty został jako domyślny język logowania (SY-LANGU) .

Realizacja

Prezentacja danych na wydruku jest zgodna z wymaganiami. Natomiast mając na względzie standaryzację formularzy wydruków, można zaproponować weryfikację tego obszaru.

Założenie SET COUNTRY ‘ZW’ wprowadzono w ramach implementacji Nowej Faktury i znajduje się w User Exitach:

Z_RWS_BI_BILL_MO_EXIT_050

Z_RWS_BI_BILL_WO_EXIT_050

Z_RWS_BI_BILL_TPA_EXIT_050

Z_RWS_BI_BILL_GUD_S_EXIT_050

Z_RWS_BI_BILL_COVER_EXIT_050

Z_RWS_CA_PAYFORM_MO_EXIT_050

Z_RWS_CA_SLDOC_COV_EXIT_050

2.2.7 Rekomendacja w zakresie utworzenia nowego formularza faktury

Mając na uwadze zapewnienie wysokiej jakości dokumentu (prawidłowa treść i prezentacja danych) oraz sprawniejsze wdrażanie nowych rozwiązań dotyczących wydruków Małego Odbioru, proponuje się utworzenie nowego formularza, np. Z_RWS_BI_BILL_MO_2015.


Z_RWS_BI_BILL_MOOgólny problem z jakością kodu i rozwojem formularza

Utworzenie nowego formularza, np. Z_RWS_BI_BILL_MO_2015.

Wysoki

str. 39

Stan obecny

Wydruki faktur Małego Odbioru są tworzone w oparciu o formularz Z_RWS_BI_BILL_MO, często zwany formularzem MO.

Formularz MO wykonany został w 2007 roku, jako formularz aplikacji PWB (SAP Print Work Bench). Początkowo formularz działał na systemie SAP 4.6C, w 2009 roku na wersji 7.10, a od początku 2014 roku – na wersji 7.40.

Formularz MO stanowi podstawowy dokument wydruku w systemie SAP IS-U. Na formularzu drukowane są faktury rozliczeniowe, faktury korygujące, faktury-prognozy. Funkcjonalność pozwala na wydruk oryginału i kopii/duplikatu, indywidualny wydruk pojedynczego dokumentu,

jak i wydruk masowy.

Patrząc od strony liczby wydruków można powiedzieć, że formularz MO jest najpopularniejszym formularzem w RWE Polska. Ilość wydruków na podstawie formularza MO w 2014 roku wyniosła ok. 8 mln.

Formularz MO jest najczęściej drukowanym dokumentem w Spółce, ale również najczęściej modyfikowanym programem w obszarze SAP IS-U.

Główny program formularza, tj. user exit Z_RWS_BI_BILL_MO_EXIT_050 jest niezwykle często modyfikowany. Nie licząc dziesiątek edycji pierwotnej wersji formularza, wprowadzonych w czasie szeroko rozumianej stabilizacji (środowisko SAP 4.6C), istotne są fakty:

w latach 2010-2013 (SAP 7.10) – wprowadzono blisko 500 transportów dotyczących tego programu,

od początku 2014 do maja 2015 roku, czyli przez minione niespełna półtora roku, gdy obowiązuje aktualna wersja systemu SAP 7.40 – wprowadzono 40 zmian.

Modyfikacje wykonywane były w ramach Projektów, Change Requestów (CR) oraz dla potrzeb obsługi suportowej czyli poprawek błędów i niespójności oraz niewielkich rozszerzeń, zgodnie z bieżącymi potrzebami Klienta.

Największa modyfikacja formularza MO miała miejsce w 2012 roku i zrealizowana została w ramach projektu Nowa Faktura. Formularz został wówczas dostosowany do nowych wymagań marketingowych, dzięki czemu otrzymał nową, atrakcyjniejszą szatę graficzną (layout). Jednocześnie z formularza MO wyłączono funkcjonalność wydruku faktur TPA i utworzono dedykowany formularz Z_RWS_BI_BILL_TPA. Stworzono również nowy formularz faktury Klientów Wielkiego Odbioru – Z_RWS_BI_BILL_WO, który zastąpił Z_RWS_BI_BILL_SK.

Przy tych wszystkich szerokich działaniach nie zdecydowano się na utworzenie nowego programu dla obszaru MO. Wprowadzone zmiany techniczne okazały się tak rozległe, że w istotnym zakresie zaburzona została pierwotna struktura/logika formularza. Realizacja

str. 40

nowych projektów w zakresie formularza MO z czasem stała się coraz trudniejsza i pracochłonna. Poniżej fragmenty kodu formularza Z_RWS_BI_BILL_MO.

Fragment kodu formularza dotyczący wyznaczania tekstu dla nadpłaty, jako specyficzny produkt Nowej Faktury (przykładowe wystąpienia słowa „Nadpłata”):

Wyliczanie kwot w formularzu (przykładowe wystąpienia słowa „Brutto”):

str. 41

str. 42

Realizacja

Ogólne wymagania funkcjonalne w stosunku do nowej wersji formularza faktur Małego Odbioru:

zapewnienie wysokiej jakości wydruku (prawidłowa treść, prezentacja danych oraz szata graficzna),

sprawniejsze wdrażanie nowych rozwiązań i modyfikacji formularza.

Formularz Z_RWS_BI_BILL_MO jest aktywny (nie zawiera błędu technicznego) i został wykonany w odpowiedniej technologii, jednak mając na uwadze sprostanie powyższym celom proponuje się wykonanie nowego formularza przeznaczonego do wydruku faktur Małego Odbioru.

Proponowane parametry:

Mandant: 050

Nazwa formularza aplikacji (PWB): Z_RWS_BI_BILL_MO_2015

Klasa formularzy: IS_U_BI_BILL

Pakiet: ZFORMS

Z chwilą wdrożenia nowego formularza MO, możliwość korzystania z dotychczasowego formularza Z_RWS_BI_BILL_MO powinna zostać zablokowana, a konfiguracja zaktualizowana.

W zależności od bieżących potrzeb Klienta należy zweryfikować i zaktualizować zawartość tabel pomocniczych, w tym:

ZRWS_OFIND_FORM – tabela sterująca wydrukiem tekstu „Oferta indywidualna” na formularzach MO/WO/TPA

/RWS/BI_MAP_TKU – klasyfikacja wydruków StreamServe wg TKU

/RWS/BI_PRZES_F – opis faktur dla StreamServe

2.3 Zlecenie serwisowe i windykacyjne

Zlecenia windykacji i odłączeń drukowane są na podstawie formularza SapScript – ZRWS_FORM44 i programu ABAP – /RWS/WYDRUK_ZLECENIA_WINDYK. Główny program generujący dane powstał na przełomie lat 2011/2012 w ramach projektu „IT for Meters

str. 43

II” (pakiet /RWS/IT4M2). Layout dokumentu odbywa się po stronie StreamServe na podstawie danych RDI.

2.3.1 Rekomendacja w zakresie wydruku informacji o liczniku

Proponuje się poprawę prezentacji danych licznika.


ZRWS_FORM44Nieprawidłowa prezentacja danych na wydruku

Poprawa wydruku informacji o odczycie

Wysoki

Stan obecny

Zarejestrowano problem z prezentacją danych odczytów/ wskazań licznika na wydruku zleceń windykacyjnych ZRWS_FORM44. Niektóre cyfry są na wydruku pomijane w przypadku dużych wartości odczytów.

Przykład

Wstrzymanie dostawy energii za zadłużenie:

Zlecenie odłączenia nr 500000231267 / KU 88000024699 / instalacja 4000108298

Stan dla strefy 1: *3933,9000

Realizacja

W celu poprawy obecnego stanu proponuje się modyfikację formularza ZRWS_FORM44 w zakresie wydruku zmiennej WA_LICZNIKI-STAN1_IN.

Nie znaleziono podobnego przypadku dla zlecenia serwisowego. Natomiast proponuje się zweryfikowanie również tego obszaru. Obiekty techniczne: formularz SapScript / ABAP: ZRWS_ORDER_FROM, pakiet /RWS/IT4M2.

str. 44

2.4 Wydruki SD

Wydruki SD tworzone są na podstawie formularza ZRWS_SDST_INV003, uruchamianego przez program ABAP. Generator danych formularza powstał w 2007 roku, natomiast sam formularz bazuje na źródle z 1993 roku i został wykonany w technologii SapScript, która w tym przypadku nie jest technologią aktualnie zalecaną w Spółce.

2.4.1 Rekomendacja w zakresie sposobu wydruku blankietu wpłaty

Proponuje się zmianę sposobu wydruku blankietu wpłaty, aby nie było konieczności korzystania z poddruku blankietu i jego ręcznej obsługi.


ZRWS_SDST_INV003 Konieczność korzystania z poddruku blankietu

Rozszerzenie formularza o sekcję blankietu

Średni

Stan obecny

Sposób wydruku blankietu wpłaty. W chwili obecnej informacje są drukowane na gotowym druku blankietu (gotowe poddruki i konieczność manualnej obsługi). Oczekuje się, aby cały blankiet z danymi był drukowany z systemu, tak jak w przypadku innych dokumentów.

Realizacja

W realizacji rekomendacji proponuje się wykorzystać funkcjonalność blankietu istniejącego w formularzu wydruku faktury MO, jak też w nowszym formularzu TPA:

Z_RWS_BI_BILL_MO – element tekstowy Z_RWS_STRD_BLANKIET („Nośnik płatności”) oraz USER_EXIT_Z_RWS_STRD_BLANKIET, będący częścią programu Z_RWS_BI_BILL_MO_EXIT_050;

str. 45

Z_RWS_BI_BILL_TPA – element tekstowy Z_RWS_BI_BILL_TPA_BLANKIET („Blankiet wpłaty”) oraz user exit Z_TPA_BLANKIET, będący częścią programu / include’a Z_RWS_BI_BILL_TPA_EXIT_050.

2.4.2 Rekomendacja w zakresie sterowania stopką wydruku

Proponuje się zmianę zarządzania (sterowania) stopką wydruku w celu usunięcia nieprawidłowości.


ZRWS_SDST_INV003Nieprawidłowe sterowanie stopką wydruku

Zmiana zarządzania (sterowania) stopką wydruku

Wysoki

Stan obecny

Zarządzanie (sterowanie) stopką wydruku. Nie we wszystkich przypadkach adres do korespondencji drukuje się na stopce w sposób prawidłowy. Jeśli Klient posiada Opiekuna w SAP IS-U, stopka z adresem powinna odsyłać np. na „Wybrzeże” a nie na „Włodarzewską”. Nie zawsze działa to w sposób prawidłowy. Samo umiejscowienie stopki i dane w niej zawarte są zgodne z wymaganiami.

Realizacja

Należy zweryfikować parametry przekazywane do StreamServe’a / layoutu w formularzu ZRWS_SDST_INV003.

2.4.3 Rekomendacja w zakresie miejsca dostarczania energii

Proponuje się dodanie w formularzu informacji o miejscu dostarczenia energii.


str. 46

ZRWS_SDST_INV003 Brak informacji o miejscu dostarczenia energii

Dodanie informacji o miejscu dostarczenia energii

Wysoki

Stan obecny

Miejsce dostarczenia energii – w formularzu SD brakuje informacji o miejscu dostarczenia energii elektrycznej. Informacja powinna stanowić jedną z podstawowych danych faktury.

Realizacja

W celu wdrożenia rekomendacji proponuje się wykorzystać moduł funkcyjny ISU_ADDRESS_PROVIDE, w szczególności wskazujący adres lokalu / instalacji. Informacja na wydruku powinna być umieszczona bezpośrednio pod numerem KU i PH, z opisem „Miejsce dostarczenia energii” (podobnie jak to obecnie ma miejsce w formularzu faktury MO).

2.4.4 Rekomendacja w zakresie harmonizacji formularza

Mając na uwadze harmonizację obszaru formularzy, proponuje się zmianę technologii formularza ZRWS_SDST_INV003 z SapScript na formularz aplikacji (PWB).


ZRWS_SDST_INV003 Technologia niezgodna z aktualną polityką Spółki

Zmiana technologii na formularz aplikacji (PWB)

Średni

Stan obecny

Technologia realizacji formularza ZRWS_SDST_INV003 jest niezgodna z aktualnymi wymaganiami.

Realizacja

Proponuje się zmianę technologii formularza ZRWS_SDST_INV003 z SapScript na formularz aplikacji (PWB).

str. 47

3. Analiza najczęstszych błędów i wyjątków

str. 48

Zweryfikowano obecny stan formularzy, jak również błędy w wydrukach na podstawie zgłoszeń serwisowych z ostatnich lat, zarejestrowanych w systemie suportowym HP Service Center.2

Analiza błędów pozwala wskazać 3 zasadnicze grupy problemów:

problemy po stronie aplikacyjnej SAP – w programach drukujących i formularzach,

problemy po stronie danych – związane z brakiem danych lub niską jakością,

inne – po stronie Użytkownika, infrastruktury, itp.

3.1 Ocena błędów i wyjątków

3.1.1 Rekomendacja po stronie aplikacyjnej

Najpopularniejsze błędy w wydrukach powstałe po stronie aplikacyjnej wynikały z niespójności w formularzach czy też programach drukujących.

Biorąc pod uwagę niską czytelność kodu i logiki programów, można powiedzieć, że problemy w zasadzie dotyczyły większości formularzy wydruków. W okresie kilku lat funkcjonowania SAP IS-U w zasadzie nie ma funkcjonalności w formularzach, która nie uległaby zmianie na skutek implementacji nowych rozwiązań – CR lub projektów, jak też bieżących zmian.

Na przykładzie analizy kodu programu najpopularniejszego formularza faktur Małego Odbioru, możemy stwierdzić, że modyfikacje dotyczyły każdej sekcji dokumentu. Zmianie uległy: nagłówek i stopka, tytuł dokumentu i data wystawienia, dane adresowe i wyliczanie kwot, pozycje i podsumowania, jak również sposób wyliczenia wartości, zaokrąglanie, prezentacja danych, itd.

Aktualnie nierozwiązanych problemów po stronie aplikacyjnej jest kilka, większość istotnych kwestii wraz z przykładami i rekomendacjami opisano w Rozdziale 1.

3.1.2 Rekomendacja po stronie danych źródłowych

W celu wyeliminowania lub znacznego ograniczenia problemów w wydrukach powstałych u źródła danych proponuje się poniższą, dodatkową rekomendację:

Obszar Stan aktualny Rekomendacja Priorytet

2 Od 1 maja 2015 roku obowiązuje w Spółce nowy system obsługi zgłoszeń suportowych ServiceNow.

str. 49

Dane źródłowe / formularze Brak danych lub niespójności

Uzupełnienie lub korekta danych, raport data quality, dodatkowe kontrole w formularzach

Wysoki

Stan obecny

Najczęstsze problemy wydruków po stronie danych dotyczą braku danych w systemie lub wynikają z niespójności w następujących obszarach:

Miejsce dostawy PPE (pole w systemie EUITRANS-EXT_UI) – brak lub niespójność w oznaczeniu miejsca dostawy na poziomie instalacji zazwyczaj skutkowały brakiem szczegółowej sekcji rozliczenia na wydruku faktury. Zdarzały się niespójności w bazie danych polegające na braku rekordu w tablicy EUITRANS dla klucza EUIINSTLN-INT_UI. W przeszłości poprawiono kilkadziesiąt tego typu przypadków.

Język – niewłaściwie określony język na koncie umowy (FKKVKP-LANGU) oraz w systemowym dokumencie wydruku (ERDK-LANGU) uniemożliwiają wydruk faktury, np. język AF zamiast PL. Przykład: FV 221012802301 / KU 82000215967.

Wirtualne konto bankowe (FKKVKP-ZZBANACC2) – brak wirtualnego konta bankowego na poziomie konta umowy uniemożliwia wydruk faktury.

Błędnie określony Typ partnera (BUT000-TYPE) powodujący niespójność z Typem konta umowy (FKKVK-VKTYP). Błędnie określony typ PH (np. Firma zamiast Klient indywidualny) w niektórych sytuacjach może wstrzymywać wydruk dokumentu, jak również powodować problemy z layoutem. Zarejestrowano tego typu przypadki zarówno podczas drukowania faktur, jak również monitów i umów na sprzedaż energii. W szczególności problem wystąpił, gdy Klient z taryfą pracowniczą błędnie został utworzony w systemie jako Firma, zamiast Osoba indywidualna. Tego typu błędy mogą pochodzić z czasu migracji danych czyli wdrożenia systemu. Aktualne przykłady PH: 9000212932 i 9000702297.

Błędne przypisanie nazwy formularza na poziomie konta umowy (FKKVKP-FORMKEY, która następnie replikuje się na dokument wydruku (ERDK-FORMKEY). Błąd powoduje nieprawidłowy wygląd wydrukowanego dokumentu, jak w FV 221013738456 / KU 88000229852, gdzie zamiast Z_RWS_BI_BILL_TPA jest Z_RWS_BI_BILL_SK. Poniżej kilka ostatnich przypadków (system SP1):

str. 50

Realizacja

W celu ograniczenia występowania błędów i wyjątków po stronie danych proponuje się:

utworzenie raportu Data Quality, cyklicznie weryfikującego bieżący stan danych w powyższym zakresie, w szczególności pokazujący brak wirtualnego konta bankowego, brak PPE (w tym różnice pomiędzy kluczami INT_UI w tabelach EUITRANS i EUIINSTLN), błędnie przypisany do KU (nieaktualny) formularz Zakładamy że raport wskazuje błędne dane do ręcznego poprawienia.

Z uwagi na duże znaczenie ww. danych proponuje się również rozważenie zmian w obszarze formularzy:

utworzenie kontroli miejsca dostawy dla Sprzedaży i Dystrybucji w formularzach, zapisującej informację o braku PPE do logu systemowego (obecnie system weryfikuje niespójność pomiędzy tabelami EUITRANS – EUIINSTLN, komunikując: „Oznaczenie miejsca dostawy XXX nie może zostać odczytane”),

obsługę wyjątku błędnego przypisania typu partnera w formularzach dla taryfy pracowniczej – obsługa musi umożliwić wydruk dokumentu.

UWAGI:

Korekta pól „Miejsce dostawy” oraz „Język” jest możliwa do realizacji po stronie Użytkownika Biznesowego.

„Wirtualne konto bankowe” – pole uzupełnia się automatycznie i później nie jest edytowalne, uzupełnienie brakującego wpisu możliwe przy użyciu dedykowanego programu, który już dziś obsługuje Keyuser.

Zmiana domyślnej „Nazwy formularza” na koncie umowy jest możliwa po stronie Użytkownika, natomiast na utworzonym już dokumencie wydruku (ERDK) pole nie jest edytowalne. Należy rozważyć konieczność utworzenia funkcjonalności służącej korekcie błędnego wpisu->patrz raport Data Quality

3.2 Ogólne zalecenia w zakresie obsługi procesu

str. 51

3.2.1 Rekomendacja w zakresie wprowadzania zmian developerskich

Proponuje się rekomendację związaną z wprowadzaniem zmian dotyczących formularzy:

Obszar Stan aktualny Rekomendacja Priorytet

Development Obiekty techniczne niezgodne z wymaganiami Spółki

Przygotowanie funkcjonalności w oparciu o bieżące wymagania Spółki

Wysoki

Stan obecny

Zanotowano wiele przypadków nieścisłości w tworzeniu obiektów formularzy w porównaniu z aktualnymi wymaganiami Spółki. Nieścisłości dotyczą nazewnictwa obiektów, rejestrowania zmian w programach i w sposobie wprowadzania modyfikacji.

Przykład z transakcji EFRM: formularz Z_RWS_BI_BILL_MO na systemie SD1-050 jest aktywny, natomiast na mandancie 100 pokazuje błąd.

Realizacja

W celu wdrożenia rekomendacji proponuje się:

wszelkie zmiany developerskie w systemach SAP opierać na dokumencie „Harmonized ABAP Guidelines”,3

wszystkie prace developerskie w obszarze formularzy w systemie SAP IS-U realizować na mandancie 050, który jest dedykowanym mandantem developerskim, natomiast na innych mandantach powinna zostać utworzona referencja do stworzonego formularza. W ten sposób wszelkie zmiany w formularzu będą od razu widoczne na wskazanych mandancie i nie będzie potrzeby transportowania formularzy między mandatami tego samego systemu.

4. Analiza segmentacji Klientów

3 Dokument w formie elektronicznej jest dostępny pod adresem: http://wiki/download/attachments/3211292/Harmonized_ABAP_Guidelines_CZ_DE_PL_SK_UK_1.0.pdf

str. 52

4.1 Wsparcie segmentacji w ramach SAP IS-U

4.1.1 Rekomendacja w zakresie reorganizacji zmiennych segmentacyjnych

Mając na uwadze wyższą jakość i sprawniejszą obsługę procesu segmentacji, a także standaryzację formularzy, proponuje się zmianę zarządzania parametrami segmentacyjnymi po stronie SAP IS-U.


Z_RWS_BI_BILL_MO

Brak przejrzystości w wyznaczaniu wartości parametrów segmentacyjnych

Utworzenie modułu funkcyjnego z parametrami segmentacji oraz tabel konfiguracyjnych

ŚredniZ_RWS_BI_BILL_WO

Z_RWS_BI_BILL_TPA

Inne wg potrzeb

Stan obecny

Funkcjonalność działa, natomiast brakuje przejrzystości w wyznaczaniu wartości parametrów segmentacyjnych w formularzach, a ocena poprawności procesu – często wymagająca weryfikacji parametrów bezpośrednio w systemie źródłowym SAP IS-U – jest utrudniona.

Realizacja

Proponuje się utworzenie dedykowanego modułu funkcyjnego, który generował będzie zmienne segmentacyjne dla potrzeb StreamServe’a/DocMonitora. Moduł powinien dotyczyć zmiennych globalnych i stanowić biznesową/funkcjonalną całość.

Główny moduł funkcyjny:

/RWS/GET_SEG_FORMS

Przykładowe parametry segmentacyjne:

G_SPRZEDAWCA – np. RWEPL, RWEOP

G_CHKL – „charakter klienta”, np. 1, 2, …

UWAGI:

str. 53

Zmienne segmentacyjne, które można określić w oparciu o dedykowane tablice konfiguracyjne, powinny zostać w ten sposób zdefiniowane, zapewniając przejrzystość, łatwą edycję i rozszerzalność.

Proponuje się dekompozycję złożonych zmiennych segmentacyjnych typu „charakter klienta” na grupę zmiennych czytelnych dla Użytkownika końcowego (np. typ partnera, typ konta umowy). Natomiast w pierwszej fazie – przed dostosowaniem StreamServe’a – moduł może wyprowadzać parametr G_CHKL.

Proponuje się wziąć pod uwagę utworzenie dedykowanej sekcji / elementu tekstowego, który będzie wspólny dla wszystkich formularzy wydruków przenoszących zmienne segmentacyjne w strumieniu danych RDI.

4.1.2 Rekomendacja w zakresie utworzenia raportu

Ponieważ system SAP IS-U nie oferuje narzędzi służących weryfikacji działań segmentacyjnych, proponuje się utworzenie dedykowanego raportu.


Program ABAPBrak narzędzi weryfikacji procesu segmentacji po stronie SAP IS-U

Utworzenie raportu segmentacyjnego, np. /RWS/MD_RAP_SEG

Średni

Stan obecny

Użytkownik nie posiada możliwości weryfikacji zmiennych segmentacyjnych w systemie źródłowym SAP IS-U, ponieważ wartości zmiennych wyznaczane są ad hoc w oparciu o kilka pól i nie są przechowywane w bazie danych.

Realizacja

Proponuje się utworzenie w SAP IS-U raportu segmentacyjnego, np. /RWS/MD_RAP_SEG, który będzie służył weryfikacji realizowanych w DocMonitorze segmentacji.

Dla zadanego numeru faktury raport powinien wskazywać wszystkie istotne wartości parametrów przekazywanych do spoola / pliku RDI (w szczególności chodzi o zbiór cech faktury, a docelowo metadanych po stronie StreamServe’a w oparciu o które Użytkownicy Biznesowi będą wykonywali projekty w Composition Center / Story Teller).

Raport powinien korzystać z głównego modułu funkcyjnego generującego zmienne segmentacyjne /RWS/GET_SEG_FORMS lub też z drobniejszych funkcjonalności/modułów wchodzących w jego skład.

str. 54

UWAGI:

Przy okazji wdrożenia powyższej rekomendacji, proponuje się zwrócenie uwagi na różnice pomiędzy wartością pola CLERK_ID a zmienną G_SPRZEDAWCA, która jest generowana w formularzu dla potrzeb layoutu w StreamServie. Na wartość zmiennej G_SPRZEDAWCA nie tylko bowiem wpływa pole Opiekun Klienta, ale również Jednostka Gospodarcza i Typ konta umowy. To w pewnych przypadkach skutkuje różnicą w spodziewanym wyglądzie dokumentu, jak również w wynikach raportów, np. /RWS/CA_RECEIVABLES_RAP (Wybieranie należności i podział na taryfy), które bazują bezpośrednio na CLERK_ID. Rozwiązaniem może być weryfikacja wartości CLERK_ID w systemie, utworzenie kontroli na tym polu, jak również przeniesienie zmiennej G_SPRZEDAWCA z formularza na poziom konta umowy.

str. 55

Documents

· Web viewjest ogólnie znany. Po pierwsze, wynika z samej natury zaokrągleń i działań na liczbach zaokrąglonych – jest to sfera matematyki i nie dotyczy wyboru tego czy