Pertukaran data dengan 1s 8 3. Pertukaran melalui format universal

Setiap paket memiliki daftar elemen tertentu, informasi tentang perubahan yang dapat disimpannya. Daftar ini disebut "Komposisi rencana pertukaran". Komposisi dapat diperluas, tetapi dukungan konfigurasi dihilangkan.

"Rencana Tata Letak" menyimpan aturan yang menjadi dasar kerja sinkronisasi. Paket konversi inilah (Aturan Pendaftaran, Aturan Pertukaran, Aturan Pertukaran Koresponden) yang kami perlukan untuk dipelajari lebih lanjut.

Perhatikan contoh sinkronisasi data antara konfigurasi "1C: Payroll and HR 3" (ZUP) dan "1C: Enterprise Accounting 3" (BP). Kami segera mencatat bahwa dalam tugas ini kami harus menghapus konfigurasi dari dukungan. Ini diperlukan oleh kondisi.

Contoh hidup dari kebutuhan untuk menyempurnakan aturan pertukaran model

Misalnya, pelanggan menghubungi kami dengan masalah berikut: saat menyinkronkan antara ZUP dan BP, tidak mungkin mentransfer data direktori "Pendaftaran dengan otoritas pajak", yang diperlukan untuk mengisi "Refleksi gaji di akuntansi”. Sekarang bagian tabular dokumen ini di sisi penerima BP berisi "Registrasi ..." kosong dan pengguna harus membuat entri tersebut secara manual di direktori. Setuju, itu tidak nyaman. Kami dapat meningkatkan poin ini.

Solusi untuk masalah ini: kami akan menyelesaikan paket konversi dari paket pertukaran ExchangeSalary3Accounting3. Mari tambahkan "Aturan Pertukaran 1C" standar "Aturan Konversi Objek" (PKO) baru untuk direktori "Pendaftaran dengan Otoritas Pajak" dan, karenanya, "Konversi Properti" dari direktori ini (PKS). Kami pasti akan menyelesaikan "Aturan untuk mendaftarkan objek" standar, karena ada kebutuhan untuk mendaftarkan perubahan direktori pada node pertukaran. Dan kami akan merevisi "Aturan Pertukaran 1C" dari basis koresponden.

Di mana kita akan mengedit ini? untuk menulis dan mengubah aturan, kita memerlukan konfigurasi "1C: Konversi Data 2".

Penyempurnaan aturan konversi standar dari rencana pertukaran PZUP-BP

Jadi, mari mulai menyelesaikan aturan pertukaran 1C dengan menambahkan elemen baru ke komposisi di konfigurator untuk rencana pertukaran ExchangeSalary3Accounting3 - direktori RegistrationIn Tax Authority. Kami akan melakukan perubahan ini di kedua konfigurasi "1C: Gaji dan Manajemen Perusahaan 3" dan "1C: Akuntansi Perusahaan 3".

Simpan dan perbarui konfigurasi.

Dalam mode perusahaan, untuk setiap basis data, kami akan mengunggah deskripsi struktur metadata menggunakan pemrosesan MD83Exp.epf untuk platform 1C:Enterprise 8.3. Pemrosesan dapat ditemukan di kit "1C: Konversi Data".

Pada tahap selanjutnya, kami akan membongkar paket konversi dari ZUP dan BP. Paket harus terdiri dari 3 file: Aturan Pendaftaran, Aturan Pertukaran, Aturan Pertukaran Koresponden.

Dalam kerangka artikel ini, tidak akan ada penjelasan tentang bagaimana sinkronisasi data dikonfigurasi, Anda dapat membacanya di situs web Coderline di bagian Artikel Pakar atau menonton rekaman webinar. Sekarang opsi ini sudah dikonfigurasi di database. Oleh karena itu, buka pengaturan sinkronisasi (Administrasi -> Sinkronisasi data -> Pengaturan sinkronisasi data), klik tombol "Muat aturan". Kami akan melihat formulir "Aturan Sinkronisasi". Klik tombol "Lainnya" dan pilih opsi "Simpan aturan ke file".


Ini adalah paket setelah bongkar yang harus kita dapatkan.

