Perencanaan arus kas operasional atau cara membangun sistem pengendalian arus kas. Subsistem "aplikasi elektronik" untuk pengeluaran dana Aplikasi untuk pengeluaran dana 1c upp

1. Perkenalan

Perencanaan kas adalah salah satu tugas utama akuntansi manajemen, berbeda dengan akuntansi keuangan.

Tentu saja, terdapat perbedaan signifikan lainnya antara manajemen dan akuntansi (persyaratan yang berbeda untuk analisis, penilaian dan revaluasi aset/kewajiban, kebutuhan untuk membuat cadangan, dll.), namun kebutuhan untuk memecahkan masalah perencanaan adalah hal yang paling sulit. mereka.
Kompleksitas perencanaan tidak hanya terletak pada penyusunan rencana (menghitungnya, membentuknya sesuai dengan skenario yang berbeda), tetapi juga diperlukan:

Melakukan penjadwalan ulang;
Perbarui rencana, transfer penyesuaian ke periode berikutnya;
Melaksanakan rencana - analisis faktual.

Harus diakui bahwa di sebagian besar perusahaan (menggunakan 1C untuk otomatisasi), perencanaan tidak dilakukan dalam program.
“Kita harus menyiapkan akuntansi…” - begitulah argumen banyak orang.

Akuntansi perlu ditingkatkan, ya, tapi tidak dengan mengorbankan perencanaan.
Tentu saja mereka tetap melakukan perencanaan (tapi bukan di 1C, tapi di XLS). Dan tugas utama pertama (yang mereka coba selesaikan) adalah perencanaan kas.

(1) Strategis (penganggaran);
(2) Operasional.

Dan jika penganggaran (tentunya dengan pendekatan perencanaan top-down) bisa dilakukan dengan menggunakan XLS, maka perencanaan operasional tidak bisa dilakukan.
Intinya adalah paling sering minimal pengguna (1-2 orang) bekerja dengan tabel anggaran. Bagi sebagian besar perusahaan, jumlah item penganggaran dan analisis lainnya tidak begitu banyak. Artinya, semuanya bisa diproses secara manual di XLS.

Namun dalam hal perencanaan operasional d/s, situasinya berbeda. Artinya, seringkali terdapat sejumlah besar faktur yang harus dibayar, banyak pembayaran rutin, pembayaran yang diharapkan untuk pesanan pelanggan, dll.

Selain itu, semua ini dapat “diikat” ke sejumlah besar dokumen utama yang digunakan oleh berbagai pengguna program, penyesuaian dokumen, perubahan situasi, dll.

Perbedaan penting lainnya antara perencanaan operasional dan penganggaran adalah bahwa perencanaan operasional sering kali dilakukan dari bawah ke atas. Yaitu dari “Permintaan pengeluaran d/s” yang selalu diisi oleh pegawai departemen.

Oleh karena itu, permohonan ini perlu diproses tepat waktu, diterima/ditolak, “dijadwalkan” dan dibayar.

Total: perencanaan operasional untuk d/s adalah tugas perencanaan pertama, yang harus diotomatisasi dalam 1C untuk perusahaan mana pun.

Dan sebagai hasil perencanaan, departemen keuangan/perbendaharaan harus “melihat” dalam sistem:

Kapan, kepada siapa, dari rekening bank/kas mana, berapa jumlah yang harus dibayarkan;
Berapa saldo kas pada tanggal “ini dan itu”, dengan memperhitungkan saldo saat ini, pengeluaran yang direncanakan dan penerimaan kas. Yang disebut harus dihindari. "kesenjangan uang tunai"
Artinya, ada kebutuhan untuk bekerja dengan kalender pembayaran.
Hutang apa dengan pihak lawan yang akan terjadi tanggal yang ditentukan, dengan mempertimbangkan pembayaran yang direncanakan, penerimaan dan saldo penyelesaian bersama saat ini.
Artinya, ada kebutuhan untuk bekerja dengan kalender perhitungan.

Tujuan artikel ini – berbicara tentang kemungkinan mengotomatiskan perencanaan operasional untuk d/c. Pada saat yang sama, analisis komparatif dari 3 konfigurasi sirkulasi yang berbeda akan dilakukan (dua adalah standar dari 1C, satu khusus dari perusahaan wiseadvice).

Masing-masing konfigurasi dapat digunakan untuk memecahkan masalah perencanaan operasional, namun pilihan yang seimbang harus dibuat berdasarkan ruang lingkup dan skala proyek Anda.

2. Fitur soft starter 1.3

Saat ini 1C belum merilis UPP edisi baru yang telah lama ditunggu-tunggu (revisi 2). Dan karena alasan ini, kami akan fokus pada apa yang tersedia - subsistem yang sesuai dari SCP 1.3:

Perlu dicatat bahwa subsistem “Permintaan Pengeluaran Tunai” diperbarui dalam konfigurasinya relatif baru (2011). Dan sebagai hasilnya, dalam mode antarmuka terkelola, item “Permintaan pengeluaran d/s/” muncul di panel bagian.

Jika Anda mencoba dalam konfigurasi standar, dalam mode file, untuk membuka formulir dokumen "Permintaan Pengeluaran D/s" (alias ZRDS), maka kesalahan segera muncul untuk variabel "Nilai Global" dari modul umum "Bekerja dengan Variabel Umum”.

Namun kesalahan tersebut dapat diperbaiki, seperti yang mereka katakan: “sedimennya tetap ada.” Artinya, terdapat cukup “kekasaran” pada subsistem UPP ZRDS.
Kemampuan untuk membuat dokumen ZRDS melalui browser WEB memang berguna, namun dalam praktiknya Anda harus memikirkan dengan hati-hati tentang penyederhanaan dan ergonomis bentuk standar dokumen. Ini sangat penting terutama untuk perangkat seluler.

Namun untuk kalender pembayaran, dalam mode klien tipis, jarak jauh melalui browser WEB, dll. kamu tidak akan bisa menggunakannya. Alasannya adalah subsistem Cash Management sudah lama tidak diperbarui dan khususnya laporan Kalender Pembayaran tidak dibangun di atas sistem komposisi data. Oleh karena itu, laporan ini tidak dapat digunakan di klien tipis; tidak ada kemungkinan untuk membuat pengaturan khusus untuknya.

Saat bekerja dengan ZRDS, peraturan untuk koordinasi dan persetujuan aplikasi menempati tempat penting. Tergantung pada struktur organisasi perusahaan dan fitur bisnis lainnya, prosedur internal untuk menyetujui aplikasi (peraturan persetujuan) bisa sangat rumit (multi-tahap, variabel, dll.). Jadi ini bukanlah tugas yang mudah untuk otomatisasi.

