Partner Biznesowy, nowe środki trwałe – co jeszcze?

W wielu firmach trwają obecnie dyskusje, czy rozpocząć projekt konwersji SAP do wersji S/4HANA jeszcze w tym roku, czy może jeszcze poczekać, bo być może producent systemu znów przesunie datę zakończenia wsparcia. Na tym etapie rozwoju nowej wersji można powiedzieć z dużą dozą pewności, że rok 2027 to realna i ostateczna data. Oczywiście pozostaje jeszcze opcja dodatkowych trzech lat wsparcia za dodatkową opłatą.

A zatem zostały trzy lata normalnego użytkowania systemu SAP EEC i czas już najwyższy na projekty migracji do S/4. Zachęcamy naszych klientów do jak najszybszego rozpoczęcia przygotowań do tego projektu.

Ważne zagadnienie, jakie pojawia się w organizacjach planujących migrację, to sposoby przygotowania się do projektu oraz działania, które można wykonać wcześniej, tak aby późniejsze prace przebiegały sprawniej. Być może warto konwersję podzielić na kilka mniejszych, mniej inwazyjnych dla organizacji projektów.

Oczywiście duża część dyskusji jest poświęcona wyborowi optymalnych scenariuszy projektu. Greenfield to w istocie nowe wdrożenie, z nową koncepcją i migracją danych. Warte rozważenia jest podejście Bluefield – umożliwiające uruchomienie S/4HANA z nowymi funkcjami, wraz z dostępnością danych historycznych. Zapewne część organizacji wybierze metodę brownfield, będącą w istocie upgrade’em technicznym do S/4.

Na tej ostatniej metodzie skupimy się w artykule, podpowiadając, w jaki sposób można przygotować system jeszcze przed właściwą migracją.

Partner Biznesowy (Business Partner) to podstawowy element danych w systemie S/4HANA, który zastępuje powszechnie znany i dotychczas używany w systemie ECC model kontrahentów, jakimi są obiekty odbiorcy i dostawcy, ale nie tylko. Jest to rozwiązanie, które scala wszystkie role kontrahenta w jednym miejscu, jednej transakcji.

Zarządzanie danymi podstawowymi jest prostsze. Wszystkie informacje agregowane są do jednego obszaru, co w znacznie ułatwia zarządzanie i kontrolę danych.

Także od strony użytkownika funkcjonalność ta wprowadza wiele udogodnień – możliwość tworzenia powiązanego dostawcy, klienta czy osoby kontaktowej, przy użyciu jednej transakcji zamiast wielu.

Z perspektywy technicznej agregacja danych pozwala na wielokrotnie szybszy odczyt z bazy danych, co ma przełożenie na wykonywanie wielu standardowych raportów oraz elementów rozszerzeń zaimplementowanych w firmowym systemie.

Wśród najważniejszych zalet Partnera Biznesowego warto wymienić:

• Podmiot prawny w systemie jest reprezentowany przez jeden obiekt – Partner Biznesowy;
• Możliwość tworzenia w różnych formach, m.in. Organizacja, Grupa, Osoba;
• Jeden PB może sprawować wiele ról w systemie, w tym m.in. dostawcy, klienta, osoby kontaktowej, punktu odbioru towarów czy też rola do weryfikacji limitów kredytowych (to tylko podstawowe role partnera, używane w większości systemów, są też inne, rzadziej używane, np. związane z zarządzaniem płynnością);
• Dane ogólne BP są dostępne dla wszystkich ról sprawowanych przez jednego BP, a dane kluczowe mogą być tworzone dla każdej roli osobno;
• Możliwość przypisania i zarządzania wieloma adresami;
• Zależności czasowe w różnych podjednostkach, np. adres, dane bankowe i inne. To jedna z najważniejszych zalet PB, która pozwala zachować pełną historię zmian (po zmianie dane nie znikają z systemu);
• PB ma wiele nowych pól w systemie dostępnych do konfiguracji, tak aby zaspokoić wszystkie potrzeby identyfikacji i klasyfikacji kontrahentów bez dodawania rozszerzeń pól.

Zmianę modelu danych dla partnera biznesowego dobrze widać w wypadku, gdy kontrahent jest zarówno odbiorcą, jak i dostawcą. Cała obsługa tworzenia i zmian danych podstawowych jak adres, numery NIP, czy inne numery określające kontrahenta, typu REGON czy BDO, odbywa się w jednym miejscu w systemie, za pomocą jednej transakcji, której kod jest również szczególny, ponieważ składa się tylko z dwóch znaków (BP), a nie jak większość kodów transakcji – z czterech. Dopiero w referencji do tych danych tworzymy/przypisujemy rolę odbiorcy czy/i dostawcy.