Kami akan melakukan tindakan serupa untuk basis informasi lain "1C: Enterprise Accounting".
Hasilnya, semua pekerjaan persiapan untuk mengedit aturan sudah siap. Kita punya:

Deskripsi struktur metadata untuk memuat ke "1C: Konversi Data 2" (untuk ZUP dan BP);

Paket konversi yang berisi aturan pertukaran 1C dan aturan pendaftaran yang diperlukan untuk mengunggah ke 1C: Konversi Data 2 (untuk ZUP dan BP).

Buka "1C: Konversi Data 2". Lakukan langkah-langkah berikut agar kedua infobases:

Memuat struktur metadata konfigurasi kami;

Kami membuat konversi dan memuat aturan pertukaran data 1C dari paket konversi (file aturan disebut ExchangeRules);

Buat registrasi dan muat aturan registrasi dari paket konversi (file aturan disebut RegistrationRules).


Kami melanjutkan langsung ke penyempurnaan kami. Kami menambahkan aturan konversi objek (PKO) baru ke aturan pertukaran 1C - buku referensi "Pendaftaran dengan otoritas pajak". Kami menambahkan aturan konversi properti (PCS) untuk direktori ini dan aturan upload data (PDS). Penyempurnaan semacam ini harus dilakukan baik untuk aturan dari paket ZUP maupun untuk aturan pertukaran dari paket BP. Kami membongkar aturan pertukaran kami ke dalam file ExchangeRules yang sesuai.

Mari beralih ke aturan untuk mendaftarkan elemen baru. Kami menambahkan buku referensi "Pendaftaran dengan otoritas pajak". Unggah aturan pendaftaran ke file yang sesuai dari paket RegistrationRules. Tindakan ini juga dilakukan untuk kedua pangkalan.

Aturan pertukaran yang dimodifikasi dan aturan pendaftaran sudah siap. Sekarang kami menyalin konten aturan pertukaran (ExchangeRules) dari paket BP ke aturan koresponden (CorrespondentExchangeRules) dari paket ZUP. Dalam aturan koresponden (CorrespondentExchangeRules) dari paket BP, salin konten aturan pertukaran (ExchangeRules) dari paket ZUP.

Hasilnya harus sebagai berikut:

Ini menyelesaikan pekerjaan di "1C: Konversi Data 2". Paket aturan konversi yang dimodifikasi sudah siap, tinggal mengunggahnya kembali ke basis info dan memeriksa sinkronisasi.

Arsipkan file dari paket ke arsip ZIP dan unggah paket konversi kami ke ZUP dan BP.

Semua sudah siap. Itu masih harus diuji.

Mari kita ingat kondisi masalahnya. Itu perlu untuk mendaftar untuk membongkar direktori "Pendaftaran dengan otoritas pajak" dan memeriksa bagaimana PM dari dokumen "Refleksi upah dalam akuntansi" diisi di sisi "1C: Akuntansi Perusahaan 3".

Di sumber "1C: Gaji dan Manajemen Perusahaan 3" kami mendaftarkan direktori kami untuk dibongkar. Kami melakukan sinkronisasi. Kami pergi ke database penerima dan juga melakukan sinkronisasi untuk menerima data. Harap perhatikan bahwa sekarang direktori yang diperlukan untuk mendaftarkan perubahan telah muncul di rencana pertukaran.

Kami memeriksa di sisi "1C: Enterprise Accounting 3":


Meringkaskan. Hasil tugas berhasil diselesaikan. Kami telah menyelesaikan rencana pertukaran ZUP - BP, menambahkan elemen baru untuk mendaftarkan perubahan dan menyelesaikan aturan konversi untuk sinkronisasi data.

Sistem otomatis manajemen dalam banyak kasus terdiri dari database terpisah dan seringkali memiliki struktur yang terdistribusi secara geografis. Pada saat yang sama, pertukaran data yang diterapkan dengan benar - kondisi yang diperlukan Untuk kerja yang efektif sistem seperti itu.