Pada UPP diterapkan subsistem koordinasi dan persetujuan. Ini memberikan pengaturan yang cukup fleksibel.

Persetujuan adalah penegasan perlunya membayar permohonan. Biasanya, persetujuan harus melalui kepala departemen, manajer, dan penanggung jawab perusahaan lainnya.
Persetujuan merupakan konfirmasi akhir (oleh Bendahara) bahwa permohonan akan dibayar. Dalam hal ini, tanggal pembayaran dan rekening bank/kantor kas tempat pembayaran akan dilakukan harus ditentukan. Dengan demikian, pembayarannya masuk dalam rencana operasional (kalender pembayaran).

Perlu dicatat bahwa sejumlah aspek fungsionalitas standar soft starter tidak menyediakan apa yang diperlukan untuk implementasi subsistem yang sebenarnya.
Saya akan menulis tentang "momen" ini nanti, tetapi untuk saat ini mari kita lihat fungsionalitas apa yang disediakan oleh konfigurasi pada umumnya.

Anda dapat mengaktifkan penggunaan mekanisme persetujuan aplikasi secara terpisah untuk setiap organisasi.

Dimungkinkan untuk mengkonfigurasi urutan aplikasi melalui rute dan hierarki rute.

Perlu dicatat bahwa hierarki dalam direktori departemen tidak diperhitungkan dalam mekanisme perutean aplikasi.
Penting juga untuk membatalkan koordinasi dan persetujuan yang dibangun secara teknis tanpa menggunakan mekanisme proses bisnis.

Pada setiap titik, Anda dapat menentukan satu/beberapa pengguna yang akan tersedia persetujuan aplikasinya. Artinya, permohonan dapat disetujui oleh salah satu dari mereka (siapa pun yang berhasil melakukannya terlebih dahulu).

Untuk setiap departemen, Anda dapat menetapkan titik rute persetujuan yang sesuai. Intinya adalah ini: saat mengisi aplikasi (ZRDS), Distrik Federal Pusat (divisi) harus ditunjukkan. Dan tergantung pada divisi yang ditentukan, UPP “menemukan” titik persetujuan yang sesuai dan “mengirimkan” permohonan persetujuan ke titik ini.

Dimungkinkan juga untuk tidak menentukan departemen saat menyiapkan rute persetujuan. Dalam hal ini, titik koordinasi tersebut akan “diterapkan” pada semua CFD yang titik rutenya tidak disebutkan secara spesifik.

Persetujuan itu sendiri dilakukan menggunakan pemrosesan khusus “Persetujuan Aplikasi”

Analisis rencana ketersediaan dana, jadwal pembayaran dan pelacakan kesenjangan kas dilakukan dalam laporan “Kalender Pembayaran”.

Selain rencana konsumsi d/s (ZRDS), Anda juga dapat memperhitungkan rencana penerimaan d/s. Untuk tujuan ini, direncanakan untuk menyusun dokumen khusus “Rencana penerimaan pendapatan”.

Perlu dicatat bahwa meskipun dokumen “Rencana penerimaan d/c” memiliki status (disiapkan, disepakati, dll.), tidak ada peluang untuk mengoordinasikan dokumen ini (serta ZRDS). Artinya, mengubah status dokumen hanya dapat dilakukan di “ kontrol manual».

Dan dalam UPP dimungkinkan untuk memperhitungkan rencana penerimaan uang tunai dari pembeli tanpa menyiapkan dokumen “Rencana penerimaan uang tunai”.

Artinya, jika “Pesanan Pelanggan” dikeluarkan untuk pembeli, maka dalam laporan terpisah “Kalender pembayaran dengan mempertimbangkan pesanan” tanda terima yang direncanakan ini dapat dilihat.

Selain laporan Kalender Pembayaran, terdapat laporan Analisis Ketersediaan Tunai.

Pada saat yang sama, dimungkinkan untuk mencadangkan d/s (berdasarkan permohonan pengeluaran) atau mengajukan permohonan terhadap pendapatan yang direncanakan.

Ada juga fungsi untuk menutup ZRDS dan pendapatan yang direncanakan dari d/s. Untuk tujuan ini, dalam mode “klien reguler”, dokumen “Penutupan aplikasi pengeluaran/penerimaan” disediakan.

Namun, fungsi ini juga tidak didukung dalam mode klien tipis/web.
Di sini Anda perlu memahami bahwa teknik “hardreservasi” sangat terkait dengan kronologi pemasukan dokumen, dan hal ini membuat penyesuaian dan penjadwalan ulang menjadi sulit.

Oleh karena itu, fungsi tersebut dibiarkan di UPP dan bukan sebagai “warisan masa lalu”, dan kalender pembayaran harus digunakan untuk menganalisis ketersediaan d/s.

Jadi, kami telah mempertimbangkan fungsionalitas soft starter dan sekarang saya akan mencantumkan aspek-aspek konfigurasi standar yang dalam praktiknya, pada proyek, harus dimodifikasi:

Menurut dokumen “Permohonan pengeluaran d/s”:
1. Dalam dokumen tersebut, Anda dapat menunjukkan "Divisi" (omong-omong, dalam konfigurasinya ditunjuk sebagai Distrik Federal Pusat - pusat tanggung jawab keuangan). Namun sangat mungkin permohonan diajukan dari satu divisi (CFD), dan dalam hal ini biayanya perlu diatribusikan/didistribusikan lebih lanjut ke divisi lain (CFD - pusat pengelolaan keuangan).
  Kemampuan untuk menentukan fungsi digital, dll. - absen.
  Tidak ada kemungkinan untuk mengubah rute atau mengalihkan aplikasi ke rute lain.

Tidak ada kemungkinan untuk merencanakan transfer uang tunai antar rekening giro, dari rekening ke meja kas, dll.

Proses perjanjian:
1. ZRDS dapat dikoordinasikan, tetapi rencana penerimaan d/s tidak dapat dikoordinasikan.
2. Dalam praktiknya, perlu dilakukan persetujuan terhadap pegawai lain. Pada saat yang sama, sistem juga perlu mencatat informasi tentang “siapa yang melakukan persetujuan dan untuk siapa.”
  Pilihan untuk memasang beberapa kemungkinan pelaksana pada satu titik koordinasi seringkali kurang tepat, sehingga pelaksana tersebut dapat ditunjuk pada tahap koordinasi lainnya. Akibatnya, semua ini akan mengarah pada fakta bahwa karyawan tersebut akan secara bersamaan memiliki tugas persetujuan utama dan tidak langsung dalam daftar permintaan persetujuan. Tentu saja hal ini membingungkan pengguna dan tidak nyaman.
  Ringkasnya, kemampuan berkoordinasi untuk pemain lain, kemampuan menunjukkan siapa yang berhak berkoordinasi untuk siapa yang tidak hadir.
