Informasi tentang perbedaan ketika Anda rekonsiliasi buku besar untuk manajemen utang atau manajemen piutang di Microsoft Dynamics GP

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 866570
PENDAHULUAN
Artikel ini membahas mengapa saldo akun dibayar atau piutang akun saldo akun di buku besar berbeda dari jumlah total yang dijadwalkan pada sejarah usia saldo percobaan melaporkan di Microsoft Dynamics GP. Ada yang sering ditanyakan di bagian akhir artikel ini.
Informasi lebih lanjut
Rekonsiliasi GL rutin ini baru untuk Microsoft Dynamics GP 10.0 (SP2). Rutin ini menghasilkan spreadsheet Microsoft Office Exel. Anda dapat menggunakan spreadsheet ini sesuai transaksi manajemen utang atau manajemen piutang yang dikirim ke buku besar. Proses ini tidak menghasilkan mengoreksi transaksi. Namun, proses ini dapat membantu Anda menentukan perbedaan transaksi yang tercantum dalam bagian ini. Untuk membuka jendela "Rekonsiliasi untuk GL", arahkan kealat pada menu Microsoft Dynamics GP , arahkan ke rutinitas, arahkan ke keuangan, dan kemudian klik rekonsiliasi terhadap GL.


Di bawah ini adalah daftar masalah yang telah kita lihat yang dapat menyebabkan perbedaan berjalan:

  • Laporan sejarah usia saldo percobaan dicetak dengan pembatasan. Mencetak laporan sejarah usia saldo percobaan lagi dengan hanya pembatasan tanggal.
  • Tidak semua account dibayar atau semua akun piutang akun secara umum melihat buku. Pastikan bahwa Anda melihat semua account dibayar account atau semua akun piutang akun di buku besar.
  • Batch di manajemen utang atau manajemen piutang telah dikirim ke buku besar. Batch di buku besar diubah atau diedit sebelum diposting.
  • Pengaturan akun dibayar akun atau akun piutang mungkin telah masuk secara langsung pada umumnya buku. Transaksi ini update akun di buku besar. Namun, transaksi ini tidak memperbarui laporan sejarah usia saldo percobaan.
  • Tanggal kisaran di saldo percobaan rincian laporan secara umum buku tidak cocok dengan kisaran tanggal laporan sejarah usia saldo percobaan di manajemen utang atau manajemen piutang. Saat mencetak laporan sejarah usia saldo percobaan, klik untuk memilih kotak centang Tanggal Posting GL di Pilih transaksi untuk laporan menggunakan area.
  • Transaksi yang diposting pada manajemen utang atau manajemen piutang. Namun, transaksi ini tidak dipasang ke buku besar jika mereka untuk saldo awal. Jika kotak centang Posting ke buku besar tidak dipilih di jendela Setup pengiriman untuk pembelian seri atau seri penjualan, transaksi akan dikirimkan untuk manajemen utang atau manajemen piutang. Namun, transaksi ini tidak akan diposting ke buku besar.
  • Lacak diskon tersedia di GL kotak centang dipilih di jendela Setup manajemen utang atau di jendela Setup manajemen piutang. Lalu, jumlah net faktur akan dikirim ke buku besar. Selain itu, jumlah sisa dikirim ke akun tersedia diskon. Hanya jumlah bersih akan muncul di laporan rinci saldo percobaan secara umum buku. Namun, faktur menampilkan total kotor faktur di sejarah usia saldo percobaan di manajemen utang atau manajemen piutang.
  • kumpulan dokumen voided dalam jangka waktu yang berbeda dari yang mereka awalnya dikirim. Saldo percobaan rincian laporan secara umum buku mungkin tidak cocok laporan sejarah usia saldo percobaan. Sebagai contoh, misalnya faktur dimasukkan pada 1/1/2007. Faktur ini ini dibatalkan pada 1/2/2007. Laporan umum buku rincian saldo percobaan dicetak untuk 1/2/2007-2/28/2007. Transaksi voided akan muncul di dalam laporan. Jika saldo percobaan usia sejarah dicetak menggunakan kisaran tanggal yang sama, voided kumpulan dokumen tidak akan mencetak laporan karena telah voided.
  • Jika Anda ingin saldo akun dibayar akun saldo atau piutang akun saldo akun secara umum buku untuk historis usia saldo percobaan melaporkan untuk jangka waktu tertentu, saldo dari laporan historis usia saldo percobaan harus didamaikan net perubahan pada saldo percobaan rincian secara umum buku untuk periode yang sama.
  • Jika Anda ingin saldo piutang saldo akun atau akun piutang akun saldo secara umum buku laporan historis usia saldo percobaan untuk hari yang tidak dalam jangka waktu tertentu, menentukan apakah manajemen utang atau manajemen piutang telah sebelumnya telah seimbang. Jika manajemen utang atau manajemen piutang sudah pernah telah seimbang, saldo awal mungkin salah. Dalam situasi ini, keseimbangan periode terbaru terlebih dahulu, dan kemudian rekonsiliasi bulan sebelumnya dalam urutan menurun terbalik.
  • Jika posting interupsi terjadi, batch mungkin tidak telah diposting benar buku besar, manajemen utang, atau manajemen piutang.
  • Tidak semua buku besar batch dikirim.
  • Saat Anda mencetak sejarah usia saldo percobaan laporan, Anda tidak klik untuk memilih kotak centang berikut di bidang Kecualikan:
    • kumpulan dokumen unposted kredit diterapkan
    • Saldo nol
    • Aktivitas
    Klik untuk mencentang kotak, dan kemudian mencetak laporan sejarah usia saldo percobaan.

    Catatan Jika Anda ingin cocok umum buku rincian saldo percobaan dan laporan historis usia saldo percobaan dengan kumpulan dokumen tertentu, klik untuk mengosongkan kotak centang Sepenuhnya dibayar kumpulan dokumen .
  • Jika Anda menggunakan multi mata uang manajemen ketika Anda revalue, Anda memilih untuk mengirim ke Beli penjualan Offset akun.
  • Di Microsoft Dynamics GP 10.0, jumlah Kartu Bisnis kredit yang dimasukkan di jendela entri transaksi utang untuk faktur. Ini dapat menyebabkan ketidakseimbangan pada rekonsiliasi untuk manajemen utang ke buku besar karena hanya perubahan net akan dikirim ke modul buku besar.
  • Jika ada posting interupsi/masalah dengan utang atau piutang kelompok dan transaksi yang ditemukan di kedua pekerjaan dan buka Daftar Tabel pada saat yang sama, menghapus batch RM atau PM di GP akan menyebabkan masalah. Dalam contoh ini, pengguna biasanya melihat data dalam Daftar Tabel kedua, dan memutuskan tidak memerlukan batch kerja sehingga mereka hanya menghapus di GP. Karena pekerjaan dan buka Daftar Tabel berbagi Daftar Tabel distribusi, menghapus batch di GP juga akan menghapus data distribusi dengannya. Hasil akhir adalah bahwa ada transaksi header catatan, tetapi ada distribusi tidak cocok di sebelah RM atau PM, tetapi GL dimutakhirkan dengan benar. Masalah ini akan dianggap dalam versi Microsoft Dynamics GP berikutnya.
  • Distribusi mungkin muncul di bagian berpotensi cocok dengan jumlah yang berbeda apabila ada diskon. Untuk cocok, akun GL diskon harus memiliki telah ditarik dengan akun PM RM sebelum menjalankan rekonsiliasi GL proses. Tutup spreadsheet dan menjalankan ulang dengan akun GL diskon juga terdaftar.
  • Distribusi mungkin akan hilang di sebelah PM RM jenis (tunai, PAY, PURCH) telah diubah. Pada spreadsheet rekonsiliasi, akun hanya digunakan untuk sisi GL. Akun yang tidak digunakan di sebelah PM RM. Sisi PM RM menarik menggunakan membayar atau REC jenis terlepas dari akun apa yang digunakan, sehingga itulah mengapa Anda harus yakin untuk daftar semua sentuh atau AR akun di jendela rekonsiliasi. Dan hanya beralih jenis distribusi di dalam Daftar Tabel SQL tidak membuat distribusi secara otomatis muncul jika Anda kembali spreadsheet.
  • Periksa tanggal Terapkan dan tanggal posting GL dalam Daftar Tabel Terapkan multi mata uang transaksi dibandingkan dengan tanggal yang sebenarnya diposting di GL. Misalnya, pada tanggal 22 Jan memo kredit tertanggal 31 Desember diterapkan ke faktur tertanggal 5 Des, dan tanggal Terapkan dan tanggal posting GL yang tersisa sebagai Jan 22. Namun, apabila posting GL batch, pengguna diubah tanggal untuk 31 Desember. Dalam hal ini, rekonsiliasi untuk GL spreadsheet untuk bulan Desember mendaftar jumlah memperoleh/kehilangan menyadari sisi dan mereka muncul harus disesuaikan. Namun, laporan HATB tidak mengenali jumlah memperoleh/kehilangan menyadari belum dan akan keluar dengan jumlah ini bila dibandingkan dengan GL, karena itu tidak diterapkan atau dikirim sampai Januari Menurut catatan Terapkan.