Dalam hal ini, penyiapan pertukaran awal mungkin memerlukan sejumlah tindakan, tidak hanya dalam hal pemrograman, tetapi juga konsultasi, bahkan jika kita berurusan dengan sumber yang homogen, seperti halnya produk berdasarkan platform 1C:Enterprise. Mengapa menyiapkan pertukaran 1C (atau, demikian juga disebut, sinkronisasi data dalam 1C 8.3) dapat menjadi tugas proyek integrasi yang paling memakan waktu dan mahal, kami akan pertimbangkan dalam artikel ini.

Pertukaran data di lingkungan 1C memungkinkan Anda untuk:

  • Hilangkan entri ganda dokumen;
  • Mengotomatiskan proses bisnis terkait;
  • Mengoptimalkan interaksi antar departemen terdistribusi;
  • Segera perbarui data untuk pekerjaan spesialis dari berbagai departemen;
  • "Membatasi" jenis yang berbeda akuntansi.*

*Dalam kasus ketika data dari satu jenis akuntansi berbeda secara signifikan dari yang lain, perlu untuk memastikan kerahasiaan informasi dan aliran informasi "terpisah". Misalnya, pertukaran data antara 1C UT dan 1C Accounting tidak memerlukan pengunggahan data manajemen ke database akuntansi peraturan, mis. sinkronisasi dalam 1C tidak akan lengkap di sini.

Jika kami mewakili proses standar untuk mengimplementasikan pertukaran data primer, ketika setidaknya salah satu objeknya adalah produk 1C, maka tahapan berikut dapat dibedakan:

  • Koordinasi komposisi bursa;
  • Definisi transportasi (protokol pertukaran);
  • Menetapkan aturan;
  • Penjadwalan.

Identifikasi komposisi bursa 1C

Pertukaran objek dapat dibagi secara kondisional menjadi "sumber" dan "penerima". Pada saat yang sama, mereka dapat melakukan dua peran sekaligus, yang disebut pertukaran dua arah. Definisi sumber dan tujuan terjadi dengan cara yang logis, tergantung pada kebutuhan atau pada Kegunaan sistem.*

*Misalnya, saat mengintegrasikan WA: Financier, solusi untuk akuntansi keuangan dan mengelola proses perbendaharaan yang dikembangkan berdasarkan 1C:Enterprise, pakar WiseAdvice merekomendasikannya sebagai sistem induk. Ini karena ketersediaan alat kontrol untuk mematuhi aturan kebijakan aplikasi, dan, karenanya, untuk memastikan keefektifan solusi.

Selanjutnya, berdasarkan persyaratan yang diterima dan direkam dari pengguna, daftar data untuk pertukaran dibuat, volumenya, persyaratan untuk frekuensi pertukaran ditentukan, proses bekerja dengan kesalahan dan penanganan situasi luar biasa (tabrakan) ditentukan.

Pada tahap yang sama, tergantung pada armada sistem yang ada dan struktur perusahaan, format pertukaran ditentukan:

Basis informasi terdistribusi

  • RIB menyiratkan pertukaran antara konfigurasi database 1C yang identik, dengan struktur kontrol master-slave yang jelas untuk setiap pasangan pertukaran. Menjadi elemen platform teknologi, RIB, selain data, dapat mentransfer perubahan dalam konfigurasi dan informasi administrasi database (tetapi hanya dari master ke slave).

pertukaran universal data dalam 1C

  • Mekanisme yang memungkinkan Anda mengonfigurasi pertukaran database 1C, baik dengan konfigurasi pada platform 1C: Perusahaan, maupun dengan sistem pihak ketiga. Pertukaran dilakukan dengan mentransfer data ke dalam format xml universal sesuai dengan "Exchange Plans".

Data Perusahaan

  • Perkembangan terbaru dari perusahaan 1C, dirancang untuk mengimplementasikan pertukaran data dalam format xml antara produk yang dibuat di platform 1C:Enterprise dengan sistem otomasi apa pun. Penggunaan EnterpriseData menyederhanakan peningkatan yang terkait dengan pertukaran. Sebelumnya saat login konfigurasi baru perlu menerapkan mekanisme untuk mengimpor dan mengekspor data, baik untuk itu maupun untuk sistem yang ada. Sekarang sistem yang mendukung EnterpriseData tidak perlu dimodifikasi, hanya memiliki satu titik masuk-keluar.