3. Dalam proses persetujuan aplikasi, ketika aplikasi diteruskan untuk disetujui ke aplikasi berikutnya di sepanjang rute, fungsi menginformasikan secara otomatis (melalui email) pelaksana berikutnya, serta penulis aplikasi, sangat dibutuhkan. .
4. Jika pembuat aplikasi sudah bertanggung jawab atas koordinasi/persetujuan (di setiap tahap rute!), maka cukup logis jika program secara otomatis “memperpendek” rute, mengarahkan aplikasi ke level tertinggi yang tersedia. Namun hal ini tidak diatur dalam UPP.
- Semua persyaratan di atas, meskipun tidak termasuk dalam konfigurasi standar, tetap ada.

Laporan, hak akses.
1. Terdapat tuntutan akan kemungkinan pembatasan akses terhadap aplikasi hanya oleh penulis/pelaksana (koordinator); menurut departemen yang tersedia bagi pengguna.
2. Tidak ada pelaporan pemantauan (berdasarkan hari dan interval) utang aktual dan terencana. Hal ini berlaku bagi pembeli dan pemasok.
3. Pelaporan dan beberapa fungsi tidak cocok untuk bekerja dalam mode klien tipis/web.
Akuntansi untuk perjanjian dan kontrak reguler.
1. Seringkali ada situasi ketika pemasok perlu membayar secara teratur. Misalnya pembayaran sewa, dll.
  UPP tidak secara otomatis mencerminkannya di kalender pembayaran, dll. pengeluaran yang akan datang ini. Artinya, pembayaran tersebut perlu dilacak secara manual dan mengisi permintaan pembayaran, yang merepotkan dan memakan waktu.
2. Perjanjian dengan pembeli dan pemasok dapat menetapkan ketentuan persentase pembayaran di muka, syarat pembayaran, dll.
  UPP tidak secara otomatis mencatat semua informasi ini dan (sebagai akibatnya) secara otomatis mencerminkannya dalam kalender pembayaran.

3. Fitur UT 11.1

Dengan dirilisnya konfigurasi baru “Manajemen Perdagangan Rev.11”, banyak fitur baru dan berguna yang muncul untuk tugas perencanaan operasional dan pengendalian keuangan.
Mungkin hal yang paling signifikan pada bagian UT11 ini (dibandingkan dengan UPP 1.3) adalah mekanisme akuntansi jadwal pembayaran. Mekanisme ini “menutup” apa yang sangat kurang – otomatisasi perencanaan/akuntansi berdasarkan perjanjian dan kontrak reguler.

Jadi, di UT11 Anda tidak perlu membuat dokumen sama sekali (bila tidak diperlukan tentunya) untuk perencanaan pengeluaran dan penerimaan, sekaligus kalender pembayaran akan terbentuk secara normal.

Anda dapat membatalkan bahwa "pengaturan standar" dari laporan "Kalender pembayaran" tidak benar-benar memenuhi harapan (dengan demikian, kalender tidak ditampilkan), namun dalam mode pengguna Anda dapat menambahkan pengelompokan berdasarkan "tanggal pembayaran" dan laporan akan dihasilkan dalam bentuk biasa.

Fungsi laporan telah berkembang pesat (dibandingkan dengan SCP 1.3) karena penggunaan sistem komposisi data. Sekarang, laporan dapat dibuat di klien tipis/web, disimpan dalam database dan ditetapkan ke pengguna berbeda dengan pengaturan yang mereka perlukan.

Selain merencanakan konsumsi dan penerimaan barang-barang rumah tangga, UT11 kini memiliki fungsi merencanakan pergerakan barang-barang rumah tangga. Untuk tujuan ini, Anda dapat membuat dokumen “Perintah relokasi rumah tangga”.

Dibandingkan dengan UPP 1.3 untuk dokumen “Permohonan pengeluaran tunai”, jumlah jenis transaksi bisnis yang dipertimbangkan mengalami peningkatan:

Sekarang dimungkinkan untuk menyetujui dokumen “Permohonan pengeluaran dana” dan perintah lainnya:

Untuk menganalisis utang berdasarkan interval/tenggat waktu, laporan “Piutang” disediakan. Jika perlu, Anda juga bisa membuat kalender utang. Untuk melakukan ini, dalam mode khusus, Anda harus menambahkan pengelompokan berdasarkan tanggal pembayaran.

Sayangnya, UT11 (seperti sebelumnya) tidak menyediakan kemampuan untuk menganalisis kalender utang pemasok. Namun, UT11 perlu diselesaikan untuk tugas ini.

Untuk meringkas: solusi metodologis baru "1C", bersama dengan kemampuan platform 8.2, memberikan dasar yang baik untuk mengotomatisasi tugas perencanaan operasional dan pengendalian d/s.

Namun pada saat yang sama, Anda perlu memahami bahwa konfigurasi UT11 belum lengkap, solusi siap pakai untuk otomatisasi perbendaharaan dan perencanaan keuangan.

Pertama, UT11 menerapkan mekanisme yang sangat sederhana untuk mengoordinasikan/menyetujui permintaan pengeluaran dan dokumen perencanaan d/s lainnya. Artinya, tidak ada mekanisme perutean, proses persetujuan aplikasi direduksi menjadi sekadar pengaturan status.
Kedua, UT11 tidak memiliki subsistem penganggaran dan (akibatnya) tidak ada fungsi untuk memantau aplikasi anggaran yang direncanakan.

4. Fitur WA: Pemodal

Secara historis, konfigurasi WA:Financier dikembangkan berdasarkan produk Manajemen Treasury.

Dan pada saat yang sama, solusi “Pemodal” baru dari WiseAdvice juga mencakup:

Subsistem perencanaan anggaran;
Subsistem manajemen kontrak;
Subsistem pembentukan dan akuntansi pembayaran aktual;
Mekanisme yang fleksibel dan dapat disesuaikan untuk menghasilkan/mengisi dokumen berdasarkan templat;
Subsistem integrasi bank klien yang fleksibel dan dapat disesuaikan.

Mari kita pertimbangkan fungsi utama "WA: Financier" dalam hal perbendaharaan - mulai dari memperhitungkan ketentuan kontrak hingga membuat kalender pembayaran.

