Pojedynczy załącznik
Ważne
Niektóre lub wszystkie funkcje wymienione w tym artykule są dostępne w ramach wydania wersji zapoznawczej. Zawartość i funkcje mogą ulec zmianie. Aby uzyskać więcej informacji dotyczących wydań wersji zapoznawczych, zobacz Dostępność aktualizacji usługi.
Co to jest „pojedynczy załącznik”?
Ze względu na elastyczność arkuszy finansowych można wprowadzić pojedynczy bon, który reprezentuje jedną transakcję, ale ma wielu klientów, sprzedawców, środki trwałe, projekty lub konta bankowe. Microsoft nazywa tę funkcjonalność pojedynczym załącznikiem. Scenariusze pojedynczego załącznika nie obejmują transakcji, które obejmują tylko konta księgowe. Transakcje te są księgowane do księgi głównej, a nie do ksiąg pomocniczych takich jak Należności, Środki trwałe czy Bank.
Istnieją dwie kategorie przykładów pojedynczego załącznika:
Załącznik zawiera wiele transakcji wprowadzonych jako pojedynczą transakcję. Oto kilka możliwych przykładów:
- W każdym wierszu wpisuje się wiele płatności dla sprzedawców (nie stosuje się konta offsetowego), a w jednym wierszu wpisuje się sumę płatności skompensowaną do rachunku bankowego. Podsumowania płatności dokonuje się w celu aktualizacji księgi pomocniczej banku jako kwoty podsumowanej, zgodnej z wyciągiem z rachunku bankowego. Jednak każda transakcja z dostawcą jest nadal szczegółowo rejestrowana w księdze pomocniczej Zobowiązania. Ten sam scenariusz występuje również po stronie płatności klienta.
- W jednym załączniku nabywanych jest wiele środków trwałych. Takie podejście jest często stosowane w przypadku wprowadzania bilansów początkowych dla modułu Aktywa trwałe.
Załącznik zawiera jedną transakcję, która wpływa na wiele typów kont nieksięgowych. Oto kilka możliwych przykładów:
- Przelewy bankowe
- Kompensowanie sald sprzedawcy/klienta (ta sama strona)
- Przeniesienie sald z klienta A do klienta B
- Faktury sprzedawców, które mają wiele linii zawierających środki trwałe lub projekty
Poprzednie przykłady dla każdej kategorii reprezentują ważne wymagania biznesowe. Czasami wymagania biznesowe nie mogą być spełnione w inny sposób: organizacja musi wprowadzić transakcje jako pojedynczy załącznik. Jednak w innych przypadkach istnieją inne ważne sposoby spełnienia wymagań biznesowych: transakcje można wprowadzić inaczej lub użyć innej funkcji.
Problemy z pojedynczym załącznikiem
Użycie funkcjonalności pojedynczy załącznik w celu spełnienia wymagań biznesowych może spowodować problemy. Różne procesy, cofnięcia transakcji oraz zapytania/raporty wymagają szczegółów transakcji. Tych szczegółów nie można określić na podstawie bieżącego modelu danych, jeśli w jednym załączniku wprowadzono wiele transakcji w podsumowaniu. Ponadto nie zawsze można jednoznacznie określić szczegóły, jeśli nie jest znany typ transakcji, która jest wprowadzana. Ograniczenie to wynika z elastyczności arkuszy, zwłaszcza gdy są one wprowadzane przez arkusz ogólny.
Niektóre scenariusze mogą nadal działać poprawnie, w zależności od konfiguracji organizacji. Oto obszary, w których możesz napotkać problemy:
Rozliczenie – jeśli na załączniku występuje więcej niż jeden dostawca lub klient, księgowość tworzona podczas rozliczenia może być nieprawidłowo przypisana do wymiarów finansowych. Więcej informacji na temat problemów, które mogą wystąpić podczas rozliczania, można znaleźć w części Pojedynczy załącznik z wieloma rekordami klienta lub sprzedawcy. Na wydajność rozliczeń duży wpływ ma liczba wierszy arkusza faktur, w których jest używany jeden załącznik. Oczekuje się, że ilość czasu wymaganego do rozliczenia i zaksięgowania płatności wzrośnie wykładniczo, im więcej wierszy arkusza faktur będzie używać jednego załącznika.
Obliczanie podatku – jeśli na danym załączniku istnieje więcej niż jeden bon lub klient, obliczenie podatku może być nieprawidłowe.
Wycofanie transakcji – jeżeli na załączniku istnieje więcej niż jeden typ konta księgowego pomocniczego, w przypadku odwrócenia pojedynczej transakcji księgi pomocniczej w księdze głównej może zostać zaksięgowany nieprawidłowy zapis księgowy dotyczący odwrócenia transakcji. Na przykład, jeśli nabędziesz wiele aktywów w jednym załączniku, a następnie odwrócisz nabycie jednego z aktywów, księgowość księgi głównej będzie nieprawidłowa dla odwrócenia.
Raporty i zapytania – w przypadku uwzględnienia na załączniku więcej niż jednego typu konta księgowego pomocniczego (na przykład Dostawca i Klient), raporty/zapytania pokażą tylko pierwszą znalezioną wartość konta.
Na przykład księgujesz następującą wielostronicową fakturę sprzedawcy. Zawiera on cztery projekty reprezentujące „wiersze” na fakturze. Takie podejście jest częstym wymaganiem biznesowym dla organizacji, które szeroko korzystają z arkuszy.
Trzy z czterech projektów są księgowane na tym samym koncie głównym (601500). Jeśli otworzysz eksplorator źródeł księgowych, aby zobaczyć szczegóły dotyczące zaksięgowanych transakcji dla tego konta głównego, zauważysz, że identyfikator projektu dla wszystkich trzech linii to 000057. To zachowanie jest znane ograniczeniem pojedynczego załącznika. Szczegóły nie będą poprawnie łączyć każdego wiersza z odpowiednim projektem na arkuszu. Zamiast tego na raportach i w zapytaniach zawsze będzie pokazywana pierwsza znaleziona wartość konta.
Wprowadź transakcję jako pojedynczy załącznik
Aby wprowadzić transakcje jako pojedynczy załącznik, należy przejść do Księga główna > Konfiguracja księgi > Parametry księgi głównej, a następnie na zakładce Księga ustawić opcję Zezwalaj na wiele transakcji w ramach pojedynczego załącznika na Tak.
Transakcję pojedynczy załącznik można wprowadzić na stronie Nazwy dzienników, ustawiając pole Nowy załącznik na jedną z następujących wartości:
- Tylko jeden numer załącznika– każdy wiersz dodany do dziennika, zostanie uwzględniony w tym samym załączniku, a wiersze będą zawierały więcej niż jednego klienta, dostawcę, bank, środek trwały lub projekt.
- W powiązaniu z saldem – umożliwia wprowadzenie załącznika wielowierszowego, w którym nie ma konta przeciwstawnego, a wiersze zawierają więcej niż jednego klienta, dostawcę, bank, środek trwały lub projekt.
- W połączeniu z saldem – umożliwia wprowadzenie załącznika, jeżeli zarówno konto, jak i konto przeciwstawne zawierają typ konta księgi podrzędnej, takie jak Dostawca/Dostawca, Odbiorca/Odbiorca, Dostawca/Odbiorca lub Bank/Bank.
Czy mój scenariusz biznesowy wymaga pojedynczego załącznika?
Zidentyfikowano następujące scenariusze biznesowe, do których klienci wykorzystują funkcjonalność pojedynczego załącznika. Niektóre z podanych wymagań biznesowych można zaspokoić tylko za pomocą funkcjonalności pojedynczego załącznika. Jednak dla wielu innych osób dostępne są alternatywne rozwiązania.
| Scenariusz | Opis | Wymagany pojedynczy załącznik? | Alternatywny |
|---|---|---|---|
| Podsumowanie płatności od dostawców | Organizacja przekazuje do swojego banku listę sprzedawców i kwot. Bank wykorzystuje tę listę do płacenia sprzedawcom w imieniu organizacji. Każda płatność sprzedawcy musi być szczegółowo zaksięgowana na koncie Zobowiązania, ale suma płatności jest księgowana na rachunku bankowym jako pojedyncza wypłata. | Nr | W wersji 10.0.32 Microsoft Dynamics 365 Finance pojawiła się funkcja o nazwie Możliwość zaksięgowania szczegółowych płatności dla dostawców i odbiorców i podsumowanie kwot na koncie bankowym. Aby uzyskać więcej informacji, zobacz Księguj szczegółowe płatności dostawców i klientów. |
| Podsumowanie płatności klienta | Wpłaty klientów są wpłacane w formie ryczałtu na rachunek bankowy. Każda wpłata klienta musi być zaksięgowana szczegółowo na koncie Należności, ale suma wpłat jest księgowana na koncie bankowym jako jedna wpłata. | VAT | W wersji 10.0.32 Dynamics 365 Finance pojawiła się funkcja o nazwie Możliwość zaksięgowania szczegółowych płatności dla dostawców i klientów, ale podsumowanie kwot na rachunek bankowy. Aby uzyskać więcej informacji, zobacz Księguj szczegółowe płatności dostawców i klientów. |
| Faktura sprzedawcy/klienta | Faktura jest wprowadzana dla jednego klienta lub sprzedawcy, ale dodatkowe linie reprezentują wiersze faktury i mają wiele środków trwałych lub projektów. | Tak | |
| Arkusz zaliczek od odbiorców zawierający podatki w wielu „wierszach” | Klient dokonuje przedpłaty na poczet zamówienia. Wiersze zamówienia mają różne podatki. Płatność klienta przedpłatowego musi zawierać klienta w wielu wierszach, aby można było obliczyć podatki dla każdego wiersza. | Tak | |
| Zwrot nadpłaty do odbiorcy | Jeśli zadanie okresowe Zwrot nadpłaty zostanie uruchomione z poziomu modułu Rozrachunki z odbiorcami, utworzy transakcję przeniesienia salda od odbiorcy do dostawcy. Sprzedawca jest tym samym podmiotem co klient. | Tak | |
| Obsługa środków trwałych: amortyzacja wyrównująca, rozbicie środka trwałego, obliczania amortyzacji przy likwidacji | Amortyzacja nadwyżkowa, podział środka trwałego oraz naliczanie amortyzacji przy zbyciu środka trwałego - wszystko to służy do stworzenia pojedynczego załącznika. | VAT | Od wersji aplikacji finansowej 10.0.21 transakcje dotyczące środków trwałych, które są tworzone dla amortyzacji nadrabianej, podziału środka trwałego oraz naliczania amortyzacji przy zbyciu środka trwałego, wykorzystują inne numery załączników. |
| Weksle i skrypty dłużne | Weksle i skrypty dłużne powodują przeniesienie salda odbiorcy lub dostawcy z jednego konta księgowego w module Rozrachunki z odbiorcami/Rozrachunki z dostawcami do innego konta na podstawie stanu płatności. Ponieważ w załączniku zawsze używany jest ten sam klient lub sprzedawca, nie występują problemy z raportowaniem. | Tak | |
| Kompensacja | Jeśli klient i sprzedawca są tą samą stroną, salda sprzedawcy i klienta są ze sobą kompensowane. To podejście minimalizuje wymianę pieniędzy między organizacją a stroną będącą odbiorcą/dostawcą. | Nr | Od wersji Microsoft Dynamics 365 Finance 10.0.40 dostępna jest funkcja Kompensacja odbiorcy i dostawcy. Funkcja kompensowania automatycznie tworzy dwa oddzielne załączniki dla dostawcy i odbiorcy. Aby uzyskać więcej informacji, zobacz Kompensacja salda odbiorcy i dostawcy. |
| Przeniesienie sald | Organizacja może potrzebować przenieść saldo od jednego dostawcy do innego dostawcy, na przykład z powodu błędu lub przejęcia odpowiedzialności przez drugiego dostawcę. Tego typu przeniesienia odbywają się również dla typów kont takich jak Odbiorca i Bank. | Tak/nie | Przeniesienia sald z jednego konta (dostawcy, odbiorcy, bankowego itd.) na inne konto mogą się odbywać za pomocą osobnych załączników, a kompensacja może być księgowana na rozliczeniowym koncie księgowym. Dla niektórych organizacji takie podejście wymaga zbyt dużego nakładu finansowego. Dlatego zamiast tego decydują się na wykorzystanie pojedynczego załącznika. |
| Rozliczanie wielu niezaksięgowanych płatności względem jednej faktury | Ten scenariusz zwykle występuje w organizacjach, gdzie odbiorcy stosują wiele metod płatności za zakupy. W tym scenariuszu organizacja musi mieć możliwość rejestrowania wielu niezaksięgowanych płatności i rozliczania ich względem faktury dla odbiorcy. | VAT | Nowa funkcja, którą dodano w aplikacji finansowej, umożliwia rozliczanie wielu niezaksięgowanych płatności względem jednej faktury. |
| Funkcje specyficzne dla kraju/regionu | Funkcja Single Administrative Document (SAD) dla Polski wymaga obecnie grupowania transakcji, a do tego celu wykorzystywany jest numer załącznika. Mogą istnieć dodatkowe cechy charakterystyczne dla danego kraju/regionu, które wymagają funkcji pojedynczego załącznika. | Tak | |
| Mechanizm grupowanie transakcji ze zdarzenia biznesowego | Organizacja ma jedno zdarzenie biznesowe, które inicjuje wiele transakcji. Dział księgowości chce przeglądać zapisy księgowe razem dla łatwiejszego audytu. Podobny scenariusz to taki, w którym transakcje bankowe są rejestrowane w aplikacji finansowej poprzez plik otrzymany z banku. Organizacje często chcą grupować te transakcje przy użyciu numeru wyciągu bankowego znajdującego się w pliku. | VAT | Chociaż grupowanie transakcji razem jest ważnym scenariuszem, numer załącznika nigdy nie może być używany do tego celu. Załączniki zawsze reprezentują pojedyncze transakcje, nigdy grupę transakcji. Transakcje mogą być grupowane według innych pól, takich jak numer partii dziennika lub numer dokumentu. |
| Wprowadzanie sald początkowych | Organizacje często wprowadzają salda początkowe dla kont księgi pomocniczej (sprzedawcy, klienci, środki trwałe i tak dalej) jako pojedynczą transakcję na załączniku. | VAT | Salda początkowe dla każdego konta księgi podrzędnej muszą być wpisane jako osobne załączniki. Kompensatę można zaksięgować na konto księgi rozliczeniowej, które jest kompensowane z saldem początkowym dla księgi głównej. |
| Korygowanie zapisu księgowego zaksięgowanego dokumentu | Organizacja może być zmuszona do skorygowania konta księgowego należności lub zobowiązań dla zaksięgowanej faktury. Ponieważ faktura jest prawidłowa, nie powinna zostać cofnięta. | Tak/nie | Jeżeli trzeba dokonać korekty na koncie księgowym modułu Rozrachunki z odbiorcami lub z Rozrachunki z dostawcami, można to zrobić bezpośrednio na koncie księgowym. Takie podejście wymaga, aby korekta została przeprowadzona podczas „przestoju”, w którym konto księgowe pozwala tymczasowo na wprowadzanie ręczne. Jednym minusem tego podejścia jest to, że raporty uzgodnień sprzedawcy/klienta do księgi głównej pokażą różnicę wchodzącą i wychodzącą. Kwota netto wynosi 0 (zero). |
| Księgowanie sumaryczne w księdze głównej | Organizacje często chcą księgować w księdze głównej sumarycznie, aby zminimalizować ilość danych. Jednak zazwyczaj takie organizacje wciąż wymagają zachowania szczegółów transakcji. Jeśli księgowanie odbywa się sumarycznie za pomocą pojedynczego załącznika, szczegóły transakcji są nieznane i nie można ich zachować. | VAT | Ponieważ szczegóły transakcji są tracone, organizacjom nie wolno używać pojedynczego załącznika do księgowania w podsumowaniu, jeśli szczegóły są wymagane do raportowania. |
| System na to pozwala | Organizacje często korzystają z funkcjonalności pojedynczego załącznika dlatego, że po prostu system na to pozwala. Niestety, nie wiedzą o skutkach używania tego mechanizmu. | VAT | Sam fakt, że system umożliwia korzystanie z funkcjonalności nigdy nie jest ważnym powodem. Funkcjonalność powinna być używana tylko wtedy, gdy jest wymagana do spełnienia innego wymagania biznesowego. |
Przyszłość funkcjonalności pojedynczego załącznika
Ze względu na problemy, które mogą wystąpić w przypadku wykorzystania pojedynczego załącznika, badane są następujące opcje:
- Nowe funkcje będą nadal wprowadzane, jeśli pojawi się lepszy sposób na realizację scenariusza biznesowego. Na przykład funkcja, która została wprowadzona w wersji aplikacji finansowej 10.0.32 umożliwia wprowadzanie płatności jako oddzielnych załączników, ale rachunek bankowy jest nadal aktualizowany w podsumowaniu. W miarę dodawania funkcji, będą one dokumentowane dla każdego scenariusza biznesowego w kolumnie "Alternatywa" w poprzedniej tabeli.
- Niektóre transakcje mogą nadal być wprowadzane przez dziennik w jednym załączniku, ale mogą być śledzone dodatkowe dane, aby prawidłowo zidentyfikować szczegóły transakcji.
- Można zastosować kombinację nowych funkcji, ale transakcje dla scenariuszy biznesowych mogą być nadal wprowadzane do dziennika za pomocą pojedynczego załącznika.
W miarę wprowadzania nowych funkcji Twoja organizacja musi stale oceniać, czy można wyłączyć opcję Zezwalaj na wiele transakcji w ramach pojedynczego załącznika na stronie Parametr księgi głównej. Zalecamy zaprzestanie korzystania z pojedynczego załącznika na integracje, chyba że potrzebujesz funkcjonalności dla jednej z udokumentowanych luk funkcjonalnych.
W miarę wypełniania luk funkcjonalnych firma Microsoft będzie informować o nowych funkcjach, które mają być używane zamiast pojedynczego załącznika. W przypadku niektórych scenariuszy biznesowych, takich jak faktura od dostawcy z wieloma wierszami, pojedynczy załącznik będzie nadal używany, ale z ulepszeniami. Informacje o tych ulepszeniach będą komunikowane w miarę ich dostarczania.