Przegląd rejestru księgowań

Rejestr księgowań to konsola na poziomie tenanta, niezależna od pojedynczego projektu, w której działy finansów i księgowości przeglądają księgowania ERP ze wszystkich projektów i połączeń, do których mają dostęp. O ile Historia księgowań ERP dotyczy jednego projektu, do którego już masz dostęp, o tyle Rejestr księgowań to widok międzyprojektowy, stworzony dla recenzenta, który musi widzieć w jednym miejscu księgowania z wielu projektów i połączeń.

Rejestr księgowań jest zbudowany przede wszystkim do przeglądu. Dwie akcje zbiorcze — czyszczenie księgowań symulowanych i ponawianie nieudanych — pojedyncze Ponów w panelu szczegółów, odwracanie oraz odwracanie całego przebiegu rozrachunków wewnątrzgrupowych naraz pozwalają działać bezpośrednio z siatki i panelu szczegółów, Asystent AI pomaga szybciej znajdować i rozumieć księgowania, a Trendy, Pochodzenie, Sumy kontrolne, Zamknięcia i Eksport pozwalają analizować dane, wracać do źródła, zamykać okres i wyprowadzać dane na zewnątrz. Współpraca umożliwia zespołowi wspólne komentowanie, zatwierdzanie i obserwowanie księgowania — bez umieszczania kwot w powiadomieniach.

Konsola to jeden zadokowany obszar roboczy, a nie zestaw pływających okien. Pasek nawigacji po lewej stronie otwiera każdy ekran — księgowania, symulowane, wyjątki, zatwierdzenia, delegowania, zestawienie, trendy, sumy kontrolne, pochodzenie, eksporty i alerty oraz asystent AI — jako panel w miejscu, więc przełączanie ekranów zmienia zawartość środka obszaru roboczego, zamiast układać kolejne okno na poprzednim. Po otwarciu księgowania jego szczegóły wsuwają się z prawej strony, nie zasłaniając listy, nad którą pracujesz.

Jeden zadokowany obszar roboczy — pasek otwiera ekran pośrodku w miejscu, a szczegóły księgowania otwierają się w panelu po prawej, bez zasłaniania listy.

Kto może go otworzyć

Otwarcie Rejestru księgowań wymaga jednego z czterech zakresów domeny Keycloak — erp.register.view, .operate, .approve i .admin. Są to niezależne uprawnienia, a nie rosnąca drabina: posiadanie .admin samo w sobie nie daje tego, co daje .operate, a każda czynność zmieniająca stan lub wyprowadzająca dane sprawdza jawnie własny wymagany zakres lub zakresy, zamiast wnioskować o nich z wyższego poziomu.

Zakres	Uprawnienia
`erp.register.view`	Otwieranie rejestru i przeglądanie księgowań — kolejka wyjątków, siatka, widoki zestawień, Trendy, Pochodzenie i Asystent AI. Nic z tego niczego nie stosuje, nie eksportuje ani o niczym nie powiadamia.
`erp.register.operate`	Podstawa dla wszystkiego, co zmienia stan lub opuszcza konsolę: akcje zbiorcze, inicjowanie odwrócenia, proszenie o jego zatwierdzenie, otwieranie skrzynki zatwierdzeń i rozstrzyganie wniosku, nad którym masz uprawnienia, przeglądanie lub zwracanie delegowania, eksportowanie lub planowanie dostarczania, subskrybowanie podsumowania Asystenta AI oraz dodawanie komentarza, zatwierdzenia lub obserwowania. Czynności bramkowane przez `.approve` i `.admin` są sprawdzane dodatkowo do `.operate`, nigdy zamiast niego — zobacz niżej.
`erp.register.approve`	Uprawnienie do zatwierdzania odwrócenia na poziomie progu rozdzielenia obowiązków w tenancie lub powyżej niego — przez bezpośrednie posiadanie tego zakresu albo przez aktywne delegowanie od osoby, która go ma — oraz rozstrzyganie zawieszonej próby odwrócenia (`released` lub `confirmed`). Przekazanie komuś innemu delegowania tego uprawnienia wymaga także posiadania `.approve`; korzystanie z niego, przeglądanie lub cofanie go tego nie wymaga. Wszystko łącznie z `.operate`.
`erp.register.admin`	Eksport audytorski i profil odczytu na dzień (kwoty i tożsamość autora bez maskowania) oraz ustawianie zasad przechowywania w tenancie — każde łącznie z `.operate`. Pozwala także usuwać lub uruchamiać harmonogram innego członka.

Reguła widoczności

Posiadanie zakresu erp.register.* otwiera konsolę, ale samo w sobie nie sprawia, że jakiekolwiek księgowanie jest widoczne. Księgowanie jest widoczne w rejestrze tylko wtedy, gdy masz także osobiste uprawnienie do połączenia tego księgowania oraz — gdy księgowanie należy do projektu — dostęp do tego projektu. Księgowanie niepowiązane z projektem jest bramkowane wyłącznie uprawnieniem do połączenia.

To uprawnienie jest osobne od zakresu rejestru opisanego wyżej i wymagane są oba:

Uprawnienie do połączenia. Musisz być jawnym właścicielem połączenia, wskazanym imiennie albo członkiem grupy zabezpieczeń wskazanej w połączeniu — to te same uprawnienia, którymi steruje Model zabezpieczeń połączenia. Połączenie ustawione na All Workspace Members nie daje widoczności w rejestrze. To ustawienie umożliwia korzystanie z połączenia wszystkim, ale nie jest uprawnieniem osobistym, grupowym ani właścicielskim, a rejestr wymaga właśnie jednego z nich.
Dostęp do projektu, dla każdego księgowania należącego do projektu — ten sam dostęp, którego wymaga Twoja pozostała praca w projekcie.

Członek, który ma erp.register.view, ale nie ma żadnych uprawnień do połączeń, widzi prawidłowo pusty rejestr, a konsola mu to komunikuje, zamiast wyglądać na uszkodzoną. Cofnięte uprawnienie do połączenia lub projektu zaczyna działać przy następnym załadowaniu strony — nie ma nieaktualnej widoczności do wyczyszczenia.

Co widzisz według roli

Konsola jest dostosowana do roli: pozycja paska lub przycisk akcji, do których nie masz zakresu, jest ukryta, a nie tylko wyszarzona, więc obszar roboczy pokazuje wyłącznie to, co faktycznie możesz zrobić. Odzwierciedla to to, co wymusza serwer, a go nie zastępuje:

Masz	Widzisz
`erp.register.view`	Ekrany przeglądu — kolejka wyjątków, siatka, zestawienie, trendy, pochodzenie, sumy kontrolne i asystent AI.
`erp.register.operate`	Dodaje przyciski akcji: ponawianie, odwracanie i czyszczenie księgowań symulowanych.
`erp.register.approve`	Dodaje skrzynkę zatwierdzeń, decyzje o zatwierdzeniu i delegowanie.
`erp.register.admin`	Dodaje ustawienia przechowywania i eksport audytorski bez maskowania.

Ukrycie kontrolki jest wyłącznie kwestią prezentacji — wygodą, aby nie oferować czegoś, co zostałoby odrzucone. Serwer pozostaje nadrzędny: każda czynność zmieniająca stan lub wyprowadzająca dane ponownie sprawdza własny wymagany zakres oraz Twoje uprawnienia do połączeń i projektów w chwili jej wykonania. Nic nie jest dozwolone dlatego, że klient pokazał przycisk, i nic nie jest naprawdę zablokowane tylko dlatego, że klient go ukrył.

Kolejka wyjątków

Otwarcie rejestru prowadzi do Kolejki wyjątków, a nie do siatki — księgowań, które najprawdopodobniej wymagają Twojej uwagi, pogrupowanych w cztery koszyki i pokazanych w kolejności priorytetu:

