Düğüm yapılandırması beklendiği gibi değil. Veritabanında çalışan kullanıcı olmadığında bu adımların uygulanması tavsiye edilir.

• Mesaj dosyası alıcı veritabanına zaten yüklenmiştir. Kaynak veritabanından tekrar indirmeniz gerekiyor.

"FTP kaynağından dosya kopyalanırken hata oluştu... İnternet ile çalışırken hata: Zaman aşımına ulaşıldı" hatası

• Değişimin gerçekleştiği siteden gerekli dosyanın kopyalanması mümkün değildir. Bunun nedeni internetinizin yavaş olması veya sitenin kendisinde sorun olması olabilir.
• Değişimi 15-30 dakika sonra tekrarlamaya çalışmanız gerekir.

Hata: Bu döneme ait verilerin düzenlenmesi yasaktır. Değişiklikler kaydedilemiyor..."

• İndirilen veriler kapalı döneme ait belgeleri içerir.
• Bu süre içerisinde belge değiştirme hakkına sahip olan kullanıcılar altında değişimin yapılması gerekmektedir.

Hata: Veritabanı yapılandırma güncellemelerinin yapılması gerekiyor. Güncelleme yapılandırıcı modunda gerçekleştirilebilir"

Sebep: Programcılar merkezdeki konfigürasyonu değiştirdiler. Çözüm: Çevre birimi veritabanındaki değiştirilen yapılandırmayı güncelleyin. Bunun için:

• Yapılandırıcıya gidin.
• “Yapılandırıcı / Veritabanı yapılandırmasını güncelle” menü öğesini çalıştırın.
• Yalnızca "Tekrarla", "İptal", "Dinamik olarak güncelle" yanıtlarını içeren bir soru görüntüleniyorsa, "Dinamik olarak güncelle" düğmesini tıklayın.
• Yalnızca "Yeniden Dene" ve "İptal" yanıtlarını içeren bir soru belirirse.
  • tüm kullanıcılar 1C'den çıkış yapar.
  • “Tekrarla” düğmesine basın.
• Kalan soruları olumlu olarak yanıtlayın: “Evet”, “Kabul ediyorum”, “Tamam”.
• Yapılandırıcıyı kapatın.
• Merkezden yüklemeyi tekrarlayın.

Hata: "Yapılandırma beklenenle eşleşmiyor", "Bilinmeyen bir yapılandırmadaki değişiklikler kabul edilmeye çalışılıyor"

• Veri tabanı hatası.
• Uzmanlarla iletişime geçmek gerekir.

Değişim çok uzun sürüyor ve donuyor

Olası nedenler:

• Çok fazla veri geliyor.
  • Gönderenden, belgede grup değişikliği (gönderme, ayrıntıları değiştirme vb.) gerçekleştirip gerçekleştirmediğini öğrenin.
  • Eğer öyleyse, bilgisayarı gece boyunca değişimde bırakın.
• İnternetten büyük bir dosya indirilemez.
  • Dosya büyükse (80-100 MB veya daha fazla), o zaman 1C onu indiremeyebilir.
  • Dosyayı indirmeniz ve manuel olarak (muhtemelen uzmanların yardımıyla) 1C'ye yüklemeniz gerekir.
    • “İşlemler” menü öğesi / Değişim planları / Tam / “Mesajı oku” panelindeki düğme.
• Veritabanı zarar görmüş:
  • Dene
• Bu adımlar yardımcı olmazsa uzmanlarla iletişime geçmeniz gerekecektir.

• Hata düzeltilemezse +7 (8512) 64-55-05 acil destek numarasını arayın.
• Hangi şehirde olursanız olun uzmanımız size yardımcı olacaktır.

