Informazioni sulle differenze quando si riconcilia la contabilità generale con Gestione contabilità fornitori o con Gestione crediti

Questo articolo illustra il motivo per cui il saldo del conto contabilità fornitori o il saldo del conto Contabilità clienti in Contabilità generale differisce dall'importo totale dovuto nel report Saldo di valutazione cronologico obsoleto in Microsoft Dynamics GP. Ci sono domande frequenti alla fine di questo articolo.

Si applica a: Microsoft Dynamics GP
Numero KB originale: 866570

La routine Riconcilia in GL era una novità di Microsoft Dynamics GP 10.0 (SP2). Questa routine genera un foglio di calcolo di Microsoft Office Excel. È possibile utilizzare questo foglio di calcolo per trovare la corrispondenza con le transazioni in Gestione contabilità fornitori o Gestione crediti registrate in Contabilità generale. Questo processo non genera transazioni di correzione. Tuttavia, questo processo può aiutare a determinare le differenze di transazione elencate in questa sezione. Per aprire la finestra Riconcilia in glg , scegliere Strumenti dal menu Microsoft Dynamics GP , scegliere Routine, Financial e quindi Fare clic su Riconcilia in GL.

Di seguito è riportato un elenco in esecuzione dei problemi riscontrati che possono causare differenze:

• Non tutti i batch gl vengono registrati. Il foglio di calcolo Riconcilia in GL segnala solo i movimenti registrati.

• Il report Bilancio di valutazione cronologico obsoleto viene stampato con restrizioni. Stampare di nuovo il report Bilancio di valutazione cronologico obsoleto con solo una restrizione di data.

• Non tutti i conti fornitori o tutti i conti clienti vengono visualizzati nella contabilità generale. Assicurarsi di visualizzare tutti i conti contabilità fornitori o tutti i conti contabilità clienti in Contabilità generale.

• I batch in Gestione contabilità fornitori o in Gestione crediti sono stati registrati in Contabilità generale. Il batch in Contabilità generale è stato modificato o modificato prima della registrazione.

• Le rettifiche al conto contabilità fornitori o al conto clienti possono essere state immesse direttamente nella contabilità generale. Queste transazioni aggiornano il conto nella contabilità generale. Tuttavia, queste transazioni non aggiornano il report Bilancio di valutazione cronologico obsoleto.

• L'intervallo di date nel report dettagliato del saldo di valutazione nella contabilità generale non corrisponde all'intervallo di date nel report Saldo di valutazione cronologico obsoleto in Gestione pagamenti o in Gestione crediti. Quando si stampa il report Saldo di valutazione cronologico obsoleto, selezionare la casella di controllo Data registrazione GL nell'area Seleziona transazioni per report utilizzando .

• Le transazioni sono state registrate in Gestione pagamenti o in Gestione crediti. Tuttavia, queste transazioni non sono state registrate nella contabilità generale se erano per i saldi iniziali. Se la casella di controllo Registra in contabilità generale non è selezionata nella finestra Setup registrazione per la serie Acquisti o per la serie Sales, le transazioni verranno registrate in Gestione contabilità fornitori o in Gestione contabilità clienti. Tuttavia, queste transazioni non verranno registrate nella contabilità generale.

• La casella di controllo Track Discounts Available in GL (Tenere traccia degli sconti disponibili in GL ) è selezionata nella finestra Setup gestione contabilità fornitori o nella finestra Setup gestione crediti. L'importo netto della fattura verrà quindi registrato nella contabilità generale. Inoltre, l'importo rimanente viene registrato in un account disponibile per gli sconti. Solo l'importo netto verrà visualizzato nel report Bilancio di valutazione dettagliato in Contabilità generale. Tuttavia, la fattura visualizza il totale della fattura lorda nel saldo di valutazione cronologico obsoleto in Gestione pagamenti o in Gestione crediti.