Wątpliwe — księgowanie zostało wysłane i nic jeszcze nie potwierdza, co się z nim stało.
Niepotwierdzone — wysłane i po terminie, do którego powinno zostać potwierdzone.
Oczekuje — księgowanie asynchroniczne po terminie, do którego powinno zostać rozstrzygnięte.
Niepowodzenie — odrzucone przez ERP.

Każdy koszyk pojawia się jako kafelek licznika nad kolejką, pokazujący swoją bieżącą sumę, więc kształt pracy widać, zanim cokolwiek otworzysz. Wybranie kafelka filtruje kolejkę do tego koszyka, a pozostałe kafelki nadal pokazują własne sumy — dzięki temu przełączenie na Niepowodzenie nigdy nie sprawia, że licznik Wątpliwe wygląda na pusty.

„Przeterminowanie” jest mierzone względem własnych liczników platformy, a nie wymyślonego progu, więc księgowanie trafia do koszyka dokładnie wtedy, gdy sama platforma uznałaby je za opóźnione. W każdym koszyku najstarsze księgowania są pierwsze.

Księgowania symulowane nigdy nie pojawiają się w kolejce ani w jej licznikach — kolejka podaje, ile ich wykluczono, więc niska liczba nigdy nie zostanie pomylona z „nic do przeglądu”, gdy powodem są symulacje. Filtrowanie do jednego koszyka zawęża wyświetlane wiersze; nie zmienia tego, co mówią liczniki pozostałych koszyków, więc przełączenie na Niepowodzenie nigdy nie sprawia, że Wątpliwe wygląda na puste.

Obowiązuje tu ta sama reguła widoczności co w siatce: widzisz tylko wyjątki dotyczące księgowań powiązanych z połączeniem, do którego masz osobiste uprawnienie, w projekcie, do którego masz dostęp.

Odwrócenia nadal oczekujące

Lista wyjątków przez API, GET /erp/register/exceptions, zgłasza także piątą kategorię, reversal_outstanding: zaksięgowany zapis, którego odwrócenie zostało wysłane, ale nigdy nie zostało rozliczone — ERP nie odpowiedziało lub próba została przerwana w trakcie wysyłania. Ma własny licznik obok pozostałych czterech, trafia na górę razem z Wątpliwe, a każdy wiersz wskazuje próbę odwrócenia i jej stan. Taki zapis pozostaje na liście do czasu rozstrzygnięcia, jak opisano w sekcji Odwracanie; nie znika sam z upływem czasu.

Kondycja połączeń

Baner nad Kolejką wyjątków i widokami zestawień (poniżej) odpowiada na pytanie, na które żaden z nich sam nie odpowiada: czy któreś z Twoich połączeń nie działa? Dla każdego połączenia, do którego masz osobiste uprawnienie — i tylko dla nich — pokazuje ostatnie udane księgowanie i to, czy połączenie aktualnie zgłasza błędy. Połączenie z uprawnieniem, ale bez żadnych księgowań, jest tak oznaczone, a nie pomijane na liście, a jeśli samo sprawdzenie kondycji nie może zostać ukończone, baner też o tym informuje, zamiast po cichu zgłaszać, że wszystko jest w porządku.

Formatowanie kwot

Każda kwota pokazywana w rejestrze — siatka, zestawienie, sumy kontrolne, panel szczegółów, kolejka wyjątków, skrzynka zatwierdzeń, Asystent AI i okno odwracania — jest wyświetlana jako liczba księgowa: separatory tysięcy, wartości ujemne w nawiasach oraz cyfry tabelaryczne (o stałej szerokości), aby kolumna kwot wyrównywała się względem przecinka dziesiętnego. Liczba miejsc dziesiętnych wynika z samej waluty, a nie ze stałych dwóch — JPY nie ma żadnych, KWD ma trzy.

Sum częściowych nigdy nie sumuje się między walutami. Grupa lub partia zawierająca więcej niż jedną walutę jest dzielona na jeden wiersz na walutę, każdy opisany własną walutą, zarówno w widokach zestawień, jak i w Sumach kontrolnych — nigdzie na platformie nie zakłada się kursu walutowego.
Zaokrąglenie na potrzeby wyświetlania nigdy nie ukrywa rzeczywistej różnicy. Gdy zaokrąglenie do zwykłej liczby miejsc dziesiętnych waluty odrzuciłoby cyfrę różną od zera, panel szczegółów pokazuje dokładną zarejestrowaną wartość obok zaokrąglonej. Wartości w Sumach kontrolnych nigdy nie są zaokrąglane, z tego samego powodu: różnica sprawdzana względem tolerancji pozostaje w pełnej precyzji, więc rzeczywista różnica poza tolerancją, jak 0.004, nie może zostać wyświetlona jako 0.00 obok werdyktu „Niezbilansowane”.

Siatka rejestru

Przełącz się na siatkę, aby zobaczyć każde księgowanie, a nie tylko wyjątki — wyświetla księgowania ze wszystkich projektów i połączeń, które widzisz, jeden wiersz na księgowanie. Wzdłuż górnej krawędzi siatki biegnie pasek zakresu, na którym zawężasz to, co oglądasz:

Projekt
Środowisko
Połączenie
Typ ERP
Jednostka
Data księgowania
Stan
Tryb księgowania

Aby zbudować własny filtr typu ERP, GET /erp/register/erp-types zwraca posortowane wszystkie typy ERP w księgowaniach, które widzisz.

Pasek zakresu używa selektorów: projekt, połączenie lub jednostkę wybierasz po nazwie z listy ograniczonej do tego, co możesz widzieć, zamiast wpisywać identyfikator. Stan jest polem wielokrotnego wyboru, więc możesz obserwować kilka stanów naraz.

Tryb księgowania to trójprzyciskowy przełącznik, który jest zawsze widoczny, więc na pierwszy rzut oka widać, co obejmują liczby. Rzeczywiste pokazuje tylko księgowania, które dotarły do ERP, Symulowane pokazuje tylko księgowania z uruchomień w trybie symulacji, a Wszystkie (domyślnie) pokazuje oba rodzaje. Kolumna Tryb księgowania w siatce wskazuje, jakiego rodzaju jest każdy wiersz. Ekrany Uzgodnienie i Zestawienie mają własny selektor Tryb księgowania z tymi samymi opcjami, domyślnie ustawiony na Rzeczywiste. Gdy tryb nie jest Rzeczywiste, notatka obok sum kwot informuje, że obejmują one księgowania symulowane, które nigdy nie dotarły do ERP, lub — w trybie Symulowane — że żadne nie dotarły do ERP. To, co ustawisz, pozostaje widoczne na ekranie w trakcie pracy, więc nigdy nie zgadujesz, co siatka aktualnie pokazuje.

Akcje zbiorcze

W siatce zaznacz więcej niż jedno księgowanie i działaj na wszystkich naraz. Księgowania zaznaczasz, oznaczając ich wiersze, albo wybierając zaznacz wszystkie pasujące do bieżącego filtra — co obejmuje każde księgowanie pasujące do filtra na wszystkich stronach, a nie tylko te już załadowane.

Dostępne są dwie akcje:

Wyczyść księgowania symulowane — miękkie usunięcie księgowań symulowanych, których nie musisz już przechowywać.
Ponów nieudane księgowania — ponowne wysłanie księgowań odrzuconych przez ERP lub takich, które nigdy nie zostały wysłane.

Podgląd wpływu

Przed uruchomieniem każdej z akcji PlaidCloud pokazuje podgląd wpływu: ile księgowań dotyczy akcja, jakie kwoty są w grze (w podziale na waluty — kwoty nigdy nie są mieszane między walutami, a niezarejestrowana kwota jest wyświetlana jako puste pole, nigdy jako 0.00) oraz do jakich połączeń i jednostek należą dotknięte księgowania. Wszystko w zaznaczeniu, czego akcja nie może dotknąć, jest wskazane osobno, więc „24 z 30 zaznaczonych księgowań nic nie zrobi” widać przed zatwierdzeniem, a nie dopiero po fakcie.

