Нетипова конфігурація 1С (допрацьована) – це автоматизована системауправління підприємства, яка зазнала низки змін, через специфіку або потреби бізнесу.
Коли перша конфігурація стане популярною і використовуватиметься в багатьох компаніях, вона стає типовою.
У другий тип сам розробник з часом вносить зміни, доповнення та покращення, робить налаштування більш зручними або актуальними. У той самий час, якщо конфігурація організацію влаштовує, то оновлювати в нову немає потреби.
Але якщо було в законодавство внесено низку серйозних змін (наприклад, змінено алгоритм обліковості), тобто 2 варіанти того, що робити з оновленнями:
- оновити нову типову версію;
- оновити нетипову конфігурацію 1С самостійно з урахуванням зміни законодавства.
Проблема оновлення нетипових конфігурацій у тому, що це завдання неможливо автоматизувати, оскільки немає стандартного сценарію. Тому, коли проводиться 1С оновлення типової конфігураціїповинен бути фахівець, який зможе виконати всі необхідні ручні операції.
Наприклад візьмемо нетипову конфігурацію 2014 року «1С:Управління торгівлею» та її оновлення на наступний доступний реліз.
Незалежно від конфігурації, всі етапи оновлення програми будуть однакові, але для одних це займе менше часу, для інших – більше. Тривалість залежить кількості доробок. Як максимум, можливо, буде необхідна ручна перевірка, якщо доробок було дуже багато.
Покрокова інструкція, як оновити нетипову конфігурацію 1С самостійно
Етапи оновлення:
- Вивантажуємо інформаційну базу.
- Переходимо до меню «Конфігурація». Там вибираємо пункт меню «Підтримка» і далі – «Оновити конфігурацію».
- Після попереднього кроку вивантажуємо форму звіту, попередньо налаштувавши його.
- Переходимо до процесу оновлення. Для цього натискаємо кнопку "Виконати".
- Відкривається інформаційне вікно з даними та елементами вибору установок. У ньому нічого не міняєте. Натискаємо "ОК".
- Запускаємо «Підприємство».
- Щоб оновлення закінчилося, необхідно прийняти зміни до контекстному меню, що відкрилося.
- Використовуючи функцію F5, отримуєте підтвердження про те, що всі оновлені легальні.
Після останнього пункту, коли відкрилося спливаюче вікно з підтвердженням оновлення, необхідно повернутися в конфігуратор, зайти в оновлені об'єкти метаданих і самостійно, вручну, внести зміни в код програми.
У цій статті не описуються методики застосування автоматичного та автоматизованого оновлення конфігурацій з використанням зовнішніх компонентів та/або програмних продуктів. Інформацію щодо них ви можете знайти на цьому та інших ресурсах Інтернету.
Можливо, ви помітили, що при кожному черговому оновленні кількість об'єктів, що вимагають вашої уваги, лише збільшується. При цьому ви точно знаєте, що змінено, наприклад, лише один документ, а при оновленні видається список кількох десятків змінених об'єктів. Звичайно, можна скористатися методикою, описаною в статті . Так, це працюватиме. Багато хто саме так виконує оновлення. Але я вважаю даний підхід неефективним і трудомістким при оновленні конфігурацій на платформі 1С:Підприємства 8. На відміну від платформи 1С:Підприємства 7.7 платформа 1С:Підприємства 8 дозволяє відкривати одночасно кілька конфігурацій (файли *.cf) конфігуратора. Виняток становлять, мабуть, лише зміни побудовані на УПП (Управління виробничим підприємством) - вони дуже важкі, платформа падає.
Процес оновлення змін 1С:Підприємства 8 більш автоматизований порівняно з 1С:Підприємством 7.7. Досить високий рівень автоматизації дозволяє значно знизити трудомісткість робіт за оновлення нетипових конфігурацій. На жаль, найчастіше процес оновлення нетипових конфігурацій не може бути виконаний повністю в автоматичному режиміта вимагає втручання спеціаліста.
Чи можлива ситуація, коли оновлення буде виконано повністю автоматично? Звичайно. Для цього змінні об'єктиповинні бути додані та не повинні використовувати функціонал існуючої конфігурації. Тобто. ці об'єкти мають вирішувати зовсім інші облікові завдання, що розширюють функціонал типової конфігурації постачальника. Погодьтеся, що описана ситуація є вкрай рідкісною. Майже завжди зміни торкаються об'єктів типової конфігурації постачальника.
Слід звернути увагу, що база даних може містити до трьох видів конфігурацій:
- конфігурація бази даних - це конфігурація, з якою працюють користувачі;
- робоча конфігурація (основна) – це конфігурація, у яку ми можемо вносити зміни, у своїй користувачі можуть продовжувати працювати;
- конфігурація постачальника – це вихідна конфігурація постачальника, на основі якої зазвичай створюються робоча конфігураціяі конфігурація бази даних. У базі даних можливо кілька змін від різних постачальників. Постачальником конфігурації може бути фірма «1С».
У випадку, коли конфігурацію знято з підтримки, конфігурації постачальникане буде. Що значно підвищує трудомісткість оновлення.
Розглянемо процес оновлення та розберемо можливі помилкина прикладі оновлення конфігурації УПП (постачальник типової конфігурації - фірма «1С», доопрацювання компанії Інформ Сервіс). Спочатку оновлення даної конфігурації виконувалося не за описаною в цій статті технології, тому помилки, що розглядаються в статті, є найбільш часто зустрічаються на практиці. Оновлення буде виконано з версії 1.2.6.2 на версію 1.2.14.1.
Етап 1. Підготовка.
На першому етапі приведемо у відповідність робочу конфігураціюдо конфігурації постачальника. Це дуже важливий етап, який дозволить значно зменшити обсяг робіт з аналізу внесених раніше змін.
Цей етап можна пропустити, якщо останнє оновленняпройшло через "підтримку" (Меню "Конфігурація" U94; "Підтримка" U94; "Оновити конфігурацію") або було виконано за описаною в даній статті методикою.
Невідповідність версій робочої конфігураціїі конфігурації постачальникаможе виникнути при використанні для оновлення *.cf файлів, не з дистрибутива постачальника або при використанні методів оновлення, які відрізняються від описаних у цій статті. Наприклад, об'єкти додавалися до робочої конфігурації копіюванням через буфер обміну або Drag&Drop.
1. Порівняння версій.
Перевіримо номери версій робочої конфігураціїі конфігурації постачальника. Номер робочої конфігураціїдивимось у меню «Конфігурація» U94; "Відкрити конфігурацію" меню "Правка" U94; "Властивості". У блоці "Розробка" пункт "Версія". (Малюнок 1).
Номер конфігурації постачальникадивимось у меню «Конфігурація» U94; "Підтримка" U94; "Налаштування підтримки..." пункт "Версія". (Малюнок 2).
Якщо номери збігаються, переходимо до наступного етапу. Див.
У цьому прикладі необхідно привести у відповідність робочу конфігураціюі конфігурацію постачальниказ постановкою на підтримку об'єктів, знятих із підтримки або доданих без постановки на підтримку. Для цього виконаємо такі дії:
2. Збереження робочої (основний) зміни.
Збережемо робочу конфігураціюу файл, наприклад work.cf. Для цього виберіть пункт меню «Конфігурація» U94; "Зберегти конфігурацію у файл...".
3. Отримати файл оновлення для конфігурації постачальника.
Для приведення у відповідність конфігурацій нам знадобиться файл *.cf з дистрибутива постачальника з тим самим номером версії, що у робочої конфігурації(Малюнки 3 та 4). Цей файлможна отримати при встановленні відповідного дистрибутива. За замовчуванням установка дистрибутива конфігурації виконується в каталог C: Program Files 1cv81 tmplts. Докладніше про встановлення шаблонів конфігурацій див. у документації.
Перевіримо каталог шаблонів. Якщо каталог шаблонів є *.cf файл потрібної версії, то переходимо до .
Що можна зробити, якщо немає *.cf файлу потрібної версії конфігурації постачальника? В цьому випадку можна скористатися файлами *.cfu і повторивши описану в Етапі 1 процедуру кілька разів послідовно підняти номер версії до необхідного релізу, даному випадкудо 1.2.6.2. Слід зазначити, що використання файлів *.cfu може не розкрити помилки, допущені раніше під час оновлення. Що, погодьтеся, досить дивно, враховуючи той факт, що спочатку збирається файл постачальника на основі файлу *.cfu, а потім виконується оновлення. Можливо це пов'язано з тим, що порівняно чомусь беруть участь не всі об'єкти конфігурації. Тому пропоную використовувати якомога більш довгий шлях, але й надійніший.
Необхідно створити порожню базу даних з "старою" конфігурацією постачальника. Оновити конфігурацію постачальникадо необхідної версії і її використовувати під час виконання робіт на 1 етапі. Для отримання "нової" конфігурації постачальникапотрібно зробити таке:
Створення "старого" файла постачальникапоточної конфігурації. Файл 1cv8.cf можна взяти з дистрибутива постачальника або зберегти з робочої бази, якщо конфігурація на підтримці. Для збереження файлу 1cv8.cf із робочої бази необхідно в меню «Конфігурація» U94; "Підтримка" U94; "Налаштування підтримки..." натиснути кнопку "Зберегти у файл" і вказати каталог та ім'я файлу. Наприклад, на робочий стіл.
Створення бази даних із новою конфігурацією постачальника.Базу даних можна створити, використовуючи дистрибутив постачальника з диска ІТС або використовуючи раніше отриманий 1cv8.cf з робочого столу. У першому випадку слідуємо інструкції, що входить у дистрибутив. У другому випадку для створення бази з розташованого на робочому столі файлу створюємо нову інформаційну базу без конфігурації і запускаємо конфігуратор. У меню "Конфігурація" U94; "Завантажити конфігурацію з файлу..." вказуємо файл, збережений раніше на робочому столі. Відкриваємо конфігурацію через меню "Конфігурація" U94; "Відкрити конфігурацію" та оновлюємо до потрібного релізу через меню "Конфігурація" U94; "Підтримка" U94; "Оновити конфігурацію" за допомогою файлів *.cfu.
Створення файлу "нової" конфігурації постачальника.Для цього вибираємо пункт у меню "Конфігурація" U94; "Зберегти конфігурацію у файл...". Уточнюємо розташування та ім'я файлу 1cv8.cf. Натискаємо "Зберегти".
4. Приведення у відповідність робочої конфігурації та конфігурації постачальника через оновлення.
Використовуючи отриманий *.cf файл конфігурації постачальникавиконаємо оновлення. Для цього виберіть пункт меню «Конфігурація» U94; "Підтримка" U94; "Оновити конфігурацію", "Вибір файлу оновлення", "Готово" (Малюнок 5), "Виконати" (Малюнок 6).
Варіанти розв'язання:
- зняти позначку з об'єкта, який у конфігурації постачальника;
- видалити посилання на об'єкт, який у конфігурації постачальника.
Виходячи з того, що посилання в доданому інтерфейсі «Керівник Відділу» виконано на об'єкт конфігурації постачальника, Підтримка з якого знята постачальником (можливо у зв'язку зі зміною методики обліку), то правильним рішенняму цій ситуації буде видалення посилання цей звіт з інтерфейсу «КерівникОтдела». Вікно порівняння конфігурацій не закриваємо, посилання на звіт «ОплатаЗамовлень» в інтерфейсі Керівник Відділу видаляємо. Після видалення посилання виконаємо повторне порівняння конфігурацій. Для цього натисніть кнопку "Оновити" у вікні оновлення (Малюнок 6).
5. Відновлення налаштувань частково загублених на попередньому етапі.
Для відновлення частково втрачених налаштувань виконаємо об'єднання з раніше збереженим файлом робочої конфігурації work.cf. Для цього виберіть пункт меню «Конфігурація» U94; "Порівняти, об'єднати з конфігурацією з файлу ...".
6. Збереження результатів оновлення.
Збережемо зміни робочої конфігураціїі оновимо конфігурацію бази даних. Для цього виберіть пункт меню «Конфігурація» U94; "Оновити конфігурацію бази даних".
Тут на нас чекає чергова проблема (Малюнок 8).
Для вирішення цієї проблеми подивимося причину її виникнення. Причин може бути кілька, але найімовірніші такі. Ці об'єкти були скопійовані в робочу конфігураціюз конфігурації постачальникаабо постачальник видалив раніше дані об'єкти, а пізніше додав нові з такими ж іменами, але з іншими внутрішніми ідентифікаторами. В результаті конфігурації з'являються об'єкти з різними внутрішніми ідентифікаторами, але з однаковими іменами.
З ролями надаємо просто - видаляємо, т.к. ролі не змінювалися (це можна перевірити, порівнявши і робочу конфігурацію). З реквізитом документа діємо інакше. Реквізит необхідно перейменувати, наприклад ЗамовленняРезерв1, а після оновлення перенести значення з перейменованого реквізиту на новий. Для цього можна скористатися обробкою Універсальні Підбір І Обробка Об'єктів. Epf з диска ІТС.
Розглянемо ще одну ситуацію, аналогічну до попередньої, але що виникла при оновленні 1С:Бухгалтерії підприємства 8.1. Що робити із формами? (Малюнок 9)
На малюнку бачимо, що ФормаСписка була видалена у постачальника, та був додана постачальником нова форма з тим самим ім'ям. Відповідно, необхідно позначити обидві форми для оновлення та натиснути кнопку «Виконати».
Якщо буде видано повідомлення про те, що є посилання на об'єкти, що видаляються, необхідно не закриваючи форму оновлення очистити посилання на видалену форму у властивостях об'єкта. У разі у властивостях регістру. Після цього необхідно у формі оновлення натиснути кнопку «Оновити», позначити оновлення властивості регістру і ще раз натиснути кнопку «Виконати».
Збережемо зміни робочої конфігураціїі оновимо конфігурацію бази даних"Конфігурація" U94; "Оновити конфігурацію бази даних".
Якщо необхідно, перенесемо значення реквізиту ЗамовленняРезерв1 до ЗамовленняРезерв за допомогою зовнішньої обробкив режимі 1С:Підприємство.
Етап 2. Оновлення.
Після проведення підготовчих робіт на Етапі 1 переходимо до оновлення основний конфігураціїта перенесення раніше зроблених доробок типової конфігурації постачальника.
Для оновлення конфігурації нам знадобиться файл *.cfu або *.cf з дистрибутива постачальника. Докладніше про способи їх отримання можна почитати.
Якщо оновлення виконується через кілька версій конфігурації, слід звернути увагу на ситуацію, описану в статті . Якщо оновлення виконується не на робочій базі, після завершення робіт з підготовки кожного нового етапу зберігаємо файли *.cf. Вони потрібні при оновленні конфігурації робочої бази даних замовника.
Якщо оновлення виконується через кілька версій, то при оновленні слід обов'язково звернути увагу на об'єкти, що видаляються, і на об'єкти зі зміненими іменами, а також на дії, що виконуються при першому запуску після оновлення. Якщо ці об'єкти використовуються в обробці при першому запуску після оновлення, то не слід видаляти їх, а по об'єктах зі зміненими іменами слід внести відповідні зміни до тексту модуля обробки. У цьому випадку залишені об'єкти можуть бути видалені під час повторного або наступного оновлення.
Якщо оновлення виконується через кілька версій, то для зниження трудомісткості оновлення можна скористатися методикою з обчисленням ключових релізів, описаною в статті .
1. Підготовка бази даних.
Отже, за результатами першого етапу готуємо дві однакові бази. Перша (основна) – наш майбутній результат. Друга (допоміжна) - до виконання порівнянь, відкриття конфігурацій та інших підготовчих процесів. Для файлового варіанта це просто копіювання файлів основної бази в інший каталог та підключення цього каталогу до списку баз, для клієнта серверного - вивантаження/завантаження.
2. Тристороннє порівняння змін.
Відкриємо обидві бази в режимі Конфігуратор та здійснимо тристороннє порівняння конфігурацій в обох базах, використовуючи наявний файл нової конфігурації постачальника. Для цього в обох базах виберіть пункт меню «Конфігурація» U94; "Підтримка" U94; "Оновити конфігурацію", "Вибір файлу оновлення", "Готово" (Малюнок 10).
В результаті порівняння трьох конфігурацій ( стара конфігурація постачальника, нова конфігурація постачальникаі робоча конфігурація) отримуємо список змінених об'єктів. Встановлюємо фільтр «Показувати лише двічі змінені властивості» (Малюнки 11 та 12).
Саме із цими об'єктами необхідно розібратися насамперед, т.к. після оновлення, виконані налаштування, можуть бути втрачені.
На цьому роботу у другій (допоміжній) базі зупиняємо та продовжуємо в основній. Кнопку «Виконати» у допоміжній основі не треба натискати. Нам ця база потрібна саме у такому вигляді до закінчення процесу оновлення.
Отже, в результаті отримуємо список об'єктів, які двічі змінені при доопрацюванні. типової конфігураціїта в . Якщо погодитись з оновленням, то зроблені раніше доопрацювання у цих об'єктах будуть втрачені. Тому по кожному об'єкту необхідно ухвалити рішення про те, як він буде оновлений (Малюнок 13). На цьому етапі виконуємо попереднє порівняння виключно для того, щоб зменшити обсяг робіт надалі. Оцінка не точна швидка – «на око».
нової конфігурації постачальника, залишаємо екземпляр об'єкта постачальника. Залишаємо галочку. Потім перенесемо зміни з робочої конфігурації.
Якщо змін в об'єкті більше робочої конфігурації, то залишаємо екземпляр об'єкту робочої конфігурації. Знімаємо галочку. Потім перенесемо зміни з конфігурації постачальника.
З модулями чинимо трохи інакше, т.к. у нашому розпорядженні можна порівнювати модулі попроцедурно. Тобто. у випадку, якщо в нашої конфігураціїі в конфігурації постачальника змінені різні процедури модуля, то правильно розставивши галочки ми позбавимо себе ручного перенесення змін коду. Щоб до цього добратися натискаємо кнопку як це показано малюнку 14.
Після того, як визначилися з об'єктами, які будуть оновлені відразу і на яких залишилися галочки, дублюємо стан по галочках у допоміжній базі, а в основній базі натискаємо кнопку «Виконати». В основній основі отримуємо майже готову конфігурацію.
Далі всі порівняння виконуємо у допоміжній основі. Одне порівняння у нас уже є – тристороннє. Для визначення раніше внесених змін виконуємо додаткове друге порівняння старої конфігурації постачальниказ основною конфігурацією. Для цього виберемо пункт у меню "Конфігурація" U94; «Порівняти конфігурації:», виберемо для порівняння « Конфігурація постачальника» та « Основна конфігурація
Аналогічним чином порівнюємо стару конфігурацію постачальниказ новою. Для порівняння нам знадобиться файл нової конфігурації постачальника. Якщо такого файлу немає, тепер його можна отримати з основної бази. Для збереження у файл нової конфігурації постачальникав основній базі меню «Конфігурація» U94; "Підтримка" U94; "Налаштування підтримки:" натискаємо кнопку "Зберегти у файл". (Малюнок 2). Вказуємо ім'я файлу, наприклад, new.cf. Далі робимо третє порівняння конфігурацій і при порівнянні другої конфігурації вказуємо файл new.cf.
Отже, ми отримали у додатковій базі список двічі змінених об'єктів. І ще два порівняння, які допоможуть нам більш ефективно перенести раніше зроблені налаштування старої версіїу нову. В основі ми отримали майже готову конфігурацію, в якій потрібно розібратися з двічі зміненими об'єктами.
Для скорочення часу на аналіз змін типової конфігурації і, відповідно, на оновлення було б доречно коментувати всі зміни, що вносяться в конфігурацію, відзначаючи не тільки змінений текст модулів, але і мета виконаних змін. Через низку причин дуже часто цього не роблять. Під час оновлення цікавлять не причини внесення змін, а їх наслідки. Зокрема необхідність зберегти функціонал зміненої конфігурації. Можливо, це вимагає не перенесення змінених рядків, а повної переробки доданого (зміненого) коду під функціонал нової конфігурації постачальника.
Порівняння форм, таблиць та модулів об'єктів у конфігурації виконується з достатнім ступенем деталізації (Малюнок 17). Цього цілком достатньо для ухвалення рішень.
Але в деяких випадках дані у звітах про порівняння подаються у вигляді, що не дозволяє прийняти рішення швидко. Наприклад, у разі зміни типу реквізитів, що мають складовий тип даних, склад, що вводяться на підставі об'єктів тощо. Саме на даному етапі, зважаючи на його складність, відбувається втрата доробок при оновленні. Розглянемо цю ситуацію з прикладу реквізитів, мають складовий тип даних. При формуванні звіту про порівняння об'єктів (Малюнок 17) розрізняються дані в порівнюваних конфігураціях представлені у вигляді списків, що містять склад типів даних, розділених комами. При цьому у звіті зовсім не видно, які типи даних було додано або видалено. Звичайно, для виявлення відмінностей звіт можна роздрукувати та скрижити. У прикладі таких об'єктів близько 200. Очевидно, що процес порівняння видається досить трудомістким і складе близько 50 годин.
Для зниження трудомісткості робіт при порівнянні об'єктів можна скористатися конфігурацією, розробленою компанією Інформ Сервіс. Приблизно в 20 разів може бути знижена трудомісткість робіт при порівнянні складових об'єктів.
Конфігурація «Порівняння осередків» запускається в режимі 1С:Підприємство та дозволяє подати інформацію зі звіту про порівняння об'єктів у наочному вигляді (Малюнки 18 та 19). Для порівняння використовуються можливості 1С:Підприємства 8.
Схема роботи конфігурації проста. У конфігураторі створюємо звіт про порівняння об'єктів (Малюнок 17) та зберігаємо у файл, наприклад Звіт Порівнянні.mxl. Відкриваємо 1С:Підприємство і в діалозі (Малюнок 18) вибираємо збережений файл і вказуємо комірки, що порівнюються. Для цього двічі клацаємо правою кнопкою миші на вибраному осередку табличного документа. По кнопці «Порівняти» отримуємо результат порівняння, в якому різні позиції виділені кольором (Малюнок 19).
Особливу увагу слід приділити шаблонам RLS за зміненими ролями користувачів.
Після завершення оновлення та перенесення, раніше зроблених змін типової конфігурації виконаємо синтаксичний контроль модулів та перевіримо роботу змінених об'єктів. Після успішного тестування процес оновлення конфігурації можна вважати завершеним. Тепер залишилося оновити зовнішні друковані форми, звіти та обробки. Для деяких конфігурацій необхідно перевірити форми звітності, підключені як зовнішні.
Етап 3. Здача робіт.
У наведеному прикладі обсяг робіт з виправлення помилок, допущених при попередніх оновленнях, а також щодо оновлення на версію 1.2.14.1 та перенесення раніше внесених до типової конфігурації змін становить близько 100-150 годин. Виконати такий обсяг робіт, виконуючи оновлення безпосередньо в базі замовника, неможливо. Відповідно, підготовчі роботи необхідно виконати на копії бази даних, а результат оновлення перенести в робочу базу замовника.
Спочатку уважно вивчаємо інструкцію з дистрибутива постачання. Виконуємо необхідні роботи перед оновленням у робочій базі.
Якщо у робочій базі даних замовника під час підготовки оновлення не проводилися роботи зі зміни конфігурації, а оновлення готувалося на актуальній копії робочої бази даних, то для перенесення налаштувань збережемо робочу конфігурацію у файл, наприклад work_2.cf, вибравши пункт меню «Конфігурація» U94; "Зберегти конфігурацію у файл...".
- використовуючи файл work_2.cf, переносимо зміни. Для цього виберіть пункт меню «Конфігурація» U94; "Завантажити конфігурацію з файлу ...";
- на питання про оновлення конфігурації бази даних відповімо згодою.
Якщо в робочій базі даних замовника під час підготовки оновлення проводилися роботи зі зміни конфігурації, ці зміни необхідно також відобразити при оновленні.
Якщо оновлення готувалося не на актуальній копії робочої бази даних, то для перенесення налаштувань скористаємося методикою використаною на першому етапі. Для цього нам знадобиться файл *.cf типової конфігурації постачальника (1.2.14.1) і результат оновлення у вигляді *.cf файлу. Для цього збережемо робочу конфігурацію до файлу, наприклад work_2.cf, вибравши пункт меню «Конфігурація» U94; "Зберегти конфігурацію у файл...".
Подальші дії на стороні замовника будуть такі:
- створити резервну копіюбази даних;
- використовуючи файл *.cf типової конфігурації постачальника, виконаємо оновлення. Для цього виберіть пункт меню «Конфігурація» U94; "Підтримка" U94; "Оновити конфігурацію", "Вибір файлу оновлення", "Готово" (Малюнок 10), "Виконати";
- використовуючи файл work_2.cf, переносимо зміни. Для цього виберіть пункт меню «Конфігурація» U94; "Порівняти, об'єднати з конфігурацією з файлу ...";
- збережемо зміни робочої конфігурації та оновимо конфігурацію бази даних. Для цього виберіть пункт меню «Конфігурація» U94; "Оновити конфігурацію бази даних".
Особистий досвід: як швидко та без зайвих витрат оновити змінену конфігурацію
Оновлювати конфігурацію на кілька релізів дуже небезпечно. Справа в тому, що після кожного оновлення конфігурації запускається оновлення інформаційних баз у режимі "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% оновлень можна сміливо оновлювати за цією інструкцією.