Selama proses persetujuan permohonan, Anda tidak hanya dapat menyetujui/menolak dokumen (seperti yang dilakukan di UPP), tetapi fungsi lain juga tersedia: misalnya mengirim dokumen untuk direvisi, atau meminta informasi tambahan. informasi.
Seluruh proses ini dilakukan secara otomatis; oleh karena itu, pelaporan diberikan mengenai status pemrosesan persetujuan dokumen.

5. Hasil

Kesimpulan:

Untuk mengotomatiskan pekerjaan departemen keuangan, perbendaharaan, organisasi dengan struktur organisasi yang kompleks. struktur solusi yang paling cocok adalah "WA: Pemodal".
Solusi ini telah berkembang dan berkembang sejak lama, sehingga memenuhi spesifikasi dan kebutuhan berbagai lembaga keuangan. departemen dan perbendaharaan. Total biaya tenaga kerja untuk mengembangkan solusi berjumlah lebih dari 5.000 orang/jam.
Keuntungan dari solusi WA: Financier adalah fungsionalitasnya yang canggih dan sejumlah besar mekanisme pengaturan program. Dengan demikian, implementasi solusi ini dimungkinkan waktu singkat(disebut “implementasi out-of-the-box”), tanpa tambahan. pengembangan, pemrograman, dll.
Karena solusinya berisi mekanisme pertukaran dua arah dengan semua konfigurasi standar utama, integrasi ke dalam struktur yang ada (pertukaran data dengan database UT, UPP, Kompleksnaya, Bukh) tidak akan sulit.
Untuk mengotomatisasi departemen keuangan/perbendaharaan sebagai bagian dari proyek otomasi yang komprehensif solusi terbaik adalah berdasarkan UPP.
Pada saat yang sama, Anda perlu memahami bahwa fungsi soft starter akan memerlukan perbaikan.
Spesifik, persyaratan keuangan. departemen dan perbendaharaan tidak tertanam dalam UPP sedalam yang dilakukan dalam solusi khusus dan terpisah.
Oleh karena itu, penerapan SCP untuk tugas-tugas ini hanya boleh dilakukan sebagai bagian dari proyek otomasi.
Untuk organisasi besar, untuk otomatisasi departemen keuangan UT11 tidak cocok.
Dalam keputusan ini, pertama, belum adanya mekanisme koordinasi/persetujuan dokumen perencanaan.
Kedua, tidak adanya subsistem penganggaran dan kontrol atas pelaksanaan anggaran selama perencanaan operasional.
Namun, UT11 sempurna untuk otomatisasi (termasuk perencanaan operasional d/c) keuangan kecil departemen perusahaan.

Dokumen “Permintaan pengeluaran dana” dimaksudkan untuk perencanaan dan koordinasi pembayaran.
Dokumen “Permintaan pengeluaran DS” dapat dibuat dengan membuka bagian “Perbendaharaan” - “Perencanaan dan pengendalian dana” - “Permintaan pengeluaran DS” - Buat.
Dokumen "Permintaan pengeluaran DS" memiliki beberapa jenis operasi yang dipilih selama pembuatan. Setiap jenis aplikasi dimaksudkan untuk mencerminkan berbagai transaksi bisnis, yang masing-masing akan dijelaskan dalam instruksi ini.
Dokumen “Permohonan pengeluaran DS” yang dibuat dikumpulkan dan disepakati menggunakan dokumen “Daftar Pembayaran”. Setelah disetujui, berdasarkan aplikasi, dokumen “Penghapusan DS non-tunai” dibuat secara otomatis, yang diunggah ke bank klien untuk pembayaran oleh bank.
Berikut ini adalah contoh pelaksanaan dokumen “Permohonan pengeluaran DS” untuk setiap jenis operasi.

Pembayaran ke pemasok
Untuk memproses transaksi pembayaran ke pemasok, jenis transaksi dari dokumen "Permintaan pengeluaran DS" dimaksudkan - "Pembayaran ke pemasok".
Pada dokumen baru “Permohonan pengeluaran DS”, kolom yang harus diisi untuk memproses dokumen ditandai dengan warna merah. Dokumen dibuat dalam status “Tidak disetujui”; status berubah secara otomatis selama persetujuan daftar pembayaran. Prioritas aplikasi saat pembuatan secara otomatis diatur ke “Medium”.

Gambar 1. Formulir dokumen “Permohonan pengeluaran DS”, jenis operasi “Pembayaran ke pemasok” (tidak diisi)
Rincian dokumen “Permohonan belanja DS” harus diisi sebagai berikut:
Tab dasar
Nomor– dihasilkan secara otomatis selama eksekusi, tidak dapat diatur secara manual.
tanggal– saat dibuat, tanggal saat ini ditetapkan.
Organisasi– Anda harus memilih dari daftar organisasi yang diusulkan menggunakan tombol, atau dengan memasukkan nama di bidang, nilai yang diperlukan akan ditawarkan untuk dipilih.
Bagian– dari direktori “Struktur Perusahaan”, Anda harus memilih divisi di mana pembayaran harus dilakukan.
Pemohon– secara default, pengguna sistem saat ini yang membuat aplikasi ditunjukkan.
Perencanaan– pengaturan default adalah “Dalam mata uang pembayaran” dan tidak dapat diubah.
Jumlah– menunjukkan jumlah pembayaran yang diperlukan.
Mata uang– menunjukkan mata uang pembayaran yang diperlukan.
Operasi– jenis transaksi dokumen “Permohonan pengeluaran DS” yang dipilih selama pembuatan tercermin
tanggal pembayaran– menunjukkan tanggal pembayaran kepada pemasok harus dijadwalkan.
Formulir pembayaran– pengaturan default adalah “Dalam bentuk apa pun” dan tidak dapat diubah.
Penerima– menunjukkan pemasok dari direktori “Counterparty” kepada siapa pembayaran harus dilakukan.
Rekening penerima– ketika memilih “Penerima”, akun penerima secara otomatis diatur; jika perlu, jika akun yang berbeda ditunjukkan pada “Faktur pembayaran” yang disediakan oleh pemasok, Anda harus memilih yang diperlukan dari direktori “Rekening Bank”.
Melewati batas– jika sistem memelihara sistem untuk membatasi pengeluaran tunai dalam konteks cabang dan item arus kas, jika jumlah pembayaran yang dilakukan sebelumnya tidak termasuk dalam batas tersebut, saat memposting dokumen, pengguna akan menerima pesan kesalahan dan lamarannya tidak akan diproses.

