Оновлення нетипової конфігурації. Правильне доопрацювання типових конфігурацій Завантажувана конфігурація є нащадком основної

Розглянемо оновлення на прикладі нетипової конфігурації УПП 1.3, що знаходиться на підтримці з можливістю зміни з релізу 1.3.61.2 на реліз 1.3.62.1. Оскільки зміна як така досить важка, це накладає деякі особливості, зокрема, який завжди вдається відкрити одному конфігураторі кілька вікон порівняння конфігурації.

Для оновлення використовую дві однакові копії бази даних старого релізу. В одній із них виконую підготовку *.cfдля оновлення, назвемо її, наприклад, for_updating. Інша база залишається не порушеною і служить лише як допоміжна, для порівняння змін, назвемо її base. В принципі, як допоміжна може використовуватися конфігурація робочої бази.

В базі for_updatingвиконуємо *.cfuнового релізу. Починається процедура оновлення, в результаті якої з'являється вікно оновлення.

Натиснути кнопку " Виконати», цьому етапі немає поки необхідності щось дивитися, оскільки метою лише отримання зміни постачальника нового релізу.

У процесі оновлення може з'явитися вікно. Нерозв'язні посилання», натискаємо « Продовжити». Про причини появи цього вікна поговоримо нижче.

З'явиться повідомлення про те, що змінені нами об'єкти будуть завантажені з нової конфігурації, погоджуємось.

Відкриється вікно Налаштування правил підтримки» - для нових об'єктів (верхній розділ) по обидва боки ставимо « Об'єкт редагується із збереженням підтримки», для існуючих об'єктів постачальника (нижній розділ) у всіх чотирьох місцях ставимо прапор « Зберігати поточний режим», натискаємо « ОК».

Відбулося оновлення основної конфігурації. Сама собою основна конфігурація цьому етапі нам не потрібна, мета - отримання нової конфігурації постачальника. Тому основну конфігурацію не зберігаємо, конфігурацію бази даних не оновлюємо.

Виконуємо « Конфігурація» - « Підтримка» - « Налаштування підтримки». У вікні вибираємо « Зберегти у файл» і зберігаємо в *.cfконфігурацію постачальника нового релізу.

Основна конфігурація в тому вигляді, в якому вона зараз є, нам не потрібна. Закриваємо конфігурацію. « Конфігурація» - « Закрити конфігурацію». Відмовляємось від збереження змін.

У конфігурації для порівняння baseзапускаємо порівняння конфігурації постачальника (старий реліз) та конфігурації постачальника з файлу (новий реліз).

Таким чином, ми побачимо ті зміни, які будуть виконані в конфігурації при оновленні на новий реліз.

В базі for_updatingзнову запускаємо оновлення конфігурації через підтримку "Конфігурація" - "Підтримка" - "Оновити конфігурацію", у вікні вибираємо *.cfuнового релізу. Починається процедура оновлення, в результаті якої з'являється вікно оновлення.

При натисканні на кнопку « Фільтрвідкриється вікно Налаштування фільтрів перегляду». У цьому вікні встановлюємо прапор « Показувати лише двічі змінені властивості».

При оновленні без нашого втручання відбувається таке:

• - об'єкт не змінено нами, змінено у новому релізі - оновлюється з нового релізу;
• - об'єкт змінено нами, не змінено у новому релізі - залишається наш об'єкт;
• - Об'єкт змінено нами, змінено в новому релізі - це і є двічі змінений об'єкт, якщо нічого не змінювати - він завантажиться з нового релізу.

Таким чином, найбільшу увагу слід приділити саме двічі зміненим об'єктам, їх і будемо розглядати.

У цьому прикладі змінено кілька загальних модулів, у тому числі й загальний модульОблік ПДВ».

За замовчуванням у вікні оновлення відображаються відмінності основної та нової конфігурації постачальника від старої конфігурації постачальника.

Якщо розглянути відмінності конфігурацій у загальному модулі « Облік ПДВ», то ми побачимо наступну картину:

Якщо ж порівняти ці модулі в базі для порівнянняbase, То картина буде інша:

Очевидно, що функції « ЗібратиДаніДляДрукуВиправленняРахункиФактури», « ЗібратиДаніДляДрукуКоригувальногоРахункуФактури» та інші містять наші доробки, але не змінюються при оновленні, а отже, немає сенсу витрачати час на їх перегляд та аналіз.

Тому, виконуючи процедурне оновлення з виділених процедур і функцій можна зняти прапори:

Багато хто скаже, що побачити відмінності старої конфігурації постачальника від нової можна за допомогою зміни налаштування фільтрів перегляду в поточному конфігураторі, не використовуючи порівняння конфігурацій у базіbase.

Наприклад, так:

Однак, як показує практичний досвід це не так, процедури та функції все одно відображаються у вікні порівняння модулів, навіть при встановленому фільтрі. показувати відмінності нової конфігурації постачальника від старої конфігурації постачальника».