Potwierdzenie przez wpisanie

Powyżej progu przycisk Zastosuj pozostaje wyłączony, dopóki nie wpiszesz kwoty, której dotyczy akcja, dokładnie tak, jak jest podana.

Ponowienie dotyczy tylko tego, co zaznaczono

Czyszczenie księgowań symulowanych może działać na oba rodzaje zaznaczenia — zaznaczone wiersze lub wszystko, co pasuje do filtra. Ponawianie jako akcja zbiorcza nie może: działa wyłącznie na księgowaniach, które indywidualnie zaznaczono. Zaznaczenie obejmujące cały filtr nie ma stałej listy księgowań, do której można by ograniczyć ponowienie, więc ponawianie prosi o wklejenie księgowań z powrotem i odmawia kontynuacji, jeśli wklejone dane nie są dokładnie tym, co pokazał podgląd — te same księgowania, bez duplikatów i w tej samej liczbie. To powiązanie sprawia, że potwierdzenie jest rzetelne: partia, którą potwierdzono, jest partią, która zostaje wysłana.

Co można ponowić

Ponowić można tylko księgowanie odrzucone przez ERP lub takie, które nigdy nie zostało wysłane. Księgowania nadal w toku, wątpliwego lub już zaksięgowanego nie można stąd ponowić.

Tam, gdzie ERP połączenia to obsługuje, PlaidCloud pyta ERP bezpośrednio przed ponowieniem: jeśli ERP już przechowuje dokument jako zaksięgowany, ponowienie jest odrzucane i zamiast tego sugerowane jest odwrócenie. Jeśli ERP nie może odpowiedzieć na to sprawdzenie, ponowienie jest odrzucane zamiast ryzykowane — nigdy nie zgaduje. Kilka połączeń w ogóle nie obsługuje tego sprawdzenia; dla nich ponowienie opiera się na własnym zarejestrowanym odrzuceniu księgowania.

Ponawianie wymaga erp.register.operate oraz Twojego osobistego uprawnienia do połączenia tego księgowania — tego samego uprawnienia do połączenia, którego Reguła widoczności wymaga, aby w ogóle zobaczyć księgowanie.

Ponawianie z panelu szczegółów

Panel szczegółów księgowania ma także własny przycisk Ponów, obok kontrolek obserwowania — to samo ponowienie, wiersz po wierszu, dostępne bez przechodzenia przez siatkę. To nie jest akcja jednym kliknięciem: jego otwarcie pokazuje ten sam podgląd wpływu i, powyżej progu, to samo wyzwanie potwierdzenia przez wpisanie, którego używa akcja zbiorcza — istnieje dokładnie jedna ścieżka ponawiania, wchodzi się do niej z dwóch miejsc. Przycisk jest widoczny w każdym wierszu dla członka z erp.register.operate; panel nigdy nie przesądza z góry, że wiersz da się ponowić, zanim go zaoferuje, więc wiersz, który okaże się niekwalifikujący się — już zaksięgowany, w toku lub taki, który ERP już przechowuje — jest odrzucany przez podgląd z własnym powodem serwera, a nie po cichu ukrywany.

Czyszczenie księgowań symulowanych

Czyszczenie to miękkie usunięcie: PlaidCloud rejestruje, kto je wykonał i kiedy, i wymaga podania powodu, zanim Zastosuj zostanie włączone. Usuwa księgowania z magazynu podglądu symulacji i z własnego dziennika symulacji księgi — nigdy nie dotyka księgowania rzeczywistego i nie ma sposobu, aby je na takie skierować.

Widok księgowań symulowanych

Księgowania symulowane otwierają się jako panel z paska, wyświetlając zawartość magazynu symulacji, zamiast kazać Ci szukać wierszy symulowanych w głównej siatce. Filtruj według połączenia, projektu, środowiska lub identyfikatora uruchomienia symulacji.

Uwzględnij wyczyszczone jest domyślnie wyłączone, zgodnie z domyślnym ustawieniem serwera: wyczyszczony wiersz jest zapisem audytowym czyszczenia i jest z tego powodu krótko przechowywany, więc widok otwiera się na tym, co nadal jest aktywne w magazynie, a nie na jego własnej historii.
Czyszczenie stąd nadal przechodzi przez ten sam podgląd wpływu co akcja zbiorcza w siatce — nigdy jednym kliknięciem — w zakresie tego, co aktualnie pasuje do filtrów widoku.
Wiersz podsumowania widoku zgłasza także tę samą wartość simulated_excluded, którą pokazuje Kolejka wyjątków — ile księgowań symulowanych w księdze księgowań, czyli osobnej tabeli niż magazyn symulacji, jest wyłączonych z kolejki, ponieważ wiersz symulowany nigdy nie dotarł do ERP i dlatego nigdy nie jest wyjątkiem.

Asystent AI

Asystent otwiera pole wyszukiwania, rząd proaktywnych kart i panel porad dla poszczególnych wierszy — każda liczba w nim jest obliczana przez sam rejestr, na podstawie Twoich bieżących uprawnień; model, jeśli jest skonfigurowany, tylko wyjaśnia lub redaguje i nigdy nie wymyśla liczby ani predykatu.

Pytaj zwykłymi słowami

Wpisz zdanie — „księgowania wątpliwe dla połączenia EMEA w zeszłym tygodniu” — a zostanie ono przekształcone na własne słownictwo filtrów rejestru przez stałą tabelę, a nie wywołanie modelu: analiza może jedynie zawęzić wiersze, które siatka i tak by Ci pokazała, nigdy nie sięgnie po wiersz, do którego nie masz uprawnień. Jedyną rolą modelu jest wyjaśnienie analizy w jednym zdaniu: wskazuje dopasowane pole i to, ile Twoich wierszy znajduje powstały filtr.

Proaktywne karty

Siedem kart podsumowuje to, co warto sprawdzić, każda z bieżącą liczbą i przykładowymi wierszami ograniczonymi do Twoich uprawnień: do rozliczenia przed zamknięciem, prawie duplikaty, luka w zerowaniu rozrachunków wewnątrzgrupowych, zmiany względem ostatniego zamknięcia, potwierdzone w ERP, wiekowanie i właściciele oraz już odwrócone. Krótkie zdanie narracji znajduje się obok liczb, gdy dla Twojego obszaru roboczego skonfigurowano połączenie LLM; gdy go nie ma, karta nadal jest wyświetlana w całości i podaje, dlaczego brakuje narracji. Niezarejestrowana kwota na karcie jest zawsze puste pole, nigdy 0.00 — ta sama reguła, którą stosują widoki zestawień.

Porady dla poszczególnych wierszy

Wybierz księgowanie i uzyskaj dwa rodzaje porad, zależnie od jego stanu:

Projekt odwrócenia, dla dowolnego księgowania — jak wyglądałoby jego odwrócenie: czy sterownik połączenia w ogóle to obsługuje, z jaką sumą kontrolną musiałoby się zgadzać oraz sprawdzenie okresu. To tylko projekt; nic tutaj niczego nie odwraca.
Wskazówki dotyczące niepowodzenia, dla księgowania odrzuconego lub wątpliwego — dlaczego się nie powiodło, czy ponowić je, czy najpierw poprawić dane źródłowe, które pole poprawić i jakie jest ryzyko duplikatu po naciśnięciu ponowienia. Własny komunikat błędu ERP to dowolny tekst, więc jest klasyfikowany do przyczyny po stronie serwera, a nie pokazywany Ci bezpośrednio — ta sama reguła, która trzyma dowolny tekst poza resztą rejestru.

Dzienne podsumowanie

Podsumowanie wyświetla na żądanie powyższe karty ograniczone do podzbioru istotnego dla zamknięcia — do rozliczenia przed zamknięciem, wiekowanie i właściciele, prawie duplikaty, luka w zerowaniu rozrachunków wewnątrzgrupowych i potwierdzone w ERP — tak, jak wyglądałyby, gdyby zostały dziś do Ciebie wysłane. Przełącznik subskrybuje lub anuluje subskrypcję; subskrypcja przechowuje wyłącznie identyfikator członka, więc uprawnienie, które później utracisz, po prostu usuwa te wiersze z następnego podsumowania, zamiast ujawniać nieaktualny widok.

