Оновлення нестандартної платформи викликає великі труднощі. Ми розглянемо, як оновити нетипову конфігурацію 1С і опишемо поетапне вирішення виникаючих труднощів.
Як в нетипової конфігурації 1С виконати оновлення.
зміст
- 1 Працюємо з 1С: 8
- 1.1 загальні поняття
- 1.2 зведення
- 1.2.1 порівняння версій
- 1.2.2 Збереження конфігурації (робочої)
- 1.2.3 Отримання файлу постачальника
- 1.2.4 Отримання файлу через оновлення
- 1.2.5 відновлення налаштувань
- 1.3 Збереження і коригування
- 1.3.1 підготовка баз
- 1.3.2 порівняння
- 2 Працюємо з 1С 7.7
- 2.1 Створення резервної копії
- 2.2 підготовка каталогів
- 2.3 об'єднання елементів
- 2.4 Інші
- 2.5 Завантаження зміненої платформи
Працюємо з 1С: 8
загальні поняття
При оновленні (update, англ.) Нетипової платформи зміни завжди зачіпають елементи типової конфігурації (configuration, англ.) Постачальника.
У базі даних (БД) міститься до трьох різновидів конфігурацій:
- безпосередньо база даних - з нею працюють логічні алгоритми;
- робоча (так звана основна, КонфігОР) - яку ми періодично змінюємо;
- конфігурація постачальника (КонфігП - на її основі створюються користувачем і робоча, і конфігурація БД.
Якщо програма скидається з підтримки - від постачальника її вже не буде. Однак тоді неминуче підвищення трудовитрат на оновлення.Розглянемо оновлення нетипової конфігурації 1С. Прикладом буде платформа УПП (Управління виробничим підприємством).
зведення
На першому етапі потрібно прибрати відмінності між робочою і поставляється конфігураціями. Це скоротить оцінку раніше привнесених нами доробок. Невідповідності між ними виникає, коли при оновленні використовувалися сторонні файли (не з поставляється дистрибутива) або методи оновлення відрізнялися від стандартних.
порівняння версій
Проводимо звірку номерів версій (робочої і поставленої). Перша перевіряється в "Конфігурація" / "Відкрити" / "Правка" / "Властивості". У розділі "Розробка / Версія". Друга в "Конфігурація" / "Підтримка" / "Налаштування підтримки" / "Версія":
При збігу номерів можна переходити до розділу Отримання файлу через оновлення.
Подальші кроки демонструють як привести до відповідності робочу і configuration постачальника. З метою поставити на підтримку ті об'єкти, які були зняті або були додані користувачем без підтримки. Для цього:
Збереження конфігурації (робочої)
Збережемо КонфігОР в якийсь файл з ім'ям, наприклад, work.cf. Для цього вибираємо "Конфігурація" / "Зберегти ...".
Отримання файлу постачальника
Для відомості КонфігОР з КонфігП потрібен cf-файл з дистрибутива постачальника (тієї ж версії). За замовчуванням він буде в C: / Program Files / 1cv81 / tmplts. Перевіримо наявність потрібного cf-файлу в таблиці шаблонів. Що робити, якщо немає потрібного файлу необхідної версії конфігурації постачальника? Тоді потрібно сформувати порожню БД зі старої, оновити її до необхідної версії і вже потім використовувати.
Отримання файлу через оновлення
Для виконання update cf-файлу КонфігП вибирається в меню команда: "Конфігурація / Підтримка / Оновити ... / Вибір файлу / Готово / Виконати" (Послідовно на картинках):
Стикаємося з проблемою - "Виявлено посилання, помічені на видалення".
Для вирішення її потрібно зняти позначку на видалення з об'єкта в configuration постачальника. Потім після видалення повторно виконуємо порівняння - натискаємо кнопку "Оновити" в віконці оновлення.
відновлення налаштувань
Частина загублених налаштувань відновлюється методом об'єднання з збереженим раніше файлом work.cf. Для цього вибираємо "Конфігурація / Порівняти, об'єднати ... файлу".
Збереження і коригування
Для збереження КонфігОР і оновлення бази даних в пункт меню "Конфігурація" вибираємо "Оновити ... БД".Тут зустрічаємо нову проблему:
Найімовірніше, причиною цього послужило те, що ці об'єкти були скопійовані з КонфігП або вони були постачальником видалені, а пізніше додані вже нові під такими ж іменами. Однак з іншими ідентифікаторами. В результаті з'явилися однойменні об'єкти, але з різними ідентифікаційними ключами.
Ролі можна просто видалити, т. К. Вони не змінювалися. Реквізит ж необхідно перейменувати, наприклад, на ЗаказРезерв1. А після поновлення внести значення з перейменованого в створений. Ще одна ситуація при оновленні. Як бути з формами?
З малюнка видно, що ФормаСпіска видалена постачальником, а потім додана заново під тим же ім'ям. Потрібно помітити їх обидві на оновлення і натиснути "Виконання".
Якщо при update видається повідомлення про наявність посилань на видаляються об'єкти, то, не закриваючи форму, потрібно очистити посилання на неї у властивостях самих об'єктів. Тут це знаходиться у властивостях регістра. Далі в формі поновлення вибрати опцію update, позначити на оновлення тепер уже властивості регістра і повторно натиснути "Виконати".
Збереження змін робочої і оновлення конфігурації БД: "Конфігурація / Оновити ... БД".Перенесення значення реквізиту ЗаказРезерв1 на ЗаказРезерв здійснюється зовнішньої обробкою режиму 1С: Підприємство.
підготовка баз
За результатами відомості готуємо дві ідентичні бази. Перша (основна) - це наш шуканий результат. Друга ж (допоміжна) - для виконання підготовчих дій. У випадку з файловим варіантом просто копіюємо їх в каталог і підключаємо до списку ІБ, з клієнт-серверних - робимо вивантаження / завантаження.
порівняння
Після відкриття обох БД Конфігуратором виконаємо їх тристоронню порівняння. Використовуємо для цього файл нової КонфігП - "Конфігурація / Підтримка / Оновити ... / Вибір файлу ... / Готово":
Порівняння робочої, старої і нової конфігурацій постачальника дає нам список змінених об'єктів по фільтру "Показувати двічі змінені властивості". З ними потрібно вирішити проблему в першу чергу:
На цей момент робота з допоміжною базою призупиняється до закінчення всього процесу, кнопку "Виконати" більше не натискаємо. Переходимо до роботи в основній базі з отриманим списком двічі змінених об'єктів. Згода з оновленням призведе до втрати зроблених раніше доробок.Тому по кожному з об'єктів потрібно приймати рішення - як він буде змінений.
Проведемо попередню оцінку тільки для зменшення робіт в подальшому. Якщо змін елемента більше міститься в новій КонфігП - залишаємо об'єкт постачальника. Ставимо галочку. Переносимо зміни з КонфігОР. Якщо змін елемента більше міститься в робочій configuration - залишаємо екземпляр об'єкта КонфігОР. Знімаємо галку. Перенесемо зміни з КонфігП. Модулі потрібно порівнювати попроцедурно. Для цього натискаємо кнопку як на малюнку:
Розставляємо галочки для вказівки процедур і функцій на заміну або видалення:
Тепер потрібно продублювати стан галочок в допоміжній базі. В основній же - натискаємо "Виконати". До цього моменту в основний отримуємо практично готову конфігурацію.
Наступні порівняння виконуємо знову в допоміжній базі. Знаходимо раніше внесені зміни додатковим порівнянням старої КонфігП з КонфігОР - "Конфігурація / Порівняти ...":
Аналогічно порівнюємо стару КонфігП з новою. Якщо файлу нової немає, - його тепер можна взяти з основної бази.
Отже, двічі змінені об'єкти отримані.В основній базі отримана практично готова configuration. У ній потрібно розібратися з двічі зміненими елементами.
ВАЖЛИВО. При аналізі користувача повинні цікавити не причини внесення тих чи інших змін, а їх наслідки. Тобто, головне - необхідність зберегти функціонал. Можливо, для цього буде потрібно не перенесення змінених рядків, а повна переробка коду під нову КонфігП.Для ухвалення рішення достатньо провести порівняння форм, таблиць, і модулів об'єктів. Іноді дані в звітах видаються в такому вигляді, який не дозволяє оперативно прийняти рішення. На цьому кроці втрата доробок відбувається якщо зміни стосуються об'єктних реквізитів складеного типу.
У порівняльному звіті дані, що розрізняються даються у вигляді списку, з якого не видно які типи даних додавалися / віддалялися. Якщо кількість рядків звіту досягає двохсот, то процес "ручного" порівняння видається досить трудомістким (близько п'ятдесяти годин).
Зниження трудомісткості досягається використанням, наприклад, конфігурації "Порівняння осередків" від компанії Інформ Сервіс. Вона доступна до запуску в режимі 1С: Підприємство і представляє дані звіту про порівняння в зручному вигляді.Порівняння здійснюється можливостями 1С:
Схема роботи проста. У конфігураторі створюється порівняльний об'єктний звіт. Зберігається в файл, наприклад, ОтчетОСравненіі.mxl. У діалозі 1С: Підприємство він відкривається і вказуються порівнювані осередку (за подвійним клацанням правою кнопкою миші на вибраній комірці табличного документа). При натисканні "Порівняти" дається результат порівняння, при цьому відрізняються позиції виділяються кольором.
Подальша інструкція дій виглядає так.
- Наступний звіт зберігається тим же ім'ям.
- Після закінчення оновлення та перенесення доробок типової конфігурації виконується синтаксичний контроль модулів і тестування роботи змінених об'єктів.
- Після вдалого тестування процес можна вважати закінченим. Залишається відновити друковані форми, звіти і обробку. У деяких випадках перевірити зовнішні форми звітності.
Працюємо з 1С 7.7
Оновлення типовий платформи на таку ж зазвичай не викликає труднощів. Досить тільки дотримуватися вказівок в інструкціях. Вони знаходяться в UPDATE.TXT каталогу дистрибутива.
Також складнощів немає, якщо в платформу додані додаткові елементи обліку (довідники, константи, відбори, звіти, регістри, журнали розрахунків, пр.). Вони вкладуться при об'єднанні платформ.Додані документи теж не внесуть дисгармонії, якщо не було змін ознак для введення "на підставі" таких доданих документів.
Рекомендується виконувати update на швидкодіючому ПК з великим об'ємом оперативної пам'яті. При її нестачі 1С може відмовитися відпрацьовувати частина функцій і "зависнути". Великий обсяг віртуальної пам'яті цю проблему не вирішує.
Створення резервної копії
Для цієї мети потрібно скористатися опцією: "Адміністрування / Зберегти дані ...". Зручно вказувати ім'я архіву, поєднавши його з датою створення (наприклад, ГГММДД.zip).
підготовка каталогів
Для роботи буде потрібно шість файлів конфігурацій (1cv7.md):
- "РабочійНовий" для підготовки поновлення (результуючий md-файл);
- "РабочійСтарий" по відстеженню змін при порівнянні і для перенесення налаштувань в ТіпНовий_2;
- Типова (стара) "ТіпСтарий_1". На її основі раніше була створена робоча.
- Типів. (Колишня) "ТіпСтарий_2". Для відстеження змін фірми 1С в новій типовій версії;
- Тип. (Нова) "ТіпНовий_1". Доробки фірми 1С в новій версії;
- "ТіпНовий_2" для складних об'єктів.
І п'ять запущених конфігуратор (все крім "ТіпНовий_1").
Спочатку каталоги попарно однакові:
- "РабочійНовий" і "РабочійСтарий";
- "ТіпСтарий_1 і ТіпСтарий_2";
- "ТіпНовий_1" і "ТіпНовий_2".
об'єднання елементів
Спершу проводимо порівняння між 3 і 2, 4 і 5, 1 і 6. Для цього кожній з перших в парі вибрати пункт "Конфігурація / Об'єднання ..." і вказати файл метаданих 1cv7.md другого в парі. На екрані відобразиться форма з деревом змінених елементів. Далі необхідно провести аналіз результатів попарного порівняння 3 з 2 і 4 з 5. Залишити для об'єднання елементи в оновлюваних платформах (1 і 6), в яких були зміни від фірми 1С (4 з 5), але не були відображені в 3 і 2. 1 і 4 потрібно об'єднати в режимі заміщення.
Інші
Сюди можна віднести план рахунків і призначені для користувача інтерфейси. Якщо в плані рахунків були зміни, то його потрібно оновлювати в режимі "Об'єднання об'єктів" РабочійНовий разом з ТіпНовий_2. Після об'єднання інтерфейсу перевіряється наявність помилок: дублювання пунктів меню, дублювання панелей інструментів, установка ознак для панелей інструментів "Розташування з нового рядка".
Завантаження зміненої платформи
Завантаження виконується по мережі або на сервері (переважно). Спочатку монопольно забезпечується доступ до БД.А через режим конфігуратора потім завантажується база. Перед проведенням завантаження і після неї виконується архівація даних (як описано в самому початку розділу). Далі потрібно слідувати інструкціям файлу UPDATE.TXT. Після закінчення завантаження все каталоги, крім РабочійНовий, можна видалити.
Сподіваємося, наша публікація допомогла вам розібратися з оновленням нетипової конфігурації 1С. Ми розглянули це касаемо і сьомий і восьмий версій.
Залишайте коментарі, пишіть про свій досвід в оновленні 1С.
