Saat ini, transisi dari 1C:Enterprise 7.7 ke 8.3 (mirip dengan 8.2) telah membuat pusing para akuntan. Sebaiknya secepat mungkin dan tanpa kesalahan. Jika Anda seorang programmer 1C:Akuntansi dan Anda perlu mengonversi dokumen-dokumen ini dari versi ketujuh ke versi kedelapan, maka artikel ini cocok untuk Anda.

Ambil hanya beberapa langkah dan masalah transfer data Anda akan terpecahkan. Baca instruksi ini sampai akhir dan Anda akan melihat cara melakukannya. Pertama, Anda harus menyiapkan tempat kerja di komputer Anda untuk manipulasi yang diperlukan. Pertama, hard drive Anda harus minimal 100 GB. Hal ini diperlukan karena transfer saldo bersifat multi level. Dan Anda perlu bekerja dengan beberapa konfigurasi 7.7.

Jika Anda memerlukan transisi cepat dan berkualitas tinggi dari 1C Accounting 7.7 ke 1C 8.3, hubungi kami! Biaya turnkey rata-rata kami adalah 6.600 rubel.

Mentransfer data dari 1C 7.7 ke 1C 8.3 akuntansi 3.0

Jadi, sebelum melakukan transfer data ke versi 1C 8.3, Anda perlu menyiapkan data tersebut di versi 7.7. Untuk melakukan ini, Anda harus melakukan hal berikut. Katakanlah Anda memiliki database yang berfungsi “Akuntansi untuk Perusahaan” di komputer Anda, yang digunakan oleh akuntan Anda. Menggunakan pemrosesan Ekspor77, unggah semua dokumen yang diperlukan ke file teks dan sejak saat itu, jangan pernah kembali ke database kerja utama. Manipulasi Anda selanjutnya akan terjadi dengan konfigurasi lain.

Instal Rilis 1C:Enterprise 7.7 terbaru ke dalam direktori baru. (paket mencakup versi kosong standar (tanpa data) dan versi demo). Kami akan bekerja dengan versi standar. Sekarang luncurkan database ini dan, menggunakan pemrosesan Impor 77, muat data dari database utama Anda dari file teks.

Saat mengonversi data, beberapa dokumen mungkin tidak diproses. Itu tidak menakutkan. Triknya adalah Anda dapat dengan mudah memperbaikinya setelah transfer, karena dalam database standar Anda bekerja dengan bagan akun standar utama. Oleh karena itu, betapapun canggihnya sub-akun, mudah untuk memperbaikinya di database kerja Anda dalam waktu sekitar 3 jam dengan masuk ke setiap dokumen yang belum diposting dan mengubah akun yang Anda miliki dalam konfigurasi di bidang akun.

Tentu saja, sebelum transfer, Anda terlebih dahulu menyelaraskan bagan akun konfigurasi standar dengan bagan akun basis kerja utama Anda. Pilihannya murni individual tergantung pada spesifikasi organisasi Anda. Setelah melakukan pekerjaan ini, Anda menerima konfigurasi standar yang diisi dengan data dari database kerja Anda.

Sekarang kita perlu melakukan transfer data lagi. Untuk melakukan ini, instal lagi konfigurasi nol standar di direktori baru. Dan transfer data di sana dari konfigurasi standar dengan data Anda. Hasilnya, Anda akan mendapatkan database versi 7 yang ideal, siap untuk ditransfer ke versi 8.2.

Faktanya adalah bahwa data ditransfer langsung ke versi kedelapan secara eksklusif dari standar "tak tersentuh" ​​​​versi 7.7. Dan sekarang Anda memiliki konfigurasi seperti itu. Namun sekarang tidak kosong, melainkan berisi data pekerjaan Anda.

Semua! Kami meluncurkan 1C:Enterprise 8.2. Pilih “Transfer data dari versi 7.7.” dan nikmati bagaimana program itu sendiri mentransfer data dari 7.7. Anda yang diproses, mentransfer dokumen dan menampilkan tabel perbandingan neraca versi 7.7 dan 8.3.

Tentu saja tidak akan ada hasil 100%. Namun pada 70-80 persen akan mendapat kecocokan. Dan kemudian pekerjaan Anda hanya akan selesai di versi 8.3.

Kemungkinan ketidakakuratan mudah diperbaiki. Ini 3-4 jam lagi. Anda masuk ke jurnal dokumen dan menyesuaikan akun atau bidang (misalnya, “Perjanjian” atau “Meja kas utama”). Itu tergantung pada tingkat perbedaan antara basis 7.7 Anda. dari standar. Sebagai hasil dari semua tindakan ini, konfigurasi kerja Anda versi 8.3 akan mampu menghasilkan data akuntansi melalui neraca dalam bentuk yang ideal.

Setelah transisi, akan bermanfaat bagi Anda untuk mempelajari cara bekerja di program baru. Untuk itu kami telah menyiapkan bagian Pelatihan 1C Akuntansi 8.3.

Omong-omong! Jika Anda memerlukan modifikasi program 1C, Anda dapat menghubungi kami!

Mentransfer database 1C 7.7 ke 8.3, bagaimana caranya?

Banyak solusi delapan inti standar (dan beberapa khusus industri) sudah memiliki alat transfer bawaan dari 7.7 atau dalam bentuk file tambahan di direktori instalasi templat.

Jika Anda mentransfernya sendiri, maka pada disk ITS (dan juga di banyak tempat di Internet - Google dapat membantu) ada pemrosesan "Memuat dari dokumen spreadsheet", yang memungkinkan Anda memuat data tabular sewenang-wenang ke dalam direktori/dokumen /mendaftar. Dengan tingkat kualifikasi yang cukup tinggi, Anda dapat menggunakan artileri militer - konfigurasi khusus "Konversi Data 2" (jangan bingung dengan 3.).

Bisakah Anda memberi tahu saya mengapa kesalahan ini terjadi? Dalam dokumentasi untuk 1C, semuanya ditulis terlalu membingungkan - lagipula, Anda perlu menerima gaji, jadi tidak mungkin untuk memahami manuskrip mereka sama sekali, perang dan perdamaian lebih mudah daripada tutorial mengoperasikan sistem mereka yang jauh dari rumit.

Maxim Kravchenko, semuanya ditulis dalam bahasa Rusia :)

Menurut pengalaman saya, alasan paling umum adalah sebagai berikut:

1) Jalur yang salah ditentukan dalam pengaturan pertukaran dengan 7.7. Mungkin hanya ada kesalahan ketik di sini atau jalur ke direktori yang salah ditentukan. Atau jalur lokal di komputer Anda ditentukan, tetapi pertukaran terjadi di sisi server perusahaan 1C dan server ini secara alami tidak melihat apa pun di sepanjang jalur Anda (masalah umum).
2) Di sisi komputer yang mencoba berkomunikasi dengan 7.7 (lokal atau server) tidak ada platform 7.7 yang terinstal sepenuhnya. Itu. tidak ada objek COM yang terdaftar, dan basis 7.7 secara tradisional terhubung menggunakan direktori dengan platform yang diretas yang tidak memerlukan kunci atau data sistem apa pun.
3) Tidak ada hak akses ke direktori dengan basis 7.7 (terutama penting ketika bekerja di server, di mana proses pekerja rphost berjalan di bawah pengguna layanan, dan direktori basis 7.7 terbuka untuk orang tertentu).

Maxim Kravchenko, mengapa tidak melalui IRC atau obrolan di “jalanan kecil terkutuk”? 🙂
Tidak, saya tidak akan menginjak penggaruk yang sama lagi. Saya sudah memberikan Skype saya kepada orang yang tidak tahu berterima kasih dan dia duduk di lehernya.

Jika Anda memiliki pertanyaan umum yang jawabannya mungkin bisa membantu orang lain, tanyakan. Mari kita melakukan perbuatan baik bersama-sama. Tidak ada negosiasi rahasia.

P.S. Untuk mencegah orang kehilangan keinginan untuk memberikan jawaban pada sumber ini, alangkah baiknya jika Anda menandai solusi atau mengklik tombol “suka” pada jawaban yang paling memadai, meskipun jawaban tersebut tidak membantu secara langsung.

Maxim Kravchenko, FAQ tidak mungkin karena 7.7 murni tidak ada di alam. Ada beragam solusi standar/industri, ada versi berbeda dari konfigurasi spesifik yang sama, namun tidak satu pun dari rangkaian ini yang langsung memenuhi kebutuhan perusahaan, dan semua 7.7 yang terjual diselesaikan selama bertahun-tahun setelah instalasi. Mempertimbangkan fakta bahwa penjualan massal 7.7 berhenti lebih dari sepuluh tahun yang lalu, mungkin tidak ada lagi fungsionalitas standar yang tersisa di database khusus Anda.

Itu satu hal jika Anda mengambil mekanisme transfer standar, yang saya tulis dalam jawaban saya, dan mentransfernya dengan pemahaman bahwa tanggung jawab atas kesalahan ada pada Anda dan semua ketidakkonsistenan yang Anda lakukan untuk memperbaiki "perempuan". Menyewa seorang spesialis demi uang adalah hal lain. Anda perlu menjelaskan semua buku referensi untuk transfer, jumlah informasi yang akan ditransfer (artikel, barcode, NPWP, dll), di mana mendapatkan informasi yang hilang, dan sebagainya. Saya belum siap untuk mengambil proyek Anda sekarang. Saya sarankan mendaftarkan tugas ini di situs freelancer dan mengadakan tender di antara mereka.

Aturan transfer 1s 8

Mentransfer data dari program “1C: Accounting 8 rev.2.0” ke “1C: Accounting 8 rev.3.0”

Dirancang terutama untuk konfigurasi yang dimodifikasi 1C:Akuntansi 8 edisi 2.0(nama yang mungkin di Internet BP 2.0 atau BP 8.2) sebagai dasar untuk mengembangkan aturan asli untuk mentransfer ke konfigurasi 1C:Akuntansi 8 edisi 3.0(kemungkinan namanya di Internet BP 3.0 atau BP 8.3), tentunya juga cocok untuk mentransfer data antar konfigurasi standar.

Kemungkinan strategi untuk bermigrasi dari edisi 2.0 ke 3.0 dapat ditemukan di sini.

Transisi dari 1C:Akuntansi 8 edisi 2.0 pada 1C:Akuntansi 8 edisi 3.0 Disarankan untuk dilakukan pada awal periode baru (tahun, triwulan, bulan) setelah selesainya operasi rutin periode sebelumnya.

Transfer data dilakukan menggunakan pemrosesan universal yang mengunduh data dari basis informasi 1C:Akuntansi 8 edisi 2.0 ke file dalam format XML. File yang dihasilkan diunggah ke database informasi 1C:Akuntansi 8 edisi 3.0 menggunakan pemrosesan pemuatan data universal.

File-file berikut diperlukan untuk mentransfer data:

ACC20_30.xml - aturan konversi data.

Dari basis informasi BP 2.0 V BP 3.0 ditransfer:

informasi saldo lancar pada akun akuntansi basis informasi “1C: Accounting 8 rev.2.0” pada tanggal konversi basis informasi

dokumen basis informasi BP 2.0 untuk periode yang dipilih

informasi referensi yang diperlukan dari basis informasi "1C: Accounting 8 edisi 2.0"

— data dari basis informasi 1C BP 8.2 diunggah ke file terpisah (file data);

— file yang dihasilkan diunggah ke database informasi 1C BP 8.3.

Tidak diperlukan instalasi, karena pemrosesan yang dibangun ke dalam konfigurasi standar digunakan, di 1C:Akuntansi 8 edisi 2.0 Dan 1C:Akuntansi 8 edisi 3.0.

(Baca di bawah tentang kemungkinan menggunakan pemrosesan khusus)

Dalam program tersebut 1C:Akuntansi 8 edisi 2.0 Anda perlu membuka pemrosesan (menu: Melayani — Pertukaran data lainnya), pilih folder tempat aturan transfer berada (lihat Gambar 1) dan unduh aturan pertukaran. Saya merekomendasikan memuat aturan pertukaran secara paksa setiap saat, meskipun aturan tersebut dimuat secara otomatis saat pemrosesan dimulai. Untuk melakukan ini, Anda perlu memilih ulang file aturan atau mengklik tombol Baca kembali aturan pertukaran. Anda tidak perlu memasukkan semua aturan transfer. Hanya yang diperlukan untuk mentransfer saldo dan/atau dokumen yang boleh digunakan. Semua buku referensi ditransfer melalui tautan, sesuai kebutuhan, mis. hanya mereka yang terlibat dalam saldo dan dokumen. Hal ini memastikan bahwa tidak ada “sampah” di basis informasi baru.

Jika perlu membongkar saldo di akhir tahun, misalnya di penghujung hari 31/12/2014, yaitu. Lebih tepat dikatakan awal tahun 2015, maka periode bongkarnya seharusnya 01/01/2015 - XX.XX.XXXX. Dokumen untuk memasukkan saldo BP 3.0 akan tertanggal 31/12/2014. Dari 01/01/2015 sampai BP 3.0 Anda perlu membuat dokumen yang mencerminkan transaksi saat ini. Jika Anda hanya membutuhkan sisa, maka Anda perlu mengaktifkan aturan untuk mengunduh data dari bagian tersebut Saldo masuk(lihat Gambar 1). Aturan untuk mengunduh data dari suatu bagian Dokumen dalam hal ini harus dinonaktifkan (lihat Gambar 3). Periode pengunggahan, misalnya 01/01/2015 - 31/01/2015 berarti dokumen mulai Januari 2015 akan ditransfer. Aturan untuk mengunduh data dari suatu bagian Dokumen dalam hal ini harus disertakan.