Odwracanie

Odwrócenie księgowania — utworzenie w ERP nowego, przeciwnego dokumentu — jest dostępne z kontrolki Odwróć w panelu szczegółów oraz bezpośrednio przez API na potrzeby automatyzacji.

Kwalifikowalność zależy od własnego stanu księgowania (odwrócić można tylko zaksięgowany zapis z potwierdzonym identyfikatorem dokumentu ERP), od sterownika połączenia (Business Central, Oracle Fusion i Acumatica w ogóle nie obsługują programowego odwracania i informują o tym przy próbie) oraz od tego, czy próba odwrócenia jest już w toku. Panel ponownie sprawdza kwalifikowalność zarówno przy otwarciu Odwróć, jak i bezpośrednio przed wysłaniem, więc wiersz, który w międzyczasie stał się nieaktualny — na przykład inne odwrócenie jest już w toku — pokazuje odmowę sterownika jego własnymi słowami, zamiast wysyłać z góry skazane żądanie.
Odwracanie wymaga erp.register.operate i jest zabezpieczone wyzwaniem potwierdzenia przez wpisanie: przepisujesz własny identyfikator dokumentu ERP księgowania, sprawdzany wyłącznie w przeglądarce i nigdy niewysyłany, zanim Odwróć się odblokuje — ten sam wzorzec zasięgu skutków, którego używają akcje zbiorcze, monit bezpieczeństwa, a nie krok zatwierdzenia.
Odwracanie może opcjonalnie przekierować nowy zapis na inny okres docelowy niż oryginalne księgowanie — uwzględniane w adapterach, których ERP akceptuje jawny okres księgowania, a odrzucane z czytelnym błędem w tych, które nie potrafią go wskazać. Przekierowanie nadal może wylądować w innym okresie niż zażądano: niektóre adaptery dowiadują się, czy je uwzględniono, dopiero po wysłaniu, więc panel podaje okres docelowy dopiero wtedy, gdy próba faktycznie zakończyła się jako odwrócona — nigdy wcześniej — a dla każdego innego wyniku odsyła do własnego komunikatu serwera. Twarda blokada w bazie danych uniemożliwia wysłanie drugiej próby odwrócenia, gdy jedna jest w toku, nawet po awarii procesu w trakcie wysyłania; odrzucenie przez ERP zwalnia tę blokadę automatycznie, ponieważ nic nie zostało utworzone.
Jedno odwrócenie naraz, niezależnie od miejsca rozpoczęcia. Odwrócenie wysłane z Rejestru księgowań oraz wysłane przez przepływ pracy lub interfejs API odwracania na poziomie projektu współdzielą tę samą blokadę, a każde ponownie odczytuje księgowanie po jej uzyskaniu, więc księgowanie nigdy nie zostaje odwrócone dwukrotnie — ani przez ponowne uruchomienie, ani przez dwa równoczesne żądania.
Nieznana odpowiedź jest wstrzymywana, a nie zgadywana. Gdy ERP przekracza limit czasu, zwraca błąd serwera lub odpowiada w sposób, którego PlaidCloud nie rozpoznaje, odwrócenie jest rejestrowane jako in_doubt, a nie odrzucane, i blokada pozostaje utrzymana. Dokument odwracający jest uznawany za odwrócenie tylko wtedy, gdy odzwierciedla oryginał — ta sama jednostka i waluta, data nie wcześniejsza, w każdym wierszu zamienione debet i kredyt; wszystko inne pozostaje wątpliwe do Twojego sprawdzenia.
Odwrócenie pozostawione jako pending lub in_doubt — o nieznanym wyniku — pozostaje takie, dopóki nie zostanie rozstrzygnięte. W przypadku Workday i Dynamics 365 Finance & Operations PlaidCloud wyszukuje odwrócenie in_doubt w ERP przy następnej próbie odwrócenia tego księgowania i rozstrzyga je na podstawie tego, co znajdzie. Odwrócenie pending w tych połączeniach oraz każde nierozstrzygnięte odwrócenie w każdym innym połączeniu jest czyszczone kontrolkami rozstrzygania w panelu, bramkowanymi przez erp.register.approve oprócz .operate: człowiek sprawdza ERP bezpośrednio i rejestruje, co znalazł — Zwolnij (nic tam nie utworzono, więc księga pozostaje nietknięta, a księgowanie znów można odwrócić) lub Oznacz jako odwrócone (dokument odwracający istnieje, wraz z jego identyfikatorem) — i to jedyny sposób, w jaki ta blokada jest kiedykolwiek zwalniana. Oznaczenie odwrócenia jako confirmed jest trwałe; w produkcie nie ma cofnięcia.

Rozdzielenie obowiązków

Odwrócenie na poziomie skonfigurowanego dla tenanta progu lub powyżej niego wymaga zatwierdzenia, zanim zostanie wykonane — a zatwierdzenie jest czymś, co robi zatwierdzający, a nie nazwiskiem podawanym przez zgłaszającego we wniosku.

Autor≠weryfikator. Członek zgłaszający odwrócenie nie może być jednocześnie jego zatwierdzającym ani własnym autoryzującym w trybie awaryjnym (break-glass).
Mierzone wielkością. Próg porównuje wielkość odwrócenia niezależnie od znaku — odwrócenie kredytu jest mierzone tak samo jak odwrócenie debetu.
Ostatnie odwrócenia wliczają się do progu. Przesuwane okno sumuje własne odwrócenia zgłaszającego na tym samym połączeniu, więc duże odwrócenie nie może zostać podzielone na kilka mniejszych, aby zmieścić się pod progiem. Kwoty są sumowane według wielkości, a nie kompensowane — odwrócenie ujemne i dodatnie nie znoszą się nawzajem.
Zawodzi bezpiecznie. Jeśli nie można zweryfikować wcześniejszego odwrócenia w oknie — na przykład z powodu niezarejestrowanej kwoty lub waluty — odwrócenie wymaga zatwierdzenia zamiast pomijania sprawdzenia.
Zatwierdzający musi być wykwalifikowany. Potrzebuje erp.register.approve — lub aktywnego delegowania od osoby, która go ma — oraz własnego uprawnienia do odwracanego połączenia. Jeśli oba posiada mniej niż dwóch członków, odwrócenia na poziomie progu lub powyżej niego są odrzucane, a nie przepuszczane.
Tryb awaryjny (break-glass) pozostaje jedyną ścieżką, na której zgłaszający sam wskazuje, kto autoryzował obejście: prawdziwa sytuacja nagła, rozstrzygana przez autoryzującego niezależnego od łańcucha operacyjnego — posiadającego erp.register.admin, ale nie .operate ani .approve, oraz własne uprawnienie do połączenia — a każde obejście jest trwale zapisywane w ścieżce audytu.
Odmowa nie podaje powodu. Niezależnie od tego, czy wniosek nie ma wykwalifikowanego zatwierdzającego, został rozstrzygnięty przez niewłaściwą osobę, czy nigdy nie został otwarty, odwrócenie jest odrzucane tym samym komunikatem — celowo, aby odmowa nie mogła posłużyć do ustalenia, kto ma jaką rolę lub uprawnienie. Rzeczywisty powód znajduje się w ścieżce audytu, a nie w błędzie.
Odwrócenie przebiegu wymaga jednego zatwierdzenia na pozycję, a nie jednego na przebieg. Odwrócenie całego przebiegu rozrachunków wewnątrzgrupowych naraz nie dostaje jednego zatwierdzenia na poziomie przebiegu — każda pozycja potrzebuje własnego, ponieważ zatwierdzenie jest powiązane z jednym księgowaniem, jednym połączeniem i jednym zatwierdzającym posiadającym tam uprawnienie, a nie ma jednego nazwiska, do którego można by powiązać wszystkie pozycje przebiegu.
Odwrócenia przechodzą przez rejestr. Gdy rozdzielenie obowiązków jest włączone, odwrócenie żądane przez interfejs API odwracania ERP na poziomie projektu — ścieżkę używaną przez projekt, funkcję zdefiniowaną przez użytkownika lub konto usługi — jest odrzucane, zanim cokolwiek dotrze do ERP, z komunikatem, aby odwrócić je z Rejestru księgowań. Zapisu, dla którego rejestr nie przechowuje szczegółów przechwycenia, również nie można tam odwrócić i należy go skorygować w ERP. Księgowanie nie jest tym dotknięte, a Business Central, Oracle Fusion i Acumatica nadal podają własny powód — że nie obsługują odwracania.

