Ada banyak instruksi untuk memperbarui konfigurasi standar platform 1C yang dimodifikasi. Oleh karena itu, agar tidak menambah esensi, saya tidak akan menjelaskan keseluruhan prosesnya secara lengkap. Selain itu, diasumsikan bahwa teks ini ditujukan untuk orang yang telah memperbarui konfigurasi yang dimodifikasi dan mengetahui poin utama dan kendalanya. Metode ini hanya menyederhanakan proses ini, pada dasarnya menyarankan penggunaan perbandingan otomatis perubahan konfigurasi dan perubahan modul pada tingkat perbandingan file teks. Dengan pendekatan ini, kemungkinan kesalahan (“menimpa” perubahan penting karena kurangnya perhatian) yang terkait dengan “faktor manusia” sangat berkurang.

Pembaruan konfigurasi APAPUN dimulai dengan membongkar keamanan informasi. Ini adalah “aturan emas”, ini harus selalu diingat, ini harus dilakukan dengan cara apapun (walaupun mereka lupa menyebutkannya). Selanjutnya, Anda dapat melakukan dua cara: memperbarui di database pengujian, atau memperbarui di database produksi. Di Sini poin penting sebagai berikut: biasanya konfigurasi yang diubah diperbarui bukan untuk setiap rilis (karena hal ini dapat dengan mudah dilakukan dengan rilis standar), tetapi untuk beberapa rilis sekaligus, karena proses ini memakan waktu. Metode pertama (pembaruan pada database pengujian) melibatkan transfer akhir pembaruan ke database yang berfungsi dengan mengunduh file cf. Dalam hal ini, kesalahan terkait detail yang dihapus mungkin terjadi (Anda dapat menemukan banyak artikel tentang ini). Oleh karena itu, terdapat beberapa risiko, namun selama pembaruan (yang dapat memakan waktu seharian penuh atau bahkan lebih lama), pengguna dapat bekerja dengan aman, mengubah database. Dalam metode kedua (pembaruan pada basis kerja) - risiko ini dikecualikan, tetapi selama durasi pembaruan pengguna kunci tidak akan dapat bekerja di database ini. Ada cukup banyak diskusi di forum tentang metode mana yang baik dan apakah layak untuk mentransfer pembaruan melalui file konfigurasi. Saya hanya bisa mengatakan: berdasarkan pengalaman saya menggunakan metode pertama, kesalahan seperti itu tidak terjadi saat memuat file cf. Bagaimanapun, Anda dapat memulihkan database menggunakan cadangan. Ini adalah metode pertama yang akan dipertimbangkan di sini, tetapi ini tidak mempengaruhi esensi metode dan, jika diinginkan, Anda dapat melanjutkan sesuai metode kedua dengan menggunakan metode yang diusulkan.

Jadi, setelah menerapkan database pengujian menggunakan cadangan baru, kami membuat pembaruan rilis berurutan ke yang terbaru. Setelah setiap rilis, kami menjalankan “Debug” untuk menyimpan perubahan konfigurasi dan mengatur ulang data. Secara keseluruhan kotak dialog Klik OK/Berikutnya/Terima/Ya/Lanjutkan...

Oleh karena itu, kami telah memperbarui konfigurasi pada basis pengujian ke rilis terbaru, tetapi kami perlu memeriksa apakah kami telah menimpa perubahan apa pun, dan jika kami telah menimpanya, kami perlu mentransfernya ke rilis ini. Sekarang kesenangannya dimulai, jadi saya akan menjelaskannya langkah demi langkah. Setiap langkah akan memiliki beberapa penjelasan: yaitu, esensi dijelaskan terlebih dahulu, dan kemudian lebih banyak lagi deskripsi rinci. Jika intinya sudah jelas, maka uraiannya bisa dihilangkan.

1. Kami menyimpan perubahan konfigurasi SEBELUM dan SETELAH pembaruan dalam file teks. Buka database yang berfungsi dan uji dalam mode Configurator. Kami membuka konfigurasi di dalamnya. Dan di kedua database kami mulai memproses perbandingan konfigurasi ("Konfigurasi - Bandingkan konfigurasi..."). PENTING: di kedua database sama saja untuk memilih konfigurasi:

Selain itu, kami menyimpannya sebagai berikut: di database yang berfungsi (di mana konfigurasi SEBELUM pembaruan) - dalam file dengan akhiran "lama", dan di database pengujian (di mana konfigurasi SETELAH pembaruan) - dalam file dengan berakhir dengan "baru".

2. Memasukkan perubahan yang hilang ke dalam konfigurasi yang diperbarui. Mari kita beralih ke tahap kunci dari metode ini. Karena ini poin utamanya, maka untuk sedikit penjelasan tentang apa yang terjadi ada sedikit materinya. Pada platform 1C 7.7, file pembaruan adalah konfigurasi lengkap. Dan pembaruan di 1C 7.7 terdiri dari memuat konfigurasi baru dan mengatur ulang database untuk konfigurasi ini. Jadi, konfigurasi dan pembaruan pada dasarnya adalah file md yang sama. Berbeda dengan platform 1C 7.7, pada platform 1C 8.x: konfigurasi ditransfer melalui file cf, dan pembaruan melalui file cfu. Perbedaan antara file-file ini adalah file cf berisi semua objek konfigurasi, dan file cfu hanya berisi objek yang diubah oleh pembaruan ini. Jadi, saat memperbarui pada platform 1C 8.x, hanya objek konfigurasi yang benar-benar berubah di rilis baru yang terpengaruh. Akibatnya, jika objek tersebut diubah oleh kami, maka setelah pembaruan, objek tersebut akan sepenuhnya diganti dengan yang standar, dan kami perlu mengulangi perubahan yang ada sebelum pembaruan agar objek ini berisi keduanya. perubahan dan perubahan rilis baru, pada saat yang sama. Namun jika objek konfigurasi yang kita ubah tidak terpengaruh oleh pembaruan, perubahan kita akan tetap ada di dalamnya setelah pembaruan. Agar lebih mudah memahaminya, saya akan gambarkan dalam bentuk diagram:

Diagram ini menunjukkan beberapa konfigurasi khas dalam proses perubahan dan pembaruan. String adalah objeknya (dokumen, direktori, pemrosesan, dan sebagainya). Pertama (di bawah nomor I) hanyalah konfigurasi tipikal: semua objek tanpa perubahan apa pun. Kemudian, di bawah nomor II, kita sudah melihat perubahan konfigurasi yang khas: beberapa objek telah diubah dan objek yang diubah ini ditandai dengan warna merah. Nomor III merupakan update selanjutnya untuk konfigurasi khas: sebenarnya, ini hanya berisi objek yang terpengaruh oleh perubahan dalam rilis baru, yang ditandai dengan warna hijau, tetapi untuk kejelasan, saya juga menambahkan semua objek lainnya. Dan kita perlu mendapatkan konfigurasi standar yang diperbarui (ditunjukkan pada diagram I), tetapi dengan perubahan pada diagram II dan diagram III. Pada dalam contoh ini- konfigurasi akhir ini ditampilkan sebagai nomor IV dan berisi satu objek yang diubah oleh kami dan pembaruan. Objek lainnya yang kami ubah jelas tidak tersentuh oleh pembaruan ini. Sekarang pertanyaannya adalah: bagaimana cara membuat SEMUA perubahan pada objek yang terpengaruh oleh pembaruan? Jelasnya, kita perlu mengambil dua langkah: pertama, temukan objek ini, dan kedua, temukan tempat di mana perubahan kita seharusnya dilakukan dan lakukan lagi. Saya perhatikan bahwa, tentu saja, mungkin ada beberapa objek seperti itu dan Anda perlu menemukan dan memperbaiki semuanya. Jadi mari kita lanjutkan ke langkah terakhir pembaruan ini. Pada titik ini, kita harus membuka database pengujian dalam mode Configurator. Jika hasil pemrosesan perbandingan konfigurasi atau jendela lain masih terbuka di sana, kami akan menutup semuanya agar tidak bingung. Selanjutnya, kami membuka database yang berfungsi dalam mode Configurator (dimungkinkan untuk menutupnya saat memperbarui database pengujian) dan mulai membandingkan konfigurasi di sana. Dan uraian dari dua langkah terakhir (temukan dan perbaiki) akan saya tempatkan di subparagraf terpisah:

2.1. Cari objek dengan perubahan yang terhapus oleh pembaruan. Saatnya mengingat file txt dengan akhiran lama/baru. Faktanya, file-file ini mencerminkan semua perubahan konfigurasi (relatif terhadap yang standar) SEBELUM dan SETELAH pembaruan. Jadi, jika kami telah menimpa beberapa perubahan dengan pembaruan, itu hanya akan ada di file “Comparison Report_old.txt”. Artinya, pencarian objek konfigurasi yang diperlukan dilakukan dengan membandingkan kedua file ini. Kami akan membandingkan file-file ini menggunakan manajer file Jumlah Komandan dan alat bawaannya. Saya rasa di sini tidak perlu dijelaskan apa itu Total Commander, dimana mendapatkannya dan bagaimana cara menggunakannya... Namun, saya akan menjelaskan secara singkat tahapan yang diperlukan dalam penggunaannya di sini. Jadi, mari luncurkan Total Commander. Jika bahasa antarmuka adalah bahasa Inggris (menu utama dan sebagainya), maka Anda dapat mengubahnya ke bahasa Rusia: “Konfigurasi - Opsi…”, di kotak dialog pilih bagian “Bahasa” di kolom kiri, cari/pilih "Rusia (Rusia)" dalam daftar dan klik "OK". Selanjutnya, melalui Total Commander kita mencari file txt laporan, memilihnya ("Sisipkan" atau "klik kanan") dan mulai membandingkan file: "File - Bandingkan berdasarkan konten..." (dalam antarmuka bahasa Inggris: "Files - Bandingkan Berdasarkan Konten..."). Di jendela yang terbuka, konten file masing-masing ditampilkan di kiri/kanan; tombol “Perbedaan berikutnya”/”Perbedaan sebelumnya” memungkinkan Anda mencari perbedaan. Alat ini memungkinkan Anda dengan cepat menemukan objek yang menarik bagi kami.

Komentar: situasi sebaliknya juga dapat terjadi - perbedaan muncul dalam konfigurasi SETELAH pembaruan yang tidak ada SEBELUM pembaruan. Ini berarti rilis pembaruan menghapus objek terkait dari konfigurasi. Pada prinsipnya, objek-objek ini dapat dilewati begitu saja di tambalan kami, karena tidak ada perubahan pada objek-objek ini.

2.2. Membuat perubahan pada objek yang diperbarui. Setelah kita menemukan objek dengan perubahan yang ditimpa, kita perlu menentukan di mana tepatnya perubahan ini terjadi: dalam modul (teks program), kotak dialog (pada formulir) atau pengaturan lainnya. Di sini saya akan memisahkan dua kasus: perubahan dalam modul dan semua perubahan lainnya. Dan mari kita lihat kedua kasus ini secara terpisah.

2.2.1. Perubahan yang terhapus oleh pembaruan ada di modul. Faktanya, ini adalah kasus utama (ini lebih sering terjadi) dan kasus ini persis seperti dalam contoh kita: perubahan telah dihapus dalam modul “Akuntansi PPN”. Seperti yang telah kami sebutkan di atas, kami memiliki jendela perbandingan konfigurasi yang terbuka di Work Base Configurator. Kami mencari objek yang kami butuhkan di sana. Faktanya, posisinya di pohon konfigurasi dijelaskan dalam file teks kita, yaitu: “GeneralModule.VAT Accounting.Module”. Inilah yang kami cari di jendela perbandingan. Kami memperluas pohon subordinasi sampai kami menemukan modul yang diperlukan - di tepi kiri di seberangnya harus ada pensil hijau yang menunjukkan bahwa objek telah diubah dibandingkan dengan konfigurasi pemasok. Klik kanan pada baris yang ditemukan dan pilih "Tampilkan perbedaan dalam modul...":

Setelah ini, jendela perbandingan modul akan terbuka:

Di sini, di bagian atas ditunjukkan prosedur Dan fungsi, di mana ada perubahan (dalam kasus kami, ini adalah salah satu prosedur "Faktur Keluaran dalam Dokumen Tabular"), dan di bagian bawah - teks dari prosedur atau fungsi yang dipilih dengan perubahan yang disorot. Kita perlu mentransfer perubahan ini ke database pengujian kita. Namun ini tidak menghapus perubahan dari pembaruan. Anda dapat mengotomatiskannya sebagai berikut. Tempatkan kursor di bagian kiri bawah (tempat teks prosedur yang dipilih dengan perubahan kita) dan tekan secara berurutan Ctrl+A (pilih semua) dan Ctrl+C (salin pilihan ke clipboard). Kemudian kita buat file dengan nama kode "old_izm.txt", buka di editor teks dan tekan Ctrl+V (paste isi buffer). Kami melakukan hal yang sama untuk bagian kanan bawah (di mana teks prosedur yang dipilih dari konfigurasi standar rilis yang tidak diperbarui) - sebagai hasilnya, kami membuat file dengan nama kode "old_type.txt". Setelah ini, kita pergi ke Test Base Configurator (harus terbuka berdampingan, tetapi tanpa jendela apa pun di dalamnya, agar tidak bingung dengan kedua konfigurator ini) - dan dalam konfigurasi kita mencari modul kita (dalam contoh ini itu adalah "GeneralModule.VAT Accounting.Module") dan di dalamnya prosedur yang diperlukan (dalam contoh ini adalah "Faktur Keluaran dalam Dokumen Tabular"): pilih semuanya dan salin ke yang baru berkas teks dengan nama kode "new_type.txt". Jadi, kita memiliki tiga file ("old_izm.txt", "old_type.txt", "new_type.txt"), yang menjadi dasar kita perlu membuat file keempat - "new_izm.txt". File keempat ini harus berisi perubahan kami, tetapi dengan mempertimbangkan pembaruan. Kita akan membentuknya secara berurutan dengan membandingkan ketiga file yang ada. Pertama, mari kita tentukan apakah ada jejak perubahan pembaruan dalam prosedur ini? Untuk melakukan ini, kami membandingkan file "old_type.txt" dan "new_type.txt" menggunakan Total Commander (lihat di atas). Jika perbandingan menunjukkan bahwa file-file tersebut identik atau terdapat perbedaan jumlah spasi atau tab, berarti kami beruntung dengan perubahan ini dan Anda dapat mentransfer perubahan hanya dengan menyalin isi file “old_izm.txt ” dan menempelkannya ke modul terbuka dari database pengujian, menghapus prosedur terkait terlebih dahulu (dengan kata lain, menggantinya). Di sini penting untuk memantau dengan cermat ruang sebelum dan sesudah prosedur sehingga tidak ada redundansi dalam perbandingan lebih lanjut: ini, tentu saja, tidak akan memengaruhi fungsionalitas, tetapi akan sedikit mempersulit verifikasi. Jika perbandingan “old_type.txt” dan “new_type.txt” menunjukkan adanya perbedaan nyata, ini berarti prosedur ini berisi perubahan kami dan perubahan dari pembaruan. Untuk menyederhanakan tugas transfer: pertama, Anda dapat menilai secara visual perubahan mana yang lebih besar - dari pembaruan atau perubahan kami. Untuk melakukan ini, sekali lagi melalui Total Commander, kami membandingkan "old_type.txt" secara berurutan dengan "new_type.txt" dan "old_izm.txt". Dan kami melihat di mana ada lebih banyak perubahan: dalam perbandingan “old_type.txt” dan “new_type.txt” atau dalam perbandingan “old_type.txt” dan “old_izm.txt”. Jika pada perbandingan pertama lebih banyak perubahan (pembaruan lebih banyak mengubah fungsi), maka lebih mudah untuk memperbaiki file yang diperbarui dengan melakukan perubahan, yaitu kita mengubah “new_type.txt”. Sebut saja ini kasus pertama dalam melakukan perubahan. Jika pada perbandingan kedua ada lebih banyak perubahan (kami memiliki lebih banyak perubahan), maka lebih mudah untuk memperbaiki file kami dengan melakukan perubahan pembaruan, yaitu kami mengubah “old_izm.txt”. Sebut saja ini kasus kedua dalam melakukan perubahan. Sekarang bagaimana tepatnya mentransfer perubahan dengan cepat dan akurat. Untuk melakukan ini, kami membuat file keempat dan, sebagaimana telah disepakati, beri nama "new_izm.txt". Dengan mempertimbangkan optimalisasi transfer koreksi, kami menyalin konten “new_type.txt” atau “old_izm.txt” ke dalam file ini (masing-masing untuk kasus perubahan pertama atau kedua).
Sekarang buka dua jendela perbandingan file sekaligus. Untuk kasus pertama perubahan, ini adalah perbandingan untuk file "new_izm.txt"/"old_izm.txt" dan "old_type.txt"/"old_izm.txt". Untuk kasus kedua, ini adalah perbandingan file "new_izm.txt"/"new_type.txt" dan "old_type.txt"/"new_type.txt". Di jendela perbandingan ada tombol "Edit": klik di perbandingan pasangan pertama. Sekarang mari kita jelaskan apa yang kita lihat. Pada pasangan perbandingan pertama, objek dari perubahan dan pembaruan kami terlihat. Tergantung pada kasus kami, kami hanya perlu mentransfer perubahan kami, atau pembaruan saja. Di jendela perbandingan kedua, hanya perubahan yang perlu kita transfer yang terlihat. Jika Anda perhatikan - dalam kedua kasus, file kedua dari perbandingan pertama dan kedua adalah sama. Oleh karena itu, kami fokus pada baris dalam file ini, dan sesuai dengan baris pada perbandingan kedua, kami membuat perubahan di jendela perbandingan pertama: menekan tombol "Edit" hanya akan memungkinkan kami melakukan ini.

