Informatie over verschillen bij het afstemmen van grootboek op Crediteurenbeheer of Debiteurenbeheer

In dit artikel wordt besproken waarom het saldo van de crediteurenrekening of het saldo van de accountsaldo van de debiteurenrekening in grootboek verschilt van het totale bedrag dat moet worden betaald in het rapport Historisch verouderd proefsaldo in Microsoft Dynamics GP. Er zijn veelgestelde vragen aan het einde van dit artikel.

Van toepassing op: Microsoft Dynamics GP
Oorspronkelijk KB-nummer: 866570

De Reconcile to GL-routine was nieuw in Microsoft Dynamics GP 10.0 (SP2). Met deze routine wordt een Microsoft Office Excel-spreadsheet gegenereerd. U kunt dit spreadsheet gebruiken om transacties in Payables Management of Debiteurenbeheer te vinden die zijn geboekt in Grootboek. Met dit proces worden geen corrigerende transacties gegenereerd. Dit proces kan u echter helpen bij het bepalen van de transactieverschillen die in deze sectie worden vermeld. Als u het venster Afstemming naar GL wilt openen, wijst u naar Extra in het menu Microsoft Dynamics GP, wijst u naar Routines, wijst u naar Financieel en selecteert u Afstemmen op GL.

Hieronder ziet u een lijst met problemen die kunnen leiden tot verschillen:

• Niet alle GL-batches worden geplaatst. (Het spreadsheet Afstemmen op GL rapporteert alleen over geplaatste items.)

• Het rapport Historische ouderdomsproefbalans wordt met beperkingen afgedrukt. Druk het rapport Historisch verouderd proefbalans opnieuw af met slechts een datumbeperking.

• Niet alle crediteurenrekeningen of alle debiteurenrekeningen worden weergegeven in Grootboek. Zorg ervoor dat u alle crediteurenrekeningen of alle debiteurenrekeningen in Grootboek bekijkt.

• Batches in Crediteurenbeheer of in Debiteurenadministratie zijn geboekt naar het Grootboek. De batch in Grootboek is gewijzigd of bewerkt voordat deze werd geplaatst.

• Aanpassingen aan de crediteurenrekening of de debiteurenrekening kunnen rechtstreeks in het grootboek zijn ingevoerd. Met deze transacties wordt het account in grootboek bijgewerkt. Deze transacties werken echter niet het rapport Historische evaluatiebalans bij.

• Het datumbereik in het rapport Gedetailleerde evaluatiebalans in Grootboek komt niet overeen met het datumbereik in het rapport Historisch oud proefsaldo in Crediteurenbeheer of in Debiteurenbeheer. Wanneer u het rapport Historisch verouderd proefsaldo afdrukt, schakelt u het selectievakje GL-boekingsdatum in het gebied Transacties voor rapport selecteren in.

• Transacties werden geboekt in Payables Management of in Debiteurenbeheer. Deze transacties werden echter niet geboekt in grootboek als ze voor beginsaldo's waren. Als het selectievakje Posten naar grootboek niet is ingeschakeld in het venster Boekingsinstellingen voor de inkoopreeks of de verkoopreeks, worden de transacties geboekt naar Crediteurenbeheer of Debiteurenbeheer. Deze transacties worden echter niet geboekt in Grootboek.

• Het selectievakje Kortingen bijhouden die beschikbaar zijn in GL is ingeschakeld in het venster Instelling van Crediteurenbeheer of in het venster Instelling van Debiteurenbeheer. Vervolgens wordt het nettobedrag van de factuur geboekt op Grootboek. Daarnaast wordt het resterende bedrag geboekt op een beschikbare kortingsrekening. Alleen het nettobedrag wordt weergegeven in het Gedetailleerde Proefbalans rapport binnen het Grootboek. Echter, op de factuur wordt het brutofactuurtotaal weergegeven op de historische ouderdomsproefbalans in Crediteurenbeheer of in Debiteurenbeheer.

• Documenten zijn in een andere periode dan oorspronkelijk geplaatst. Het rapport Gedetailleerde proefbalans in grootboek komt mogelijk niet overeen met het rapport Historische ouderdomsproefbalans. Stel dat er een factuur is ingevoerd op 1-1-2007. Deze factuur is op 2-1-2007 ongeldig. Een Algemeen Grootboek gedetailleerde proefbalansrapport wordt afgedrukt voor 1/2/2007 - 28/2/2007. De ongeldige transactie wordt weergegeven in het rapport. Als een historisch verouderd proefsaldo wordt afgedrukt met hetzelfde datumbereik, wordt het ongeldige document niet afgedrukt in het rapport omdat het ongeldig is.