• I documenti sono stati annullati in un periodo diverso da quello originariamente pubblicato. Il report del saldo di valutazione dettagliato nella contabilità generale potrebbe non corrispondere al report Bilancio di valutazione cronologico obsoleto. Si supponga, ad esempio, che sia stata immessa una fattura il 1/1/2007. La fattura è stata annullata il 1/2/2007. Viene stampato un report sul saldo di valutazione dettagliato della contabilità generale per il 2/1/2007 - 28/2/2007. La transazione annullata verrà visualizzata nel report. Se un saldo di valutazione cronologico obsoleto viene stampato usando lo stesso intervallo di date, il documento annullato non verrà stampato nel report perché è stato annullato.

• Se si desidera bilanciare il saldo del conto contabilità fornitori o il saldo del conto crediti in Contabilità generale con il report Bilancio di valutazione cronologico obsoleto per un determinato periodo, i saldi del report Bilancio di valutazione cronologico obsoleto devono essere riconciliati con la modifica netta del saldo di valutazione dettagliato nella contabilità generale per lo stesso periodo.

• Se si desidera bilanciare il saldo del conto contabilità fornitori o il saldo del conto crediti in Contabilità generale con il report Bilancio di valutazione cronologico obsoleto per un giorno non compreso in un determinato periodo, determinare se gestione contabilità fornitori o Gestione crediti è mai stato bilanciato. Se la gestione dei debiti o la gestione crediti non è mai stata bilanciata, i saldi iniziali potrebbero non essere corretti. In questa situazione, bilanciare prima il periodo più corrente e quindi riconciliare i mesi precedenti in ordine inverso.

• Se si sono verificate interruzioni della registrazione, è possibile che i batch non siano stati registrati correttamente in Contabilità generale, in Gestione contabilità fornitori o in Gestione crediti.

• Quando si stampa il report Bilancio di valutazione cronologico obsoleto, non sono state selezionate le caselle di controllo seguenti nell'area Escludi.

• Selezionare queste caselle di controllo e quindi stampare il report Bilancio di valutazione cronologico obsoleto.

  Nota

  Se si desidera trovare la corrispondenza tra il report bilancio di valutazione dettagliato della contabilità generale e il report saldo di valutazione cronologico obsoleto in base a documenti specifici, deselezionare la casella di controllo Documenti completamente a pagamento .

  • Documenti di credito applicati non archiviati
  • Saldo zero
  • Attività

• Se si usa Gestione multicurrency quando si rivaluta, è stato selezionato per la pubblicazione nell'account di offset acquisti/vendite.

• Importi della carta di credito immessi nella finestra Contabilità fornitori per una fattura. Ciò può causare uno squilibrio nella riconciliazione per Gestione contabilità fornitori in Contabilità generale, perché solo la modifica netta verrà contabilita nel modulo Contabilità generale. Ovvero, sembra che le transazioni GL non siano presenti, ma gli importi sul lato GL vengono inseriti in una voce gl, mentre il lato PM può mostrare tre record. Ma devono comunque corrispondere nelle versioni successive e passare correttamente alla sezione Transazioni corrispondenti.

• Se sono state registrate interruzioni o problemi con un batch Debiti o Crediti e le transazioni sono state rilevate contemporaneamente nelle tabelle Lavoro e Apri, l'eliminazione del batch RM o PM in Microsoft Dynamics GP causerà problemi. In questa istanza, l'utente visualizza in genere i record in entrambe le tabelle e decide che non è necessario il batch di lavoro, quindi è sufficiente eliminarlo in Microsoft Dynamics GP. Poiché le tabelle Lavoro e Apri condividono una tabella di distribuzione, l'eliminazione del batch in Microsoft Dynamics GP rimuoverà anche i record di distribuzione. Il risultato finale è che il record di intestazione della transazione esiste, ma non sono presenti distribuzioni corrispondenti sul lato RM o PM, ma gl è stato aggiornato correttamente. Questo problema verrà considerato nella prossima versione di Microsoft Dynamics GP.

• Le distribuzioni possono essere visualizzate nella sezione Potenzialmente abbinate con importi diversi se sono presenti sconti. Per trovare la corrispondenza, è necessario eseguire il pull degli account gl di sconto con l'account PM/RM prima di eseguire il processo Riconcilia in gl. Chiudere il foglio di calcolo ed eseguirlo nuovamente con gli account gl di sconto elencati.