Definisi transportasi (protokol pertukaran)

Sistem yang didasarkan pada platform 1C:Enterprise 8 menyediakan berbagai opsi untuk mengatur pertukaran dengan siapa pun sumber daya informasi melalui standar universal yang diterima secara umum (xml, file teks, Excel, koneksi ADO, dll.). Oleh karena itu, saat menentukan transportasi untuk pertukaran data, seseorang harus mulai dari kemampuan database sistem pihak ketiga.

Sinkronisasi direktori

Prinsip utama sinkronisasi direktori yang efektif adalah adanya satu titik masuk. Tetapi jika kita berbicara tentang bekerja dengan direktori yang secara historis diisi menurut aturan yang berbeda, bidang sinkronisasi perlu didefinisikan dengan jelas untuk membawa pertukaran ke "common denominator".*

*Pada tahap ini, pekerjaan normalisasi data referensi di sisi sumber data mungkin perlu dilakukan. Bergantung pada keadaan direktori dan volumenya, proses membandingkan elemen, mengenali, mengidentifikasi kesalahan dan duplikat, serta mengisi bidang yang hilang dan menetapkan bidang sinkronisasi, mungkin memerlukan kerja seluruh kelompok ahli, baik dari sisi integrator (pemilik metodologi normalisasi data referensi) dan dari sisi pelanggan.

Menetapkan aturan

Kemampuan untuk menampilkan data dari sistem sumber di penerima bergantung pada aturan pertukaran yang ditentukan dengan benar. Aturan yang disajikan dalam format xml mengatur korespondensi atribut kunci dari objek sumber-tujuan. Solusi 1C: Konversi Data dirancang untuk mengotomatiskan pembuatan aturan untuk penerapan pertukaran satu kali dan permanen.

Memastikan tidak ada kehilangan data selama pertukaran rencana Exchange. Ini adalah bagian integral dari setiap konfigurasi pada platform 1C:Enterprise, yang sepenuhnya menjelaskan prosedur pertukaran 1C: komposisi data (dokumen dengan detail "identifikasi") dan node (basis informasi penerima-pemancar), serta aktivasi RIB untuk arah pertukaran yang dipilih.

Setiap perubahan pada data yang dimasukkan dalam Exchange Plan adalah tetap dan menerima tanda "perubahan". Selama data yang diubah tidak sesuai satu sama lain di node penerima-pemancar, bendera tidak akan disetel ulang, dan sistem akan mengirimkan pesan kontrol ke kedua node. Setelah membongkar data dan mengonfirmasi kepatuhan penuh mereka di kedua sistem, tanda disetel ulang.

Jadwal pertukaran di 1C

Untuk mengotomatiskan pertukaran reguler, frekuensi pengunggahan data diatur. Frekuensi pertukaran tergantung pada kebutuhan dan kemampuan teknis. Selain itu, konfigurasi pada platform 1C:Enterprise memungkinkan Anda mengonfigurasi pertukaran data saat terjadi peristiwa.

Setelah mempertimbangkan proses standar untuk mengimplementasikan pertukaran, perhatikan faktor-faktor yang memerlukan peningkatan pada berbagai tahap:

  • Konfigurasi database yang tidak standar dan banyak dimodifikasi;
  • Versi berbeda dari 1C: Platform perusahaan;
  • Tidak diperbarui untuk waktu yang lama, bukan versi konfigurasi terbaru;
  • Pertukaran objek yang telah dimodifikasi sebelumnya;
  • Perlunya aturan pertukaran non-standar;
  • Kumpulan dan komposisi detail yang sangat berbeda dalam direktori yang tersedia.

Karena bahkan tindakan standar untuk implementasi pertukaran data primer memerlukan pengetahuan ahli, tindakan tersebut direkomendasikan untuk dilakukan dengan partisipasi spesialis 1C. Hanya setelah menyelesaikan semua langkah di atas, Anda harus melanjutkan ke pengaturan pertukaran dalam konfigurasi. Pertimbangkan integrasi database pada contoh "1C: UPP" dan "1C: Retail" (menurut skema yang sama, pertukaran dengan "1C: UT" dikonfigurasi). Juga, sinkronisasi tipikal mencakup pertukaran SCP - SCP, yang tipikal untuk sistem otomasi skala besar di perusahaan industri terbesar.

