Özel yapılandırma güncellemesi. Tipik konfigürasyonların doğru şekilde tamamlanması Yüklenen konfigürasyon, ana konfigürasyonun devamıdır.

1.3.61.2 sürümünden 1.3.62.1 sürümüne geçme olasılığı ile destek altında olan standart olmayan bir SCP 1.3 yapılandırması örneğini kullanarak bir güncellemeyi ele alalım. Konfigürasyonun kendisi oldukça ağır olduğu için, bu bazı özellikler gerektirir, özellikle bir konfigüratörde birkaç konfigürasyon karşılaştırma penceresi açmak her zaman mümkün değildir.

Yükseltme için eski sürüm veritabanının iki özdeş kopyasını kullanıyorum. Bir tanesinde hazırlanıyorum *.cf güncellemek için, diyelim ki, örneğin, için_güncelleme. Diğer taban dokunulmadan kalır ve konfigürasyonları karşılaştırmak için sadece yardımcı bir taban olarak hizmet eder, hadi diyelim temel. Prensip olarak, çalışma tabanının konfigürasyonu yardımcı bir yapı olarak kullanılabilir.

tabanda for_updating rol yapmak *.cfu Yeni sürüm. Güncelleme prosedürü başlar ve güncelleme penceresi görünür.

Düğmesine basın " Çalıştırmak”, bu aşamada henüz hiçbir şeye bakmaya gerek yok, çünkü amaç yalnızca yeni sürüm satıcısının yapılandırmasını almak.

Güncelleme sırasında bir pencere görünebilir Çözümlenemeyen bağlantılar", basmak" Devam et". Aşağıda bu pencerenin ortaya çıkmasının nedenleri hakkında konuşacağız.

Değiştirdiğimiz nesnelerin yeni konfigürasyondan yükleneceğini belirten bir mesaj görünecektir, kabul ediyoruz.

Pencere " Destek kurallarını ayarlama" - her iki tarafa yeni nesneler (üst bölüm) için koyduğumuz " Destek korunurken nesne düzenlenir”, mevcut tedarikçi nesneleri için (alt bölüm) dört yerde de bayrağını koyduk” Mevcut modu kaydet", basmak" tamam».

Ana yapılandırma güncellendi. Bu aşamada tek başına ana konfigürasyona ihtiyacımız yoktur, amaç yeni bir tedarikçi konfigürasyonu elde etmektir. Bu nedenle ana konfigürasyonu kaydetmiyoruz, veritabanı konfigürasyonunu güncellemiyoruz.

yürütüyoruz" Yapılandırma» - « Destek» - « Özelleştirmeyi Destekleyin". Açılan pencerede " Dosyaya kaydet» ve kaydet *.cf yeni sürüm satıcı yapılandırması.

Şu anda mevcut olduğu biçimde ana yapılandırmaya ihtiyacımız yok. Yapılandırmayı kapatıyoruz. " Yapılandırma» - « Yapılandırmayı kapat". Değişiklikleri kaydetmeyi reddediyoruz.

Karşılaştırma için yapılandırmada temel bir dosyadan (yeni sürüm) satıcı yapılandırması (eski sürüm) ve satıcı yapılandırması karşılaştırmasını çalıştırın.

Bu nedenle, yalnızca yeni bir sürüme güncelleme yaparken yapılandırmada yapılacak değişiklikleri göreceğiz.

tabanda for_updating destek aracılığıyla yapılandırma güncellemesini tekrar çalıştırın "Yapılandırma" - "Destek" - "Yapılandırmayı güncelle", açılan pencerede öğesini seçin. *.cfu Yeni sürüm. Güncelleme prosedürü başlar ve güncelleme penceresi görünür.

" düğmesine basarak filtre» penceresi açılacak « Görünüm Filtrelerini Ayarlama". Bu pencerede bayrağı ayarlayın " Yalnızca iki kez değişen özellikleri göster».

Müdahalemiz olmadan güncelleme yaparken aşağıdakiler olur:

- nesne tarafımızca değiştirilmemiştir, yeni sürümde değiştirilmiştir - yeni sürümden güncellenmiştir;
- nesne bizim tarafımızdan değiştirilir, yeni sürümde değiştirilmez - nesnemiz kalır;
- nesne tarafımızca değiştirilir, yeni sürümde değiştirilir - bu iki kez değiştirilen nesnedir, eğer hiçbir şey değişmezse - yeni sürümden yüklenir.

Bu nedenle, iki kez değiştirilen nesnelere en yakın dikkat gösterilmelidir ve bunları dikkate alacağız.

Bu örnekte, ortak modül " dahil olmak üzere birkaç ortak modül değiştirilmiştir.KDV muhasebesi».

Varsayılan olarak güncelleme penceresi, ana ve yeni sağlayıcı yapılandırması ile eski sağlayıcı yapılandırması arasındaki farkları gösterir.

Ortak modüldeki yapılandırma farklılıklarına bakarsanız " KDV muhasebesi”, o zaman aşağıdaki resmi göreceğiz:

Karşılaştırma için bu modülleri veritabanında karşılaştırırsaktemel, o zaman resim farklı olacaktır:

Açıkçası, işlevler CollectDataForPrintDüzeltmeFaturalarFaturalar», « DataToPrintAyarlama Faturasını ToplaFatura” ve diğerleri iyileştirmelerimizi içerir, ancak güncelleme sırasında değişmez, bu da onları incelemek ve analiz etmek için zaman kaybetmenin bir anlamı olmadığı anlamına gelir.

Bu nedenle, seçilen prosedürlerden ve işlevlerden prosedürel bir güncelleme gerçekleştirerek bayrakları kaldırabilirsiniz:

Birçoğu, veritabanındaki konfigürasyonların karşılaştırmasını kullanmadan, mevcut konfigüratördeki görünüm filtreleri ayarlarını değiştirerek eski satıcı konfigürasyonu ile yenisi arasındaki farkları görebileceğinizi söyleyecektir.temel.

Örneğin, bunun gibi:

Ancak, pratik deneyimin gösterdiği gibi, durum böyle değil, prosedürler ve işlevler, filtreyle bile modül karşılaştırma penceresinde görüntüleniyor " yeni satıcı yapılandırması ile eski satıcı yapılandırması arasındaki farkları göster».

