Cara mengatur ulang register dalam 1s 8.3. Menyetel ulang saldo dan gerakan register akumulasi (UV)

Kami memutuskan untuk membereskan konfigurasi UT 11. Dan di sana ... Sisa-sisa barang tidak menyatu dengan sisa-sisa organisasi (beberapa organisasi digunakan), tetapi mereka tidak begitu dekat dengan pengiriman barang, dan perdagangan komisi digunakan bersamaan dengan perdagangan reguler. Singkatnya, semuanya begitu terabaikan sehingga lebih mudah untuk memulai dari awal, TETAPI ... Anda tidak dapat memulai dari awal - bundel dengan akuntansi perusahaan 3.0 (direktori, dokumen), dan di sana pelaporan telah dikirimkan. Kami memutuskan demikian, dalam pembukuan kami membuat pesanan secara terpisah, di UT secara terpisah. Khusus untuk UT, mereka memutuskan: segala sesuatu yang berkaitan dengan barang (barang di gudang, barang organisasi, banyak barang organisasi, ditambah register yang berkaitan dengan komisi) dibatalkan, maka kami membuat kedatangan fiktif (termasuk komisi), dan kami memperbaiki penyelesaian bersama dengan menyesuaikan penyelesaian bersama. Pada awalnya saya mulai menulis pemrosesan untuk register tertentu, ketika saya sedang menulis, saya berpikir tentang menulis waktu universal, hampir sama, tetapi itu akan berlaku untuk semua register sehingga saya tidak akan menulis ulang sepuluh kali kemudian. Ini juga harus cocok untuk Ritel 2, Konfigurasi terintegrasi dan lainnya untuk formulir yang dikelola. Diuji pada UT11.

Bagaimana cara menggunakan. Pertama, kita secara manual membuat dokumen kosong "penyesuaian daftar", mengatur tanggal dan waktu (saya menetapkan 23:59:59 pada akhir kuartal), sisa register akan dibawa ke posisi ini (posisi dokumen), secara umum, kita hanya memiliki posisi dari dokumen dan membutuhkannya Kemudian kita memilih register mana yang perlu kita nol dan klik "Formulir." Kami membuka penyesuaian, melihat, memeriksa register dengan bantuan laporan dan / atau laporan universal. Saldo ditutup di semua dimensi dan semua sumber daya. Juga dalam formulir terdapat pilihan berdasarkan organisasi dan gudang (atavisme dari versi asli, tetapi berfungsi) Saya tidak menambahkan pilihan lain (karena saya tidak membutuhkannya sama sekali), yang perlu Anda tambahkan sendiri, semuanya ditulis dengan jelas dalam modul, tetapi tidak Dia mulai berlaku karena, misalnya, jika suatu organisasi dipilih, maka pemilihan untuk Daftar Barang Organisasi akan berhasil, tetapi untuk Pendaftaran Barang di Gudang itu tidak (tidak ada pengukuran seperti itu), oleh karena itu menghilang tanpa seleksi.

Beberapa waktu telah berlalu ...

Versi baru dirilis, sekarang prosesnya telah belajar (biasanya memberikan kesalahan - yaitu, sebenarnya hanya bekerja dengan register saldo) untuk membalikkan gerakan register akumulasi terbalik. Selain itu, pergerakannya terbalik, mis. jika Anda melihat register, katakan, "Penjualan" di UT11, maka setelah membalikkan penjualan tidak akan muncul sama sekali, yaitu seolah-olah tidak ada penjualan sama sekali - omset secara keseluruhan untuk periode tersebut akan kosong. Sekali lagi - ternyata, misalnya, kami memiliki penjualan untuk periode 1-30 Januari, saya melakukan pembalikan pada tanggal 31, setelah itu jika saya melihat laporan dari 1 hingga 30 saya akan melihat penjualan, dari 31 hingga 31 saya akan melihat pembalikan, dari 1- 31 - acara kosong. Sebagai contoh, saya membalikkan gerakan register "Tunai" di UT11 dan Ritel 2.2 ketika saya harus memesan "Kasir" (50 akun yang mengerti).