Untuk lebih jelasnya, mari kita gambarkan secara grafis tindakan selama transfer dalam kasus pertama (kami mengubah file yang diperbarui dengan membuat perubahan):

Tindakan dalam kasus kedua sangat mirip dan prinsip tindakannya persis sama.

Kasus yang paling sulit dan tidak menyenangkan adalah ketika perubahan dan pembaruan kita ada di SATU tempat. Artinya, kenyataannya ada dua perubahan dalam satu segmen kode. Dalam hal ini, diperlukan intervensi programmer. Intervensi pemrogram juga diperlukan, namun pada tingkat yang lebih rendah, jika, misalnya, pembaruan mengubah nama variabel yang digunakan dalam perubahan kami. Perlu juga dicatat bahwa file "old_type.txt" atau "old_izm.txt" mungkin berisi baris kosong - ini adalah "jejak" dari perubahan kami. Anda perlu mentransfernya agar tidak ada di file akhir. Ini tidak mempengaruhi fungsionalitas, tetapi dalam perbandingan lebih lanjut (dengan pembaruan berikutnya) ini akan membuat analisis tindakan sedikit lebih sulit. Jadi, setelah kita membuat file keempat, mentransfer semua perubahan, kita perlu menyalin isinya ke konfigurasi. Di Test Database Configurator, modul yang diperlukan harus dibuka di lokasi baru: hapus prosedur yang ada dan masukkan konten file akhir kita, dengan mempertimbangkan semua spasi antara fungsi sebelumnya/selanjutnya. Jadi, kami mentransfer perubahan ke SATU prosedur dari objek yang ditemukan. Kami (Gbr. 6) sebenarnya hanya memiliki satu prosedur. Jika ada beberapa prosedur seperti itu, langkah-langkah yang dijelaskan harus dilakukan untuk masing-masing prosedur. Jika prosedurnya baru (hanya di bagian kiri), maka tambahkan saja ke modul yang sesuai di database pengujian (untuk kebenaran perbandingan lebih lanjut, Anda perlu menjaga urutan prosedur, seperti pada modul kerja yang sesuai. database, dimana masih ada rilis lama).

2.2.2. Perubahan yang ditimpa oleh pembaruan TIDAK ada dalam modul. Untuk mentransfer perubahan tersebut, perbandingan seperti itu tidak akan menyederhanakan pekerjaan dengan cara apa pun, sehingga perubahan ditransfer hanya dengan perbandingan visual objek dalam database kerja dan pengujian.

Jadi, kami mentransfer perubahan untuk setiap objek di mana perubahan kami ditimpa oleh pembaruan. Untuk memeriksa seberapa benar kami mentransfer semua perubahan, kami menyimpan konfigurasi di database pengujian, mengunggah perbandingan konfigurasi ke file "Comparison Report_new2.txt" dan membandingkannya dengan file "Comparison Report_old.txt". Jika semuanya sudah sempurna, pesan “File-file tersebut identik” akan muncul. Jika beberapa objek dihapus oleh pembaruan, maka jika perubahan ditransfer dengan benar, hanya objek ini yang akan terlihat perbedaannya. Akan benar jika hanya spasi/baris/tab kosong yang terlihat dalam perbandingan, tetapi dalam hal ini lebih baik untuk menghapusnya dan mendapatkan pesan “File-file tersebut identik”. Jadi, setelah menyimpan perubahan dalam database pengujian, kami mengunggah perbandingan ke file dan membandingkannya dengan perubahan pada rilis lama - kami mengulanginya hingga perbandingan menunjukkan bahwa kami telah mentransfer semua perubahan yang diperlukan.

3. Mentransfer konfigurasi yang diperbarui dari pengujian ke database yang berfungsi. Pada tahap sebelumnya, kami memperbarui basis pengujian ke rilis terbaru, memeriksa dan mentransfer perubahan yang diperlukan dan menyimpan konfigurasi yang dihasilkan. Sekarang kami mengunggahnya ke file cf dan memuatnya ke dalam database yang berfungsi. Sebelum mengunduh, Anda perlu membuat salinan database yang berfungsi dan menghapus konfigurasi dari dukungan. SEMUA. Pengguna "berdiam diri" hanya di awal, saat kami membongkar database, dan di akhir, saat kami membongkar database lagi dan memuat konfigurasi.

Pembaruan ini telah selesai sepenuhnya.

Artikel asli ada di website

Dalam instruksi untuk pembaruan non-standar 1c 8.3 yang dimodifikasi ini, saya tidak akan menjelaskan hal-hal dasar, seperti: cara membuka konfigurator, apa konfigurasi database, konfigurasi pemasok, dan konfigurasi utama. Banyak yang telah ditulis tentang ini, dan Anda dapat menemukan informasi ini sendiri di Internet. Saya akan mencoba menjelaskan poin-poin utama dari proses pembaruan dan apa yang perlu Anda perhatikan.
Saya mengambil akuntansi atipikal 3.0.51.22 sebagai contoh dan akan menunjukkan cara memperbaruinya ke versi 3.0.53.29. Pada platform versi 8.3.10.2561 (tidak ada perbedaan besar pada platform lama, jendela perbandingan hanya terlihat sedikit berbeda sebelumnya).
Saya akan segera mengatakan bahwa akan ada banyak gambar dan sedikit teks. Saya merasa lebih mudah mengingat suatu proses secara visual daripada membaca lautan teks.

1. Periksa apakah konfigurasi database cocok dengan konfigurasi vendor.

Untuk ini, Anda perlu

Jika ada kecocokan, Anda dapat melanjutkan ke langkah 2 dengan aman.

