Udostępnij za pośrednictwem

Informacje o różnicach podczas uzgadniania Księgi Głównej do zarządzania zobowiązaniami lub do zarządzania należnościami

W tym artykule omówiono, dlaczego saldo konta zobowiązań lub saldo konta należności w księdze głównej różni się od całkowitej kwoty należnej według raportu z hipotetycznego badania historycznego w Microsoft Dynamics GP. Na końcu tego artykułu często zadawane są pytania.

Dotyczy: Microsoft Dynamics GP
Oryginalny numer KB: 866570

Uzgadnianie z procedurą GL było nowością w programie Microsoft Dynamics GP 10.0 (SP2). Ta rutyna generuje arkusz kalkulacyjny programu Microsoft Office Excel. Za pomocą tego arkusza kalkulacyjnego można dopasować transakcje do zarządzania zobowiązaniami lub zarządzania należnościami, które zostały opublikowane w Księdze Głównej. Ten proces nie generuje korekcyjnych transakcji. Ten proces może jednak pomóc w ustaleniu różnic transakcji wymienionych w tej sekcji. Aby otworzyć okno Uzgodnij z GL, wskaż pozycję Narzędzia w menu Microsoft Dynamics GP, wskaż pozycję Procedury, wskaż pozycję Finanse, a następnie wybierz pozycję Uzgodnij z GL.