Włączenie rozdzielenia obowiązków i ustawienie jego progu jest konfigurowane dla Twojego tenanta przez PlaidCloud — nie ma jeszcze w konsoli przełącznika do tego.

Skrzynka zatwierdzeń

Gdy próg tego wymaga, Poproś o zatwierdzenie — oferowane obok Odwróć w panelu szczegółów — kieruje odwrócenie do każdego zatwierdzającego, który ma aktywne osobiste uprawnienie do tego połączenia. Nie ma osoby, do której trzeba je adresować; uprawnienie do połączenia jest routingiem. Zatwierdzający obsługują kolejkę z Zatwierdzenia na pasku: skrzynka wniosków oczekujących na ich decyzję oraz druga kolejka pokazująca wnioski, które sami zgłosili. Każdy wiersz zawiera kwotę księgowania, jednostkę i okres oraz czas oczekiwania, więc podjęcie decyzji nigdy nie wymaga opuszczenia kolejki w celu sprawdzenia czegoś. Zatwierdź lub Odrzuć wymaga podania jednego powodu, rejestrowanego wraz z decyzją.

Zatwierdzenie jest powiązane dokładnie z tym, na co zostało udzielone — księgowaniem, jego połączeniem, podanym powodem i okresem docelowym — i nie można go użyć ponownie do innego odwrócenia, innego powodu ani zmienionego okresu docelowego; zmieniony wniosek wymaga nowego zatwierdzenia. Na księgowaniu może być otwarty tylko jeden wniosek naraz, a zatwierdzenie zostaje zużyte w chwili jego zrealizowania. Po każdym zatwierdzeniu następuje krótkie wstrzymanie, w trakcie którego zarówno zatwierdzający, jak i zgłaszający mogą je jeszcze anulować — po jego upływie odwrócenie może już być dokumentem w ERP i nic tego nie cofnie. Wszystko jest sprawdzane ponownie w chwili faktycznego zastosowania odwrócenia — rola zatwierdzającego, dostęp obu stron do połączenia i minimum dwóch zatwierdzających w tenancie — więc wcześniej udzielone zatwierdzenie nie przetrwa utraty dostępu przez zatwierdzającego w międzyczasie.

Delegowanie

Zatwierdzający może delegować swoje uprawnienia do zatwierdzania innemu członkowi na ograniczony czas, z panelu Delegowania na pasku — przydatne, gdy zatwierdzający będzie niedostępny, a odwrócenia nadal wymagają rozstrzygnięcia. Udzielenie delegowania wymaga erp.register.approve; korzystanie z niego, przeglądanie własnych i zwracanie wymaga tylko .operate, ponieważ typowy zastępca w ogóle nie ma roli zatwierdzającego — na tym polega sens delegowania mu uprawnień.

Samodelegowanie jest odrzucane, podobnie jak para wzajemna (delegowanie do kogoś, kto już deleguje do Ciebie) lub dowolny dłuższy łańcuch — żadne z nich nie jest honorowane, więc dwaj członkowie nie mogą po cichu sprawić, że decyzje jednego liczą się jako pokrywające obu, bezpośrednio lub przez pośredni krok. Autor≠weryfikator nadal obowiązuje przy delegowaniu: zastępca nie może zatwierdzić wniosku osoby, która mu delegowała, ani własnego wniosku. Każda decyzja podjęta przez zastępcę jest zapisywana w ścieżce audytu jako podjęta w ramach uprawnień delegującego zatwierdzającego, a nie tak, jakby zastępca sam miał tę rolę.

Eskalacja

Zatwierdzenie czekające zbyt długo na decyzję wywołuje alert, aby nie starzało się po cichu w kolejce, której nikt nie obserwuje. Każdy odbiorca jest informowany tylko o wnioskach, które sam mógłby faktycznie rozstrzygnąć — e-mail eskalacyjny dla kolegi nigdy nie wymienia wniosku skierowanego do cudzych uprawnień — a alert nie zawiera kwoty ani dowolnego tekstu, zgodnie z tą samą minimalizacją, którą stosują pozostałe powiadomienia rejestru.

Przebiegi rozrachunków wewnątrzgrupowych

Przebieg rozrachunków wewnątrzgrupowych to grupa księgowań — jego pozycji — wykonanych razem na potrzeby jednego zamknięcia, identyfikowana przez dzień zamknięcia i numer kolejny naniesione na nie w tamtym czasie, a nigdy przez uruchomienie przepływu pracy, które je wytworzyło. (Ten identyfikator uruchomienia przepływu pracy żyje osobno w historii księgi i może przetrwać stempel zamknięcia księgowania, więc nie jest bezpiecznym sposobem identyfikacji przebiegu.) Wyświetl przebiegi, otwórz jeden, aby zobaczyć jego pozycje rozliczone i sparowane, i odwróć cały przebieg jako jedną kontrolowaną akcję.

Na razie dostępne wyłącznie przez API — GET /erp/register/runs, GET /erp/register/runs/{run_day}/{sequence} oraz POST /erp/register/runs/{run_day}/{sequence}/reverse — nie ma jeszcze ekranu w konsoli.

Zerowanie i parowanie

Otwórz przebieg, a jego pozycje zostaną rozliczone na dwa sposoby, oba ograniczone do połączeń, do których masz osobiste uprawnienia — ta sama reguła widoczności co wszędzie w rejestrze, więc przebieg obejmujący połączenia, które widzisz tylko częściowo, jest zgłaszany jako częściowo widoczny, a nie jako niezbilansowany.

Zerowanie, dla każdej waluty: werdykt zrównoważony, niezbilansowany lub nieokreślony, z rozbiciem jednostek stojących za każdą sumą netto. Waluta nie jest rozliczona, chyba że zarejestrowano każdą jej pozycję — jedna niezarejestrowana pozycja czyni całą walutę nieokreśloną, a nigdy sumą netto obliczoną tylko na tym, co akurat zmierzono.
Parowanie dopasowuje każdą pozycję zobowiązania do odpowiadającej jej pozycji należności za pomocą klucza parowania, który przepływ księgowania nanosi na obie przed wysłaniem którejkolwiek. Dopasowana para zeruje się w jednej walucie; wszystko inne ma nazwany powód — brak widocznej dla Ciebie pozycji kontrahenta, niezarejestrowana kwota, suma netto rzeczywiście różna od zera lub międzywalutowe, które jest zgłaszane i nigdy nie rozliczane, ponieważ nigdzie na platformie nie ma kursu walutowego.

Przebieg większy niż 200 pozycji jest zbyt duży, aby rozliczyć go lub sparować w jednej odpowiedzi: oba wyniki są zwracane jako nieokreślone, a nie obliczane na obciętym fragmencie przebiegu, więc duży przebieg nigdy nie zgłasza fałszywego salda ani fałszywego braku kontrahenta spowodowanego samym jego rozmiarem.

Odwracanie przebiegu

Odwróć każdą pozycję przebiegu jedną akcją, z POST /erp/register/runs/{run_day}/{sequence}/reverse.