1a. Menyiapkan konfigurasi untuk dukungan.

Jika versi database Anda dan versi konfigurasi vendor berbeda, maka Anda perlu menghapus konfigurasi saat ini melalui menu yang sama: konfigurasi - dukungan - pengaturan dukungan. Dan klik tombol “Mundur dari dukungan”.

Setelah menunggu "sebentar", kami menghapus centang semua kotak. Nah, Anda dapat menghapus centang pada kotak “Simpan pengaturan secara otomatis”. Dan klik jalankan.

Hasilnya, kita akan mendapatkan konfigurasi yang didukung dengan versi database yang sama.

2. Perbarui basis data.

Sekarang Anda dapat melanjutkan ke pembaruan.

Izinkan saya memberi tahu Anda segera bahwa pembaruan harus dilakukan HANYA melalui menu "Konfigurasi" - "Dukungan" - "Perbarui konfigurasi...".
Anda TIDAK BISA menggunakan "Bandingkan, gabungkan dengan konfigurasi dari file..."!!! Saat menggunakan mekanisme ini, Anda akan melakukannya pembaruan berikutnya Anda harus pergi ke poin 1a. Oleh karena itu, jangan lakukan ini dan menimbulkan masalah yang tidak perlu bagi diri kita sendiri (atau orang yang akan memperbarui database di lain waktu).

Selanjutnya, pilih file pembaruan.
Saya ingin berbicara tentang pembaruan setelah beberapa rilis. 1C tidak menyarankan memperbarui file CF dengan melompati beberapa rilis sekaligus. Hal ini harus dilakukan secara konsisten. Secara teori hal ini benar.
Saya akan menjelaskan mengapa hal ini tidak disarankan. Jika pemrogram ingin menghapus alat peraga apa pun, pertama-tama mereka menetapkan awalan “hapus” padanya, kemudian setelah beberapa rilis mereka menghapusnya. Dan mereka dapat mentransfer informasi darinya dalam beberapa rilis. Dengan melewatkan rilis ini, Anda mungkin kehilangan data. Namun dalam praktiknya, selama 10 tahun saya bekerja dengan database 1C, saya punya satu kasus seperti itu. Ketika karena alasan tertentu pengembang memutuskan untuk mentransfer data dari listingan ke direktori. Namun, ini tidak berakhir dengan sesuatu yang penting bagi saya. saya menulis pemrosesan sederhana, yang mentransfer data ini dari arsip ke database saat ini. Tidak perlu melakukan pembaruan ulang apa pun.
Anda bisa melempari saya dengan batu, tapi saya selalu mengupdate database melalui file cf untuk beberapa rilis.
Jadi kami mengklik perbarui, sebuah pesan muncul memberitahu kami versi mana pembaruan akan dilakukan. Kami klik OK.

Kami menunggu perbandingan objek berlangsung.
Selanjutnya, kita perlu memilih “hanya tampilkan properti yang diubah dua kali” dari daftar di bawah.

Saya juga ingin mengatakan bahwa menurut versi lama, sebelumnya ada kotak centang.

Jadi, kita sekarang melihat lebih sedikit objek.

Jika milik Anda kosong, maka Anda sangat beruntung, dan Anda dapat dengan aman mengklik tombol “jalankan” dan menganggap pembaruan telah selesai. Ya, tidak semuanya sesederhana itu di sini, jadi saya akan membahas objek utamanya.

Hal pertama yang ingin saya katakan. Jangan mengalihkan mode penggabungan dalam kondisi apa pun. Seharusnya "Ambil dari konfigurasi pemasok baru". Jika tidak, Anda akan mendapatkan sampah di database dengan komentar MGR.
Tidak ada tombol "tunjukkan perbedaan dalam modul...".!
Klik pada ikon roda gigi di sebelah modul

Sebuah jendela terbuka di mana ada banyak perubahan fungsi dan prosedur.

Untuk memahami fungsi mana yang mengalami perubahan, kita perlu mengambil salinan database, atau menyimpan konfigurasi ke file melalui menu konfigurasi. Dan kemudian memuatnya ke database kosong. Selanjutnya, buka menu “konfigurasi” dan klik “Bandingkan konfigurasi…”
Pilih Bandingkan Konfigurasi Dasar dengan Konfigurasi Vendor.

Dan sekarang Anda dapat melihat perubahannya melalui “tunjukkan perbedaan modul…”. Karena kami tidak akan mengubah apa pun, kami hanya ingin melihat apa yang telah diubah.

Dan kita melihat bahwa sepotong kode telah ditambahkan ke fungsi “Kemiringan”. Semua perubahan dapat dilihat dengan mengklik panah biru.

Mari kembali ke konfigurasi yang diperbarui. Di sana kami menggunakan ikon roda gigi untuk masuk ke mode penggabungan modul. Selanjutnya, centang semua kotak... secara manual... ucapkan pada diri sendiri “terima kasih” kepada pengembang platform :)

Kami menemukan fungsi penurunan kami. Menemukan elemen yang diubah. Saya harap sekarang jelas mengapa Anda perlu memisahkan kode yang ditambahkan dengan komentar - dengan benar, agar tidak menebak-nebak saat memperbarui dari mana kode ini berasal.
Klik ikon kaca pembesar, dan platform akan menyorot baris kode di mana Anda perlu menambahkan teks ini.

Salin dari jendela atas dan tempel ke jendela bawah.

Lakukan ini dengan semua modul. Jika modul belum diubah, seperti dalam kasus kita dengan direktori mata uang. Kita cukup atur modenya menjadi “Ambil dari konfigurasi pemasok baru” dan JANGAN klik roda gigi (tidak boleh ada tanda centang hijau di sebelah roda gigi, artinya kode akan diambil seluruhnya dari konfigurasi baru, tanpa manual. konfigurasi).

Besar. Sekarang, setelah memeriksa semua objek, Anda dapat menghapus centang "simpan pengaturan secara otomatis" dan kemudian "eksekusi"

Untuk pesan “Ada objek yang telah diubah di konfigurasi utama sehubungan dengan konfigurasi lama... Saat memperbarui, objek ini akan diganti! Menjalankan? Kami dengan berani mengklik YA.

Di jendela berikutnya, biarkan kotak centang seperti yang ditunjukkan pada gambar. Dan tidak ada yang lain!!! Kedua kotak centang harus dicentang - “objek diedit sambil mempertahankan dukungan.” Klik Oke.

Semua. Memperbarui konfigurasi atipikal 1s selesai.
Cara ini memang tidak dimaksudkan untuk sempurna, namun menurut saya banyak orang yang melakukan kesalahan dalam langkah ini.
Tentu saja saya belum menceritakan semuanya, masih banyak kendala. Namun menurut saya 90% pembaruan dapat diperbarui dengan aman menggunakan petunjuk ini.

Pengalaman pribadi: cara memperbarui konfigurasi yang diubah dengan cepat dan hemat biaya

Memperbarui konfigurasi untuk beberapa rilis sekaligus sangatlah berbahaya. Faktanya adalah bahwa setelah setiap pembaruan konfigurasi, pembaruan basis info dimulai dalam mode 1C:Enterprise. Oleh karena itu, jika Anda hanya memperbarui rilis terbaru, basis informasi mungkin tidak sesuai konfigurasi terbaru. Dalam artikel tersebut, Dmitry Rudakov, seorang spesialis di Siberian Agrarian Group CJSC, berbagi pengalaman pribadi untuk pembaruan konfigurasi satu kali untuk 12 rilis.

Memeriksa mode perubahan konfigurasi

