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

У цій статті буде розказано про оновлення нетипової конфігурації 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с Підприємствов режимі Конфігуратор;
• Перейдіть до меню Конфігурація -> Підтримка -> Оновити конфігурацію.
  
  
• У вікні «Оновлення конфігурації», що відкрилося, встановлюємо прапор на пункті Вибір файлу оновленьі тиснемо кнопку Далі(якщо хочете, то можна скористатися і першим пунктом Пошук доступних оновленьта пошукати файли оновлень в автоматичному режимі) ;
• У полі «Вкажіть файл оновлень» виберіть файл .cfu з папки з номером релізу. Зверніть увагу, що оновити конфігурацію бази 1С 8 можна не на будь-який реліз. Для кожного файлу оновлення існує список релізів, для яких воно призначене. Тому, можливо, доведеться встановлювати кілька файлів оновлення послідовно;
• У наступному вікні ви побачите опис цього оновлення. Також у ньому можна подивитися для оновлення яких версій конфігурації призначений цей файл. Натисніть кнопку Продовжити оновлення;
• Якщо цю версію конфігурації неможливо оновити вибраним файлом, вам буде видано віконце з підказкою, які релізи слід встановити;
• Якщо вибраний файл підходить для оновлення конфігурації, з'явиться вікно з даними про версію оновлення. Щоб продовжити оновлення, натисніть кнопку ОК;
  
• Після цього розпочнеться процес оновлення. Якщо ваша конфігурація типова, то після її завершення залишиться лише погодиться змінити поточну конфігурацію та запустити 1С 8 у режимі Підприємство;
• Якщо ви оновлюєте конфігурацію зі змінами (нетипову), то після завершення процесу оновлення з'явиться вікно порівняння-об'єднання старої та нової конфігурації.

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

8. Вся проблема оновлення такої конфігурації полягає в тому, що в типові об'єкти метаданих (загальні модулі, ролі, документи, довідники і т.д.) внесені сторонні зміни. Треба зробити так, щоб усі ваші зміни залишилися на своєму місці, в цілості та безпеці, але при цьому всі зміни фірми 1С, що містяться у файлі оновлення, теж були застосовані. Саме для цього при оновленні зміненої конфігурації з'являється вікно порівняння Основний конфігурації(з вашими змінами) та Нової конфігурації постачальника(Оновлена ​​типова конфігурація).

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

Для цього натисніть розташовану внизу вікна кнопку Фільтр, у вікні встановити прапор та натисніть ОК.

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

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

Відновлення загального модуля.