Poniżej znajduje się lista uruchomionych problemów, które mogły powodować różnice:

  • Nie wszystkie partie GL są publikowane. (Uzgadnianie z arkuszem kalkulacyjnym GL raportuje tylko opublikowane wpisy).

  • Raport Historycznego przestarzałego salda prób jest drukowany z ograniczeniami. Wydrukuj ponownie raport Historyczne przestarzałe saldo wersji próbnej tylko z ograniczeniem daty.

  • Nie wszystkie konta płatne lub wszystkie konta należności są wyświetlane w rejestrze ogólnym. Upewnij się, że wszystkie konta płatne lub wszystkie konta należności są wyświetlane w rejestrze ogólnym.

  • Transakcje w zarządzaniu zobowiązaniami lub w zarządzaniu należnościami zostały zaksięgowane w Księdze Głównej. Partia w rejestrze ogólnym została zmieniona lub edytowana przed jej opublikowaniem.

  • Korekty rachunku płatnego lub rachunku należności mogły zostać wprowadzone bezpośrednio w Rejestrze Ogólnym. Te transakcje aktualizują konto w rejestrze ogólnym. Jednak te transakcje nie aktualizują raportu Historyczne przestarzałe saldo wersji próbnej.

  • Zakres dat w raporcie szczegółowego salda testowego w rejestrze ogólnym nie jest zgodny z zakresem dat w raporcie salda wiekowego okresu próbnego w obszarze Zarządzanie zobowiązaniami lub Zarządzanie należnościami. Po wydrukowaniu raportu Arkusz próbny zaległości historycznych zaznacz pole wyboru Data księgowania GL w obszarze Wybieranie transakcji dla raportu według.

  • Transakcje zostały zaksięgowane w Zarządzanie zobowiązaniami lub w Zarządzanie należnościami. Jednak te transakcje nie zostały opublikowane w General Ledger, jeśli dotyczą one początkowych sald. Jeśli pole wyboru Księgowanie do księgi głównej nie jest zaznaczone w oknie Konfiguracji księgowania dla serii Zakupów lub serii Sprzedaży, transakcje zostaną zaksięgowane w Zarządzaniu zobowiązaniami lub w Zarządzaniu należnościami. Jednak te transakcje nie zostaną opublikowane w rejestrze ogólnym.

  • Pole wyboru Śledź rabaty dostępne w GL jest zaznaczone w oknie Konfiguracja zarządzania płatnościami lub w oknie Konfiguracja zarządzania należnościami. Następnie kwota netto faktury zostanie zaksięgowana w księdze głównej. Ponadto pozostała kwota jest księgowana na konto rabatowe. Tylko kwota netto zostanie wyświetlona w raporcie szczegółowego bilansu próbnego w Księdze Głównej. Jednak na fakturze jest wyświetlana łączna kwota faktury brutto dla historycznego salda okresu próbnego w ramach zarządzania zobowiązaniami lub zarządzania należnościami.

  • Dokumenty zostały unieważnione w innym okresie niż zostały pierwotnie opublikowane. Raport Szczegółowe saldo prób w rejestrze ogólnym może nie być zgodny z raportem Historyczne przestarzałe saldo prób. Załóżmy na przykład, że faktura została wprowadzona w dniu 1.1.2007 r. Faktura została unieważniona w dniu 2.1.2007 r. Szczegółowy raport salda próbnego księgi głównej jest drukowany dla 2.02.2007 - 28.02.2007. Transakcja unieważniona zostanie wyświetlona w raporcie. Jeśli historyczne eksperymentalne saldo jest drukowane przy użyciu tego samego zakresu dat, unieważniony dokument nie zostanie uwzględniony w raporcie, ponieważ jest już nieważny.

  • Jeśli chcesz zrównoważyć saldo konta zobowiązań lub saldo konta należności z raportem o historycznym bilansie wiekowym za dany okres, saldo z raportu o historycznym bilansie wiekowym musi zostać uzgodnione ze zmianą netto w szczegółowym bilansie próbnym w rejestrze ogólnym za ten sam okres.

  • Jeśli chcesz zrównoważyć saldo konta zobowiązań lub saldo konta należności w Księdze Głównej do raportu historycznego bilansu próbnego na dzień, który nie znajduje się w określonym okresie, ustal, czy Zarządzanie Zobowiązaniami lub Zarządzanie Należnościami kiedykolwiek było zrównoważone. Jeśli zarządzanie zobowiązaniami lub zarządzanie należnościami nigdy nie zostały zrównoważone, początkowe salda mogą być nieprawidłowe. W takiej sytuacji najpierw zrównoważ najbardziej bieżący okres, a następnie uzgodnij poprzednie miesiące w odwrotnej kolejności.

  • Jeśli wystąpiły przerwy w delegowaniu, partie mogły nie zostać poprawnie opublikowane w Rejestrze Ogólnym, w zarządach płatnych lub do zarządzania należnościami.

  • Po wydrukowaniu raportu Historyczne przestarzałe saldo wersji próbnej nie zaznaczono następujących pól wyboru w obszarze Wykluczanie.

  • Zaznacz te pola wyboru, a następnie wydrukuj raport historycznego bilansu prób wiekowego.

    Uwaga

    Jeśli chcesz dopasować raport szczegółowy salda próbnego księgi głównej i raport historycznego salda próbnego według wieku według określonych dokumentów, odznacz pole wyboru W pełni opłacone dokumenty.

    • Niepostowane zastosowane dokumenty kredytowe
    • Zero Balance
    • Activity

  • Jeśli używasz Zarządzania Wielowalutowego podczas dokonywania przeszacowania, wybrano księgowanie na konto przesunięcia zakupów/sprzedaży.

  • Kwoty karty kredytowej wprowadzone w oknie Wprowadzania Transakcji Płatnych dla faktury. Może to spowodować nierównowagę w uzgadnianiu zarządu płatnego do księgi ogólnej, ponieważ tylko zmiana netto zostanie udostępniona modułowi General Ledger. (Oznacza to, że wydaje się, że brakuje transakcji GL, ale kwoty po stronie GL są zsumowane w jednym wpisie GL, podczas gdy po stronie PM mogą być wyświetlane trzy rekordy. Jednak powinny nadal odpowiadać sobie w najnowszych wersjach i poprawnie przejść do sekcji Dopasowane transakcje.)

  • Jeśli wystąpiły zakłócenia/problemy z księgowaniem partii Zobowiązań lub Należności, a transakcje zostały znalezione zarówno w tabelach Praca i Otwarte w tym samym czasie, usunięcie partii RM albo PM w usłudze Microsoft Dynamics GP może spowodować problemy. W tym przypadku użytkownik zwykle widzi rekordy w obu tabelach i decyduje, że nie potrzebuje partii roboczej, więc po prostu ją usuwa w Microsoft Dynamics GP. Ponieważ tabele Work and Open współużytkują tabelę dystrybucji, usunięcie partii w usłudze Microsoft Dynamics GP spowoduje również usunięcie z niej rekordów dystrybucji. Wynikiem końcowym jest to, że rekord nagłówka transakcji istnieje, ale nie ma pasujących dystrybucji po stronie RM lub PM, ale GL został poprawnie zaktualizowany. Ten problem będzie brany pod uwagę w następnej wersji programu Microsoft Dynamics GP.

  • Dystrybucje mogą być wyświetlane w sekcji Potencjalnie Dopasowane z różnymi kwotami, jeśli były rabaty. W celu dopasowania konta rabatu GL powinny zostać pobrane z kontem PM/RM przed uruchomieniem procesu Uzgadnianie z gl. Zamknij arkusz kalkulacyjny i uruchom go ponownie z wyświetlonymi kontami rabatu GL.

  • Dystrybucje mogą brakować po stronie PM/RM, jeśli typ (CASH, PAY, PURCH) został zmieniony. W arkuszu kalkulacyjnym uzgodnień konto jest używane tylko po stronie księgi głównej. Konto nie jest używane po stronie PM/RM. Strona PM/RM przeprowadza operacje przy użyciu typu PŁATNOŚCI lub REC niezależnie od używanego konta, dlatego należy pamiętać, aby wyświetlić listę wszystkich kont rozrachunkowych AP lub AR w oknie rekonsyliacji. Po prostu przełączenie typu dystrybucji w tabeli SQL nie spowoduje automatycznego wyświetlenia dystrybucji w przypadku ponownego wygenerowania arkusza kalkulacyjnego. (Był to problem w poprzednich wersjach dla płatności kartą kredytową z typem gotówka i rozliczanych na koncie AP, ale te rekordy są widoczne w GP 2016, więc nie wydaje się już problematyczne).

  • Sprawdź datę zastosowania i datę księgowania w głównej księdze w tabeli zastosowań dla transakcji wielowalutowych i porównaj z rzeczywistą datą, kiedy została zaksięgowana w głównej księdze. Na przykład w dniu 22 stycznia do faktury z dnia 5 grudnia zastosowano notę kredytową z datą 31 grudnia, a data zastosowania i data księgowania GL pozostały ustalone na 22 stycznia. Jednak podczas księgowania partii księgi głównej (GL) użytkownik zmienił datę na 31 grudnia. W tym przypadku arkusz kalkulacyjny Uzgodnienie z GL na grudzień zawiera zrealizowane kwoty zysku/straty po obu stronach, które wydają się być uzgodnione. Jednak raport HATB nie rozpoznaje jeszcze zrealizowanej kwoty zysku/straty i będzie różnił się o tę kwotę w porównaniu z GL, ponieważ nie został zastosowany lub opublikowany do stycznia zgodnie z zapisem o zastosowaniu.  