Gambar 2. Contoh kesalahan saat melakukan pemesanan yang tidak direncanakan batasnya.
Untuk melakukan pemesanan melebihi batas, Anda harus menyetel tanda “Melebihi Batas”.
Transfer ke anggaran– tanda ini disetel jika pembayarannya adalah transfer ke anggaran. Menyetel bendera memungkinkan Anda memasukkan nilai KBK, OKTMO, dll. yang diperlukan untuk pembayaran ke anggaran.

Gambar 3. Contoh pengaturan bendera “Transfer ke anggaran”.
UIP– pengidentifikasi pembayaran unik, ditunjukkan hanya jika hal ini ditentukan dalam perjanjian dengan penerima pembayaran.
Tujuan pembayaran- program ini menyediakan beberapa opsi untuk pengisian otomatis tujuan pembayaran menggunakan tombol "Sisipkan".

Gambar 4. Opsi untuk mengisi otomatis kolom “Tujuan pembayaran”.
Daftar dokumen, termasuk. TONG- akan menampilkan informasi tentang objek penyelesaian dari tab “dekripsi pembayaran”.

Termasuk PPN (18%) (untuk seluruh jumlah), termasuk. PPN (10%) (untuk seluruh jumlah), Tidak termasuk pajak (PPN)- Informasi PPN akan ditambahkan ke teks yang dimasukkan.

SMS dari rekening bank penerima- memasukkan teks yang ditentukan dalam bidang "Teks tujuan pembayaran" dari kartu akun rekanan.

Gambar 5. Contoh pengisian tab “Dasar”.

Tab Detail Pembayaran
Tab “Decoding Pembayaran” memberikan informasi rinci tentang pembayaran dan penyelesaian bersama dengan penerima pembayaran.
Pembayaran dapat dimasukkan sebagai daftar, mis. mendistribusikan ke beberapa objek perhitungan, atau tanpa pemisahan, dimungkinkan untuk memilih hanya satu objek perhitungan.
Pembayaran dari dana pertahanan negara– bendera dipasang hanya jika pembayaran dilakukan dalam kerangka perintah pertahanan pemerintah, dalam kasus lain bendera tidak dipasang.
Objek perhitungan– sebagai objek penyelesaian, Anda dapat menentukan “Perjanjian dengan pihak lawan” (untuk jenis operasi dokumen aplikasi ini, jika dipilih, tersedia perjanjian dengan jenis hubungan “Dengan pemasok/pelaksana”) atau dokumen yang disepakati “Pesanan kepada pemasok”.
Pemberi
Jumlah penyelesaian bersama– diatur secara otomatis saat memposting dokumen.
Mata uang– diatur secara otomatis saat memilih objek perhitungan.
artikel DDS– menunjukkan item arus kas yang sesuai dengan jenis pembayaran.
Komentar– jika perlu, tunjukkan komentar pada dekripsi pembayaran.

Gambar 6. Contoh pengisian tab “Payment Decoding”.
Tab distribusi akun
Pada tab “Distribusi ke Rekening”, rekening bank organisasi tempat dana harus didebit ditunjukkan. Jumlah dan tanggal pembayaran diatur secara otomatis sesuai dengan data yang ditentukan pada tab “Dasar”.

Gambar 7. Contoh pengisian tab “Distribusi berdasarkan Akun”.

Gambar 8. Contoh dokumen “Penghapusan DS non tunai” yang dibuat secara otomatis untuk aplikasi dengan jenis transaksi “Pembayaran ke pemasok”.

Pengembalian pembayaran ke klien
Untuk memproses transaksi pengembalian dana ke klien, jenis transaksi dalam dokumen "Permohonan pembelanjaan DS" dimaksudkan - "Pengembalian pembayaran ke klien".
Susunan rincian dokumen “Permohonan pengeluaran DS” dengan jenis operasi ini sama dengan susunan rincian pada saat membayar pemasok, perbedaannya hanya pada jenis rekanan dan objek penyelesaian.

Gambar 9. Bentuk dokumen “Permohonan pembelanjaan DS”, jenis operasi “Pengembalian pembayaran ke klien”
Penerima– menunjukkan klien dari direktori “Counterparty” yang perlu melakukan pembayaran.
Objek perhitungan– sebagai objek penyelesaian, Anda dapat menentukan “Perjanjian dengan pihak lawan” (untuk jenis operasi dokumen aplikasi ini, saat memilih, tersedia perjanjian dengan jenis hubungan “Dengan pembeli/pelanggan”) atau dokumen yang disepakati “ Pesanan pelanggan".
Pembeli– kolom diisi secara otomatis saat memilih objek perhitungan. Elemen direktori "Mitra" yang ditentukan dalam bidang yang sesuai dari objek perhitungan telah diinstal.

Gambar 10. Contoh pengisian tab “Payment Decoding”.
Setelah melewati seluruh tahapan persetujuan, dokumen “Permohonan pengeluaran DS” akan diberi status “Untuk pembayaran” dan dokumen “Penghapusan DS nontunai” akan dibuat secara otomatis.

Gambar 11. Contoh dokumen “Penghapusan DS non tunai” yang dibuat secara otomatis berdasarkan aplikasi dengan jenis operasi “Pengembalian pembayaran ke klien”.

Penerbitan kepada yang bertanggung jawab
Untuk meresmikan transaksi pengeluaran dana ke rekening bank orang yang bertanggung jawab, jenis transaksi dari dokumen "Permohonan pengeluaran DS" - "Penerbitan kepada orang yang bertanggung jawab" dimaksudkan.

Gambar 12. Bentuk dokumen “Permohonan pengeluaran DS”, jenis operasi “Penerbitan ke akuntabel”
Orang yang bertanggung jawab– karyawan ditunjukkan dari direktori “ Individu”, kepada siapa uang itu perlu ditransfer.
Laporan– dari daftar periode yang diusulkan, perlu untuk menunjukkan periode sampai akuntan perlu melaporkan jumlah yang diterima.

Gambar 13. Contoh pengisian tab “Payment Decoding”.
Setelah melewati seluruh tahapan persetujuan, dokumen “Permohonan pengeluaran DS” akan diberi status “Untuk pembayaran” dan dokumen “Penghapusan DS nontunai” akan dibuat secara otomatis.

Gambar 14. Contoh dokumen “Penghapusan DS non tunai” yang dibuat secara otomatis berdasarkan aplikasi dengan jenis operasi “Penerbitan ke penanggung jawab”.

Kondisi penting bagi keberadaan efektif suatu perusahaan dalam lingkungan persaingan modern adalah terciptanya mekanisme manajemen yang efektif Arus kas memastikan terciptanya informasi yang cepat dan andal, pengaturan penyelesaian bersama, meningkatkan disiplin pembayaran dan, pada akhirnya, mempercepat perputaran uang.