• Le distribuzioni potrebbero non essere presenti sul lato PM/RM se il tipo (CASH, PAY, PURCH) è stato modificato. Nel foglio di calcolo riconciliare l'account viene usato solo per il lato GL. L'account non viene usato sul lato PM/RM. Il lato PM/RM esegue il pull usando il tipo PAY o REC indipendentemente dall'account usato, pertanto è necessario assicurarsi di elencare tutti gli account AP o AR nella finestra di riconciliazione. Il semplice cambio del tipo di distribuzione nella tabella SQL non fa sì che la distribuzione venga visualizzata automaticamente se si rigenera il foglio di calcolo. Si tratta di un problema nelle versioni precedenti per i pagamenti con carta di credito che usano il tipo DI CASSA e raggiungono l'account AP, ma questi record vengono visualizzati in GP 2016, quindi non sembra più essere un problema.

• Controllare la data di applicazione e la data di registrazione gl nella tabella apply per le transazioni multivaluta rispetto alla data effettiva in cui è stata registrata in GL. Ad esempio, il 22 gennaio è stata applicata una nota di credito datata 31 dicembre a una fattura datata 5 dicembre e la data di applicazione e la data di pubblicazione gl sono state lasciate al 22 gennaio. Tuttavia, quando si registra il batch GL, l'utente ha modificato la data in 31 dicembre. In questo caso, il foglio di calcolo Riconcilia con gl per il mese di dicembre elenca l'importo di guadagno/perdita realizzato su entrambi i lati e sembrano essere riconciliati. Tuttavia, il report HATB non riconosce ancora l'importo di guadagno/perdita realizzato e verrà disattivato di questo importo rispetto a GL, poiché non è stato applicato o registrato fino a gennaio in base al record di applicazione.  

Domande frequenti

D1: Il foglio di calcolo Riconcilia con indirizzo generale è una vera riconciliazione tra debiti/crediti e indirizzo generale?

A1: La funzionalità riconcilia con gl è uno strumento di risoluzione dei problemi che consente agli utenti di identificare distribuzioni non corrispondenti tra RM/PM e GL. Non era necessariamente destinato a legarsi alla HATB e questo non era lo scopo previsto, anche se sappiamo che i clienti lo stanno facendo. I saldi nel foglio di calcolo Riconcilia in GL sono stime ottimali che usano una semplice addizione/sottrazione nelle distribuzioni nella tabella. Mentre i saldi della HATB prendono in considerazione quasi tutte le tabelle e sono saldi molto più complessi e accurati e quindi i due spesso non si legano.

La vera riconciliazione deve essere tra i report RM o PM Historical Aged Trial Balance (HATB) e GL Trial Balance. Se queste corrispondenze, non è necessario eseguire necessariamente lo strumento Riconcilia in gl per quel mese. Le tabelle GL sono costituite da addebiti e crediti e le tabelle da cui viene eseguito il pull di HATB sono l'intestazione della transazione e applicano le tabelle dei record. I clienti hanno quindi chiesto un modo per riconciliare le distribuzioni in GL con le tabelle di distribuzione in RM o PM per trovare le differenze a quel livello. Questo è il motivo per cui è stata creata la routine Reconcile to GL. È stato progettato per essere uno strumento di risoluzione dei problemi per confrontare le distribuzioni con le distribuzioni tra i moduli per identificare le distribuzioni mancanti, che potrebbero riportare a una transazione mancante da HATB. Usare quindi lo strumento Riconcilia in GL come aiuto solo per riconciliare haTB e GL Trial Balance. Se il bilanciamento di HATB e GL TB, non è necessario eseguire lo strumento Riconcilia in gl per quel mese.

D2: I totali nel foglio di calcolo Riconcilia con gl devono corrispondere ai totali della HATB?