Kwalifikowalność jest sprawdzana dla każdej pozycji z góry. Wszystko, co można ustalić wcześniej — stan, obsługa adaptera, oczekująca próba, Twoje osobiste uprawnienie do połączenia — odrzuca cały przebieg, zanim jakiekolwiek żądanie dotrze do ERP.
To, czego nie można wiedzieć z góry, jest zgłaszane później, dla każdej pozycji. Stan żywego ERP i autoryzacji może zmienić się w trakcie przebiegu, więc przebieg może zakończyć się jako częściowo odwrócony, mimo że przy sprawdzeniu wstępnym nic nie budziło zastrzeżeń. Nic nie jest automatycznie kompensowane — księgowanie kolejnych dokumentów w celu cofnięcia częściowego niepowodzenia to ryzykowniejszy zapis niż ten, który się nie powiódł. Częściowy przebieg naprawia się pozycja po pozycji, tak samo jak pojedyncze odwrócenie.
Ponowne uruchomienie odwrócenia przebiegu to sposób na dokończenie częściowego. Pozycje już odwrócone wcześniejszą próbą są odkładane na bok, a nie odrzucane, więc ponowna próba odwraca tylko to, co faktycznie pozostało.
Rozdzielenie obowiązków obowiązuje dla każdej pozycji, a nie dla sumy przebiegu. Gdy zasady SoD tenanta są egzekwowane, każda pozycja potrzebuje własnego zatwierdzenia, zanim przebieg cokolwiek wyśle — przy dowolnej kwocie, nie tylko powyżej progu. To celowo ostrożne podejście: wymóg danej pozycji można rozstrzygnąć dopiero w chwili jej wysłania — przesuwane okno przeciwdziałające dzieleniu, które zlicza własne pozycje przebiegu w miarę ich odwracania, oraz odczyt zwrotny z żywego ERP, który może się nie udać — więc żądanie wszystkich zatwierdzeń z góry powstrzymuje przebieg przed odwróceniem połowy pozycji i odkryciem w połowie drogi, że reszta też wymaga zatwierdzenia.
Akcje zbiorcze obejmują cały przebieg jednym wywołaniem. POST /erp/register/runs/{run_day}/{sequence}/approval-requests otwiera wniosek o zatwierdzenie dla każdej pozycji, na której zgłaszający może działać, a POST .../approval-decisions rozstrzyga każdą pozycję, do której zatwierdzający jest uprawniony — po jednym wywołaniu zamiast wniosku i decyzji dla każdej pozycji (20 wywołań dla rutynowego przebiegu z 10 pozycjami). Model zabezpieczeń pod spodem się nie zmienia: każda pozycja nadal dostaje własne zatwierdzenie, powiązane z tym księgowaniem, jego połączeniem, powodem i okresem docelowym, a zatwierdzający nadal potrzebuje własnego dostępu do połączenia każdej pozycji — pozycja, której nie może autoryzować, po prostu pozostaje oczekująca na kogoś, kto może, i nigdy nie jest wciągana. Wywołujący bez żadnych uprawnień do zatwierdzania jest odrzucany od razu, bez informacji, dla których pozycji otwarto wnioski. Wyniki wracają dla każdej pozycji, więc przebieg częściowo możliwy do autoryzacji zgłasza dokładnie, które pozycje rozstrzygnięto, a które pozostały oczekujące, i dlaczego.
Tryb awaryjny (break-glass) nie jest dostępny dla odwrócenia przebiegu. To obejście dwuosobowe dla jednego księgowania, a zastosowanie autoryzacji jednego świadka do całego przebiegu pomnożyłoby je przez liczbę jego pozycji. Użyj trybu awaryjnego dla pojedynczej pozycji przez POST /entries/{ledger_id}/reverse.
Przebiegów powyżej 200 pozycji nie można odwrócić jedną akcją. Odwracaj je częściami z listy zapisów.

Trendy

Trendy pokazują wskaźnik niepowodzeń i opóźnienia, pogrupowane według połączenia lub typu ERP, oraz rozkład kodów przyczyn odwróceń — każda liczba, w tym każdy mianownik, jest obliczana na podstawie Twoich bieżących uprawnień. Połączenie bez niczego ostatecznego w oknie pokazuje pauzę zamiast wskaźnika niepowodzeń, nigdy 0%, ponieważ idealne zero umieściłoby połączenie, którego nikt nie używa, na szczycie listy kondycji. Opóźnienie to ograniczona próbka z najnowszych księgowań ostatecznych, opisana jako próbka, a nie przedstawiana tak, jakby obejmowała całe okno. Przyczyny odwróceń pojawiają się wyłącznie jako ich ustrukturyzowane kody — dowolny tekst powodu wpisany przez osobę nigdy nie jest tu grupowany ani pokazywany.

Pochodzenie

Pochodzenie prowadzi od jednego księgowania wstecz do uruchomienia przepływu pracy, które je wytworzyło, i na zewnątrz do dokumentu w samym ERP. Wyszukaj je według identyfikatora uruchomienia lub identyfikatora księgi księgowania — zapytanie według identyfikatora księgi rozstrzyga uruchomienie najpierw przez Twoje uprawnienia, więc księgowanie na połączeniu, którego nie widzisz, nie rozstrzyga niczego, zamiast ujawniać, z jakiego uruchomienia pochodzi. Tam, gdzie PlaidCloud może zweryfikować kształt adresu URL dokumentu ERP dla danego adaptera, pochodzenie zawiera link bezpośredni do dokumentu; tam, gdzie nie może, lub księgowanie nigdy nie zostało potwierdzone, podaje, który z tych powodów ma zastosowanie, zamiast zgadywać link. Klucz biznesowy ERP nadal nigdy się tu nie pojawia — kluczem pochodzenia jest run_id przepływu pracy, a wskaźnikiem ERP jest confirmation_id, tak samo jak wszędzie w rejestrze.

Zamknięcia

Poproś o zamknięcie, aby zapieczętować okres — dla jednego lub wielu połączeń i jednostek — w niezmienną migawkę z określonego punktu w czasie: wszystko, co rejestr wiedział o tych księgowaniach w tamtej chwili, zachowane nawet wtedy, gdy żywe wiersze zostaną później ponowione, odwrócone lub wyczyszczone. Jest przeznaczone dla zablokowanego okresu księgowego, w którym potrzebujesz wiarygodnego, niezmiennego zapisu, a nie tego, co dziś pokazuje żywa siatka. Żądanie lub odczyt zamknięcia jest na razie dostępny wyłącznie przez API; nie ma jeszcze ekranu w konsoli do żądania ich ani przeglądania.

Żądanie zamknięcia (erp.register.operate) jest czynnością administracyjną obejmującą cały tenant, a nie osobistą — wskazane połączenia i jednostki są dokładnie tymi, które zostają zapieczętowane, niezależnie od Twoich osobistych uprawnień do połączeń. Ponowne zamknięcie już zamkniętego okresu nigdy nie jest destrukcyjne: zawsze tworzy nową, osobno numerowaną rewizję, a nie nadpisuje poprzedniej.

Zamknięcia materializują się samodzielnie. Żądanie zamknięcia nie pieczętuje go natychmiast — zadanie w tle automatycznie przegląda każde oczekujące zamknięcie według dziennego harmonogramu i zapisuje jego migawkę Iceberg bez żadnych dalszych działań z Twojej strony. Jeśli przegląd nie może zostać ukończony dla danego zamknięcia (na przykład z powodu awarii hurtowni danych), to zamknięcie jest oznaczane jako niepowodzenie, a nie pozostawiane w zawieszeniu, i jest automatycznie podejmowane ponownie podczas przeglądu następnego dnia — nigdy nie jest po cichu pomijane. Wyjątkowo duże zamknięcie (obejmujące więcej niż około 500 000 księgowań) to jedyny przypadek, który nie rozwiąże się w ten sposób sam: przegląd odmawia zapieczętowania go w jednym przebiegu i potrzebna jest pomoc PlaidCloud, aby zamknąć je w mniejszych partiach. To rzadki przypadek brzegowy dla większości okresów raportowych.