Często zadawane pytania

P1: Czy plik arkusza kalkulacyjnego uzgadniający z księgą główną stanowi prawdziwe uzgodnienie zobowiązań/należności z księgi głównej?

1: Funkcja uzgadniania do GL to narzędzie służące do rozwiązywania problemów, które pomaga użytkownikom identyfikować niezgodne dystrybucje między zarządzaniem zasobami (RM), zarządzaniem projektami (PM) i księgą główną (GL). Niekoniecznie chodziło o wiązanie się z HATB i to nie było zamierzonego celu, chociaż wiemy, że klienci to robią. Salda w arkuszu kalkulacyjnym Uzgadniania z GL są najlepszymi oszacowaniami przy użyciu prostego dodawania/odejmowania dystrybucji w tabeli. Podczas gdy salda na HATB uwzględniają prawie każdą tabelę i są znacznie bardziej złożone oraz dokładne, często zdarza się, że te wartości nie są zgodne ze sobą.

Prawdziwe uzgadnianie powinno być przeprowadzane pomiędzy raportami RM lub PM Historical Aged Trial Balance (HATB) i GL Trial Balance. Jeśli te dopasowania pasują do siebie, niekoniecznie musisz uruchamiać narzędzie Uzgadnianie do GL w tym miesiącu. Tabele GL składają się z debetów i kredytów, a tabele, z których czerpie HATB, to tabele nagłówków transakcji i tabele stosowania rekordów. W związku z tym klienci poprosili o sposób uzgodnienia dystrybucji w gl z tabelami dystrybucji w programie RM lub PM, aby pomóc w znalezieniu różnic na tym poziomie. Dlatego właśnie została utworzona rutyna Uzgadnianie z GL. Miał on być narzędziem do rozwiązywania problemów, aby porównać dystrybucje z dystrybucjami między modułami, aby pomóc zidentyfikować brakujące dystrybucje, które mogą prowadzić do powrotu do brakującej transakcji z HATB. Dlatego użyj narzędzia Uzgodnij z GL jako pomoc tylko w celu ułatwienia uzgadniania salda próbnego HATB z GL. Jeśli saldo HATB i GL TB równoważą się, to na ten miesiąc nie trzeba uruchamiać narzędzia Uzgodnij z GL.

