Księgowanie zapisów dziennika w NetSuite

Księguj zapisy dziennika z tabel projektu PlaidCloud w NetSuite za pomocą kroku Post NetSuite Journal Entry przepływu pracy. Ten przewodnik buduje partię z tabeli nagłówków i tabeli wierszy, wyświetla jej podgląd bez kontaktu z NetSuite, a następnie ją księguje i odczytuje wynik.

Uwaga

Przed zaksięgowaniem na żywo przejdź dla każdej partii przez sekcję Podgląd i weryfikacja poniżej, a przy pierwszym uruchomieniu na prawdziwym koncie uzgodnij kilka księgowań bezpośrednio w NetSuite.

Wymagania wstępne

• Działające połączenie NetSuite z rolą, która może tworzyć zapisy dziennika (dostęp Create do rekordu Journal Entry, oprócz konfiguracji REST/OAuth opisanej w przewodniku dotyczącym odczytu).
• Dwie tabele źródłowe w projekcie:
  • Tabela nagłówków z jednym wierszem na każdy zapis dziennika.
  • Tabela wierszy z jednym lub wieloma wierszami debetowymi/kredytowymi na każdy zapis dziennika.

Notatka

Tabele nagłówków i wierszy mogą pochodzić z dowolnego miejsca przepływu pracy — z importu, wcześniejszego przekształcenia lub tabeli przestawnej. Jedynym wymaganiem jest to, by obie zawierały kolumnę identyfikatora dziennika (Journal ID) łączącą każdy wiersz z jego nagłówkiem.

Przygotowanie tabel nagłówków i wierszy

1. Zbuduj lub zaimportuj tabelę nagłówków z jednym wierszem na każdy zapis dziennika. Minimalnie potrzebuje ona:

   Kolumna	Mapowana na	Wymagana
   Identyfikator dziennika	Journal ID	Tak
   Spółka zależna NetSuite	Subsidiary	Tak
   Data zapisu	Posting Date	Tak
   Waluta NetSuite	Currency	Nie
   Opis na poziomie zapisu	Memo	Nie
   Zewnętrzny identyfikator podany przez wywołującego	External ID	Nie

2. Zbuduj lub zaimportuj tabelę wierszy z jednym lub wieloma wierszami na każdy zapis dziennika, z tym samym identyfikatorem dziennika co wiersz nagłówka:

   Kolumna	Mapowana na	Wymagana
   Identyfikator dziennika	Journal ID	Tak
   Konto księgi głównej	Account	Tak
   Kwota po stronie Wn (0, jeśli brak)	Debit	Tak
   Kwota po stronie Ma (0, jeśli brak)	Credit	Tak
   Opis na poziomie wiersza	Memo	Nie
   Dział, klasa, lokalizacja, jednostka	Department / Class / Location / Entity	Nie

   Uwaga

   Wiersze każdego zapisu dziennika muszą się bilansować — suma debetów musi być równa sumie kredytów co do grosza. Niezbilansowany zapis nigdy nie jest wysyłany do NetSuite; zamiast tego jest rejestrowany jako błąd (zobacz Podgląd i weryfikacja).

3. Zgrupuj kwoty w tych dwóch tabelach na takim poziomie, na jakim księgujesz — jeden zapis na dzień, na dokument lub na partię — używając zwykłych kroków tabel (tabeli przestawnej, agregacji z grupowaniem lub złączenia). Identyfikator dziennika łączy zestaw wierszy z jego nagłówkiem, więc zbuduj go jako klucz unikatowy dla każdego zapisu dziennika i wspólny dla wszystkich należących do niego wierszy.

Konfiguracja kroku

1. Dodaj do przepływu pracy krok Post NetSuite Journal Entry.

2. Na karcie Connection ustaw NetSuite Connection na swoje połączenie NetSuite i wybierz Environment.

3. Na karcie Data:

   • Ustaw Journal Entry Header Table i Journal Entry Lines Table na tabele zbudowane powyżej.
   • Na razie pozostaw zaznaczone Test Only Mode — zobacz Podgląd i weryfikacja.
   • Pozostaw zaznaczone Continue posting remaining entries if one entry fails, chyba że wolisz, aby partia zatrzymała się na pierwszym błędnym zapisie.
   • Pozostaw wyłączone Submit Asynchronously, chyba że konieczna jest ścieżka asynchronicznego przyjmowania w NetSuite dla partii o dużej objętości — zobacz Przesyłanie asynchroniczne poniżej.
   • Ustaw Posting Result Table na tabelę, którą PlaidCloud może utworzyć lub nadpisać. Będzie ona potrzebna przy każdym uruchomieniu, nie tylko za pierwszym razem — zobacz Odczyt tabeli wyników.

4. Na karcie Header Map zmapuj kolumny tabeli nagłówków na Journal ID, Subsidiary, Posting Date oraz (jeśli je masz) Currency, Memo i External ID. Użyj Header Filters, jeśli chcesz zaksięgować tylko podzbiór wierszy nagłówka.

5. Na karcie Line Map zmapuj kolumny tabeli wierszy na Journal ID, Account, Debit, Credit oraz (jeśli je masz) Memo, Department, Class, Location i Entity. Użyj Line Filters w ten sam sposób.

Notatka

Każde pole z wewnętrznym identyfikatorem — Subsidiary, Account, Currency, Department, Class, Location, Entity — przyjmuje wewnętrzny identyfikator NetSuite, a nie jego nazwę wyświetlaną. Jeśli dane źródłowe zawierają nazwę wyświetlaną, najpierw zamień ją na wewnętrzny identyfikator (wyszukanie w małej tabeli referencyjnej pobranej z NetSuite lub złączenie z tabelą, którą prowadzisz samodzielnie).