Pertanyaan yang sering diajukan:


Q1: Adalah rekonsiliasi GL spreadsheet rekonsiliasi benar untuk utang/piutang untuk GL?

A1: Rekonsiliasi untuk GLfeature adalah 'alat pemecahan masalah' untuk membantu pengguna mengidentifikasi tiada banding distribusi antara RM PM dan GL. Itu tidak perlu dimaksudkan untuk mengikat untuk HATB dan itu bukan tujuan, meskipun kami tahu klien melakukannya. Saldo pada rekonsiliasi ke GL spreadsheet yang terbaik perkiraan menggunakan penambahan/pengurangan sederhana di distribusi di dalam Daftar Tabel. Sedangkan saldo pada HATB mempertimbangkan hampir setiap Daftar Tabel dan yang lebih kompleks dan akurat saldo dan begitu dua sering tidak mengikat keluar.

Rekonsiliasi yang sebenarnya harus antara RM atau PM sejarah usia saldo percobaan (HATB) dan saldo percobaan GL laporan. Jika ini sesuai, maka Anda akan tidak perlu harus menjalankan rekonsiliasi GL alat untuk bulan. Daftar Tabel GL terdiri dari debit dan kredit, dan Daftar Tabel yang menarik HATB dari header transaksi dan menerapkan data Daftar Tabel. Jadi pelanggan meminta cara rekonsiliasi distribusi di GL untuk distribusi Daftar Tabel di RM atau PM untuk membantu menemukan perbedaan pada tingkat itu. Jadi, ini adalah alasan mengapa rekonsiliasi GL rutin dibuat. Ini dimaksudkan untuk menjadi alat pemecahan masalah untuk membandingkan distribusi distribusi antara modul untuk membantu mengidentifikasi distribusi hilang, yang dapat menyebabkan Anda kembali ke transactionfrom hilang HATB. Jadi gunakan rekonsiliasi GL alat sebagai bantuan hanya untuk membantu Anda rekonsiliasi HATB untuk saldo percobaan GL. Jika HATB dan GL TB keseimbangan, maka tidak ada benar-benar perlu menjalankan rekonsiliasi GL alat untuk bulan.