• Als u het saldo van de crediteurenrekening of het saldo van de debiteurenrekening in grootboek wilt verdelen naar het rapport Historisch oud proefsaldo voor een bepaalde periode, moeten de saldo's uit het rapport Historisch oud proefsaldo worden afgestemd op de nettowijziging op het gedetailleerde proefboek in Grootboek voor dezelfde periode.

• Als u het saldo van de crediteurenrekening of het saldo van de debiteurenrekening in het grootboek wilt afstemmen met het rapport Historisch oud proefsaldo voor een dag die zich buiten een bepaalde periode bevindt, bepaalt u of Crediteurenbeheer of Debiteurenbeheer ooit in balans is geweest. Als Crediteurenbeheer of Debiteurenbeheer nooit evenwichtig is geweest, zijn de beginsaldo's mogelijk onjuist. In deze situatie moet u eerst de meest recente periode in balans brengen en vervolgens de vorige maanden in omgekeerde volgorde afstemmen.

• Als er onderbrekingen tijdens het boeken zijn opgetreden, zijn batches mogelijk niet correct geboekt in Grootboek, Crediteurenbeheer of Debiteurenbeheer.

• Wanneer u het rapport Historische ouderdomsproefbalans afdrukt, hebt u de volgende selectievakjes niet geselecteerd in het gebied Uitsluiten.

• Schakel deze selectievakjes in en druk daarna het rapport 'Historische Ouderwetse Proefbalans' af.

  Notitie

  Schakel het selectievakje Volledig betaalde documenten uit als u het rapport Algemeen grootboek gedetailleerd proefsaldo en het rapport Historisch oud proefsaldo per specifieke documenten wilt vergelijken.

  • Niet geboekte toegepaste kredietdocumenten
  • Nul-saldo
  • Activiteit

• Als u Multicurrency Management gebruikt wanneer u de waarde wijzigt, hebt u geselecteerd om te posten op het offsetaccount Voor aankopen/verkopen.

• Creditcardbedragen die ingevoerd zijn in het venster Crediteuren Transactie-invoer voor een factuur. Dit kan leiden tot een onbalans bij de afstemming voor Crediteurenbeheer naar Grootboek, omdat alleen de nettoverandering wordt geboekt in de module Grootboek. (Dat wil gezegd, het lijkt alsof GL-transacties ontbreken, maar de bedragen aan de GL-zijde worden in één GL-vermelding samengevoegd, terwijl de PM-zijde mogelijk drie records weergeeft. Maar ze moeten nog steeds overeenkomen in latere versies en naar de sectie Overeenkomende transacties correct worden verplaatst.)

• Als er onderbrekingen/problemen waren met een batch Crediteuren of Debiteuren en de transacties zijn gevonden in zowel de Werk- als Open-tabellen, zal het verwijderen van de RM- of PM-batch in Microsoft Dynamics GP problemen veroorzaken. In dit geval ziet de gebruiker meestal de records in beide tabellen en besluiten ze dat ze de werkbatch niet nodig hebben, dus verwijderen ze deze gewoon in Microsoft Dynamics GP. Omdat de tabellen Werk en Open een distributietabel delen, leidt het verwijderen van de batch in Microsoft Dynamics GP ertoe dat de distributierecords ook verwijderd worden. Het eindresultaat is dat de transactieheaderrecord bestaat, maar er zijn geen overeenkomende distributies aan de RM- of PM-zijde, maar GL is correct bijgewerkt. Dit probleem wordt overwogen in de volgende versie van Microsoft Dynamics GP.

• Distributies kunnen worden weergegeven in de sectie Mogelijk overeenkomende items met verschillende bedragen als er kortingen zijn. Om alles correct af te stemmen, hadden de GL-kortingsrekeningen samen met het PM/RM-account moeten worden opgehaald voordat het proces "Afstemmen met GL" werd uitgevoerd. Sluit het spreadsheet en voer het opnieuw uit met de vermelde kortings-GL-accounts.