Ya, saya lupa mengatakan, bidang "Tanggal Mulai" muncul - digunakan untuk mengatur tanggal mulai periode untuk register yang dapat dinegosiasikan (tentu saja, itu tidak berlaku untuk saldo), posisi dokumen "Penyesuaian Daftar" digunakan sebagai tanggal akhir periode (untuk register yang dapat dinegosiasikan) - yaitu. . adapun neraca saldo (saldo dihapus pada posisi dokumen). Untuk register yang dapat dinegosiasikan, "DateStart" dapat tetap kosong - dalam hal ini, dianggap sebagai tanggal paling awal yang dapat terjadi, dan untuk register yang dapat dinegosiasikan itu berarti bahwa semua pergerakan dibalik dari awal akuntansi untuk posisi dokumen "Koreksi Registrasi".

Berita baik - biaya poin telah berkurang.

Belajar bekerja dengan register (1C: Akuntansi 8.3, edisi 3.0)

  2016-12-08T13: 50: 45 + 00: 00

Pembaca yang budiman, dalam pelajaran ini saya ingin menyentuh topik yang sangat penting ketika bekerja di 1C: Akuntansi 8.3 - Daftar.

Segera saya akan menunjukkan kepada Anda dengan contoh kecil mengapa ini sangat penting.

Misalkan kita memiliki daftar gaji untuk bulan Januari:

Pada awal Februari, kami membuat lembar penggajian dari mesin kasir dan klik tombol "Isi":

Dan kami mendapatkan yang berikut:

Tapi untuk bulan Januari:

• Mengisi 50.000 rubel
• Pajak penghasilan pribadi 6 500 rubel
• Total hutang 43.500 rubel

Di mana kesalahan merayap masuk? Apa yang salah? Apakah sekarang selalu memungkinkan untuk memasukkan jumlah yang harus dibayar secara manual?

Seorang akuntan yang berpengalaman akan segera membuat neraca untuk 70 akun:

Dan itu akan semakin membingungkan, karena menurut laporan, 43.500 yang sama akan keluar untuk pembayaran! Dan dari mana 5.000 rubel ekstra itu berasal?

Selain itu, situasi seperti itu (dengan perhitungan apa pun) dapat terjadi baik di "troika" dan "deuce".

Hari ini saya akan mencoba membuka tabir kerahasiaan - mengapa kadang-kadang sebuah program berperilaku aneh. Saya akan memberi tahu Anda cara menemukan dan memperbaiki kesalahan dalam kasus seperti itu. Menjelang akhir artikel, kita akan mencari tahu dari mana 5.000 rubel ini berasal.

Jadi ayo pergi!

Belajar melihat register

Saat melakukan dokumen 1C: Akuntansi 8 membuat entri dalam akun akuntansi (tombol DtKt untuk dokumen apa pun):

Atas dasar postingan inilah dibangun semua laporan akuntansi: Analisis Akun, Kartu Akun, Neraca ...

Tetapi ada lapisan besar data yang ditulis oleh program secara paralel dengan posting dan digunakan untuk yang lainnya: mengisi KUDIR, buku pembelian dan penjualan, pelaporan yang diatur ... hutang penggajianakhirnya

Seperti yang sudah Anda duga, layer ini disebut registerini dia:

Saya tidak akan masuk ke rincian deskripsi register sendiri sekarang, agar tidak membingungkan Anda lebih banyak lagi.

  Saya hanya bisa mengatakan bahwa sangat penting bagi kita untuk secara bertahap belajar untuk "melihat" gerakan dalam register ini untuk lebih memahami dan, jika perlu, menyesuaikan perilaku program.

Mari kita lihat daftar Gaji untuk Membayar - masuk akal untuk menyelesaikan masalah kita dengan 5.000 tambahan:

Kami melihat dua entri pada daftar ini dibuat di paroki, yaitu di plus. Jika kita menggulir layar ke kanan, maka kita akan melihat di baris pertama jumlah yang harus dibayar "-6.500", dan di "50.000" kedua.

Saldo register ini -6.500 + 50.000 sama dengan 43.500, yang harus dimasukkan dalam dokumen "Pernyataan pembayaran dari meja kas" ketika kita mengklik tombol "Isi".

Saya ulangi lagi -   lembar gaji menentukan tunggakan gaji kami kepada karyawan tidak sesuai dengan akun ke-70, tetapi menurut daftar Gaji untuk Membayar.