Dağıtılmış bir bilgi tabanı (DIB), şubelerin ve bölümlerin çalışmalarını organize etmek için sıklıkla kullanılır ve gerekli özerklik derecesini korurken hızlı bilgi alışverişine olanak tanır. Bu teknoloji oldukça güvenilir olmasına rağmen zaman zaman bozuluyor. Bugün oldukça yaygın olan hatalardan birine bakacağız: Size bunun oluşma nedenlerini ve bununla baş etme yöntemlerini anlatacağız.

Her zaman olduğu gibi en baştan başlayalım. RIB'yi oluşturduktan sonra bilgi tabanı yapılandırmasındaki tüm değişiklikler yalnızca ana düğümde yapılabilir. Daha sonra, bir sonraki değişim sırasında tüm değişiklikler yardımcı düğümlere aktarılacak ve orada otomatik olarak uygulanacaktır. Ama kağıt üzerinde pürüzsüzdü...

Pratikte bazen değişim oturumları arasında, özellikle de çevredeki kanal kötüyse, ana düğümün konfigürasyonunun iki kez değişmeyi başardığı görülür. Örneğin, değişiklikler yaptılar, yüklediler, çevresel veritabanı değişiklikleri aldı ancak henüz uygulamadı, bu biraz zaman alabilir ve henüz onay göndermedi. Bu süre zarfında tekrar değişiklik yapıp santrali tekrar yüklerseniz, merkezin çevresel düğümde 1 numaralı konfigürasyonu görmeyi beklediği ve onu 3 numaralı konfigürasyona güncellemeye çalışacağı, ancak aslında 1 numaralı konfigürasyonla karşılaşacağı ortaya çıkıyor. 2 orada. Bazen merkezi veritabanının dinamik güncellenmesi sırasında da benzer bir durum ortaya çıkar. Sonuç olarak, değişim imkansız hale gelecek ve şunu belirten bir mesaj alacaksınız: Dağıtılmış bilgi güvenliği düğümünün yapılandırması beklenenle eşleşmiyor!

Genel olarak, bu hikayenin ana fikri basittir; çalışan veritabanını aktif olarak iyileştirmeyin ve bunu yaparsanız, sonraki değişiklikleri yapmadan önce tüm değişim oturumlarını tamamlayın. Peki ya böyle bir sıkıntı olursa?

Basit çözüm, köle düğümün yeni bir görüntüsünü oluşturmaktır, ancak pratikte bu genellikle uygulanamaz. Kural olarak, değişim sırasında meydana gelen ciddi bir hata hemen tespit edilmez, ancak çevresel veritabanlarından operasyonel verilerin gelmesi durduktan bir süre sonra tespit edilir. İletişim planına bağlı olarak, sorunun ortaya çıkması ile tespit edilmesi arasında tam bir iş günü veya daha uzun bir süre geçebilir.

Burada bunu bir hata olarak bildiren ve durumu aynı şekilde kırmızıyla vurgulayan geliştiricilere taş atmaya değer. Mesaj numarası daha önce alınan mesajın numarasına eşit veya ondan küçük Bu genellikle oldukça normaldir. Sonuç olarak, kullanıcıların hata algısı körelir ve her şeyin yolunda olduğuna ve karşı tarafın henüz alışverişi yapmadığına inanarak görüntülenen mesajları okumayı bırakırlar.

Ama hatamıza dönelim. Çözüm oldukça basit ve yüzeyde yatıyor: çevresel tabanın konfigürasyonunu beklenene getirin, yani. merkezi düğümün konfigürasyonuna uygun hale getirin. Ancak pratikte bu o kadar kolay değil. Yapılandırıcıda çevre veri tabanını açarsak değişikliklerin RIB yönetim araçları tarafından engellendiğini göreceğiz.

Bir yardımcı düğümün konfigürasyonunu değiştirmek için, merkezi tabanla olan bağlantısını geçici olarak kesmeniz gerekecektir. Bu amaçlar için ağda bol miktarda bulunan işleme seçeneklerinden birini kullanabilir veya bilgi güvenliğini merkezi düğümden ayırabilirsiniz. Yapılandırıcı başlatma parametresini kullanma/ResetMasterNode.