• Distributies kunnen ontbreken aan de kant van PM/RM als het type (CASH, PAY, PURCH) is gewijzigd. In het spreadsheet voor afstemming wordt het account alleen gebruikt voor de GL-zijde. Het account wordt niet gebruikt aan de PM/RM-zijde. De PM/RM-zijde gebruikt het type BETALEN of REC, ongeacht welk account wordt gebruikt, daarom moet u ervoor zorgen dat u al uw AP- of AR-accounts in het afstemmingsvenster vermeldt. Als u het distributietype in de SQL-tabel wijzigt, wordt de distributie niet automatisch weergegeven als u het werkblad opnieuw genereert. (Dit was een probleem in eerdere versies voor creditcardbetalingen met behulp van contanttype en het AP-account, maar deze records worden weergegeven in GP 2016 en lijkt dus geen probleem meer te zijn.)

• Controleer de toepassingsdatum en de GL-postdatum in de toepassingstabel voor transacties met meerdere valuta, in vergelijking met de werkelijke datum waarop deze in de GL is geboekt. Op 22 januari werd bijvoorbeeld een creditnota van 31 december toegepast op een factuur van 5 december, waarbij de toepassingsdatum en GL-postdatum op 22 januari bleven staan. Bij het posten van de GL-batch heeft de gebruiker de datum echter gewijzigd in 31 december. In dit geval vermeldt het spreadsheet 'Afstemmen naar GL' voor de maand december het gerealiseerde winst-/verliesbedrag aan beide zijden en lijken ze afgestemd te zijn. Het HATB-rapport herkent echter nog niet het gerealiseerde winst-/verliesbedrag en zal afwijken door dit bedrag in vergelijking met GL, aangezien het niet werd toegepast of geboekt tot januari volgens het toepassingsverslag.  

Veelgestelde vragen

V1: Is het spreadsheet Afstemmen naar GL een echte afstemming voor Crediteuren/Vorderingen naar GL?

A1: De functie Voor het afstemmen van GL is een hulpprogramma voor probleemoplossing waarmee gebruikers niet-overeenkomende distributies tussen RM/PM en GL kunnen identificeren. Het was niet per se bedoeld om aan te sluiten bij de HATB en dat was niet het bedoelde doel, hoewel we weten dat klanten het wel doen. De balansen op het spreadsheet Afstemmen op GL zijn de beste schattingen met behulp van een eenvoudige optellen/aftrekken van de distributies in de tabel. Hoewel de balansen op de HATB bijna elke tabel in overweging nemen en veel complexer en nauwkeuriger zijn, sluiten de twee balansen daardoor vaak niet aan.

De werkelijke afstemming zou moeten plaatsvinden tussen de RM- of PM Historical Aged Trial Balance (HATB) en de GL-proefbalansrapporten. Als deze overeenkomen, hoeft u niet noodzakelijk het Afstemming naar GL-tool voor die maand uit te voeren. De GL-tabellen bestaan uit debits en tegoeden en de tabellen waaruit de HATB haalt, zijn transactieheader en passen recordtabellen toe. Klanten vroegen dus om een manier om de distributies in GL af te stemmen op de distributietabellen in RM of PM om verschillen op dat niveau te vinden. Dit is dus de reden waarom de afstemming naar GL-routine is gemaakt. Het was bedoeld als een hulpprogramma voor probleemoplossing om distributies tussen verschillende modules met elkaar te vergelijken. Dit kan helpen bij het identificeren van ontbrekende distributies, wat je mogelijk kan terugleiden naar een ontbrekende transactie van de HATB. Gebruik de Reconcile to GL tool dus alleen als hulpmiddel om u te helpen bij het afstemmen van de HATB met de GL Trial Balance. Als de HATB- en GL TB-saldo in balans zijn, dan is het niet echt nodig om de Reconcile to GL-tool voor die maand uit te voeren.

V2: Moeten de totalen op het 'Afstemmen met GL'-spreadsheet overeenkomen met de totalen op de HATB?

A2: Nee. De totalen in het spreadsheet Afstemmen op GL zijn slechts een eenvoudige optellen/aftrekken van de distributierecords in die tabel en houden geen rekening met andere tabellen. Terwijl de HATB naar geheel verschillende tabellen kijkt om een saldo te berekenen met behulp van de transactie en recordstabellen toepast en een veel complexere berekening is. Vanwege de verschillende berekeningsmethoden en tabellen die worden gebruikt om de saldi te verkrijgen, wordt niet verwacht dat de Reconcile to GL-spreadsheet direct overeenkomt met de ouderdomssaldi in de HATB-rapporten, wat het afstemmen ervan bemoeilijkt. Het is niet nodig om de balansen voor de reconciliatie aan het GL-spreadsheet aan het HATB-rapport te koppelen.