A2: No. I totali nel foglio di calcolo Riconcilia in GL sono solo una semplice addizione/sottrazione dei record di distribuzione in tale tabella e non prendono in considerazione altre tabelle. Mentre haTB esamina tabelle completamente diverse per calcolare un saldo usando la transazione e applicare tabelle di record ed è un calcolo molto più complesso. A causa dei diversi metodi/tabelle di calcolo usati per ottenere i saldi, il foglio di calcolo Riconcilia con gl non dovrebbe essere completamente legato ai saldi obsoleti nei report HATB e rende difficile la riconciliazione. Non è necessario collegare i saldi nel foglio di calcolo riconciliati con gl al report HATB.

È consigliabile ignorare i totali nel foglio di calcolo riconciliato con GL e usare solo le sezioni Non corrispondenti e Potenzialmente corrispondenti per individuare le differenze nella ricerca per vedere se questo può spiegare anche una differenza tra la TB GL e HATB. Il foglio di calcolo Riconcilia con gl non è una vera riconciliazione ed è stato progettato solo per aiutare a identificare le differenze di distribuzione per la ricerca per vedere se si tratta anche di una differenza a livello di transazione. Infatti, se haTB corrisponde alla TB GL, in realtà non sarebbe necessario eseguire l'utilità riconcilia con gl per quel mese, dal momento che non ci sono differenze da identificare.

Se si desidera ancora legare il saldo nel foglio di calcolo riconciliato con gl gl al saldo sulla HATB, questo non è supportato in un caso di supporto regolare. I motivi identificati sono elencati nella parte superiore di questa knowledge base e potrebbero esserci altri motivi non ancora identificati. Tuttavia, poiché questa riconciliazione non è necessaria tra il semplice saldo totale elencato nel foglio di calcolo riconciliato con gl e il saldo calcolato più complesso sul report HATB e non lo scopo previsto di questa utilità di riconciliazione, sarebbe considerato una spesa di consulenza per scavare nei dati per facilitare la riconciliazione tra loro.

D3: Cosa devo fare se le distribuzioni sono mancanti sul lato GL?

A3: se si trovano distribuzioni sul lato RM o PM che non si trovano sul lato GL, esaminare il lato GL per individuare le differenze di temporizzazione. Verificare che tutti i batch gl vengano registrati. Se sono realmente mancanti sul lato GL, sarà necessario impostare una voce del journal di rettifica direttamente in GL per la voce per creare le distribuzioni gl.

D4: Cosa devo fare se le distribuzioni sono mancanti sul lato RM o PM?

A4: se la distribuzione gl è elencata, ma manca sul lato RM o PM, esaminare prima di tutto le differenze di intervallo. Cercare anche se la transazione stessa è elencata nel report HATB ed è già stata eseguita. È possibile che la transazione esista, ma le distribuzioni sono mancanti. Quindi la domanda diventa come si ottengono le distribuzioni in RM o PM, se la transazione esiste? In primo luogo, tenere presente che le tabelle di distribuzione in RM o PM non vengono usate per altri scopi o report in Criteri di gruppo, ad eccezione di questo foglio di calcolo riconciliato. Quindi è davvero necessario farli aggiungere di nuovo in RM o PM? Valutare se vale la pena popolare una tabella che non viene usata altrove.

Tuttavia, se si sceglie di correggere la tabella di distribuzione PM, è necessario annullare il documento, in modo che i record applicati vengano spostati di nuovo per aprirlo. Usare quindi l'utilità Rimuovi cronologia transazioni per rimuovere il documento annullato. Assicurarsi di impostare la registrazione in modo che venga eseguita la registrazione in GL e non eseguire la pubblicazione in GL. Eliminare il batch GL creato dal void. Reimpostare quindi il documento in Contabilità fornitori, in modo che le transazioni e le distribuzioni vengano ricreate. Assicurarsi di annullare il batch gl per questo. Riapplicare quindi il nuovo documento ai documenti aperti e passare nuovamente alla cronologia.

Per risolverlo nella tabella di distribuzione RM, è necessario rimuovere entrambi i lati della fattura e del pagamento e reimpostarli entrambi ed eliminare il batch in GL.

D5: le transazioni nella sezione Potenzialmente corrispondenti sembrano corrispondere. Perché non sono presenti nella sezione Corrispondente?