Gdy zamknięcie zostanie zmaterializowane, jego odczyt stosuje zwykłe reguły rejestru, ponownie rozstrzygane na żywo przy każdym odczycie, a nie wbudowane w migawkę w chwili pieczętowania: widzisz tylko wiersze z połączeń i projektów, do których aktualnie masz uprawnienia. W przeciwieństwie do żywej siatki, która pokazuje kwoty i tożsamość autora każdemu widzowi, który w ogóle widzi wiersz, kwoty zamknięcia są maskowane, chyba że masz erp.register.admin — ta sama reguła, którą stosuje Eksport. Zamknięcie zgłasza także własną liczbę późnych napływów: księgowań wysłanych lub zmienionych po znaczniku wysokiej wody zamknięcia, a więc nigdy nieuwzględnionych w pieczęci — widocznych tylko po zażądaniu nowego zamknięcia tego samego okresu, ponieważ nic nie otwiera starego ponownie.

Eksport

Eksporty i alerty to miejsce, w którym rejestr opuszcza konsolę jako plik lub powiadomienie — i jedyna powierzchnia, na której kontrole PlaidCloud przestają obowiązywać w chwili, gdy bajty opuszczą system. Wytworzenie eksportu lub zaplanowanie dostarczania wymaga erp.register.operate; otwarcie rejestru w celu jego obejrzenia nie.

Pobieranie teraz

Wyeksportuj rejestr, który aktualnie oglądasz, jako plik CSV przyjazny dla Excela lub jako JSON, zbudowany na nowo na podstawie Twoich bieżących uprawnień. W zależności od roli obowiązują dwa profile maskowania:

erp.register.operate otrzymuje standardowy, maskowany profil: kwoty i tożsamość autora są wstrzymywane.
erp.register.admin otrzymuje profil audytorski — jedyny, który niesie kwoty i tożsamość autora bez maskowania.

Każdy eksport podlega tym samym regułom co reszta rejestru: natural_key nigdy się nie pojawia, pola z dowolnym tekstem (komentarze, wartości wymiarów i worktagów) są wykluczane całkowicie, a nie tylko oczyszczane, a niezarejestrowana kwota jest pustym polem — odróżnionym od zamaskowanej, więc puste pole nigdy nie czyta się jako „nic nie zaksięgowano”, gdy w rzeczywistości oznacza „Twoja rola tego nie widzi”.

Planowanie dostarczania

Utwórz harmonogram — filtr, częstotliwość, format i listę odbiorców według członków lub połączenie Slack dla powiadomienia w ogóle bez treści wierszy. Oferowane są dwa rodzaje:

Eksport — cykliczne dostarczanie pliku CSV lub JSON z przefiltrowanym rejestrem.
Alert — powiadomienie wyzwalane jednym z trzech warunków: nieudane księgowanie rzeczywiste, starzejąca się autoryzacja lub odwrócenie księgowania. Przed zasubskrybowaniem zobacz podgląd tego, co wyzwalacz aktualnie by dla Ciebie dopasował.

Plik każdego odbiorcy jest budowany na podstawie jego własnych bieżących uprawnień w chwili wysyłania, a nie uprawnień właściciela harmonogramu — dwaj odbiorcy tego samego harmonogramu mogą otrzymać dwa różne pliki, a odbiorca, który w międzyczasie utracił rolę eksportu, utracił wszystkie uprawnienia do połączeń, został wyłączony lub nie ma zapisanego adresu, jest pomijany indywidualnie ze wskazaniem powodu, a nie po cichu odrzucany. Tylko właściciel harmonogramu lub osoba z erp.register.admin może usunąć lub uruchomić cudzy harmonogram.

Przechowywanie

Skonfiguruj, jak długo rejestr przechowuje trzy rodzaje historii: zarejestrowane szczegóły ładunku, księgowania symulowane i ścieżkę audytu — każdy jako liczbę dni, dla całego tenanta, co wymaga erp.register.admin. Każde pole jest zapisywane przy każdym wywołaniu; pominięte pole czyści ten horyzont, zamiast pozostawiać go bez zmian, a nieskonfigurowany tenant przechowuje wszystko (każdy horyzont jest odczytywany jako null, a nie ukryta wartość domyślna).

Przegląd przechowywania, który działa według tej polityki, uruchamia się teraz automatycznie, raz dziennie, dla całego tenanta — tym samym mechanizmem zadań okresowych, który napędza także zaplanowane eksporty i alerty, przenosi przeterminowane księgowania do kolejki wyjątków i wygasza stare księgowania symulowane.

Widoki zestawień

Zestawienie otwiera się jako panel z paska. Pogrupuj rejestr według uruchomienia, okresu lub połączenia, aby zobaczyć sumy częściowe i zestawienie statusów zamiast pojedynczych wierszy — grupowanie to kontrolka segmentowa u góry panelu, więc przełączasz się między Według uruchomienia, Według okresu i Według połączenia w miejscu, bez ponownego otwierania czegokolwiek.

Puste kwoty pozostają puste. Księgowanie bez zarejestrowanej kwoty — każde księgowanie SAP, księgowanie od razu ostateczne lub zapisane przed istnieniem tej funkcji — niczego nie wnosi do sumy częściowej i nigdy nie jest pokazywane jako 0.00. Każda grupa podaje słownie, czy zarejestrowano każde księgowanie w niej, niektóre nie, czy żadne.
Waluty nigdy nie są mieszane w jedną sumę. PlaidCloud nie wykonuje żadnych przeliczeń walutowych, więc grupa obejmująca więcej niż jedną walutę dostaje jeden wiersz na walutę, a nie jedną zmieszaną wartość — zobacz Formatowanie kwot.
Obcięta lista grup nadal sumuje się poprawnie. Jeśli grupowanie daje więcej grup, niż widok wyświetla, wiersz sum nadal obejmuje każdą grupę, a nie tylko pokazane, i o tym informuje.

Baner Kondycja połączeń pojawia się także w tym widoku.

Sumy kontrolne

Sumy kontrolne otwierają się jako panel z paska, nad tymi samymi połączeniami i jednostkami, do których Reguła widoczności już Cię ogranicza. Grupuje księgowania w partie i dla każdej podaje trójstanowy werdykt — Zrównoważony, Niezbilansowane lub Nieokreślone — z własnym podanym powodem serwera, nigdy samym słowem.

Nieokreślone to prawdziwa odpowiedź, a nie łagodne zaliczenie. Partia jest Zrównoważona tylko wtedy, gdy każdy jej wiersz został zmierzony, a jej grupy się zgadzają. Puste okno, niezarejestrowana kwota, adapter, który wysyła i zapomina, lub skan przerwany przed odczytaniem całej partii — wszystko to wraca jako Nieokreślone, z jawnie podanym powodem — nigdy jako domyślna zieleń.
Kwoty są puste, nigdy zerowe. Sumy źródłowe i zaksięgowane grupy oraz jej różnica są puste, ilekroć kwota nie została zarejestrowana lub potwierdzona — ta sama reguła, którą stosują widoki zestawień, ponieważ zmyślone 0.00 zaniżałoby niezmierzoną partię, a wyglądałoby jak miarodajna liczba.
Grupy są według waluty i jednostki i nigdy nie są sumowane razem. PlaidCloud nie wykonuje żadnych przeliczeń walutowych, więc partia obejmująca więcej niż jedną walutę lub jednostkę wymienia sumy każdej grupy obok siebie, a nie miesza ich — zobacz Formatowanie kwot, aby dowiedzieć się, jak te wartości są wyświetlane.
Wiersze sprzed przechwytywania dostają własny koszyk (no batch id). Księgowania zapisanego przed istnieniem przechwytywania partii nie można ponownie przypisać do partii, która nigdy go nie zawierała, więc jest pokazywane jako osobny wiersz, a nie wciągane ani porzucane.