Gdy porównujemy obiekty danych odbiorcy i dostawcy w systemie ECC z nowym modelem PB, uwagę zwraca praktyczny brak powiązania danych odbiorcy i dostawcy w dotychczasowym modelu. Jedynym powiązaniem jest pole odbiorca w danych podstawowych dostawcy, w którym możemy wpisać numer odbiorcy, i odwrotnie, pole dostawca w danych podstawowych odbiorcy. Powiązanie to daje możliwość raportowania otwartych pozycji kontrahenta za pomocą jednego raportu i wspomaga kompensaty.

Natomiast jeśli spojrzymy na model danych PB widzimy, że powiązanie ról odbiorców i dostawców odbywa się za pomocą PB, który jest nadrzędnym obiektem w stosunku do ról, które w nim tworzymy.

W porównaniu tabel widzimy, że po przejściu na funkcjonalność Partnera Biznesowego żadna z dobrze nam znanych tabel związanych z danymi dostawcy i odbiorcy, jak KNA1 czy LFA1, nie znika. Tabele te ciągle są napełniane danymi, a dodatkowo zostaje uruchomionych szereg nadrzędnych tabel, które agregują dane. Wykorzystując nowe tabele, możemy wykonać optymalizacje zapytań niestandardowych rozwiązań i raportów. Jeśli natomiast firma nie chce zmieniać swoich obecnych rozwiązań, to w większości wypadków nie będzie to konieczne po uruchomieniu PB w systemie ECC, ponieważ obecnie używane tabele – jak już wspomniano – pozostają bez zmian.

Uruchomienie Partnera Biznesowego to krok obowiązkowy, który musi być wykonany jeszcze na systemie ECC (w wersji co najmniej 6.0). Warto taki projekt przeprowadzić już teraz, jako przygotowanie do przyszłej migracji do S/4. Czas i zasoby na to poświęcone nie zostaną w żaden sposób zmarnowane ani zdublowane. Co więcej, sama konwersja z pewnością przebiegnie sprawniej i szybciej, zminimalizujemy też liczbę błędów. Zespół projektowy będzie mógł skupić się tylko na procesie migracji, nie zajmując się dodatkowo PB i problemami z nim związanymi. Nie bez znaczenia jest też argument mówiący, że użytkownicy wcześniej zaznajomią się z logiką nowego systemu oraz problematyką związaną z migracją do S/4.

Projekt uruchomienia PB zaczyna się od etapu przygotowania, w którym musimy wykonać niezbędną konfigurację z wyborem modelu numeracji, przygotować ewentualne rozszerzenia, a w szczególności dane podstawowe, które wymagają kilku uspójnień i weryfikacji. W dalszej kolejności jest etap synchronizacji, w którym pracujemy nad usunięciem błędów i sprawdzamy kompatybilność. Faza testów końcowych jest połączona ze szkoleniem użytkowników z nowej funkcjonalności. Oczywiście projekt kończy się uruchomieniem produkcyjnym rozwiązania.

Etap przygotowania możemy podzielić na dwa mniejsze. Pierwszy, który możemy zrealizować niezależnie, jako miniprojekt, to weryfikacja danych i przygotowanie dokumentu analizy. Pierwszą analizę danych dotyczącą odbiorców i dostawców możemy uzyskać przez wykonanie Readiness check. Jest to jednak bardzo ogólna, wstępna informacja.

Szczegółową analizę danych uzyskujemy przez wdrożenia i uruchomienie kilku raportów, które dadzą pełen obraz operacji niezbędnych do wykonania na danych przed migracją. Kroki do przygotowania tych raportów znajdują się w nocie 2743494.

Bardzo ważnym elementem takiej analizy i przygotowania dokumentacji jest wybór numeracji dla nowego obiektu PB. Zazwyczaj systemy nie są gotowe na rekomendowane rozwiązanie, jakim jest jednakowa numeracja odbiorców, dostawców i PB. Najczęściej wybieraną opcją jest numeracja częściowa, gdzie numeracja PB jest zgodna z numeracją odbiorcy bądź dostawcy.

Ta część etapu przygotowania ze strony All for One kończy się zawsze przygotowaniem dokumentacji z użyciem dokumentów rekomendowanych przez SAP. Wdrożenie BP wymaga uruchomienia kilku funkcji biznesowych, wszystkie niezbędne kroki zostały opisane w nocie SAP 2832085.

Cały projekt zazwyczaj trwa 4-6 miesięcy, w zależności od skomplikowania i ilości danych.

O ile funkcja Partnera Biznesowego nie jest jeszcze powszechnie używana w obecnych systemach ECC, o tyle funkcja EA-FIN jest już dobrze znana użytkownikom tego systemu. Jednak ciągle jeszcze spotykamy systemy, które używają starego silnika środków trwałych.