• Розглянемо приклад: У загальний модуль КонтрольВерсіїКонфігураціїви внесли такі зміни:
  • У процедурі ПеревіритиВерсіюКонфігурації()закоментували рядок: //ВідкритиФормуМодально("ЗагальнаФорма.НерекомендованаВерсіяКонфігурації", Параметри);
  • Додали до модуля свою процедуру з ім'ям Моя Тестова Процедура ().

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

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

  • Затерти ваші зміни, встановивши типові. Після цього вручну внести затерті зміни в оновлений модуль;
  • Не оновлювати модуль та внести типові зміни вручну.

  Механізми порівняння конфігурацій

  Для порівняння змін у модулі можна скористатися такими вбудованими механізмами вікна порівняння-об'єднання конфігурацій:

  • Перегляд відмінностей у модулях. Для цього у вікні порівняння клацніть правою кнопкою миші на модулі виберіть пункт Показати відмінності у модулях…Після цього відкриється вікно порівняння модулів, у якому можна побачити, які саме процедури в оновленому та зміненому вами модулі різняться. Верхня частина екрана поділена на дві колонки: у лівій наведено список процедур основної конфігурації, які були змінені, а в правій аналогічний список процедур оновленої типової конфігурації. Нижня частина вікна також поділена на дві частини, за тим самим принципом. У ньому відображається код виділених процедур. Рядки, які присутні лише в основній конфігурації, виділені синім кольором. Рядки, які присутні лише в оновленій типовій конфігурації, виділені зеленим кольором. Рядки, які є в обох конфігураціях, але не збігаються між собою, виділені червоним кольором.
    
    
    
    
    
    
    
  • . Для порівняння модулів можна також використовувати звіт про порівняння об'єктів. Щоб викликати його у вікні порівняння, клацніть правою кнопкою миші на модулі, виберіть пункт У вікні, в області Формат,встановіть прапор Детально.У звіті можна побачити, які рядки модуля змінені і як вони виглядають в обох конфігураціях.
    
    
    Незважаючи на те, що цей звіт надає всю інформацію про зміни, він не зручний у роботі (принаймні при оновленні модулів). Набагато цікавіші дві його модифікації: звіт про порівняння об'єктів основної конфігурації зі старою конфігурацією постачальника(у цьому звіті видно лише зміни, внесені вами) та (У цьому звіті помітні лише зміни, внесені до модуля оновленням).
    
    
    
    За допомогою першого звіту можна побачити у скількох місцях внесені ваші зміни до модуля, це дозволить швидко знайти їх у вікні Перегляд відмінностей у модулях.У другому звіті можна побачити у кількох місцях типове оновлення, що внесло свої зміни.

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

  • Обновимо модуль, затерши внесені до нього зміни. Внесемо їх вручну після поновлення;
  • Не оновлюватимемо модуль. Зміни, отримані в оновленні, внесемо після.

  Перший спосіб:

  • • Перед описом алгоритму зауважу, що ми розглядаємо дуже простий приклад оновлення, для того щоб опис не зайняв дуже багато місця, але процес оновлення в складному випадку складається з таких етапів, хоча і вимагає більшої зосередженості і уважності;
    • Перед оновленням конфігурації створимо текстовий документ. До нього ми будемо записувати зміни, які потрібно буде внести вручну після оновлення. Дані у текстовому документі мають бути представлені максимально зрозумілим чином, тобто структуровані. У нашому прикладі писатимемо так: 1. Загальні модулі 1.1 КонтрольВерсіїКонфігурації
    • Знайдемо спільний модуль КонтрольВерсіїКонфігурації Модуль.Клікнемо по ньому правою кнопкою миші та в контекстному меню виберемо пункт О звіт про порівняння об'єктів основної конфігурації зі старою.У вікні поставимо прапор Детально.Також я встановлюю прапор Виводити у Текстовий документтому що так зручніше дивитися зміни, але це вже справа звички. Натисніть кнопку ОК.Звіт, що відкрився, матиме такий вигляд:
      
      
    • Зі звіту видно, що в модуль внесено дві зміни (перед кожною новою зміною пишуться номери рядків, в яких вона внесена):
      • Змінено рядок 34, в основній конфігурації вона закоментована, а старої конфігурації постачальника немає;
      • Додано процедуру, в старій конфігурації постачальника на її місці порожньо, а в основній конфігурації вона є. Звіт не закриваємо, він стане нам у нагоді;
    • Тепер знайдемо першу відмінність у вікні порівняння модулів. Для цього знову клацаємо правою кнопкою миші по гілці Модульі в контекстному меню вибираємо пункт Показати відмінності у модулях…Так як у вікні порівняння модулів не видно номерів рядків (глобальної нумерації), то для того, щоб знайти першу зміну прогортаємо всі процедури у верхній половині вікна. Також зі звіту ми знаємо, що перша зміна пов'язана зі зміною рядка, тому шукаємо текст, виділений червоним кольором. Змінений рядок знайдеться у процедурі ПеревіритиВерсіюКонфігурації().
      
      
    • Відкриємо текстовий документ, створений для запису змін. Пунктом «1.1.1» запишемо там назву процедури, в якій перебуває зміна. Після цього нам треба вписати в нього знайдену зміну так, щоб ми легко могли знайти її в тексті модуля. Для цього я зазвичай копіюю в документ не один, а відразу кілька рядків процедури, до і після змін. Але в даному випадку процедура маленька і тому достатньо скопіювати змінений рядок. Вийде наступний запис: 1. Загальні модулі 1.1 КонтрольВерсіїКонфігурації 1.1.1 ПеревіритиВерсіюКонфігурації//ВідкритиФормуМодально("ЗагальнаФорма.НерекомендованаВерсіяКонфігурації", Параметри);
    • Тепер знову відкриємо звіт про порівняння конфігурацій, подивимося таку зміну і знайдемо її у вікні порівняння модулів. На цей раз це додана нова процедура. Оскільки ця процедура повністю відсутня у старої конфігурації постачальника, її текст буде виділено синім шрифтом:
      
      
    • Знову відкриємо текстовий документ, створений для запису змін. У пункті «1.1.2» запишемо назву доданої процедури. Після цього скопіюємо туди текст доданої процедури. 1.1.2 МояТестоваПроцедура Процедура МояТестоваПроцедура() Експорт //Текст процедури КінецьПроцедури
    • КонтрольВерсіїКонфігураціївстановлений прапор, який означає, що цей модуль слід оновити, затерши всі внесені зміни;
      
    • Далі необхідно записати до текстового документа зміни інших двічі змінених об'єктів метаданих. Але оскільки в цьому прикладі ми розглядаємо конкретний загальний модуль, то пропустимо цей етап;
    • Після того, як робота над двічі зміненими об'єктами виконана, у вікні порівняння/об'єднання натискаємо кнопку Виконати;
    • Якщо з'явиться вікно з текстом «Існують об'єкти, змінені в основній конфігурації…», натискаємо кнопку Так;
      
      
    • У наступному вікні Налаштування правил підтримки не змінюємо жодних налаштувань, а просто натискаємо кнопку Так;
      
      
    • Останнім з'явиться повідомлення: "Об'єднання конфігурацій завершено". Тиснемо кнопку ОК;
      
    • Збережемо конфігурацію за допомогою меню Файл -> Зберегти, піктограми Зберегти(синя дискета) або клавіші Ctrl+S;
    • Після того, як конфігурація збережена, відновимо затерті зміни модуля. У дереві метаданих знайдемо та відкриємо модуль КонтрольВерсіїКонфігурації;
    • Відкриємо текстовий документ, в який занесені зміни даного модуля;
    • У пункті «1.1.1» зазначено процедуру ПеревіритиВерсіюКонфігурації,знайдемо її в модулі та розкриємо;
    • У текстовому документі зазначено, що слід закоментувати рядок: ВідкритиФормуМодально("ЗагальнаФорма.НерекомендованаВерсіяКонфігурації", Параметри);

      Знайдемо її в модулі та встановимо коментар;

    • У пункті «1.1.2» зазначено процедуру МояТестоваПроцедура,яку необхідно додати модуль. Копіюємо її з текстового документа та вставляємо в кінець модуля;
    • Зберігаємо конфігурацію одним із зазначених вище способів;
    • Оновлення конфігурації завершено, залишилося лише оновити конфігурацію, скориставшись клавішами F5або F7або відповідними піктограмами, та в режимі 1С:Підприємства підтвердити легальність оновлення;
      
      
  • Другий спосіб:
    • Другий спосіб повністю повторює перший, крім того, що діє він від зворотного. Тому опишу його коротко;
    • Створюємо текстовий документ із такою самою структурою;
    • Сформуємо звіт Звіт про порівняння об'єктів нової конфігурації постачальника зі старою конфігурацією постачальника;
    • Використовуючи сформований звіт та вікно порівняння модулів, випишемо в текстовий документ зміни, внесені новою конфігурацією постачальника;
    • У вікні порівняння/об'єднання конфігурацій перевіряємо, що біля модуля КонтрольВерсіїКонфігураціїЗНЯТИЙ прапор. Це означає, що модуль не буде оновлюватися;
    • Оновлюємо конфігурацію, вносимо зміни з текстового документа до модуля КонтрольВерсіїКонфігурації.