Зробивши невелике уявне зусилля, виявимо двічі змінені процедури та функції, тільки вони потребуватимуть доопрацювань після процесу об'єднання. З цими процедурами та функціями потрібно визначитися, що легше:

• - або взяти процедуру чи функцію з нової конфігурації постачальника і потім, після об'єднання, зробити наші доробки;
• - або зняти прапорець оновлення, тим самим зберігши наші доробки, і потім додати потрібний код з конфігурації постачальника.

Об'єднання з пріоритетом основної конфігурації та поєднання з пріоритетом нової конфігурації постачальника використовую рідко, в принципі і без використання даних режимів, результат вийде якісним.

Після того, як загальні модулі були проаналізовані і в частині процедур знято прапори оновлення, бачимо, що у модулів тепер встановлено режим об'єднання - індивідуальне налаштування:

Рухаємось далі. Серед двічі змінених об'єктів є форма елемента довідника. Основні засоби». Перш ніж визначитися чи оновлювати цю форму з нової конфігурації постачальника, необхідно з'ясувати, що за фактом змінюється під час оновлення.

Для цього у базі baseза допомогою контекстного меню викличемо « Звіт про порівняння об'єктів...».У вікні, що відкриється, повинні стояти всі прапори в групі «Об'єкти».

Мені подобається режим виведення звіту в табличний документ, коли відмінності показуються графічно, але це справа смаку.

В результаті порівняння форми елемента довідника Основні засоби» бачимо, що зміни є лише в модулі форми, а змін у діалозі форми в оновленні немає.

Але оскільки форма елемента потрапила в двічі змінені об'єкти, то наші доробки є або діалогом форми, або модулем.

Виконавши аналогічне порівняння у базі for_updatingможна побачити, що доробки є у діалозі форми.

Причина цього, додавання довідника. Основні засобиу план видів характеристик « ВластивостіОб'єктів». Якщо оновити форму елемента довідника Основні засоби» ми отримаємо посилання, про що і буде свідчити вікно:

В даному випадку найкращим варіантом буде не оновлювати форму елемента довідника. Основні засоби» і потім додати необхідний код в модуль форми елемента. В цьому випадку вікно Нерозв'язні посилання» при оновленні не з'являтиметься.

Зробимо відступ і уявимо, що діалог форми елемента довідника Основні засоби» Змінюється при оновленні на новий реліз, тоді найкращим варіантом було б оновлення форми. Вже потім, після об'єднання, потрібно було б додати у форму наші зміни, як модуль, так і діалог. Якщо у модулі багато наших доробок і мало від постачальника, то після об'єднання можна повністю повернути наш модуль та додати зміни до постачальника.

В цьому випадку в процесі об'єднання з'явилося б вікно. Нерозв'язні салаки». Варіантів вибору у цьому вікні два: 1) « Позначити все для об'єднання»; 2) « Продовжити».

На мій погляд, правильніше вибирати Позначити все для об'єднання».

І тут план видів характеристик « ВластивостіОб'єктів» буде додано як об'єкт для об'єднання в дереві у вікні, що відкрилося « Оновлення…»

Природно, що після оновлення у план видів характеристик ВластивостіОб'єктів» потрібно буде додати наші зміни, зробити це краще за допомогою порівняння та об'єднання з поточною конфігурацією.

Розглянемо, що сталося б, якби ми вибрали Продовжити" у вікні " Нерозв'язні посилання». І тут форма елемента довідника « Основні засоби» стала б новою, а план видів характеристик « ВластивостіОб'єктів» залишився б старим. У цьому випадку у нас затруться зміни у діалозі форми елемента довідника, а саме на сторінці « ВластивостіЗначення», дивись малюнок нижче.

Ця проблема теж не є непереборною, якщо звичайно про неї не забувати.

Звичайно, найкраще намагатися якнайменше вносити змін додіалоги форм , наприклад, створювати реквізити та кнопки на формі програмно.

Багато хто взагалі рекомендує не змінювати типові форми, а створювати їх копії з нашими доробками та робити їх основними. Мені цей варіант не подобається тому, що якщо постачальник додав щось у діалозі формі - на моїй формі це не з'явиться і мені доведеться робити додавання вручну, а змін постачальника може бути набагато більшим, ніж наших.

Окрему увагу хотілося б приділитипо процедурному оновлення форм (частину процедур беру з конфігурації постачальника, а частина ні - індивідуальне налаштування). Розглянемо, як за даному режимі відбувається оновлення діалогу форми на відміну режиму «взяти з конфігурації постачальника».

Приклад немає відношення до цього оновлення конфігурації, але показовий, тому розглянемо його.

Довідник « Контрагенти» додано кілька реквізитів, і вони розміщені на форму елемента.

У разі оновлення конфігурації на новий реліз через підтримку буде запропоновано вікно порівняння та об'єднання конфігурації, в якому можна зробити різні налаштування. Порівняємо кілька варіантів:

