1. Етап 1. Підготовка
2. Етап 2. Оновлення
3. Етап 3. Здача робіт

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

У цій статті не описуються методики застосування автоматичного і автоматизованого оновлення конфігурацій з використанням зовнішніх компонент і / або програмних продуктів. Інформацію по ним ви можете знайти на цьому і інших ресурсах Інтернету.

Можливо, ви помітили, що при кожному черговому оновленні кількість об'єктів, які потребують вашої уваги, тільки збільшується. При цьому ви точно знаєте, що змінений, наприклад, тільки один документ, а при оновленні видається список з декількох десятків змінених об'єктів. Звичайно, можна скористатися методикою описаної в статті «Технологія поновлення нетипових конфігурацій 1С: Підприємства 7.7» від 27.06.2003. Так, це буде працювати. Багато хто саме так виконують оновлення. Але я вважаю даний підхід неефективним і трудомістким при оновленні конфігурацій на платформі 1С: Підприємство 8. На відміну від платформи 1С: Підприємства 7.7 ​​платформа 1С: Підприємство 8 дозволяє відкривати одночасно кілька конфігурацій (файли * .cf) і виконувати кілька порівнянь конфігурацій в одній копії конфігуратора. Виняток становлять, мабуть, тільки конфігурації побудовані на УПП (Управління виробничим підприємством) - вони занадто важкі, платформа падає.

Процес оновлення конфігурацій 1С: Підприємство 8 більш автоматизований в порівнянні з 1С: Підприємством 7.7. Досить високий рівень автоматизації дозволяє значно знизити трудомісткість робіт при оновленні нетипових конфігурацій. На жаль, найчастіше процес оновлення нетипових конфігурацій не може бути виконаний повністю в автоматичному режимі і вимагає втручання фахівця.

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

Слід звернути увагу на те, що база даних може містити до трьох видів конфігурацій:

• конфігурація бази даних - це конфігурація, з якою працюють користувачі;
• робоча конфігурація (основна) - це конфігурація, в яку ми можемо вносити зміни, при цьому користувачі можуть продовжувати працювати;
• конфігурація постачальника - це вихідна конфігурація постачальника, на основі якої зазвичай створюються робоча конфігурація і конфігурація бази даних. У базі даних може бути кілька конфігурацій від різних постачальників. Постачальником конфігурації може бути не тільки фірма «1С».

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

Розглянемо процес оновлення і розберемо можливі помилки на прикладі поновлення конфігурації УПП (постачальник типової конфігурації - фірма «1С», доопрацювання компанії Інформ Сервіс). Спочатку оновлення даної конфігурації виконувалося не по описаній в даній статті технології, тому що розглядаються в статті помилки є найбільш часто зустрічаються на практиці. Оновлення буде виконуватися з версії 1.2.6.2 на версію 1.2.14.1.

Етап 1. Підготовка

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

Цей етап можна пропустити, якщо останнє оновлення пройшло через «підтримку» (Меню «Конфігурація» → «Підтримка» → «Оновити конфігурацію») або було виконано за описаною в даній статті методикою.

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

1. Порівняння версій.

Перевіримо номера версій робочої конфігурації та конфігурації постачальника. Номер робочої конфігурації дивимося в меню «Конфігурація» → «Відкрити конфігурацію» меню «Правка» → «Властивості». У блоці «Розробка» пункт «Версія». (Малюнок 1).

Малюнок 1.

Номер конфігурації постачальника дивимося в меню «Конфігурація» → «Підтримка» → «Налаштування підтримки ...» пункт «Версія». (Малюнок 2).

Малюнок 2.

Якщо номери співпадають, то переходимо до наступного етапу. Див. Етап 2.

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

2. Збереження робочої (основний) конфігурації.

Збережемо робочу конфігурацію в файл, наприклад work.cf. Для цього виберемо пункт меню «Конфігурація» → «Зберегти конфігурацію в файл ...».

3. Отримання файлу оновлення для установки постачальника.

Для приведення у відповідність конфігурацій нам знадобиться файл * .cf з дистрибутива постачальника з тим же номером версії, що у робочої конфігурації (Малюнки 3 і 4). Даний файл можна отримати при встановленні відповідного дистрибутива. За замовчуванням установка дистрибутива конфігурації виконується в каталог C: Program Files1cv81tmplts. Детальніше про встановлення шаблонів конфігурацій см. Документацію.

Малюнок 3.

Малюнок 4.

Перевіримо каталог шаблонів. Якщо в каталозі шаблонів є * .cf файл потрібної версії, то переходимо до пункту 4 Етапу 1.

Що можна зробити, якщо немає * .cf файлу потрібної версії конфігурації постачальника? В цьому випадку можна скористатися файлами * .cfu і повторивши описану в Етапі 1 процедуру кілька разів послідовно підняти номер версії до необхідного релізу, в даному випадку до 1.2.6.2. Слід зазначити, що використання файлів * .cfu може не розкрити помилки, допущені раніше при оновленні. Що, погодьтеся, досить дивно, з огляду на той факт, що спочатку збирається файл постачальника на основі старої конфігурації постачальника і * .cfu файлу, а потім виконується оновлення. Можливо це пов'язано з тим, що в порівнянні чомусь беруть участь не всі об'єкти конфігурації. Тому пропоную використовувати максимально довгий шлях, але і більш надійний.