Konfigurasi tersebut berisi alat untuk pengelolaan kas perusahaan otomatis, yang menjalankan dua fungsi utama:

akuntansi operasional pergerakan aktual dana perusahaan pada rekening giro dan meja kas;
perencanaan operasional penerimaan dan pengeluaran kas perusahaan.

Perencanaan umum pengeluaran dan penerimaan dana suatu perusahaan dilakukan dalam kerangka penganggaran. Rencana keuangan yang sedang disusun - anggaran - bertindak sebagai seperangkat pedoman dan batasan untuk subsistem pengelolaan kas.

Namun dalam kerangka fungsi pengelolaan kas, rencana keuangan operasional dipertahankan - kalender pembayaran. Masuk akal untuk membuat kalender pembayaran beberapa hari sebelumnya.

Kalender pembayaran merupakan kumpulan permintaan pengeluaran dana dan rencana penerimaan kas. Kalender pembayaran dikompilasi dengan perincian hingga ke tempat penyimpanan dana - rekening bank dan meja kas perusahaan. Saat menyusun kalender pembayaran, kelayakannya diperiksa secara otomatis - kecukupan cadangan kas di tempat penyimpanannya.

Pembagian fungsi perencanaan keuangan menjadi dua subsistem konfigurasi - subsistem penganggaran dan subsistem pengelolaan kas - sesuai dengan pembagian fungsi manajemen keuangan antara berbagai departemen dan karyawan perusahaan. Jika anggaran dibuat oleh jasa keuangan, maka permintaan dana pembelanjaan dihasilkan oleh karyawan dan departemen yang berinteraksi langsung dengan rekanan perusahaan.

Dalam konfigurasi, dokumen moneter dihasilkan (perintah pembayaran, penerimaan kas dan perintah debit, dll.), interaksi dengan program perbankan khusus seperti "Klien Bank" dipastikan, arus keuangan dikendalikan, dan ketersediaan dana di tempat penyimpanan adalah dipantau. Kemungkinan pembayaran tunai dalam mata uang asing disediakan.

Dokumen “Permintaan pengeluaran dana” dimaksudkan untuk mencatat keputusan melakukan pembayaran tunai atau non tunai (kelompok pembayaran) atau memindahkan dana. Rincian dokumen dan tata cara penggunaannya pada dasarnya mirip dengan dokumen “Perintah pembayaran (keluar)” dan “Perintah pengeluaran tunai”.

Parameter reservasi dan penempatan dapat diisi secara otomatis. Untuk tujuan ini, dokumen tersebut menyediakan bendera dan "Penempatan otomatis".

Jika tanda ini disetel, maka kolom “Penempatan” dapat terisi secara otomatis saat Anda mengklik tombol "Isi dan Posting".

Skema penempatan otomatis dan manual dapat digabungkan. Saat bendera dipasang "Reservasi otomatis" Dan "Penempatan otomatis" Anda dapat secara manual menentukan opsi penempatan untuk sebagian dari jumlah aplikasi. Kemudian ketika Anda menekan tombol "Isi dan Posting" Akan ada penempatan otomatis hanya untuk jumlah yang tersisa.

Ketika jenis operasi diatur ke " Pembayaran ke pemasok" atau " Pengembalian dana ke pembeli" perubahan dilakukan pada penyelesaian operasional dengan pihak lawan.

Berdasarkan dokumen “Permohonan pengeluaran dana”, dokumen pembayaran bank dan tunai dapat dimasukkan. Dokumen-dokumen tersebut memberikan persyaratan “ Aplikasi", yang diisi saat Anda mengetik berdasarkan itu, atau dapat diisi secara manual. Saat memposting dokumen pembayaran dengan aplikasi tertentu untuk membelanjakan dana, kesesuaian jumlah dokumen dengan saldo pembayaran terutang saat ini untuk aplikasi ini diperiksa.

Saat mengatur hak tambahan, dimungkinkan untuk melarang pengguna memproses dokumen pembayaran tanpa menunjukkan aplikasi untuk membelanjakan dana.

Dokumen “Permintaan Pengeluaran Dana” juga dapat berfungsi sebagai penghubung antara subsistem pengelolaan kas dan subsistem penganggaran. Untuk tujuan ini, aplikasi menyediakan blok rincian yang mirip dengan dokumen “Operasi Anggaran” (skenario perencanaan, item turnover, distrik keuangan pusat, proyek, dll.). Dengan menggunakan perincian yang ditentukan, saat mengajukan permohonan, kepatuhan jumlah total dana yang disetujui untuk dibelanjakan dengan nilai batas yang ditetapkan sebelumnya dipantau.

Fitur bekerja dengan aplikasi saat menggunakan mekanisme persetujuan aplikasi

Mekanisme persetujuan permohonan digunakan secara opsional: untuk daftar organisasi.

Saat menggunakan mekanisme pencocokan aplikasi, fitur-fitur berikut muncul:

Jika permohonan tidak menunjukkan suatu organisasi, permohonan ini tidak ikut serta dalam persetujuan

Jalur persetujuan permohonan ditentukan sesuai dengan pengaturan tergantung Divisi yang ditentukan dalam permohonan.

Jika permohonan belum melewati jalur persetujuan (status permohonan tidak “Disetujui”), dokumen pembayaran tidak dapat diterbitkan atas dasar tersebut.

Jika permohonan mulai melalui jalur persetujuan, maka permohonan dapat diubah

Pengguna yang permohonannya sedang disetujui

Pengguna menyetujui aplikasi pada tahap persetujuan yang lebih tinggi
Pengguna lain tidak dapat mengubah aplikasi.

Jika pesanan dalam keadaan “Disetujui”, maka tidak dapat diubah

Apabila permohonan memasuki keadaan “Ditolak”, maka permohonan dibatalkan

Status aplikasi saat ini ada dalam daftar aplikasi

status ditampilkan dalam kolom terpisah

Pengelompokan berdasarkan status pesanan digunakan

aplikasi disorot dengan warna latar belakang
- ditolak - merah muda

Pada bagian kedua artikel, kita akan membahas prinsip pembuatan “Permintaan pengeluaran dana”, meneruskannya melalui jalur persetujuan dan mengeluarkan dana sesuai dengan aplikasi yang dibuat.
Mari kita lihat sebuah contoh:

Akuntan pengadaan mengajukan permintaan pengeluaran dana untuk melakukan pembayaran di muka kepada pemasok IP Dobronravov untuk penyediaan bahan;
CFO harus meninjau dan menyetujui permohonan;
Berdasarkan permohonan yang disetujui, akuntan pengadaan membuat pesanan penerimaan kas (tanpa tanda “Dibayar”, tetapi dengan tanda “Cermin dalam akuntansi operasional”);
Kasir senior, setelah memeriksa pesanan penerimaan kas, mengeluarkan dana (dan menandai dokumen tersebut sebagai “Dibayar”);
Akuntan transaksi tunai memeriksa pesanan penerimaan kas (mencentang kotak untuk refleksi dalam catatan akuntansi dan akuntansi pajak sehingga entri akuntansi dan akuntansi pajak dihasilkan).

Untuk mempermudah dalam merefleksikan transaksi, mari kita alihkan antarmuka ke “Manajemen Kas”.
Sebelum Anda mulai bekerja dengan aplikasi pengeluaran dana, Anda harus memasukkan semuanya informasi latar belakang. Hal pertama yang perlu Anda isi adalah daftar informasi “Pengaturan untuk menyetujui aplikasi pengeluaran dana.” Dalam “Menyiapkan persetujuan aplikasi”, organisasi yang menggunakan mekanisme ini dan tanggal mulai penggunaan mekanisme persetujuan ditunjukkan. Pengaturan ini diperlukan agar program dapat menentukan bahwa organisasi StroyTorg LLC akan menggunakan mekanisme untuk menyetujui permintaan pengeluaran dana mulai 01/01/2013.

Rute koordinasi juga perlu dikonfigurasi (Gbr. 2). Pengaturan ini ditunjukkan dalam daftar informasi "Pengaturan untuk memulai rute persetujuan": korespondensi rute persetujuan ke departemen ditentukan. Jalur persetujuan (direktori “Rute Persetujuan”) menunjukkan tahapan dan daftar orang yang memberikan persetujuan pada tahap ini. Dalam contoh kita, aplikasi yang dibuat harus melalui satu tahap persetujuan terlebih dahulu oleh direktur keuangan.

Anda juga perlu menyiapkan daftar informasi “Menyiapkan persetujuan permohonan pengeluaran dana” (Gbr. 1) dan menentukan tahapan (rute) persetujuan permohonan (Gbr. 2)

Beras. 1

Beras. 2

Jalur koordinasi Lamaran ditentukan sesuai dengan pengaturan dan tergantung departemen yang ditentukan dalam lamaran.

catatan bahwa satu divisi harus berhubungan dengan hanya satu jalur koordinasi. Rute persetujuan harus ditentukan untuk setiap divisi, jika tidak, proses persetujuan untuk semua aplikasi yang dibuat untuk divisi ini tidak akan berlaku.

1. Akuntan pembelian membuat dokumen “Permintaan pengeluaran dana”.

Di antarmuka “Manajemen Kas” yang kami pilih, buka item menu “Perencanaan” - “Permintaan” - “Permintaan pengeluaran dana” (Gbr. 3). Mari kita buat “Aplikasi pengeluaran dana” dengan tipe status “Disiapkan” (Gbr. 5)

Aplikasi memiliki beberapa jenis operasi yang mengulangi jenis operasi “Pesanan keluar tunai” dan “Pesanan pembayaran keluar” (Gbr. 4)

Dalam "Permintaan pengeluaran dana" pada tab "Penyelesaian dengan pihak lawan", informasi dasar ditunjukkan: pihak lawan pembayaran kepada siapa dana harus dikeluarkan, serta perjanjian, jumlah, organisasi, divisi dan status.

Pada tab “Deskripsi” Anda dapat menentukan Informasi tambahan dalam bentuk apapun.

Tab “Alokasi” memberikan kemungkinan untuk memesan dan menempatkan dana (Gbr. 6). Artinya, dalam contoh kita, akuntan pembelian dapat mencadangkan dana untuk membayar uang muka kepada pemasok, dan menunjukkan dari meja kas mana dana tersebut akan dikeluarkan. Parameter reservasi dan penempatan dapat diisi secara otomatis. Ada tanda untuk tujuan ini di dokumen. "Reservasi otomatis" Dan "Penempatan otomatis". Jika tanda ini disetel, maka kolom “Penempatan” dapat terisi secara otomatis saat Anda mengklik tombol "Isi dan Posting". Skema penempatan otomatis dan manual dapat digabungkan.

Data pada tab “Penganggaran” dapat digunakan sebagai penghubung antara subsistem penganggaran dan subsistem pengelolaan kas. Informasi yang ditampilkan pada tab ini berfungsi untuk mengontrol jumlah dana yang direncanakan untuk dicairkan sesuai dengan anggaran yang direncanakan (Gbr. 7).

Karena akuntan pengadaan memiliki hak akses yang terbatas, ia hanya dapat mengatur status “Siap” dalam dokumen “Permintaan pengeluaran dana”, dan status seperti: “Disetujui”, “Ditunda”, “Setuju”, “Ditolak” adalah ditetapkan oleh pengguna, bertanggung jawab untuk menyetujui aplikasi.

2. Direktur keuangan meninjau dan menyetujui permohonan pengeluaran dana sebesar 120.000 rubel.

Direktur keuangan dapat menganalisis daftar permohonan yang memerlukan pertimbangan menggunakan pemrosesan “Status Persetujuan Permohonan” (Gbr. 8).

Saat Anda mulai memproses "Status Persetujuan Aplikasi", ini akan menampilkan daftar semua aplikasi yang dikelompokkan berdasarkan status (status) tertentu, seperti: "Disiapkan", "Disetujui", "Ditunda", "Setuju", "Ditolak". Untuk kenyamanan, Anda dapat memilih “Pengaturan periode” menggunakan tombol, misalnya, untuk satu hari, satu minggu, satu bulan, satu dekade, satu kuartal, setengah tahun, satu tahun, dll., lalu, dari semua permohonan, hanya permohonan yang termasuk dalam jangka waktu tertentu yang akan tetap ada.

Untuk mengubah status permohonan pembelanjaan dana, misalnya dari “Disiapkan” menjadi “Disetujui”, Anda perlu menggunakan pemrosesan lain (“Status Permohonan”).

Dalam pemrosesan ini, Anda dapat memilih dari daftar umum permohonan, misalnya permohonan dengan status “Menunggu persetujuan”, “Ditunda”, “Menunggu persetujuan pada tahap sebelumnya”, “Sedang Diproses” (Gbr. 9).

Pemrosesan menampilkan daftar aplikasi yang tidak terkoordinasi dan Anda dapat mengubah status aplikasi (Gbr. 10). Anda dapat melanjutkan ke pemrosesan ini melalui item menu "Perencanaan" - "Permintaan" - "Koordinasi aplikasi".