Mari kita bayangkan situasi seperti ini. Pengembang "Manajemen Perusahaan Manufaktur" (selanjutnya disebut PPE) dalam rilis 1 (nomor rilis selanjutnya ditetapkan secara kondisional) menetapkan dimensi (indikator) dari register perhitungan jenis "Link Direktori.Individu" dengan nama "Individu" . Dalam rilis 2 mereka menambahkan satu dimensi lagi - "Karyawan" dengan tipe "DirectoryLink.Employees". Saat Anda memulai "1C:Enterprise", pemrosesan diaktifkan, yang mengisi dimensi "Karyawan" dengan cara yang sesuai dengan dimensi untuk "Individu". Dan kemudian di rilis 3, pengembang 1C menghapus dimensi “Individu” dan hanya menyisakan “Karyawan”. Jika Anda segera memperbarui konfigurasi dari rilis 1 ke rilis 3, Anda dapat menghapus seluruh register penghitungan.

Dan jika konfigurasi didukung dengan kemungkinan perubahan, dan pelaporan yang diatur dihasilkan dalam database yang sama, maka perlu memperbarui konfigurasi untuk setiap rilis, yang bisa sangat mahal dalam hal jam kerja. Misalnya, memperbarui "UPP" yang banyak dimodifikasi untuk 1 rilis mungkin memerlukan waktu 30 jam dari waktu spesialis berpengalaman.

Oleh karena itu, sebelum Anda mulai memperbarui, Anda perlu menentukan: apakah Anda bekerja dalam konfigurasi standar dengan kemampuan untuk mengubah atau dalam konfigurasi tanpa kemampuan untuk mengubah? Untuk melakukan ini, buka konfigurator, di mana di menu ikuti langkah-langkah "Konfigurasi - Dukungan - Pengaturan Dukungan".

Gambar.1. Memanggil jendela pengaturan dukungan konfigurasi

Jika diatur ke “Pada dukungan”, maka konfigurasi ini tipikal, dan jika “Kemungkinan modifikasi diaktifkan”, kemungkinan besar konfigurasi telah diubah (setidaknya, kemungkinan seperti itu disertakan). Status ketiga adalah "Konfigurasi tidak lagi didukung". Status konfigurasi yang berbeda ditunjukkan pada Gambar 2, 3, 4.

Beras. 2. Konfigurasi standar tanpa kemungkinan perubahan

Beras. 3. Konfigurasi khas dengan kemampuan untuk mengubah diaktifkan

Beras. 4. Konfigurasi yang tidak digunakan lagi

Algoritma untuk memperbarui konfigurasi yang diubah

Baru-baru ini saya dihadapkan pada tugas memperbarui konfigurasi Manajemen Perdagangan yang dimodifikasi, rilis 10.3.13.2. Konfigurasi diubah sebagai hasil integrasi dengan solusi industri "BIT: Automotive Service Management 8" dan terus ditingkatkan selama dua tahun. Sekarang konfigurasi perlu diperbarui ke rilis 10.3.25.1, yaitu 12 rilis. Saya telah membagi seluruh prosedur pembaruan menjadi beberapa tahap.

Tahap 1. Estimasi biaya dan waktu prosedur update

Sebelum Anda mulai pekerjaan mandiri, saya memutuskan untuk mendapatkan penilaian independen dari para ahli di bidang ini. Satu-satunya perusahaan yang memiliki kemampuan untuk memperbarui konfigurasi yang diubah menggunakan metode otomatis adalah 1C-IzhTiS LLC. Saya menghubungi spesialis perusahaan ini dengan permintaan untuk memperkirakan biaya memperbarui konfigurasi saya. Untuk memperkirakan waktu dan biaya pekerjaan, saya telah memberikan konfigurasi saat ini yang perlu diperbarui. Sehari kemudian saya menerima surat dengan laporan.

Laporkan hasil penilaian biaya dan waktu pembaruan konfigurasi:

Konfigurasi: Manajemen Perdagangan, edisi 10.3
Versi saat ini konfigurasi: 10.3.13.2
Pembaruan ke versi: 10.3.25.1
Jumlah modul yang diperbarui: 1.847
Jumlah rilis kontrol: 8

Hasil penilaian mengejutkan saya, karena harga sahamnya tertera di situs web perusahaan - 1000 rubel. per pembaruan per rilis. Komentar dari "1C-IzhtiSi":

“Biaya pembaruan untuk setiap rilis yang terlewat tidak lebih dari 2.000 rubel. Saat ini sedang berlangsung promosi, sehingga biayanya tidak melebihi 1.000 rubel. Namun harga akhir layanan ditentukan dengan memperkirakan biaya tenaga kerja untuk pembaruan dan mungkin kurang dari 1.000 rubel per rilis.”

Saya juga mengklarifikasi bagaimana rilis yang diperlukan untuk pembaruan dipilih. Menanggapi pertanyaan saya, saya menerima tangkapan layar yang menunjukkan hal ini dengan jelas (Gbr. 5). Kolom Nomor Versi menunjukkan versi konfigurasi yang perlu Anda tingkatkan. Kolom "Peningkatan Versi" menunjukkan dari rilis mana peningkatan dapat dilakukan. Dari hasil penilaian, jumlahnya pembaruan yang diperlukan dikurangi menjadi 9.

Beras. 5. Memilih rilis yang harus digunakan untuk memperbarui konfigurasi dengan benar

Setelah mempelajari laporan 1C-IzhTiS, saya menghitung biaya waktu pribadi untuk jumlah pekerjaan yang sama. Setiap pembaruan membutuhkan waktu sekitar 6 jam. Jadi total biaya waktu adalah 56 (9x6) jam kerja, yaitu kurang lebih tujuh hari kerja. Selain itu, ada kemungkinan beberapa kekurangan akan terungkap setelah pembaruan: misalnya, pengguna akan mengeluh bahwa perubahan konfigurasi yang diperlukannya hilang, dan kemudian biaya waktu akan meningkat secara signifikan. Sementara itu, spesialis dari perusahaan 1C-IzhTiSi menawarkan untuk menyelesaikan seluruh pekerjaan dalam tiga hingga empat hari kerja. Oleh karena itu, saya memutuskan untuk menggunakan layanan mereka.

Sekarang saya akan menjelaskan secara singkat apa sebenarnya yang diubah dalam konfigurasi.

Objek yang banyak dimodifikasi. Ini adalah objek yang banyak properti tipikalnya telah diubah. Penyesuaiannya rumit. Detail objek telah ditambahkan bagian tabel, ditampilkan pada formulir objek dan pada formulir daftar. Penangan untuk detail tambahan dalam formulir telah ditambahkan. Mekanisme standar untuk memposting dokumen atau mencatat serangkaian pergerakan untuk register telah diubah.

Dokumen yang banyak dimodifikasi:
"Pesanan ke pemasok";
"Pergerakan barang";
"Faktur Persyaratan";
"Penerimaan barang dan jasa."

Register yang banyak dimodifikasi:
"Pengiriman barang ke gudang";
"Barang di gudang."

Objek yang dimodifikasi secara signifikan. Objek yang detailnya telah ditambahkan, baik bentuk objek atau modul objek telah diubah (sebagai aturan, pemrosesan dokumen tidak lazim).
Dokumentasikan "Pesanan penerimaan tunai";
Daftar informasi "Bagian komponen";
Daftar informasi "Barang yang dihapuskan";
Modul umum.

Objek yang sedikit dimodifikasi. Hanya bentuk pada objek yang diubah dan detailnya ditambahkan.

Direktori:
"Jenis tata nama";
"Perjanjian Kontraktor";
"Pihak Rekanan";
"Tata nama";
"Jenis harga barang";
“Sejumlah informasi mendaftar.”

Di bagian "Umum", langganan acara, tata letak, peran, dan modul umum telah diubah. Hampir semuanya telah diubah oleh keputusan industri.

Langkah 2: Menghapus informasi rahasia

Sebelum memberikan basis informasi untuk pengujian kepada karyawan 1C-IzhTiS, informasi rahasia harus dihapus darinya. Untuk kasus seperti itu, 1C merekomendasikan penggunaan pemrosesan “Perubahan Informasi Rahasia”, yang tidak diketahui secara luas.

