Aracılığıyla paylaş


Genel Muhasebe'yi Borç Yönetimi veya Alacak Yönetimi ile uzlaştırdığınızda ortaya çıkan farklılıklar hakkında bilgi

Bu makalede, Genel Muhasebe'deki Borç Hesapları hesap bakiyesinin veya Alacak Hesapları hesap bakiyesinin, Microsoft Dynamics GP'deki Geçmiş Eski Deneme Bakiyesi raporunda vadesi geçmiş toplam tutardan neden farklı olduğu açıklanır. Bu makalenin sonunda sık sorulan sorular vardır.

Şunlar için geçerlidir: Microsoft Dynamics GP
Özgün KB numarası: 866570

GL ile Uzlaştırma yordamı Microsoft Dynamics GP 10.0 (SP2) için yeniydi. Bu yordam bir Microsoft Office Excel elektronik tablosu oluşturur. Bu elektronik tabloyu, Genel Muhasebe'ye deftere nakledilmiş Borçlar Yönetimi veya Alacaklar Yönetimi'ndeki işlemleri eşleştirmek için kullanabilirsiniz. Bu işlem düzeltme işlemleri oluşturmaz. Ancak bu işlem, bu bölümde listelenen işlem farklarını belirlemenize yardımcı olabilir. GL ile Mutabık Kıl penceresini açmak için, Microsoft Dynamics GP menüsünde Araçlar'ın üzerine gelin, Rutinler'in üzerine gelin, Finansal'ın üzerine gelin ve ardından GL ile Mutabık Kıl'ı seçin.