We raden u aan de totalen voor het afstemmen van de GL-spreadsheet te negeren en alleen de secties Niet-overeenkomend en Potentieel Overeenkomend te gebruiken om verschillen te vinden voor onderzoek en te kijken of dat ook een verschil kan verklaren van een verschil tussen de GL TB en HATB. De afstemming met GL-spreadsheet is geen echte afstemming en was alleen bedoeld als hulpmiddel om u te helpen bij het identificeren van distributieverschillen om te zien of dit ook een verschil is op transactieniveau. Eigenlijk, als de HATB overeenkomt met de GL TB, zou het echt niet nodig zijn om het GL-afstemmingshulpprogramma voor die maand uit te voeren, aangezien er geen verschillen zijn om te identificeren.

Als u het saldo op de afstemming met GL-spreadsheet nog steeds wilt koppelen aan het saldo op de HATB, wordt dit niet ondersteund in een reguliere ondersteuningsaanvraag. De redenen die we hebben geïdentificeerd, worden bovenaan deze KB vermeld en er kunnen nog meer redenen zijn die nog niet zijn geïdentificeerd. Maar omdat deze afstemming niet nodig is tussen het eenvoudige totale saldo dat wordt vermeld op de afstemming met GL-spreadsheet en het complexere berekende saldo in het HATB-rapport, en niet het beoogde doel van dit hulpprogramma voor afstemming, zou het als advieskosten worden beschouwd om in uw gegevens te graven om u te helpen deze met elkaar te afstemmen.

V3: Wat moet ik doen als distributies ontbreken aan de GL-zijde?

A3: Als u distributies vindt aan de RM- of PM-zijde die zich niet aan de GL-zijde bevinden, onderzoekt u de GL-zijde op tijdsverschillen. Controleer of alle GL-batches zijn geplaatst. Als ze echt ontbreken aan de GL-zijde, moet u een aanpassend logboekitem rechtstreeks in GL versleutelen om de GL-distributies te maken.

V4: Wat moet ik doen als distributies ontbreken aan de RM- of PM-zijde?

A4: Als de GL-verdeling wordt vermeld, maar ontbreekt aan de RM- of PM-zijde, onderzoekt u eerst naar tijdsverschillen. Onderzoek ook of de transactie zelf wordt vermeld in het HATB-rapport en waarvoor al rekening is gehouden. Het is mogelijk dat de transactie bestaat, maar de distributies ontbreken gewoon. De vraag wordt dus hoe ik de distributies in RM of PM krijg als de transactie bestaat? Onthoud dat de distributietabellen in RM of PM niet worden gebruikt voor andere doeleinden of rapporten in GP, behalve voor dit afstemmingsspreadsheet. Dus is het echt nodig om ze weer toe te voegen aan RM of PM? Evalueer of het de moeite waard is om een tabel te vullen die nergens anders wordt gebruikt.

Maar als u ervoor kiest om de PM-distributietabel op te lossen, moet u het document ongeldig maken, zodat de toegepaste records teruggaan naar open. Gebruik vervolgens het hulpprogramma Transactiegeschiedenis verwijderen om het ongeldige document te verwijderen. Zorg ervoor dat u de boeking instelt op post naar GL en niet doorbrengt naar GL. Verwijder de GL-batch die door de void is gemaakt. Voer het document vervolgens opnieuw in de Crediteurenadministratie in, om de transacties en distributies te herstellen. Zorg ervoor dat u de GL-batch hiervoor ongeldig maakt. Pas het nieuwe document vervolgens opnieuw toe op de geopende documenten en ze moeten opnieuw naar de geschiedenis gaan.

Als u dit probleem wilt oplossen in de RM-distributietabel, moet u beide zijden van de factuur en betaling verwijderen en opnieuw versleutelen, en de batch in GL verwijderen.

V5: De transacties in de sectie Potentieel overeenkomend zien eruit alsof ze overeenkomen. Waarom worden ze niet in de sectie Overeenkomend weergegeven?