Di submenu "Layanan", pilih "Pertukaran data dengan produk di platform ..." (pilihan pertukaran langsung dengan "Ritel" sering mengancam kesalahan pada level objek COM). Perhatikan pesan resmi " Kesempatan ini tidak tersedia."


Untuk mengatasi masalah ini, Anda harus memilih "Pengaturan Berbagi Data"


...dan centang kotaknya. Selanjutnya, pesan kesalahan diabaikan.


Di pengaturan sinkronisasi data, pilih "Buat pertukaran dengan" Ritel "...



Sebelum mengonfigurasi pengaturan koneksi melalui direktori lokal atau jaringan, pastikan ada ruang pada disk untuk direktori tersebut. Meskipun, sebagai aturan, tidak lebih dari 30-50 MB, dalam kasus luar biasa mungkin memerlukan hingga 600 MB. Anda dapat membuat direktori yang diperlukan langsung dari konfigurator.



Saat menghubungkan melalui direktori jaringan, kami mengabaikan proposal untuk mengonfigurasi koneksi melalui alamat FTP dan melalui email dengan mengklik "Berikutnya".


Dalam pengaturan, letakkan awalan secara manual - konvensi basis (sebagai aturan, BP, SCP, RO), kami menetapkan aturan dan tanggal mulai untuk mengunggah data. Awalan akan ditunjukkan dalam judul dokumen untuk menunjukkan dasar pembuatannya. Jika aturan unggahan tidak diedit, data default akan diunggah sesuai dengan semua parameter yang tersedia.



Kami membuat file pengaturan pertukaran untuk Ritel agar tidak mengulangi tindakan kami. Jika Anda perlu mengirim data segera setelah menyiapkan sinkronisasi, centang kotaknya.


Untuk mengotomatiskan proses pertukaran, Anda perlu mengatur jadwal.


menu eceran.


Centang kotak dan pilih Sinkronkan.


Kami membuat pengaturan "terbalik" dengan memilih Mengelola perusahaan manufaktur.




Muat file dengan pengaturan yang dibuat di SCP.


Kami memberi tanda centang, sistem mengambil alamat secara otomatis.





Kami bertindak dengan cara yang sama seperti di UPP.









Perbandingan verifikasi data (Perbandingan data manual direkomendasikan untuk dilakukan pada tahap persiapan, karena pekerjaan ini dapat menjadi yang paling memakan waktu dalam proses implementasi pertukaran). Jendela perbandingan dibuka dengan mengklik dua kali mouse.



Jika terjadi kesalahan sinkronisasi, “Details…” akan diganti dengan “Never…”.


“Detail…” membuka log pendaftaran dengan informasi terbaru di bursa.


Siap.

Mekanisme Pertukaran Data Universal dimaksudkan untuk membuat sistem yang terdistribusi secara geografis berdasarkan 1C:Enterprise 8, dan untuk mengatur pertukaran data dengan pihak lain sistem Informasi tidak berdasarkan 1C: Perusahaan 8.

Mekanisme ini memungkinkan Anda untuk mentransfer hanya 1C: Data perusahaan; mentransfer konfigurasi dan informasi administrasi 1C: Enterprise 8 menggunakan mekanisme ini tidak dimungkinkan.

Kemungkinan

  • pertukaran data dapat diimplementasikan baik dengan 1C: basis informasi Perusahaan maupun dengan sistem informasi lainnya;
  • pengorganisasian berbagai strategi perpesanan;
  • penerapan berbagai cara menyelesaikan tabrakan saat mengubah data di node berbeda dari sistem terdistribusi;
  • pelaksanaan pemulihan pertukaran data dalam kasus seperti pemulihan infobase dari backup dll.