Ternyata kita tahu bahwa gaji yang harus dibayar dipenuhi berdasarkan register ini, tetapi bahkan melihat entri register kita tidak dapat memahami apa yang salah.

Kemungkinan besar, kami tidak melihat keseluruhan gambar (mungkin ada entri lain pada register ini), dan beberapa alat untuk menganalisis register mirip dengan laporan akuntansi.

Belajar menganalisis register

Dan ada alat seperti itu, itu disebut " Laporan Universal".

Buka bagian "Laporan" dari item "Laporan Universal":

Pilih jenis register "Akumulasi daftar", register "Gaji untuk membayar" dan klik tombol "Hasilkan":

Ternyata tidak terlalu informatif:

Itu karena laporan harus dikonfigurasi sebelumnya, klik tombol "Tampilkan pengaturan" dan pada tab "Pengelompokan" tambahkan bidang "Karyawan":

Pada tab "Pilihan" kami membuat pilihan untuk organisasi kami:

Klik tombol "Buat":

Ini sudah lebih menarik. Kami melihat saldo dibayarkan kepada karyawan kami 48.400 rubel yang sama!

Sekali lagi, buka pengaturan laporan dan tambahkan ke tab "Indikator" bidang baru "Pencatat":

Kami kembali menghasilkan laporan:

Sekarang kita dapat dengan jelas melihat bahwa 5.000 muncul sebagai hasil dari operasi (tampaknya memasuki saldo) pada 31 Desember 2014.

Dan kita perlu mengubah operasi ini, atau secara manual menyesuaikan daftar Gaji untuk Membayar dan menutup 5.000 rubel ini, misalnya, pada 31 Desember 2015.

Ayo pergi ke jalan kedua. Jadi, tugas kami adalah memastikan bahwa pada awal 2016, menurut daftar Gaji untuk Membayar, tidak ada utang kami kepada karyawan.

Ini dilakukan dengan operasi manual.

Belajar menyesuaikan register

Buka bagian "Operasi" dari item "Entri Manual":

Kami menciptakan operasi baru pada akhir 2015:

Dari menu "Lainnya", pilih item "Pilih Registrasi ...":

Tentukan register "Gaji dibayar" dan klik OK:

Kami beralih ke bookmark register yang muncul dan mengeluarkan 5.000 rubel:

Dengan demikian, kami tampaknya mengurangi 5.000 rubel per karyawan dari register untuk mencapai nol pada awal 2016.

Kami melakukan operasi dan menghasilkan kembali laporan universal:

Semuanya berhasil! Kami melihat bahwa operasi manual kami pada 31 Desember 2015 membawa sisanya menjadi nol dan gaji yang dibayarkan setelah akrual sama dengan yang diharapkan 43.500.

Bagus Dan sekarang kita akan memeriksa ini di lembar penggajian.

Tapi pertama-tama, saya ingin menarik perhatian Anda ke poin penting lain:

Harap dicatat bahwa saldo di awal dan di akhir pengelompokan "Karyawan" menunjukkan omong kosong. Ini bukan kesalahan sama sekali, itu adalah nuansa yang harus diperhitungkan terkait dengan fitur arsitektur 1s.

  Ingat. Dalam hal laporan universal ditampilkan dengan detail ke dokumen (pendaftar) - sisanya dengan pengelompokan akan menunjukkan omong kosong.

Jika kita membutuhkan keseimbangan dengan pengelompokan karyawan, kita harus terlebih dahulu menghapus indikator "Pencatat" yang kita tambahkan dari pengaturan.