Aşağıda, farklılıklara neden olabilecek sorunların güncellenen bir listesi yer almaktadır.

  • Tüm GL toplu işlemleri deftere nakledilmemiş. (GL'ye Mutabakat Elektronik Tablosu yalnızca kaydedilmiş girişleri rapor eder.)

  • Geçmiş Eski Deneme Bakiyesi raporu kısıtlamalarla yazdırılır. Geçmiş Eski Deneme Bakiyesi raporunu yalnızca tarih kısıtlamasıyla yeniden yazdırın.

  • Tüm borç hesapları veya alacak hesapları Genel Muhasebe'de görüntülenmez. Genel Muhasebe'de tüm borç hesapları veya tüm alacak hesapları hesaplarını görüntülediğinizden emin olun.

  • Borç Yönetimi veya Alacak Yönetimi'ndeki Toplu İşlemler Genel Muhasebe'ye nakledildi. Genel Muhasebe'deki toplu iş deftere nakledilmeden önce değiştirildi veya düzenlendi.

  • Borç hesapları hesabında veya alacak hesapları hesabında yapılan ayarlamalar doğrudan Genel Muhasebe'ye girilmiş olabilir. Bu işlemler, Genel Muhasebe'deki hesabı güncelleştirir. Ancak bu işlemler Geçmiş Eski Deneme Bakiyesi raporunu güncelleştirmez.

  • Genel Muhasebe'deki Ayrıntılı Deneme Bakiyesi raporundaki tarih aralığı, Borç Yönetimi'ndeki veya Alacak Yönetimi'ndeki Geçmiş Eski Deneme Bakiyesi raporundaki tarih aralığıyla eşleşmiyor. Geçmiş Tarihli Yaşlandırılmış Deneme Bakiyesi raporunu yazdırdığınızda, Kullanılacak Rapor için Hareketleri Seçin alanında GL Deftere Nakil Tarihi onay kutusunu seçin.

  • İşlemler Borç Yönetimi'nde veya Alacak Yönetimi'nde deftere nakledildi. Ancak, bu hareketler başlangıç bakiyeleri içinse Genel Muhasebe'ye kaydedilmemiştir. Satınalma serisi veya Satış serisi için Genel Muhasebeye Deftere Naklet onay kutusu Deftere Nakil Kurulumu penceresinde seçili değilse, hareketler Borçlar Yönetimi'ne veya Alacaklar Yönetimi'ne nakledilir. Ancak bu işlemler Genel Muhasebe'ye nakledilmez.

  • GL'de Kullanılabilir İndirimleri İzle onay kutusu, Borçlar Yönetimi Kurulumu penceresinde veya Alacak Yönetimi Kurulumu penceresinde seçilidir. Ardından, faturanın net tutarı Genel Muhasebe'ye nakledilir. Ayrıca, kalan tutar kullanılabilir bir indirim hesabına nakledilir. Genel Muhasebe'deki Ayrıntılı Deneme Bakiyesi raporunda yalnızca net tutar görünür. Ancak, fatura, Borç Yönetimi veya Alacak Yönetimi'nde Geçmiş Tarihli Alacaklı Deneme Bakiyesi'nde brüt fatura toplamını gösterir.

  • Belgeler, başlangıçta kaydedildikleri dönemden farklı bir zamanda iptal edildi. Genel Muhasebe'deki Ayrıntılı Deneme Bakiyesi raporu, Geçmiş Eski Deneme Bakiyesi raporuyla eşleşmeyebilir. Örneğin, 1/1/2007 tarihinde bir fatura girildiğini varsayalım. Bu fatura 1/2/2007 tarihinde geçersiz kılındı. 1/2/2007 - 28/2/2007 için Genel Muhasebe Ayrıntılı Deneme Bakiyesi raporu yazdırılır. Geçersiz kılınan hareket raporda görünür. Geçmiş Eski Deneme Bakiyesi aynı tarih aralığı kullanılarak yazdırılırsa, geçersiz kılınan belge geçersiz kılındığından rapora yazdırılmaz.

  • Genel Muhasebe'deki borç hesapları hesap bakiyesini veya alacak hesapları hesap bakiyesini belirli bir süre için Geçmiş Eski Deneme Bakiyesi raporuna dengelemek istiyorsanız, Geçmiş Eski Deneme Bakiyesi raporundaki bakiyelerin aynı dönem için Genel Muhasebe'deki Ayrıntılı Deneme Bakiyesi'ndeki net değişiklikle mutabık olması gerekir.

  • Genel Muhasebe'deki borç hesapları bakiyesini veya alacak hesapları hesap bakiyesini belirli bir süre içinde olmayan bir gün için Geçmiş Eski Deneme Bakiyesi raporuna dengelemek istiyorsanız, Borç Yönetimi veya Alacak Yönetimi'nin hiç dengelenip dengelenmediğini belirleyin. Borç Yönetimi veya Alacak Yönetimi hiçbir zaman dengelenmemişse, başlangıç bakiyeleri yanlış olabilir. Bu durumda, önce en güncel dönemi dengeleyin ve ardından önceki ayları ters sırada uzlaştırın.

  • Deftere nakil kesintileri oluştuysa, toplu işlemler Genel Muhasebe'ye, Borç Yönetimi'ne veya Alacak Yönetimi'ne doğru şekilde deftere nakledilmemiş olabilir.

  • Geçmiş Eski Deneme Bakiyesi raporunu yazdırdığınızda Dışla alanında aşağıdaki onay kutularını seçmemişsinizdir.

  • Bu onay kutularını seçin ve Geçmiş Eski Deneme Bakiyesi raporunu yazdırın.

    Not

    Genel Muhasebe Ayrıntılı Deneme Bakiyesi raporuyla Eski Deneme Bakiyesi raporunu belirli belgelere göre eşleştirmek istiyorsanız, Tam Ücretli Belgeler onay kutusunu temizleyin.

    • Deftere Nakledilmemiş Uygulanan Kredi Belgeleri
    • Sıfır Bakiye
    • Etkinlik
  • Yeniden değerleme yaparken Çoklu Para Birimi Yönetimi'ni kullanıyorsanız, Satın Alma/Satış Mahsup Hesabına kaydetmeyi seçtiniz.

  • Fatura için Borçlar İşlem Girişi penceresine girilen kredi kartı tutarları. Bu durum, Genel Muhasebe modülüne yalnızca net değişiklik gönderileceğinden, Borç Yönetimi'nin Genel Muhasebe ile mutabakatı konusunda bir dengesizliğe neden olabilir. (Yani, GL işlemleri eksik gibi görünür, ancak GL tarafındaki tutarlar tek bir GL girdisinde netleştirilirken PM tarafı üç kayıt gösterebilir. Ancak bunlar yine de sonraki sürümlerde eşleşmeli ve Eşleşen İşlemler bölümüne doğru şekilde geçmelidir.)

  • Deftere nakletme kesintileri veya sorunları bir Borçlar veya Alacaklar toplu işleminde gerçekleştiğinde ve işlemler hem Çalışma hem de Aç tablolarında aynı anda bulunduğunda, Microsoft Dynamics GP'de RM veya PM toplu işleminin silinmesi sorunlara neden olur. Bu örnekte, kullanıcı genellikle kayıtları her iki tabloda da görür ve iş toplu işlemine gerek duymadığına karar verir, bu nedenle yalnızca Microsoft Dynamics GP'de siler. İş ve Aç tabloları bir dağıtım tablosunu paylaştığından, Microsoft Dynamics GP'de iş grubunun silinmesi, onunla birlikte dağıtım kayıtlarının da silinmesine neden olur. Sonuç, işlem üst bilgisi kaydının mevcut olmasıdır, ancak RM veya PM tarafında eşleşen dağıtımlar yoktur, ancak GL doğru güncelleştirildi. Bu sorun, Microsoft Dynamics GP'nin sonraki sürümünde ele alınacaktır.

  • Dağıtımlar, Potansiyel Eşleşmeler bölümünde indirimler varsa farklı tutarlarla görüntülenebilir. Eşleşmenin sağlanabilmesi için, GL hesaplarıyla uzlaştırma işlemi çalıştırılmadan önce indirim GL hesaplarının PM/RM hesabına getirilmesi gerekmektedir. Elektronik tabloyu kapatın ve listelenen indirim GL hesaplarıyla yeniden çalıştırın.

  • Tür (NAKİT, ÖDEME, SATIN ALMA) değiştirildiyse, PM/RM tarafında dağıtımlar eksik olabilir. Mutabakat elektronik tablosunda hesap yalnızca GL tarafı için kullanılır. Hesap PM/RM tarafında kullanılmaz. PM/RM tarafı, hangi hesabın kullanıldığına bakılmaksızın PAY veya REC türünü kullanarak çeker, bu nedenle tüm AP veya AR hesaplarınızı mutabakat penceresinde listelediğinizden emin olmanız gerekir. Sql Tablosunda dağıtım türünü değiştirmek, elektronik tabloyu yeniden oluşturursanız dağıtımın otomatik olarak gösterilmesini sağlamaz. (Bu, NAKİT tipi kullanan ve AP hesabına işlenen kredi kartı ödemeleri için önceki sürümlerde bir sorundu, ancak bu kayıtlar GP 2016'da görüntülendiğinden artık bir sorun olarak görünmüyor.)

  • GL'de deftere nakledildiği gerçek tarihle karşılaştırıldığında, çok para birimli işlemler için uygulama tablosundaki uygulama tarihini ve GL deftere nakil tarihini kontrol edin. Örneğin, 22 Ocak'ta, 5 Aralık tarihli bir faturaya 31 Aralık tarihli bir iade faturası uygulandı ve uygulama tarihi ve GL posta tarihi 22 Ocak olarak bırakıldı. Ancak, GL toplu işlemini deftere naklederken kullanıcı tarihi 31 Aralık olarak değiştirdi. Bu durumda, Aralık ayı için Genel Defter ile Mutabakat elektronik tablosu, her iki tarafta da gerçekleşen kazanç/kayıp miktarını listeler ve bunlar uzlaştırılmış olarak görünür. Ancak HATB raporu, gerçekleştirilen kazanç/zarar tutarını henüz tanımamaktadır ve Ocak ayına kadar uygulanmadığı veya kaydedilmediği için GL ile karşılaştırıldığında bu tutarda bir fark yaratacaktır.  

Sık sorulan sorular

GL Mutabakat elektronik tablosu, Borçlar/Alacaklar hesabının GL ile gerçek bir mutabakatı mı sağlıyor?

Y1: GL ile uzlaştırma özelliği, kullanıcıların RM/PM ile GL arasındaki eşleşmeyen dağıtımları tanımlamasına yardımcı olan bir sorun giderme aracıdır . HATB'ye bağlı olması şart değildi ve amaçlanan amaç bu değildi, ancak istemcilerin bunu yaptığını biliyoruz. Genel Muhasebe ile Mutabakat elektronik tablosundaki bakiyeler, tablodaki dağıtımlar üzerinde basit bir toplama ve çıkarma işlemi kullanılarak yapılmış yaklaşık tahminlerdir. HATB'de dengeler neredeyse her tabloyu dikkate alır ve çok daha karmaşık ve doğru dengelerdir ve bu nedenle ikisi genellikle birbirine bağlı olmaz.

Doğru uzlaştırma, RM veya PM Tarihsel Yaşlandırılmış Deneme Bakiyesi (HATB) ile GL Deneme Bakiyesi raporları arasında olmalıdır. Eğer bunlar eşleşiyorsa, o ay için GL'ye Mutabakat aracını kullanmanız gerekmeyebilir. GL tabloları borçlar ve alacaklardan oluşur ve HATB'nin çektiği tablolar işlem üst bilgisi ve kayıt uygulama tablolarıdır. Müşteriler bu düzeydeki farkları bulmaya yardımcı olmak için GL'deki dağıtımları RM veya PM'deki dağıtım tablolarıyla mutabık hale getirmek için bir yol istedi. Dolayısıyla Genel Muhasebe ile Uzlaştırma yordamının oluşturulmasının nedeni budur. Eksik dağıtımları belirlemenize yardımcı olmak için dağıtımları modüller arasındaki dağıtımlarla karşılaştıran ve HATB'den eksik bir işleme geri dönmenize neden olabilecek bir sorun giderme aracı olması amaçlanmıştır. Bu nedenle GL ile Uzlaştırma aracını yalnızca HATB ile GL Deneme Bakiyesi'ni mutabık hale getirmek için yardımcı olarak kullanın. Eğer HATB ve GL TB dengedeyse, o ay için Reconcile to GL aracını çalıştırmaya gerçekten gerek yoktur.

S2: Genel Muhasebe (GL) uzlaştırma tablosundaki toplamlar HATB'nin toplamlarıyla eşleşmeli mi?

A2: Hayır. GL'ye Mutabık Hale Getir elektronik tablosundaki toplamlar, bu tablodaki dağıtım kayıtlarının basit bir toplama/çıkarma işlemidir; diğer tabloları dikkate almaz. HATB, işlemi kullanarak bir bakiyeyi hesaplamak ve kayıt tablolarını uygulamak için tamamen farklı tablolara bakar ve çok daha karmaşık bir hesaplamadır. Bakiyeleri elde etmek için farklı hesaplama yöntemleri/tabloları kullanılması nedeniyle, GL ile mutabakat sağlama elektronik tablosunun HATB raporlarındaki eskime bakiyeleriyle birebir uyuşması beklenmez ve bu mutabakatı zorlaştırır. Uzlaştırma bakiyelerini GL elektronik tablosunda HATB raporuna bağlamak gerekli değildir.

GL uzlaştırma elektronik tablosundaki toplamları göz ardı etmenizi ve GL TB ile HATB arasındaki farkı açıklayıp açıklamadığını görmek için araştırma yapmak üzere farkları bulmanıza yardımcı olması adına Eşleşmeyen ve Muhtemelen Eşleşenler bölümlerini kullanmanızı öneririz. GL verileri ile mutabakat, gerçek bir mutabakat değildir ve yalnızca dağıtım farklılıklarını belirleyip araştırmanıza, böylece bunun işlem düzeyinde de bir fark olup olmadığını görmenize yardımcı olmak amacıyla hazırlanmıştır. Aslında, HATB GL TB ile eşleşirse, tanımlanacak bir fark olmadığından, o ay için GL yardımcı programıyla uzlaştırmayı çalıştırmaya gerek kalmaz.

GL elektronik tablosundaki bakiyeyi HATB'deki bakiyeyle uzlaştırmak istiyorsanız, bu işlem standart bir destek talebinde desteklenmemektedir. Belirlediğimiz nedenler bu KB'nin en üstünde listelenmiştir ve henüz tanımlanmamış daha fazla neden olabilir. Ancak, GL elektronik tablosunda listelenen basit toplam bakiye ile HATB raporundaki daha karmaşık hesaplanmış bakiye arasında bu mutabakat gerekli olmadığından ve bu mutabakat aracı bu amaç için tasarlanmamış olduğundan, bunları birbirine uyumlu hale getirmenize yardımcı olması için verileriniz üzerinde derinlemesine çalışma yapılması danışmanlık gideri olacaktır.

S3: GL tarafında dağıtımlar eksikse ne yapmalıyım?

A3: RM veya PM tarafında GL tarafında olmayan dağılımlar bulursanız, zamanlama farklılıkları için GL tarafını araştırın. Tüm GL toplu işlemlerinin deftere nakledildiğinden emin olun. GL tarafında gerçekten eksikse, GL dağıtımlarını oluşturmak için bir ayarlama günlüğü girdisini doğrudan GL'ye anahtarlamanız gerekir.

S4: RM veya PM tarafında dağıtımlar eksikse ne yapmalıyım?

4: GL dağılımı listeleniyorsa ancak RM veya PM tarafında eksikse, önce zamanlama farklılıklarını araştırın. Ayrıca işlemin kendisinin HATB raporunda listelenip listelenmediğini ve zaten hesaba katılıp katılmadığını da araştırın. İşlem mevcut olabilir, ancak dağıtımlar eksik olabilir. Bu nedenle soru , işlem mevcutsa RM veya PM'deki dağıtımları nasıl alabilirim? İlk olarak, RM veya PM'deki dağıtım tablolarının bu mutabakat elektronik tablosu dışında GP'de başka bir amaç veya rapor için kullanılmadığını unutmayın. Yani onları RM veya PM'ye geri eklemek gerçekten gerekli mi? Başka hiçbir yerde kullanılmayan bir tabloyu doldurmaya zaman ayırıp değmediğini değerlendirin.

Ancak PM dağıtım tablosunu düzeltmeyi seçerseniz, belgeyi geçersiz kılmanız gerekir, böylece uygulanan kayıtlar yeniden açılacaktır. Ardından geçersiz kılınan belgeyi kaldırmak için İşlem Geçmişini Kaldır Yardımcı Programını kullanın. Gönderiyi GL'ye nakil olarak ayarladığınızdan ve GL'ye nakil olmadığından emin olun. Void tarafından oluşturulan GL toplu işlemini silin. Ardından, işlemlerin ve dağıtımların yeniden oluşturulması için belgeyi Borçlar'a tekrar girin. Bunun için GL toplu işlemini geçersiz kılmayı unutmayın. Ardından yeni belgeyi açık belgelere yeniden uygulayın; bunlar yeniden geçmişe taşınmalıdır.

RM dağıtım tablosunda düzeltmek için faturanın ve ödemenin her iki tarafını da kaldırmanız ve her ikisini de yeniden oluşturmanız ve toplu işlemi GL'de silmeniz gerekir.

S5: Olası Eşleşmeler bölümündeki işlemler eşleşmiş gibi görünür. Neden Eşleştirildi bölümünde değiller?

Y5: Her dağıtım kaydı için eşleşen birkaç alan vardır. Eşleşen kısma taşımak için tüm alanların eşleşmesi gerekir. Alanların bazıları eşleşiyorsa ancak tümü eşleşmiyorsa, eşleşme olasılığı olan bölüme koyar. Örneğin, PM ile GL arasında eşleşen alanlar şunlardır:

Borç Yönetimi -- Genel Muhasebe
Fiş Numarası -- Kaynak Kontrol Numarası
TRX Kaynağı -- Başlangıç TRX Kaynağı
Muhasebe Kaydı Tarihi -- Hareket Tarihi
Hesap Tutarı -- Borç Tutarı veya Alacak Tutarı

S6: Eksik dağıtımları GL veya RM/PM'de girersem ve GL mutabakat elektronik tablosunu yeniden çalıştırırsam, eşleşmemiş veya eşleşebilir öğeler Eşleşen bölümüne taşınır mı?

A6: Hayır. İşlemler ayrı olarak anahtarlanmışsa, farklı fiş numaraları ve Trx Kaynak kodları olacaktır. En iyi durumda, Kayıt Tarihi ve Tutarlar eşleşebilir ve bu onları elektronik tablonun Potansiyel Eşleşenler bölümüne koyabilir.

S7: Aylık veya üç aylık bir elektronik tablodaki Bitiş Bakiyesi neden sonraki aylık veya üç aylık elektronik tablodaki Başlangıç Bakiyesi ile eşleşmiyor?

Y7: Bir dönemin Bitiş Bakiyesi bir sonraki dönemin Başlangıç bakiyesi ile eşleşmiyorsa, bunun nedeni genellikle alt kayıt tablosunda ilişkili üst bilgi kaydı olmayan yalnız bırakılmış dağıtım kayıtlarıdır. Bitiş Bakiyesi, doğrudan elektronik tabloda Excel tarafından hesaplanır. Yalnızca elektronik tablonun en üstündeki dönemin başlangıç bakiyesini alır ve bitiş bakiyesine ulaşmak için elektronik tabloda görünen dağıtım kayıtlarını ekler/çıkarır. Öte yandan, sonraki dönemde Başlangıç bakiyesi, SQL tablosundaki dağıtım kayıtlarının basit bir borç/alacak hesaplaması alınarak hesaplanır. Saklı yordam, üst bilgi tablosu ile birleştirme işlemi yapar, bu nedenle üst bilgi kaydı eksik olan hiçbir dağıtımı içermeyecektir. Sonuç olarak, bazı dağıtımlar önceki elektronik tablodaki bitiş bakiyesine hesaplanmış ve sonraki dönemde başlangıç bakiyesinden atlanmış olabilir.

S8: RM/PM tarafındaki dağıtımlar var, ancak elektronik tabloya aktarılmıyor.

A8: Şu sorun giderme ipuçlarını gözden geçirin:

  • Mutabakat elektronik tablosundaki tarih aralığını inceleyin.
  • Dağıtımların PM için PM10100 veya PM30600 tablolarında mevcut olduğunu doğrulayın. (veya RM için: RM10101 veya RM30301 arama) Elektronik tablo için girdiğiniz aralıkta yer aldıklarından emin olmak için bu dağıtımlardaki tarihleri inceleyin. Bunları RM veya PM dağıtım tablolarında bulmak ve yalnızca yeniden yazdırılan defter kayıtlarına güvenmemek önemlidir.
  • Dağıtımları RM veya PM tablolarında bulursanız, ön uçtaki belgedeki bu dağıtımlara bakın. Pay veya REC ya da AVAIL dağıtım türüne sahipler mi? Bunlar, eski sürümlerde RM veya PM tarafındaki mutabakat tablosuna çekilecek tek türler bunlardır. (Güncelleştirme: Kredi kartı ödemeleri, AP hesabına NAKIT türünde bir dağıtım üretebilir ve bu dağıtım tabloda yer alır, ancak GL ile mutabakat tablosu bu dağılımı sol sütunda göstermedi. Bu nedenle, veri sorunu değil, yalnızca elektronik tabloyla ilgili bir görüntüleme sorunu. Ancak bu, Microsoft Dynamics GP 2016'da bir sorun olarak görünmüyor, çünkü NAKIT türü artık tabloda doğru bir şekilde görüntüleniyor ve bu süreçte düzeltildi.)

S9: GL ile Mutabakat penceresinin diğer para birimlerinde görüntülenmesini sağlayabilir misiniz?

Y9: Yalnızca işlevsel para birimlerini görüntülemek için tasarlanmış GL ile Mutabakat penceresi. Daha fazla bilgi için bkz . Microsoft Dynamics GP'de GL ile uzlaştırma penceresindeki bakiyeler hakkında bilgi.