Podgląd i weryfikacja

Przy zaznaczonym Test Only Mode uruchom krok. PlaidCloud buduje każdy zapis dziennika ze zmapowanych danych i wykonuje te same sprawdzenia, które wykonałby przed księgowaniem — zbilansowanie debetów i kredytów, obecność wymaganych pól, prawidłową datę księgowania — bez ani jednego wywołania NetSuite. Nic nie zostaje zaksięgowane.

1. Uruchom krok (zobacz Uruchamianie jednego kroku w przepływie pracy).

2. Otwórz tabelę wyników i upewnij się, że każdy wiersz, który miał zostać zaksięgowany, ma status = validated. Każdy wiersz z wartością error wskazuje identyfikator dziennika zapisu i problem — najczęściej niezbilansowany zapis, brakujące konto (Account) albo puste pole Subsidiary lub Posting Date.

3. Popraw dane źródłowe (lub mapowania i filtry) dla każdego wiersza error i uruchamiaj ponownie, aż partia przejdzie weryfikację bez błędów.

Księgowanie partii

Gdy partia przejdzie weryfikację bez błędów, odznacz Test Only Mode i uruchom krok ponownie. Tym razem PlaidCloud faktycznie księguje w NetSuite każdy zweryfikowany zapis.

Uwaga

Księgowanie to nie to samo co ponowna weryfikacja — po każdej zmianie danych źródłowych lub mapowań zawsze uruchamiaj krok ponownie w trybie Test Only Mode i wyłącz go dopiero wtedy, gdy masz pewność co do wyniku. Krok zaplanowany do uruchamiania bez nadzoru traktuj tak samo, jak każdy inny zapis do ksiąg wykonywany bez nadzoru.

Przesyłanie asynchroniczne

Submit Asynchronously wysyła każdy zapis z asynchronicznym nagłówkiem akceptacji NetSuite zamiast czekać na synchroniczne utworzenie i odczyt zwrotny. NetSuite umieszcza zapis w kolejce i odpowiada natychmiast; PlaidCloud rejestruje go jako pending wraz z odwołaniem do przesłania, a nie jako posted lub error.

Uwaga

Obecnie żadny mechanizm nie rozstrzyga zapisu oczekującego automatycznie. Rozstrzyga go ponowne uruchomienie tego kroku — krok wyszukuje zapis oczekujący po odwołaniu do przesłania i rejestruje jego ostateczny wynik (posted lub error). Jeśli włączysz Submit Asynchronously, uwzględnij ponowne uruchamianie kroku w przepływie pracy (zaplanowane ponowne uruchomienie lub kolejny krok w tym samym przepływie pracy), zamiast traktować każdy wiersz pending jako zakończony. Pozostaw tę opcję wyłączoną, chyba że jest naprawdę potrzebna dla partii o dużej objętości, w której ścieżka synchroniczna jest zbyt wolna.

Odczyt tabeli wyników

Tabela wyników zawiera jeden wiersz na każdy zapis dziennika, którego dotyczyła próba, niezależnie od trybu, w którym uruchomiono krok:

Kolumna	Opis
journal_id	Identyfikator dziennika z tabeli nagłówków.
external_id	Zewnętrzny identyfikator użyty w tej próbie księgowania (patrz niżej).
internal_id	Wewnętrzny identyfikator NetSuite utworzonego zapisu lub odwołanie do przesłania asynchronicznego, gdy status to pending. Puste w Test Only Mode i w przypadku błędu.
status	validated, posted, pending (Submit Asynchronously — zapis przyjęto, ale NetSuite go jeszcze nie potwierdził) lub error.
message	Szczegóły błędu przy error. Puste przy posted/validated.

Kolejne kroki — powiadomienie o każdym wierszu error, złączenie z tabelą nagłówków w celu zapisania internal_id — buduj na tej tabeli, a nie na statusie uruchomienia samego kroku, ponieważ jeden błędny zapis w dużej partii nie powoduje niepowodzenia całego kroku, gdy włączono Continue posting remaining entries.

Bezpieczne ponowne uruchamianie partii

Każdy zapis jest księgowany z deterministycznym zewnętrznym identyfikatorem zbudowanym z projektu, połączenia, identyfikatora dziennika, daty księgowania i kwot jego wierszy. Ponowne uruchomienie kroku dla niezmienionego zapisu używa tego samego zewnętrznego identyfikatora, a mechanizm obsługi zewnętrznych identyfikatorów w NetSuite zapobiega utworzeniu duplikatu — dlatego ponowne uruchomienie przepływu pracy po przejściowej awarii jest bezpieczne dla zapisów, które się nie zmieniły.

Uwaga

Ta ochrona dotyczy wyłącznie niezmienionego zapisu. Jeśli zmienisz wiersze zapisu — inną kwotę, dodany lub usunięty wiersz — i uruchomisz krok ponownie, PlaidCloud obliczy nowy zewnętrzny identyfikator, a NetSuite zarejestruje drugi zapis dziennika, a nie aktualizację pierwszego. Aby poprawić zapis, który już został zaksięgowany, popraw go bezpośrednio w NetSuite. Wpisanie własnej wartości w kolumnie External ID tabeli nagłówków zastępuje wartość wygenerowaną przez PlaidCloud, jeśli zewnętrzne identyfikatory mają podlegać Twojemu schematowi.

Powiązane

• Połączenie z NetSuite — konfiguracja połączenia, przez które ten krok księguje
• Opis kroku Post NetSuite Journal Entry — pełny opis pól i konfiguracji
• Przykłady zapytań SuiteQL w NetSuite — pobierz spółki zależne, konta i wymiary, których potrzebujesz jako wewnętrznych identyfikatorów
• Zaawansowane użycie Data Mapper