Büyük bir zihinsel çaba göstermeden, iki kez değiştirilen prosedürleri ve işlevleri ortaya çıkaracağız, sadece birleştirme işleminden sonra iyileştirilmesi gerekecek. Bu prosedürler ve işlevlerle hangisinin daha kolay olduğuna karar vermeniz gerekir:

- ya yeni bir tedarikçi konfigürasyonundan bir prosedür ya da işlev alın ve birleştirmeden sonra iyileştirmelerimizi yapın;
- ya güncelleme bayrağını kaldırın, böylece iyileştirmelerimizi kaydedin ve ancak bundan sonra satıcının konfigürasyonundan gerekli kodu ekleyin.

Ana konfigürasyonun önceliği ile birleştirmek ve nadiren kullandığım tedarikçinin yeni konfigürasyonunun önceliği ile birleştirmek, prensipte, bu modları kullanmadan bile, sonuç yüksek kalitede olacaktır.

Ortak modüller analiz edildikten ve bazı prosedürler için güncelleme bayrakları temizlendikten sonra, modüllerin artık birleştirme modu setine sahip olduğunu görüyoruz - bireysel bir ayar:

Devam ediyoruz. İki kez değiştirilen nesneler arasında, "referans öğesinin bir formu var. Temel Araçlar". Belirli bir formu yeni bir sağlayıcı yapılandırmasından güncelleyip güncellemeyeceğinize karar vermeden önce, güncelleme yaptığınızda gerçekte nelerin değiştiğini bulmanız gerekir.

Bunun için veritabanında temel bağlam menüsünü kullanarak " Nesne karşılaştırma raporu…”. Açılan pencerede "Objects" grubundaki tüm flaglar olmalıdır.

Farklılıklar grafiksel olarak gösterildiğinde, bir elektronik tablo belgesindeki rapor çıktı modunu seviyorum, ancak bu bir zevk meselesi.

Referans elemanının formunu karşılaştırmanın bir sonucu olarak " Temel Araçlar» sadece form modülünde değişiklik olduğunu ve güncellemede form iletişim kutusunda herhangi bir değişiklik olmadığını görüyoruz.

Ancak öğenin formu iki kez değiştirilmiş nesnelere girdiğinden, iyileştirmelerimiz form iletişim kutusunda veya modüldedir.

Veritabanında benzer bir karşılaştırma yapmak for_updating form iletişim kutusunda iyileştirmeler olduğunu görebilirsiniz.

Bunun nedeni, dizinin eklenmesidir " Temel Araçlar» özellik türlerinin planına « ÖzelliklerNesneler". Referans öğesinin formunu güncellerseniz " Temel Araçlar"Pencerenin gösterdiği gibi, çözülemeyen bağlantılar alacağız:

Bu durumda, en iyi seçenek, referans öğesinin biçimini güncellememek olacaktır " Ana tesisler” ve ancak o zaman gerekli kodu eleman form modülüne ekleyin. Bu durumda, pencere Çözümlenemeyen bağlantılar” güncelleme sırasında görünmeyecektir.

Bir arasöz yapalım ve dizinin form öğesinin diyaloğunun " Ana tesisler' yeni bir sürüme güncellerken değişirse, en iyi seçenek formu güncellemek olacaktır. Daha sonra birleştirmeden sonra, hem modülde hem de iletişim kutusunda değişikliklerimizi forma eklememiz gerekecek. Modülde çok fazla iyileştirmemiz ve tedarikçiden çok az şey varsa, birleşmeden sonra modülümüzü tamamen iade edebilir ve tedarikçiye değişiklikler ekleyebilirsiniz.

Bu durumda, birleştirme işlemi sırasında “ çözülemez etiketler". Bu pencerede iki seçenek vardır: 1) " Birleştirme için Tümünü İşaretle"; 2)" Devam et».

Bence tercih et daha iyi Tümünü birleştirme için işaretle».

Bu durumda, özellik türlerinin planı " ÖzelliklerNesneler” Yeni açılan pencerede ağaçta birleştirilecek bir nesne olarak eklenecektir” Güncelleme…»

Doğal olarak, özellik türlerinin planını güncelledikten sonra " ÖzelliklerNesneler» değişikliklerimizi eklememiz, mevcut konfigürasyonla karşılaştırarak ve birleştirerek daha iyi hale getirmemiz gerekecek.

Seçersek ne olacağını bir düşün" Devam et" pencerede " Çözümlenemeyen bağlantılar". Bu durumda, referans elemanının şekli " Temel Araçlar” yeni olacak ve özellik türlerinin planı” ÖzelliklerNesneler' eski kalırdı. Bu durumda, referans öğesinin form iletişim kutusundaki, yani sayfadaki değişikliklerin üzerine yazacağız " ÖzelliklerFDeğerler”, aşağıdaki şekle bakın.

Bu sorun da, tabii ki unutmadıkça aşılmaz değildir.

Elbette, mümkün olduğunca az değişiklik yapmaya çalışmak en iyisidir. form diyalogları örneğin, formda programlı olarak ayrıntılar ve düğmeler oluşturmak için.

Birçoğu genellikle standart formları değiştirmemeyi, ancak bizim değişikliklerimizle kopyalarını oluşturmayı ve onları ana form haline getirmeyi önerir. Bu seçeneği sevmiyorum çünkü tedarikçi form iletişim kutusuna bir şey eklediyse, formumda görünmeyecek ve manuel olarak eklemeler yapmak zorunda kalacağım ve bizimkinden çok daha fazla tedarikçi değişikliği olabilir.

özellikle dikkat etmek istiyorum prosedüre göre formları güncelleme (prosedürlerden bazılarını tedarikçinin yapılandırmasından alıyorum ve bazıları değil - bireysel ayarlar). Bu modda, form iletişim kutusunun modun aksine nasıl güncellendiğini düşünelim "satıcı yapılandırmasından al».

Örnek, bu yapılandırma güncellemesiyle ilgili değil, ancak gösterge niteliğindedir, o yüzden ona bakalım.

El kitabında " karşı taraflar» bir kaç props eklenir ve elementin formuna yerleştirilir.

Destek aracılığıyla bir yapılandırmayı yeni bir sürüme güncellerken, çeşitli ayarları yapabileceğiniz bir karşılaştırma ve birleştirme yapılandırma penceresi sunulacaktır. Birkaç seçeneği karşılaştıralım:

1. Form güncelleme bayrağı ayarlandı, ancak güncelleme tamamlandı prosedüre göre , yani aslında, özelleştirme yapılır

Birçok kişi, form iletişim kutusunun sağlayıcının yapılandırmasından ve yapılan ayarlara bağlı olarak prosedürlerden alınması gerektiğini düşünüyor. Bakalım sendikadan sonra nasıl olacak. Satıcı yapılandırmasını ana yapılandırmayla karşılaştıralım.

Formlarda cilt vb.nin bozuk olduğu aşikardır. form iletişim kutusu, sağlayıcının yapılandırmasından tamamen alınmadı. Bu durumda, nesnelerimiz form iletişim kutusunda kaldı, bir yandan bu iyi, diğer yandan öğelerimizin formdaki konumu, özellikle yeni tedarikçi öğelerin eklenmesiyle bağlantılı olarak her zaman optimal değil, baypas konumlarında bir değişiklik ve bağlantıların ihlali var. Bazı durumlarda, form iletişim kutusuna öğelerimizi manuel olarak eklemek, düzeltme yapmaktan daha kolaydır.

2. Form güncelleme bayrağı ayarlanır, güncelleme " Yeni sağlayıcı yapılandırmasından alın»

Bu durumda, elemanın form diyalogu, tedarikçi elemanının form diyalogu ile tamamen hizalanır.

Güncellemeye geri dönelim. Nesne modüllerini ve belge yöneticisi modüllerini, ortak modüllerle aynı şekilde ele alıyoruz ve bunları prosedürel olarak güncelliyoruz. Dizin formlarıyla yaptığımız gibi, belge formlarıyla da hareket ediyoruz.

Ayrı ayrı, çalışmayı rollerle vurgulamak gerekir. Örnekte rolleri güncellemenin gerekli olmamasına rağmen, bahsetmeye değer. Sağlayıcının yapılandırması yeni bir nesne içerdiğinde en basit durumu ele alalım. Bu durumda, rolü güncellemeniz gerekecek "Tam haklar”, ancak bu rol bizim tarafımızdan oluşturulan bazı nesneleri, örneğin dizinleri, belgeleri vb. içerebilir.

Görünüşe göre rol ile Tam haklar» her şey basit, onları tamamen birleştiriyoruz, standart dışı nesnelerin hakları yine de korunacak. Yani, tür olmayan nesnelerin hakları asla kaybolmaz, ancak tüm bu nesnelerin bayrağı olacak " Etkileşimli kaldırma", ki bu her zaman iyi değildir. Eski sürüm ve hazırlanan yeni sürümün konfigürasyonları karşılaştırıldığında, bu açıkça görülmektedir:

Modüllerle çalıştığımız gibi diğer rollerle de ilerliyoruz - daha fazla değişikliğimiz varsa, rolü birleştirmeyiz, güncellemeden sonra tedarikçinin yeni sürümde eklediklerini ona ekleriz.

Güncelleme penceresinde iki kez değiştirilen tüm nesneler üzerinde çalıştıktan sonra, " Çalıştırmak»

Değiştirdiğimiz nesnelerin yeni konfigürasyondan yükleneceği sorusuna olumlu cevap veriyoruz.

Açılan pencerede " Destek kurallarını ayarlama"Bayrakların ayarlanıp ayarlanmadığını kontrol edin, varsayılan olarak doğru olmalarına rağmen, tuşuna basın" tamam».

Birleştirme işleminin sonunda ana konfigürasyonu kaydediyoruz, veritabanı konfigürasyonunu henüz güncellemiyoruz.

Şimdi yapılandırmak içiniçin_güncellemedüzenli yollarla doğru bir şekilde güncellenemeyen bu minimal iyileştirmeleri ekliyoruz.

Veritabanında bu işlemin yürütülmesini kontrol etmeyi kolaylaştırmak için temel Satıcı yapılandırmasını ve eski sürümün ana yapılandırmasını karşılaştırmaya başlayalım.

tabanda for_updating aynısını yapalım. İki kez değiştirilmiş nesneleri kontrol ediyoruz, hiçbir fark olmamalı.

Veritabanını güncelledikten sonrafor_undatingtamamlanacak, veritabanı yapılandırmasını güncelleyeceğiz ve bazı noktaları test edeceğiz, yükseltme işlemi sırasında tam olarak neyin test edilmesinin iyi olacağı netleşecek, burada her şey bireyseldir.

Destek yardımı ile çalışan veritabanının güncellenmesi tavsiye edilir."Yapılandırma" - "Destek" - "Yapılandırmayı güncelle".Bu durumda, yeni sürümden iki kez değiştirilmiş nesneler yüklenecektir, yani. değişikliklerimizin üzerine yazılır (konfigürasyonu kaydetmeyiz!), ancak daha sonra hazırlanan konfigürasyon ile birleştirildiğinde onları geri yükleriz. Bundan sonra yapılandırmayı kaydedebilir, veritabanı yapılandırmasını güncelleyebilirsiniz.

Değiştirilmiş 1s 8.3'ün standart olmayan bir güncellemesi için bu talimatta, yapılandırıcının nasıl açılacağı, veritabanı yapılandırması, tedarikçi yapılandırması ve ana yapılandırma gibi temel şeyleri açıklamayacağım. Bu konuda ve orada çok şey yazıldı ve bu bilgiyi bağımsız olarak İnternette bulabilirsiniz. Yükseltme işleminin ana noktalarını ve nelere dikkat etmeniz gerektiğini anlatmaya çalışacağım.
Atipik muhasebe 3.0.51.22'yi örnek olarak aldım ve bunun 3.0.53.29 sürümüne nasıl yükseltileceğini göstereceğim. 8.3.10.2561 platform sürümünde (eski platformlarda büyük bir fark yok, sadece karşılaştırma penceresi daha önce biraz farklı görünüyordu).
Bol resim ve az yazı olacağını hemen söyleyeceğim. Bir süreci ezberlemeyi, bir metin denizini okumaktan görsel olarak daha kolay buluyorum.

1. Veritabanı yapılandırmasının satıcı yapılandırmasıyla uyumluluğunu kontrol edin.

Bunun için ihtiyacınız var

Kabul ederseniz, güvenle 2. maddeye geçebilirsiniz.

1 A. Destek için yapılandırmayı ayarlama.