Необхідно створити порожню базу даних зі "старої" конфігурацією постачальника. Оновити конфігурацію постачальника до потрібної версії і вже її використовувати при виконанні робіт на 1 етапі. Для отримання "нової" конфігурації постачальника потрібно зробити наступне:

1. Створення "старого" файлу постачальника для поточної конфігурації. Файл 1cv8.cf можна взяти з дистрибутива постачальника або зберегти з робочої бази, якщо конфігурація знаходиться на підтримці. Для збереження файлу 1cv8.cf з робочої бази необхідно в меню «Конфігурація» → «Підтримка» → «Налаштування підтримки ...» натиснути кнопку «Зберегти в файл» і вказати каталог та ім'я файлу. Наприклад, на робочий стіл.

2. Створення бази даних з новою конфігурацією постачальника. Базу даних можна створити, використовуючи дистрибутив постачальника з диска ІТС або використовуючи отриманий раніше 1cv8.cf з робочого столу. У першому випадку слідуємо інструкції входить в дистрибутив. У другому випадку для створення бази з розташованого на робочому столі файлу, створюємо нову інформаційну базу без конфігурації і запускаємо конфигуратор. В меню «Конфігурація» → «Завантажити конфігурацію з файлу ...» вказуємо файл, збережений раніше на робочому столі. Відкриваємо конфігурацію через меню «Конфігурація» → «Відкрити конфігурацію» і оновлюємо до потрібного релізу через меню «Конфігурація» → «Підтримка» → «Оновити конфігурацію» використовуючи файли * .cfu.

3. Створення файлу "нової" конфігурації постачальника. Для цього вибираємо пункт в меню «Конфігурація» → «Зберегти конфігурацію в файл ...». Уточнюємо розташування і ім'я файлу 1cv8.cf. Натискаємо «Зберегти».

Використовуючи отриманий * .cf файл конфігурації постачальника виконаємо оновлення. Для цього виберемо пункт меню «Конфігурація» → «Підтримка» → «Оновити конфігурацію», «Вибір файлу оновлення», «Готово» (Малюнок 5), «Виконати» (Малюнок 6).

Малюнок 5.

Малюнок 6.

Отже, перша проблема - «Виявлено посилання на об'єкти, помічені на видалення». (Малюнок 7).

Малюнок 7.

Варіанти вирішення:

• зняти позначку з об'єкта, которийв установки постачальника;
• видалити посилання на об'єкт, которийв установки постачальника.

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

5. Відновлення налаштувань частково втрачених на попередньому етапі.

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

6. Збереження результатів оновлення.

Збережемо зміни робочої конфігурації та оновимо конфігурацію бази даних. Для цього виберемо пункт меню «Конфігурація» → «Оновити конфігурацію бази даних».

Тут нас чекає чергова проблема (Малюнок 8).

Малюнок 8.

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

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

Розглянемо ще одну ситуацію, аналогічну попередньої, але виникла при оновленні 1С: Бухгалтерія підприємства 8.1. Що робити з формами? (Малюнок 9)

Малюнок 9.

На малюнку ми бачимо, що ФормаСпіска була видалена у постачальника, а потім додана постачальником нова форма з тим же ім'ям. Відповідно необхідно позначити обидві форми для поновлення і натиснути кнопку «Виконати».

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

Збережемо зміни робочої конфігурації та оновимо конфігурацію бази даних «Конфігурація» → «Оновити конфігурацію бази даних».

Якщо необхідно, перенесемо значення реквізиту ЗаказРезерв1 в ЗаказРезерв за допомогою зовнішньої обробки в режимі 1С: Підприємство.

Етап 2. Оновлення

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

Для оновлення конфігурації нам знадобиться файл * .cfu або файл * .cf з дистрибутива постачальника.

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

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

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

1. Підготовка баз даних.

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

2. тристороннього порівняння конфігурацій.

Відкриємо обидві бази в режимі Конфігуратор і виконаємо тристороннього порівняння конфігурацій в обох базах, використовуючи наявний файл нової конфігурації постачальника. Для цього в обох базах виберемо пункт меню «Конфігурація» → «Підтримка» → «Оновити конфігурацію», «Вибір файлу оновлення», «Готово» (Малюнок 10).

Малюнок 10.

В результаті порівняння трьох конфігурацій (стара конфігурація постачальника, нова конфігурація постачальника і робоча конфігурація) отримуємо список змінених об'єктів. Встановлюємо фільтр «Показувати тільки двічі змінені властивості» (Малюнки 11 і 12).

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

Малюнок 11.

Малюнок 12.

Малюнок 13.

На цьому роботу в другій (допоміжної) базі припиняємо і продовжуємо в основний. Кнопку «Виконати» в допоміжній базі не треба натискати. Нам ця база потрібна саме в такому вигляді до закінчення процесу оновлення.

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

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

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

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