Pemrosesan “Perubahan Informasi Rahasia” dimaksudkan untuk mengubah atau membersihkan informasi secara selektif di basis info.Perawatannya bisa digunakan untuk persiapan basis informasi sebelum transmisi untuk pengujian, jika perlu menyembunyikan (menghapus, mengubah) beberapa informasi.

Memproses ChangeConfidentialInformation.epf ada pada disk ITS di direktori 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Juga pemrosesan ini dapat diunduh dari tautan: http://its.1c.ru/db/metod81#content:1644:1.

Tentu saja, informasi rahasia Setiap perusahaan berbeda, namun saya ingin menarik perhatian Anda pada data yang kemungkinan besar perlu diubah:

• Direktori: Perorangan, Kontak person, Kontak person rekanan, Rekanan, Jenis harga.
• Register informasi: Data paspor individu, Nama Lengkap Perorangan.

Daftar Anda mungkin akan lebih panjang, namun ini adalah poin data yang paling umum. Mengubahnya tidak akan mempengaruhi kemampuan untuk menguji basis informasi Anda. Anda juga dapat menggunakan pemrosesan grup untuk menghapus semua objek yang tidak seharusnya digunakan oleh perusahaan jasa.

Langkah 3: Mendapatkan hasil pembaruan

Tiga hari kemudian saya diberikan file cf dan instruksi lengkap untuk menginstalnya. Untuk rilis kontrol, disediakan file cf yang tidak dapat digunakan untuk pekerjaan pengguna, karena hanya metadata yang diperbarui di dalamnya. Mereka dimaksudkan hanya untuk pembaruan yang benar ke versi terbaru.

Berdasarkan hasil pekerjaan, saya dapat mengatakan bahwa semua perubahan konfigurasi telah dipertahankan; setelah diperiksa secara visual, semua objek yang diubah tetap mempertahankan fitur dan perbedaannya dari konfigurasi standar. Selama pengoperasian, tidak ada pengguna yang melaporkan bahwa ada perubahan yang hilang.

Sebagai hasil dari pembaruan, saya mengidentifikasi dua tugas kecil yang harus saya selesaikan sendiri.

Pertama. Karena pembaruan dilakukan menggunakan mekanisme “Bandingkan, Gabungkan”, konfigurasi database benar-benar diperbarui, dan diperbarui dengan benar, tanpa risiko teknis karena memperhitungkan rilis kontrol. Namun, konfigurasi penyedia tidak diperbarui. Tentu saja, spesialis yang kompeten secara teknis akan dengan mudah melengkapinya pekerjaan ini, namun, saya meminta 1C-IzhtiSi untuk mengirim lebih banyak instruksi lengkap oleh pembaruan. Sesuai dengan itu, pembaruan dapat dilakukan bahkan oleh spesialis yang tidak berpengalaman.

Kedua. Sebagai hasil dari pembaruan, semua objek tetap dalam dukungan dengan kemungkinan perubahan, yang juga dapat menjadi kerugian tidak langsung. Jika Anda perlu menggunakan layanan ini sekaligus, maka Anda perlu mengembalikan semua objek ke dukungan. Sejauh ini saya hanya dapat melakukan ini dengan menelusuri semua objek metadata. Sayangnya, proses ini saat ini dilakukan secara manual, namun kedepannya akan dilakukan secara otomatis.

Selain dua tugas yang disebutkan, satu kelemahan kecil ditemukan, yang pada prinsipnya tidak mempengaruhi kualitas pembaruan dan jarang muncul. Sebagai hasil dari pembaruan, baris kode konfigurasi asli dan yang diperbarui secara visual cocok, tetapi karena alasan tertentu spasi ditambahkan di akhir baris. Ini merupakan kerugian karena sedikit meningkatkan jumlah kode yang dimodifikasi. Dan jika terjadi lebih lanjut pembaruan manual akan lebih baik jika tidak memiliki bagian kode seperti itu. Pada Gambar. 6 menunjukkan contoh sebelum pembaruan, dan Gambar. 7 - contoh setelah pembaruan.

Konfigurasi 1C yang tidak lazim (dimodifikasi) adalah sistem otomatis pengelolaan suatu perusahaan yang telah mengalami beberapa kali perubahan karena kekhususan atau kebutuhan usaha.

Ketika konfigurasi pertama menjadi populer dan digunakan di banyak perusahaan, itu menjadi standar.

Pada tipe kedua, pengembang sendiri membuat perubahan, penambahan dan perbaikan seiring berjalannya waktu, menjadikan pengaturan lebih nyaman atau relevan. Pada saat yang sama, jika organisasi puas dengan konfigurasinya, maka tidak perlu memperbaruinya ke yang baru.

Tetapi jika sejumlah perubahan besar dilakukan pada undang-undang (misalnya, algoritma akuntansi diubah), maka ada 2 opsi tentang apa yang harus dilakukan dengan pembaruan tersebut:

• perbarui ke versi standar baru;
• perbarui sendiri konfigurasi 1C non-standar, dengan mempertimbangkan perubahan undang-undang.

Masalah dengan memperbarui konfigurasi non-standar adalah tugas ini tidak dapat sepenuhnya otomatis karena tidak ada skrip standar. Oleh karena itu, ketika pembaruan 1C dari konfigurasi non-standar dilakukan, harus ada spesialis yang dapat melakukan semua operasi manual yang diperlukan.
Sebagai contoh, mari kita ambil konfigurasi non-standar "1C: Trade Management" tahun 2014 dan pembaruannya ke rilis berikutnya yang tersedia.

Terlepas dari konfigurasinya, semua tahapan pembaruan program akan sama, tetapi untuk beberapa hal akan memakan waktu lebih sedikit, untuk yang lain akan memakan waktu lebih lama. Durasinya tergantung pada jumlah modifikasi. Paling-paling, pemeriksaan manual mungkin diperlukan jika ada banyak modifikasi.

Petunjuk langkah demi langkah tentang cara memperbarui sendiri konfigurasi 1C non-standar

Langkah-langkah peningkatan:

1. Mengunggah database informasi.
2. Buka menu "Konfigurasi". Di sana kami memilih item menu "Dukungan" dan kemudian "Perbarui konfigurasi".
3. Setelah langkah sebelumnya, kita upload form laporan, setelah sebelumnya dikonfigurasi.
4. Mari beralih ke proses pembaruan itu sendiri. Untuk melakukan ini, klik tombol “Jalankan”.
5. Jendela informasi terbuka dengan elemen pemilihan data dan pengaturan. Anda tidak mengubah apa pun tentang hal itu. Klik "Oke".
6. Mari kita luncurkan Enterprise.
7. Agar pembaruan selesai, Anda harus menerima perubahan di menu konteks yang terbuka.
8. Dengan menggunakan fungsi F5, Anda menerima konfirmasi bahwa semua pembaruan yang dilakukan adalah legal.

Setelah poin terakhir, ketika jendela pop-up terbuka untuk mengonfirmasi pembaruan, Anda harus kembali ke konfigurator, membuka objek metadata yang diperbarui dan secara manual membuat perubahan pada kode program.

Mari kita pertimbangkan pembaruan menggunakan contoh konfigurasi non-standar SCP 1.3, yang didukung dengan kemungkinan perubahan dari rilis 1.3.61.2 ke rilis 1.3.62.1. Karena konfigurasinya sendiri cukup berat, hal ini menimbulkan beberapa kekhasan, khususnya, tidak selalu mungkin untuk membuka beberapa jendela perbandingan konfigurasi dalam satu konfigurator.

Untuk pembaruan, saya menggunakan dua salinan identik dari database rilis lama. Di salah satu dari mereka saya melakukan pelatihan *.lih untuk memperbarui, sebut saja, misalnya, untuk_memperbarui. Basis data lainnya tetap tidak tersentuh dan hanya berfungsi sebagai basis data tambahan untuk membandingkan konfigurasi, sebut saja basis. Pada prinsipnya, konfigurasi dasar kerja dapat digunakan sebagai konfigurasi tambahan.

