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