Bir komut istemi açın ve şunu girin (platform sürümünü ve gerçek kurulum yolunu dikkate alarak):

"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" yapılandırma /ResetMasterNode

Bu komutu yürüttükten sonra, normal başlangıç ​​\u200b\u200bpenceresi görünecektir, orada istediğiniz tabanı seçin ve düğmeye tıklayın. Yapılandırıcı.

Bilgi güvenliğini aynı anda başlatıyoruz gerçekleşmeyecek yani hiçbir şey olmamış gibi görünebilir, ancak veritabanını Yapılandırıcıda tekrar açarak ana düğümle bağlantısının kesildiğinden ve değişiklik yapmaya hazır olduğundan emin olabilirsiniz.

Dikkat! 8.3.7 - 8.3.9 platformlarında bu komutun yürütülmesi çökmeye neden olur. Hata platform 8.3.10'da düzeltildi.

Komut satırıyla uğraşmak istemiyorsanız, tedavilerden birini kullanabilirsiniz; aşağıda bizim kullandığımız tedavi var; internette bulundu ve üzerinde sadece kozmetik değişiklikler yaptık. İşlemenin yalnızca normal bir uygulama için uygun olduğunu lütfen unutmayın; yönetilen bir uygulamadaki yapılandırmalar için Yapılandırıcı başlatma anahtarını kullanın.

Onunla çalışmak son derece basittir; 1C:Enterprise modunda başlatıyoruz. Dosya - Aç, ardından bizim durumumuzda istediğiniz düğmeye basmanız yeterlidir Ana düğümü devre dışı bırak.

Şimdi merkezi düğümden gelen en son konfigürasyona ihtiyacımız var. Bunun için açacağız merkezi bilgi güvenliği Yapılandırıcıda ve yürütün Yapılandırma - Yapılandırmayı dosyaya kaydet. Uzantılı olarak ortaya çıkan dosya bkz.çevresel bir düğüme gönderilmesi gerekecektir.

Daha sonra çevresel düğümde, Yapılandırıcıda bilgi güvenliğini (daha önce ana düğümle bağlantısını kestikten sonra) başlatıyoruz ve destekten kaldırıyoruz. Bunu yapmak için şunu seçin: Yapılandırma - Destek - Destek Kurulumu.

Açılan pencerede öncelikle düzenleme seçeneklerini etkinleştirin.

Daha sonra yapılandırmayı destekten kaldırıyoruz.

Artık konfigürasyonu bir dosyadan yükleyebilirsiniz; bunu yapmak için Yapılandırma - Yapılandırmayı dosyadan yükle ve merkezi düğümden iletilmediğini belirtin bkz.-dosya. Bundan sonra mevcut konfigürasyonun boş olmadığına dair bir uyarı alacaksınız. Yaptığımız manipülasyonların potansiyel olarak tehlikeli olduğunu ve bilgi güvenliğine geri dönülemez zararlar verebileceğini lütfen unutmayın; bu nedenle devam etmeden önce güncel bir yedek kopyaya sahip olduğunuzdan emin olun.

İlk olarak, kullanılan kısaltmaların bir listesi:

• RIB - dağıtılmış bilgi tabanı
• CB - merkezi taban, RIB'in kök düğümü
• UB - uzak taban, uzak bir RIB düğümünün veritabanı

Kendi tecrübelerime dayanarak hatanın iki nedeni ile karşılaştığımı söyleyebilirim:

• Mesaj dosyasını alırken veritabanı yönetim sistemine "düştü" ve bu nedenle görünüşe göre conf arasında bir senkronizasyon bozukluğu vardı. Merkez Bankası ve UB;
• MSSQL altında istemci, çalışan veritabanının bir kopyasını indirdi ve kaydı kapatmadı. otomatik değişim görevleri, bunun sonucunda uzak düğümlere gönderilen bazı mesajlar çalışma veritabanından, bazıları ise bir kopyadan oluşturuldu ve bu da yapılandırmaların senkronizasyonunun bozulmasına yol açtı