Veritabanının farklı bir sürümüne ve satıcı konfigürasyonunun sürümüne sahipseniz, aynı menüden mevcut konfigürasyonu silmeniz gerekir: konfigürasyon - destek - destek ayarları. Ve "Destekten çekil" düğmesini tıklayın.

"Kısa" bir beklemeden sonra tüm onay işaretlerini kaldırın. Peki, "Ayarları otomatik olarak kaydet" onay kutusunun işaretini kaldırabilirsiniz. Ve yürütmek için tıklayın.

Sonuç olarak, aynı veritabanı sürümleriyle desteklenen bir yapılandırma elde edeceğiz.

2. Veritabanı güncellemesi.

Şimdi güncellemeye devam edebilirsiniz.

SADECE "Yapılandırma" - "Destek" - "Yapılandırmayı güncelle ..." menüsünden güncellemeniz gerektiğini hemen söyleyeceğim.
"Karşılaştır, dosyadan konfigürasyonla birleştir..." seçeneğini kullanın. YAPMAYIN!!! Bu mekanizmayı kullanırken, bir sonraki yükseltmenizde adım 1a'ya gitmeniz gerekecektir. Bu nedenle, bunu yapmayalım ve kendimize (veya bir dahaki sefere veritabanını güncelleyecek birisine) gereksiz sorunlar yaratmayalım.

Ardından, güncelleme dosyasını seçin.
Birkaç sürümden sonra güncelleme hakkında söylemek istiyorum. 1C, aynı anda birkaç sürümden geçerek dosyaları CF'ye güncellemeyi önermez. Bu sırayla yapılmalıdır. Teoride bu doğru.
Bunun neden tavsiye edilmediğini açıklayayım. Programcılar herhangi bir aksesuarı kaldırmak isterse, önce buna “delete” önekini atfederler, ardından birkaç sürümden sonra onu kaldırırlar. Ve bazı sürümlerde ondan bilgi aktarabilirler. Bu sürümü atlayarak veri kaybedebilirsiniz. Ancak pratikte, 1c veritabanlarıyla 10 yıllık çalışmam boyunca böyle bir durumla karşılaştım. Bir nedenden dolayı, geliştiriciler numaralandırmadan dizine veri aktarmaya karar verdiğinde. Ancak, benim için kritik olmaktan çıkmadı. Bu verileri arşivden mevcut veritabanına aktaran basit bir işlem yazdım. Yeniden güncellemeye gerek yoktu.
Bana taş atabilirsin, ama ben her zaman birkaç sürüm için veritabanını cf dosyaları aracılığıyla güncellerim.
Biz de güncellemeye bastık, güncellemenin hangi sürümle yapılacağı mesajını aldık. Tamam'a tıklıyoruz.

Karşılaştırılacak nesneleri bekliyoruz.
Ardından, listenin en altındaki “yalnızca iki kez değişen özellikleri göster” öğesini seçmemiz gerekiyor.

Bir de bayrak olmadan önceki eski versiyonlarından bahsetmek istiyorum.

Yani artık çok daha az nesne görüyoruz.

Sizinki boşsa, inanılmaz derecede şanslısınız ve "yürüt" düğmesine güvenle basabilir ve güncellemenin tamamlandığını düşünebilirsiniz. Pekala, burada her şey o kadar basit değil, bu yüzden ana nesnelerin üzerinden geçeceğim.

İlk söylemek istediğim şey. Birleştirme modunu asla değiştirmeyin."Yeni satıcı yapılandırmasından al" olmalıdır. Aksi takdirde, MGR yorumu ile veritabanında çöp alırsınız.
"Modül farklılıklarını göster..." düğmesi yok!
Modülün yanındaki dişli simgesine tıklayın

İşlev ve prosedürlerde birçok değişikliğin olduğu bir pencere açılır.

Hangi fonksiyonda değişiklik olduğunu anlamak için ya veritabanının bir kopyasını almamız ya da konfigürasyon menüsünden konfigürasyonu bir dosyaya kaydetmemiz gerekecek. Ve sonra boş bir veritabanına yükleyin. Ardından, "yapılandırma" menüsüne gidin ve "Yapılandırmaları karşılaştır ..." seçeneğini tıklayın.
Ana konfigürasyonu tedarikçinin konfigürasyonu ile karşılaştırmak için seçin.

Ve şimdi değişiklikleri zaten "modüllerdeki farklılıkları göster ..." ile görebilirsiniz. Çünkü hiçbir şeyi değiştirmeyeceğiz, sadece neyin değiştiğini görmek istiyoruz.

Ve Decline fonksiyonuna bir kod parçasının eklendiğini görüyoruz. Tüm değişiklikler mavi oklara tıklanarak görüntülenebilir.

Güncellenmiş konfigürasyona dönelim. Orada, dişli simgesi aracılığıyla modülleri birleştirme moduna girdik. Ardından, tüm onay kutularını koyduk ... manuel olarak .. platform geliştiricilerine “teşekkür ederim” diyerek :)

Fonksiyonumuzun azaldığını görüyoruz. Değiştirilen öğeyi bulun. Umarım şimdi, bu kodun nereden geldiğini güncellerken tahmin etmemek için, eklenen kodlardan herhangi birini neden yorumlarla ayırmanız gerektiği açıklığa kavuşmuştur.
Büyüteç simgesini tıkladığınızda platform, bu metni eklemek istediğiniz kod satırını vurgulayacaktır.

Üst pencereden kopyalayın ve alt pencereye yapıştırın.

Bunu tüm modüller için yapın. Modül değiştirilmediyse, para birimi referansı ile bizim durumumuzda olduğu gibi. Modu basitçe “Yeni satıcı konfigürasyonundan al” olarak ayarladık ve vitese TIKLAMAYIN (dişlinin yanında yeşil bir onay işareti olmamalıdır, bu, kodun manuel olmadan tamamen yeni konfigürasyondan alınacağı anlamına gelir) yapılandırma).

İyi. Şimdi, tüm nesneleri gözden geçirdikten sonra, "ayarları otomatik olarak kaydet" seçeneğinin işaretini kaldırabilir ve ardından "yürüt" yapabilirsiniz.

“Ana konfigürasyonda eski konfigürasyona göre değiştirilmiş nesneler var….. Güncelleme sırasında bu nesneler değiştirilecek! Uygulamak?" EVET'e basmaktan çekinmeyin.

Bir sonraki pencerede, onay kutularını resimde gösterildiği gibi bırakın. Ve başka bir şey!!! Her iki onay kutusu da işaretlenmelidir - "nesneler destek korunurken düzenlenir." Tamam'a basıyoruz.

Her şey. Standart olmayan konfigürasyon 1'lerin güncellemesi tamamlandı.
Bu yöntem ideal değil ama bence birçok kişi bu adımlarda hata yapıyor.
Tabii ki, her şeyi anlatmadım, hala birçok tuzak var. Ancak güncellemelerin %90'ının bu talimata göre güvenli bir şekilde güncellenebileceğini düşünüyorum.

Birkaç yayın için yapılandırmayı aynı anda güncellemek çok tehlikelidir. Buradaki nokta, her yapılandırma güncellemesinden sonra bilgi bankası güncellemesinin 1C:Enterprise modunda başlatılmasıdır. Bu nedenle, yalnızca en son sürümü güncellerseniz bilgi tabanları en son yapılandırmayla eşleşmeyebilir. Makalede, Sibirya Tarım Grubu CJSC'nin bir uzmanı olan Dmitry Rudakov, kişisel deneyimini 12 sürüm için tek seferlik bir yapılandırma güncellemesinde paylaşıyor.

Yapılandırma değişiklik modunu kontrol etme

Böyle bir durumu hayal edelim. Hesaplama kaydı boyutuna (gösterge) sürüm 1'deki (bundan böyle PPM olarak anılacaktır) "Manufacturing Enterprise Management" (bundan sonra PPM olarak anılacaktır) geliştiricilerine "Bireysel" adıyla "DirectoryReference.Individual" türü atanmıştır. 2. sürümde bir boyut daha eklediler - "ReferenceReference.Employees" türünde "Çalışan". 1C:Enterprise başlatıldığında, "Çalışan" boyutunu "Bireysel" boyutla aynı şekilde dolduran işleme etkinleştirilir. Ve sonra 3. sürümde, "1C" geliştiricileri "Bireysel" boyutu kaldırdı ve yalnızca "Çalışan"ı bıraktı. Yapılandırmayı yayın 1'den yayın 3'e hemen güncellerseniz, tüm hesaplama kaydını silebilirsiniz.

Ve konfigürasyon değişiklik imkanı ile destekleniyorsa ve aynı veri tabanında düzenlenmiş raporlama üretiliyorsa, her sürüm için konfigürasyonun güncellenmesi gerekir ki bu da adam-saat açısından çok pahalı olabilir. Örneğin, büyük ölçüde değiştirilmiş bir "SCP"yi 1 sürüm için güncellemek, deneyimli bir uzman için 30 saatlik çalışma süresi alabilir.

Bu nedenle, güncellemeye devam etmeden önce şunları belirlemeniz gerekir: değişiklik olasılığı olan tipik bir konfigürasyonda mı yoksa değişiklik olasılığı olmayan bir konfigürasyonda mı çalışıyorsunuz? Bunu yapmak için, menüde adımları takip eden yapılandırıcıya gidin " Yapılandırma - Destek - Destek Ayarı".

Şekil 1. Yapılandırma desteği ayar penceresini çağırma

ayarlanırsa " destek konusunda", bu yapılandırma tipiktir ve " Değiştir etkin"- konfigürasyon büyük olasılıkla değiştirildi (en azından böyle bir olasılık dahil edildi). Üçüncü durum ise Yapılandırma kullanımdan kaldırıldı."Çeşitli konfigürasyon durumları Şekil 2, 3, 4'te gösterilmektedir.

Pirinç. 2. Değişiklik olasılığı olmayan tipik konfigürasyon

Pirinç. 3. Değişiklik etkinleştirilmiş tipik yapılandırma

Pirinç. 4. Yapılandırma destekten kaldırıldı

Değiştirilen konfigürasyonları güncellemek için algoritma

Son zamanlarda, "Ticaret Yönetimi" değiştirilen yapılandırmasını güncelleme göreviyle karşılaştım, sürüm 10.3.13.2. Konfigürasyon, "BIT: Car Service Management 8" endüstri çözümü ile birleşmenin bir sonucu olarak değiştirildi ve iki yıl boyunca sürekli olarak iyileştirildi. Şimdi yapılandırmanın 10.3.25.1 sürümüne, yani 12 sürüme güncellenmesi gerekiyordu. Tüm güncelleme prosedürünü birkaç adıma böldüm.

Aşama 1. Yenileme prosedürünün maliyetinin ve zamanlamasının tahmini

Bağımsız çalışmaya başlamadan önce, bu alandaki uzmanların bağımsız bir değerlendirmesini almaya karar verdim. Değiştirilen konfigürasyonları otomatik yöntemlerle güncelleme yeteneğine sahip tek şirket 1C-IzhTiSi LLC'dir. Yapılandırmamı güncelleme maliyetini tahmin etme talebiyle bu şirketin uzmanlarıyla iletişime geçtim. İşin süresini ve maliyetini tahmin etmek için güncellenmesi gereken mevcut konfigürasyonu sağladım. Bir gün sonra raporu olan bir mektup aldım. .

Konfigürasyon güncellemesinin maliyet ve zamanlaması değerlendirmesinin sonuçları hakkında rapor:

Yapılandırma: Ticaret Yönetimi Revizyonu 10.3
Mevcut yapılandırma sürümü: 10.3.13.2
Sürüme güncelleme: 10.3.25.1
Yükseltilebilir modül sayısı: 1.847
Kontrol sürümleri sayısı: 8

Hisse başına fiyat şirketin web sitesinde belirtildiğinden - 1000 ruble - değerlendirmenin sonuçları beni şaşırttı. bir sürüm güncellemesi için. "1C-IzhTiSi" yorumu:

"Kaçırılan her sürüm için güncelleme maliyeti 2000 ruble'den yüksek değildir. Şimdi bir promosyon var, bu yüzden maliyet 1000 rubleyi geçmiyor. Ancak hizmetlerin nihai fiyatı, güncelleme için işçilik maliyetlerinin değerlendirilmesinin sonuçlarına göre belirlenir ve 1000 ruble/serbest bırakmadan daha düşük olabilir.".

Güncelleme için gereken sürümlerin nasıl seçildiğini de açıkladım. Soruma yanıt olarak, bunun açıkça gösterildiği bir ekran görüntüsü aldım (Şekil 5). Sürüm Numarası sütunu, yükseltmek istediğiniz yapılandırma sürümünü gösterir. 'Yükseltme Sürümü' sütunu, hangi sürümden yükseltme yapabileceğinizi gösterir. Değerlendirme sonucunda gerekli güncelleme sayısı 9'a düşürülmüştür.

Pirinç. 5. Yapılandırmayı doğru şekilde güncellemek için kullanılması gereken sürümlerin seçimi

1C-IzhTiSi raporunu inceledikten sonra, aynı miktarda çalışmaya harcanan kişisel zamanı hesapladım. Her güncelleme prosedürü yaklaşık 6 saatimi alıyor. Bu nedenle toplam harcanan süre 56 (9x6) çalışma saati, yani yaklaşık yedi iş günüdür. Ek olarak, güncellemeden sonra bazı eksikliklerin ortaya çıkma olasılığı vardır: örneğin, kullanıcı ihtiyaç duyduğu konfigürasyon değişikliklerinin kaybolduğundan şikayet edecek ve ardından zaman maliyetleri ciddi şekilde artacaktır. Bu arada, "1C-IzhTiSi" şirketinin uzmanları, tüm iş miktarını üç ila dört iş günü içinde yapmayı teklif ediyor. Bu yüzden hizmetlerini kullanmaya karar verdim.

Şimdi konfigürasyonda tam olarak nelerin değiştiğini kısaca anlatacağım.

Büyük ölçüde değiştirilmiş nesneler. Bunlar, birçok tipik özelliğin değiştirildiği nesnelerdir. Ayarlamalar karmaşıktır. Nesnenin ayrıntıları, nesne formunda ve liste formunda görüntülenen tablo bölümüne eklenir. Formlara eklenen ayrıntılar için işleyiciler eklendi. Bir belgeyi postalamak veya kayıt için bir dizi hareketi kaydetmek için tipik mekanizma değiştirildi.

Büyük ölçüde değiştirilmiş belgeler:

"Tedarikçiye sipariş";
"Malların hareketi";
"Gereksinim-fatura";
"Mal ve hizmetlerin alınması".

Büyük ölçüde değiştirilmiş kayıtlar:

"Depolardaki mal sevkiyatı";
"Depolardaki mallar".

Önemli ölçüde değiştirilmiş nesneler. Ayrıntıların eklendiği nesneler, nesnelerin biçimleri veya nesnenin modülleri değiştirilmiştir (kural olarak, belge yazılmaz).

"Gelen nakit siparişi" belgesi;
Bilgi kaydı "Bileşen isimlendirmesi";
"İptal edilen mallar" bilgi kaydı;
Genel modüller.

Biraz değiştirilmiş nesneler. Objelerde sadece formlar değiştirilmiş ve detaylar eklenmiştir.

Referans kitapları:

"Adlandırma türleri";
"Karşı taraf sözleşmeleri";
"Müteahhitler";
"Adlandırma";
"Adlandırma fiyat türleri";
"Bir dizi bilgi kaydı".

"Genel" bölümündeki etkinliklere, düzenlere, rollere ve ortak modüllere ilişkin abonelikler değiştirildi. Neredeyse her şey bir endüstri kararıyla değişti.

Aşama 2. Gizli bilgilerin kaldırılması

1C-IzhTiSi çalışanlarına test için bir bilgi tabanı sağlamadan önce, içindeki gizli bilgileri silmek gerekir. Bu gibi durumlar için 1C, çok yaygın olarak bilinmeyen "Gizli bilgilerin değiştirilmesi" işleminin kullanılmasını önerir.

"Gizli bilgilerin değiştirilmesi" işlemi, bilgi tabanındaki bilgilerin seçici olarak değiştirilmesi veya temizlenmesi için tasarlanmıştır. İşleme, bazı bilgileri gizlemenin (temizlemenin, değiştirmenin) gerekli olduğu durumlarda, test için iletmeden önce bir bilgi tabanı hazırlamak için kullanılabilir.

ChangePrivateInformation.epf'nin işlenmesi, ITS diskinde 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation dizinindedir. Ayrıca, bu işlem şu bağlantıdan indirilebilir: http://its.1c.ru/db/metod81#content:1644:1.

Doğal olarak, her şirketteki gizli bilgiler farklıdır, ancak büyük olasılıkla değiştirilmesi gereken verilere dikkatinizi çekiyorum:

Rehberler: Kişiler, İrtibat kişileri, Karşı tarafların irtibat kişileri, Karşı taraflar, Fiyat türleri.
Bilgi kayıtları: Bir kişinin pasaport verileri, kişilerin tam adı.

Listeniz muhtemelen daha uzun olacaktır, ancak bunlar en yaygın verilerdir. Bunları değiştirmek, bilgi tabanınızı test etme yeteneğinizi etkilemez. Ayrıca, hizmet şirketinin birlikte çalışması gerekmeyen tüm nesneleri grup işleme yoluyla silebilirsiniz.

Aşama 3. Güncellemenin sonuçlarını alın

Üç gün sonra, bana cf dosyaları ve bunları kurmak için kapsamlı talimatlar verildi. Kontrol sürümleri için, yalnızca meta veriler güncellendiğinden, kullanıcı çalışması için kullanılamayan cf dosyaları sağlanır. Yalnızca en son sürüme doğru şekilde yükseltme yapmaları amaçlanır.

Yapılan çalışmanın sonucuna göre, konfigürasyondaki tüm değişikliklerin kaydedildiğini söyleyebilirim; görsel izleme sırasında, değiştirilen tüm nesneler, tipik konfigürasyondan özelliklerini ve farklılıklarını korudu. İşlem sırasında, kullanıcıların hiçbiri herhangi bir değişikliğin kaybolduğunu bildirmedi.

Güncelleme sonucunda bağımsız bir çözüm için iki küçük görev belirledim.

Öncelikle. Güncellemenin "Karşılaştır, birleştir" mekanizması kullanılarak gerçekleştirilmesi nedeniyle, kontrol sürümleri nedeniyle teknik riskler olmadan veritabanı konfigürasyonu gerçekten güncellenir ve doğru bir şekilde güncellenir. Ancak, satıcı yapılandırması güncellenmez. Tabii ki, teknik olarak yetkin bir uzman bu çalışmayı kolayca tamamlayacaktır, ancak 1C-IzhTiSi'den güncelleme için daha eksiksiz talimatlar göndermesini istedim. Buna göre, deneyimsiz bir uzman bile güncelleme yapabilir.

İkinci. Güncellemenin bir sonucu olarak, tüm nesneler, dolaylı bir dezavantaj da olabilen değişiklik olasılığı ile desteklenir. Bu hizmetleri aynı anda kullanmanız gerekiyorsa, tüm nesneleri tekrar desteğe koymanız gerekir. Şimdiye kadar bunu yalnızca tüm meta veri nesnelerinin numaralandırılmasıyla yapabilirim. Ne yazık ki, bu işlem manuel olarak yapılırken, gelecekte otomatik hale gelecektir.

Bahsedilen iki göreve ek olarak, prensipte güncellemenin kalitesini etkilemeyen ve nadiren kendini gösteren küçük bir kusur keşfedildi. Güncellemenin bir sonucu olarak, orijinal konfigürasyonun kod satırları ile güncellenmiş olanın kod satırları görsel olarak örtüşmektedir, ancak bazı nedenlerden dolayı satırların sonuna boşluklar eklenmiştir. Bu, değiştirilen kodun miktarını biraz arttırdığı için bir dezavantajdır. Ve daha fazla manuel güncelleme durumunda, bu tür kod bölümlerinin olmaması daha iyi olur. Şek. 6, güncellemeden önceki bir örneği gösterir ve şek. 7 güncellemeden sonraki bir örnektir.

1C lisanslama politikası, standart konfigürasyonlarda iyileştirmeler yapma ve kaydetme imkanı ve buna bağlı olarak bunları güncelleme imkanı sağlar.*

* Değiştirilmiş veya standart olmayan konfigürasyonlar 1C, işletmenin ihtiyaçları ve özellikleri nedeniyle bir takım değişikliklere uğramış, otomatikleştirilmiş kurumsal yönetim sisteminin bir parçası veya tamamını oluşturan 1C:Enterprise platformunu temel alan bir yazılım ürünüdür, dizinlerin, belgelerin, rollerin, modüllerin vb. formları ve bileşimi açısından, bu nedenle 1C yapılandırmasını değişikliklerle güncellemek, standart bir çözümü güncellemekle tamamen aynı değildir.

1C tarafından yayınlanan güncellemeler, hataları düzeltmeyi ve mevzuat nedeniyle değişiklik ve eklemeler yapmayı amaçlamaktadır. Yakın zamanda piyasaya giren yeni konfigürasyonlar, birinci tipte çok sayıda güncellemenin piyasaya sürülmesi ile karakterize edilir. Temel olarak düzenleyici raporlamayı derlemeyi amaçlayan işlevselliğe sahip yapılandırmalar için, örneğin "1C: ZUP", "1C: Muhasebe", ikinci türden daha fazla güncelleme vardır.

Standart olmayan konfigürasyonları güncellemenin özellikleri, daha önce yapılan iyileştirmeleri tamamen korurken, 1C'nin en son sürümünde tüm değişiklikleri yapma ihtiyacıdır. Bu, çözümü standart bir komut dosyasına sahip olmayan, yani tamamen otomatikleştirilemeyeceği, önemsiz olmayan bir görevdir. Bu nedenle, standart dışı konfigürasyonları güncelleme metodolojisinde bir uzmanın katılımını gerektiren manuel işlemler hakimdir.

Standart olmayan konfigürasyonları güncellemenin uygulama aşamaları, mevcut iyileştirmelerin miktarından etkilenmez. Kısaca şu şekilde açıklanabilirler:

Değiştirilen nesnelerin aranması ve karşılaştırılması;
Yeni sürümden güncellemeler yapmak;
Daha önce yapılan değişikliklerin tanıtımı, önceki aşamada "üzerine yazılan";
Proseslerin uyumluluğunu ve işleyişini kontrol etmek.

Fark, uygulama süresinde olacaktır: Çok fazla iyileştirme varsa, süreç buna göre daha fazla zaman alacak, odaklanma, dikkat ve manuel doğrulama gerektirecektir.

Bir sonraki kullanılabilir sürüm için "1C: Ticaret Yönetimi" (sürüm 2014) örneğini kullanarak 1C ortamı için standart olmayan bir yapılandırmayı güncellemeyi düşünün.

Bu çok basit bir örnektir, ancak yukarıda belirtildiği gibi, daha karmaşık bir konfigürasyonun güncellenmesi, elbette, bir uzman adına çok fazla zaman ve konsantrasyon gerektirecektir, ancak aynı aşamalara sahip olacaktır - güncelleme (yeni bir standarda) konfigürasyon), girilenlerin ve yapılan değişikliklerin mutabakatı ile çalışma, vb.

Yapılandırmayı güncellemeden önce bilgi tabanını kaldırın. Bu eylemin, istisnasız tüm veritabanlarıyla ve özellikle standart olmayanlarla herhangi bir manipülasyondan önce gerçekleştirilmesi önerilir:

Bilgi bankasının boşaltılması tamamlandı:

Konfigürasyon sonlandırılmamışsa, yani tipik bir durumsa, o zaman Konfigürasyon penceresinde adın karşısındaki sarı küpün yanında kilit simgesinin de görüntüleneceğini lütfen unutmayın:

Konfigürasyon menüsünde, "Destek" ve "Yapılandırmayı güncelle"yi seçin. Aslında, bu aşamada eylemler, tipik bir yapılandırmayı güncelleme süreciyle tamamen aynıdır:

Veritabanının boyutuna ve değişikliklerine bağlı olarak, mevcut güncellemelerin otomatik olarak aranması biraz zaman alabilir. Bu nedenle, önerilere rağmen, “Bir güncelleme dosyası seçin” seçeneğini seçmeye değer ve bağımsız olarak, arşivi güncellemelerle açıp kaydettikten sonra yolu manuel olarak belirtin:

Yardım bilgilerini, talimatları ve güncelleme sırasını içeren pencere:

Yapılandırma karşılaştırma penceresi. Mevcut konfigürasyonun durumu ağaçta solda, yeni, standart versiyonla ilgili bilgiler sağda görüntülenir. Değişiklik yapılan bölümler de vurgulanır. Ardından, yeni konfigürasyonda hangi bölümlerin değiştirildiğini ve aynı anda hangi bölümlerin değiştirildiğini bulmanız gerekiyor:

Hangi tipik meta veri nesnelerinin daha önce değiştirildiğini ve yeni bir sağlayıcı yapılandırması kurulurken de değiştirileceğini öğrenmek için "Yalnızca iki kez değiştirilen özellikleri göster" seçeneğini seçin:

Yalnızca bu koşulu karşılayan nesneler vardır:

Meta veri ağacını genişleterek, hangi belirli nesnelerin değiştirileceğini görebilirsiniz. Ayrıntılı bilgi almak için, değiştirilen nesneyi seçmek için sağ tıklayın:

"Modüllerdeki farklılıkları göster" seçeneğini kullanarak değişiklikleri kod düzeyinde değerlendirebilirsiniz, ancak güncellemeleri kurduktan sonra yapmak için bunların da hatırlanması gerektiğinden, iki rapor oluşturuyoruz: "Ana konfigürasyon nesnelerinin eski satıcıyla karşılaştırılması hakkında rapor yapılandırma" (mevcut iyileştirmeler) ve "Eski Satıcı Yapılandırma Raporu ile Karşılaştırıldığında Yeni Satıcı Yapılandırma Nesnesi" (Güncellemeler).*

*Biraz terminolojiyi aradan çıkaralım:

"Ana konfigürasyon" - güncellenmesi gereken standart olmayan bir konfigürasyon;
"Eski satıcı yapılandırması" - güncellemelerin en son yüklendiği tipik yapılandırma;
"Yeni sağlayıcı yapılandırması" - şu anda güncellediğimiz yapılandırma.

Rapor formunu ayarlayın ve yükleyin. Daha önce yapılan değişikliklerin listesi düzeltildi:

Raporları kaldırdıktan sonra, doğrudan güncellemeye gidin ve "Çalıştır" ı tıklayın. Konfigüratör, "Yeni satıcı konfigürasyonundan al" güncelleme kuralını sunar (üçüncü sütunda belirtilir). Bu, tüm iyileştirmelerin silineceği ve standart güncellenen nesnelerle değiştirileceği anlamına gelir. Bu kuralı cazip "Birleştirme Modu" olarak değiştirmek buna değmez çünkü. otomatik birleştirme kaosa yol açacaktır. Yine de, zaman harcamak ve manuel olarak değişiklik yapmak daha iyidir:

Bir yapılandırmanın destekten kaldırılmasıyla ilgili genel bilgilerin bulunduğu pencerede hiçbir şeyi değiştirmeniz gerekmez. "Tamam" tıklandığında nesneler birleştirilir. Ardından, güncelleme sürecini doğru bir şekilde tamamlamak için "Enterprise"ı başlatır ve değişiklikleri yazarız:

Değişiklik listesini kabul ediyoruz:*

*"Kabul Et" düğmesi etkin değilse, "Yama Testi" çalıştırmalısınız:

F5 üzerinden hata ayıklamaya başlıyoruz ve güncellemelerin yasallığının onayını alıyoruz:

Güncelleme dağıtım sürecinin tamamen tamamlandığına dair onay alındıktan sonra, yapılandırıcıya dönmeli, iki kez değiştirilen meta veri nesnelerine gitmeli ve indirilen raporları kullanarak kod düzeyinde sabit değişiklikleri manuel olarak yapmalısınız. Sonuç olarak, bundan sonra ayarların doğruluğunun ve iş süreçlerinin yeterliliğinin kontrol edilmesi gerektiğini ekliyoruz.

Tüm konfigürasyon değişikliklerini bulmak için, veritabanı konfigürasyonunu (geçerli konfigürasyon) satıcı konfigürasyonu (değişiklik olmadan orijinal konfigürasyon) ile karşılaştırmanız gerekir. Bu, standart platform özellikleri kullanılarak yapılabilir. Konfigüratörde konfigürasyon desteği ayarlarına gidin:

Önümüzde bir konfigürasyon desteği ayarları penceresi açılacaktır.

"Karşılaştır, Birleştir" komutunu çalıştırarak, ana konfigürasyonda tedarikçinin konfigürasyonuna göre değiştirilmiş nesnelerin bir listesini alacağız. Bu, görüntülenen meta veri ağacı için varsayılan filtredir. Satıcı yapılandırmasıyla karşılaştırmanın sonucu bu şekilde görünebilir.

Bu noktada, ana ve sağlayıcı yapılandırma nesneleri arasındaki farkları yeterli ayrıntıda görebiliriz. Örneğin, aşağıdaki ekran görüntüsü, konfigürasyonlardaki tipik bir uygulamanın modüllerinin bir karşılaştırmasını gösterir.

Çoğu durumda, meta veri nesnelerini bu şekilde karşılaştırarak, tüm iyileştirmeleri korurken tipik yapılandırmayı güncelleyebiliriz. Tabii ki, hepsi yapılan değişikliklerin karmaşıklığına bağlıdır, çünkü tüm konfigürasyon "birkaç kez yeniden yazılırsa", satıcının resmi güncelleme paketinden güncelleme yapmak imkansız hale gelebilir.

Çıktı

Kolaylık sağlamak için, tüm yapılandırma değişikliklerini bir elektronik tablo belgesinde listeleyebilir ve modülleri nasıl birleştireceğinizi seçmeniz gerektiğinde, ana yapılandırmaya veya satıcı yapılandırmasına öncelik vermeniz gerektiğinde bunu sonraki bir güncellemede kullanabilirsiniz. Konfigürasyon karşılaştırmalarının sonuçlarını kaydetmek için konfigürasyonun tamamı için ayrıntılı bir karşılaştırma raporu oluşturmalısınız.

"Tamam" düğmesine tıklayarak, 1C:Enterprise platformunun diğer biçimlerde (örneğin, bir Excel elektronik tablosu) kaydetmenize izin verdiği bir elektronik tablo belgesi biçimindeki tipik yapılandırmadaki değişiklikler hakkında ayrıntılı bir rapor alacağız. .

Bu noktada değişiklik raporu hazır, güncellemeye başlayalım. Alınan rapora göre metadata nesnelerinin güncellenmesinin doğruluğuna bakmayı unutmayınız.