Beras. 1. Pemrosesan untuk pengunggahan data

Pertama-tama, kami merekomendasikan untuk mentransfer kebijakan akuntansi organisasi (direktori Organisasi ditransfer melalui tautan). Saat mentransfer data, Anda juga dapat mengatur parameter (lihat Gambar 2). Untuk kembali ke nilai default, Anda harus memuat ulang aturan pertukaran.

Gbr.2 Pengaturan parameter

Parameter Abaikan daftar kumpulan PPN pertama-tama menentukan apakah itu akan diisi BP 3.0 saat memasukkan saldo Inventaris meja Data faktur yang diterima. Ini juga mempengaruhi cara pengisian subkonto Pesta: menurut data BU atau dengan sisa register PPN atas Barang Berharga yang Dibeli.

Menyetel parameter ini memungkinkan Anda mengelola pembongkaran saldo untuk organisasi yang menggunakan sistem perpajakan yang disederhanakan. Saat akuntansi berjalan, jika data register tidak sesuai Biaya di bawah sistem pajak yang disederhanakan Mungkin akan lebih berguna bagi register akuntansi untuk membongkar saldo berdasarkan data akuntansi saja, tanpa memperhitungkan register sistem perpajakan yang disederhanakan, yang dapat menambah banyak kesalahan. Dalam hal ini, dalam dokumen untuk memasukkan saldo awal BP 3.0 detail Refleksi dalam sistem perpajakan yang disederhanakan Dan Status Aliran diisi dengan nilai default.

Saat mengatur parameter ke Ya bersamaan dengan dokumen-dokumen tersebut, kumpulan register yang terkait dengan dokumen-dokumen ini akan ditransfer. Jika tidak, isi dokumen akan ditransfer, dan untuk menerima perpindahan, dokumen tersebut harus dimasukkan ke dalam database BP 3.0 setelah transfer. Anda harus memahami bahwa tidak semua perpindahan dokumen yang ada di BP 8.3, ada korespondensi di BP 8.2. Oleh karena itu, meskipun Anda memilih opsi untuk mentransfer dokumen dengan perpindahan, untuk beberapa jenis dokumen Anda mungkin perlu mempostingnya untuk membuat semua kumpulan register yang diperlukan.

Gambar 3 Daftar dokumen yang ditransfer ke BP 3.0

Daftar direktori dan register informasi untuk transfer disajikan pada Gambar 4. Jika ada yang tertarik untuk memperluas daftar ini, silakan hubungi penulisnya. Ada aturan untuk mentransfer objek ke banyak direktori. Hal ini dapat dimaklumi, karena berbagai buku referensi terdapat dalam banyak dokumen dan karenanya diunduh melalui tautan. Tidak sulit untuk membuat aturan pembongkaran dari mereka; Anda bisa melakukannya sendiri. Aturan untuk membongkar direktori diperlukan jika ada keinginan untuk mentransfer seluruh direktori, dan bukan hanya tautan.

Beras. 4 Daftar direktori dan register informasi untuk transfer

Fitur transfer saldo pada akun 76.AB dan 76.VA

Saat diatur ke Ya parameter Memperbaiki kesalahan penilaian dalam penyelesaian dengan pihak lawan kesalahan yang dibuat dalam akuntansi dapat diperbaiki. Apa yang disesalkan jelas dari Gambar 5.1: untuk pihak lawan saldonya nol, tetapi untuk subkonto kedua jumlahnya tidak nol. Saldo tersebut tidak akan terbawa.

Gambar 5.1 Penilaian ulang residu

Jika diatur ke Ya parameter Pesan secara detail, kemudian pada saat pengunggahan akan ditampilkan pesan penjelasan (lihat Gambar 5.2).

Gambar 5.2 Pesan jika terjadi kesalahan penilaian saldo

Fitur mentransfer saldo pada akun inventaris

Algoritme untuk memperbaiki kesalahan seperti kesalahan penilaian pada residu bekerja dengan cara yang sama. Inventaris. Algoritma ini berfungsi saat mengatur parameter Memperbaiki kesalahan penilaian saldo persediaan dalam arti Ya. Contohnya ditunjukkan pada Gambar 5.3. Akuntansi pada akun 10.03 dilakukan berdasarkan item, gudang dan batch. Tersisa berdasarkan item Bensin AI-92 pada gudang nomor 4 sama dengan nol, tetapi jika Anda memperluas saldo secara batch, jumlahnya akan banyak. Jumlah aljabar saldo per batch sama dengan nol, ini adalah penilaian ulang. Saldo tersebut tidak boleh ditransfer, karena ini jelas merupakan kesalahan. Mereka tidak akan ditransfer jika parameternya disetel.

Gambar 5.3 Penilaian ulang residu Inventaris dalam database sumber BP 2.0

Keadaan menjadi lebih buruk dengan saldonya gudang nomor 6. Sisanya bukan nol, sehingga algoritma koreksi kesalahan penilaian tidak akan berfungsi; sisanya akan ditransfer. Mari kita lihat bagaimana mereka akan ditransfer. Jumlah -155,29 tidak akan dimasukkan dalam transfer, karena sisanya masuk BP 3.0 tidak mungkin masuk, tidak mungkin memasukkan jumlah nol dan jumlah bukan nol, dokumen pemasukan saldo tidak akan diposting, jadi tidak kami upload. Akibatnya, di BP 3.0 dua jumlah sisanya akan turun (lihat Gambar 5.4). Sisanya ditransfer seolah-olah ada kesalahan. Sebenarnya di sini tidak ada kesalahan transfer, tapi ada kesalahan akuntansi.

Gambar.5.4 Hasil transfer ke BP 3.0

Apakah akan menggunakan algoritme yang dijelaskan untuk memperbaiki kesalahan penilaian atau tidak, terserah pengguna untuk memutuskan. Anda hanya perlu mengingat bahwa saldo dengan jumlah nol tidak pernah ditransfer. Menurut penulis, ini adalah perilaku yang paling benar, setidaknya memungkinkan Anda memasukkan dokumen untuk memasukkan saldo dan memulai rekonsiliasi. Untuk lebih cepat mencari posisi selisih antar saldo BP 2.0 Dan BP 3.0 Berdasarkan hasil transfer tersebut, dapat direkomendasikan untuk memilih posisi-posisi bermasalah tersebut pada sumbernya dengan mengatur neraca yang sesuai. Cara melakukannya, lihat Gambar 5.5.

Gambar 5.5 Pemilihan posisi dengan kuantitas nol

Setelah bongkar muat selesai Anda perlu menjalankan programnya 1C:Akuntansi 8 edisi 3.0. Pemuatan, baik pada awalnya maupun selama transfer data berulang atau transfer tambahan, harus dilakukan menggunakan pemrosesan standar Pertukaran data universal dalam format XML(lihat Gambar 8.1). Anda dapat membukanya melalui menu: Semua fungsi - Pemrosesan - Pertukaran data universal dalam format XML. Jika tidak ada item di menu Semua fungsi, maka Anda harus pergi ke Layanan -Parameter dan centang kotaknya Tampilkan perintah Semua fungsi.

Setelah memuat data ke dalam database 1C: Accounting 8 rev.3.0, Anda perlu memasukkan dokumen untuk memasukkan saldo awal guna mendapatkan semua pergerakan yang diperlukan. Anda dapat menggunakan pemrosesan Pemindahan dokumen secara kelompok(lihat Gambar 8.2) atau posting dokumen di jurnal (menu: Semua fungsi - Dokumen - Memasukkan saldo). Jika dokumen ditransfer tanpa perpindahan (parameter Unggah pergerakan dokumen ditetapkan ke nilai TIDAK), maka untuk menerima transaksi dan entri dalam register, perlu dilakukan posting dokumen.

Teknik konversi data.

Konversi bila perlu dapat dilakukan dalam beberapa tahap, misalnya pertama buku referensi, kemudian dokumen pemasukan saldo, kemudian dokumen lainnya. Transfer ulang informasi dimungkinkan. Di sela-sela transfer, Anda tidak boleh melakukan koreksi terhadap data yang ditransfer 1C:Akuntansi 8 edisi 3.0, jika tidak, perbaikan ini mungkin hilang selama transfer berulang.

Saldo ditransfer melalui dokumen Memasukkan saldo awal.

Lebih detail mengenai cara memasukkan saldo dapat dilihat pada artikel di website ITS perusahaan 1C.

Penting! Sebelum memasukkan saldo awal, parameter kebijakan akuntansi harus ditetapkan. Parameter kebijakan akuntansi organisasi dibaca pada tanggal setelah tanggal entri saldo. Misalnya, jika tanggal memasukkan saldo adalah 31 Desember 2013, maka parameter kebijakan akuntansi yang ditetapkan pada 1 Januari 2014 akan diperhitungkan. jika pada tahun 2013 organisasi menerapkan sistem perpajakan yang disederhanakan, dan sejak tahun 2014 beralih ke sistem umum - maka ketika memasukkan saldo pada tanggal 31 Desember 2013, parameter kebijakan akuntansi tahun 2014 akan diperhitungkan). Oleh karena itu, sebagaimana dinyatakan di atas, pertama-tama kami merekomendasikan untuk mentransfer kebijakan akuntansi organisasi.

Penting! Jika Anda memutuskan untuk mulai bekerja 1C:Akuntansi 8 edisi 3.0 sebelum sisa-sisanya dipindahkan ke sana, perlu dilakukan terlebih dahulu sebelum mulai bekerja 1C:Akuntansi 8 edisi 3.0 direktori transfer. Jika tidak, kesalahan mungkin terjadi saat mentransfer saldo ke database yang tidak kosong.

Penting: Dimungkinkan untuk memecahkan masalah sinkronisasi saat memuat ke database yang tidak kosong - pencocokan objek.

Cara bekerja dengan pemrosesan transfer data khusus.

Pemrosesan hanya digunakan dalam mode Mengajukan. Pengolahan Transfer_Data_dari_BP20_ke_BP30.epf harus diluncurkan di basis info tempat data ditransfer, mis. V Akuntansi Perusahaan 1C ed.3.0. Di jendela pertama (lihat Gambar 9), Anda harus menentukan opsi untuk memuat data dari basis info pada platform 1C:Enterprise:

Muat data langsung dari infobase

Gbr.9 Jendela awal untuk pemrosesan transfer data

Di jendela berikutnya (lihat Gambar 10) Anda perlu mengkonfigurasi transfer:

Pilih basis info dari daftar (daftarnya sama seperti saat memulai aplikasi Perusahaan 1C).

Tentukan nama pengguna dan kata sandi

Tentukan informasi apa yang harus ditransfer

Selain itu, Anda dapat memeriksa data di sumber untuk kebenaran transfer

Saat mentransfer direktori, data akan ditransfer dari direktori basis info yang dipilih, yang memiliki aturan pengunggahan. Dalam hal ini, direktori ditransfer seluruhnya. Jika kotak centang tidak dicentang, tetapi opsi transfer lainnya dipilih, maka direktori juga akan ditransfer, tetapi hanya sejauh diperlukan untuk mengisi data dalam transaksi dan dokumen yang ditransfer. Saat mentransfer data, Anda dapat mentransfer buku referensi, dokumen, dan saldo ke awal tahun. Opsi transfer dapat dipilih dalam kombinasi apa pun. Saat mentransfer saldo, data saldo akun pada 1 Januari tahun yang dipilih akan ditransfer sesuai aturan yang ditunjukkan pada Gambar 1. Dalam 1C: Akuntansi 8, dokumen “Memasuki saldo awal” akan dibuat untuk tanggal 31 Desember tahun sebelum tahun yang dipilih.



Gbr.10 Jendela parameter transfer

Jika opsi untuk memeriksa data dipilih, maka sebelum memuat pemeriksaan tersebut akan dilakukan dan hasil pemeriksaan akan ditampilkan di layar (lihat Gambar 11). Jika ditemukan kesalahan selama proses verifikasi, proses transfer akan dihentikan sementara agar kesalahan dapat diperbaiki. Jika Anda perlu mengunggah dan mengunduh data meskipun ada kesalahan, hapus centang Periksa data sebelum mengunduh atau klik Melanjutkan. Daftar aturan pemeriksaan terus diperbarui.



Gambar 11 Hasil Verifikasi Data Sebelum Loading

Selama proses transfer data dari sumber ke penerima, gambar akan diperbarui di layar yang menunjukkan tahapan saat ini: menghubungkan ke basis info, mengunggah data, memuat data, dll. Selain itu, informasi lebih detail ditampilkan di bawah ini dalam bentuk baris, misalnya “Unggahan data: Dokumen (3/3)”. Setelah pengunduhan data selesai, proses memposting dokumen yang diunduh dan kemudian memeriksa data yang diunduh dimulai. Jika terjadi kesalahan selama pemrosesan dokumen atau verifikasi data, pesan tentang hal ini akan muncul di jendela pesan setelah selesai. Pesan kesalahan juga dapat dilihat di jendela terpisah dengan mengklik hyperlink Informasi Kesalahan(lihat Gambar 12).



Gambar.12 Indikasi proses transfer data