Keanehan

  • Dokumen XML digunakan sebagai format pertukaran;
  • saat bertukar data antara 1C:Enterprise 8 infobases, tidak ada batasan yang dikenakan pada identitas konfigurasi dan struktur objek tertentu;
  • dalam satu konfigurasi, beberapa skema pertukaran independen dengan berbagai sistem informasi dapat dibuat;
  • saat mengatur skema pertukaran, tidak ada batasan yang dikenakan pada struktur sistem terdistribusi. Ini dapat diatur sebagai struktur tipe bintang klasik, serta struktur tipe kepingan salju multi-level yang lebih kompleks dan lainnya;
  • pengembang solusi yang diterapkan diberi kesempatan untuk secara fleksibel mengontrol komposisi pertukaran, baik dalam hal struktur data yang dikirimkan, maupun dalam hal komposisi informasi yang dikirimkan ke node pertukaran tertentu;
  • objek database awalnya dibuat di salah satu node pertukaran. Komposisi informasi yang dikirimkan dapat disesuaikan tergantung pada isi data, dan tidak tergantung pada tempat input awal informasi.

Komponen

Mekanisme pertukaran data universal bukanlah solusi yang kaku. Pekerjaannya diimplementasikan oleh seperangkat alat platform teknologi 1C: Enterprise 8, yang dapat digunakan dalam solusi aplikasi dalam berbagai kombinasi.

  • Rencana Pertukaran
    Objek konfigurasi Rencana pertukaran adalah pusat di mana alat komunikasi lain dikelompokkan. Dengan bantuan objek-objek ini, sekumpulan node dari sistem terdistribusi dan komposisi data yang seharusnya dipertukarkan dalam kerangka rencana pertukaran ini dijelaskan.
    Selain itu, rencana pertukaran menerapkan dua mekanisme penting yang terlibat dalam pertukaran data:
    • Ubah Layanan Pendaftaran
      Memungkinkan Anda mendapatkan informasi tentang elemen data mana yang telah diubah dan ke node pertukaran mana mereka perlu ditransfer.

DI DALAM kehidupan nyata sebuah perusahaan langka mengelola dengan satu basis 1C. Situasi yang paling umum adalah dua pangkalan, akuntansi dan gaji.

Pangkalan harus dihubungkan - gaji telah dihitung, pajak yang masih harus dibayar harus masuk ke departemen akuntansi untuk pembayaran.

Untuk menghubungkan beberapa database, ada Exchange 1C. Bagaimana dia bekerja?

Apa itu Pertukaran 1C?

Ada jaringan pertokoan dan kantor pusat. Setiap toko dan kantor memiliki gudang. Barang dipindahkan dari gudang ke gudang (terutama dari gudang pusat ke toko), dan di toko barang dijual.

Basis Ritel 1C digunakan di kantor dan basis yang sama di setiap toko. Pangkalan di toko berada di bawah pangkalan di kantor.

Kantor membuat dokumen tentang pergerakan barang dari gudang ke gudang, harga ditetapkan. Dokumen diunggah ke pangkalan bawahan dan barang "muncul" di sana.

Di toko, dokumen dibuat untuk penjualan barang. Dokumen diunggah ke pangkalan kantor dan penjualan "muncul" di sana.

Skema semacam itu disebut basis informasi terdistribusi (DIB). Prosedur untuk "mengisi" dokumen - pertukaran dua arah 1C. Dan pengaturan skema ini adalah URIB atau URIBD (manajemen basis data informasi terdistribusi).

Prinsip Pertukaran Direktori dalam 1C

Direktori 1C (dan kumpulan semua direktori "dalam kompleks" disebut NSI - informasi referensi peraturan) - dalam database yang berbeda biasanya harus sama. Artinya meskipun ada beberapa database, daftar barang, gudang, kontraktor sama di database yang berbeda.

Ini adalah praktik umum ketika dalam satu database direktori diizinkan untuk diedit, dan disalin ("bermigrasi") ke yang lain. Seperti yang telah kita bahas sebelumnya, setiap elemen 1C memiliki pengidentifikasi unik - GUID. Direktori biasanya disalin bersama dengan GUID mereka, dan dengan demikian identik di seluruh sistem informasi terdistribusi.