Q2: Czy sumy w arkuszu kalkulacyjnym Uzgodnij z GL są zgodne z sumami w HATB?

A2: Nie. Sumy w arkuszu kalkulacyjnym "Reconcile to GL" są tylko prostym dodawaniem/odejmowaniem zapisów dystrybucji w tej tabeli i nie uwzględniają żadnych innych tabel. Podczas gdy HATB analizuje zupełnie różne tabele, aby obliczyć saldo przy użyciu transakcji i zastosować tabele rekordów i jest znacznie bardziej złożone obliczenie. Ze względu na różne metody obliczeniowe/tabele używane do uzyskiwania sald, arkusz kalkulacyjny Uzgadnianie z GL nie powinien bezpośrednio odpowiadać zestawieniom wiekowym sald w raportach HATB, a poprzez to uzgadnianie będzie trudne. Nie jest konieczne powiązanie sald w arkuszu kalkulacyjnym GL z raportem HATB.

Sugerujemy ignorowanie sum w arkuszu kalkulacyjnym GL i po prostu użyj sekcji Niedopasowane i Potencjalnie dopasowane, aby ułatwić znalezienie różnic w badaniach, aby sprawdzić, czy może to również wyjaśnić różnicę między GL TB i HATB. Arkusz uzgadniania do GL nie jest prawdziwym uzgodnieniem i miał być jedynie pomocą w identyfikacji różnic w dystrybucjach, aby sprawdzić, czy są one również obecne na poziomie transakcji. W rzeczywistości, jeśli HATB pasuje do GL TB, naprawdę nie byłoby potrzeby uruchamiania narzędzia do uzgadniania z GL dla tego miesiąca w ogóle, ponieważ nie ma żadnych różnic do zidentyfikowania.

Jeśli nadal chcesz powiązać saldo z arkusza kalkulacyjnego GL z saldem w HATB, nie jest to obsługiwane w standardowej procedurze wsparcia. Zidentyfikowane przyczyny są wymienione w górnej części tej bazy wiedzy i może być więcej przyczyn, które jeszcze nie zostały zidentyfikowane. Ale ponieważ to uzgadnianie nie jest konieczne pomiędzy prostym łącznym saldem wymienionym w arkuszu kalkulacyjnym GL a bardziej złożonym obliczonym saldem w raporcie HATB, i nie jest to funkcją tego narzędzia uzgodnień, należy rozważyć wydatki na konsultacje, aby przeanalizować dane i pomóc w ich wzajemnym uzgodnieniu.

