Има много инструкции за актуализиране на модифицирани стандартни конфигурации на платформата 1C. Ето защо, за да не увеличавам същността, няма да описвам напълно целия процес. Освен това се предполага, че този текст е за човек, който вече е актуализирал модифицирани конфигурации и знае основните моменти и клопки. Този методсамо опростява този процес, като по същество предполага използването на автоматизирано сравнение на промените в конфигурацията и промените в модулите на ниво сравнение на текстови файлове. С този подход вероятността от грешки е значително намалена („пренаписване“ чрез актуализиране важни променипоради невнимание), свързани с „човешкия фактор“.

ВСЯКА актуализация на конфигурацията започва с разтоварване на информационната сигурност. Това е „златното правило“, това винаги трябва да се помни, това трябва да се направи с всеки метод (дори ако са забравили да го споменат). След това можете да отидете по два начина: или актуализиране в тестовата база данни, или актуализиране в производствената база данни. Тук важен моменткакто следва: обикновено променените конфигурации се актуализират не за всяка версия (тъй като това може лесно да се направи със стандартните), а за няколко наведнъж, тъй като този процес е трудоемък. Първият метод (актуализация на тестова база данни) включва окончателното прехвърляне на актуализацията в работната база данни чрез изтегляне на cf файл. В този случай може да възникнат грешки, свързани с изтрити детайли (можете да намерите много статии за това). Следователно има някои рискове, но по време на актуализацията (която може да отнеме цял ден или дори повече) потребителите могат безопасно да работят, променяйки базата данни. При втория метод (актуализация на работеща база данни) тези рискове са елиминирани, но през цялото времетраене на актуализацията ключовите потребители няма да могат да работят в тази база данни. Във форумите има достатъчно дискусии за това кой метод е добър и дали си струва да прехвърлите актуализацията чрез конфигурационен файл. Мога само да кажа: въз основа на моя опит с първия метод, такива грешки не са възникнали при зареждане на cf файл. Във всеки случай можете да възстановите базата данни с помощта на резервно копие. Това е първият метод, който ще бъде разгледан тук, но това не засяга същността на метода и, ако желаете, можете да продължите според втория метод, като използвате предложения метод.

Така че, след като разположихме тестова база данни, използвайки ново архивиране, ние правим последователни актуализации на версиите до най-новите. След всяка версия стартираме „Debug“, за да запазим промените в конфигурацията и да реорганизираме данните. Във всичко диалогови прозорциЩракнете върху OK/Напред/Приемам/Да/Продължи...

По този начин актуализирахме конфигурацията на тестовата база до най-новата версия, но трябва да проверим дали сме презаписали промени и ако сме ги презаписали, трябва да ги прехвърлим в тази версия. Сега започва забавлението, така че ще го опиша стъпка по стъпка. Всяка стъпка ще има някакво обяснение: тоест първо се описва същността и след това повече Подробно описание. Ако същността е ясна, тогава описанието може да бъде пропуснато.

1. Ние запазваме промените в конфигурацията ПРЕДИ и СЛЕД актуализацията в текстови файлове.Отворете работните и тестовите бази данни в режим на конфигуратор. Отваряме конфигурациите в тях. И в двете бази данни започваме да обработваме сравнението на конфигурацията („Конфигурация – Сравнете конфигурации...“). ВАЖНО: и в двете бази данни изборът на конфигурации е един и същ:

Освен това, ние го записваме по следния начин: в работната база данни (където е конфигурацията ПРЕДИ актуализацията) - във файл с окончание "стар", а в тестовата база данни (където е конфигурацията СЛЕД актуализацията) - във файл с завършващ "нов".

2. Включване на изгубени промени в актуализираната конфигурация. Нека да преминем към ключовия етап на метода. Тъй като това е основната точка, за малко обяснение на случващото се има малко материал. На платформата 1C 7.7 файлът за актуализация беше пълна конфигурация. А актуализацията в 1C 7.7 се състоеше от зареждане на нова конфигурация и реорганизиране на базата данни за тази конфигурация. По този начин както конфигурацията, така и актуализацията бяха по същество един и същ md файл. За разлика от платформата 1C 7.7, на платформата 1C 8.x: конфигурацията се прехвърля чрез cf файл, а актуализацията чрез cfu файл. Разликата между тези файлове е, че cf файлът съдържа всички конфигурационни обекти, а cfu файлът съдържа само тези, които са променени от тази актуализация. И по този начин, когато се актуализира на платформата 1C 8.x, се засягат само онези конфигурационни обекти, които действително са променени в новата версия. В резултат на това, ако такъв обект е бил променен от нас, след актуализацията той ще бъде напълно заменен със стандартен и ще трябва да повторим в него промените, които е имал преди актуализацията, така че този обект да съдържа както нашите промените и промените на новата версия едновременно. Но ако конфигурационният обект, който сме променили, не е бил засегнат от актуализацията, нашите промени ще останат в него след актуализацията. За по-лесно разбиране ще го изобразя под формата на диаграма:

Тази диаграма показва някои типични конфигурации в процеса на промяна и актуализация. Низовете са неговите обекти (документи, директории, обработка и т.н.). Първо (под номер I) е само типична конфигурация: всички обекти без никакви промени. След това под номер II вече виждаме типична променена конфигурация: някои обекти са променени и тези променени обекти са обозначени в червено. Номер III е следващата актуализация за стандартната конфигурация: всъщност тя съдържа само обекти, засегнати от промените в новата версия, които са обозначени в зелено, но за по-голяма яснота завърших и всички останали обекти. И трябва да получим актуализирана стандартна конфигурация (показана на диаграма I), но с промени в двете диаграми II и III. На в този пример- тази крайна конфигурация е показана като номер IV и съдържа един обект, който е променен както от нас, така и от актуализацията. Останалите обекти, които променихме, очевидно останаха незасегнати от тази актуализация. Сега въпросът е: как да направим ВСИЧКИ наши промени в обекта, който е бил засегнат от актуализацията? Очевидно е, че трябва да направим две стъпки: първо, да намерим този обект и второ, да намерим местата в него, където трябва да бъдат нашите промени, и да ги направим отново. Отбелязвам, че естествено може да има няколко такива обекта и трябва да ги намерите и поправите всички. Така че нека да преминем към тази последна стъпка от актуализацията. На този момент, трябва да имаме отворена тестова база данни в режим на конфигуратор. Ако резултатът от обработката на сравнението на конфигурации или някакъв друг прозорец все още е отворен там, ние ще ги затворим всички, за да не се объркаме. След това отваряме работещата база данни в режим на конфигуратор (възможно е да я затворим, докато актуализираме тестовата база данни) и започваме да сравняваме конфигурациите там. И ще поставя описанието на последните две стъпки (намиране и коригиране) в отделни подпараграфи:

2.1. Потърсете обект с промени, изтрити от актуализацията. Време е да си припомним за txt файловете с окончания стар/нов. Всъщност тези файлове отразяват всички промени в конфигурацията (спрямо стандартната) съответно ПРЕДИ и СЛЕД актуализацията. По този начин, ако сме презаписали някаква промяна с актуализация, тя ще бъде само във файла „Отчет за сравнение_old.txt“. Тоест търсенето на необходимите конфигурационни обекти се свежда до сравняване на тези два файла. Ще сравним тези файлове с помощта на файлов мениджър Total Commander и неговите вградени инструменти. Мисля, че няма нужда да обяснявам тук какво е Total Commander, откъде да го вземете и как да го използвате... Тук обаче ще опиша накратко необходимите етапи от използването му. И така, нека стартираме Total Commander. Ако езикът на интерфейса е английски (главно меню и т.н.), тогава можете да го промените на руски: „Конфигурация - Опции...“, в диалоговия прозорец изберете секцията „Език“ в лявата колона, потърсете/изберете „Руски (руски)“ в списъка и щракнете върху „OK“. След това чрез Total Commander търсим txt файлове с отчети, избираме ги („Вмъкване“ или „щракване с десен бутон“) и започваме да сравняваме файлове: „Файлове – Сравнете по съдържание...“ (в английския интерфейс: „Файлове - Сравнете по съдържание ..."). В прозореца, който се отваря, съдържанието на файловете се показва съответно вляво/вдясно; бутоните „Следваща разлика”/„Предишна разлика” ви позволяват да търсите разлики. Този инструмент ще ви позволи бързо да намерите обекти, които ни интересуват.

Коментирайте: може да се случи и обратната ситуация - да се появят разлики в конфигурацията СЛЕД актуализацията, които ги нямаше ПРЕДИ актуализацията. Това означава, че изданието на актуализацията премахна съответните обекти от конфигурацията. По принцип тези обекти могат просто да бъдат пропуснати в нашите корекции, тъй като няма промени в тези обекти.

2.2. Извършване на промени в актуализирани обекти.След като намерим обект с презаписани промени, трябва да определим къде точно са тези промени: в модула ( програмен текст), диалогов прозорец (на формуляра) или други настройки. Тук ще отделя два случая: промяна в модул и всички други промени. И нека разгледаме тези два случая поотделно.

2.2.1. Промените, които бяха изтрити от актуализацията, бяха в модула.Всъщност това е основният случай (това се случва много по-често) и точно този случай е в нашия пример: промяната е изтрита в модул „Осчетоводяване на ДДС”. Както вече споменахме по-горе, имаме отворен прозорец за сравнение на конфигурации в конфигуратора на работната база. Там търсим обекта, от който се нуждаем. Всъщност неговата позиция в конфигурационното дърво е описана в нашия текстов файл, а именно: „GeneralModule.VAT Accounting.Module“. Точно това търсим в прозореца за сравнение. Разширяваме дървото на подчинение, докато намерим необходимия модул - в левия край срещу него трябва да има зелен молив, който показва, че обектът е променен в сравнение с конфигурацията на доставчика. Щракнете с десния бутон върху намерения ред и изберете „Показване на разликите в модулите...“:

След това ще се отвори прозорецът за сравнение на модулите:

Тук в горната част са посочени процедуриИ функции, в които има промени (в нашия случай това е една процедура „Изходна фактура в табличен документ“), а в долната част - текстовете на избраната процедура или функция с подчертани промени. Трябва да прехвърлим тези промени в нашата тестова база данни. Но това не премахва промените от актуализацията. Можете да автоматизирате това, както следва. Поставете курсора в долната лява част (където се променя текстът на избраната процедура с нашите промени) и натиснете последователно Ctrl+A (избиране на всички) и Ctrl+C (копиране на селекцията в клипборда). След това създаваме файл с кодово име "old_izm.txt", отваряме го текстов редактори натиснете Ctrl+V (поставете съдържанието на буфера). Правим същото за долната дясна част (където е текстът на избраната процедура от стандартната конфигурация на неактуализирана версия) - в резултат на това създаваме файл с кодово име "old_type.txt". След това отиваме в конфигуратора на тестовата база (трябва да е отворен един до друг, но без никакви прозорци вътре, за да не се объркаме в тези два конфигуратора) - и в конфигурацията търсим нашия модул (в този пример това е „ОбщиМодул.ДДС Счетоводство.Модул“) и в него необходимата процедура (в този пример е „Изходна фактура в табличен документ“): изберете всичко и го копирайте в нов текстов файлс кодово име "new_type.txt". Така имаме три файла ("old_izm.txt", "old_type.txt", "new_type.txt"), на базата на които трябва да създадем четвърти файл - "new_izm.txt". Този четвърти файл трябва да съдържа нашите промени, но като се вземе предвид актуализацията. Ще го формираме последователно чрез сравняване на съществуващите три файла. Първо, нека определим дали има следи от промени в актуализацията в тази процедура? За да направим това, сравняваме файловете "old_type.txt" и "new_type.txt" с помощта на Total Commander (вижте по-горе). Ако сравнението покаже, че файловете са идентични или има разлика в броя на интервалите или разделите, това означава, че сме имали късмет с тази част от промените и можете да прехвърлите промените просто като копирате съдържанието на файла „old_izm.txt ” и го поставяте в отворения модул на тестовата база данни, като първо изтриете съответната процедура (с други думи, заменяйки я). Тук е важно внимателно да наблюдавате пространствата преди и след процедурата, така че да няма излишък при по-нататъшно сравнение: това, разбира се, няма да повлияе на функционалността, но леко ще усложни проверката. Ако сравнението на „old_type.txt“ и „new_type.txt“ показа, че има реални разлики, това означава, че тази процедура съдържа както нашите промени, така и промените от актуализацията. За да опростите задачата за прехвърляне: първо, можете визуално да прецените кои промени са по-големи - от актуализацията или нашите. За да направим това, отново чрез Total Commander, ние последователно сравняваме „old_type.txt“ с „new_type.txt“ и „old_izm.txt“. И гледаме къде има повече промени: в сравнението на “old_type.txt” и “new_type.txt” или в сравнението на “old_type.txt” и “old_izm.txt”. Ако има повече промени в първото сравнение (актуализацията е променила повече функцията), тогава е по-лесно да коригираме актуализирания файл, като направим нашите промени, тоест променяме „new_type.txt“. Нека наречем това първия случай на извършване на промени. Ако има повече промени във второто сравнение (имахме повече промени), тогава е по-лесно да коригираме нашия файл, като направим актуализиращи промени, тоест променяме „old_izm.txt“. Нека наречем това вторият случай на извършване на промени. Сега как точно да прехвърлите промените бързо и точно. За да направим това, създаваме четвърти файл и, както вече беше договорено, го наричаме „new_izm.txt“. Като се има предвид оптимизирането на прехвърлянето на корекции, ние копираме съдържанието на „new_type.txt“ или „old_izm.txt“ в този файл (съответно за първия или втория случай на извършване на промени).
Сега отворете два прозореца за сравнение на файлове наведнъж. За първия случай на извършване на промени, това са сравнения за файловете "new_izm.txt"/"old_izm.txt" и "old_type.txt"/"old_izm.txt". За втория случай това са сравнения на файловете "new_izm.txt"/"new_type.txt" и "old_type.txt"/"new_type.txt". В прозореца за сравнение има бутон "Редактиране": щракнете върху него в сравнението на първата двойка. Сега нека обясним какво виждаме. В първата двойка сравнения се виждат обекти от нашата промяна и актуализация. В зависимост от нашия случай трябва да прехвърлим само нашите промени или само актуализациите. Във втория прозорец за сравнение се виждат само тези промени, които трябва да прехвърлим. Ако обърнете внимание - и в двата случая вторият файл и на първото, и на второто сравнение е един и същ. Затова се фокусираме върху редовете в този файл и според редовете във второто сравнение правим промени в първия прозорец за сравнение: натискането на бутона „Редактиране“ просто ще ни позволи да направим това.

За по-голяма яснота, нека изобразим графично действията по време на прехвърлянето в първия случай (ние променяме актуализирания файл, като правим нашите промени):

Действията във втория случай са абсолютно подобни и принципът на действие е абсолютно същият.

Най-трудният и неприятен случай е, когато нашите промени и ъпдейт промени са на ЕДНО място. Тоест, в действителност имаше две промени в един кодов сегмент. В този случай е необходима намесата на програмист. Намесата на програмист също е необходима, но в по-малка степен, ако например актуализация промени имената на променливите, които се използват в нашите промени. Също така си струва да се отбележи, че файлът „old_type.txt“ или „old_izm.txt“ може да съдържа празни редове - това са „следи“ от нашите промени. Трябва да ги прехвърлите, за да не са във финалния файл. Това не засяга функционалността, но при по-нататъшни сравнения (с последващи актуализации) ще направи анализа на действията малко по-труден. И така, след като сме създали четвъртия файл, прехвърляйки всички промени, трябва да копираме съдържанието му в конфигурацията. В конфигуратора на тестовата база данни необходимият модул трябва да се отвори на ново място: изтрийте съществуващата процедура и вмъкнете съдържанието на нашата финален файл, като се вземат предвид всички интервали между предишни/последващи функции. Така прехвърлихме промените в ЕДНА процедура на намерения обект. Ние (фиг. 6) наистина имаме само една процедура. Ако има няколко такива процедури, описаните стъпки трябва да се изпълнят за всяка от тях. Ако процедурата е нова (само в лявата половина), просто я добавете към съответния модул в тестовата база данни (за коректността на по-нататъшното сравнение трябва да поддържате реда на процедурите, както в съответния модул на работния база данни, където все още има стара версия).

2.2.2. Промените, които бяха презаписани от актуализацията, НЕ бяха в модула.За да прехвърлите такива промени, подобно сравнение няма да опрости работата по никакъв начин, така че промените се прехвърлят просто чрез визуално сравнение на обекти в работещите и тестовите бази данни.

По този начин ние прехвърляме промени за всеки обект, където нашите промени са били презаписани от актуализацията. За да проверим колко правилно сме прехвърлили всички промени, запазваме конфигурацията в тестовата база данни, качваме сравнението на конфигурациите във файла “Comparison Report_new2.txt” и го сравняваме с файла “Comparison Report_old.txt”. Ако всичко е перфектно, ще се появи съобщението „Файловете са идентични“. Ако някои обекти са били изтрити от актуализацията, тогава ако промените са прехвърлени правилно, само тези обекти ще бъдат видими в разликата. Би било правилно, ако в сравнението се виждат само интервали/празни редове/табулатори, но в този случай е по-добре да го изчистите и да получите съобщението „Файловете са идентични“. По този начин, след като запазим промените в тестовата база данни, качваме сравнението във файл и го сравняваме с промените в старата версия - повтаряме това, докато сравнението покаже, че сме прехвърлили всички необходими промени.

3. Прехвърляне на актуализираната конфигурация от теста към работещата база данни. На предишните етапи актуализирахме тестовата база до най-новата версия, проверихме и прехвърлихме необходимите промени и запазихме получената конфигурация. Сега го качваме в cf файл и го зареждаме в работещата база данни. Преди да изтеглите, трябва да направите копие на работещата база данни и да премахнете конфигурацията от поддръжката. ВСИЧКО. Потребителите бяха "бездействащи" само в началото, когато разтоварихме базата данни и в края, когато отново разтоварихме базата данни и заредихме конфигурацията.

Тази актуализация е напълно завършена.

Оригиналната статия е на уебсайта

Актуализирането на нестандартна платформа е много трудно. Ще разгледаме как да актуализираме нестандартна конфигурация на 1C и ще опишем стъпка по стъпка решение на възникващи трудности.

Как да актуализирате в нестандартна 1C конфигурация.

Общи понятия

При актуализиране на нестандартна платформа промените винаги засягат елементи от стандартната конфигурация на доставчика.

Базата данни (DB) съдържа до три типа конфигурации:

• самата база данни - с нея работят логически алгоритми;
• работещ (т.нар. основен, ConfigOR) – който периодично променяме;
• конфигурация на доставчика (ConfigP - въз основа на него, както работната, така и конфигурацията на базата данни се създават от потребителя.

Ако дадена програма бъде изключена от поддръжката, тя вече няма да бъде достъпна от доставчика. Тогава обаче увеличението на разходите за труд за актуализиране е неизбежно. Нека помислим за актуализиране на нестандартна 1C конфигурация. Пример може да бъде платформата PPM (Manufacturing Enterprise Management).

Смесване

Първата стъпка е да премахнете разликите между работещите и доставените конфигурации. Това ще намали оценката на направените преди това подобрения. Несъответствия между тях възникват, когато се използва актуализацията външни файлове(не от предоставената дистрибуция) или методите за актуализиране се различават от стандартните.

Сравнение на версиите

Проверяваме номерата на версиите (работещи и доставени). Първият се маркира в “Конфигурация” / “Отвори” / “Редактиране” / “Свойства”. В секцията „Разработка/Версия“. Второ в „Конфигурация“ / „Поддръжка“ / „Настройки за поддръжка“ / „Версия“:

Ако числата съвпадат, можете да преминете към раздела Получаване на файл чрез актуализация.

Следващите стъпки показват как да съпоставите работната конфигурация и конфигурацията на доставчика. За да поставите на поддръжка онези обекти, които са премахнати или добавени от потребителя без поддръжка. За това:

Запазване на конфигурацията (работи)

Нека запазим ConfigOR във файл с име, например work.cf. За да направите това, изберете “Конфигурация”/“Запазване...”.

Извличане на файла на доставчика

За да комбинирате ConfigOR с ConfigP, имате нужда от cf файл от комплекта за разпространение на доставчика (от същата версия). По подразбиране ще бъде в C:/Program Files/1cv81/tmplts. Нека проверим наличието на необходимия cf файл в таблицата с шаблони. Какво да направите, ако не желания файлнеобходима версия на конфигурацията на доставчика? След това трябва да създадете празна база данни от старата, да я актуализирате до необходимата версия и едва след това да я използвате.

Получаване на файл чрез актуализация

За да извършите актуализация на ConfigP cf файла, изберете командата от менюто: “Конфигурация/Поддръжка/Актуализиране.../Избор на файл/Край/Изпълнение” (Поредно на снимките):

За да разрешите това, трябва да премахнете отметката от знака за изтриване от обекта в конфигурацията на доставчика. След това, след изтриване, извършваме сравнението отново - щракнете върху бутона „Актуализиране“ в прозореца за актуализиране.

Възстановяване на настройките

Някои от загубените настройки се възстановяват чрез обединяването им с предварително запазения файл work.cf. За да направите това, изберете „Конфигуриране/Сравняване, обединяване... файлове“.

Запазване и коригиране

За да запазите ConfigOR и да актуализирате базата данни, в елемента от менюто „Конфигурация“ изберете „Актуализиране...БД“. Тук срещаме нов проблем:

Най-вероятно причината за това е, че тези обекти са били копирани от ConfigP или са били изтрити от доставчика, а по-късно са добавени нови под същите имена. Но с различни идентификатори. В резултат се появиха обекти със същото име, но с различни идентификационни ключове.

Ролите могат просто да бъдат изтрити, тъй като не са били променени. Атрибутът трябва да бъде преименуван, например на OrderReserve1. И след актуализиране въведете стойностите от преименуваната в създадената. Друга ситуация по време на актуализацията. Ами формулярите?

От фигурата можете да видите, че формулярът за списък е изтрит от доставчика и след това добавен отново под същото име. Трябва да маркирате и двете за актуализация и да щракнете върху „Изпълни“.

Ако по време на актуализацията се издаде съобщение за наличието на връзки към обекти за изтриване, тогава, без да затваряте формуляра, трябва да изчистите връзките към него в свойствата на самите обекти. Ето го в регистъра имоти. След това във формуляра за актуализиране изберете опцията за актуализиране, маркирайте свойствата на системния регистър за актуализиране сега и щракнете отново върху „Изпълни“.

Запазване на промените в работещата база данни и актуализиране на конфигурацията на базата данни: “Конфигурация/Актуализация...БД”. Стойността на атрибута OrderReserve1 се прехвърля към OrderReserve външна обработка 1C: Корпоративен режим.

Подготовка на основи

Въз основа на резултатите от информацията изготвяме две идентични бази данни. Първият (основният) е желаният от нас резултат. Втората (спомагателна) е за извършване на подготвителни действия. В случай на файлова версия, ние просто ги копираме в директория и ги свързваме към списъка за сигурност на информацията с опцията клиент-сървър, извършваме качване/изтегляне;

Сравнение

След като отворим двете бази данни с конфигуратора, ще извършим тристранно сравнение между тях. За целта използваме новия файл ConfigP - „Конфигурация/Поддръжка/Актуализиране…/Избор на файл…/Готово“:

Сравняването на работещите, старите и новите конфигурации на доставчика ни дава списък с променени обекти с помощта на филтъра „Показване на два пъти променени свойства“. Първо трябва да разрешите проблема с тях:

В този момент работата със спомагателната база данни е спряна, докато не приключи целият процес; вече не натискаме бутона „Изпълни“. Нека да преминем към работа в основната база данни с получения списък с два пъти променени обекти. Съгласяването с актуализацията ще доведе до загуба на направените преди това подобрения. Следователно за всеки от обектите е необходимо да се вземе решение как ще бъде променен.

Ще направим предварителна оценка само за да намалим бъдещата работа. Ако има повече промени в елемента, съдържащи се в новия ConfigP, оставяме обекта доставчик. Поставяме отметка. Прехвърляме промените от ConfigOR. Ако има повече промени в даден елемент в работната конфигурация, оставяме екземпляр на обекта ConfigOR. Махнете отметката от квадратчето. Нека прехвърлим промените от ConfigP. Модулите трябва да се сравняват процедурно. За да направите това, натиснете бутона, както е на фигурата:

Отбелязваме квадратчетата, за да посочим процедурите и функциите, които трябва да бъдат заменени или премахнати:

Сега трябва да дублирате състоянието на квадратчетата за отметка в спомагателната база данни. В основния щракнете върху „Изпълнение“. В този момент в основни линии получаваме почти готова конфигурация.

Последващите сравнения се извършват отново в спомагателната база данни. Намираме направени по-рано промени чрез допълнително сравняване на стария ConfigP с ConfigOR - „Конфигурация/Сравнение...“:

По подобен начин сравняваме стария ConfigP с новия. Ако няма нов файл, сега можете да го вземете от основната база данни.

Така се получават два пъти модифицирани обекти. Получи се почти готова конфигурация в основната база данни. В него трябва да се справите с два пъти променени елементи.

ВАЖНО.

Когато анализира, потребителят трябва да се интересува не от причините за извършване на определени промени, а от техните последствия. Тоест основното е необходимостта от поддържане на функционалност. Може би това ще изисква не прехвърляне на променените редове, а пълно преработване на кода за новия ConfigP.

За да вземете решение, е достатъчно да сравните формуляри, таблици и обектни модули. Понякога данните в отчетите се представят във форма, която не позволява бързо вземане на решения. На тази стъпка загубата на модификации възниква, ако промените засягат детайли на обект от съставен тип.

Намаляването на интензивността на труда се постига чрез използване например на конфигурацията „Cell Comparison“ от компанията Inform Service. Той е достъпен за стартиране в режим 1C:Enterprise и представя сравнителни отчетни данни в удобна форма. Сравнението се извършва с помощта на възможностите на 1C:

Схемата на работа е проста. В конфигуратора се създава отчет за сравнителен обект. Записан във файл, например Comparison Report.mxl. В диалоговия прозорец на 1С:Предприятие се отваря и се посочват клетките, които се сравняват (чрез двойно щракване с десния бутон на мишката върху избраната клетка документ с електронна таблица). Чрез щракване върху „Сравнение“ се дава резултатът от сравнението, като различните позиции са маркирани в цвят.

Допълнителни инструкции за действие изглеждат така.

1. Следващият отчет се записва със същото име.
2. След приключване на актуализацията и прехвърляне на модификации в стандартната конфигурация се извършва синтактичен контрол на модулите и тестване на работата на променените обекти.
3. След успешно тестване процесът може да се счита за завършен. Остава да се актуализира печатни форми, отчети и обработка. В някои случаи проверете външни формуляри за докладване.

Работим с 1C 7.7

Актуализирането на стандартна платформа до същата обикновено не създава затруднения. Просто трябва да следвате инструкциите в инструкциите. Те се намират в UPDATE.TXT на директорията за разпространение.

Също така няма трудности, ако допълнителни елементисчетоводство (справочници, константи, селекции, отчети, регистри, калкулационни дневници и др.). Те ще паснат, когато платформите се комбинират. Добавените документи също няма да причинят дисхармония, ако няма промени в характеристиките за въвеждане „на базата“ на такива добавени документи.

Препоръчително е да извършите актуализация на бърз компютър с голямо количество RAM. Ако липсва, 1C може да откаже да изработи някои от функциите и да замръзне. Голям обем виртуална паметне решава този проблем.

Създаване на резервно копие

За целта е необходимо да използвате опцията: “Администриране/Запазване на данни...”. Удобно е да посочите името на архива, като го комбинирате с датата на създаване (например YYMMDD.zip).

Изготвяне на каталози

За да работите, ще ви трябват шест конфигурационни файла (1cv7.md):

1. “WorkingNew” за подготовка на актуализацията (резултатен md-файл);
2. „WorkingOld“ за проследяване на промените по време на сравнение и за прехвърляне на настройки към TypeNew_2;
3. Типичен (стар) “TypeOld_1”. На негова основа преди това е създаден работещ.
4. Видове. (бивш) "TypeOld_2". За проследяване на промените в компанията 1C в новата стандартна версия;
5. Тип. (ново) "TypeNew_1". Подобрения от 1C в новата версия;
6. „TypeNew_2“ за сложни обекти.

И пет работещи конфигуратора (всички с изключение на „TypeNew_1“).

Първоначално директориите са идентични по двойки:

• “WorkerNew” и “WorkerOld”;
• "TypeOld_1 и TypeOld_2";
• „TypeNew_1“ и „TypeNew_2“.

Комбиниране на елементи

Първо правим сравнение между 3 и 2, 4 и 5, 1 и 6. За да направите това, за всеки от първите в двойката изберете елемента „Конфигурация / Обединяване ...“ и посочете файла с метаданни 1cv7. md на втория в двойката. На екрана ще се покаже форма с дърво с променени елементи. След това е необходимо да се анализират резултатите от сравнението по двойки на 3 с 2 и 4 с 5. Оставете за обединяване на елементи в актуализираните платформи (1 и 6), в които имаше промени от 1C (4 с 5), но не са отразени в 3 и 2. 1 и 4 трябва да се комбинират в режим на заместване.

други

Това може да включва сметкоплан и потребителски интерфейси. Ако има промени в сметкоплана, тогава той трябва да се актуализира в режим „Комбиниране на обекти“ WorkNew заедно с TypeNew_2. След комбиниране на интерфейса се проверява наличието на грешки: дублиране на елементи от менюто, дублиране на ленти с инструменти, настройка на флаговете „Оформление на нов ред“ за ленти с инструменти.

Изтеглянето се извършва по мрежата или на сървър (за предпочитане). Първо, предоставя се изключителен достъп до базата данни. След това базата данни се зарежда в режим на конфигуратор. Преди и след изтеглянето данните се архивират (както е описано в самото начало на раздела). След това трябва да следвате инструкциите във файла UPDATE.TXT. След като изтеглянето приключи, всички директории с изключение на WorkNew могат да бъдат изтрити.

Надяваме се, че нашата публикация ви помогна да разберете актуализирането на нестандартна конфигурация на 1C. Разгледахме това по отношение както на седмата, така и на осмата версия.

Оставете коментари, пишете за опита си в актуализацията на 1C.

Софтуерните продукти 1C са специфични в смисъл, че тяхната работа е силно повлияна от законодателството на страната, в която се използват тези програми. Ето защо е много важно да можете да актуализирате тези продукти, тъй като в допълнение към правните проблеми актуализираните конфигурации ще съдържат корекция критични грешки, ускоряване на цялата програма и други полезни подробности. Има два варианта за развитие на събитията: първият вариант е актуализиране на стандартната (стандартна) конфигурация, което се случва доста бързо и не изисква много усилия, докато вторият вариант, когато трябва да актуализирате модифициран монтаж, е по-дълъг и по-сложен.

Определяне на типа конфигурация

Обикновено потребителят знае точно каква версия има, тъй като стандартната компилация се характеризира с липса на намеса във вътрешните обекти на програмата. Друго нещо е, че модификацията, като правило, се извършва от програмисти; съответно потребителят получава вече модифициран продукт, за който може дори да не знае. Има лесен начин да разберете дали там са направени промени или не. За да направите това, ще трябва да влезете в режим Конфигуратор, съответният бутон за който е в началния прозорец на програмата. В горната част има раздел Конфигурация, в който има елемент Поддръжка. След като щракнете върху него, трябва да изберете Настройки за поддръжка. IN отворен прозорецБутонът „Активиране на възможностите за модификация“ също трябва да е активен, знак за стандартна сглобка е наличието на икона за заключване до името на сглобката. Тези знаци показват, че програмните модули не са променени, което означава, че можете да извършите централизирана актуализация от официалния уебсайт през Интернет. При липсата на тези признаци може да се твърди, че програмистът е работил върху редактирането на този продукт, докато е възможна ситуация, когато модификацията е частична, т.е. редица обекти са оставени в оригиналната им форма. Всички модифицирани обекти остават без идентификационни икони, а стандартните елементи са маркирани с жълто кубче. Частичната модификация не премахва напълно програмата от поддръжка, тъй като ще бъде възможно да се актуализират недокоснати обекти.

Стандартна (типова) конфигурация - подготовка за актуализация

В допълнение към посочените проблеми, като промени в законодателството или влошаване на работата на програмата, трябва да я актуализирате, когато програмата 1C издаде съответното съобщение. Ще пише, че тази компилация е пусната преди известно време, сега има подобрена конфигурация и че може да се актуализира точно сега чрез уебсайта или с помощта на ITS диска. Като начало е много важно да се направи резервно копиебаза, за да може всичко да се възстанови, ако нещо се обърка. Това става по три начина. Можете просто да копирате основна папкас основата на диск или флашка. След стартиране на 1C се избира база данни и пътят до нея ще бъде посочен в прозореца. В случай на проблеми тази папка се премества на мястото на неработещата база данни. Можете да работите и през конфигуратора, за което трябва да изберете този режим в програмата. В секцията Администриране има бутон Качване на информационна база. След като изберете папка, там ще се появи .dt файл, който впоследствие може да бъде отворен със съответния бутон в същата секция.

Третият метод се появява малко по-късно, на етапа на актуализиране през интернет. Всичко може да се направи чрез ITS диска, който се получава от предприятието всеки месец; можете да вземете този диск и от служител, който има споразумение с ITS, само трябва да сте сигурни, че конфигурациите съвпадат. Иначе всичко става през интернет. Има важен нюанс: пакетите за актуализация се инсталират строго последователно и ако някоя версия е пропусната, системата ще изисква първо да ги инсталирате. съдържащ се в менюто Помощ, където ще трябва да щракнете върху секцията Информация.
Ако всичко е наред с интернет, тогава трябва да отидете на уебсайта usersv8.1c.ru, където въведете вашето потребителско име и парола. След това изберете необходимите конфигурации, разположени на връзката Изтегляне на актуализации. Следващата стъпка е да изберете конкретни версии, като вземете предвид първите и тези, които са пуснати наскоро. Всички файлове се записват един по един на компютъра. Преди да актуализирате, трябва да отворите всички архивни файлове и да инсталирате всяка версия. Изданията могат да бъдат изтеглени, както е описано, от ITS диска. Сега трябва да влезете в режим Конфигуратор, след което обектите трябва да се покажат отляво; ако те не са там, тогава ще трябва да щракнете върху раздела Отваряне на конфигурацията.
За да актуализира, потребителят отива на конфигурация Configuration-Support-Update configuration. В новия прозорец щракнете върху Търсене.

От предложените опции изберете Търсене в текущи каталози с актуализации, след което посочете наличната версия или тази, чието име ще бъде маркирано с удебелен шрифт. Трябва да щракнете върху Да върху всички други предложения, включително последния прозорец за реорганизиране на информация. Последната стъпка е да стартирате програмата в производствен режим, за да влязат в сила актуализациите.

Актуализиране на нестандартна (модифицирана) конфигурация на 1C

Смисълът на актуализирането на модифициран асембли е да се гарантира, че направените от програмистите промени не се губят и промените, направени от разработчиците, влизат в сила. Всички изброени стъпки, описани в предишните инструкции, се изпълняват този път, само на последната стъпка ще се появи таблица за сравнение, където в една колона ще има конфигурация с модифицирани обекти, а във втората колона ще има списък с актуализации. Тези колони съдържат дървета с метаданни. Със зелен маркер програмата ще маркира кои конкретни обекти програмистът прави корекции и кои са променили разработчиците на продукта. На на този етаптрябва да намерите онези обекти, които са отбелязани в тези две колони.

За да опростите търсенето си, можете да използвате бутона Филтър, който се намира най-долу, след което да поставите отметка на опцията Показване на два пъти променени свойства. Ако всичко е направено правилно, тогава в работния прозорец ще бъдат показани само обектите, от които се нуждаем. Процедурата за актуализиране на нестандартни модули няма да повлияе на конфигурацията.

Трябва да анализираме тази таблица. В този случай е ясно, че са настъпили промени и в двата случая, тъй като има икони с молив, тъй като има и икона до името на модула, това означава, че те ще бъдат обединени. Последната колона вдясно показва, че когато процесът приключи, целият потребителски код ще бъде променен в полза на актуализацията от разработчиците.

Има и други режими с частично сливане (приоритет), но тези режими се използват от опитни потребители, тъй като начинаещият ще превърне всички разработки в объркващи модули. Съответно няма смисъл да променяте нищо в последната колона. От друга страна, като премахнете отметката от първата колона, принудителното сливане може да бъде отменено. Въз основа на това можете или ръчно да въведете кода в актуализирания модул, или да оставите кода сам и ръчно да направите самите актуализации. За да разберете какво точно трябва да се добави, щракнете с десния бутон върху избрания модул и изберете Показване на разликите. Тази стъпка ще покаже разликите в конкретните процедури. В долната част на прозореца също има разделение на две колони, но самият код вече е показан там.

По-нататъшните действия зависят от нивото на промяна в модулите; ако конфигурацията е била радикално пренаписана, тогава ще бъде изключително трудно да актуализирате всичко сами, без помощта на програмист.

Възможно при актуализиране на 1C

Повечето грешки се правят, когато базата данни е силно модифицирана, тъй като няколко страници код, различни справочници и други обекти могат да объркат неопитен потребител. Много е важно да създадете и запазите архив, преди да правите промени. възстановяване на резервно копие, след което се уверете отново, че всичко е направено правилно. Класическа грешка е актуализирането на нестандартна сглобка, сякаш е стандартна. Но дори и да следвате описаните инструкции, далеч не е факт, че програмата веднага ще работи както трябва. Вероятно без допълнителни настройкине достатъчно. Конфигураторът не показва промените, направени в контролите на диалоговите форми, така че тази точка ще трябва да се провери ръчно, в противен случай всички актуализации ще бъдат презаписани. След актуализиране конфигураторът може да забрани актуализирането на старата информационна база, тъй като номерата на документите вече не са уникални, същото важи и за информационните регистри.

За да разрешите проблема, ще ви трябва:
— промяна на броя на знаците в кодовете;
- промяна на кодовете в информационна база;
— промяна на свойството за контрол на уникалността във всички директории.

По време на процеса на актуализиране не трябва да забравяме актуализирането на интерфейсите и потребителските права, което често се пренебрегва. Значението на последователното обновяване на изданията вече е описано; също така е изключително важно да използвате вградена обработка на актуализации на конфигурацията, която ще ви позволи да конвертирате необходимите данни и да попълните базите данни с информация, ако е необходимо. В интерес на потребителя е да гарантира, че вътрешните идентификатори на обекти или детайли съвпадат, в противен случай актуализацията може да презапише всички разработки. Дори след внимателна подготовка на нова конфигурация, не можете веднага да преминете към комбинирането й с използваната работна база, тъй като тя също трябва да бъде актуализирана и след това всичко трябва да бъде щателно тествано.

Трябва да разберете, че има опции, когато конфигурацията ще бъде върната за поддръжка, тоест процесът на актуализиране ще се извърши в стандартен режимза програмата, чрез изтегляне на изданието в Интернет. Програмата се премахва от поддръжка след въвеждане на модифицирани модули в продукта. Премахването на тези модули ще върне програмата към първоначалното състояние, но е невъзможно напълно да се отървете от тях, тъй като нормална операция 1C ще бъде невъзможно, защото по някаква причина модулите са програмирани с това. Съответно тези модули могат да бъдат преместени извън обхвата на програмата - работата ще се извършва с помощта на външни модули, но това няма да повлияе на работата на програмата. По този начин директориите и другите обекти ще останат на мястото си. Да направите това сами без необходимите познания е проблематично, така че програмистът трябва да върне програмата към стандартната асемблирана рамка, ако е необходимо.

Има и няколко съвета за улесняване на процеса на актуализиране в бъдеще. софтуерни продукти 1C. На първо място, трябва да се опитате да модифицирате програмата възможно най-малко и освен ако това не е абсолютно необходимо, тогава не въвеждайте там нищо трето лице, а се опитайте да разрешите проблемите със стандартните инструменти, които са налични. Без изключение всички промени в конфигурацията трябва да бъдат коментирани и записани в отделен документ, така че нищо важно да не бъде пропуснато по време на процеса на възстановяване. До обем програмен кодв стандартните обекти е намален, трябва да се премести в собствения си общ модул, трябва да разберете, че извикванията на процедури и функции не могат да се пипат - те трябва да останат в стандартни обекти, за да може програмата да работи правилно. За целите на оптимизацията има смисъл да се заменят всички извиквания на стандартни процедури и функции, които се намират както в „самонаписания“ код на обекти, така и в кода на външни модули, с извиквания на процедури от собствен модул. Тези процедури са прост пряк път, който ще се използва за извикване на процедури от стандартни модули. По този начин, когато сравнявате промените, потребителят няма да трябва да търси необходимите редове в модифицирания код дълго време. Ако следвате тези препоръки, времето за актуализиране се намалява до няколко часа работа и ако всичко се остави както е, процесът може да се проточи няколко дни.

Инструкции

Изберете две бази данни - работеща и нейно копие. В последния покажете промените, които го отличават от стандартната програмна конфигурация, която е налична, когато започнете да работите с програмата след инсталирането й.

Създайте .cf файл, тъй като уебсайтът на производителя предоставя на потребителите само .cfu файл. Ще ви трябва, за да завършите следващата стъпка, която е пряко свързана с актуализирането на променената конфигурация.

В работната база данни отидете в менюто „Поддръжка“, след това щракнете върху елемента „Актуализация на конфигурацията“, изберете създадения преди това .cf файл. В прозореца за сравнение на копия на база данни, който се показва, премахнете отметките от квадратчетата, които наскоро сте актуализирали.

Сравнете и консолидирайте данни с помощта на менюто Поддръжка. В опцията „Настройки за поддръжка“ ще има поделемент „Сравняване и обединяване“. Моля, обърнете специално внимание, че в този случай трябва само да сравнявате и обединявате данните, без да поставяте отметки в квадратчетата. Тази операция е необходима само за целите на установяване на ред и идентифициране на последователността от обекти в текущата конфигурация с реда и последователността на обектите, разположени във файла за актуализиране.

След това отидете отново до същите елементи от менюто в „Поддръжка“, изпълнете отново операцията „Сравняване и обединяване“, точно както последния път. Извършете работа върху обекти, анализирайте резултатите, сравнете идентифицираната работеща база данни от копието и в копието на базата данни посочете точно онези елементи, които са били променени. Мигрирайте промените от новата конфигурация на доставчика. Запазете промените, като натиснете клавиша F7.

Повторете горните стъпки няколко пъти, преди да започнете да работите с реални производствени бази данни. Не забравяйте, че колкото повече пъти преминете през тази последователност, преди да започнете да работите директно с данните, които са важни за вас, толкова по-добре.

Забележка

Конфигурационните обекти, които сте добавили, не могат да бъдат променени;

Полезен съвет

Практикувайте актуализиране на копия; не започвайте работа без определени умения.

Има стандартни и нестандартни конфигурации за приложението 1C: Enterprise. Стандартната конфигурация се пуска от разработчика и се използва от крайния потребител в оригиналната си форма, докато нестандартната конфигурация може да бъде написана от нулата или модифицирана въз основа на стандартната.

Инструкции

Определете коя конкретна конфигурация на програмата 1C: Enterprise е инсталирана на вашия компютър, тъй като методите за актуализиране на конфигурацията ще бъдат различни. Ако използвате стандартна конфигурация, просто трябва да изпълните действието „Зареждане на модифицирана конфигурация“. Ако сте собственик на програмата, следвайте тези стъпки.

Подгответе следните обекти за актуализация на конфигурацията. Първо, трябва да имате инсталирана самата конфигурация. Второ, намерете типичната конфигурация на версията, която използвате. Трето, ще трябва да намерите типичната конфигурация на най-новата версия на версията, която трябва да получите в резултат на актуализацията. Четвърто, направете копие на вашия конфигурационен файл инсталирана версияпрограма "1C: Enterprise".

Обновяването на нестандартна, силно модифицирана конфигурация е много трудоемка и отговорна задача. Обикновено се извършва актуализация на изданието за конфигурации, съдържащи блок от регулирано отчитане. Например, .

Нека да разгледаме най-лесния начин да направите нестандартна актуализация без грешки, използвайки конфигурацията на 1C Enterprise Accounting като пример.

Началото на всяка актуализация е описано в статията. Ще разгледаме само най-важното - нюансите на нестандартна актуализация.

Малко теория за нестандартните конфигурации:

• Неподдържаната конфигурация съдържа 2 конфигурации: конфигурацията на базата данни и основната конфигурация.
• Поддържаната конфигурация без възможност за редактиране съдържа 2 конфигурации: конфигурацията на базата данни и основната конфигурация (известна още като доставчик).
• Поддържаната конфигурация с възможност за промяна вече съдържа 3 конфигурации: конфигурацията на базата данни, основната конфигурация и конфигурацията на доставчика.

1. Подготовка за актуализация

Преди да започнете, уверете се, че конфигурацията на доставчика съответства на основната конфигурация - това значително ще улесни персонализираната актуализация. Ако конфигурацията на доставчика има повече от по-ранна версия, което означава, че преди това конфигурацията е била актуализирана неправилно. Можете да актуализирате версия на доставчик, като стартирате актуализацията една по една и без да избирате един обект за сравнение.

Първо, внедрявам 2 бази данни с първоначалната конфигурация. Едната за смяна, втората за сравняване с новата.

Вземете безплатно 267 видео урока за 1C:

Ако вашата конфигурация не е стандартна, след като щракнете върху бутона „актуализация“ в конфигуратора, системата ще започне да сравнява основните и новите конфигурации на доставчика:

Външно изглежда, че голям брой обекти са се променили. Но нека си представим ситуация: Променили сте документ, но той не се е променил – трябва ли да го актуализирате ръчно? Разбира се, че не. За да изберете такива обекти след сравнение, не забравяйте да щракнете върху бутона Филтъри поставете отметка в квадратчето

След филтриране виждаме, че има много по-малко променени обекти:

Получихме списък с обекти, по които ще работим. В нашия случай имаше само един сложен обект - документът RecordKUDiR.

2. Прехвърляне на промените в актуализацията на 1C

За да прехвърля промените, отварям 2 конфигуратора - в единия правя сравнения и правя промени, а във втория правя модификации.

Следващият етап е същинското прехвърляне на промените. Нека да разгледаме основните техники за актуализиране на нестандартни конфигурации.

3. Разлики в модулите

Доста проста, но много отговорна операция - просто прехвърляме модули от новата версия към старата. Ако кодът е коментиран, тогава не би трябвало да има проблеми:

4. Сравнения на форми и оформления

Тук процесът е много по-сложен. Трябва да уловите и най-малките промени във формулярите. Препоръчвам да генерирате подробен отчет за разликите с графично представяне:

След като сте прехвърлили всички промени в обекта от новата конфигурация, стартирайте сравнението и обединете отново, като премахнете за сравнение обектите, които сте променили ръчно.

Нетипичната актуализация на модифицираната конфигурация на 1C е завършена!

Забележка!Ако не знаете как да програмирате в 1C 8, шансът за успешно актуализиране на нестандартна конфигурация е изключително малък. Ще загубите много време и ще се окажете с конфигурация, която дори не стартира. Препоръчвам да се свържете за бърза помощ.