Jika tidak, ketika beberapa database yang sudah ada terhubung, atau ketika direktori dapat dibuat di database yang berbeda pada saat yang sama, GUID mereka akan berbeda. Ada mekanisme pencocokan untuk ini. Selama pertukaran 1C, informasi dicatat dalam register informasi khusus bahwa elemen dari basis No. 1 dengan GUID xxx sama dengan elemen di basis ini dengan GUID yyy. Awalnya, elemen-elemen yang ada yang tidak lagi sama harus dicocokkan secara otomatis (dengan detail lain, misalnya dengan nama atau dengan NPWP dan KPP) atau secara manual.

Prinsip Pertukaran Dokumen dalam 1C

Dokumen dalam 1C diposting oleh register dan setelah itu dianggap "diposting". Ini menimbulkan kesulitan yang bisa dimengerti dalam transfer.

Salah satu opsinya adalah hanya mentransfer dokumen dan mempostingnya lagi setelah diunggah. Metode ini sering digunakan, tetapi dapat menimbulkan kesalahan - dokumen mungkin tidak diposting di database baru, karena kondisi selama posting mungkin berbeda dari saat dokumen ini diposting di database asli.

Pilihan lainnya adalah mentransfer dokumen dan register secara bersamaan. Seperti yang kami pahami, pertanyaan segera muncul - apakah kami mentransfer semua dokumen secara umum dan kemudian seluruh register secara umum, atau kami terpaksa memilih untuk mentransfer hanya pergerakan pada dokumen yang ditransfer.

Katakanlah kita perlu mentransfer elemen dari direktori Nomenklatur. Direktori ini memiliki 10 bidang, 5 di antaranya adalah string dan angka, dan 5 adalah tautan ke direktori lain.

Karenanya, saat mentransfer satu elemen Nomenklatur, kami terpaksa mencari dan mentransfer juga 5 elemen dari direktori lain.

Jadi, saat mentransfer satu elemen direktori atau satu dokumen, 100 atau lebih objek 1C lainnya dapat ditransfer melalui referensi.

Faktanya, hampir semua direktori konfigurasi dikatakan saling merujuk satu sama lain dengan satu atau lain cara.

Rencana pertukaran 1C

Misalkan kita telah membuat database terdistribusi dan bertukar 1C. Barang dibeli di gudang pusat dan disiapkan untuk pengiriman ke toko. Di 1C, kantor memasukkan dokumen yang diperlukan untuk pergerakan barang. Mereka harus dimuat ke toko.

Apa yang harus dilakukan? Melakukan pertukaran penuh lagi 1C? Panjang dan tidak efisien! Akan jauh lebih baik untuk menghitung apa yang sebenarnya ditambahkan atau diubah oleh pengguna ke kantor, sehingga hanya perubahan yang masuk ke toko.

Untuk ini, ada rencana pertukaran 1C. Pemrogram membuat rencana pertukaran 1C terlebih dahulu untuk melakukan pertukaran 1C dengan database lain, misalnya, dengan toko kami.

Catatan rencana pertukaran 1C, ketika pengguna bekerja dengan direktori dan dokumen, apa yang telah ditambahkan atau diubah sejak pertukaran 1C terakhir dengan database ini.

Pembuatan URIB 1C

Jadi, kami akan membuat database terdistribusi dari awal. Awalnya, kami memiliki basis kantor "induk". Dari situ kita akan memilih basis toko yang akan berada di bawahnya.

Dalam konfigurasi tipikal, sudah ada paket pertukaran 1C standar. Jenis pangkalan yang dimaksudkan secara intuitif jelas dari namanya:

  • Tukarkan 1C dengan situs: tukarkan dengan situs 1C: Bitrix
  • Exchange 1C UPP-UT atau UT-Retail: pertukaran tipikal dengan konfigurasi saudara
  • Penuh - pertukaran 1C dengan database berdasarkan konfigurasi yang sama.

RIB - basis informasi terdistribusi - juga dapat dibuat berdasarkan rencana pertukaran "Penuh" 1C. Di konfigurator, dalam paket pertukaran 1C ini, kotak centang "Database terdistribusi" harus dicentang.

Rencana pertukaran 1C yang dibuat di konfigurator menunjukkan bahwa kita akan bertukar dengan konfigurasi seperti itu. Dalam mode Perusahaan dalam paket pertukaran 1C yang sama, Anda sekarang perlu menentukan database tertentu berdasarkan konfigurasi ini.