A5: esistono diversi campi corrispondenti per ogni record di distribuzione. Tutti i campi devono corrispondere per spostarlo nella sezione Corrispondente. Se alcuni campi, ma non tutti, corrispondono, verranno inseriti nella sezione Potenzialmente corrispondente. Ad esempio, di seguito sono riportati i campi corrispondenti tra PM e GL:

Gestione debiti -- GL
Numero giustificativo - Numero di controllo di origine
Origine TRX -- Origine TRX di origine
Data registrazione - Data transazione
On Account Amount -- Debit Amount or Credit Amount

D6: Se si chiaveranno le distribuzioni mancanti in GL o RM/PM e si eseguirà nuovamente il foglio di calcolo Riconcilia in GL, gli elementi non corrispondenti o potenzialmente corrispondenti verranno spostati nella sezione Corrispondente?

A6: No. Se le transazioni vengono chiavete separatamente, l'oggetto avrà numeri di voucher e codici di origine Trx diversi. Nella migliore delle ipotesi la data di registrazione e gli importi potrebbero corrispondere, che potrebbero essere inseriti nella sezione Potenzialmente corrispondente del foglio di calcolo.

D7: Perché il saldo finale in un foglio di calcolo mensile o trimestrale non corrisponde al saldo iniziale nel foglio di calcolo mensile o trimestrale successivo?

A7: se il saldo finale di un periodo non corrisponde al saldo iniziale del periodo successivo, è spesso dovuto a record di distribuzione orfani che non hanno un record di intestazione associato nella tabella del libro mastro secondario. Il saldo finale viene calcolato da Excel direttamente nel foglio di calcolo. Basta il saldo iniziale per quel periodo nella parte superiore del foglio di calcolo e aggiunge/sottrae i record di distribuzione visualizzati nel foglio di calcolo per arrivare al saldo finale. D'altra parte, nel periodo successivo, il saldo iniziale viene calcolato prendendo un semplice calcolo di debito/credito dei record di distribuzione nella tabella SQL e la stored procedure esegue il join della tabella di intestazione, quindi non includerà alcuna distribuzione che manca un record di intestazione. Il risultato finale potrebbe essere che alcune distribuzioni sono state calcolate nel saldo finale nel foglio di calcolo precedente e omesse dal saldo iniziale nel periodo successivo.

D8: le distribuzioni sul lato RM/PM esistono, ma non vengono inserite nel foglio di calcolo.

A8: Esaminare questi suggerimenti per la risoluzione dei problemi:

• Esaminare l'intervallo di date utilizzato nel foglio di calcolo Riconcilia con.
• Verificare che le distribuzioni esistano nelle tabelle PM10100 o PM30600 per PM. (o per RM: cercare il RM10101 o RM30301) Esaminare le date di queste distribuzioni per assicurarsi che rientrino nell'intervallo immesso per il foglio di calcolo. È importante individuarli nelle tabelle di distribuzione RM o PM e non basarsi esclusivamente sui giornali di registrazione di registrazione ristampe, ad esempio.
• Se si trovano le distribuzioni nelle tabelle RM o PM, esaminare queste distribuzioni nel documento nel front-end. Hanno un tipo di distribuzione pay o REC o AVAIL? Questi sono gli unici tipi che verranno inseriti nel foglio di calcolo di riconciliazione sul lato RM o PM nelle versioni precedenti. (Aggiornamento: i pagamenti con carta di credito possono produrre una distribuzione al conto AP con un tipo di CASH su di esso, in cui si trova nella tabella, ma il foglio di calcolo riconcilia con GL non ha visualizzato questa distribuzione sul lato sinistro. Quindi solo un problema di visualizzazione con il foglio di calcolo e non un problema di dati. Tuttavia, questo non sembra essere un problema in Microsoft Dynamics GP 2016, poiché il tipo CASH è ora visualizzato correttamente nel foglio di calcolo, quindi è stato risolto lungo la strada.)

D9: È possibile visualizzare la finestra Riconcilia in GL in altre valute?

A9: la finestra Riconcilia in GL progettata per visualizzare solo le valute funzionali . Per altre informazioni, vedere Informazioni sui saldi nella finestra Riconcilia in GL in Microsoft Dynamics GP.