Оновлення плану обміну.

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

Розглянемо кроки оновлення складу плану обміну По Організаціїіз зазначеними змінами:

• До створеного при оновленні загального модуля текстового документа додамо нові рядки: 2. Плани обміну 2.1 По Організації
• Знайдемо план обміну По Організаціїу вікні порівняння / об'єднання, розкриємо його до гілки склад.Зауважу, що в плані обміну вами може бути змінений модуль, його треба оновлювати за правилами описаними для загального модуля. У разі нас цікавить саме оновлення складу плану обміну;
  
• Як і у випадку із загальним модулем, склад плану обміну можна або оновити, після цього додавши свої зміни вручну або не оновлювати, додавши типові зміни вручну. Якщо ваших змін у складі більше, ніж типових, то краще оновлювати другим способом, якщо менше то першим. Подивитися яких змін більше можна за допомогою тих самих звітів:
  
• У нашому прикладі типових змін більше, тому випишемо в текстовий документ наші зміни: 2. Плани обміну 2.1 По Організації - ***Довідники - -->Довідник.
• Перевіряємо, що у вікні порівняння/об'єднання встановлена ​​галочка біля плану обміну По Організації;
• Зберігаємо конфігурацію;
• Після того, як конфігурація збережена, відновимо затерті зміни плану обміну. У дереві метаданих знайдемо та відкриємо план обміну По Організації;
• У пункті «2.1» текстового документа вказано довідник ЗовнішніОбробки,знайдемо його у дереві метаданих складу плану обміну та встановимо прапор, що означає участь довідника в обміні;
  
  
• Збережемо та оновимо конфігурацію;

Оновлення передплати на подію.

Розглянемо приклад: джерело передплати на подію Перед Видаленням Довідника Для Обміну По Організаціїви ввімкнули довідник Зовнішні обробки.При оновленні склад джерел змінився, завдання аналогічне попереднім – виконати оновлення нетипової конфігурації 1с правильно.

Розглянемо кроки оновлення складу джерел підписки на подію із зазначеними змінами:

Оновлення ролей у 1С

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

Але все ж таки часто бувають випадки коли роль вже змінена, і не один раз, а розбиратися навіщо і чому часу немає. Тому розглянемо приклад: у типовій ролі Бухгалтердля довідника Податкові органидодано права на читання та перегляд, при оновленні набір прав ролі також було змінено.

Розглянемо оновлення ролі за кроками:

• Знайдемо роль Бухгалтеру вікні порівняння / об'єднання, розкриємо її до гілки Права;
  
• У цьому прикладі у ролі лише одна зміна, але зазвичай буває негаразд. Тому роль набагато простіше не оновлювати, а типові зміни вносити вручну;
• Сформуємо Звіт про порівняння об'єктів нової конфігурації постачальника зі старою конфігурацією постачальника. Зазвичай у ньому дуже багато інформації, але далеко не вся потрібна для оновлення:
  
• Залишаються або додані нові об'єкти метаданих, або зміни прав для старих:
  • Додані об'єкти виглядають так: - -->

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

  • Змінені об'єкти мають такий вигляд: - ***Довідники - ***ПодатковіОргани - ***Права - ***Читання - ***Значення -->Дозволено<--Запрещено - ***Просмотр - ***Значение -->Дозволено<--Запрещено

    У цьому докладно зазначено, які права змінилися;

• У нашому прикладі з корисної інформації у звіті про порівняння знаходиться лише один рядок, додаємо її до текстового документа: 4. Ролі 4.1 Бухгалтер - -->Об'єкт - РегламентованийЗвітСтатистикаФорма11НА

  При цьому можна вказати який це об'єкт метаданих, але в даному випадку і так видно, що звіт;

• У вікні порівняння/об'єднання знімемо галочку біля ролі Бухгалтер;
• Після цього необхідно записати в текстовий документ зміни інших двічі змінених метаданих об'єктів і виконати оновлення (процес докладно описаний вище);
• Зберігаємо конфігурацію;
• Після збереження конфігурації необхідно внести типові зміни в роль Бухгалтер. У дереві метаданих знайдемо і відкриємо цю роль;
• У пункті «4.1» текстового документа сказано, що до ролі додано об'єкт РегламентованийЗвітСтатистикаФорма11НА,знайдемо його в дереві метаданих ролі, встановимо галочки на правах Використанняі Перегляд;
  
  
• Збережемо та оновимо конфігурацію.

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

Після інсталяції на комп'ютер актуальну версію платформи можна переходити безпосередньо до оновлення конфігурації 1С. Пропонуємо дізнатися, як оновити самостійно «1С:Бухгалтерія 8» версії 3.0 – один з найбільш популярних та затребуваних бухгалтерських додатків у Росії.

Пошук оновлень

Перейдіть до оновлень

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

Вкажіть параметри адміністрування

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

Зверніть увагу – це не ті ім'я та пароль, які використовуються для отримання оновлень!

Виберіть у списку користувача (обов'язково з правами Адміністратора) і введіть пароль, який він використовує для авторизації в системі.

Виберіть відповідний варіант встановлення оновлень

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

Увага! Якщо з базою цієї роботи працюють інші користувачі, попросіть їх завершити сеанс - це необхідно для створення резервної копії даних. Дізнатися, хто саме підключений до бази, можна за посиланням «Переглянути список активних користувачів».

Зробіть бекап ІБ

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

Відкат буде виконано автоматично із збереженням усіх даних. Перейдіть за посиланням «Створювати резервну копію ІБ та виконувати відкат при позаштатній ситуації».

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

Зачекайте, поки завершиться оновлення

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

• Закриття сеансів користувача;
• Резервне копіювання ІБ;
• Копіювання файлів оновлення в ІБ;
• Оновлення конфігурації;
• Отримання дозволу на підключення.

Після оновлення конфігурації 1С 8 версії програма відкриється в режимі користувача і оновлення продовжиться. Хід прогресу буде видно на індикаторі.

Наприкінці програма видасть вікно з інформацією «Що нового у цій версії». Якщо вам цікаво, що дало оновлення конфігурації 1С 8.3 через конфігуратор, перейдіть за запропонованим посиланням та ознайомтеся з корисними відомостями.

Перевірте правильність встановлення оновлень

Зайдіть в меню «Адміністрування» у підпункт «Підтримка та обслуговування». У списку посилань із загальною назвою «Оновлення версії програми» клацніть на рядку «Результати оновлення та додаткова обробка даних».

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

Інструкцію щодо оновлення нетипової конфігурації 1С ми розглянемо в окремій статті.

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

Особистий досвід: як швидко та без зайвих витрат оновити змінену конфігурацію

Оновлювати конфігурацію відразу на кілька релізів дуже небезпечно. Справа в тому, що після кожного оновлення конфігурації запускається оновлення інформаційних баз у режимі "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.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буде завершено оновлюємо конфігурацію бази даних і тестуємо деякі моменти, що саме добре протестувати стане зрозуміло в процесі оновлення, тут все індивідуально.

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

Інструкція

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

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

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

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

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

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

Зверніть увагу

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

Корисна порада

Тренуйтеся в оновленні на копіях, не починайте роботу без певних навичок.

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

Інструкція

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

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