Mari beralih ke paket pertukaran 1C (Paket Operasi / Pertukaran; bisa juga di menu lain, sering kali di menu Layanan / XXX).

Di daftar database di rencana pertukaran 1C, ada satu dengan lingkaran hijau di gambar. Elemen ini singkatan dari DASAR INI. Elemen yang tersisa menunjukkan basis LAIN yang dengannya 1C dipertukarkan.

Nama dan kode harus diisi untuk semua elemen.

Untuk membuat subbase "toko":

  • Atur kursor dalam daftar ke elemen rencana pertukaran 1C, yang kami buat sebagai "basis penyimpanan"
  • Pilih item menu "Tindakan/Buat gambar awal".

Akibatnya, satu database akan dibuat, dengan data awal diunggah ke dalamnya. Ini harus diulangi untuk setiap elemen dari rencana pertukaran 1C, kecuali untuk CURRENT BASE.

Teori pertukaran 1C

Teori pertukaran 1C cukup sederhana:

  • Salah satu pangkalan (lebih sering pangkalan pusat) memulai pertukaran 1C sesuai dengan jadwal atau "pada suatu acara" (login ke pangkalan pengguna tertentu, dll.)
  • Pertukaran 1C terdiri dari membongkar file dari database
  • File harus dipindahkan ke tempat di mana basis bawahan dapat mengambilnya (biasanya share atau ftp, lebih jarang email)
  • Database budak mengunduh file yang diterima
  • Sebagai konfirmasi bahwa informasi telah diterima, pangkalan budak mengunggah file "respons", yang diunggah kembali ke pangkalan pusat dengan cara yang sama.
  • Pertukaran sesi 1C selesai.

Ada metode pertukaran 1C lainnya, bukan melalui file, tetapi, misalnya, melalui koneksi COM langsung antara dua database. Keuntungannya:

  • Tidak diperlukan "ruang untuk menyimpan dan mentransfer file".
  • Tidak perlu mengupload ulang konfirmasi
  • Semuanya terjadi lebih cepat karena dua poin pertama.

Namun, batasannya jelas - pangkalan harus berada sedemikian dekat satu sama lain agar dapat memulai koneksi COM.

Menyiapkan RIB 1C

Dalam konstanta konfigurasi tipikal (Operasi / Konstanta; atau Pengaturan Layanan / Program) - biasanya ada pengaturan umum pertukaran 1C. Ini adalah awalan dalam kode elemen dan nomor dokumen untuk dengan mudah menentukan di database mana itu dibuat. Serta metode internal untuk menyimpan informasi tentang tempat pembuatan direktori dan dokumen.

Sekarang Anda perlu mengonfigurasi bagaimana proses pertukaran informasi 1C secara berkala antara database yang dibuat akan berlangsung.
Semua pengaturan RIB di 1C dalam konfigurasi tipikal, biasanya di menu Service / Distributed infobases / Configure RIB nodes.

Untuk setiap elemen "basis penyimpanan jarak jauh" yang dibuat sebelumnya, Anda perlu menambahkan elemen konfigurasi.

Pengaturan menentukan metode pertukaran 1C: file (share), file (FTP), file (email).

Membuat dan mengonfigurasi infobase 1C terdistribusi di thin client

Mari kita lihat pengaturan serupa dalam konfigurasi tipikal berdasarkan klien kurus– Edisi manajemen perdagangan 11.
Pengaturan (dan pembuatan dari awal) terletak di tab Administrasi antarmuka. Item "Pertukaran Data".

Pilih "Buat pertukaran di basis info terdistribusi".

Sejak awal, 1C akan meminta kami untuk menunjukkan bagaimana kami akan bertukar informasi dengan basis data bawahan. Ini adalah opsi konfigurasi "melalui file di bola."

Berikut opsi konfigurasi melalui file di FTP.

Nama pengaturan pertukaran kami adalah 1C.

Dan segera proposal untuk membuat "gambar awal" - yaitu, database budak itu sendiri dengan mengunggah informasi utama ke dalamnya.

Berbeda dengan konfigurasi pada klien yang tebal, kedua pengaturan pertukaran 1C berada di tempat yang sama.



Memuat...
Atas