Bagian dari tabel yang berisi catatan kesalahan ditunjukkan pada Gambar 13. Pertama, tabel menampilkan pesan tentang kesalahan yang terjadi saat memposting dokumen, kemudian kesalahan saat verifikasi. Pengecekan data yang diunduh terdiri dari membandingkan neraca yang dihasilkan pada tanggal pemasukan saldo di sumber dan tujuan. Jika saldo pada akun mana pun tidak cocok, catatan akan dibuat tentang hal ini. Dengan mengklik dua kali pada entri di tabel kesalahan, Anda dapat membuka dokumen bermasalah untuk koreksi dan pengeditan manual. Hal yang sama dapat dilakukan di jendela pesan.



Gambar 13 Fragmen tabel yang berisi catatan kesalahan

Setelah melakukan koreksi pada database tujuan, tidak masuk akal untuk mentransfer informasi yang sama dari database sumber lagi, karena ketika ditransfer lagi, data ini akan kembali dicatat dengan kesalahan. Oleh karena itu, usahakan melakukan koreksi pada sumbernya, bukan pada penerimanya, atau tidak mengulangi penyampaian informasi yang sama. Misalnya, setelah mentransfer saldo awal dan memperbaiki semua dokumen untuk memasukkan saldo awal di penerima, jangan atur tanda untuk transfer selanjutnya Saldo di awal tahun.

Pembaruan gratis selama 6 bulan setelah pembelian. Setelah periode pembaruan gratis berakhir, Anda dapat menerima pembaruan secara berbayar (lihat harga di bawah). Pada saat yang sama, jika Anda membeli beberapa produk perangkat lunak, sebagai bagian dari set atau secara terpisah, maka Anda berhak mengandalkan diskon. Anda dapat mempelajari lebih lanjut tentang sistem diskon.

Aturan dibuat dengan menggunakan teknologi Konversi data: Mudah diedit.
Terbuka sepenuhnya, tidak ada batasan perizinan selain larangan replikasi.

Mengajukan TransferDemo20_30.xml adalah unduhan dari database yang diperoleh dengan mentransfer database demo BP 2.0, didistribusikan oleh 1C, ke database BP 3.0. Buat database BP 3.0.44.94 kosong, baik dari template 1C atau menggunakan file konfigurasi 1Cv8.cf. Tetapkan dalam parameter akuntansi ke Menyiapkan bagan akun akuntansi persediaan berdasarkan gudang dan batch. Unduh file basis data demo TransferDemo20_30.xml menggunakan pemrosesan Pertukaran data universal dalam format XML. Basis data demo menunjukkan transfer saldo pada 01/01/2009 dan dokumen untuk periode 01/01/2009 hingga 31/12/2009.

Aturan diperbarui secara berkala untuk rilis baru, cocok untuk rilis BP 2.0.64.23 dan yang lebih baru. Tidak perlu mencari dan memilih versi aturan transfer yang diinginkan; aturan tersebut cocok untuk rilis SOURCE apa pun dalam rentang yang ditentukan. Jika Anda memerlukan aturan untuk rilis sebelumnya, silakan hubungi penulis. Rilis RECEIVER harus persis seperti itu sesuai aturan.

29/08/2018 Pembongkaran saldo per bagian telah dialokasikan sebagai aturan tersendiri Kredit dan pinjaman(akun 66, 67), sebelumnya merupakan bagian dari Akun akuntansi lainnya

20/08/2018 Pembaruan ke 2.0.66.59 dan 3.0.64.48

06/03/2018 Menambahkan transfer dokumen Refleksi gaji dalam akuntansi yang diatur

18/05/2018 Pembaruan ke 2.0.66.54 dan 3.0.61.37

23/02/2018 Pembaruan ke 2.0.66.48 dan 3.0.58.41

18/01/2018 Pembaruan ke 2.0.66.46 dan 3.0.57.17

22/12/2017 Pembaruan ke 2.0.66.42 dan 3.0.56.22

03/11/2017 Pembaruan ke 2.0.66.37 dan 3.0.53.38

26/09/2017 Pembaruan ke 2.0.66.37 dan 3.0.52.35

14/06/2017 Pembaruan ke 2.0.66.29 dan 3.0.50.18

05/05/2017 Pembaruan ke 2.0.66.25 dan 3.0.49.27

04/04/2017 - menambahkan pembuatan invoice yang diterima ketika di BP 2.0 hanya ada nomor dan tanggal. Anda perlu mengatur parameternya Konversi faktur(buat yang baru jika sumbernya hanya berisi nomor dan tanggal)

02/06/2017 Update ke BP 3.0.47.23

26/01/2017 Menambahkan transfer dokumen Refleksi akrual PPN Dan Refleksi PPN untuk dipotong

11/01/2017 Update ke BP 2.0.66.8 dan BP 3.0.46.16. Pengalihan kasus tidak termasuk NDSpoOSiNMA. Di versi sebelumnya, yang disertakan dalam konfigurasi, itu tidak akan ditransfer.

14/12/2016 Update ke BP 3.0.44.203

07/12/2016 Menambahkan transfer dokumen Penyesuaian utang

12/01/2016 Menambahkan parameter Jangan memperhitungkan register Pengeluaran di bawah sistem pajak yang disederhanakan, yang memungkinkan Anda mengelola pembongkaran saldo untuk organisasi yang menggunakan sistem pajak yang disederhanakan

21/11/2016 Menambahkan pengunduhan direktori Pengguna aturan terpisah dengan pembuatan pengguna keamanan informasi di penerima (detailnya di sini). Menambahkan transfer saldo di seluruh RS Karyawan organisasi(data personel). Saat mentransfer saldo pada akun 76.AB dan 76.BA, dimungkinkan untuk memeriksa dan memperbaiki kesalahan penilaian pada sub-akun kedua.

08.11.2016 Daftar dokumen telah diperluas.

28/10/2016 Menambahkan transfer dokumen. Demo transfer telah ditambahkan, ini adalah hasil transfer database demo BP 2.0.

26/10/2016 Memperbaiki pembuatan dokumen kosong untuk memasukkan saldo ketika ada saldo akun 10.07

09.09.2016 Pembaruan ke BP 3.0.44.102

23/03/2016 Peningkatan transfer data pada faktur yang diterima (saat mentransfer saldo inventaris)

01/11/2016 Menambahkan transfer informasi kontak individu, kewarganegaraan, data paspor, informasi tentang kecacatan, status individu. Menambahkan aturan untuk mentransfer rekening bank dan rekening akuntansi item.

23/12/2015 Pembaruan ke BP 3.0.43.29. Menambahkan transfer informasi kontak rekanan dan orang yang dapat dihubungi.

14/12/2015 Aturan untuk BP 3.0.42 telah dibuat

Paket termasuk: aturan transfer "ACC20_30" dan pemrosesan Transfer_Data_dari_BP20_ke_BP30. Jika organisasi Anda tidak memiliki pemrogram penuh waktu untuk melaksanakan pekerjaan, kami siap menawarkan layanan spesialis kami (pemrogram akan terhubung ke komputer Anda melalui Internet menggunakan program khusus untuk pekerjaan jarak jauh dan melakukan pekerjaan yang diperlukan ). Jika memungkinkan, sediakan basis kerja "1C: Akuntansi 8 edisi 2.0", kami dapat mentransfer datanya sendiri dan mentransfer filenya” 1C:Akuntansi 8 edisi 3.0» dengan saldo yang ditransfer. Biaya layanan ini belum termasuk dalam total biaya paket.

Penting. Tidak semua dokumen ditransfer (untuk kompatibilitas dengan rilis BP 2.0 yang lebih lama). Sebelum membeli, bacalah dengan cermat daftar pada Gambar 3.

Mentransfer data dari program “1C: Accounting 7.7” dan “1C: USN 7.7” ke “1C: Accounting 8”

Beberapa kata tentang bagaimana data ditransfer dari konfigurasi standar “ Akuntansi", edisi 4.5 untuk 1C:Enterprise 7.7 atau konfigurasi "" (selanjutnya disebut Konfigurasi Sumber) ke dalam konfigurasi standar " Akuntansi perusahaan", edisi 3.0 untuk 1C:Enterprise 8 (versi 3.0.52), selanjutnya disebut sebagai “Konfigurasi penerima”.

PENTING! Transfer data dimungkinkan dari konfigurasi Akuntansi edisi 4.5 untuk 1C:Enterprise 7.7 versi 7.70.569 dan yang lebih baru atau dari konfigurasi " Sistem perpajakan yang disederhanakan, ed. 1.3» versi 7.70.219 dan lebih tinggi.

Disarankan untuk beralih dari Konfigurasi sumber ke Konfigurasi tujuan pada awal periode baru (tahun, kuartal, bulan) setelah menyelesaikan operasi regulasi pada periode sebelumnya.

Transfer data dilakukan menggunakan pemrosesan khusus yang mengunduh data dari basis informasi Konfigurasi sumber ke dalam file dalam format XML. File yang dihasilkan dimuat ke basis info Konfigurasi penerima menggunakan pemrosesan pemuatan data universal.

ACC_ACC8 .ert - pemrosesan eksternal mengunggah data ke file eksternal dari konfigurasi " Akuntansi, ed.4.5»;

USN_ACC8 .ert - pemrosesan eksternal mengunggah data ke file eksternal dari konfigurasi " Sistem perpajakan yang disederhanakan, ed. 1.3»;

ACC_ACC8 .xml - aturan konversi data.

USN_ACC8 .xml - aturan konversi data.

Berikut ini ditransfer dari infobase Konfigurasi Sumber ke Konfigurasi Penerima:

— informasi tentang saldo saat ini dalam akun akuntansi basis informasi Konfigurasi Sumber pada tanggal konversi basis informasi;

— dokumen terkini dengan tanggal lebih besar dari tanggal konversi basis informasi.

Konversi dilakukan dalam dua tahap:

— data dari basis informasi Konfigurasi Sumber diunggah ke file terpisah (file data);

— file yang diterima dimuat ke dalam basis informasi Konfigurasi penerima.

Untuk menginstal pemrosesan migrasi data, Anda harus menggunakan program instalasi setup.exe. Setelah memulai program (jika jumlah basis info 1C:Enterprise banyak, maka setelah beberapa waktu) sebuah kotak dialog akan muncul di mana Anda perlu menandai basis info tempat pemrosesan transfer data akan diinstal. Jendelanya terlihat seperti pada Gambar 1. Jika jumlah basis informasi lebih dari tujuh, gunakan tombol “atas” dan “bawah” untuk bernavigasi. Jika beberapa basis informasi dipilih, maka garis “jalur” mencerminkan lokasi hanya basis yang terakhir dipilih. Informasi ini bersifat tambahan dan digunakan secara opsional untuk kontrol tambahan oleh pengguna atas hasil program instalasi; jangan memberikan perhatian khusus padanya, program itu sendiri akan menentukan di mana basis informasi yang Anda pilih dipasang .



Gbr.1 Jendela untuk memilih basis informasi selama instalasi

Selain itu, Anda dapat menentukan folder di mana pemrosesan transfer data juga akan diinstal; untuk melakukan ini, gunakan jendela pemilihan folder (dengan mengklik tombol dengan tiga titik). Jalur lengkap untuk folder yang dipilih akan tercermin dalam baris pilihan. Setelah mengklik tombol "install", file yang diperlukan akan diinstal di infobase yang dipilih dan (atau) di folder yang dipilih. Setelah selesai, Anda dapat mengklik tombol “detail” dan melihat log instalasi terperinci, file mana yang ditulis ke folder mana. Hasilnya, folder yang dipilih akan terlihat seperti gambar berikut, lihat Gambar 2.



Gbr.2 File diinstal di folder yang dipilih

Ke subdirektori Formulir Ekst aturan pemrosesan dan transfer ditetapkan. Harap dicatat bahwa pemrosesan unggahan ACC_ACC8.ert dan aturan pengunggahan data menggantikan pemrosesan dan aturan standar. Jika Anda ingin mempertahankan mekanisme transisi standar, instal pemrosesan baru di direktori terpisah, dan bukan di basis info.

Proses instalasi dijelaskan lebih detail menggunakan contoh instalasi laporan " Pemeriksaan ekspres akuntansi untuk konfigurasi "1C: Accounting 7.7"«.

Dalam program " 1C: Akuntansi 7.7"Anda perlu membuka pemrosesan dari opsi tambahan" Transisi ke 1C:Akuntansi 8, ed. 3.0“, pilih folder tempat aturan transfer berada (lihat Gambar 3) dan unduh aturan pertukaran. Anda tidak perlu memasukkan semua aturan transfer. Hanya yang diperlukan saja, misalnya untuk pemindahan residu, atau residu dan dokumen, yang boleh digunakan. Misalnya, dalam grup direktori, tidak ada satu aturan pun yang dapat dimasukkan, karena semua direktori ditransfer melalui tautan, sesuai kebutuhan, mis. hanya mereka yang terlibat baik dalam saldo atau dalam dokumen. Hal ini memastikan bahwa tidak ada “sampah” di basis informasi baru. Dokumen juga tidak perlu disertakan semua. Misalnya, jika beberapa dokumen tidak ada dalam database Anda, atau Anda tidak ingin mentransfernya, Anda tidak perlu mengaktifkan aturan ini.



Gambar.3. Pemrosesan untuk pengunggahan data