Ten sam odczyt obejmuje też dwa pokrewne pytania: gotowość do zamknięcia okresu, dla każdej jednostki i okresu, która degraduje się do Nieokreślone — a nie do fałszywego Zablokowane — dla koszyka, dla którego platforma nie ma jeszcze liczb, takiego jak wiersz sprzed przechwytywania przy zamknięciu w momencie przejścia; oraz rozbieżność potwierdzeń, zgłaszaną dla każdego dokumentu, a nie dla każdej grupy, ponieważ dwa dokumenty rozchodzące się w przeciwnych kierunkach w tej samej grupie waluta/jednostka mogą zgadzać się w sumie i ukryć oba.

Panel szczegółów

Panel szczegółów dokuje się po prawej stronie obszaru roboczego, więc lista pozostaje widoczna, gdy czytasz jedno księgowanie. Otwórz go ikoną lupy w wierszu, naciskając Enter na zaznaczonym wierszu albo dwukrotnie klikając wiersz. Jest podzielony na karty:

Karta	Pokazuje
Dziennik	Linie debetowe i kredytowe księgowania, czytane tak, jak czytałby je księgowy. Zobacz Karta Dziennik.
Żądanie/odpowiedź	Żądanie wychodzące i odpowiedź ERP, przefiltrowane pod kątem minimalizacji danych (zobacz niżej).
Błędy	Każdy błąd zwrócony przez ERP lub krok księgowania.
Oś czasu	Stany księgowania w kolejności, od wysłania do stanu bieżącego.
Powiązane	Oryginalne księgowanie i jego odwrócenie, połączone ze sobą, jeśli istnieje.
Audyt	Zapis tylko do odczytu aktywności na tym księgowaniu. Na razie skąpy — zobacz Karta Audyt poniżej.
Komentarze	Wątkowe komentarze do tego księgowania, z @wzmianką po identyfikatorze członka. Zobacz Współpraca.
Zatwierdzenie	Bieżący status przeglądu księgowania — Sprawdzone, Wyczyszczone lub Wymaga dalszych działań — z pełną historią. Zobacz Współpraca.

Karta Dziennik

Karta Dziennik czyta jedno księgowanie tak, jak czytałby je księgowy — jego linie debetowe i kredytowe według konta, a nie surowy ładunek żądania.

Tylko kolumny, które każde ERP faktycznie rejestruje. Karta pokazuje pola, które dany system wysyła, i żadnych innych: księgowanie Acumatica pokazuje swoje subkonto, a system, który go nigdy nie wysyła, w ogóle nie pokazuje pustej kolumny subkonta — nie przeglądasz kolumn, które nigdy niczego nie będą zawierać.
Wymiary i worktagi znajdują się pod każdą linią. Szczegóły analityczne linii — jej wymiary lub worktagi Workday — pojawiają się pod linią, do której należą, a nie są upchane w dodatkowych kolumnach u góry.
Podsumowanie dla każdej waluty z dokładnym sprawdzeniem salda. Każda waluta jest sumowana osobno; sprawdzenie nigdy nie miesza walut i nigdy nie zaokrągla niezbilansowanego księgowania do zera, więc rzeczywista nierównowaga jest pokazana jako liczba, którą jest, a nie znika w 0.00.
Adapter, który nie rejestruje szczegółów linii, mówi o tym. Tam, gdzie sterownik — taki jak lokalny SAP — nie zapisuje rozbicia na linie, karta stwierdza to wprost, zamiast pokazywać pustą siatkę, którą można by odczytać jako „brak linii”.

Nawigacja klawiaturą

W Kolejce wyjątków strzałki w górę i w dół przechodzą od jednego księgowania do następnego, a panel szczegółów podąża za zaznaczeniem — dzięki temu możesz przejść całą sesję selekcji z klawiatury, czytając szczegóły kolejnych księgowań bez sięgania po mysz.

Główna siatka celowo zachowuje zaznaczanie myszą, Enter i dwukrotne kliknięcie: jej zaznaczanie wielu wierszy napędza akcje zbiorcze, takie jak ponawianie i czyszczenie księgowań symulowanych, więc strzałki tam przesuwają zaznaczenie, zamiast przeciągać panel przez każdy wiersz.

Współpraca

Pracuj nad księgowaniem z zespołem, nie opuszczając rejestru: komentuj je z @wzmianką, zapisz zatwierdzenie lub obserwuj połączenie albo uruchomienie pod kątem przyszłej aktywności.

Komentarze to wątkowe notatki w zwykłym tekście do jednego księgowania, z jego karty Komentarze. Oznacz koleżankę lub kolegę przez @wzmiankę po identyfikatorze członka, a zostaną powiadomieni — jeśli aktualnie widzą księgowanie; to sprawdzenie jest powtarzane w chwili wysyłania, nigdy nie jest zakładane na podstawie tego, kogo wspomniano.
Zatwierdzenie rejestruje jeden z trzech stanów — Sprawdzone, Wyczyszczone lub Wymaga dalszych działań — z opcjonalną notatką i zachowuje pełną historię tego, kto co ustawił i kiedy. To zapis, a nie bramka: nic obecnie nie blokuje księgowania ani odwrócenia na podstawie stanu jego zatwierdzenia.
Obserwuj połączenie lub uruchomienie — dwa osobne przełączniki — aby otrzymywać powiadomienia o przyszłej aktywności na którymkolwiek z nich.

Dodanie komentarza, zatwierdzenia lub obserwowania wymaga erp.register.view i .operate; odczytanie ich wymaga samego .view.

Minimalizacja danych

Rejestr jest zbudowany tak, aby pokazywać to, czego recenzent potrzebuje, by potwierdzić, że księgowanie nastąpiło, bez ujawniania wrażliwych danych, którymi krok księgowania zajmował się, aby do tego doprowadzić.

Ładunki żądań i odpowiedzi są na liście dozwolonych dla każdego adaptera. Pole pojawia się tylko wtedy, gdy zostało jawnie sklasyfikowane jako bezpieczne do zachowania. Numery kont bankowych, numery rozliczeniowe, IBAN-y, identyfikatory podatkowe i inne identyfikatory osobowe są usuwane, zanim zobaczysz ładunek.
Klucz biznesowy ERP jest całkowicie wstrzymywany. Może zawierać nazwę dostawcy lub inny token referencyjny, więc nigdy nie trafia do rejestru — w tym do Asystenta AI: ta sama lista dozwolonych, która decyduje o tym, co widzisz, decyduje o tym, co może zobaczyć monit modelu, a wartość klucza naturalnego w dowolnym miejscu tego ładunku jest odrzucana od razu, a nie wysyłana. Identyfikuj wiersz po identyfikatorze księgi i używaj confirmation_id jako własnego wskaźnika ERP do dokumentu — tego samego pola, które Historia księgowań ERP nazywa confirmation_id.
Pola z dowolnym tekstem są oczyszczane wzorcami przy odczycie i wykluczane całkowicie — nie tylko oczyszczane — z podsumowania, dowolnego monitu modelu AI i dowolnego eksportu. Oczyszczanie wzorcami wychwytuje kształt taki jak IBAN lub identyfikator podatkowy; nie wychwyci nazwy dostawcy wpisanej w notatce, dlatego wszystko opuszczające konsolę jako plik całkowicie pomija te pola, zamiast polegać wyłącznie na oczyszczaniu.

Karta Audyt

Karta Audyt jest tylko do wyświetlania. Jej szczegóły są w tej wersji celowo skąpe, ponieważ słownictwo audytu nie zostało jeszcze sklasyfikowane — spodziewaj się, że będą się uzupełniać w miarę postępu tej pracy, a nie że zmienią sposób czytania reszty panelu.

Wszystko inne na tej stronie — kolejka wyjątków, kondycja połączeń, widoki zestawień, akcje zbiorcze, ponawianie pojedynczych wierszy, odwracanie, sumy kontrolne, Asystent AI, trendy, pochodzenie, zamknięcia, współpraca i eksport — działa już dziś.