1. Прапор оновлення форми виставлено, але оновлення зробленопо процедурно , тобто. за фактом виконано індивідуальне налаштування

Багато хто думає, що діалог форми повинен взятися з конфігурації постачальника, а процедури в залежності від зроблених налаштувань. Подивимося, наскільки це після виконання об'єднання. Зробимо порівняння конфігурації постачальника з основною конфігурацією.

Вочевидь, що у формах порушилися прив'язки та інше, тобто. діалог форми не був повністю взятий із конфігурації постачальника. В даному випадку в діалозі форми залишилися наші об'єкти, з одного боку це добре, з іншого боку, розташування наших елементів на формі не завжди оптимальне, особливо у зв'язку з додаванням нових елементів постачальника, спостерігається зміна позицій обходу та порушення прив'язок. У деяких випадках легше вручну додати наші елементи до діалогу форми, ніж робити виправлення.

2. Прапор оновлення форми виставлено, оновлення зроблено як « Взяти з нової конфігурації постачальника»

У цьому випадку діалог форми елемента повністю приводиться у відповідність до діалогу форми елемента постачальника.

Повернімося до поновлення. З модулями об'єкта та модулями менеджера документів надаємо також як із загальними модулями, оновлюємо їх за процедурно. З формами документів чинимо аналогічно до того, як поводилися з формами довідників.

Окремо необхідно виділити роботу з ролями. Незважаючи на те, що в прикладі не потрібно оновлювати ролі, поговорити про це варто. Розглянемо найпростіший випадок, коли конфігурації постачальника міститься новий об'єкт. В цьому випадку потрібно оновлення ролі «Повні права», але ця роль може містити якісь створені нами об'єкти, наприклад, довідники, документи та інше.

Здається, що за участю « Повні права» все просто, об'єднуємо їх повністю, права на нетипові об'єкти збережуться у них однаково. Так і є права на нетипові об'єкти ніколи не пропадуть, але у всіх цих об'єктів буде включений прапор. Інтерактивне видалення», що не завжди добре. При порівнянні конфігурацій старого релізу та підготовленої нового релізу це добре видно:

З іншими ролями чинимо аналогічно тому, як ми працюємо з модулями - якщо наших змін більше, то не поєднуємо роль, після оновлення додаємо до неї те, що додав постачальник у новому релізі.

Після того як пропрацювали всі двічі змінені об'єкти у вікні оновлення, натискаємо « Виконати»

На питання, що змінені нами об'єкти будуть завантажені з нової конфігурації, відповідаємо ствердно.

У вікні « Налаштування правил підтримки» перевіряємо, чи встановлені прапори, хоча за умовчанням повинні стояти правильно, натискаємо « ОК».

Після закінчення процесу об'єднання зберігаємо основну конфігурацію, конфігурацію бази даних поки що не оновлюємо.

Тепер у конфігураціюfor_updatingдодаємо ті мінімальні доопрацювання, які не вдалося правильно оновити штатними засобами.

Щоб зручніше було проконтролювати виконання цього процесу, у базі baseзапустимо порівняння конфігурації постачальника та основної конфігурації старого релізу.

В базі for_updatingзробимо те саме. Контролюємо двічі змінені об'єкти, відмінностей не повинно бути.

Після того, як оновлення в базіfor_undatingбуде завершено оновлюємо конфігурацію бази даних і тестуємо деякі моменти, що саме добре протестувати стане зрозуміло в процесі оновлення, тут все індивідуально.

Оновлення у робочій базі бажано виконувати за допомогою підтримки"Конфігурація" - "Підтримка" - "Оновити конфігурацію".У цьому двічі змінені об'єкти будуть завантажені з нового релізу, тобто. наші зміни затруться (конфігурацію не зберігаємо!), але при об'єднанні з підготовленою конфігурацією ми їх відновлюємо. Після цього можна зберегти конфігурацію та оновити конфігурацію бази даних.

У цій інструкції нетипового оновлення зміненої 1с 8.3 я не описуватиму базові речі, такі як: як відкрити конфігуратор, що таке конфігурація БД, конфігурація постачальника та основна конфігурація. Про це і там багато написано і ви можете самостійно знайти цю інформацію на просторах інтернету. Я намагатимусь описати основні моменти процесу оновлення та на що потрібно звернути увагу.
Я взяв наприклад нетипову бухгалтерію 3.0.51.22 і покажу як оновити її до версії 3.0.53.29. На платформі версії 8.3.10.2561 (немає великої різниці на старіших платформах, просто раніше віконце порівняння виглядало трохи інакше).
Скажу відразу, буде багато картинок та мало тексту. Вважаю, що візуально простіше запам'ятовувати процес, ніж читати море тексту.

1. Перевірити відповідність конфігурації БД та конфігурації постачальника.

Для цього вам потрібно

При збігу можете сміливо переходити до пункту 2.

1а. Налаштування конфігурації на підтримку.

Якщо у вас відрізняються версія БД та версія конфігурації постачальника, то вам потрібно видалити поточну конфігурацію через те саме меню: конфігурація – підтримка – налаштування підтримки. І натиснути кнопку "Зняти з підтримки".

Після недовгого очікування знімаємо всі галочки. Ну і можна забрати галку «Зберігати налаштування автоматично». І тиснемо виконати.

В результаті ми отримаємо конфігурацію на підтримці з однаковими версіями бази даних.

2. Відновлення бази.

Тепер можна перейти до оновлення.

Скажу відразу оновлення робити потрібно ТІЛЬКИ через меню "Конфігурація" - "Підтримка" - "Оновити конфігурацію ...".
Використовувати "Порівняти, об'єднати з конфігурацією з файлу ..." НЕ МОЖНА!!!Якщо ви використовуєте цей механізм, вам доведеться переходити до пункту 1а при наступному оновленні. Тому давайте не будемо так робити і створювати собі (або тому, хто наступного разу оновлюватиме базу) зайві проблеми.

Далі вибираємо файл оновлень.
Хотілося б сказати про оновлення через кілька релізів. 1С не рекомендує оновлювати CF файли, відразу стрибаючи через кілька релізів. Це потрібно робити послідовно. Теоретично це правильно.
Поясню чому так не рекомендують робити. Якщо програмісти хочуть видалити який-небудь реквізит, вони спочатку приписують до нього приставку «видалити», потім через кілька релізів видаляють його. І можуть у якомусь релізі перенести з нього інформацію. Ось, пропускаючи цей реліз, ви можете втратити дані. Але на практиці за свої вже 10 років роботи з базами 1с у мене був такий один випадок. Коли чомусь розробники вирішили перенести дані із перерахування на довідник. Проте нічим критичним це для мене не закінчилося. Я написав просту обробку, яка перекинула ці дані з архіву на поточну базу. Жодного повторного оновлення робити не довелося.
Можете кидати в мене каміння, але я завжди оновлюю базу через файли cf на кілька релізів.
Отже ми натиснули оновлення, нам вискочило повідомлення з якою на яку версію буде здійснено оновлення. Ми натискаємо OK.

Очікуємо, поки пройде порівняння об'єктів.
Далі нам потрібно унизу зі списку вибрати пункт «показувати лише двічі змінені властивості.

Так само хочу сказати за старими версіями, раніше це був прапорець.

Отже, ми бачимо набагато менше об'єктів.

Якщо у вас порожньо, то вам дуже пощастило, і ви можете сміливо натискати кнопку «виконати» і вважайте оновлення закінчено. Ну, у нас не все так просто, тому пробіжуся по основних об'єктах.

Перше, що хочеться сказати. У жодному разі не перемикайте режим об'єднання.Він повинен стояти "Взяти з нової конфігурації постачальника". Інакше ви отримаєте в базі сміття із коментарем MGR.
Жодних кнопок «показати відмінності в модулях…»!
Тиснемо саме на значок шестерні поруч із модулем

Відкривається віконце, в якому дуже багато змін у функціях та процедурах.

Для того щоб зрозуміти в якій функції були зміни нам потрібно буде взяти копію бази, або через меню конфігурація зберегти конфігурацію у файл. І далі завантажити у порожню базу. Далі зайти в меню "Конфігурація" і натиснути "Порівняти конфігурації ..."
Вибрати порівняння основної конфігурації із конфігурацією постачальника.

І ось ту можна вже переглянути зміни через «показати відмінності в модулях…». Т.к. ми не збираємося нічого міняти, ми хочемо подивитися, що було змінено.

І бачимо, що у функцію «Прохиляти» було додано шматок коду. Всі зміни можна переглянути, натискаючи на сині стрілки.

Повернемося до оновлюваної конфігурації. Там ми через значок шестерні зайшли з режимом об'єднання модулів. Далі ставимо всі галки ... вручну ... говорячи про себе «дякую» розробникам платформи:)

Знаходимо нашу функцію схилятися. Знаходимо змінений елемент. Сподіваюся, тепер стало зрозуміло, навіщо потрібно відокремлювати будь-який доданий свій коментар - правильно, щоб не гадати при оновленні, звідки взятий цей код.
Натискаємо значок лупи, і платформа виділить рядок коду, куди потрібно додати цей текст.

Копіюємо його з верхнього вікна та вставляємо в нижнє вікно.

Так зробити з усіма модулями. Якщо модуль не змінено, як у нашому випадку з довідником валюти. Ми просто ставимо режим «Взяти з нової конфігурації постачальника» і НЕ натискаємо на шестірню (поряд із шестірнею не повинно стояти зеленої галочки, це означає, що код буде повністю взятий з нової конфігурації, без ручного налаштування).

Чудово. Тепер, пробігшись по всіх об'єктах, можна зняти галку «зберігати налаштування автоматично» і потім «виконати»

На повідомлення «Існують об'єкти, змінені в основній конфігурації по відношенню до старої конфігурації… При оновленні буде виконано заміщення цих об'єктів! Виконати? Натискаємо сміливо ТАК.

У наступному вікні залишаємо галки, як показано на малюнку. І ніяк інакше!!! Повинні стояти обидві галки – «об'єкти редагуються із збереженням підтримки». Натискаємо ОК.

Усе. Оновлення нетипової конфігурації 1с завершено.
Цей метод не претендує на ідеал, але я думаю, багато хто робить помилки в цих кроках.
Звичайно, я розповів не все, тут ще багато підводного каміння. Але я думаю, 90% оновлень можна сміливо оновлювати за цією інструкцією.

Оновлювати конфігурацію на кілька релізів дуже небезпечно. Справа в тому, що після кожного оновлення конфігурації запускається оновлення інформаційних баз у режимі "1С:Підприємство". Тому якщо актуалізувати лише останній реліз, інформаційні основи можуть відповідати останньої зміни. У статті Дмитро Рудаков, спеціаліст компанії ЗАТ "Сибірська Аграрна Група", ділиться особистим досвідом щодо одноразового оновлення конфігурації на 12 релізів.

Перевірка режиму зміни конфігурації

Уявімо таку ситуацію. Розробники "Управління виробничим підприємством" (далі - УПП) у релізі 1 (номери релізів тут і далі присвоєно умовно) виміру (показнику) регістру розрахунку призначили тип "Довідник Посилання. Фізичне Обличчя" з найменуванням "ФізОбличчя". У релізі 2 вони додали ще один вимір - "Співробітник" з типом "Довідник Посилання. Співробітники". При запуску "1С:Підприємство" включається обробка, яка заповнює вимірювання "Співробітник", що відповідає вимірюванню для "ФізОсоби" чином. І потім у релізі 3 розробники "1С" видалили вимір "ФізЛіцо" і залишили тільки "Співробітник". Якщо оновити конфігурацію з релізу 1 відразу до релізу 3, можна очистити весь регістр розрахунку.

А якщо конфігурація стоїть на підтримці з можливістю зміни, і в цій же базі даних формується регламентована звітність, то необхідно оновлювати конфігурацію на кожен реліз, що може бути дуже дорогим у людино-годиннику. Наприклад, оновлення сильно зміненої "УПП" на 1 реліз може зайняти 30 годин робочого часу досвідченого спеціаліста.

Тому перш ніж приступати до оновлення, потрібно визначити: працюєте ви в типовій конфігурації з можливістю зміни або конфігурації без можливості зміни? Для цього зайдіть у конфігуратор, де в меню виконайте дії Конфігурація - Підтримка - Налаштування підтримки".

Рис.1. Виклик вікна налаштування підтримки конфігурації

Якщо встановлено На підтримці", то ця конфігурація типова, а якщо " Увімкнено можливість зміни"- конфігурація, швидше за все, змінена (принаймні така можливість закладена). Третій стан - " Конфігурацію знято з підтримки.Різні стани конфігурації показані малюнки 2, 3, 4.

Рис. 2. Типова конфігурація без можливості змін

Рис. 3. Типова конфігурація із включеною можливістю зміни

Рис. 4. Конфігурація, знята з підтримки

Алгоритм оновлення змінених конфігурацій

Нещодавно переді мною постало завдання оновлення зміненої конфігурації "Управління торгівлею", реліз 10.3.13.2. Конфігурація була змінена в результаті об'єднання з галузевим рішенням "БІТ: Управління автосервісом 8" та безперервно доопрацьовувалась протягом двох років. Тепер конфігурацію потрібно було оновити до релізу 10.3.25.1, тобто 12 релізів. Я розбив всю процедуру поновлення на кілька етапів.

Етап 1. Оцінка вартості та термінів процедури оновлення

Перш ніж розпочинати самостійну роботу, я вирішив отримати незалежну оцінку фахівців у цій галузі. Єдина компанія, що має можливість оновлення змінених змін автоматизованими методами, це ТОВ "1С-ІжТіСі". Я звернувся до фахівців цієї компанії із проханням оцінити вартість оновлення моєї конфігурації. Для оцінки часу та вартості робіт я надав поточну конфігурацію, яка потребує оновлення. Через день я отримав лист зі звітом .

Звіт за підсумками оцінки вартості та термінів проведення оновлення конфігурації:

Конфігурація: Управління торгівлею, редакція 10.3
Поточна версія конфігурації: 10.3.13.2
Оновлення до версії: 10.3.25.1
Кількість модулів, що поновлюються: 1 847
Кількість контрольних релізів: 8

Результати оцінки мене здивували, оскільки на сайті компанії була вказана вартість акції - 1000 руб. за оновлення однією реліз. Коментар "1С-ІжТіСі":

"Вартість поновлення на кожен пропущений реліз у нас не вище 2000 рублів. Наразі проходить акція, тому вартість не перевищує 1000 руб. Але остаточна вартість послуг визначається за результатами оцінки трудовитрат на оновлення і може бути нижче 1000 руб.".

Також я уточнив, як було обрано релізи, необхідні для оновлення. У відповідь на своє запитання я отримав скріншот, на якому це було наочно продемонстровано (рис. 5). У стовпці "Номер версії" вказана версія конфігурації, до якої потрібно оновитись. У стовпці "Оновлення версії" зазначено, з якого релізу можливе оновлення. В результаті оцінки кількість оновлень скоротилася до 9.

Рис. 5. Вибір релізів, які потрібно використовувати для коректного оновлення конфігурації

Після вивчення звіту "1С-ІжТіСі" я підрахував особисті тимчасові витрати на той самий обсяг роботи. Кожна процедура оновлення займає приблизно 6 годин. Отже, загальні часові витрати становлять 56 (9х6) робочих годин, тобто приблизно сім робочих днів. Крім того, існує можливість, що після оновлення виявляться якісь недоліки: наприклад, користувач поскаржиться, що необхідні для нього зміни в конфігурації втрачені, і тоді тимчасові витрати серйозно збільшаться. Тим часом, фахівці компанії "1С-ІжТіСі" пропонують зробити весь обсяг роботи за три-чотири робочі дні. Тому я вирішив скористатися їхніми послугами.

Тепер коротко поясню, що було змінено у конфігурації.

Сильно змінені об'єкти.Це об'єкти, де змінено багато типових властивостей. Коригування мають комплексний характер. Реквізити об'єкта додані в табличну частину, виведені на форму об'єкта та форму списку. Дописано обробників доданих реквізитів у формах. Змінено типовий механізм проведення документа або запису набору руху для регістру.

Сильно змінені документи:

• "Замовлення постачальнику";
• "Переміщення товарів";
• "Вимога-накладна";
• "Надходження товарів та послуг".

Сильно змінені регістри:

• Партії товарів на складах;
• "Товари на складах".

Значно змінені об'єкти.Об'єкти, у яких додані реквізити, змінено або форми об'єктів, або модулі об'єкта (зазвичай, проведення документа нетипове).

• Документ "Прибутковий касовий ордер";
• Реєстр відомостей "Комплектуючі номенклатури";
• Реєстр відомостей "Списані товари";
• Загальні модулі

Незначно змінені об'єкти.В об'єктах змінено лише форми та додано реквізити.

Довідники:

• "Види номенклатури";
• "Договори контрагентів";
• "Контрагенти";
• "Номенклатура";
• "Типи цін номенклатури";
• "Ряд регістрів відомостей".

У розділі "Загальні" змінено підписки на події, макети, ролі, спільні модулі. Майже все було змінено галузевим рішенням.

Етап 2. Видалення конфіденційної інформації

Перш ніж надавати співробітникам "1С-ІжТіСі" інформаційну базу для тестування, у ній потрібно видалити конфіденційну інформацію. Для таких випадків фірма "1С" рекомендує використовувати обробку "Зміна конфіденційної інформації", яка не дуже відома.

Обробка "Зміна конфіденційної інформації" призначена для вибіркової зміни або очищення інформації в базі інформації. Обробку можна використовуватиме підготовки інформаційної бази перед передачею на тестування, де необхідно приховати (очистити, змінити) деяку інформацію.

Обробка ЗмінаКонфіденційноїІнформації.epf є на диску ІТС у каталозі 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Також дану обробку можна завантажити за посиланням: http://its.1c.ru/db/metod81#content:1644:1.

Звичайно, конфіденційна інформація в кожній компанії різна, але звертаю вашу увагу на дані, які, найімовірніше, потрібно змінити:

• Довідники: Фізичні особи, Контактні особи, Контактні особи контрагентів, Контрагенти, Типи цін.
• Регістри відомостей: Паспортні дані фізичної особи, ПІБФізЛіц.

Ваш список, ймовірно, буде ширшим, але це найпоширеніші дані. Їхня зміна навряд чи вплине на можливість тестування вашої інформаційної бази. Також можна груповий обробкою видалити ті об'єкти, робота з якими обслуговуючою компанією не передбачається.

Етап 3. Отримання результатів поновлення

Через три дні мені надали cf-файли та вичерпні інструкції щодо їх встановлення. Для контрольних релізів надаються cf-файли, які не можна використовувати для роботи користувачів, оскільки в них оновлено лише метадані. Вони призначені лише для коректного оновлення на останню версію.

За результатом проведеної роботи можу сказати, що зміни в конфігурації були збережені, при візуальному перегляді всі об'єкти, які були змінені, зберегли свої особливості та відмінності від типової конфігурації. Під час експлуатації ніхто з користувачів не повідомив, що зміни були втрачені.

В результаті оновлення я виділив два невеликі завдання для самостійного вирішення.

Перший. З огляду на те, що оновлення проводиться з використанням механізму "Порівняння, об'єднання", конфігурація БД дійсно оновлюється і оновлюється правильно, без технічних ризиків завдяки обліку контрольних релізів. Однак конфігурація постачальника не оновлюється. Зрозуміло, технічно грамотний фахівець без проблем доповнить цю роботу, проте я попросив "1С-ІжТіСі" надіслати більш повну інструкцію з оновлення. Відповідно до неї, оновлення зможе зробити навіть недосвідчений фахівець.

Друга. В результаті оновлення всі об'єкти залишаються на підтримці з можливістю зміни, що також може бути непрямим недоліком. Якщо потрібно скористатися цими послугами одночасно, тоді всі об'єкти потрібно знову ставити на підтримку. Зробити це у мене поки що виходить тільки перебором всіх об'єктів метаданих. На жаль, поки що цей процес виконується вручну, але в майбутньому і він буде автоматизований.

Крім двох названих завдань, було виявлено один невеликий недолік, який, в принципі, не впливає на якість оновлення та рідко проявляється. В результаті оновлення рядка коду вихідної конфігурації та оновленого візуально збігаються, але в кінці рядків з якихось причин додано пробіли. Це є недоліком, оскільки дещо збільшує обсяг зміненого коду. І у разі подальшого ручного оновлення було б краще не мати таких ділянок коду. На рис. 6 наведено приклад до оновлення, а на рис. 7 – приклад після оновлення.

Ліцензійною політикою 1С передбачена можливість внесення та збереження доробок у типові конфігурації, а відповідно і можливість їх оновлення.

*Допрацьовані або нетипові конфігурації 1С – це програмний продукт на платформі «1С:Підприємство», що входить до складу або становить повністю автоматизовану систему управління підприємства, який зазнав ряду змін, обумовлених потребами та специфікою бізнесу, в частині форм і складу довідників, документів, ролей, модулів і т.д., тому оновлення конфігурації 1С зі змінами - зовсім не те саме, що оновлення типового рішення.

Оновлення, що випускаються фірмою 1С, спрямовані на виправлення багів та внесення змін та доповнень, зумовлених законодавством. Для нових, недавно що вийшли ринку змін, характерний випуск великої кількості оновлень першого типу. Для змін із функціоналом, спрямованим, переважно, на складання регламентної звітності, наприклад «1С: ЗУП», «1С:Бухгалтерія», виходить більше оновлень другого типу.

Специфікою оновлення нетипових змін є необхідність внесення всіх змін нового релізу 1С, при збереженні раніше вироблених доробок. Це нетривіальне завдання, рішення якого немає стандартного сценарію, отже, може бути повністю автоматизовано. Тому в методиці оновлення нетипових змін переважають ручні операції, що вимагають участі спеціаліста.

На етапи реалізації оновлення нетипових змін впливає обсяг наявних доопрацювань. Коротко їх можна описати так:

• Пошук та зіставлення змінених об'єктів;
• Внесення оновлень із нового релізу;
• Внесення раніше здійснених змін, «затертих» на попередньому етапі;
• Перевірка сумісності та роботи процесів.

Різниця полягатиме в часі реалізації: якщо доробок багато, процес відповідно займе більше часу, вимагатиме зосередженості, уваги та ручної перевірки.

Розглянемо для середовища 1С оновлення нетипової конфігурації з прикладу «1С:Управління торгівлею» (реліз 2014 року) на наступний доступний реліз.

Це дуже простий приклад, але як уже було сказано вище, оновлення складнішої конфігурації, звичайно ж, вимагатиме великих витрат часу та зосередженості з боку спеціаліста, але матиме ті ж етапи – оновлення (на нову типову конфігурацію), робота з звіркою внесених і змін, що вносяться і т.д.

Перед оновленням конфігурації слід розвантажити інформаційну базу. Ця дія рекомендується проводити перед будь-якими маніпуляціями з усіма базами без винятку, і особливо з нетиповими:

Вивантаження інформаційної бази завершено:

Зверніть увагу, якби конфігурація не була доопрацьована, тобто була типовою, то у вікні Конфігурації навпроти назви, поруч із жовтим кубиком, відображалася б ще й піктограма замочка:

У меню Конфігурації вибираємо «Підтримка» та «Оновити конфігурацію». Власне, цьому етапі, дії повністю збігаються з процесом оновлення типової конфігурації :

Залежно від розміру бази та її доробок автоматичний пошук доступних оновлень може зайняти якийсь час. Тому варто, незважаючи на рекомендації, вибрати варіант «Вибір файлу оновлення» та самостійно, попередньо розпакувавши архів з оновленнями та зберігши їх, вказати шлях вручну:

Вікно з довідковою інформацією, інструкцією та черговістю оновлень:

Віконце порівняння змін. Ліворуч у дереві відображається стан наявної конфігурації, справа – інформація за новою, типовою версією. Також виділено розділи, що зазнали змін. Далі необхідно з'ясувати, які розділи були змінені з нашого боку і одночасно зазнали змін у новій конфігурації:

Для того, щоб з'ясувати, які типові об'єкти метаданих були змінені раніше і також будуть змінені під час встановлення нової конфігурації постачальника, потрібно вибрати "Показати тільки двічі змінені властивості":

Залишилися тільки об'єкти, що підходять під цю умову:

Розкривши дерево метаданих, можна побачити, які саме об'єкти будуть змінені. Для отримання докладної інформації, кліком правої клавіші вибираємо змінений об'єкт:

Оцінити зміни на рівні коду можна за допомогою "Показати відмінності в модулях", але оскільки їх необхідно ще й запам'ятати, щоб внести після встановлення оновлень, створюємо два звіти: "Звіт про порівняння об'єктів основної конфігурації зі старою конфігурацією постачальника" (існуючі доопрацювання) та «Звіт про порівняння об'єктів нової конфігурації постачальника зі старою конфігурацією постачальника» (оновлення).*

*Давайте розберемося в термінології:

• "Основна конфігурація" - нетипова конфігурація, яку необхідно оновити;
• "Стара конфігурація постачальника" – типова конфігурація, з якої встановлювалися оновлення в останній раз;
• "Нова конфігурація постачальника" - та, на яку оновлюємо зараз.

Налаштовуємо форму звіту та вивантажуємо його. Список внесених раніше змін зафіксовано:

Після вивантаження звітів переходимо безпосередньо до оновлення та натискаємо «Виконати». Конфігуратор пропонує правило оновлення "Взяти з нової конфігурації постачальника" (воно зазначено у третьому стовпці). Це означає, що всі доробки будуть стерті та замінені на типові оновлені об'єкти. Міняти це правило на привабливий "Режим об'єднання" не варто, т.к. автоматичне поєднання призведе до хаосу. Все ж таки краще витратити час і внести зміни вручну:

У вікні із загальною інформацією про зняття конфігурації з підтримки, міняти нічого не треба. Натискання ОК призведе до об'єднання об'єктів. Далі запускаємо «Підприємство» та записуємо зміни, щоб точно закінчити процес оновлення:

Приймаємо перелік змін: *

*Якщо кнопка «Прийняти» неактивна, слід запустити «Тестування виправлень»:



Запускаємо через F5 налагодження та отримуємо підтвердження легальності оновлень:

Після того, як отримано підтвердження, що процес накатки оновлень повністю завершено, слід повернутися до конфігуратора, зайти в двічі змінені об'єкти метаданих та вручну внести зафіксовані зміни на рівні коду, користуючись вивантаженими звітами. На закінчення додамо, що після цього, необхідно перевірити коректність налаштувань та адекватність процесів роботи.

Щоб знайти всі зміни в конфігурації, потрібно порівняти конфігурацію бази даних (поточну конфігурацію) із конфігурацією постачальника (вихідною конфігурацією без змін). Це можна зробити стандартними можливостями платформи. У конфігураторі перейдемо до налаштувань підтримки конфігурації:

Перед нами відкриється вікно налаштування підтримки конфігурації.

Виконавши команду "Порівняти, об'єднати" ми отримаємо список об'єктів, які були змінені в основній конфігурації порівняно з конфігурацією постачальника. Саме такий фільтр за замовчуванням встановлений для дерева метаданих, що відображається. Ось так може виглядати результат порівняння з конфігурацією постачальника.

На цьому етапі ми можемо переглядати відмінності об'єктів основної конфігурації та конфігурації постачальника докладно. Наприклад, на наступному скріншоті показано порівняння модулів звичайної програми у конфігураціях.

У більшості випадків, порівнюючи таким чином об'єкти метаданих, ми можемо оновити типову конфігурацію зі збереженням усіх доробок. Звичайно, все залежить від складності внесених змін, адже якщо вся конфігурація "переписана на кілька разів", оновлення з офіційного пакета оновлень постачальника може стати неможливим.

Роздруковуємо

Для зручності можна вивести список всіх змін конфігурації в табличний документ і використовувати його при подальшому оновленні, коли потрібно буде вибирати способи об'єднання модулів, надавати пріоритет основної конфігурації або конфігурації постачальника. Для збереження результатів порівнянь конфігурацій необхідно сформувати докладний звіт порівняння для всієї конфігурації.

Натиснувши кнопку "ОК" ми отримаємо докладний звіт про зміни у типовій конфігурації у форматі табличного документа, який платформа 1С:Підприємство дозволяє зберегти інші формати (наприклад, таблиця Excel).

На цьому звіт про зміни готовий, розпочинаємо оновлення. Не забуваємо дивитися на коректність оновлення об'єктів метаданих відповідно до отриманого звіту.