P3: Co należy zrobić, jeśli brakuje alokacji po stronie księgi głównej?

A3: Jeśli znajdziesz dystrybucje po stronie RM lub PM, które nie występują po stronie GL, zbadaj stronę GL w kontekście różnic czasowych. Upewnij się, że wszystkie serie GL zostały zaksięgowane. Jeśli naprawdę brakuje ich po stronie GL, musisz wprowadzić dostosowujący zapis w dzienniku bezpośrednio do GL, aby utworzyć dystrybucje GL.

Q4: Co należy zrobić, jeśli brakuje dystrybucji po stronie Menedżera Zasobów lub Menedżera Projektów?

A4: Jeśli rozkład GL jest wymieniony, ale brakuje go po stronie RM lub PM, najpierw zbadaj różnice w czasie. Ponadto badania, aby sprawdzić, czy sama transakcja jest wymieniona w raporcie HATB i jest już uwzględniona. Istnieje możliwość, że transakcja istnieje, ale brakuje dystrybucji. Zatem pytanie brzmi jak w takim razie uzyskać dystrybucje w RM lub PM, jeśli transakcja faktycznie istnieje? Najpierw należy pamiętać, że tabele dystrybucji w RM lub PM są używane wyłącznie w tym arkuszu kalkulacyjnym do uzgadniania i nie mają innego zastosowania w raportach GP. Czy więc naprawdę jest konieczne dodanie ich ponownie do RM lub PM? Oceń, czy warto wypełnić tabelę, która nie jest używana nigdzie indziej.

Jeśli jednak zdecydujesz się naprawić tabelę dystrybucji PM, musisz unieważnić dokument, więc zastosowane rekordy zostaną przeniesione z powrotem do stanu otwartego. Następnie usuń unieważniony dokument za pomocą narzędzia Usuń historię transakcji. Pamiętaj, aby ustawić księgowanie na Główną Księgę i nie księgować do Głównej Księgi. Usuń partię GL utworzoną przez void. Następnie wprowadź ponownie dokument do księgi zobowiązań, aby transakcje i rozliczenia zostały odtworzone. Pamiętaj, aby unieważnić partię GL. Następnie ponownie zastosuj nowy dokument do otwartych dokumentów i powinny zostać ponownie przeniesione do historii.

Aby rozwiązać ten problem w tabeli dystrybucji RM, należy usunąć obie strony faktury i płatności, a następnie ponownie użyć ich zarówno z powrotem, jak i usunąć partię w gl.

P5: Transakcje w sekcji Potencjalnie dopasowane wyglądają tak, jakby były zgodne. Dlaczego nie są one w sekcji Dopasowane?

A5: Istnieje kilka pól pasujących do każdego rekordu dystrybucji. Wszystkie pola muszą być zgodne, aby przenieść je do sekcji Dopasowane. Jeśli niektóre, ale nie wszystkie pola są zgodne, zostanie ono umieszczone w sekcji Potencjalnie dopasowane. Na przykład poniżej przedstawiono pola, które są dopasowane dla pm do GL:

Zarządzanie zobowiązaniami - Księgowość główna
Numer kuponu — numer kontrolny pochodzenia
Źródło TRX — źródło źródłowe TRX
Data delegowania — data transakcji
Kwota na koncie — kwota debetowa lub kwota kredytowa

Pytanie 6: Jeśli wprowadzę brakujące dystrybucje w GL lub RM/PM i ponownie uruchomię arkusz do uzgodnienia z GL, czy elementy, które nie zostały dopasowane lub które mogą zostać dopasowane, zostaną przeniesione do sekcji "Dopasowane"?