Kami memutuskan untuk membereskan konfigurasi UT 11. Dan di sana ... Sisa-sisa barang tidak menyatu dengan sisa-sisa organisasi (beberapa organisasi digunakan), tetapi mereka tidak begitu dekat dengan pengiriman barang, dan perdagangan komisi digunakan bersamaan dengan perdagangan reguler. Singkatnya, semuanya begitu terabaikan sehingga lebih mudah untuk memulai dari awal, TETAPI ... Anda tidak dapat memulai dari awal - bundel dengan akuntansi perusahaan 3.0 (direktori, dokumen), dan di sana pelaporan telah dikirimkan. Kami memutuskan demikian, dalam pembukuan kami membuat pesanan secara terpisah, di UT secara terpisah. Khusus untuk UT, mereka memutuskan: segala sesuatu yang berkaitan dengan barang (barang di gudang, barang organisasi, banyak barang organisasi, ditambah register yang berkaitan dengan komisi) dibatalkan, maka kami membuat kedatangan fiktif (termasuk komisi), dan kami memperbaiki penyelesaian bersama dengan menyesuaikan penyelesaian bersama. Pada awalnya saya mulai menulis pemrosesan untuk register tertentu, ketika saya sedang menulis, saya berpikir tentang menulis waktu universal, hampir sama, tetapi itu akan berlaku untuk semua register sehingga saya tidak akan menulis ulang sepuluh kali kemudian. Ini juga harus cocok untuk Ritel 2, Konfigurasi terintegrasi dan lainnya untuk formulir yang dikelola. Diuji pada UT11.

Bagaimana cara menggunakan. Pertama, kita secara manual membuat dokumen kosong "penyesuaian daftar", mengatur tanggal dan waktu (saya menetapkan 23:59:59 pada akhir kuartal), sisa register akan dibawa ke posisi ini (posisi dokumen), secara umum, kita hanya memiliki posisi dari dokumen dan membutuhkannya Kemudian kita memilih register mana yang perlu kita nol dan klik "Formulir." Kami membuka penyesuaian, melihat, memeriksa register dengan bantuan laporan dan / atau laporan universal. Saldo ditutup di semua dimensi dan semua sumber daya. Juga dalam formulir terdapat pilihan berdasarkan organisasi dan gudang (atavisme dari versi asli, tetapi berfungsi) Saya tidak menambahkan pilihan lain (karena saya tidak membutuhkannya sama sekali), yang perlu Anda tambahkan sendiri, semuanya ditulis dengan jelas dalam modul, tetapi tidak Dia mulai berlaku karena, misalnya, jika suatu organisasi dipilih, maka pemilihan untuk Daftar Barang Organisasi akan berhasil, tetapi untuk Pendaftaran Barang di Gudang itu tidak (tidak ada pengukuran seperti itu), oleh karena itu menghilang tanpa seleksi.

Beberapa waktu telah berlalu ...

Versi baru dirilis, sekarang prosesnya telah belajar (biasanya memberikan kesalahan - yaitu, sebenarnya hanya bekerja dengan register saldo) untuk membalikkan gerakan register akumulasi terbalik. Selain itu, pergerakannya terbalik, mis. jika Anda melihat register, katakan, "Penjualan" di UT11, maka setelah membalikkan penjualan tidak akan muncul sama sekali, yaitu seolah-olah tidak ada penjualan sama sekali - omset secara keseluruhan untuk periode tersebut akan kosong. Sekali lagi - ternyata, misalnya, kami memiliki penjualan untuk periode 1-30 Januari, saya melakukan pembalikan pada tanggal 31, setelah itu jika saya melihat laporan dari 1 hingga 30 saya akan melihat penjualan, dari 31 hingga 31 saya akan melihat pembalikan, dari 1- 31 - acara kosong. Sebagai contoh, saya membalikkan gerakan register "Tunai" di UT11 dan Ritel 2.2 ketika saya harus memesan "Kasir" (50 akun yang mengerti).

Ya, saya lupa mengatakan, bidang "Tanggal Mulai" muncul - digunakan untuk mengatur tanggal mulai periode untuk register yang dapat dinegosiasikan (tentu saja, itu tidak berlaku untuk saldo), posisi dokumen "Penyesuaian Daftar" digunakan sebagai tanggal akhir periode (untuk register yang dapat dinegosiasikan) - yaitu. . adapun neraca saldo (saldo dihapus pada posisi dokumen). Untuk register yang dapat dinegosiasikan, "DateStart" dapat tetap kosong - dalam hal ini, dianggap sebagai tanggal paling awal yang dapat terjadi, dan untuk register yang dapat dinegosiasikan itu berarti bahwa semua pergerakan dibalik dari awal akuntansi untuk posisi dokumen "Koreksi Registrasi".

Berita baik - biaya poin telah berkurang.

