Analiza podwójnych płatności dla danych spoza SAP

Wprowadzenie

Analiza podwójnych płatności pozwala wykryć faktury, które potencjalnie zostały zaksięgowane więcej niż jeden raz. Jeżeli te księgowania zostaną później rozliczone poprzez płatności, dla jednej transakcji powstaną wielokrotne płatności. W celu identyfikacji takich przypadków dla danych SAP wykorzystywane jest nasze standardowe narzędzie AP_Dupl_Payments, które wyświetla przychodzące faktury potencjalnie zaksięgowane wielokrotnie. Część transakcji księgowych może wyglądać na duplikaty, lecz w rzeczywistości są poprawne. Określa się je jako potencjalne przypadki wymagające szczegółowej weryfikacji. Poprzez oznaczenie potwierdzonych duplikatów możliwe jest przeszkolenie modelu AI, by automatycznie oceniał nowe przypadki oraz niezawodnie rozpoznawał fałszywe trafienia, które mogą zostać wykluczone. Klienci niekorzystający z SAP, którzy chcą skorzystać z oceny AI, mogą wykorzystać narzędzie analityczne AI_Dupl_Payments. Wymaga ono przekazania specjalnie oznaczonych potencjalnych duplikatów księgowań w zdefiniowanym formacie.

Wymagania

• Instalacja ACL dla Windows oraz lokalna instalacja dab AnalyticSuite: Analiza jest możliwa wyłącznie lokalnie na komputerze, nie w środowisku Robotics
• R oraz R-Studio: Wymagana instalacja, wymagane jest R.exe oraz pakiet R (artykuł na temat instalacji środowiska R)
• Highbond: Wymagany moduł Results
• TF_Import.xlsx: Plik musi być zapisany w tej samej lokalizacji co projekt ACL
• Początkowy plik Pool o nazwie AI_Dupl_Payments_Pool.xlsx:
  • Nazwa pliku musi brzmieć AI_Dupl_Payments_Pool.xlsx
  • Ścieżka (domyślnie C:\Users\Public\dabgmbh\AnalyticSuite\Utilities) może być zmieniona
  • Plik musi zawierać podwójne płatności, które dotychczas zostały znalezione, zweryfikowane i oznaczone jako True Duplicate Payments albo False Duplicate Payments
• Plik z danymi, które nie były jeszcze zweryfikowane: musi być zapisany w zdefiniowanej lokalizacji
• Lista kolumn dla tabeli: wymagana zarówno w pliku Pool, jak i w pliku z nieweryfikowanymi danymi
• Różnica między tymi dwoma plikami polega na tym, że pola AI_Meta_Information, AI_Potential, AI_Assessment oraz Manual Assessment NIE występują w pliku z nieweryfikowanymi danymi.

Ustawienia w skrypcie startowym __Run_AI_Dupl_Payments

Następujące zmienne są wymagane do przesłania danych do modułu Results w Highbond:

• v_TF_Cust_Specific_OrgID: Identyfikator organizacji (Organisation-ID) dla jednostki
• v_TF_Cust_Specific_UploadToken: Token API użytkownika Highbond wykonującego analizę
• v_TF_Cust_Specific_APIArea: Możliwe wartości: 1 = EU (domyślnie); 2 = US; 3 = CA; 4 = AS; 5 = AU
• v_AI_Dupl_Paym_OneLineID:
  • Identyfikator tabeli Highbond, do której wgrywane są wyniki
  • Tabela Highbond zostanie utworzona dopiero podczas pierwszego przesłania; zmienna ta nie powinna istnieć na początku pierwszego uruchomienia
  • Odpowiedni wiersz należy zakomentować
  • Po pierwszym uruchomieniu: Adres Highbond należy wprowadzić w tabeli, by możliwe były kolejne aktualizacje wobec tej samej tabeli Highbond przy następnych uruchomieniach

Następujące zmienne mają wartości domyślne, które mogą być dostosowane