Bu hatanın dinamik bir veritabanı güncelleme mekanizmasının kullanılmasından kaynaklandığına dair bir görüş de var. Burada şüpheler var, çünkü bir yandan dinamik güncelleme hiçbir zaman veritabanı yapısını etkilemez ve RIB mekanizmaları uygulanan kısmıyla değil veritabanı yapısıyla çalışmaya devam eder; yine de RIB, veri tabanının dijital imzasını oluşturmak için bir mekanizma kullanır. konfigürasyon sürümü (gelecekte buna kısaca karma diyeceğim) ve uygulama kısmı değiştiğinde, karmanın doğal olarak yeniden hesaplanması gerekir. Bunu ne inkar edeceğim ne de onaylayacağım çünkü... Bu durumla karşılaştıysam buna dair net bir kanıt bulamadım.

Düzeltmek için duruma göre 2 yöntem kullanıyorum.

İLK TEKNİK

İlki (en yaygın olanı) hem ortak konferansında hem de 1C ile ilgili diğer İnternet kaynaklarında defalarca bahsedilmektedir. Çoğu durumda, konfigürasyonlardaki farklılıklar hakkındaki mesaja rağmen, manuel karşılaştırmanın bunların aynı olduğunu gösterdiği durumlarda kullanılır.

Sıralama:

1. CF dosyasını merkez bankasından boşaltın;
2. UB'nin RIB ile olan bağlantısını kaldırıyoruz (Set MainNode yöntemi, hazır işleme uygulamada veya diğer yayınlarda bulunabilir);
3. conf'un değiştirilmesi İlk adımda yüklenen cf dosyasına UB, bunun için “Yapılandırmayı dosyadan yükle” menüsünü kullanıyoruz (ve karşılaştırma-birleştirme değil!!!);
4. UX için RIB işaretini geri yükleyelim.

Çoğu durumda, bu eylemler değişimi yeniden sağlamak için fazlasıyla yeterlidir, ancak her zaman değil...

İKİNCİ YÖNTEM

İlk yöntem işe yaramadıysa ve düğümün tekrar boşaltılması mümkün değilse kullanılır.

Arka plan: istemci bir kademeli RIB kuruyordu ve kademenin ilk seviyesinde bir hata oluştu (ikinci seviye tüm bu süre boyunca kusursuz çalıştı). Yapılandırma müşterinin BT hizmetiyle ortaklaşa geliştirildi ve hatanın oluşmasından bu yana merkez bankasının yapılandırması birkaç kez değişti. Değişiklikleri geri alma seçeneği prensipte bile dikkate alınmadı çünkü bazı verilerin kaybı ve birkaç departmanın kapatılması kesinlikle kabul edilemezdi. Hatayı düzeltmek için ilk seçenek herhangi bir somut sonuç vermedi. Bu nedenle başka çözümler aramak zorunda kaldık.

Fikir, yapılandırma dosyalarının karmalarını doğrudan XML değişim dosyalarında değiştirmeyi denemek için geldi. Değişim dosyasının yapısının “1C: Enterprise 8 sisteminde mesleki gelişim” kitabındaki açıklaması, konfigürasyonların dijital imzalarının oluşumu ve bunlardaki değişiklikler hakkında zayıf bir fikir verdi, ancak yönünü belirledi. arama: Digest1 ve Digest2 değerleri. Geriye kalan her şeyi tamamen ampirik olarak (yani deneme yanılma yoluyla) çözdüm, ancak bir model oluşturmak mümkündü.

Test denemeleri başarılıydı. Çalışma üslerinde de her şey yolunda gitti.

Yani, eylem sırası:

1. ilk yöntemin 1 - 4 arasındaki adımlarını gerçekleştirin;
2. Takas dosyasını UB'den kaldırıyoruz ancak Merkez Bankası'na yüklemiyoruz;
3. Takas dosyasını Merkez Bankasından kaldırıyoruz ancak UB'ye yüklemiyoruz;
4. Merkez Bankası'ndan gelen değişim dosyasında, konfigürasyon değişiklikleri ve hash'ler hakkındaki bilgileri içeren bloğu (Digest1 ve Digest2) UB dosyasındaki bir hash bloğu ile değiştiriyoruz (aşağıdaki örneğe bakın)
5. 4. noktadan itibaren dosyayı UB'ye yüklüyoruz;
6. UB'den gelen değişim dosyasının üzerine yazdığınızdan emin olun (2. nokta)! Merkez Bankası ile alışveriş yaparken bu dosya indirilmemelidir!
7. Kontrol etmek için ardı ardına birkaç değişim yapıyoruz.

Değişim sırasında veri sıkıştırması kullanılıyorsa, ya sıkıştırmayı devre dışı bırakırız ya da önce dosyayı paketinden çıkarırız, değiştiririz, sonra geri paketleyip göndeririz.

Merkez Bankası'ndan döviz dosyası blokesi

106.0
...işte konfigürasyon değişikliklerini açıklayan bloklar...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

UB'den gelen değişim dosyası bloğuyla değiştirilmesi gerekiyor (UB'den gelen bir dosya için Digest1'in her zaman "000000000000000000000000000000000" değerine eşit olduğunu unutmayın!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Listelenen eylemler çok dikkatli bir şekilde gerçekleştirilmelidir; yanlış bir sıralama, RIB'nin tamamen çalışmaz hale gelmesine neden olabilir. Bu nedenle bu işlemlerden önce yedek kopyaların oluşturulması ZORUNLUDUR!

Dinamik güncelleme hataları (veya diğer platform aksaklıkları), dağıtılmış bilgi tabanı değişim hatalarının nedeni olabilir:

• "Veriler, konfigürasyon değişikliklerinin kaydedildiği düğümden alındı"
  

• "Dağıtılmış bilgi güvenliği düğümünün yapılandırması beklenenle eşleşmiyor"
  

Değişim nasıl geri yüklenir?

Ama restorasyonla değil, gerçekleştirme fırsatıyla başlayalımgün içinde önemli olan "manuel" değişim, çünkü her zaman olduğu gibi her şey "dün" çalışmalı :) Bu, hatırlamadığım harika tedavilerin yardımıyla yapılabilir.indirdiğim yerde çıplak (yazarlar, lütfen yanıt verin - kaynağınıza bağlantılar bırakacağım ve gerekirse onu benimkinden sileceğim)). İşleme, yapılandırma değişikliklerini indirmeden yalnızca veritabanındaki kayıtlı veri değişikliklerini (belirli bir düğüm için belirtilen değişim planına göre!) XML olarak indirmeyi mümkün kılar ve eğer yapılandırma nesneleri çok fazla değişmediyse, o zaman çok yüksek bir şans vardır. Bu verileri yüklemek için. Bunları makalenin sonundaki bağlantıdan indirebilirsiniz.

İyileşmeye gelince. Aşağıdaki listedeki tüm öğeleri içermeyen daha basit yöntemler vardır, ancak benim vakalarımdan birinde olduğu gibi bunlar her zaman yardımcı olmaz. Bu nedenle bana yardımcı olan yöntemi sunuyorum; olası sorunları daha kapsamlı bir şekilde atlıyor. Sonraki adım adım.

Veritabanında çalışan kullanıcı olmadığında bu adımların uygulanması tavsiye edilir. Bu mümkün değilse, yöntemi kendiniz "bitirmeniz" gerekecektir ve bu nedenle önce mantığını anlamalısınız.

1. Her yerde yedekleme yapın.