Di basis data untuk_memperbarui kami melaksanakan *.cfu rilis baru. Prosedur pembaruan dimulai dan jendela pembaruan muncul.

Tekan tombol " Menjalankan", pada tahap ini belum perlu melihat apa pun, karena tujuannya hanya untuk mendapatkan konfigurasi vendor dari rilis baru.

Selama proses pembaruan, “ Tautan yang belum terselesaikan", klik" Melanjutkan" Kami akan membicarakan alasan munculnya jendela ini di bawah.

Akan muncul pesan yang menyatakan bahwa objek yang kita ubah akan dimuat dari konfigurasi baru, kami setuju.

Jendela “ Menyiapkan aturan dukungan" - untuk objek baru (bagian atas) di kedua sisi atur " Objek diedit dengan tetap mempertahankan dukungan", untuk objek pemasok yang ada (bagian bawah) di keempat tempat kita pasang benderanya" Simpan mode saat ini", klik" OKE».

Konfigurasi utama telah diperbarui. Kami tidak memerlukan konfigurasi utama itu sendiri pada tahap ini; tujuannya adalah untuk mendapatkan konfigurasi pemasok baru. Oleh karena itu, kami tidak menyimpan konfigurasi utama dan tidak memperbarui konfigurasi database.

Jalankan " Konfigurasi» - « Mendukung» - « Menyiapkan dukungan" Di jendela yang terbuka, pilih “ Simpan ke file"dan simpan di dalamnya *.lih konfigurasi vendor rilis baru.

Kami tidak memerlukan konfigurasi utama dalam bentuk yang ada saat ini. Tutup konfigurasi. " Konfigurasi» - « Tutup konfigurasi" Kami menolak untuk menyimpan perubahan.

Dalam konfigurasi untuk perbandingan basis kita mulai membandingkan konfigurasi pemasok (rilis lama) dan konfigurasi pemasok dari file (rilis baru).

Jadi, kita hanya akan melihat perubahan yang akan dilakukan pada konfigurasi saat memperbarui ke rilis baru.

Di basis data untuk_memperbarui kami mulai memperbarui konfigurasi lagi melalui dukungan "Konfigurasi" - "Dukungan" - "Perbarui konfigurasi", di jendela yang terbuka, pilih *.cfu rilis baru. Prosedur pembaruan dimulai dan jendela pembaruan muncul.

Saat Anda menekan tombol " Menyaring"jendela akan terbuka" Menyiapkan filter tampilan" Di jendela ini, atur bendera “ Tampilkan hanya dua kali properti yang diubah».

Saat memperbarui tanpa campur tangan kami, hal berikut terjadi:

• - objek belum kami ubah, diubah di rilis baru - diperbarui dari rilis baru;
• - objek diubah oleh kami, tidak diubah dalam rilis baru - objek kami tetap;
• - objek telah kami ubah, diubah di rilis baru - ini adalah objek yang diubah dua kali, jika Anda tidak mengubah apa pun, itu akan dimuat dari rilis baru.

Oleh karena itu, perhatian paling dekat harus diberikan pada objek yang diubah dua kali, dan kami akan mempertimbangkannya.

Dalam contoh ini, beberapa modul umum telah diubah, termasuk modul umum "akuntansi PPN».

Secara default, jendela pembaruan menunjukkan perbedaan antara konfigurasi penyedia utama dan baru dari konfigurasi penyedia lama.

Jika Anda melihat perbedaan konfigurasi pada modul umum " akuntansi PPN", maka kita akan melihat gambar berikut:

Jika kita membandingkan modul-modul ini di database perbandinganbasis, maka gambarnya akan berbeda:

Jelas sekali bahwa fungsinya " Mengumpulkan data untuk pencetakan, koreksi, faktur, faktur», « Kumpulkan data untuk mencetak faktur penyesuaian" dan lainnya berisi perbaikan kami, tetapi tidak berubah selama pembaruan, yang berarti tidak ada gunanya membuang waktu untuk melihat dan menganalisisnya.

Oleh karena itu, saat melakukan pembaruan prosedural dari prosedur dan fungsi yang dipilih, Anda dapat menghapus tanda:

Banyak yang akan mengatakan bahwa Anda dapat melihat perbedaan antara konfigurasi pemasok lama dan yang baru dengan mengubah pengaturan filter tampilan di konfigurator saat ini, tanpa menggunakan perbandingan konfigurasi di databasebasis.

Misalnya seperti ini:

Namun, seperti yang ditunjukkan oleh pengalaman praktis, hal ini tidak terjadi, prosedur dan fungsi masih ditampilkan di jendela perbandingan modul, bahkan dengan filter “; menunjukkan perbedaan antara konfigurasi penyedia baru dan konfigurasi penyedia lama».

Dengan sedikit usaha mental, kami akan mengidentifikasi prosedur dan fungsi yang diubah dua kali, hanya saja memerlukan modifikasi setelah proses penggabungan. Dengan prosedur dan fungsi ini, Anda perlu memutuskan mana yang lebih mudah:

• - mengambil prosedur atau fungsi dari konfigurasi pemasok baru dan kemudian, setelah penggabungan, melakukan modifikasi;
• - hapus tanda pembaruan, sehingga menyimpan peningkatan kami, dan baru kemudian menambahkan kode yang diperlukan dari konfigurasi penyedia.

Saya jarang menggunakan penggabungan dengan prioritas konfigurasi utama dan penggabungan dengan prioritas konfigurasi pemasok baru pada prinsipnya, bahkan tanpa menggunakan mode ini, hasilnya akan berkualitas tinggi;

Setelah modul umum dianalisis dan tanda pembaruan untuk beberapa prosedur dihapus, kita melihat bahwa modul sekarang disetel ke mode penggabungan - pengaturan individual:

Mari kita lanjutkan. Di antara objek yang dimodifikasi dua kali terdapat bentuk elemen direktori " Sarana Dasar" Sebelum memutuskan apakah akan memperbarui formulir ini dari konfigurasi vendor baru, Anda perlu mencari tahu apa yang sebenarnya berubah selama pembaruan.

Untuk melakukan ini di database basis dengan menggunakan menu konteks ayo telepon" Laporan Perbandingan Objek…” Semua bendera di grup “Objek” harus ada di jendela yang terbuka.

Saya suka mode keluaran laporan dokumen spreadsheet, ketika perbedaannya ditampilkan secara grafis, tapi ini masalah selera.

Sebagai hasil perbandingan bentuk elemen direktori " Sarana Dasar“Kami melihat yang ada perubahan hanya pada modul form saja, dan tidak ada perubahan pada dialog form pada update tersebut.

Tapi karena bentuk elemennya berakhir pada objek yang diubah dua kali, modifikasi kita ada di dialog formulir atau di modul.

Dengan melakukan perbandingan serupa di database untuk_memperbarui Anda dapat melihat bahwa ada perbaikan pada dialog formulir.

Alasannya adalah penambahan direktori " Sarana Dasar» ditinjau dari jenis karakteristiknya « Properti Objek" Jika Anda memperbarui bentuk item direktori " Sarana Dasar"kita akan mendapatkan tautan yang belum terselesaikan, yang akan ditunjukkan oleh jendela:

Dalam hal ini, pilihan terbaik adalah tidak memperbarui bentuk elemen direktori " Dasar dana"dan baru kemudian tambahkan kode yang diperlukan ke modul formulir elemen. Dalam hal ini, jendela Tautan yang belum terselesaikan"tidak akan muncul selama pembaruan.