• v_AI_Dupl_Paym_AI_ExpPath: Ścieżka, w której plik pool jest przechowywany i aktualizowany. Rekomendacja: zachowanie ścieżki domyślnej, ponieważ plik pool jest aktualizowany po każdym uruchomieniu. Nie należy zmieniać ścieżki po pierwszym uruchomieniu.
• v_AI_Dupl_Paym_Unseen_Path: Ścieżka oraz nazwa pliku z nowymi danymi do zaimportowania
• v_TF17_ExportPfad: Ścieżka, gdzie zostanie utworzony plik .json

Procedura podczas pierwszego uruchomienia

• Plik Pool oraz plik z nieweryfikowanymi danymi są przetwarzane w skrypcie R
• Pola AI_Meta_Information, AI_Potential oraz AI_Assessments utworzone w skrypcie R zostają przekazane do skryptu ACL i dodane do nieweryfikowanych danych
• Wpisy o unikalnym identyfikatorze są dublowane: po jednym wierszu na każdy unikalny identyfikator w tabeli AI_Dupl_Payments_OneLine
• Tabela AI_Dupl_Payments_OneLine zostaje załadowana do modułu Results w Highbond, gdzie tworzona jest nowa tabela

Ręczne kroki po pierwszym uruchomieniu w Highbond

• Utworzenie ankiety dla wygenerowanego zbioru
• Nadanie nazwy, np. identyfikacja rzeczywistych lub fałszywych podwójnych płatności
• Wybranie i zapisanie załadowanej tabeli w Linked tables
• Utworzenie nowego pytania (typ: wybór pojedynczy)
• Pytanie np.: Czy ten rekord to rzeczywista czy fałszywa podwójna płatność?
• Dodanie dwóch możliwych odpowiedzi: True double payment, False double payment
• Ważne: dostosowanie nazw kolumn przy ręcznym ocenianiu
• W ustawieniach tabeli Highbond należy zdefiniować pole UpdateKey jako klucz podstawowy tabeli
• Przetworzenie rekordów w ankiecie: w polu Manual_Assessment_Upl znajdują się rekordy z początkowego pliku pool:
  • Pole jest wypełnione: wartości można zaakceptować
  • Pozostałe wpisy: decyzja użytkownika na podstawie wartości w polach AI_Meta_Information, AI_Potential i AI_Assessments. Pole Manual_Assessment_Upl może zostać usunięte po zaakceptowaniu wszystkich wartości.

Ręczne kroki przed drugim uruchomieniem w skrypcie startowym ACL __Run_AI_Dupl_Payments

• Skopiowanie identyfikatora tabeli wyników Highbond: Wklejenie tej wartości do zmiennej v_AI_Dupl_Paym_OneLineID. Jest to wymagane, by zaimportować tabelę wyników Highbond do ACL.
• TF_Import: Otworzyć plik i wprowadzić identyfikator w arkuszu ScheduledResultsUpload. To konieczne, by nowo dodane wpisy zostały zaaktualizowane w tabeli Highbond.
• Plik unseen_date: Odświeżyć

Procedura przy kolejnych uruchomieniach

• Tabela Highbond: importowana do ACL, gdyż zawiera ręczne oceny użytkowników
• Plik Pool: aktualizowany na podstawie danych z tabeli Highbond
• Plik Pool oraz plik z nieweryfikowanymi danymi: przetwarzane w skrypcie R
• Pola AI_Meta_Information, AI_Potential, AI_Assessments: utworzone w skrypcie R są przekazywane do skryptu ACL i dodawane do nieweryfikowanych danych
• Wpisy o unikalnym identyfikatorze są łączone: by w tabeli AI_Dupl_Payments_OneLine była pojedyncza linia dla każdego unikalnego identyfikatora
• Tabela Dupl_Payments_OneLine: przesyłana do modułu Results w Highbond, gdzie następuje aktualizacja istniejącej tabeli wyników