Ada situasi ketika, ketika menghitung layanan dengan metode perhitungan "Menurut pembacaan meter", satu indikasi dimasukkan, dan ketika mengisi daya layanan, biayanya sama sekali berbeda. Situasi seperti itu dapat muncul dalam kasus di mana pengguna secara manual mengubah data dalam dokumen "Memasuki pembacaan meter" dan "Layanan pengisian daya". Pertimbangkan sebuah contoh.

• Kami memperkenalkan pembacaan meter untuk layanan Pasokan Air Panas untuk bulan Januari:

• Mari kita hitung layanannya:

Dalam hal ini, perhitungannya benar.

Untuk menyimpan konsumsi untuk perangkat pengukuran, register akumulasi "Perhitungan perangkat pengukuran" digunakan. Buka register ini menggunakan menu "Operasi - register Akumulasi - Perhitungan perangkat pengukuran." Register juga dapat dibuka dari dokumen "Memasukkan pembacaan meter" atau "Layanan pengisian daya" menggunakan tombol "Go - Perhitungan perangkat pengukuran".

Ditetapkan dalam daftar akumulasi pilihan untuk akun pribadi dan layanan:

Dapat dilihat dalam register bahwa pengeluaran dalam dokumen “Biaya layanan” untuk bulan Januari sesuai dengan indikasi yang dimasukkan oleh dokumen “Masukkan pembacaan meter” untuk bulan yang sama. Untuk perhitungan yang benar, laju aliran harus sesuai dengan indikasi yang dimasukkan di setiap bulan.

• Buka dokumen "Memasuki bacaan counter" untuk Januari dan secara manual ubah bacaan yang dimasukkan:

Pada saat yang sama, kami tidak akan mengisi ulang dokumen “Layanan Pengisian” untuk bulan Januari.

• Masukkan pembacaan meter untuk Februari:

• Mari kita hitung layanan untuk Februari:

Dapat dilihat bahwa pengeluaran yang salah masuk ke dalam dokumen. Buka daftar akumulasi "Perhitungan perangkat pengukuran" dan atur pilihan untuk akun pribadi dan layanan:

Register menunjukkan bahwa indikasi dan pengeluaran yang dimasukkan tidak sesuai satu sama lain.

Dalam contoh ini, Anda tentu saja dapat mengisi ulang dan mentransfer kembali dokumen "Layanan Pengisian", tetapi ini adalah contoh sederhana, dalam kenyataannya ada banyak dokumen, mengisi ulang hanya dapat memperburuk situasi.

Dalam hal ini, perlu untuk menggunakan pemrosesan "AOB_Reset Residu dari Daftar Akumulasi".

CATATAN: Anda disarankan untuk membuat cadangan infobase sebelum menggunakan pemrosesan.

Untuk memperbaiki situasi, kami akan melakukan tindakan berikut:

1.   Dalam mode "1C: Enterprise", kami membuka pemrosesan "AOB_Reset Residu dari Daftar Akumulasi" menggunakan menu "File - Open";

2.   Di bidang "Dokumen lalu lintas", pilih dokumen "Biaya layanan" untuk Januari.

CATATAN: dokumen dipilih sebelum dokumen di mana data yang benar harus diperoleh. Dalam hal ini, kami akan memperbaiki dokumen “Layanan Pengisian” untuk bulan Februari, oleh karena itu, dokumen “Layanan Pengisian” untuk bulan Januari dipilih sebagai dokumen perpindahan.

3.   Di bidang "Register zeroing" pilih register "Perhitungan perangkat pengukuran":

CATATAN: pemrosesan residu dimungkinkan dalam pemrosesan. Kriteria pemilihan dikonfigurasikan dalam tabel.

4. Klik tombol “Run”.
   Ketika tombol ini ditekan, data dalam register akumulasi "Penghitungan perangkat pengukuran" tidak akan berubah secara visual, tetapi saldo akan diatur ulang ke nol.

5. Kami mengisi ulang dokumen "Layanan Pengisian Daya" untuk bulan Februari:

Terlihat bahwa setelah menggunakan pemrosesan, perhitungan menjadi benar.

Nilai yang salah dalam register akumulasi "Penghitungan perangkat pengukuran" juga dapat dibentuk sebagai akibat dari perubahan data secara manual dalam dokumen "Layanan pengisian daya", atau memasukkan beberapa dokumen "Memasukkan pembacaan meter" atau "Layanan pengisian daya" untuk periode tersebut.