Q2: Harus cocok Total pada rekonsiliasi untuk GL spreadsheet Total di HATB?

A2: Nomor Total pada rekonsiliasi untuk GL spreadsheet yang hanya sederhana penambahan/pengurangan catatan distribusi di Daftar Tabel tersebut dan tidak mempertimbangkan Daftar Tabel lain. Sedangkan HATB terlihat pada Daftar Tabel yang berbeda untuk menghitung keseimbangan menggunakan transaksi dan menerapkan catatan Daftar Tabel dan perhitungan jauh lebih kompleks. Karena berbeda perhitungan metode/tabel digunakan untuk mendapatkan saldo, rekonsiliasi ke GL spreadsheet tidak diharapkan untuk mengikat langsung ke saldo umur HATB laporan dan akan membuat merekonsiliasi mereka sulit. Hal ini tidak diperlukan untuk mengikat saldo pada rekonsiliasi untuk GL spreadsheet laporan HATB.

Kami menyarankan untuk mengabaikan Total pada rekonsiliasi untuk GL spreadsheet, dan hanya menggunakan bagian Unmatched dan berpotensi cocok untuk membantu Anda menemukan perbedaan penelitian untuk melihat apakah yang mungkin juga menjelaskan perbedaan antara GL TB dan HATB. Rekonsiliasi ke GL spreadsheet bukan rekonsiliasi benar, dan hanya dimaksudkan untuk menjadi 'Bantuan' untuk membantu Anda mengidentifikasi perbedaan distribusi penelitian untuk melihat apakah hal ini juga perbedaan tingkat transaksi. Pada kenyataannya, jika HATB cocok dengan GL TB, tidak benar-benar akan perlu menjalankan rekonsiliasi ke GL utilitas untuk bulan yang sama sekali, karena ada tidak ada perbedaan untuk mengidentifikasi.