2. İstemci-sunucuları için: "sunucu yönetimi" yoluyla veritabanlarını devre dışı bırakın ve bunları hemen zamanlanmış görevlerin engellenmesiyle bağlayın (bu, sunucu önbelleğini sıfırlayacaktır). Bundan sonra kayıt günlüğünü yeni dizine aktarmayı unutmayın.

3. Kurtarma için kullanılan tüm bilgisayarlarda, 1C başlatıcı veritabanları listesindeki veritabanını silin ve yeni bir tane oluşturun (kullanıcı önbelleği temizlenecektir)

4. Yapılandırıcıda (merkezi veritabanında), yeni bir sabit ekleyin ve yapılandırma değişikliklerini kaydedin.

5. Tüm değişim dizinlerini temizleyin.

6. Tüm şubelere boşaltma yapın (şimdilik sadece boşaltmalar).

7. Alınan verileri tüm şubelere indirmeyi (sadece indirmeyi) deneyin. Conf değişikliklerini kabul etmek doğaldır.

Her şey her yerde iyiyse yolumuza devam ediyoruz, eğer her şey kötüyse merkezi veri tabanından .cf dosyasını indirip şubeye YÜKLEMENİN (karşılaştırma-birleştirme değil) faydalı olabileceğini düşünüyoruz. Köle düğümde, veritabanının RIB ile olan bağlantısını kaldırmalısınız (işleme bu konuda yardımcı olacaktır - aşağıdaki bağlantıdan indirin). Infostart.ru'da bu konuyla ilgili bir makale var.

8. Merkez Bankası'ndaki şubelerdeki değişikliklerin kaydını iptal ediyoruz (sonuçta tüm değişiklikleri zaten her yere aldık). Farklı şubelerden biriken değişikliklerin diğer şubelere ulaşması için bu aşamada yapılması önemlidir. (bağlamayı kaldırma-bağlama işlemini aşağıdaki bağlantıdan indirin).

9. Merkez Bankası'na yükleme yapıyoruz ve eğer her şey yolundaysa, sonucu pekiştirmek için her şubeye birkaç kez yükleme ve boşaltma yapıyoruz.

10. İşte bu.

İstemci-sunucu veritabanları için rutin görevlerin yürütülmesini etkinleştirebilirsiniz.

Bu hataya neden olan sorunları önlemek için, dinamik güncellemelerin yapılmaması (en azından arka arkaya birkaç kez - değişiklikler şubelere yüklenene kadar) ve ayrıca "verileri yalnızca başarılı yükleme sonrasında yükle" kutusunun işaretlenmesi önerilir. değişim ayarlarında.

Merhaba, blog sitemizin sevgili okuyucuları! Bugün bunun hakkında konuşacağız
iki hatayı düzeltme dağıtılmış bir bilgi tabanında (RIB) alışveriş sırasında ortaya çıkabilecek. Veritabanınızın konfigürasyonunu değiştirdiyseniz ve bu değişiklikleri merkezi veritabanından çevresel veritabanına aktarmaya çalıştığınızda bu tür hatalar ortaya çıkabilir. Mesela anlatıldığı şekilde. Başlayalım!

RIB kullanarak takas yapmaya çalıştığınızda görünebilecek mesajlar şunlardır:

"Veri, ilgili düğümden alınır
yapılandırma değişiklikleri günlüğe kaydedildi.
Değişikliklerin aktarılması gerekiyor
düğüme yapılandırmalar."


“Dağıtılmış bilgi güvenliği düğümü yapılandırması
beklenildiği gibi değil!"

Durumu düzeltmeye yardımcı olacak adımlara bakalım. Başlamadan önce bilgi veritabanımızı oluşturalım!!!

1. Güncelleme ile birlikte konfigürasyon dosyasını alalım, Konfigüratörde merkezi veri tabanını açıp yükleyelim (Konfigürasyon-Konfigürasyonu dosyadan yükle...). Bilgi güvenliğini kaydedelim (F7).
2. Çevresel veritabanına gidip bir dosyaya yükleyelim:
   
   
   • Listeden değişim planını seçin, ardından içerik menüsünü açmak için sağ tıklayın ve "Değişiklikleri kaydet..." seçeneğini seçin.