Saya sarankan untuk mengatur nama file data menjadi “C:\v77_v8\Exp77_80.xml”, ini adalah folder yang sering digunakan secara default dalam program “ 1C: Akuntansi 8" saat mengunduh data dari program di platform " 1C:Perusahaan 7.7". Jika perlu, atur parameter pada " Pilihan«.

Selama proses pengunduhan data dari konfigurasi " Akuntansi 7.7“Berbagai kesalahan mungkin terjadi. Aturan transfer yang disajikan di sini berbeda dari aturan standar karena pada tahap pengunggahan data, aturan tersebut mencari kesalahan umum. Mari kita pertimbangkan pesan apa yang ditampilkan.

Kuantitas nol dan jumlah item inventaris yang bukan nol. Memasukkan saldo dalam Konfigurasi penerimaan sedemikian rupa sehingga jumlah material sama dengan nol, dan perkiraan biaya material tidak sama dengan nol, adalah tidak mungkin dan tidak ada gunanya, karena ini adalah kesalahan. Oleh karena itu, ketika mentransfer saldo, posisi tersebut (dengan jumlah nol) tidak akan dimasukkan dalam dokumen entri saldo. Akibatnya, jika kesalahan tidak diperbaiki sebelum transfer data, maka jumlah sumber dan tujuan data saat mentransfer saldo tidak akan cocok, yang akan menyebabkan kesulitan rekonsiliasi tambahan. Oleh karena itu, dalam proses pengunduhan data dari konfigurasi " Akuntansi 7.7» pesan tentang kesalahan yang ditemui ditampilkan (lihat Gambar 4). Selain itu, untuk menemukan kesalahan, kami dapat merekomendasikan penggunaan pemrosesan “Pemeriksaan cepat atas pemeliharaan akuntansi”, yaitu aturan “Tidak adanya jumlah yang bukan nol ketika jumlah bahan tidak ada”.



Gambar 4.1 Pesan tentang kesalahan yang terjadi

Saldo bukan nol untuk sub-akun tingkat kedua (ketiga)., sedangkan saldo pada level pertama (kedua) adalah nol. Ini adalah situasi pencatatan yang salah yang cukup umum. Contoh tipikal ditunjukkan pada Gambar 4.2. Kondisi ini timbul akibat adanya “re-grading” dalam akuntansi analitik. Misalnya, ada kesepakatan yang tertera pada dokumen arus kas, namun tidak ada kesepakatan pada dokumen kapitalisasi, atau sebaliknya, atau ada kesepakatan namun berbeda. Dalam semua kasus ini, terdapat saldo yang bukan nol dalam kontrak, meskipun faktanya saldo pada pihak lawan sama dengan nol. Gambaran serupa dapat muncul dalam akuntansi bahan dan nomenklatur (bila akuntansi total berdasarkan lokasi penyimpanan dimasukkan): penilaian ulang antar gudang, terutama jika gudang tersebut adalah orang yang bertanggung jawab secara finansial.



Gambar 4.2 Contoh kesalahan dalam akuntansi

Jelas bahwa ini adalah sebuah kesalahan, dan jelas bahwa tidak masuk akal untuk memindahkan saldo tersebut. Untuk mengecualikan perpindahan saldo semacam ini, ada opsi “Jangan bongkar saldo jika saldo nol di level atas”. Jika parameter ini disetel ke satu, maka selama pengunggahan pesan yang ditunjukkan pada Gambar. 4.3 (bandingkan dengan Gambar 4.2), dan saldo untuk posisi tersebut tidak akan dibongkar. Anda dapat menggunakan kombinasi berbeda dari parameter ini dengan aturan untuk mentransfer saldo berbeda. Jika Anda mentransfer tidak semua saldo sekaligus, tetapi berdasarkan bagian akuntansi, maka Anda dapat mentransfer saldo dari bagian akuntansi yang berbeda dengan nilai parameter yang berbeda.



Gambar 4.3. Pesan kesalahan

Nilai kontrak kosong atau kontrak luar negeri. Masalahnya mirip dengan yang dijelaskan di atas, alasannya sama - kesalahan penilaian dalam akuntansi analitik untuk kontrak (lihat Gambar 4.4). Namun saldo untuk pihak lawan tidak nol, sehingga aturan verifikasi yang dijelaskan di atas tidak akan berfungsi. Pada saat transfer data akan terjadi kesalahan pada saat memposting dokumen pemasukan saldo, karena nilai kontrak kosong tidak diperbolehkan.



Gbr.4.4 Laporan menunjukkan kesalahan

Untuk menghilangkan kesalahan tersebut sebelum transfer, pesan kesalahan dikeluarkan pada tahap pengunggahan data (lihat Gambar 4.5). Gambar yang sama menunjukkan bahwa kesalahan lain terjadi: kontrak tidak sesuai dengan pihak lawan, yaitu. pemilik kontrak adalah pihak lain. Kesalahan seperti itu sering ditemukan pada modifikasi, mis. konfigurasi non-standar atau dalam database yang dibuat sejak lama, bahkan dalam konfigurasi standar tidak ada pemeriksaan yang cukup ketat untuk kepatuhan kontrak saat mengisi dokumen.



Gambar.4.5 Pesan kesalahan akuntansi

Pengecekan nilai kosong kontrak dan kontrak orang lain dilakukan jika parameter " disetel ke satu Periksa kontrak untuk nilai kosong dan kepatuhan dengan pihak lawan". Selain itu, untuk menemukan kesalahan, kami dapat merekomendasikan penggunaan pemrosesan “Pemeriksaan cepat atas pemeliharaan akuntansi”, yaitu aturan “Tidak adanya analisis kosong untuk kontrak” dan “Kepatuhan pihak lawan dan kontrak.”

Masih ada pengecekan error lainnya, untuk informasi lebih lanjut silahkan menghubungi kami (kontak di bagian bawah halaman).

Kami akan menunjukkan bagaimana Anda dapat mentransfer data sebagian, bukan seluruhnya, dengan menggunakan contoh mengunggah dokumen dari jenis terpisah atau bahkan salinan individual dari dokumen dari jenis yang dipilih. Mari kita tandai hanya satu aturan pengunggahan data “ Perintah pembayaran"(lihat Gambar 5). Ini akan memungkinkan Anda mengunggah dokumen hanya seperti " Perintah pembayaran". Jika, dengan parameter ini, Anda mengklik tombol “ Membongkar", maka semua dokumen bertipe " Perintah pembayaran", terletak pada interval waktu dengan" tanggal mulai" Oleh " Tanggal akhir". Klik tombol " Instal PVD", setelah itu tulisan" Pemilihan data untuk perintah Pembayaran«.



Gbr.5 Cara menetapkan aturan untuk mengunggah data jenis tertentu

Selanjutnya, klik tombol “Tambahkan kondisi”, Anda akan dapat memilih atribut pilihan (lihat Gambar 6.1), paling sering adalah “ Dokumen Saat Ini“, yang memungkinkan Anda memilih dokumen terpisah dari daftar dokumen jenis ini. Anda dapat, dengan menggunakan detail pilihan lainnya, mendapatkan pilihan berdasarkan kelompok dokumen, misalnya, memilih dokumen berdasarkan tanggal. Dalam semua kasus, dokumen dipilih dalam interval waktu yang ditentukan oleh parameter " tanggal mulai" Dan " Tanggal akhir«.



Gbr.6.1 Cara memilih satu dokumen

Penting! "1C"), yang dalam beberapa konfigurasi tidak mengizinkan pemilihan dokumen saat mengunggah sesuai dengan detail pemilihan. Sebab, dalam aturan baku, pemilihan dokumen dilakukan berdasarkan permintaan tanpa menentukan jangka waktu. Permintaan seperti itu tidak selalu berhasil.

Dengan cara serupa, Anda dapat mengunggah direktori, bukan seluruh direktori, tetapi dengan memilih berdasarkan beberapa detail. Pertama, pilih aturan pengunggahan data yang diinginkan, lalu tekan tombol “ Instal PVD" Dan " Tambahkan kondisi". Misalnya, Gambar 6.2 menunjukkan bagaimana Anda hanya dapat menurunkan karyawan yang bersamanya pada saat transisi dari program " 1C: Sistem perpajakan yang disederhanakan, ed. 1.3" ke " 1C: Akuntansi Perusahaan, edisi 3.0"(atau, seperti yang sering dikatakan pengguna, transisi dari akuntansi 7.7 ke 3.0) hubungan kerja telah terjalin.



Gbr.6.2 Cara memilih sekelompok elemen direktori

Penting! Kesalahan dalam aturan standar telah diperbaiki dalam aturan yang diusulkan untuk transfer data (dari perusahaan "1C"), yang menyebabkan pemilihan elemen direktori yang salah saat membongkar menggunakan detail direktori periodik, mis. yang memiliki nilai berbeda yang ditetapkan untuk tanggal berbeda. Hal ini disebabkan oleh fakta bahwa dalam aturan standar, pemilihan elemen direktori dilakukan dengan query tanpa menentukan periode.

Pemilihan berdasarkan rincian periodik direktori dilakukan pada tanggal parameter “ Tanggal akhir«.

Anda dapat menggunakan kombinasi aturan pengunggahan data dan pemilihan. Aturan yang pilihannya telah ditetapkan akan ditandai sebagai "[PILIHAN]". Untuk melihat atau mengedit pilihan aturan pengunggahan data tertentu, Anda perlu mengklik dua kali aturan ini di daftar aturan atau, setelah memilihnya, klik tombol " Instal PVD«.

Penting! Jika pengunggahan objek ternyata kosong atau tidak lengkap, Anda perlu memeriksa apakah mode sinkronisasi diatur dengan 1C:Akuntansi 8. Jika demikian, maka hanya objek yang diubah setelah transfer yang akan diunggah (Directory.Synchronous Accounting Parameter menyimpan parameter Posisi Dokumen yang Terakhir Diunggah, yang diperiksa selama pengunggahan oleh fungsi Periksa Kemungkinan Pengunggahan). Pengoperasian penuh dalam mode sinkronisasi menjadi tidak mungkin. Mode sinkronisasi diperiksa setelah memuat aturan pertukaran. Jika mode ini diinstal, jendela peringatan akan dibuat (lihat Gambar 6.5) dan Anda akan diminta untuk menonaktifkan mode sinkronisasi.



Beras. 6.5 Jendela peringatan mode sinkronisasi

Perbedaan tambahan dari aturan standar

Memperbaiki error pada transfer PT&U dengan tipe resi lama: jika pada dokumen Resi Barang dan Jasa tipe resi sama dengan 2 (nilai kadaluarsa) dan tidak ada invoice pemasok, kesalahan konversi dokumen ini di BP 3.0 menjadi retur dokumen dari pembeli terjadi.

Kesalahan telah diperbaiki saat mentransfer operasi manual yang memiliki sub-akun Divisi ke BP versi PROF. Operasi seperti itu tidak dicatat di BP; terjadi kesalahan: “Bidang Divisi harus kosong.” Hal ini disebabkan oleh fakta bahwa aturan dirancang untuk bekerja dengan versi CORP, namun, di PROF, dimensi DivisionDt dan DivisionKt dari register akuntansi harus kosong.

Memperbaiki bug yang menyebabkan duplikasi grup direktori Perjanjian dan, sebagai konsekuensinya, duplikasi elemen direktori ini (karena pencarian selama pemuatan dilakukan dengan mempertimbangkan induknya). Hal ini diilustrasikan pada Gambar 6.6.



Gambar.6.6 Hasil transfer direktori Perjanjian aturan standar

Di sini, di kolom Induk(grup direktori) dengan nama 2015 Ada dua grup direktori berbeda dengan nama yang sama (hanya ada satu grup di sumbernya), oleh karena itu kontraknya diduplikasi.

Memperbaiki kesalahan dalam mentransfer dokumen bank saat mentransfer uang dari satu rekening giro ke rekening lainnya. DI DALAM BP 3.0 dalam hal ini dokumen dibuat Mendebit dari rekening giro dengan jenis operasinya Transfer ke akun lain organisasi, yang tidak dilakukan karena rinciannya tidak diisi Rekening penerima. Selain itu, rincian yang diisi salah. Akun Dan Rekening debet. Ini akan muncul jika berbeda, misalnya 55 dan 51, maka perlu ditukar. Memperbaiki kesalahan tidak mengisi detail Jenis kewajiban dalam dokumen transfer pajak. Semua hal di atas berlaku untuk rilis 3.0.43.215.

Alat peraga ditransfer Kesepakatan utama direktori Pihak rekanan.

Aturan untuk mengunduh direktori telah diubah Tata nama, sekarang metode pemilihan data adalah pengambilan sampel standar, yang memungkinkan Anda memilih elemen direktori berdasarkan detail (dalam aturan standar sistem pajak yang disederhanakan 7.7 - BP 3.0 hal ini tidak dimungkinkan). Saat mentransfer direktori Tata nama, ditransfer dan Harga barang melalui tautan, mis. harga hanya item nomenklatur yang ditransfer. Untuk mengaktifkan fitur ini, Anda perlu menyetel nilai parameter ke satu Unggah harga saat membongkar barang.

Kesalahan telah diperbaiki dalam aturan standar "STS 7.7 - BP 3.0" saat mentransfer saldo untuk penyelesaian dengan pihak lawan: jenis perjanjian selalu ditetapkan ke Lainnya. Sekarang - tergantung pada jenis saldo, menurut bagian akuntansi " Penyelesaian dengan pemasok dan kontraktor"jenis kontrak = " Dengan pemasok", menurut bagian akuntansi" Penyelesaian dengan pembeli dan pelanggan"jenis kontrak = " Dengan pembeli", dalam kasus lain, tipe kontrak = " Lainnya«.

Kesalahan telah diperbaiki dalam aturan standar "USN 7.7 - BP 3.0" saat mentransfer saldo untuk penyelesaian dengan pihak lawan: jumlah penyelesaian bersama dicatat dalam dua rincian dokumen untuk memasukkan saldo awal Jumlah Dan JumlahKt. Oleh karena itu, dokumen pencatatan saldo awal tidak diposting.

MemeriksaDengan pembeli"(dalam aturan standar" Lainnya"). Nilai atribut " telah ditetapkan Status pembayaran“, ini penting untuk memilih faktur pembayaran kepada pembeli dengan benar dalam dokumen pembayaran bank di Konfigurasi Penerima.

Saat mentransfer dokumen formulir " Perintah pembayaran» jenis kontrak disetel ke nilai « Dengan pemasok"(dalam aturan standar" Lainnya«).

Kesalahan telah diperbaiki dalam aturan standar "USN 7.7 - BP 3.0" saat mentransfer lokasi penyimpanan: atribut " tidak diisi Tipe gudang«.

Parameter yang ditambahkan" Pertukaran dengan otoritas pengatur disertakan": jika nilainya 1, maka prop Jenis Pertukaran dengan Otoritas Kontrol elemen direktori " Organisasi" disetel ke " PertukaranDalam Format Universal", jika tidak di" ExchangeDinonaktifkan"seperti dalam aturan standar. Hal ini penting untuk transfer berulang (reguler), agar tidak merusak pengaturan EDI.

Aturan pencarian item yang diunduh untuk direktori " telah diubah Pihak rekanan": pertama-tama pencarian dilakukan oleh TIMAH Dan pos pemeriksaan(jika nilai-nilai ini diisi), maka hanya dengan TIMAH dan akhirnya lewat Nama. Dalam ketiga kasus tersebut, pencarian melibatkan atribut grup (Grup Ini) dan grup itu sendiri (Induk). Hal ini penting untuk transfer berulang (reguler), agar tidak membuat duplikat untuk rekanan dengan nama yang diubah SETELAH pemuatan.

Saat mentransfer rekanan, isi detailnya Pendaftaran Negara berarti "Rusia". Ini diperlukan agar setelah memuat direktori rekanan ke dalam program "1C Akuntansi 8" Saya tidak perlu mengisi rincian yang diperlukan secara manual Pendaftaran Negara. Jika tidak diisi, maka berupa elemen direktori " Pihak rekanan» detail akan tersedia « Nomor pajak" Dan " Reg. nomor"dan detailnya" TIMAH" Dan " pos pemeriksaan" akan disembunyikan.

Aturan pengunggahan data untuk mentransfer direktori “Karyawan” telah ditambahkan ke aturan transfer “USN 7.7 - BP 3.0” (dalam aturan standar, hanya direktori individu yang ditransfer).

Dalam aturan transfer “USN 7.7 - BP 3.0”, aturan transfer untuk register informasi Tarif Tarif Pegawai Saat Ini telah diperbaiki.

Fitur mentransfer perintah pembayaran untuk pembayaran pajak

Untuk perintah pembayaran dengan jenis transaksi Transfer pajak Rincian tambahan harus diisi: KBK - kode klasifikasi anggaran, status penyusun, dll. Struktur detail ini ada di Bukh 7.7 (USN 7.7) dan masuk BP 3.0 tidak cocok. Khususnya di BP 3.0 Beberapa rincian ini disertakan dalam direktori terpisah, tautannya terdapat dalam perintah pembayaran. Direktori Jenis pajak dan pembayaran anggaran berisi sejumlah elemen yang disediakan yang muncul di basis informasi, misalnya saat mengedit kebijakan akuntansi. Saat mentransfer data, elemen ini juga akan muncul saat memuat kebijakan akuntansi. Saat mengunggah dan mengunduh perintah pembayaran, elemen direktori Jenis pajak dan pembayaran anggaran dicari menggunakan KBK untuk substitusi ke dalam rincian perintah pembayaran Pajak. Oleh karena itu, disarankan agar setelah mentransfer kebijakan akuntansi, Anda memeriksa apakah semua pajak yang diperlukan muncul di direktori dan, jika perlu, melengkapinya. Dalam membandingkan (sinkronisasi) KBK dalam perintah pembayaran, sumber dan penerima tidak memperhitungkan empat kategori KBK, kategori 14-17, kode subtipe pendapatan: pajak, denda, denda, dll. Di direktori Jenis pajak dan pembayaran anggaran bit-bit ini diisi dengan nol. Saat menambahkan elemen baru ke direktori, bit 14-17 juga harus diisi dengan angka nol.

Transfer database informasi yang besar.

Pertama-tama, saat mentransfer basis informasi yang besar, proses pengunduhan data bisa memakan waktu yang sangat lama. Hal ini terjadi jika terdapat banyak sekali saldo dalam satu bagian akuntansi, misalnya saldo barang. Untuk mengurangi waktu upload, Anda bisa menggunakan teknik pemisahan satu dokumen” Memasukkan saldo awal"untuk beberapa. Jika Anda menetapkan nilai parameter " Jumlah baris dalam dokumen entri saldo» berbeda dengan nol (lihat Gambar 6.3), maka pengunggahan data ke dalam satu dokumen akan dibatasi pada nilai yang ditentukan. Hal ini dapat mengurangi waktu pembongkaran secara signifikan (beberapa kali).



Gambar.6.3 Mengatur parameter saat mentransfer data dengan batasan ukuran dokumen " Memasukkan saldo awal»

Catatan: nilai parameter membatasi jumlah baris tabel transaksi yang diunggah ke dalam satu dokumen" Memasukkan saldo awal", daripada menentukan jumlah baris dokumen itu sendiri. Oleh karena itu, jumlah baris dokumen akan berbeda dari nilai parameter; ini bukan kesalahan. Saat memisahkan dokumen " Memasukkan saldo awal” untuk beberapa dokumen, postfix akan ditambahkan ke komentar setiap dokumen di akhir baris: “-1”, “-2”, dll.

PENTING! Algoritma yang dijelaskan untuk memisahkan satu dokumen " Memasukkan saldo awal"beberapa digunakan hanya untuk mengurangi waktu pengunggahan data; semua dokumen diunggah ke dalam satu file, mis. Transfer data terjadi dalam satu langkah, komentar (postfix) dihasilkan secara otomatis, hanya satu parameter yang ditentukan. Namun teknik ini tidak menyelesaikan masalah kekurangan memori yang akan dibahas di bawah ini.

Saat memigrasikan basis informasi besar, masalah kehabisan RAM mungkin muncul: ketika Anda mencoba membongkar, program akan berakhir dengan pesan kesalahan yang sesuai atau tanpa pesan. Mencoba mengganti komputer Anda dengan yang lebih bertenaga tidak ada gunanya. Dalam hal ini, Anda harus mengunggah data dalam beberapa bagian, membaginya menjadi beberapa bagian. Hal ini memerlukan aturan transfer yang mendukung mode yang ditentukan. Mari kita lihat cara membongkarnya. Pertama, transfer data harus dilakukan hanya dengan menggunakan satu aturan pengunggahan (lihat Gambar 6.4). Jika transfer tidak mungkin dilakukan menurut satu aturan, maka kami membaginya menjadi beberapa bagian, menunjukkan nomor bagian awal dan akhir. Setiap bagian akan berisi informasi untuk sejumlah nilai analitik tingkat pertama tertentu, misalnya saldo produk, mis. jumlah nilai saldo akun yang ditentukan “41”. Mengetahui jumlah total analitik untuk sebuah akun, mudah untuk menghitung jumlah porsi. Berapa banyak data yang ditransfer tanpa masalah pada satu waktu (menjadi satu informasi) harus ditentukan secara eksperimental; sebagai aturan, saat mengunggah saldo akun, masalah transfer muncul ketika jumlah saldo beberapa ribu atau lebih. Meskipun demikian, untuk menghemat waktu dalam mengunggah data, kami menyarankan untuk membaginya menjadi beberapa bagian, meskipun memungkinkan untuk mengunggah semua saldo di bagian akuntansi sekaligus. Waktu upload tergantung besar kecilnya porsi data, tidak proporsional, tidak linier. Oleh karena itu, dengan membagi, misalnya, sepuluh ribu saldo produk menjadi sepuluh bagian dari seribu, Anda dapat mengurangi waktu pembongkaran beberapa kali lipat. Jika kita memindahkan bagian pertama, nomor bagian awal tidak dapat dicantumkan; jika bagian terakhir dipindahkan, maka nomor bagian akhir tidak dapat dicantumkan.

PENTING! Saat mentransfer data sebagian, perlu untuk menentukan postfix di parameter, yang terlibat dalam pembentukan komentar dokumen “ Memasukkan saldo awal" Saat mengubah nomor rentang porsi, Anda harus ingat untuk mengubah postfix, jika tidak, saat memuat ke Konfigurasi penerima, dokumen dengan komentar yang sama (postfix) akan ditimpa. Nama file data tidak terlalu penting. Anda dapat menggunakan taktik transfer berurutan: bongkar - muat, bongkar - muat, dll. Dalam hal ini, nama file data tidak perlu diubah. Anda dapat memilih taktik: pertama bongkar semuanya, lalu muat semuanya. Dalam kasus terakhir, nama file data harus diubah setiap kali diunggah. Satu contoh lagi. Jika jumlah saldo pada bagian akuntansi (misalnya barang) misalkan 10.000, kita bagi menjadi bagian seribu, maka kita mendapat 10 porsi. Setiap bagian harus memiliki postfix unik: "-1", "-2", "-3", "-4". Jika kita membongkar semua sisa barang lalu memuat semuanya, maka file datanya juga harus unik, misalnya: “41_1”, “41_2”, “41_3”, “41_4”. Parameter “Nomor porsi awal” dan “Nomor porsi akhir” harus mengambil nilai berikut: 0, 1000; 1001, 2000; 2001, 3000; 3001, 4000.

• Ketika masa kerja terganggu setelah pemecatan Sejak 1 Januari 2007, prosedur yang sedikit berbeda telah diberlakukan untuk menentukan kelangsungan pengalaman kerja warga negara. Sebelumnya, jika tidak lewat waktu 3 minggu saat berpindah dari satu tempat kerja ke tempat kerja lainnya, maka masa kerja tidak terputus. Sejak tahun 2007 […]
• ANKO Tambov Pusat Keahlian dan Penelitian Forensik, ANO ANO Pusat Keahlian dan Penelitian Forensik Tambov, ANO terdaftar di Tambov, Rabochaya St., 37, kantor 40, 392008. DIREKTUR organisasi ORGANISASI NON-PROFIT OTONOM PUSAT PERADILAN TAMBOV [… ]
• Urutan jadwal waktu kerja Contoh urutan jadwal waktu kerja Pada jadwal waktu kerja Sesuai dengan Pasal 100, 103, 104, 73 dari Kode Perburuhan Federasi Rusia dan Peraturan Perburuhan Internal "Organisasi" PJSC, secara berurutan untuk mengoperasikan perusahaan secara optimal dan meningkatkan […]
• Di Rumah Sakit Pusat Kota No. 20 Yekaterinburg, tempat dokter kepala dipecat, sebuah perusahaan penjabat telah ditunjuk | Wilayah Sverdlovsk | Distrik Federal Ural Alena Tunis ditunjuk sebagai penjabat kepala dokter di rumah sakit pusat kota No. 20 di Yekaterinburg. Seperti yang dilaporkan koresponden [...]
• Hukum Ohm untuk Paralel Rumah Ingat Fisika: Kelas 7 Kelas 8 Kelas 9 Kelas 10-11 Video Fisika Multimedia Kelas 7. multimedia kelas 8 multimedia kelas 9 multimedia kelas 10-11. tes astronomi kelas 7 tes kelas 8. tes kelas 9 tabel demonstrasi Ujian Negara Bersatu [...]
• Undang-undang RSFSR “Tentang persaingan dan pembatasan kegiatan monopoli di pasar komoditas” tanggal 22 Maret 1991 N 948-1 (sebagaimana diubah dengan Undang-undang Federasi Rusia tanggal 24 Juni 1992 N 3119-1, tanggal 15 Juli 1992 N 3310 -1;

Kini pengguna "1C: Accounting 7.7" tidak perlu menunggu hingga akhir tahun untuk beralih ke "1C: Accounting 8". Peralihan dapat dilakukan pada akhir bulan mana pun dalam masa pajak. Teknologi transfer saldo telah diuji di perusahaan yang ada, salah satunya dijelaskan oleh spesialis dari Automated Accounting Systems LLC. Artikel ini berisi penjelasan tentang metodologi transfer dan rekomendasi umum untuk kontrol input dan output data yang ditransfer.

Sebelum pindah ke Laima LLC (Miass, wilayah Chelyabinsk), program “1C: Accounting 7.7. Program ini diinstal pada laptop. Pekerjaan dilakukan di kantor pusat.

Peluncuran metodologi transfer data baru oleh 1C dan volume kecil basis informasi memungkinkan transfer data untuk tahun 2006 langsung pada saat instalasi 1C: Accounting 8.

Metode transfer data

Metode transisi baru dari "1C: Accounting 7.7" ke "1C: Accounting 8" yang disertakan dalam rilis 1.5.8.5 menyediakan transfer data dari basis informasi "1C: Accounting 7.7", yang akan memastikan eksekusi yang benar di " 1C: Akuntansi 8" dari tindakan berikut:

• pelaksanaan dokumen yang diterbitkan setelah transisi ke "1C: Accounting 8";
• pembentukan register akuntansi untuk periode pelaporan berjalan (neraca, buku besar, dll);
• pembentukan register akuntansi pajak untuk periode pelaporan berjalan, yang memuat indikator-indikator yang ditentukan berdasarkan akrual sejak awal tahun;
• pembuatan pelaporan yang diatur untuk periode pelaporan berjalan.

Peralihan dari "1C: Accounting 7.7" ke "1C: Accounting 8" dengan cara ini disarankan dilakukan pada awal masa (tahun) pajak baru atau jika sudah dibuka masa pajak baru, maka di akhir bulan berikutnya pada periode pelaporan berjalan. Selama proses transfer data ke 1C: Accounting 8, informasi berikut dimuat:

• saldo rekening akuntansi dan pajak pada awal periode pelaporan berjalan (per 1 Januari tahun berjalan);
• perputaran akun akuntansi dan pajak untuk periode pelaporan berjalan dengan entri bulanan konsolidasi;
• perbedaan temporer yang tercermin dalam akun pajak terkait (untuk organisasi yang menerapkan PBU 18/02);
• dokumen pemasukan saldo awal aset tetap dan aset tidak berwujud;
• dasar pengenaan pajak penghasilan orang pribadi dan pajak gaji untuk periode pelaporan berjalan;
• pembayaran terutang atas tagihan yang diterima dan diterbitkan pada akhir bulan tertutup terakhir periode pelaporan berjalan;
• informasi tentang objek akuntansi analitik.

Operasi persiapan di "1C: Accounting 7.7"

Transfer data dari "1C: Accounting 7.7" dimungkinkan mulai dari rilis 7.70.477. Oleh karena itu, sebelum melakukan migrasi, konfigurasi ke rilis ini perlu diperbarui.

Penting juga untuk memastikan bahwa operasi akuntansi rutin dan akuntansi pajak telah dilaksanakan selama bulan terakhir tahun ini (termasuk reformasi neraca).

Semua file yang diperlukan untuk transfer data terdapat dalam folder Convert di direktori template rilis 1.5.8.5 "1C: Accounting 8". Lebih baik menyalin isi folder ini ke direktori ExtForms dari database informasi 1C: Accounting 7.7.

Metode transfer menyediakan satu operasi persiapan - memeriksa kode direktori, yang mungkin menjadi tidak unik saat mentransfer data ke 1C: Accounting 8. Pemrosesan eksternal ChkCode.ert digunakan untuk verifikasi.

Namun, untuk memverifikasi kebenaran akuntansi dan akuntansi pajak dalam database "1C: Accounting 7.7" dan tidak mentransfer entri yang sengaja salah ke "delapan", ada baiknya untuk melakukan analisis teknologi akuntansi (Menu "Laporan -> Analisis teknologi akuntansi" ), serta analisis keadaan akuntansi pajak (“Akuntansi pajak -> Analisis keadaan akuntansi pajak”).

Biasanya, masalah disebabkan oleh entri “manual” yang dibuat tanpa mengontrol saldo awal, akuntansi kuantitatif, dll. Teknik baru ini bahkan mentransfer transaksi tersebut dengan benar, namun kontrol masuk memungkinkan Anda untuk segera mengidentifikasi masalah dan mengeluarkan rekomendasi untuk memperbaikinya.

Dalam kasus kami, kontrol mengungkapkan perbedaan dalam akuntansi mengenai penghapusan penyusutan aset tetap atas kerugian periode sebelumnya, yang diputuskan untuk diperbaiki di “1C: Akuntansi 8” setelah transisi.

Perpindahan data

Transfer datanya sendiri dilakukan menggunakan pemrosesan eksternal V77Exp.ert (menu "File -> Open"). Dialog pemrosesan menunjukkan:

• file aturan konversi data - Acc77_80.xml (bidang "Nama file aturan");
• file tempat data akan diunggah (bidang "Nama file data");
• tanggal mulai periode pelaporan saat ini - 1 Januari 2006 (bidang "Tanggal mulai");
• tanggal akhir bulan terakhir yang ditutup pada periode saat ini (bidang Tanggal Akhir). Dalam kasus kami, 31 Mei 2006.

Setelah mengklik tombol "Muat aturan pertukaran", daftar aturan pengunggahan data akan diisi dalam dialog pemrosesan. Daftar yang dimuat adalah daftar akun, yang hasilnya dapat diunduh, dan direktori yang dapat ditransfer ke konfigurasi "Akuntansi Perusahaan". Pada tabel di sebelah kanan, Anda dapat mengatur pilihan berdasarkan nilai detail untuk sebagian besar aturan pengunggahan data (misalnya, untuk pengunggahan item secara selektif).

Karena kami mentransfer data dari "tujuh", saat pertama kali meluncurkan 1C: Accounting 8, Anda harus mengabaikan pengisian awal database. Setelah itu menggunakan pemrosesan pemuatan data (menu "Tools -> Pertukaran data -> Pertukaran data universal dalam format XML"), kita memuat file transfer ke gambar delapan.

Penyelidikan

Seluruh prosedur transfer data memakan waktu tidak lebih dari setengah jam. Yang tersisa hanyalah memastikan bahwa semua data ditransfer dengan benar. Di sini yang terbaik adalah memulai dengan neraca untuk periode transfer data. Untuk akun neraca, laporan yang dihasilkan di “1C: Accounting 7.7” dan “1C: Accounting 8” harus cocok. Jika omset pada akun mana pun tidak cocok, maka perlu dibuat laporan yang lebih rinci (neraca atau kartu omset) untuk akun ini untuk menentukan omzet mana yang tidak ditransfer. Dengan demikian, Anda dapat memeriksa semua data, kecuali saldo aset tetap dan aset tidak berwujud, dasar pengenaan pajak penghasilan pribadi dan pajak gaji untuk periode pelaporan berjalan dan utang pembayaran faktur yang diterima dan diterbitkan pada akhir penutupan terakhir. bulan periode pelaporan berjalan.

Dalam kasus kami, dalam "1C: Akuntansi 7.7" data tentang aset tetap tidak dimasukkan secara lengkap, dan dalam "delapan" dokumen "Memasukkan saldo awal aset tetap" tidak dimasukkan, dan karenanya, tidak ada saldo pada awal periode untuk akun 01. Dokumen-dokumen ini telah diperbaiki secara manual.

Subsistem akuntansi PPN diimplementasikan dalam "1C: Akuntansi 8" pada register; untuk memeriksa kebenaran transfer, Anda harus menggunakan laporan universal "Saldo dan Perputaran" (Laporan -> Saldo dan Perputaran) tanpa membatasi periode akuntansi bagian "PPN yang disajikan", "PPN di muka" untuk menganalisis kebenaran transfer rekening ZPK dan ZPR.

Mungkin setiap spesialis 1C menghadapi kebutuhan untuk mentransfer data dari satu basis informasi ke basis informasi lainnya. Jika konfigurasinya berbeda, Anda harus menulis aturan konversi data. Aturan-aturan ini dibuat dalam konfigurasi "Konversi Data" 1C.

Data juga dapat ditransfer menggunakan . Banyak konfigurasi 1C 8.3 memiliki fungsionalitas standar untuk mengatur sinkronisasi data antara konfigurasi yang berbeda dan integrasi tanpa batas dengan 1C Document Flow.

Namun ketika data perlu ditransfer antara konfigurasi yang benar-benar identik, Anda dapat menyederhanakan tugas Anda dan menggunakan pemrosesan standar untuk mengunggah dan mengunduh melalui XML. Harap dicatat bahwa metode ini, seperti konversi data, membandingkan objek satu sama lain berdasarkan pengidentifikasi unik (GUID), dan bukan berdasarkan nama.

Anda dapat mendownload pemrosesan ini pada disk ITS, atau menggunakan link:

Ini bersifat universal dan cocok untuk konfigurasi apa pun.

Mari kita perhatikan contoh membongkar direktori "Nomenklatur" dari satu basis informasi 1C 8.3 Accounting 3.0 ke basis informasi lainnya. Prasyaratnya adalah seleksi oleh induk (grup) “Woodworking”.

Mengunggah data dari 1C ke XML

Buka basis informasi dari mana data akan diunduh (sumber). Pastikan untuk memeriksanya, dengan mempertimbangkan semua kondisi yang mungkin terjadi untuk menghindari konsekuensi yang tidak diinginkan.

Buka pemrosesan unggah dan unduh data XML (Ctrl+O).

Kami tertarik pada tab "Unggah". Pertama-tama, tentukan nama file tempat data akan diunggah dan jalur penyimpanannya. Dalam hal ini, data diunggah “Ke file di server.”

Di header pemrosesan, Anda dapat mengonfigurasi periode pemilihan akan dilakukan. Selain itu, untuk register periodik, Anda dapat menentukan metode penerapan seleksi berdasarkan periode. Jika perlu mengunggah pergerakan bersama dengan dokumen, bendera yang sesuai disetel. Dalam hal ini, kami membebani direktori secara berlebihan, jadi tidak perlu mengonfigurasi apa pun di header.

Mari beralih ke memilih data untuk diunggah. Di bagian tabel formulir pemrosesan, pilih kotak centang untuk objek konfigurasi yang perlu Anda transfer.

Kolom “Bongkar jika perlu” berarti apakah perlu membebani objek ini jika direferensikan oleh atribut direktori yang kita bebankan berlebihan. Misalnya posisi barang yang Anda muat memiliki satuan ukuran yang tidak ada dalam database target. Jika bendera pada kolom “Unggah jika perlu” dicentang di seberang buku referensi dengan satuan pengukuran, posisi baru akan dibuat. Jika tidak, nilai atributnya adalah “<Объект не найден>" dan pengenal uniknya.

Dalam kasus sederhana tanpa pilihan, pengaturan kelebihan item akan terlihat seperti ini.

Dalam contoh ini, Anda hanya perlu memilih item yang terletak di folder “Woodworking”.

Pemrosesan serupa untuk 8.2 memungkinkan Anda mengatur pilihan untuk setiap objek konfigurasi dalam bentuk yang mudah. Sayangnya, di 8.3, fungsi seperti itu tidak ada. Salah satu jalan keluar dalam situasi ini adalah dengan memilih item yang diperlukan pada tab “Objek tambahan untuk dibongkar”.

Anda dapat menambahkan objek di sini secara manual (tombol “Tambah”) atau berdasarkan permintaan (“Tambahkan berdasarkan permintaan…”). Jika jumlahnya banyak, opsi kedua lebih disukai.

Dalam hal ini, permintaannya adalah sebagai berikut. Isi parameternya, selesaikan permintaan setelah memeriksa data, dan klik tombol “Pilih hasil”.

Setelah Anda menentukan semua objek yang diperlukan dan elemen tambahan untuk diunggah, klik tombol “Unggah data”. Mereka akan berakhir di file XML, nama dan jalur yang Anda tentukan sebelumnya. Hasil operasi ini akan ditampilkan dalam pesan.

Dalam contoh ini, hanya 3 posisi yang perlu dibongkar, tetapi lima posisi dibongkar. Ini karena sebuah bendera dipasang di seberang direktori “Nomenklatur” di kolom “Unggah jika perlu”. Seiring dengan posisi yang diperlukan, orang tua mereka juga kelebihan beban.

Memuat direktori dari XML

Setelah berhasil mendownload data dari konfigurasi sumber ke dalam file XML, buka database tujuan. Struktur benda dan detailnya harus cocok satu sama lain. Dalam hal ini, transfer dilakukan antara dua konfigurasi standar 1C: Accounting 3.0.

Buka pemrosesan di database penerima. Pemrosesan ini digunakan untuk mengunggah dan memuat data. Buka tab "Unduh" dan tentukan jalur ke file XML tempat data diunduh sebelumnya. Setelah itu, klik tombol “Unduh data”.

Hasil pengunduhan akan ditampilkan dalam pesan. Dalam kasus kami, semuanya berjalan dengan baik.

Direktori “Nomenklatur” di database penerima tidak diisi. Kini ia memiliki lima elemen: tiga posisi nomenklatur dan dua kelompok.

Memigrasikan data antar konfigurasi yang berbeda bukanlah tugas yang mudah. Seperti biasa, ada beberapa solusi, namun tidak semuanya optimal. Mari kita coba memahami nuansa transfer data dan memilih strategi universal untuk menyelesaikan masalah tersebut.

Masalah migrasi data (kita berbicara murni tentang produk perusahaan 1C) dari satu solusi ke solusi lainnya tidak muncul kemarin. Perusahaan 1C memahami betul kesulitan apa yang dihadapi pengembang saat membuat migrasi, sehingga mereka mencoba dengan segala cara untuk membantu dengan alat.

Selama pengembangan platform, perusahaan memperkenalkan sejumlah alat universal, serta teknologi yang menyederhanakan transfer data. Mereka dibangun ke dalam semua solusi standar dan masalah migrasi antara konfigurasi yang identik secara umum telah teratasi. Kemenangan ini sekali lagi dikonfirmasi oleh integrasi yang erat dari solusi standar.

Dengan migrasi antar solusi non-standar, situasinya menjadi lebih rumit. Beragamnya pilihan teknologi memungkinkan pengembang untuk secara mandiri memilih cara terbaik untuk memecahkan masalah dari sudut pandang mereka.

Mari kita lihat beberapa di antaranya:

• pertukaran melalui file teks;
• penggunaan rencana pertukaran;
• dll.

Masing-masing memiliki kelebihan dan kekurangannya masing-masing. Singkatnya, kelemahan utama adalah verbositasnya. Penerapan algoritma migrasi secara independen memerlukan banyak waktu dan proses debugging yang lama. Saya bahkan tidak ingin berbicara tentang dukungan lebih lanjut terhadap keputusan tersebut.

Kompleksitas dan tingginya biaya dukungan mendorong perusahaan 1C untuk menciptakan solusi universal. Teknologi yang memungkinkan untuk menyederhanakan pengembangan dan dukungan migrasi sebanyak mungkin. Hasilnya, ide tersebut diimplementasikan dalam bentuk konfigurasi terpisah – “Konversi Data”.

Konversi data - solusi standar, konfigurasi independen. Setiap pengguna dengan langganan “ITS:Prof” dapat mengunduh paket ini secara gratis dari situs dukungan pengguna atau disk ITS. Instalasi dilakukan dengan cara standar - seperti semua solusi standar lainnya dari 1C.

Sekarang sedikit tentang keuntungan dari solusi tersebut. Mari kita mulai dengan hal yang paling penting - keserbagunaan. Solusinya tidak disesuaikan dengan konfigurasi/versi platform tertentu. Ia bekerja sama baiknya dengan konfigurasi standar dan kustom. Pengembang memiliki teknologi universal dan pendekatan standar untuk menciptakan migrasi baru. Fleksibilitas solusi ini memungkinkan Anda mempersiapkan migrasi bahkan untuk platform selain 1C:Enterprise.

Nilai tambah besar kedua adalah alat bantu visual. Migrasi sederhana dibuat tanpa pemrograman. Ya, ya, tanpa satu baris kode pun! Untuk hal ini saja, ada baiknya meluangkan waktu untuk mempelajari teknologinya satu kali, dan kemudian menggunakan keterampilan yang sangat berharga berulang kali.

Keuntungan ketiga yang ingin saya catat adalah tidak adanya pembatasan distribusi data. Pengembang sendiri yang memilih metode pengiriman data ke konfigurasi penerima. Ada dua opsi yang tersedia: mengunggah ke file xml dan koneksi langsung ke basis info (COM/OLE).

Mempelajari arsitektur

Kita sudah tahu bahwa konversi data dapat memberikan hasil yang luar biasa, namun belum sepenuhnya jelas apa keuntungan teknisnya. Hal pertama yang perlu Anda pahami adalah bahwa setiap migrasi (konversi) data didasarkan pada aturan pertukaran. Aturan pertukaran adalah file xml biasa yang menjelaskan struktur tempat data keamanan informasi akan diunggah. Pemrosesan layanan yang mengunggah/mengunduh data menganalisis aturan pertukaran dan melakukan pengunggahan berdasarkan aturan tersebut. Selama pemuatan, proses sebaliknya terjadi.

Konfigurasi "CD" adalah sejenis konstruktor visual yang dengannya pengembang membuat aturan pertukaran. Ia tidak tahu cara mengunduh data. Pemrosesan layanan eksternal tambahan yang disertakan dalam paket distribusi CD bertanggung jawab untuk hal ini. Ada beberapa di antaranya (XX pada nama file adalah nomor versi platform):

• MDXXExp.epf- pemrosesan memungkinkan Anda mengunggah deskripsi struktur infobase ke file xml. Deskripsi struktur dimuat ke dalam CD untuk analisis lebih lanjut dan pembuatan aturan pertukaran.
• V8ExchanXX.epf- mengunggah/mengunduh data dari basis informasi sesuai dengan aturan pertukaran. Pada sebagian besar konfigurasi umum, pemrosesan dilakukan secara langsung (lihat item menu “Layanan”). Pemrosesan bersifat universal dan tidak terikat pada konfigurasi/aturan tertentu.

Oke, sekarang berdasarkan semua hal di atas, mari kita tentukan tahapan pengembangan konversi baru:

1. Definisi tugas. Penting untuk memahami dengan jelas data apa yang perlu ditransfer (dari objek konfigurasi mana) dan, yang paling penting, ke mana harus mentransfernya.
2. Persiapan deskripsi struktur konfigurasi (Sumber/Sink) untuk pemuatan selanjutnya ke dalam CD. Masalahnya diselesaikan dengan pemrosesan layanan MDXXExp.epf.
3. Memuat deskripsi struktur yang telah disiapkan ke dalam keamanan informasi.
4. Membuat aturan pertukaran menggunakan alat CD visual.
5. Melakukan upload/download sesuai aturan konversi data yang dibuat menggunakan pemrosesan V8ExchanXX.epf.
6. Men-debug aturan pertukaran (jika perlu).

Konversi paling sederhana

Untuk demonstrasi kita memerlukan dua konfigurasi yang diterapkan. Saya memutuskan untuk memilih opsi: “Manajemen Perdagangan” edisi ke-10 dan solusi kecil yang ditulis sendiri. Tugasnya adalah mentransfer data dari konfigurasi standar “UT”. Untuk singkatnya, sebut saja solusi yang ditulis sendiri sebagai “Sink”, dan manajemen perdagangan “Sumber”. Mari kita mulai menyelesaikan masalah dengan mentransfer elemen dari direktori “Nomenklatur”.

Pertama-tama, mari kita lihat skema konversi data dan baca kembali daftar tindakan yang perlu dilakukan. Kemudian kami meluncurkan konfigurasi "Sumber" dan membuka pemrosesan layanan MD82Exp.epf di dalamnya.

Antarmuka pemrosesan tidak memiliki banyak pengaturan. Pengguna hanya perlu menunjukkan jenis objek metadata yang tidak akan disertakan dalam deskripsi struktur. Dalam kebanyakan kasus, pengaturan ini tidak perlu diubah, karena Tidak ada gunanya melakukan pergerakan bongkar muat menggunakan register akumulasi (sebagai contoh).

Lebih tepat membentuk gerakan sambil memegang dokumen di dalam penerima. Semua perpindahan akan dilakukan oleh dokumen itu sendiri setelah transfer. Argumen kedua yang membela pengaturan default adalah pengurangan ukuran file dengan pengunggahan.

Beberapa dokumen (terutama dalam konfigurasi standar) menghasilkan pergerakan di beberapa register. Membongkar semua hal ini akan membuat file XML yang dihasilkan menjadi terlalu besar. Hal ini dapat mempersulit pengangkutan dan pemuatan selanjutnya ke basis penerima. Semakin besar file datanya, maka semakin besar pula RAM yang dibutuhkan untuk memprosesnya. Selama latihan, saya berkesempatan menemukan file unggahan berukuran tidak senonoh. File-file tersebut sepenuhnya menolak untuk diuraikan menggunakan alat standar.

Jadi, kami membiarkan semua pengaturan default dan mengunggah deskripsi konfigurasi ke file. Kami mengulangi prosedur serupa untuk base kedua.

Buka CD dan pilih di menu utama “Direktori” -> “Konfigurasi”. Direktori menyimpan deskripsi struktur semua konfigurasi yang dapat digunakan untuk membuat konversi. Kami memuat deskripsi konfigurasi satu kali, lalu kami dapat menggunakannya beberapa kali untuk membuat konversi berbeda.

Di jendela direktori, klik tombol “ Menambahkan” dan di jendela yang muncul, pilih file yang menjelaskan konfigurasi. Centang kotak “Muat ke konfigurasi baru” dan klik tombol “Muat”. Kami melakukan tindakan serupa dengan deskripsi struktur konfigurasi kedua.

Sekarang Anda siap membuat aturan pertukaran. Di menu CD utama, pilih “Direktori” -> “Konversi”. Tambahkan elemen baru. Di jendela untuk membuat konversi baru, Anda perlu menentukan: konfigurasi sumber (pilih UT) dan konfigurasi tujuan (pilih “Penerima”). Selanjutnya, buka tab “Lanjutan” dan isi kolom berikut:

• nama file aturan pertukaran - aturan pertukaran yang dibuat akan disimpan dengan nama ini. Anda dapat mengubah nama file kapan saja, namun sebaiknya atur sekarang. Ini akan menghemat waktu di masa depan. Saya memberi nama aturan untuk contoh demo: “rules-ut-to-priemnik.xml”.
• nama - nama konversi. Namanya bisa apa saja, saya membatasi diri pada “Demo. UT ke Penerima.”

Itu saja, klik "Oke". Segera sebuah jendela muncul di depan kita meminta kita untuk membuat semua aturan secara otomatis. Menyetujui tawaran yang menggiurkan tersebut akan memberikan perintah kepada master untuk secara otomatis menganalisis deskripsi konfigurasi yang dipilih dan secara mandiri menghasilkan aturan pertukaran.

Mari kita beri tanda “i” segera. Wizard tidak akan dapat menghasilkan sesuatu yang serius. Namun kemungkinan ini tidak boleh diabaikan. Jika perlu untuk melakukan pertukaran antara konfigurasi yang identik, maka layanan spesialis akan sangat berguna. Sebagai contoh, mode manual lebih disukai.

Mari kita lihat lebih dekat jendela “Pengaturan Aturan Pertukaran”. Antarmukanya mungkin tampak sedikit membingungkan - banyak tab yang penuh dengan kontrol. Faktanya, semuanya tidak begitu sulit; Anda mulai terbiasa dengan kegilaan ini setelah beberapa jam bekerja dengan aplikasi tersebut.

Pada tahap ini, kami tertarik pada dua tab: “Aturan konversi objek” dan “Aturan pengunggahan data”. Pertama-tama, kita harus mengonfigurasi aturan pencocokan, yaitu. membandingkan objek dari dua konfigurasi. Yang kedua, tentukan kemungkinan objek yang akan tersedia bagi pengguna untuk diunggah.

Di paruh kedua tab “Aturan Konversi Objek” terdapat panel tambahan dengan dua tab: “Konversi Properti” dan “ Mengubah nilai" Yang pertama akan memilih properti (detail) dari objek yang dipilih, dan yang kedua diperlukan untuk bekerja dengan nilai yang telah ditentukan sebelumnya (misalnya, elemen direktori yang telah ditentukan atau elemen enumerasi).

Bagus, sekarang mari buat aturan konversi untuk direktori. Anda dapat melakukan tindakan ini dengan dua cara: menggunakan Wizard Sinkronisasi Objek (tombol “”) atau menambahkan korespondensi untuk setiap objek secara manual.

Untuk menghemat ruang, kami akan menggunakan opsi pertama. Di jendela wizard, hapus centang pada grup “ Dokumen” (kami hanya tertarik pada direktori) dan perluas grupnya “ Direktori" Kami dengan hati-hati menelusuri daftarnya dan melihat nama-nama buku referensi yang dapat dibandingkan.

Dalam kasus saya, ada tiga direktori: Nomenklatur, Organisasi, dan Gudang. Ada juga direktori bernama Klien, yang memiliki tujuan yang sama dengan “ Pihak rekanan"dari konfigurasi" UT" Benar, sang master tidak dapat membandingkannya karena namanya berbeda.

Kita bisa memperbaiki masalah ini sendiri. Kami menemukan di jendela “ Kecocokan Objek» buku referensi « Klien", dan pada kolom "Sumber" pilih direktori "Counterparty". Kemudian centang kotak pada kolom “Type” dan klik tombol “Ok”.

Wizard Sinkronisasi Objek akan menawarkan untuk secara otomatis membuat aturan untuk mengonversi properti semua objek yang dipilih. Properti akan dibandingkan berdasarkan nama dan untuk demonstrasi kami ini sudah cukup, kami setuju. Pertanyaan selanjutnya adalah usulan untuk membuat aturan upload. Mari kita setujui juga.

Dasar aturan pertukaran sudah siap. Kami memilih objek untuk sinkronisasi, dan aturan untuk mengonversi properti dan mengunggah aturan dibuat secara otomatis. Mari simpan aturan pertukaran ke file, lalu buka "Sumber" IB (dalam kasus saya ini adalah UT) dan luncurkan pemrosesan layanan di dalamnya V8Exchan82.epf.

Pertama-tama, di jendela pemrosesan, pilih aturan pertukaran yang kita buat. Kami menjawab pertanyaan tentang memuat aturan dengan setuju. Pemrosesan akan menganalisis aturan pertukaran dan membangun pohon objek dengan nama yang sama yang tersedia untuk diunggah. Untuk pohon ini, kita dapat mengatur segala macam pilihan atau pertukaran node, dengan mengubah mana yang kita perlukan untuk memilih data. Kami benar-benar ingin mengunduh semua data, jadi tidak perlu memasang filter.

Setelah selesai proses upload data ke file, masuk ke IB “ Penerima" Kami juga membuka pengolahan di dalamnya V8Exchan82.epf, baru kali ini kita masuk ke tab “Pemuatan Data”. Pilih file data dan klik tombol "Unduh". Selesai, data sudah berhasil ditransfer.

Masalah dunia nyata

Demo pertama mungkin menyesatkan. Semuanya terlihat cukup sederhana dan logis. Faktanya, hal ini tidak sepenuhnya benar. Dalam pekerjaan nyata, timbul masalah yang sulit atau sama sekali tidak mungkin diselesaikan hanya dengan menggunakan sarana visual (tanpa pemrograman).

Agar tidak kecewa dengan teknologinya, saya menyiapkan beberapa masalah kehidupan nyata. Anda pasti akan menemukannya di tempat kerja. Mereka tidak terlihat sepele dan membuat Anda melihat konversi data dari sudut pandang baru. Pertimbangkan dengan cermat contoh-contoh yang disajikan, dan jangan ragu untuk menggunakannya sebagai cuplikan saat memecahkan masalah nyata.

Tugas No.1. Isi detail yang hilang

Misalkan kita perlu mentransfer direktori “ Pihak rekanan" Penerima memiliki direktori “Klien” serupa untuk tujuan ini. Ini sepenuhnya cocok untuk penyimpanan data, tetapi memiliki alat peraga “ Organisasi”, yang memungkinkan Anda memisahkan rekanan berdasarkan keanggotaan organisasi. Secara default, semua rekanan harus menjadi anggota organisasi saat ini (ini dapat diperoleh dari konstanta dengan nama yang sama).

Ada beberapa solusi untuk masalah ini. Kami akan mempertimbangkan opsi untuk mengisi detailnya “ Organisasi“tepat di database” Penerima”, yaitu pada saat memuat data. Organisasi saat ini disimpan secara konstan, oleh karena itu, tidak ada hambatan untuk memperoleh nilai ini. Mari kita buka aturan konversi objek (selanjutnya disebut PKO)” Klien” (klik dua kali pada objek) dan di wizard pengaturan aturan, buka bagian “Event Handler”. Dalam daftar penangan kita akan menemukan “ Setelah mengunduh”.

Mari kita jelaskan kode untuk mendapatkan organisasi saat ini dan kemudian menugaskannya ke detailnya. Pada saat pengendali “Setelah memuat” dipicu, objek akan sepenuhnya terbentuk, tetapi belum ditulis ke database. Tidak ada yang melarang kami mengubahnya sesuai kebijaksanaan kami:

Jika BUKAN Object.ThisGroup Maka Object.Organization = Constants.CurrentOrganization.Get(); akhirJika;

Sebelum mengisi rincian" Organisasi"Penting untuk memeriksa nilai atribut" Ini adalah grup" Untuk buku referensi" Klien“Fitur hierarki sudah diatur, jadi perlu dilakukan pengecekan grup. Isi detail apa pun dengan cara yang sama. Pastikan untuk membaca bantuan untuk opsi penangan lainnya " Setelah Memuat" Misalnya di antaranya ada parameter “ Penolakan" Jika Anda menetapkan nilai "Benar", maka objek tersebut tidak akan ditulis ke database. Dengan demikian, menjadi mungkin untuk membatasi objek yang dapat ditulis pada saat memuat.

Tugas No.2. Detail untuk daftar informasi

Di direktori “ Pihak rekanan"Konfigurasi UT, detail tersedia" Pembeli" Dan " Pemasok" Kedua detail tersebut bertipe “ Boolean” dan digunakan untuk menentukan jenis rekanan. Di IB “ Penerima”, di direktori “ Klien“Tidak ada rincian serupa, tetapi ada daftar informasinya” Jenis Klien" Ia melakukan fungsi serupa dan dapat menyimpan banyak atribut untuk satu klien. Tugas kita adalah mentransfer nilai rincian ke dalam entri terpisah dalam daftar informasi.

Sayangnya, sarana visual saja tidak dapat mengatasi hal ini. Mari kita mulai dari yang kecil, buat perangkat lunak baru untuk register informasi “ Jenis Klien" Jangan mengutip apa pun sebagai sumber. Hindari membuat aturan upload secara otomatis.

Langkah selanjutnya adalah membuat aturan upload. Buka tab yang sesuai dan klik tombol “ Menambahkan" Di jendela untuk menambahkan aturan unggah, isi:

• Metode pengambilan sampel. Ubah ke “Algoritma sewenang-wenang”;
• Aturan konversi. Pilih daftar informasi “Jenis Klien”;
• Kode (nama) aturan. Tuliskan sebagai “Membongkar Jenis Klien”;

Sekarang Anda perlu menulis kode untuk memilih data yang akan diunggah. Parameternya “ Pengambilan Sampel Data" Kita bisa menempatkan koleksi dengan kumpulan data yang sudah disiapkan di dalamnya. Parameter " Pengambilan Sampel Data” dapat mengambil berbagai nilai - hasil kueri, pilihan, kumpulan nilai, dll. Kami menginisialisasinya sebagai tabel nilai dengan dua kolom: klien dan tipe klien.

Di bawah ini adalah kode untuk event handler “ Sebelum diproses" Ini menginisialisasi parameter “ Pengambilan Sampel Data” dilanjutkan dengan mengisi data dari direktori “ Pihak rekanan" Disini anda harus memperhatikan pengisian kolom “ Jenis Klien" Dalam “UT” atribut kita bertipe “Boolean”, dan penerimanya adalah enumerasi.

Pada tahap ini, kita tidak bisa mengonversinya ke tipe yang dibutuhkan (tidak ada di UT), jadi untuk saat ini kita biarkan dalam bentuk string. Anda tidak perlu melakukan ini, tetapi saya segera ingin menunjukkan cara melakukan cast ke tipe yang hilang di sumbernya.

DataFetch = Tabel Nilai Baru(); DataSelection.Columns.Add("Klien"); DataSelection.Columns.Add("Jenis Klien"); SelectingDataFromDirectory = Direktori.Akun.Select(); Saat SelectingDataFromDirectory.Next() Loop Jika SelectingDataFromDirectory.ThisGroup Kemudian Lanjutkan;

akhirJika; Jika Pemilihan Data Dari Direktori.Pembeli Maka NewRow = Pemilihan Data.Tambah(); NewRow.Client = DataFetchFromDirectory.Link; Jenis Klien NewRow.ClientType = "Pelanggan";

akhirJika;

Dalam listing, rinciannya diisi berdasarkan sampel data yang dipilih. Kami cukup meneruskan klien sebagai tautan, dan menulis jenis klien di parameter “ Ekspresi" Data parameter ini akan diinterpretasikan di penerima, dan ketika dijalankan, prop akan diisi dengan nilai yang benar dari pencacahan.

Itu saja, aturan pertukaran sudah siap. Contoh yang dipertimbangkan ternyata cukup universal. Pendekatan serupa sering digunakan saat memigrasikan data dari konfigurasi yang dibuat pada platform 7.7. Contoh mencolok dari hal ini adalah transfer detail periodik.

Tugas No.3. Trik dengan bagian meja

Seringkali Anda menemukan tugas yang memerlukan penempatan baris dari satu bagian tabel menjadi beberapa. Misalnya, dalam konfigurasi awal, jasa dan barang didaftarkan dalam satu bagian tabel, dan di penerima, penyimpanan entitas ini dibagi. Sekali lagi, permasalahan ini tidak dapat diselesaikan dengan cara visual. Di sini akan lebih mudah untuk mengambil solusi dari masalah kedua sebagai dasar.

Kami membuat aturan untuk membongkar data, menentukan algoritma arbitrer, dan di handler "Sebelum membongkar" kami menulis permintaan untuk mendapatkan data dari bagian tabel.

Untuk menghemat ruang, saya tidak akan memberikan kode (Anda selalu dapat merujuk ke sumber) permintaan - tidak ada yang aneh di dalamnya. Kami memilah-milah pilihan yang dihasilkan, dan menempatkan hasil yang diurutkan di parameter yang sudah dikenal “ Pengambilan Sampel Data" Sekali lagi akan lebih mudah untuk menggunakan tabel nilai sebagai kumpulan:

DataFetch = Tabel Nilai Baru(); //Akan ada bagian tabel lain di sini Data Selection.Columns.Add(“Products”); //Di sini juga akan ada bagian tabular Data Selection.Columns.Add(“Services”); SelectionData.Columns.Add("Tautan");

Tugas No.4. Mentransfer data ke suatu operasi

Jika suatu organisasi menggunakan beberapa sistem akuntansi, cepat atau lambat akan ada kebutuhan untuk memigrasi data dengan pembuatan transaksi berikutnya.

Dalam konfigurasi “ BP“ada dokumen universal” Operasi” dan ini ideal untuk membentuk lebih banyak kabel. Hanya ada satu masalah – dokumen dibuat dengan cerdik, dan data tidak dapat ditransfer dengan mudah.

Anda akan menemukan contoh konversi semacam itu di kode sumber artikel. Jumlah kodenya ternyata cukup banyak, jadi tidak ada gunanya menerbitkannya bersamaan dengan artikel. Izinkan saya mengatakan bahwa mengunggah kembali menggunakan algoritma sewenang-wenang dalam aturan mengunggah data.

Tugas No.5. Sinkronisasi data di berbagai detail

Kami telah melihat beberapa contoh, tetapi kami masih belum membicarakan tentang sinkronisasi objek selama migrasi. Bayangkan kita perlu mentransfer rekanan dan beberapa di antaranya mungkin ada di database penerima. Bagaimana cara mentransfer data dan mencegah munculnya duplikat? Dalam hal ini, CD menawarkan beberapa cara untuk menyinkronkan objek yang ditransfer.

Yang pertama adalah dengan pengidentifikasi unik. Banyak objek memiliki pengenal unik yang menjamin keunikan dalam sebuah tabel. Misalnya pada direktori “ Pihak rekanan” tidak boleh ada dua elemen dengan pengidentifikasi yang sama. CD membuat perhitungan untuk ini dan untuk semua PCO yang dibuat, pencarian berdasarkan pengidentifikasi segera diaktifkan secara default. Saat membuat PCO, Anda seharusnya memperhatikan gambar kaca pembesar di sebelah nama objek.

Sinkronisasi menggunakan pengidentifikasi unik adalah metode yang dapat diandalkan, namun tidak selalu tepat. Saat menggabungkan direktori “ Pihak rekanan” (dari beberapa sistem berbeda) tidak akan banyak membantu.

Dalam kasus seperti itu, lebih tepat untuk menyinkronkan objek berdasarkan beberapa kriteria. Lebih tepat mencari rekanan berdasarkan INN, KPP, Nama atau membagi pencarian menjadi beberapa tahap.

Konversi data tidak membatasi pengembang dalam menentukan kriteria pencarian. Mari kita lihat contoh abstrak. Misalkan kita perlu menyinkronkan direktori “ Pihak rekanan” dari basis informasi yang berbeda. Mari kita siapkan PKO dan pada pengaturan aturan konversi objek, centang “ Lanjutkan pencarian di kolom pencarian jika objek penerima tidak ditemukan oleh pengenal" Dengan tindakan ini, kami segera menentukan dua kriteria pencarian - berdasarkan pengidentifikasi unik dan bidang khusus.

Kami berhak memilih sendiri bidangnya. Dengan mencentang NPWP, KPP, dan Nama, kami akan langsung mencantumkan beberapa kriteria pencarian. Nyaman? Benar, tapi sekali lagi ini tidak cukup. Bagaimana jika kita ingin mengubah kriteria pencarian? Misalnya kita cari dulu kombinasi NPWP+KPP, dan jika tidak ketemu, barulah kita mulai mencoba peruntungan dengan nama tersebut.

Algoritma seperti ini cukup mampu untuk diimplementasikan. Dalam pengendali acara “ Bidang pencarian” kita dapat menentukan hingga 10 kriteria pencarian dan untuk masing-masing kriteria tersebut menentukan komposisi bidang pencariannya sendiri:

Jika SearchOptionNumber = 1 maka SearchPropertyNameString = “TIN, KPP”; Jika tidakIfSearchOptionNumber = 2 ThenSearchPropertyNameString = “Nama”; akhirJika;

Selalu ada beberapa solusi

Setiap tugas memiliki beberapa solusi, dan mentransfer data antar konfigurasi yang berbeda tidak terkecuali. Setiap pengembang memiliki hak untuk memilih jalur solusinya sendiri, tetapi jika Anda terus-menerus harus mengembangkan migrasi data yang kompleks, saya sangat menyarankan untuk memperhatikan “”. Anda mungkin harus menginvestasikan sumber daya (waktu) dalam pelatihan pada awalnya, tetapi sumber daya tersebut akan lebih dari sekadar membuahkan hasil pada proyek pertama yang kurang lebih serius.

Menurut pendapat saya, perusahaan 1C secara tidak adil mengabaikan topik penggunaan konversi data. Selama keberadaan teknologi, hanya satu buku yang diterbitkan tentangnya: “1C: Enterprise 8. Konversi data: pertukaran antar solusi aplikasi.” Buku ini sudah cukup tua (2008), namun tetap disarankan untuk membiasakan diri dengannya.

Pengetahuan tentang platform masih diperlukan

"adalah alat universal, tetapi jika Anda berencana menggunakannya untuk membuat migrasi data dari konfigurasi yang dikembangkan untuk platform 1C:Enterprise 7.7, maka Anda harus meluangkan waktu untuk memahami bahasa bawaannya. Sintaks dan ideologi bahasanya sangat berbeda, jadi Anda harus meluangkan waktu untuk belajar. Kalau tidak, prinsipnya tetap sama.