Lagi jika Anda masih ingin mengikat keseimbangan pada rekonsiliasi untuk GL spreadsheet keseimbangan di HATB, hal ini tidak didukung dalam kasus dukungan biasa. Alasan kami telah mengidentifikasi tercantum di bagian atas KB ini dan mungkin ada alasan lain yang tidak teridentifikasi. Namun karena rekonsiliasi ini tidak diperlukan antara keseimbangan total sederhana yang tercantum pada rekonsiliasi GL spreadsheet dan keseimbangan dihitung lebih kompleks HATB laporan, dan tidak tujuan rekonsiliasi utilitas ini, itu akan dianggap pengeluaran konsultasi untuk menggali data untuk membantu Anda untuk rekonsiliasi ini satu sama lain.



T3: Apa yang harus saya lakukan jika distribusi hilang di sebelah GL?

A3: apabila Anda menemukan distribusi di sebelah RM atau PM yang tidak di sebelah GL, menyelidiki sisi GL perbedaan waktu. Periksa untuk memastikan bahwa semua kumpulan GL dikirim. Jika sudah benar-benar hilang di sebelah GL, Anda akan perlu untuk menyesuaikan entri jurnal langsung ke GL entri untuk membuat GL distribusi bukti kunci.



T4: Apa yang harus saya lakukan jika distribusi hilang di sebelah RM atau PM?

A4: Jika distribusi GL terdaftar, tetapi tidak ada di sebelah RM atau PM, pertama-tama menyelidiki untuk perbedaan waktu. Juga penelitian untuk melihat apakah transaksi sendiri tercantum di HATB laporan dan telah menyumbang. Ada kemungkinan bahwa transaksi sudah ada, namun distribusi tidak hanya ada. Jadi pertanyaan menjadi 'Bagaimana cara mendapatkan distribusi RM atau PM kemudian, jika ada transaksi?' Pertama, diingat Daftar Tabel distribusi RM atau PM tidak digunakan untuk tujuan lain atau laporan di GP, Selain ini rekonsiliasi lembar kerja. Jadi adalah benar-benar diperlukan untuk mendapatkan mereka ditambahkan ke dalam RM atau PM? Mengevaluasi apakah bernilai waktu Anda untuk mengisi Daftar Tabel yang tidak digunakan di mana saja lain.

Namun, jika Anda memilih untuk memperbaiki Daftar Tabel distribusi PM Anda harus membatalkan kumpulan dokumen, sehingga data diterapkan kembali untuk membuka. Kemudian gunakan menghapus transaksi Riwayat utilitas untuk menghapus kumpulan dokumen voided. Pastikan untuk mengatur posting ' posting ke ' GL dan tidak 'posting melalui terhadap GL'. Hapus batch GL yang dibuat oleh void. Kemudian Pickering kumpulan dokumen kembali ke utang, sehingga transaksi dan distribusi akan dibuat ulang. Pastikan untuk membatalkan GL batch ini. Kemudian Terapkan kembali kumpulan dokumen baru untuk membuka kumpulan dokumen dan mereka harus pindah ke Riwayat lagi.