3. Şimdi çevresel bilgi güvenliğiyle ilgilenelim. Kullanıcı kalmaması için özel modda açalım ve Yapılandırıcıyı da kapatalım. Şimdi mevcut veritabanı için ana düğüm olan düğümü hatırlamanız gerekiyor. Açık Operasyonlar-Değişim Planları-Değişim planınızı seçin (örneğin, “Depoya göre”). Değişim planları listesinde ana düğüm sarı simgeli öğedir. Bu bilgi yedinci noktada işimize yarayacaktır. İşlemeyi açalım ve “Ana düğüm atamasını iptal et” butonuna tıklayalım.
4. Şimdi Konfigüratörde çevre bilgi güvenliğini açalım ve ilk adımda yüklediğimiz konfigürasyon dosyasının aynısını merkezi veri tabanına yükleyelim (Konfigürasyon-Konfigürasyonu dosyadan yükle...). Bilgi güvenliğini kaydedelim (F7).
5. Destek ayarlarını değiştirelim (Yapılandırma-Destek-Destek Ayarları...). İletişim kutusunda, tabloda birinci satır ile ikinci sütunun kesişimindeki hücreyi seçin. Ardından “Destek Kuralları Ayarları” iletişim kutusunu açmak için çift tıklayın. İçinde “Alt nesneler için yükle” bayrağını işaretleyin ve “Tamam” düğmesini tıklayın. “Kapat” düğmesine tıklayarak destek ayarları iletişim kutusunu kapatın. IB'yi (F7) kaydedin. Konfigüratörü kapatalım.
6. Şimdi çevresel bilgi güvenliğini 1C:Enterprise özel modunda tekrar açalım, böylece kullanıcı kalmasın ve ayrıca Yapılandırıcıyı kapatalım. MainNodeDB.epf dosyasının kurulumunu açalım ve ana düğüm olarak kurmak istediğimiz exchange planını seçelim (dördüncü paragrafta bu düğümü hatırladık). Daha sonra “Ana Düğümü Yükle” butonuna tıklayın. Bundan sonra mevcut bilgi güvenliği yeniden periferik hale gelecektir.
7. Şimdi mevcut bilgi güvenliğinde (çevresel) değişim planlarını açacağız ve üçüncü adımda aldığımız santral veri tabanından değişimin bulunduğu dosyayı indireceğiz:
   
   
   • Operasyonlar-Değişim Planları-Değişim planımızı seçin (örneğin, “Depoya göre”).
8. Her şey yolunda giderse, mevcut bilgi güvenliğine (çevre birimi) Merkezi veritabanı değişimini yükleyeceğiz:
   
   
   • Operasyonlar-Değişim Planları-Değişim planımızı seçin (örneğin, “Depoya göre”).
   • Listeden değişim planını seçin, ardından içerik menüsünü açmak için sağ tıklayın ve "Değişiklikleri kaydet..." seçeneğini seçin.
   • İletişim kutusunda, değişim dosyasının yolunu ve adını belirtin. “Tamam” düğmesine tıklayın.
9. Şimdi bu dosyayı Merkezi Veritabanına yükleyip 1C:Enterprise modunda açmayı deneyelim:
   
   
   • Operasyonlar-Değişim Planları-Değişim planımızı seçin (örneğin, “Depoya göre”).
   • Listeden değişim planını seçin - Bağlam menüsünü çağırmak için sağ tıklayın ve "Değişiklikleri oku..." seçeneğini seçin.
   • İletişim kutusunda değişim dosyasını seçin. “Tamam” düğmesine tıklayın.

Çalışma kopyalarıyla ilgili sorunlardan kaçınmak için öncelikle şunları yapın: