Відновлення нетипової конфігурації 1с 8.2 покрокова інструкція. Особистий досвід: як швидко та без зайвих витрат оновити змінену конфігурацію

Розглянемо оновлення на прикладі нетипової конфігурації УПП 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С:Підприємство". Тому якщо актуалізувати лише останній реліз, інформаційні основи можуть відповідати останньої зміни. У статті Дмитро Рудаков, спеціаліст компанії ЗАТ "Сибірська Аграрна Група", ділиться особистим досвідом щодо одноразового оновлення конфігурації на 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с 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С є специфічними тому, що у їхню роботу дуже впливає законодавство країни, у якій ці програми використовуються. Саме тому дуже важливо вміти оновлювати ці продукти, оскільки окрім законодавчих питань, оновлені конфігурації матимуть виправлення критичних помилок, прискорення всієї роботи програми та інші корисні деталі. Є два варіанти розвитку подій: перший варіант являє собою оновлення стандартної (типової) конфігурації, що відбувається досить швидко і не вимагає особливих зусиль, другий варіант, коли оновити потрібно модифіковану збірку, є більш довгим і складним.

Визначення типу конфігурації

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

Стандартна (типова) конфігурація – підготовка до оновлення

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

Третій спосіб відбувається трохи згодом, на етапі оновлення через інтернет. Можна все зробити через диск ІТС, які надходять на підприємство щомісяця, також цей диск можна взяти у співробітника, який має договір з ІТС, тільки слід простежити за збігом змін. В іншому випадку все виконується через інтернет. Є важливий нюанс: пакети оновлення встановлюються суворо послідовно, і якісь релізи були пропущені, система потребує встановити спочатку їх. міститься в меню Довідка, де потрібно натиснути розділ Про програму.
Якщо з інтернетом все гаразд, потрібно зайти на сайт usersv8.1c.ru, в якому вводиться логін і пароль. Далі вибираються необхідні зміни, що знаходяться за посиланням Завантажити оновлення. Наступний крок – це вибір конкретних релізів, з урахуванням найперших та тих, що виходили нещодавно. Усі файли по черзі зберігаються на комп'ютері. Перед оновленням потрібно відкрити всі архівні файли та встановити кожен реліз. Релізи можна завантажити, як було описано, та з диска ІТС. Тепер потрібно заходити в режим Конфігуратора, після чого зліва повинні відображатися об'єкти, якщо їх немає, то потрібно натиснути вкладку Відкрити конфігурацію.
Для оновлення користувач переходить до конфігурації-підтримки-оновити конфігурацію. У новому вікні натискається Пошук.

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

Оновлення нетипової (модифікованої) конфігурації 1С

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

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

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

Існують інші режими з частковим об'єднанням (пріоритетом), але цими режимами користуються досвідчені користувачі, оскільки новачок перетворить усі напрацювання на заплутані модулі. Відповідно, щось змінювати в останньому стовпці, сенсу немає. З іншого боку, прибравши галку у першому стовпчику, примусове об'єднання можна скасувати. Виходячи з цього, можна або вручну внести код у оновлений модуль, або не чіпати код, і вручну вносити самі оновлення. Щоб зрозуміти, що потрібно внести, слід на вибраному модулі натиснути правою кнопкою миші і вибрати пункт Показати відмінності. Цей крок покаже відмінності у конкретних процедурах. Внизу вікна є також поділ на два стовпці, але там уже відображається код.

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

Можливі при оновленні 1С

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

Для вирішення проблеми потрібно:
- міняти кількість символів у кодах;
- Змінювати коди в інформаційній базі;
- Змінювати властивість контролю унікальності у всіх довідниках.

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

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

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

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

Розглянемо, як найпростіше і без помилок зробити нетипове оновлення, на прикладі конфігурації 1С Бухгалтерія підприємства.

Початок будь-якого оновлення описано у статті. Ми ж розглядатимемо лише найголовніше — нюанси нетипового оновлення.

Трохи теорії про нетипові конфігурації:

• Конфігурація без підтримки містить 2 конфігурації: конфігурацію бази даних та основну конфігурацію.
• Конфігурація на підтримці без можливості редагування містить у собі 2 конфігурації: конфігурацію бази даних та основну конфігурацію (вона ж постачальника).
• Конфігурація на підтримці з можливістю зміни містить у собі вже 3 конфігурації: конфігурацію бази даних, основну конфігурацію та конфігурацію постачальника.

1. Підготовка до оновлення

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

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

Отримайте 267 відеоуроків з 1С безкоштовно:

Якщо Ваша конфігурація не типова, то після натискання кнопки «оновити» в конфігураторі система почне порівняти основну та нову конфігурацію постачальника:

Зовні здається, що у нас змінилася велика кількість об'єктів. Однак уявимо ситуацію: Ви змінювали документ, але він не змінювався — чи потрібно його оновлювати вручну? Звичайно, ні. Для відбору таких об'єктів після порівняння обов'язково натисніть кнопку Фільтрі поставте галку

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

Ми отримали список об'єктів, над якими працюватимемо. У нашому випадку виявився лише один складний об'єкт — документ ЗаписКУДіР.

2. Перенесення змін на оновлення 1С

Для перенесення змін я відкриваю 2 конфігуратори - в одному запускаю порівняння і забираю зміни, а в другому - доробки.

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

3. Відмінності у модулях

Досить проста, але дуже відповідальна операція – ми просто переносимо модулі з нового релізу до старого. Якщо код коментується, то проблем не повинно бути:

4. Порівняння форм та макетів

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

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

Нетипове оновлення зміненої конфігурації 1С завершено!

Зверніть увагу!Якщо Ви не вмієте програмувати 1С 8, шанс на успішне оновлення нетипової конфігурації вкрай малий. Ви витратите багато часу і в результаті отримаєте конфігурацію, яка не запускається. Рекомендую звернутися для оперативної допомоги.