Малюнок 14.

Далі розставляємо галочки, вказуючи які процедури і функції слід замінити або видалити (Малюнок 15).

Малюнок 15.

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

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

Малюнок 16.

Аналогічним чином порівнюємо стару конфігурацію постачальника з новою. Для порівняння нам знадобиться файл нової конфігурації постачальника. Якщо такого файлу немає, то тепер його можна отримати з основної бази. Для збереження в файл нової конфігурації постачальника в основній базі в меню «Конфігурація» → «Підтримка» → «Налаштування підтримки:» натискаємо кнопку «Зберегти в файл». (Малюнок 2). Вказуємо ім'я файлу, наприклад, new.cf. Далі робимо третє порівняння конфігурацій і при порівнянні в якості другої конфігурації вказуємо файл new.cf.

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

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

Порівняння форм, таблиць, і модулів об'єктів в конфігурації виконується з достатнім ступенем деталізації (Малюнок 17). Цього цілком достатньо для прийняття рішень.

Малюнок 17.

Але в деяких випадках дані в звітах про порівняння подаються у вигляді, що не дозволяє прийняти рішення швидко. Наприклад, в разі зміни типу реквізитів, що мають складовою тип даних, склад вводяться на підставі об'єктів і т.д. Саме на даному етапі, зважаючи на його складність, відбувається втрата доробок при оновленні. Розглянемо цю ситуацію на прикладі реквізитів, що мають складовою тип даних. При формуванні звіту про порівняння об'єктів (Малюнок 17) дані, що розрізняються в порівнюваних конфігураціях представлені у вигляді списків, що містять склад типів даних, розділених комами. При цьому в звіті абсолютно не видно, які типи даних були додані або видалені. Звичайно, для виявлення відмінностей звіт можна роздрукувати і «скрижіть». У розглянутому прикладі таких об'єктів близько 200. Очевидно, що процес порівняння видається досить трудомістким і складе близько 50 годин.

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

Конфігурація «Порівняння осередків» запускається в режимі 1С: Підприємство і дозволяє представити інформацію зі звіту про порівняння об'єктів в наочному вигляді (Малюнки 18 і 19). Для порівняння використовуються можливості 1С: Підприємство 8.

Малюнок 18.

Малюнок 19.

Схема роботи конфігурації проста. У конфігураторі створюємо звіт про порівняння об'єктів (Малюнок 17) і зберігаємо в файл, наприклад ОтчетОСравненіі.mxl. Відкриваємо 1С: Підприємство і в діалозі (Малюнок 18) вибираємо збережений файл і вказуємо порівнювані осередки. Для цього двічі клацаємо правою клавішею миші на вибраній комірці табличного документа. За кнопці «Порівняти» отримуємо результат порівняння, в якому розрізняються позиції виділені кольором (Малюнок 19).

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

Особливо пильну увагу слід приділити шаблонами RLS за зміненими ролями користувачів.

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

Етап 3. Здача робіт

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

Спочатку уважно вивчаємо інструкцію з дистрибутива поставки. Виконуємо необхідні роботи перед оновленням в робочій базі.

Якщо в робочій базі даних замовника під час підготовки оновлення не проводилися роботи по зміні конфігурації, а оновлення готувалося на актуальною копії робочої бази даних, то для перенесення налаштувань збережемо робочу конфігурацію в файл, наприклад work_2.cf, вибравши пункт меню «Конфігурація» → « зберегти конфігурацію в файл ... ».

Подальші дії на стороні замовника будуть наступні:

• створити резервну копію бази даних;
• використовуючи файл work_2.cf, переносимо зміни. Для цього виберемо пункт меню «Конфігурація» → «Завантажити конфігурацію з файлу ...»;
• на питання про оновлення конфігурації бази даних відповімо згодою.

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

Якщо оновлення готувався не на актуальною копії робочої бази даних, то для перенесення налаштувань скористаємося методикою використаної на першому етапі. Для цього нам знадобиться файл * .cf типової конфігурації постачальника (1.2.14.1) і результат відновлення у вигляді також * .cf файлу. Для цього збережемо робочу конфігурацію в файл, наприклад work_2.cf, вибравши пункт меню «Конфігурація» → «Зберегти конфігурацію в файл ...».

Подальші дії на стороні замовника будуть наступні:

• створити резервну копію бази даних;
• використовуючи файл * .cf типової конфігурації постачальника, виконаємо оновлення. Для цього виберемо пункт меню «Конфігурація» → «Підтримка» → «Оновити конфігурацію», «Вибір файлу оновлення», «Готово» (Малюнок 10), «Виконати»;
• використовуючи файл work_2.cf, переносимо зміни. Для цього виберемо пункт меню «Конфігурація» → «Порівняти, об'єднати з конфігурацією з файлу ...»;
• збережемо зміни робочої конфігурації та оновимо конфігурацію бази даних. Для цього виберемо пункт меню «Конфігурація» → «Оновити конфігурацію бази даних».

Далі слідуємо інструкції з дистрибутива поставки і виконуємо необхідні роботи після оновлення.

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