Mari kita mundur selangkah dan bayangkan dialog elemen direktori terbentuk " Dasar dana" berubah saat memperbarui ke rilis baru, maka opsi terbaik adalah memperbarui formulir. Hanya kemudian, setelah penggabungan, kita perlu menambahkan perubahan kita ke formulir, baik di modul maupun di dialog. Jika suatu modul berisi banyak modifikasi kami dan sedikit dari pemasok, maka setelah penggabungan kami dapat mengembalikan modul kami sepenuhnya dan menambahkan perubahan dari pemasok.

Dalam hal ini, selama proses penggabungan, jendela “ Tag yang tidak dapat dipecahkan" Ada dua opsi di jendela ini: 1) “ Tandai semua untuk digabungkan"; 2) " Melanjutkan».

Menurut saya, lebih tepat memilih " Tandai semua untuk digabungkan».

Dalam hal ini, rencana tipe karakteristik " Properti Objek" akan ditambahkan sebagai objek untuk digabungkan pada pohon di jendela yang baru dibuka " Memperbarui…»

Tentu saja, setelah memperbarui tipe karakteristik ke dalam rencana, “ Properti Objek“Kami perlu menambahkan perubahan kami, menjadikannya lebih baik dengan membandingkan dan menggabungkan dengan konfigurasi saat ini.

Mari kita pertimbangkan apa yang akan terjadi jika kita memilih " Melanjutkan"di jendela" Tautan yang belum terselesaikan" Dalam hal ini, bentuk elemen direktori " Sarana Dasar"akan menjadi baru, dan rencana jenis karakteristiknya" Properti Objek"akan tetap tua. Dalam hal ini kita akan menimpa perubahan pada dialog form elemen direktori yaitu pada halaman “ PropertiNilai", lihat gambar di bawah.

Masalah ini juga bukannya tidak bisa diatasi, kecuali tentu saja kita melupakannya.

Tentu saja, yang terbaik adalah mencoba membuat perubahan sesedikit mungkin dialog bentuk , misalnya, membuat detail dan tombol pada formulir secara terprogram.

Banyak yang umumnya merekomendasikan untuk tidak mengubah bentuk standar, tetapi membuat salinannya dengan modifikasi kami dan menjadikannya yang utama. Saya tidak menyukai opsi ini karena jika pemasok menambahkan sesuatu ke dalam dialog formulir, itu tidak akan muncul di formulir saya dan saya harus menambahkannya secara manual, dan perubahan yang dilakukan pemasok mungkin jauh lebih banyak daripada perubahan kami.

Saya ingin memberikan perhatian khusus sesuai prosedur memperbarui formulir (saya mengambil beberapa prosedur dari konfigurasi pemasok, dan beberapa tidak - pengaturan individual). Mari kita lihat bagaimana dialog formulir diperbarui dalam mode ini, berbeda dengan "ambil dari konfigurasi vendor».

Contohnya tidak ada hubungannya dengan pembaruan ini konfigurasi, tetapi bersifat indikatif, jadi mari kita pertimbangkan.

Ke buku referensi" Pihak rekanan» beberapa detail telah ditambahkan dan ditempatkan pada formulir elemen.

Saat memperbarui konfigurasi ke rilis baru, dukungan akan menawarkan jendela untuk membandingkan dan menggabungkan konfigurasi, di mana Anda dapat membuat berbagai pengaturan. Mari kita bandingkan beberapa opsi:

1. Bendera pembaruan formulir disetel, tetapi pembaruan telah selesai secara prosedural , yaitu sebenarnya, pengaturan individual telah selesai

Banyak orang berpikir bahwa formulir dialog harus diambil dari konfigurasi vendor, dan prosedurnya tergantung pada pengaturan yang dibuat. Mari kita lihat bagaimana hal ini benar setelah penggabungan selesai. Mari kita bandingkan konfigurasi pemasok dengan konfigurasi utama.

Jelas sekali bahwa ikatan dan sebagainya pada formulir telah rusak, yaitu. Dialog formulir tidak sepenuhnya diambil dari konfigurasi penyedia. Dalam hal ini objek kita tetap berada pada dialog form, di satu sisi bagus, di sisi lain letak elemen kita pada form tidak selalu optimal, apalagi sehubungan dengan penambahan elemen pemasok baru, disana adalah perubahan posisi traversal dan pelanggaran ikatan. Dalam beberapa kasus, lebih mudah menambahkan elemen secara manual ke dialog formulir daripada melakukan koreksi.

2. Bendera pembaruan formulir disetel, pembaruan dilakukan di “ Ambil dari konfigurasi penyedia baru»

Dalam hal ini, dialog formulir elemen sepenuhnya disesuaikan dengan dialog formulir elemen pemasok.

Mari kita kembali ke pembaruan. Kami memperlakukan modul objek dan modul pengelola dokumen dengan cara yang sama seperti modul umum; kami memperbaruinya secara prosedural. Kami menangani formulir dokumen dengan cara yang sama seperti yang kami lakukan dengan formulir direktori.

Secara terpisah, perlu untuk menyoroti pekerjaan dengan peran. Terlepas dari kenyataan bahwa contoh tersebut tidak memerlukan pembaruan peran, ada baiknya membicarakannya. Mari kita pertimbangkan kasus paling sederhana, ketika konfigurasi pemasok berisi objek baru. Dalam hal ini, Anda perlu memperbarui peran "Hak penuh", tetapi peran ini mungkin berisi beberapa objek yang kami buat, misalnya direktori, dokumen, dll.

Tampaknya dengan peran " Hak penuh“Semuanya sederhana, kami menggabungkannya sepenuhnya, hak atas objek non-standar akan tetap dipertahankan di dalamnya. Benar sekali, hak atas benda nonstandar tidak akan pernah hilang, namun semua benda tersebut akan memiliki “ Penghapusan interaktif", yang tidak selalu baik. Saat membandingkan konfigurasi rilis lama dan rilis baru yang disiapkan, hal ini terlihat jelas:

Dengan peran lainnya, kami bertindak dengan cara yang sama seperti kami bekerja dengan modul - jika ada lebih banyak perubahan, maka kami tidak menggabungkan peran tersebut, setelah pembaruan kami menambahkan apa yang ditambahkan pemasok di rilis baru.

Setelah kami mengerjakan semua objek yang diubah dua kali di jendela pembaruan, klik “ Menjalankan»

Ketika ditanya apakah objek yang kami ubah akan dimuat dari konfigurasi baru, kami menjawab setuju.

Di jendela yang terbuka " Menyiapkan aturan dukungan"periksa apakah tandanya sudah disetel, meskipun secara default sudah disetel dengan benar, klik " OKE».

Di akhir proses penggabungan, kami menyimpan konfigurasi utama; kami belum memperbarui konfigurasi database.

Sekarang ke konfigurasiuntuk_memperbaruiKami menambahkan perbaikan minimal yang tidak dapat diperbarui dengan benar menggunakan alat standar.

Agar lebih mudah memantau pelaksanaannya proses ini, di basis data basis Mari kita mulai membandingkan konfigurasi vendor dan konfigurasi utama rilis lama.

Di basis data untuk_memperbarui kami akan melakukan hal yang sama. Kami mengontrol objek yang diubah dua kali, seharusnya tidak ada perbedaan.

Setelah pembaruan di databasefor_undatingakan selesai, kami memperbarui konfigurasi database dan menguji beberapa poin, apa sebenarnya yang baik untuk diuji akan menjadi jelas selama proses pembaruan, semuanya bersifat individual di sini.

Dianjurkan untuk memperbarui database yang berfungsi dengan bantuan dukungan"Konfigurasi" - "Dukungan" - "Perbarui konfigurasi".Dalam hal ini, objek yang diubah dua kali akan dimuat dari rilis baru, mis. perubahan kami akan ditimpa (kami tidak menyimpan konfigurasinya!), tetapi kemudian, jika digabungkan dengan konfigurasi yang telah disiapkan, kami memulihkannya. Setelah ini, Anda dapat menyimpan konfigurasi dan memperbarui konfigurasi database.