A5: Er zijn verschillende velden die overeenkomen met elke distributierecord. Alle velden moeten overeenkomen om deze naar de overeenkomende sectie te verplaatsen. Als sommige, maar niet alle velden overeenkomen, wordt deze in de sectie Mogelijk overeenkomend geplaatst. Hier ziet u bijvoorbeeld de velden die overeenkomen met PM naar GL:

Crediteurenbeheer -- GL
Vouchernummer -- Oorspronkelijk controlenummer
TRX-bron -- Oorspronkelijke TRX-bron
Boekingsdatum -- Transactiedatum
Op rekeningbedrag -- Debetbedrag of Creditbedrag

V6: Als ik de ontbrekende distributies in GL of RM/PM versleutel en de spreadsheet Afstemmen op GL opnieuw uitvoert, worden de niet-overeenkomende of mogelijk overeenkomende items verplaatst naar de sectie Overeenkomende items?

A6: Nee. Als de transacties afzonderlijk worden gesleuteld, hebben de verschillende vouchernummers en Trx-broncodes. In het beste geval kunnen de boekingsdatum en bedragen overeenkomen, waardoor ze in de sectie Mogelijk overeenkomende van de spreadsheet kunnen worden geplaatst.

V7: Waarom komt het eindsaldo op een maandelijks of kwartaal spreadsheet niet overeen met het beginsaldo op de volgende maandelijkse of driemaandelijkse spreadsheet?

A7: Als het eindsaldo van een periode niet overeenkomt met het beginsaldo van de volgende periode, wordt dit vaak veroorzaakt door verweesde distributierecords die geen gekoppelde koprecord hebben in de subboek-tabel. Het eindsaldo wordt rechtstreeks in het werkblad berekend door Excel. Het neemt alleen het beginsaldo voor die periode bovenaan het werkblad en voegt de distributierecords die op het werkblad worden weergegeven toe of trekt ze af om het eindsaldo te berekenen. Aan de andere kant wordt in de volgende periode het beginsaldo berekend door een eenvoudige debet-/tegoedberekening van de distributierecords in de SQL-tabel te maken en de opgeslagen procedure voegt de kopteksttabel toe, zodat er geen distributies worden opgenomen die een headerrecord missen. Het eindresultaat kan zijn dat sommige distributies zijn berekend in het eindsaldo op het vorige werkblad en dat dit wordt weggelaten uit het beginsaldo voor de volgende periode.

V8: De distributies aan de RM/PM-zijde bestaan wel, maar worden niet in de spreadsheet opgenomen.

A8: Bekijk deze tips voor probleemoplossing:

• Bekijk het datumbereik dat wordt gebruikt op de spreadsheet 'Afstemmen'.
• Controleer of de distributies bestaan in de PM10100- of PM30600 tabellen voor PM. (of voor RM: zoeken in de RM10101 of RM30301) Bekijk de datums op deze distributies om ervoor te zorgen dat ze binnen het bereik vallen dat u hebt ingevoerd voor het spreadsheet. Het is belangrijk om deze te vinden in de RM- of PM-distributietabellen en niet alleen te vertrouwen op opnieuw afgedrukte postlogboeken.
• Als u de distributies in de RM- of PM-tabellen vindt, bekijkt u deze distributies in het document in de front-end. Hebben ze een distributietype UITBETALING, ONTVANGST of BESCHIKBAAR? Dit zijn de enige typen die in oudere versies worden opgehaald in het afstemmingsspreadsheet aan de RM- of PM-zijde. (Update: Creditcard betalingen kunnen een distributie naar de AP-account produceren met het type CASH, waarbij dit type in de tabel voorkomt, maar de afstemming met de GL-spreadsheet heeft deze distributie niet aan de linkerkant weergegeven. Dus alleen een weergaveprobleem met het werkblad en geen gegevensprobleem. Dit is echter geen probleem in Microsoft Dynamics GP 2016, aangezien het cash-type nu correct in het werkblad wordt weergegeven, dus is dit opgelost.)

V9: Kunt u het venster Afstemmen op GL weergeven in andere valuta's?

A9: Het venster Afstemmen op GL, zoals ontworpen om alleen functionele valuta's weer te geven. Zie Informatie over de saldi in het venster Afstemming met GL in Microsoft Dynamics GP voor meer informatie.