A6: Nie. Jeśli transakcje są wprowadzane oddzielnie, będą miały różne numery bonów i kody źródła Trx. W najlepszym razie data i kwoty delegowania mogą być zgodne, co może umieścić je w sekcji Potencjalnie dopasowane arkusza kalkulacyjnego.

Pytanie 7: Dlaczego saldo końcowe w arkuszu kalkulacyjnym miesięcznym lub kwartalnym nie jest zgodne z saldem początkowym w następnym arkuszu kalkulacyjnym miesięcznym lub kwartalnym?

A7: Jeśli saldo końcowe jednego okresu nie jest zgodne z saldem początkowym następnego okresu, często wynika to z osieroconych rekordów dystrybucji, które nie mają skojarzonego rekordu nagłówka w tabeli rejestru podrzędnego. Saldo końcowe jest obliczane przez program Excel bezpośrednio w arkuszu kalkulacyjnym. Po prostu przyjmuje saldo początkowe dla tego okresu z górnej części arkusza kalkulacyjnego i dodaje lub odejmuje rekordy dystrybucji, które się w nim pojawiają, aby uzyskać końcowe saldo. Z drugiej strony, w następnym okresie, saldo początkowe jest obliczane poprzez proste obliczenie debetowe/kredytowe zapisów dystrybucji w tabeli SQL, a procedura składowana łączy z tabelą nagłówków, więc nie obejmie żadnych dystrybucji, które nie mają rekordu nagłówka. Wynikiem końcowym może być to, że niektóre rozkłady zostały obliczone na saldo końcowe w poprzednim arkuszu kalkulacyjnym i pominięto od początku salda w następnym okresie.

Q8: Dystrybucje po stronie RM/PM istnieją, ale nie są pobierane do arkusza kalkulacyjnego.

A8: Przejrzyj następujące porady dotyczące rozwiązywania problemów:

  • Sprawdź zakres dat używany w arkuszu kalkulacyjnym "Reconcile to".
  • Sprawdź, czy dystrybucje istnieją w tabelach PM10100 lub PM30600 dla PM. (lub w przypadku menedżera zasobów: wyszukaj RM10101 lub RM30301) Sprawdź daty w tych dystrybucjach, aby upewnić się, że mieszczą się one w zakresie wprowadzonym dla arkusza kalkulacyjnego. Ważne jest, aby zlokalizować je w tabelach dystrybucji RM lub PM, a nie polegać wyłącznie, na przykład, na przedrukowanych dziennikach publikowania.
  • Jeśli znajdziesz dystrybucje w tabelach RM lub PM, sprawdź te rozkłady w dokumencie na interfejsie użytkownika. Czy mają typ dystrybucji PŁATNOŚĆ, REC lub DOSTĘPNOŚĆ? Są to jedyne typy, które zostaną pobrane do arkusza kalkulacyjnego uzgadniania po stronie RM lub PM w starszych wersjach. (Aktualizacja: Płatności kart kredytowych mogą spowodować rozliczenie na konto AP z typem GOTÓWKI, która znajduje się w tabeli, ale arkusz uzgodnień z GL nie wyświetlał tej transakcji po lewej stronie. Jest to zatem tylko problem wyświetlania, a nie problem z danymi. Jednak wydaje się, że nie jest to problem w programie Microsoft Dynamics GP 2016, ponieważ typ GOTÓWKI jest teraz poprawnie wyświetlany w arkuszu, więc został naprawiony.)

Czy można wyświetlić okno Uzgadnianie z GL w innych walutach?

A9: Okno Uzgadnianie z GL zostało zaprojektowane tak, aby wyświetlać wyłącznie waluty funkcjonalne. Aby uzyskać więcej informacji, zapoznaj się z Informacjami o saldach w oknie Uzgadnianie z GL w programie Microsoft Dynamics GP.