Direktur Keuangan dapat “Menyetujui” Permohonan pengeluaran dana, “Menunda” atau “Menolak”. Saat Anda memilih "Ubah status" - "Setuju", kotak centang menandai aplikasi yang perlu disetujui. Aplikasi lainnya yang berada dalam antrian dapat dilihat di log dokumen “Persetujuan Aplikasi”.

Jika permohonan belum melewati jalur persetujuan (status permohonan tidak “Disetujui”), maka dokumen pembayaran tidak dapat diterbitkan atas dasar tersebut.

Apabila permohonan mulai melalui jalur persetujuan, maka permohonan dapat diubah:

Pengguna yang permohonannya sedang disetujui;

Pengguna yang menyetujui aplikasi pada tahap persetujuan yang lebih tinggi.

Pengguna lain tidak dapat mengubah aplikasi.

Jika permohonan dalam keadaan “Disetujui”, maka permohonan tidak tersedia untuk diubah (menjadi tidak aktif untuk diedit), sehingga kolom dalam permohonan menjadi abu-abu bagi akuntan pembelian dan tidak dapat diubah.

3. Berdasarkan permohonan yang disetujui, akuntan pembelian membuat tanda terima kas dengan jenis transaksi “Pembayaran ke pemasok” tanpa tanda “Dibayar” untuk penerbitan uang muka kepada pemasok IP Dobronravov (Gbr. 11)

catatan, bahwa dalam perintah penerimaan kas yang dibuat oleh akuntan pembelian, hanya kotak centang “Renungkan dalam akuntansi manajemen” dan “Renungkan dalam akuntansi operasional” yang dicentang. Kotak centang “Dibayar” harus dicentang oleh kasir senior setelah memeriksa kebenaran pembentukan pesanan penerimaan kas. Kami juga menunjukkan dalam pesanan penerimaan kas berdasarkan aplikasi mana kami membuatnya.

Jika dalam pesanan penerimaan kas hanya terdapat kotak centang untuk akuntansi manajemen, maka dokumen tersebut tidak menghasilkan postingan (catatan akuntansi). Tapi dia membuat entri dalam register akumulasi: "Uang tunai untuk penghapusan" dan "Penyelesaian dengan pihak lawan" (Gbr. 12). Informasi ini dimasukkan ke dalam laporan “Kalender pembayaran” di bagian “Dokumen keluar yang belum dibayar” (Gbr. 13).

4. Kasir senior memeriksa pesanan penerimaan kas, mencentang kotak “Dibayar” dan mengeluarkan uang tunai.

Setelah pesanan penerimaan tunai dibayar, kolom dalam dokumen menjadi abu-abu dan tidak dapat diedit oleh akuntan pembelian dan peserta lain dalam contoh kita. Bergantung pada hak akses apa yang dikonfigurasi untuk pengguna tertentu, dokumen tertentu, bidang dalam dokumen, dll. mungkin tersedia untuk diedit.

Catatan: Jika ada banyak mesin kasir dan Anda perlu mencentang kotak “Berbayar” di masing-masing mesin kasir, Anda dapat menggunakan pemrosesan kelompok direktori dan dokumen (item menu “Layanan”). Anda dapat melanjutkan ke pemrosesan ini dengan membuka antarmuka lengkap, item menu "Layanan" (Gbr. 14).

Untuk mengubah detailnya, klik tombol “Pengaturan” dan pilih tanda “Izinkan perubahan detail objek”. Untuk memudahkan analisis, mari kita atur tanda “Tampilkan semua kolom” (Gbr. 15).

Dengan menggunakan pemrosesan grup, kami ingin memasang tanda “Dibayar” di pesanan penerimaan kas. Untuk melakukan ini, di bagian “Pilihan” pemrosesan grup, kami menunjukkan organisasi StroyTorg LLC; Kami hanya memilih dokumen yang diproses untuk periode 01/01/2013 hingga 21/01/2013 dengan opsi "Berbayar" - "Tidak".

Ketika Anda mengklik tombol "Pilih" pada tab "Pemrosesan", dokumen akan muncul di mana Anda perlu menandai "Dibayar" (Gbr. 16). Di baris “Tindakan”, pilih “Ubah detail[Link.Paid] - Instal. Dan lari".

Setelah mengubah nilai detailnya, Anda perlu memposting ulang dokumen yang diubah: di bidang “Tindakan”, pilih “Ubah: [Posting dokumen] – Atur - “Jalankan” (lihat Gambar 17).

5. Akuntan kas memeriksa pesanan penerimaan kas (mencentang kotak untuk refleksi dalam catatan akuntansi dan akuntansi pajak sehingga dihasilkan entri akuntansi dan akuntansi pajak).

Selanjutnya misalnya pada akhir hari kerja, seorang akuntan transaksi tunai memeriksa semua pesanan kas keluar yang bertanda “Dibayar” dan mencentang kotak BU dan NU pada dokumen sehingga dokumen tersebut menghasilkan entri akuntansi dan akuntansi pajak. (Gbr. 18)

Catatan: jika ada banyak pesanan penerimaan kas yang perlu dicentang kotak BU dan NU, maka Anda dapat menggunakan “Pemrosesan kelompok buku referensi dan dokumen” (Gbr. 19).

Dalam pemrosesan grup direktori dan dokumen, kami memilih dokumen "Perintah pengeluaran tunai [TC: Penguraian Pembayaran]", di bagian tabel di mana Anda perlu mencentang kotak "Renungkan dalam akuntansi".

Di bidang "Pilihan" kami menunjukkan organisasi mana yang perlu kami pilih dokumennya, kami menunjukkan bahwa kami hanya tertarik pada dokumen yang diproses untuk interval dari 01/01/2013 hingga 21/01/2013 (serta penerimaan kas di mana kotak centang "Renungkan dalam akuntansi" tidak dicentang) akuntansi"). Setelah mengisi semua parameter, klik tombol “Pilih”: dokumen yang memenuhi ketentuan yang ditentukan akan dipilih. Di bagian bawah jendela pemrosesan, pilih “Ubah atribut” - “Renungkan akuntansi" - "Instal" dan klik tombol "Jalankan". Setelah dokumen diproses, dokumen tersebut perlu diposting ulang (Gbr. 16). Maka Anda perlu mengulangi hal yang sama, tetapi untuk mencentang kotak “Renungkan dalam akuntansi pajak”

Saat memposting dokumen “Perintah pengeluaran tunai”, tidak hanya pergerakan yang dihasilkan di akun akuntansi, tetapi juga di register (Gbr. 20, 21)