Отже, ми хочемо внести зміни в типову конфігурацію 1С: Бухгалтерія підприємства, редакція 3.0 (3.0.9.4).
1. Йдемо в налаштування підтримки: Меню Конфігурація -\u003e Підтримка -\u003e Налаштування підтримки;
2. Включаємо можливість зміни натисканням однойменної кнопки. Погоджуємося з попередженням про неможливість надалі автоматичного оновлення;
3. Налаштування правил підтримки залишаємо за замовчуванням, тобто «Об'єкт постачальника не редагується» і тиснемо ОК. Тепер можливість зміни включена, але жоден об'єкт конфігурації не доступний для редагування;
4. Якщо ми збираємося змінити, наприклад, документ РеалізаціяТоваровУслуг, в налаштуванні підтримки знаходимо цей документ. Якщо потрібно додати реквізит, доведеться змінити правило підтримки самого об'єкта документ РеалізаціяТоваровУслуг. Міняємо правило підтримки на «Редагується зі збереженням підтримки», при цьому правила підлеглих об'єктів документа РеалізаціяТоваровУслуг (реквізити, табличні частини, форми і т.д.) залишаються без змін, тобто «Не редагується». Реквізит ми, ймовірно, захочемо розмістити на формі, тому змінюємо правило підтримки форми нашого документа на «Редагується зі збереженням підтримки»;
5. Тепер ми можемо додати реквізит, розмістити його на формі і змінити модуль документа. Додаємо «МойРеквізіт», тип Булево. Далі відкриваємо форму документа і перетягуємо «МойРеквізіт» з «Об'єкту» на форму, а в модуль документа в процедурі «ПріЗапісі» додаємо рядки:
// >>> <<<
Виділяємо додані рядки «фірмовим» коментарем, Це полегшить там життя при оновленні (в ідеальному випадку описуємо навіщо все це було зроблено);
6. Оновлюємо конфігурацію бази даних, щоб в режимі «Підприємство» відбилися всі зроблені нами доопрацювання. Перевіряємо в режимі Підприємство все що ми зробили. На формі документа «Реалізація товарів і послуг» з'явився прапорець «Мій реквізит», а при збереженні документа отримуємо повідомлення про стан цього прапорця.
Ось ми і внесли нехитрі доопрацювання в типову конфігурацію.
Тепер спробуємо відновити нашу вже нетипову конфігурацію, зберігши в оновленій конфігурації всі зроблені доопрацювання.
1. Повертаємося в меню Конфігурація -\u003e Підтримка і вибираємо "Оновити конфігурацію». Вибираємо файл оновлення або довіряємо платформі його знайти. Натискаємо "Готово" і продовжуємо оновлення;
2. Оскільки у нас включена можливість зміни, оновлення проходить не в автоматичному режимі, а запускається механізм порівняння і об'єднання конфігурацій.
До цього моменту в нашій базі міститься вже три конфігурації: Основна конфігурація (та яку ми можемо змінювати), Конфігурація постачальника (абсолютно типова) і конфігурація бази даних. Конфігурація бази даних в порівнянні і об'єднанні не бере, зате беруть участь дві інші: «Основна конфігурація», «Конфігурація постачальника» і третя - «Нова конфігурація постачальника».
Отже, перед нами список відмінностей Основний конфігурації від Нової конфігурації постачальника. У цьому списку для нас найцікавіше - це об'єкти які ми доробляли, і не просто допрацьовували ми, а й допрацьовував постачальник, в них потрібно залишити все те що було зроблено нами, але і привнести нововведення придумані постачальником типової конфігурації.
Ми пам'ятаємо, що в порівнянні брало участь три конфігурації (Основна, Постачальника стара і Постачальника нова), платформа дає нам можливість побачити ті об'єкти, які змінили і ми і постачальник.
Застосуємо фільтр (тиснемо кнопку «Фільтр») і встановлюємо прапорець «Показувати тільки двічі змінені властивості». Натискаємо ОК і бачимо, що в новому релізі постачальник теж вніс свої зміни в документ РеалізаціяТоваровУслуг. Аналізуємо зміни в оновленні. У нашому випадку ми можемо просто встановити режим об'єднання для модуля документа РеалізаціяТоваровУслуг і його форми: «Об'єднати з пріоритетом нової конфігурації постачальника». Якби ми залишили режим за замовчуванням ( «Взяти з нової конфігурації постачальника»), то всі зроблені нами доопрацювання були б втрачені;
3. Відключимо фільтр і переконаємося, що знятий прапорець з доданого нами реквізиту «МойРеквізіт». Такий реквізит в конфігурації постачальника відсутня, якщо поставимо прапорець - втратимо реквізит, а разом з ним і дані, які в ньому зберігалися, «МойРеквізіт» заміниться «відсутнім реквізитом»;
4. Натискаємо «Виконати». Налаштування правил підтримки залишаємо за замовчуванням і тиснемо ОК;
5. Після того як процес об'єднання завершиться, шукаємо в дереві Основний конфігурації документ РеалізаціяТоваровУслуг. Переконаємося що «МойРеквізіт» нікуди не зник, подивимося на форму - і там він на місці, заглянемо в модуль. У ньому у вигляді коментарів вставляються всі відмінності модуля непріоритетної конфігурації фрагменти тексту. На початок кожного рядка вставляється фрагмента тексту додається подвійний слеш (два символу косої риси), що в тексті програмного модуля робить ці рядки закоментовано. Крім того, для полегшення подальшої роботи з результуючим текстом, в нього вставляються спеціальні рядки-коментарі.
Змінені фрагменти обрамляются зверху і знизу рядками
// ((MRG [<-> ]
додані
// ((MRG [<-- ]
віддалені
// ((MRG [-\u003e]
У нашому модулі ми бачимо що платформа всі наші труди закоментувавши, але хоч не видалила:
// ((MRG [<-> ] // // \u003e\u003e\u003e // Повідомити (ЕтотОб'ект.МойРеквізіт); // //<<< //}}MRG[ <-> ]
Приберемо зайві коментарі:
// \u003e\u003e\u003e Повідомити (ЕтотОб'ект.МойРеквізіт); //<<<
6. Оновимо конфігурацію бази даних. Подивимося на результат, запустивши режим Підприємство. Бачимо що після поновлення все доопрацювання збереглися і функціонують так само як і до оновлення, а номер релізу змінився на 3.0.10.8.
Нетипова конфігурація 1С, це коли: 1) конфігурація 1С написана з нуля самостійно програмістом, 2) конфігурація 1С була типовою, але в неї додали зміни, навіть якщо додали один реквізит.
У даній статті ми розглянемо, як необхідно коректно оновлювати конфігурації 1С, а також кілька прийомів по м'якому зміни типових конфігурацій, тобто правильному зміни, яке не впливатиме на можливість подальшого оновлення.
Для того, щоб внести будь-які зміни в типову конфігурацію 1С, необхідно розблокувати зміна типової конфігурації 1С, а в деяких випадках «зняти її з підтримки».
У самому оптимальному варіанті поновлення конфігурація 1С може оновлюватися в повністю автоматичному режимі, це можливо, коли у нас заборонені зміни конфігурації. Досить часто потрібно включати зміну конфігурації, оскільки необхідна адаптація прикладних рішень під бізнес-вимоги замовника, на цьому варіанті ми і зупинимося.
Перш ніж виконувати оновлення настійно рекомендується зробити резервну копію бази даних, зробити це можна через меню Адміністрування / вивантажити інформаційну базу.
Існує 2 варіанти поновлення: а) Оновлення 1С через підтримку (виклик через діалог Конфігурація / Підтримка / Оновити конфігурацію) і б) через Порівняння об'єднання з конфігурацією з файлу. Слід звернути особливу увагу, що різниця між цими двома пунктами в тому, що в першому випадку оновлюється і основна конфігурація і конфігурація постачальника, а при порівнянні об'єднанні конфігурацій оновлюється тільки основна конфігурація, конфігурація постачальника залишається старою. Таким чином найбільш рекомендованим варіантом є оновлення через Оновити конфігурацію. Для поновлення через Підтримку конфігурації використовуються файли поставки постачальника CF або CFU, які можна знайти пошуком, в каталозі шаблонів, вказавши шлях в Інтернеті, або безпосередньо вказати шлях до потрібного файлу на жорсткому диску.
При оновленні конфігурації 1С без можливості внесення змін оновлення після вибору файлу оновлення відбувається в автоматичному режимі, якщо в конфігурації включена можливість внесення змін, тоді після вибору файлу оновлення буде виведено вікно порівняння конфігурацій. У цьому діалозі ми можемо побачити як система пропонує нам оновити нашу нетипову конфігурацію 1С. У нижній частині діалогового вікна розташована відповідна легенда по статусах об'єктів: "Статуси по відповідностям об'єктів" позначають порівняння "Основний конфігурації" і "Нової конфігурації", "Статуси з історії об'єктів" позначають порівняння об'єктів конфігурацій з об'єктами "Старої установки постачальника".
Проставляючи прапорці поруч з об'єктами, можна вибирати, зміняться поточний об'єкт конфігурації, або залишиться старим, а також спосіб зміни об'єкта. В меню дії є можливість проставити галочки по підсистемах (це корисно, якщо конфігурація знаходиться на підтримці у кількох постачальників). Також в цьому меню є можливість вказати пріоритет об'єднання для всіх об'єктів разом, за замовчуванням система вважає більш пріоритетним конфігурацію постачальника. Налаштування фільтру дозволяють вказати, які об'єкти конфігурації нам варто виводити для можливості детального вказівки режиму об'єднання. Існують кілька стандартних шаблонів фільтра, крім цього можна вказати фільтри для кожної пари порівнюваних конфігурацій. Є можливість встановити в налаштуваннях "Фільтр" галочку "Показувати тільки двічі змінені властивості", це дозволить відсіяти об'єкти, при оновленні яких не виникло конфліктів між змінами постачальника і доробками цих об'єктів:
Отже, в результаті вийде список об'єктів, двічі змінених при доопрацюванні типової конфігурації і в новій конфігурації постачальника. Якщо погодитися з оновленням, то зроблені раніше доопрацювання в цих об'єктах будуть загублені. Тому по кожному об'єкту необхідно прийняти рішення про те, яким чином він буде оновлений. На цьому етапі слід виконати попереднє порівняння виключно для того, щоб зменшити обсяг робіт в подальшому. Оцінка не точна швидка - "на око". Якщо змін в об'єкті більше в новій конфігурації постачальника, то залишаємо екземпляр об'єкта постачальника. Ми залишаємо галочку. Потім потрібно буде перенести зміни з робочої конфігурації. Якщо змін в об'єкті більше в робочій конфігурації, то залишаємо екземпляр об'єкта робочої конфігурації. Знімаємо галочку. Потім потрібно буде перенести зміни з установки постачальника. З модулями можна поступити трохи інакше, тому що є можливість порівнювати модулі попроцедурно.
Тобто в разі, якщо в нашій конфігурації 1С і в конфігурації постачальника змінені різні процедури модуля, то, правильно розставивши, галочки ми позбавимо себе від ручного перенесення змін коду. Щоб до цього дістатися, необхідно натиснути кнопку у вигляді лупи поруч з назвою режиму об'єднання модулів:
При виведенні меню дій по об'єкту (наприклад натисненням правої кнопки миші) ми можемо викликати звіт про порівняння об'єктів.
Щоб підтвердити проведене оновлення 1С - потрібно вибрати пункт меню Конфігурація / Оновити конфігурацію бази даних.
Щоб відмовитися від поновлення 1С - потрібно вибрати пункт меню Конфігурація / Повернутися до конфігурації БД.
Кілька правил, які спрощують майбутнє оновлення конфігурацій 1С:
Основне правило поновлення 1С: потрібно додавати нові об'єкти, тому що при оновленні нові об'єкти системою не будуть зачіпатися
При зміні текстів модулів бажано також додавати свої нові процедури і функції, а з існуючих викликати свої нові
Використання підписок на події, завдяки цьому можна допрацьовувати типові механізми, не змінюючи типового коду
Використання типового функціоналу конфігурацій
Програмне створення елементів форми (В подію ПріСозданііФормиНаСервере)
Спасибі!
У цій статті буде розказано про оновлення нетипової конфігурації 1С (редакцій 8.2 і 8.3), зі збереженням всіх змін внесених вами (або іншими розробниками) в типову конфігурацію 1С 8.
Розглянемо приклад оновлення конфігурації Бухгалтерія 2.0 з нетиповими змінами в модулях, ролях, підписках на події, плани обміну і т.д. Розглянуті тут випадки не будуть надто складними для поновлення, за їх допомогою я лише покажу методику оновлення, що дозволить вам розібратися зі своїми випадками.
Оновлення нетипової конфігурації 1С покрокова інструкція
Розглянемо по кроках алгоритм оновлення конфігурації 1С 8. Даний алгоритм є універсальним, перші одинадцять його кроків описують процес оновлення будь-який типовий конфігурації 1С 8, а всі пункти в сукупності описують оновлення нетипової конфігурації 1С 8:
- Скачайте файл оновлення конфігурації з сайту users.v8.1c.ru або отримаєте його з будь-яких інших доступних джерел (наприклад з диска ІТС);
- Розпакуйте і встановіть файл з оновленням 1С 8 в будь-яку папку на жорсткому диску;
- В папці з номером релізу 1С 8 знайдіть файл 1cv8.cfu - саме цей файл містить оновлення конфігурації;
- запустіть 1с Підприємство в режимі Конфігуратор;
- Перейдіть в меню Конфігурація -\u003e Підтримка -\u003e Оновити конфігурацію.
- У віконці «Оновлення конфігурації» встановлюємо прапор на пункті Вибір файлу поновлення і тиснемо кнопку далі (Якщо хочете то можна скористатися і першим пунктом Пошук доступних оновлень і пошукати файли оновлень в автоматичному режимі) ;
- В поле «Вкажіть файл оновлення» виберіте.cfu файл з папки з номером релізу. Зауважте, що оновити конфігурацію бази 1С 8 годі й на будь-який реліз. Для кожного файлу поновлення існує список релізів для яких він призначений. Тому можливо доведеться встановлювати кілька файлів оновлення послідовно;
- У наступному вікні ви побачите опис цього оновлення. Також в ньому можна подивитися для поновлення яких версій конфігурації призначений даний файл. Натисніть кнопку продовжити оновлення;
- Якщо дану версію конфігурації неможливо оновити обраним файлом, то вам буде видано віконце з підказкою, які релізи слід встановити;
- Якщо обраний файл підходить для оновлення конфігурації, то з'явиться вікно з даними про версію оновлення. Для продовження поновлення натисніть кнопку ОК;
- Після цього запуститься процес оновлення. Якщо ваша конфігурація типова, то по його завершенні залишиться тільки погодиться змінити поточну конфігурацію і запустити 1С 8 в режимі підприємство;
- Якщо ж ви оновлюєте конфігурацію зі змінами (нетипової), то після завершення процесу оновлення з'явиться вікно порівняння-об'єднання старої та нової конфігурації.
Оновлення нетипової конфігурації 1С розбір прикладу
Перейдемо до докладного розбору правильного поновлення нетипової конфігурації 1С 8. Вся проблема поновлення такої конфігурації полягає в тому, що в типові об'єкти метаданих (загальні модулі, ролі, документи, довідники і т.д.) внесені сторонні зміни. Треба зробити так, що б всі ваші зміни залишилися на своєму місці, в цілості й схоронності, але при цьому всі зміни фірми 1С, що містяться в файлі поновлення, теж були застосовані. Саме для цього при оновленні зміненої конфігурації з'являється вікно порівняння основний конфігурації(З вашими змінами) та Нової конфігурації постачальника(Оновлена \u200b\u200bтипова конфігурація).
В даному вікні присутній дві колонки, кожна з яких містить дерево метаданих. У першій показані метадані поточної конфігурації бази даних, а в другій оновлені метадані установки постачальника (оновлена \u200b\u200bтипова конфігурація). Зеленими олівчик відзначені змінені об'єкти, в першому стовпці позначені змінені вами типові об'єкти метаданих, а в другому змінені оновленням типові об'єкти метаданих. Таким чином, щоб зробити правильне оновлення нетипової конфігурації 1с, потрібно знайти всі об'єкти метаданих, які змінені і вами і оновленням (тобто двічі змінені).
Для це натисніть розташовану внизу вікна кнопку Фільтр, У вікні, встановити прапор і натисніть ОК.
Тепер у вікні порівняння буде видно тільки потрібні нам об'єкти, що значно полегшує процес оновлення. Слід зауважити, що якщо у вашій конфігурації додані нові нетипові документи, довідники, ролі, модулі і т. П., То їх оновлення конфігурація не затре, вони залишаться на своєму місці і нічого з ними не станеться. Проблему становлять лише змінені типові об'єкти.
Для правильного поновлення різних об'єктів метаданих потрібен свій підхід, тому розглянемо на нескладних прикладах різні ситуації. Зауважу також, що оновлення сильно переписаних конфігурацій завдання складне і вимагає максимальної уважності і зосередження.
Оновлення загального модуля.
- Розглянемо приклад: У загальний модуль КонтрольВерсііКонфігураці ви внесли такі зміни:
- У процедурі ПроверітьВерсіюКонфігураціі ()закоментувавши рядок: //ОткритьФормуМодально("ОбщаяФорма.НерекомендуемаяВерсіяКонфігураціі ", Параметри);
- Додали в модуль свою процедуру з ім'ям МояТестоваяПроцедура ().
При оновленні цей модуль змінився, поставивши в вікні порівняння фільтр по двічі зміненим ми побачимо, що він потрапив в список.
Розглянемо докладніше це вікно, і зрозуміємо яку інформацію з нього ми зможемо почерпнути. По-перше, ми бачимо, що загальний модуль змінений і в основний конфігурації і в оновленій конфігурації постачальника, про це говорять зелені олівчик в обох стовпчиках. По-друге, в першому стовпці ми бачимо встановлений прапорець біля імені загального модуля, він говорить про те, що буде вироблено об'єднання модулів (того, що змінений нами і типового оновленого). По-третє, в останньому стовпчику ми бачимо в якому режимі відбудеться об'єднання модулів. В даному випадку встановлено значення: Взяти з нової конфігурації постачальника, це означає, що наші зміни будуть повністю затерті, а зміни внесені оновленням будуть повністю застосовані.Інші режими об'єднання пропонують часткове об'єднання модулів, з різними пріоритетами. Але я вам настійно рекомендую не використовувати ці режими, так як після цього в вашому модулі може вийти натуральна «каша»: деякі ваші зміни будуть затерті, а деякі типові зміни не застосовуються. Тому змінювати значення в стовпці Режим об'єднання ...ми ніколи не будемо. По-четверте, якщо зняти галку встановлену в першому стовпці навпроти модуля, то об'єднання проводитися не буде і модуль залишиться в тому вигляді в якому він був до обновленія.Ісходя з перерахованих пунктів є два способи відновити загальний модуль:
- Затерти ваші зміни встановивши типові. Після чого вручну внести затерті зміни в оновлений модуль;
- Не оновлювати модуль і внести типові зміни вручну.
Механізми порівняння конфігурацій
Для порівняння змін в модулі можна скористатися наступними вбудованими механізмами вікна порівняння-об'єднання конфігурацій:
- Перегляд відмінностей в модулях. Для цього у вікні порівняння клацніть на модулі правою кнопкою миші виберіть пункт Показати відмінності в модулях ... Після чого відкриється вікно порівняння модулів, в якому можна побачити, які саме процедури в оновленому і зміненому вами модулі розрізняються. Верхня частина екрану розділена на дві колонки: у лівій представлений список процедур основний конфігурації, які були змінені, а в правій аналогічний список процедур оновленої типової конфігурації. Нижня частина вікна також розділена на дві частини, за тим же принципом. У ній відображається код виділених процедур. Рядки, які присутні тільки в основний конфігурації виділені синім кольором. Рядки, які присутні тільки в оновленій типової конфігурації виділені зеленим кольором. Рядки, які присутні в обох конфігураціях, але не збігаються між собою, виділені червоним кольором.
- . Для порівняння модулів також можна використовувати звіт про порівняння об'єктів. Щоб викликати його у вікні порівняння клацніть на модулі правою кнопкою миші виберіть пункт У вікні, в області формат, встановіть прапорець Детально. У відкритому звіті можна побачити, які рядки модуля змінені і як вони виглядають в обох конфігураціях.
Не дивлячись на те, що даний звіт надає всю інформацію про зміни, він не зручний в роботі (принаймні при оновленні модулів). Набагато цікавіші дві його модифікації: Про тчет про порівняння об'єктів основної конфігурації зі старою конфігурацією постачальника (В цьому звіті видно тільки зміни внесені вами) і (В цьому звіті видно тільки лише зміни внесені в модуль оновленням).
За допомогою першого звіту можна побачити у скількох місцях внесені ваші зміни в модулі, це дозволить швидко знайти їх у вікні Перегляду відмінностей в модулях.У другому ж звіті можна побачити у скількох місцях типове оновлення внесло свої зміни.
Ми розібрали всі інструменти необхідні для поновлення модуля. Для того, що б показати їх практичне застосування розглянемо по кроках процес оновлення модуля КонтрольВерсііКонфігураці з перерахованими вище змінами. Оновимо модуль двома способами:
- Оновимо модуль, затерев внесені в нього зміни. Внесемо їх вручну після поновлення;
- Не будемо оновлювати модуль. Зміни отримані в оновленні внесемо після.
Перший спосіб:
- Перед описом алгоритму зауважу, що ми розглядаємо дуже простий приклад оновлення, для того щоб опис не зайняло дуже багато місця, але процес відновлення в складному випадку складається з точно таких етапів, хоча і вимагає більшої зосередженості і уважності;
- Перед оновленням конфігурації створимо текстовий документ. У нього ми будемо записувати зміни, які необхідно буде внести вручну, після оновлення. Дані в текстовому документі повинні бути представлені максимально зрозумілим чином, тобто бути структуровані. У нашому прикладі будемо писати так: 1. Загальні модулі 1.1 КонтрольВерсііКонфігураці
- Знайдемо загальний модуль КонтрольВерсііКонфігураці Модуль. Кликнемо по ньому правою кнопкою миші і в контекстному меню виберемо пункт Про тчет про порівняння об'єктів основної конфігурації зі старою.У вікні, поставимо прапор Детально.Також я встановлюю прапор Виводити в Текстовий документ, Тому що так зручніше дивитися зміни, але це вже справа звички. натиснемо кнопку ОК.Відкрився звіт матиме такий вигляд:
- Із звіту видно, що в модуль внесено дві зміни (перед кожним новим зміною пишуться номери рядків, в яких воно внесено):
- Змінено рядок 34, в основний конфігурації вона закоментований, а в старій конфігурації постачальника немає;
- Додана процедура, в старій конфігурації постачальника на її місці порожньо, а в основний конфігурації вона є. Звіт не закриваємо, він нам стане в нагоді;
- Тепер знайдемо перша відмінність у вікні порівняння модулів. Для цього знову натискаємо правою кнопкою миші по гілці модуль і в контекстному меню вибираємо пункт Показати відмінності в модулях ... Так як у вікні порівняння модулів не видно номерів рядків (глобальної нумерації), то для того щоб знайти перша зміна перегорнемо всі процедури у верхній половині вікна. Також зі звіту ми знаємо, що перша зміна пов'язана зі зміною рядка, тому шукаємо текст виділений червоним кольором. Змінена рядок знайдеться в процедурі ПроверітьВерсіюКонфігураціі ().
- Відкриємо текстовий документ, створений для запису змін. Пунктом «1.1.1» запишемо там назва процедури, в якій знаходиться зміна. Після цього нам треба вписати в нього знайдене зміна так, що б ми легко могли знайти його в тексті модуля. Для цього я зазвичай копіюю в документ не одну, а відразу кілька рядків процедури, до і після змін. Але в даному випадку процедура маленька і тому досить скопіювати саму змінену рядок. Вийде такий запис: 1. Загальні модулі 1.1 КонтрольВерсііКонфігураці 1.1.1 ПроверітьВерсіюКонфігураціі //ОткритьФормуМодально("ОбщаяФорма.НерекомендуемаяВерсіяКонфігураціі ", Параметри);
- Тепер знову відкриємо звіт про порівняння конфігурацій, подивимося наступне зміна і також знайдемо його у вікні порівняння модулів. На цей раз це додана нова процедура. Так як дана процедура повністю відсутня в старій конфігурації постачальника, то її текст буде виділений синім шрифтом:
- Знову відкриємо текстовий документ, створений для запису змін. У пункт «1.1.2» запишемо назву доданої процедури. Після цього скопіюємо туди весь текст доданої процедури. 1.1.2 МояТестоваяПроцедура Процедура МояТестоваяПроцедура () Експорт // Текст процедури КонецПроцедури
- КонтрольВерсііКонфігураці встановлений прапор, що означає, що даний модуль слід оновити, затерев всі внесені зміни;
- Далі необхідно записати в текстовий документ зміни інших двічі змінених об'єктів метаданих. Але так як в даному прикладі ми розглядаємо конкретний загальний модуль, то пропустимо цей етап;
- Після того, як робота над двічі зміненими об'єктами виконана, у вікні порівняння / об'єднання натискаємо кнопку виконати;
- Якщо з'явиться вікно з текстом «Існують об'єкти, змінені в основний конфігурації ...», натискаємо кнопку Так;
- У наступному вікні Налаштування правил підтримки не змінюємо ніяких налаштувань, а просто натискаємо кнопку Так;
- Останнім з'явиться повідомлення: «Об'єднання конфігурацій завершено». тиснемо кнопку ОК;
- Збережемо конфігурацію за допомогою меню Файл -\u003e Зберегти, піктограми зберегти (Синя дискета) або поєднання клавіш Ctrl + S;
- Після того як конфігурація збережена, відновимо затерті зміни модуля. У дереві метаданих знайдемо і відкриємо модуль КонтрольВерсііКонфігураці;
- Відкриємо текстовий документ в який занесені зміни даного модуля;
- У пункті «1.1.1» вказана процедура ПроверітьВерсіюКонфігураціі, знайдемо її в модулі і розкриємо;
- У текстовому документі зазначено, що слід закомментировать рядок: ОткритьФормуМодально ( "ОбщаяФорма.НерекомендуемаяВерсіяКонфігураціі", Параметри);
Знайдемо її в модулі і встановимо коментар;
- У пункті «1.1.2» вказана процедура МояТестоваяПроцедура, яку необхідно додати в модуль. Копіюємо її з текстового документа і вставляємо в кінець модуля;
- Зберігаємо конфігурацію одним із зазначених вище способів;
- Оновлення конфігурації на цьому завершено, залишилося тільки оновити конфігурацію, скориставшись клавішами F5 або F7 або відповідними піктограмами, і в режимі 1С: Підприємства підтвердити легальність поновлення;
- Другий спосіб:
- Другий спосіб повністю повторює перший, за винятком того, що діє він від зворотного. Тому опишу його коротко;
- Створюємо текстовий документ з такою ж структурою;
- сформуємо звіт Звіт про порівняння об'єктів нової конфігурації постачальника зі старою конфігурацією постачальника;
- Використовуючи сформований звіт і вікно порівняння модулів випишемо в текстовий документ зміни внесені новою конфігурацією постачальника;
- У вікні порівняння / об'єднання конфігурацій перевіряємо, що біля модуля КонтрольВерсііКонфігураці ЗНЯТО ПРАПОР. Це означає, що даний модуль НЕ буде оновлюватися;
- Оновлюємо конфігурацію, вносимо зміни з текстового документа в модуль КонтрольВерсііКонфігураці.
Оновлення плану обміну.
Розглянемо приклад: до складу плану обміну ПоОрганізаціі ви включили довідник ВнешніеОбработкі.При оновленні нетипової конфігурації 1с склад даного плану обміну змінився і перед нами стоїть завдання правильно оновити план обміну, які не затерев ні типові зміни, ні свої. Інструменти використовуються для порівняння змінених об'єктів метаданих були докладно описані в попередніх пунктах, тому для даного випадку все буде описано коротко.
Розглянемо по кроках оновлення складу плану обміну ПоОрганізаціі із зазначеними змінами:
- У створений при оновленні загального модуля текстовий документ додамо нові рядки: 2. Плани обміну 2.1 ПоОрганізаціі
- Знайдемо план обміну ПоОрганізаціі у вікні порівняння / об'єднання, розкриємо його до гілки Склад.Зауважу, що в плані обміну вами може бути змінений і модуль, його треба оновлювати за правилами описаним для загального модуля. В даному випадку нас цікавить саме оновлення складу плану обміну;
- Як і у випадку з загальним модулем, склад плану обміну можна або оновити, після цього додавши свої зміни вручну, або не оновлювати, додавши типові зміни вручну. Якщо ваших змін в складі більше, ніж типових, то оновлювати краще другим способом, якщо менше то першим. Подивитися яких змін більше можна за допомогою все тих же звітів:
- У нашому прикладі типових змін більше, тому випишемо в текстовий документ наші зміни: 2. Плани обміну 2.1 ПоОрганізаціі - *** Довідники - -\u003e Справочнік.ВнешніеОбработкі
- Перевіряємо, що в вікні порівняння / об'єднання встановлена \u200b\u200bгалочка біля плану обміну ПоОрганізаціі;
- Зберігаємо конфігурацію;
- Після того як конфігурація збережена, відновимо затерті зміни плану обміну. У дереві метаданих знайдемо і відкриємо план обміну ПоОрганізаціі;
- У пункті «2.1» текстового документа вказано довідник ВнешніеОбработкі,знайдемо його в дереві метаданих складу плану обміну і встановимо прапор, що означає участь довідника в обміні;
- Збережемо і відновимо конфігурацію;
Оновлення підписки на подію.
Розглянемо приклад: в джерело підписки на подію ПередУдаленіемСправочнікаДляОбменаПоОрганізаціі ви включили довідник ВнешніеОбработкі.При оновленні складу джерел змінився, завдання аналогічна попереднім - виконати оновлення нетипової конфігурації 1с правильно.
Розглянемо по кроках оновлення складу джерел підписки на подію з зазначеними змінами:
Оновлення ролей в 1С
Перед тим, як почати розповідати про оновлення ролей в 1С 8, хочеться зауважити, що краще не змінювати типові ролі, в цьому немає ніякої необхідності, до того ж сильно ускладнюється оновлення нетипової конфігурації 1с. Якщо ви допрацьовуєте якусь типову конфігурацію і додаєте в неї свої документи, довідники і т.д., то створіть свою роль (або кілька, в залежності від ситуації), в яку включіть нові об'єкти метаданих. Якщо ви так не зробите, то з часом вам буде дуже важко оновлювати типові ролі (а під час неможливо), так як майже в кожному релізі вони сильно змінюються і звіти про порівняння конфігурацій можуть виглядати не дуже зрозуміло.
Але все ж часто бувають випадки коли роль вже змінена, і не один раз, а розбиратися навіщо і чому часу немає. Тому розглянемо приклад: у типовій ролі Бухгалтер для довідника Податкові органидодані права на читання і перегляд, при оновленні набір прав ролі також був змінений.
Розглянемо оновлення ролі по кроках:
- знайдемо роль Бухгалтеру вікні порівняння / об'єднання, розкриємо її до гілки права;
- В даному прикладі в ролі всього одна зміна, але зазвичай буває не так. Тому роль набагато простіше не оновлювати, а типові зміни вносити вручну;
- сформуємо Звіт про порівняння об'єктів нової конфігурації постачальника зі старою конфігурацією постачальника. Зазвичай в ньому дуже багато інформації, але далеко не вся потрібна для поновлення:
- Залишаються або додані нові об'єкти метаданих, які зміни прав для старих:
- Додані об'єкти виглядають так: - -\u003e
При додаванні нового об'єкта в звіті не виводяться дані про те, які права необхідно для нього встановити. Тому після оновлення можна або подивитися їх розстановку в конфігурації постачальника, або встановити всі доступні.
- Змінені об'єкти виглядають так: - *** Довідники - *** НалоговиеОргани - *** Права - *** Читання - *** Значення -\u003e Дозволено<--Запрещено
- ***Просмотр
- ***Значение
-->дозволено<--Запрещено
При цьому детально зазначено, які права змінилися;
- Додані об'єкти виглядають так: - -\u003e
- У нашому прикладі з корисною інформацією в звіті про порівняння знаходиться лише один рядок, додаємо її в текстовий документ: 4. Ролі 4.1 Бухгалтер - -\u003e Об'єкт - РегламентірованнийОтчетСтатістікаФорма11НА
При цьому можна вказати який це об'єкт метаданих, але в даному випадку і так видно, що звіт;
- У вікні порівняння / об'єднання знімемо галочку біля ролі Бухгалтер;
- Після цього необхідно записати в текстовий документ зміни інших двічі змінених об'єктів метаданих і виконати оновлення (процес детально описаний вище);
- Зберігаємо конфігурацію;
- Після того як конфігурація збережена, необхідно внести типові зміни в роль Бухгалтер. У дереві метаданих знайдемо і відкриємо цю роль;
- У пункті «4.1» текстового документа сказано, що в роль доданий об'єкт РегламентірованнийОтчетСтатістікаФорма11НА,знайдемо його в дереві метаданих ролі, встановимо галочки на правах Використання і Перегляд;
- Збережемо і відновимо конфігурацію.
На цьому стаття про Оновлення нетипової конфігурації 1С завершена. Якщо після прочитання у вас залишилися питання - сміливо задавайте їх у коментарях! За бажанням читачів в наступній статті я можу розповісти про інші цікаві і складні аспекти поновлення нетипової конфігурації 1С 8.
Режим об'єднання можна встановити для кожного об'єднаного об'єкта. Існує два види режиму: «Взяти з завантажується конфігурації» і «Об'єднувати ...», у другому випадку зазвичай вказується пріоритет конфігурацій при об'єднанні.
Вибір «Взяти з завантажується конфігурації» означає, що об'єкт конфігурації буде додано, якщо він новий, або заміщений, якщо він змінений. Причому переноситься вся структура об'єкта, модулі, опису, форми. При цьому пріоритет однозначно віддається завантажується конфігурації.
При виборі методу «Об'єднувати ... », що відбувається при об'єднанні конфігурацій залежить від встановленого пріоритету.
Якщо з завантажується конфігурації необхідно взяти тільки нове і максимально зберегти старе, необхідно вибрати «Об'єднати» з пріоритетом основний конфігурації. В цьому режимі додаються тільки нові об'єкти.
тексти
Для модуля форми вплив вибору пріоритету на результуючий текст можна проілюструвати так.
Об'єднання властивостей об'єктів. Для об'єктів, значення властивостей яких визначаються простою вказівкою в палітрі властивостей (наприклад, Синонім, Коментар ), Залежність результату об'єднання від пріоритету і наявності значень представлена \u200b\u200bв таблиці:
| Значення в основний | Значення в завантажується | пріоритет конфігурації | Результат (значення вибирається з ...) |
| Визнач | Визнач | пріоритет основний | Основний |
| Визнач | Не задано | Основний | |
| Не задано | Визнач | завантажується | |
| Визнач | Визнач | пріоритет завантажується | завантажується |
| Визнач | Не задано | Основний | |
| Не задано | Визнач | завантажується |
Якщо властивість будь-якого об'єкта може представляти результат складеного значення об'єктів двох конфігурацій (наприклад, властивість Вводиться на підставі), то результат визначається простим об'єднанням або вибирається з завантажується конфігурації.
макетиоб'єднуються в такий спосіб:
| пріоритет | результат |
| пріоритет основний | Макет основний конфігурації залишається |
| Макет завантажується конфігурації додається, але, якщо його ім'я збігається з ім'ям макета основний конфігурації, воно змінюється (наприклад, «Макет» -\u003e «Макет!»); таким чином, з цього імені в об'єднаній конфігурації буде викликатися макет основний конфігурації, але макет завантажується теж не втрачений. | |
| пріоритет завантажується | Макет завантажується конфігурації додається |
| Макет основний конфігурації залишається, але, якщо її ім'я збігається з ім'ям макета завантажується конфігурації, ім'я макета основний конфігурації змінюється (тим самим, макет основний конфігурації не втрачений, але викликатися буде макет з завантажується конфігурації). |
Елементи управління, наявні в формі, Не відображаються у вікні «Об'єднання конфігурацій» і, тому при об'єднанні Конфігуратор робить аналіз складу форми, визначає:
список співпадаючих (за іменами) елементів управління, розташованих в межах групи елементів (сторінка форми, елемент управління, який може містити елементи управління, наприклад, табличний документ) і, в залежності від обраного режиму об'єднання, виробляє об'єднання:
Нові елементи управління додаються в форму. Збігаються елементи (за іменами) в основній формі будуть замінені (замінюються властивості, розміри і розташування), якщо обраний пріоритет завантажується конфігурації, і залишені без зміни, якщо обраний пріоритет основної форми.
Властивості елементів керування не об'єднуються. Елементи управління, що мають однакове ім'я, але розташовані на різних сторінках форм, при об'єднанні будуть присутні в формі, незалежно від обраного режиму об'єднання.
Для деяких об'єктів (реквізитів об'єктів) вибір режиму об'єднання може бути відсутнім. Так наприклад, для реквізиту з базовим типом (наприклад «Число») режим об'єднання встановлюється тільки «Взяти з завантажується конфігурації».
Для деяких об'єктів вибір пріоритетності також може бути відсутнім. Наприклад, для властивості Підсистеми можна вибрати режим об'єднання «Взяти з завантажується конфігурації» і «Об'єднати». Якщо обраний режим «Об'єднати», то при об'єднанні відбувається просте об'єднання зазначених підсистем двох конфігурацій.
Установка порядку підлеглих об'єктів
Для видів об'єктів, які можуть мати необмежену кількість підлеглих об'єктів (наприклад, підлеглі об'єкти Реквізити, Форми, Макети, Табличні частини довідників і документів), в деяких випадках важливий порядок проходження об'єктів в кожній такій групі.
Якщо в процесі порівняння конфігурацій Конфігуратор визначив відповідність об'єктів, що входять в групу, але їх порядок в конфігураціях різний, то в графі «Режим об'єднання і порядок підлеглих об'єктів» можна вказати потрібний порядок проходження об'єктів.
Для вказівки порядку виберіть будь-який підлеглий об'єкт і в третій графі виберіть варіант установки порядку: «Порядок з основної конфігурації» або «Порядок з завантажується конфігурації».
Вибір порядку діє на всі підлеглі об'єкти даного виду.
Якщо для обраного об'єкта його підлеглі об'єкти змінені і розташовані в іншому порядку, то в третій колонці можна вибрати тільки порядок. Режим об'єднання вказується в об'єкті верхнього рівня за допомогою контекстного меню. Наприклад, в обох конфігураціях для документа «Рахунок» є кілька підлеглих об'єктів типу «Форми». Вони змінені і порядок їх проходження також змінений. Для вибору режиму об'єднання вкажіть об'єкт більш вищого рівня ( «Форми» або «Рахунок») і в контекстному меню виберіть потрібний режим об'єднання.
Розглянемо оновлення на прикладі нетипової конфігурації УПП 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 буде завершено оновлюємо конфігурацію бази даних і тестуємо деякі моменти, що саме добре б протестувати стане зрозуміло в процесі оновлення, тут все індивідуально.
Оновлення в робочій базі бажано виконувати за допомогою підтримки«Конфігурація» - «Підтримка» - «Оновити конфігурацію».При цьому двічі змінені об'єкти будуть завантажені з нового релізу, тобто наші зміни затруться (конфігурація не зберігаємо!), але потім при об'єднанні з підготовленою конфігурацією ми їх відновлюємо. Після цього можна зберегти конфігурацію, оновити конфігурацію бази даних.