Uruchomienie funkcji biznesowej EA-FIN jest niezbędnym elementem konwersji obecnego systemu do S/4. Także tę funkcjonalność warto wprowadzić jeszcze przed głównym projektem migracji.

Główne zmiany wynikające z uruchomienia EA-FIN to nowy sposób obliczania amortyzacji, jednak dzięki dostarczonemu przez producenta oprogramowania raportowi możemy w prosty sposób te różnice zidentyfikować. Są to różnice groszowe, a wynikają z innego modelu obliczania amortyzacji.

Dla użytkownika najbardziej widoczną zmianą jest możliwość wprowadzania kluczy amortyzacji czy długości użytkowania środków trwałych w zależności czasowej, dzięki czemu system nie wykonuje kalkulacji wstecznej amortyzacji do początku roku obrotowego, a wprowadza zmiany dokładnie z zadeklarowaną datą.

Aktywacja funkcji EA-FIN wymusza również zmianę miejsca implementacji rozszerzeń, z poprzedniego opartego, na user-exit na BAdI, które również jest wykorzystywane w S/4HANA.

Uruchomienie nowych środków trwałych nie jest dużym i skomplikowanym projektem, ale może wymagać pewnego czasu downtime systemu w czasie aktywacji funkcji biznesowej. Jak zwykle czas ten jest uzależniony od ilości środków trwałych.

Ważnym etapem przygotowania obecnego systemu, którego w żaden sposób nie da się pominąć, jest archiwizacja starych nieużywanych już danych. Takie działania skrócą czas migracji oraz zmniejszą ilość ewentualnych błędów, które mogą wystąpić podczas konwersji. Jest to praca bardzo niewdzięczna i często pomijana, bo jej efekty nie są widoczne od razu. Jednak zaprocentują w przyszłości, podczas wdrożenia.

Inne prace, które warto wykonać w systemie, to usuwanie duplikatów, standaryzacja czy weryfikacja spójności danych. Zapewne część organizacji posiada już odpowiednie procedury mające na celu weryfikację wprowadzanych danych, a jeśli nie – warto je wdrożyć, aby w przyszłości zminimalizować ilość czasu poświęconego na sprzątanie.

Przygotowując się do konwersji systemu, warto skorzystać z dostępnych transakcji i programów do sprawdzania konsystencji danych transakcyjnych. SAP dostarcza takie rozwiązania dla większości danych, takich jak środki trwałe, uspójnienie MM i FI, sprawdzenie danych KM czy ksiąg specjalnych. Dodatkowo, w zależności od rodzaju używanej księgi głównej, można użyć dedykowanego programu do wykonania analizy porównawczej oraz całościowego sprawdzenia spójności finansów.

Podobnie jak funkcja biznesowa EA-FIN, tak i Nowa Księga Główna funkcjonuje już u niektórych z naszych klientów. Jest to funkcjonalność dość powszechna w systemach ECC.

Nowa KG wprowadza kilka usprawnień, takich jak księgowania równoległe w różnych księgach, co umożliwia prowadzenie różnej sprawozdawczości na tych samych kontach KG. Jest to szczególnie przydatne dla firm międzynarodowych, w których sprawozdawczość grupowa różni się od lokalnej (krajowej) i podatkowej. W modelu klasycznej KG musieliśmy multiplikować konta KG i inaczej budować sprawozdanie finansowe. W Nowej KG raportowanie jest prostsze. Rozwiązanie to jest również szeroko wykorzystywane w module środków trwałych podczas księgowania amortyzacji.

Nowa KG daj także możliwość podziału dokumentu, tzw. Document Splitting, dzięki czemu możemy zapewnić kolejne wymiary raportowania. Otrzymujemy również zagregowaną tabelę, co pozwala optymalizować zapytania oraz przyspiesza działanie standardowych raportów, a także daje możliwość optymalizacji rozszerzeń zaimplementowanych w finansach.

W systemach, które funkcjonują jeszcze z klasyczną KG, nie ma konieczności wykonywania migracji do nowej KG na wersji ECC, zostanie ona migrowana do Nowej KG podczas procesu konwersji do systemu S/4HANA jako jeden z jej kroków.

Istnieje oczywiście możliwość uruchomienia Nowej KG w systemie ECC, jednak wymaga to zaangażowania całej organizacji w testy większości procesów. W analizę systemu przed rozpoczęciem przejścia na Nową KG musi zostać zaangażowana również firma SAP. Do takiego kontaktu została opracowana specjalna procedura i kwestionariusz, który należy wypełnić i przesłać do producenta oprogramowania.