Untuk memperbaiki hal pada Daftar Tabel distribusi RM, Anda harus menghapus kedua sisi faktur dan pembayaran dan Pickering keduanya kembali, dan menghapus batch di GL.



P5: Transaksi di bagian berpotensi cocok terlihat seperti mereka cocok. Mengapa tidak mereka di bagian Matched?

J5:Ada beberapa bidang yang cocok untuk setiap kumpulan dokumen distribusi. Semua kolom harus cocok untuk memindahkannya ke bagian Matched. Jika beberapa tetapi tidak semua kolom sesuai, maka hal itu akan memasukkannya di bagian berpotensi cocok. Sebagai contoh, berikut adalah kolom yang cocok untuk terhadap GL:

Manajemen utang--GL
Nomor voucher--Berasal dari nomor kontrol
Sumber TRX--Berasal dari sumber TRX
Posting tanggal - tanggal transaksi
Jumlah akun di--Debit jumlah atau jumlah kredit


Q6: Jika saya bukti kunci distribusi hilang di GL atau RM PM dan jalankan kembali rekonsiliasi ke GL spreadsheet, akan tiada banding atau berpotensi cocok item pindah ke bagian Matched?

A6: Nomor Jika transaksi mengetik secara terpisah, akan memiliki nomor voucher berbeda dan Trx sumber kode. Terbaik tanggal pengiriman dan jumlah mungkin cocok, yang dapat menempatkannya di bagian berpotensi cocok spreadsheet.



Q7:Mengapa tidak keseimbangan berakhir pada spreadsheet bulanan atau triwulanan cocok saldo awal pada lembar kerja bulanan atau triwulanan berikutnya?

A7: Ifthe berakhir keseimbangan satu periode tidak cocok dengan saldo awal periode berikutnya, sering karena ditinggalkan distribusi data yang telah ada catatan header Daftar Tabel sub buku. Saldo berakhir dihitung dengan Excel tepat di spreadsheet. Hanya dibutuhkan saldo awal untuk jangka waktu di atas spreadsheet dan menambahkan/mengurangi distribusi data yang muncul di lembar kerja untuk tiba di akhir keseimbangan. Di sisi lain, di masa depan, saldo awal dihitung dengan mengambil perhitungan sederhana debit/kredit distribusi data di dalam Daftar Tabel SQL dan prosedur tersimpan bergabung dengan header Daftar Tabel, sehingga tidak akan menyertakan distribusi yang hilang catatan header. Hasil akhir bisa bahwa beberapa distribusi dihitung ke akhir keseimbangan spreadsheet sebelumnya, dan dihilangkan dari saldo awal di masa depan.



T8: Distribusi di sebelah RM PM ada, namun tidak menarik ke dalam spreadsheet.

A8: Meninjau tips pemecahan masalah ini:
  • Periksa rangeused tanggal pada rekonsiliasi ke lembar kerja.
  • Verifikasi bahwa distribusi ada dalam Daftar Tabel PM10100 atau PM30600 untuk malam (atau RM: pencarian RM10101 atau RM30301) memeriksa tanggal distribusi ini untuk memastikan bahwa mereka jatuh berada dalam kisaran yang Anda masukkan untuk spreadsheet. Penting untuk menemukan ini dalam Daftar Tabel distribusi RM atau PM dan untuk tidak hanya mengandalkan dicetak posting jurnal misalnya.
  • Jika Anda menemukan distribusi dalam Daftar Tabel RM atau PM, kemudian lihat ini distribusi di kumpulan dokumen di front-end. Apakah mereka memiliki jenis distribusi membayar atau REC? Ini adalah jenis hanya yang akan diambil untuk spreadsheet rekonsiliasi di sebelah RM atau PM.


Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 866570 - Tinjauan Terakhir: 09/07/2016 19:55:00 - Revisi: 0.8

Microsoft Dynamics GP 2015, Microsoft Dynamics GP 2013, Microsoft Dynamics GP 2010, Microsoft Dynamics GP 10.0, Microsoft Dynamics GP 9.0

  • kbexpertiseinter kbhowto kbinfo kbexpertisebeginner kbmbsmigrate kbmt KB866570 KbMtid
Tanggapan