Реалізовано у версії 8.3.6.1977.

Ми реалізували принципово новий механізм адаптації прикладних рішень під конкретного споживача – механізм розширень.

Чим хороші розширення?

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

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

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

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

Стратегія, запропонована розширеннями, ось у чому. Якщо ви хочете змінити типову конфігурацію, ви не торкаєтеся самої конфігурації. Усі зміни ви виконуєте у розширенні, яке, по суті, також є конфігурацією.

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

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

Коли потрібно використовувати розширення?

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

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

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

Інша ситуація - це доопрацювання типової зміни під конкретного замовника в нього на впровадженні. Або доробки типової конфігурації, які виконують для себе IT фахівці замовника власними силами. Якщо всі ці доопрацювання виконати у розширенні, то типова конфігурація залишиться на повній підтримці, що значно спростить її супровід.

Є спокуса використати розширення для створення тиражних прикладних рішень, проте робити це не варто. По-перше, тому, що розширення не проектувалося під такі завдання. А по-друге, тому, що інші механізми платформи, наприклад, механізми постачання та підтримки, нічого не знають про розширення.

Якщо трохи зазирнути в історію появи розширень, то, безумовно, ми бачили раніше, бачимо й зараз, що стають складнішими. Ми бачимо, що потрібна додаткова підтримка різних рівнях розробки: бібліотечна, модульна і галузева тощо. Ми аналізували всі ці завдання і дійшли висновку, що найпріоритетнішою на даний момент є адаптація конфігурацій до побажань користувачів під час впроваджень.

Саме для цього завдання ми створили механізм розширень. Звісно, ​​у ньому можна побачити різні риси та інших перелічених напрямів розробки. Але вони не є його основним призначенням і не повинні збивати вас з пантелику.

Що можна змінювати вже зараз за допомогою розширень?

Поки що зроблено не дуже багато з того, що планується зробити. Механізм, звісно, ​​розвиватиметься. Але те, що вже зроблено, може бути корисним у багатьох випадках на впровадженнях. Зараз:

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

Надалі ми плануємо поступово нарощувати функціональність розширень і будемо раді отримати вашу думку про те, яка функціональність найбільш потрібна на впровадження з невеликими доробками.

Як влаштовано розширення?

Розширення дуже схоже на нормальну конфігурацію. Воно також представляється як дерева об'єктів. p align="justify"> Для роботи з розширенням використовуються ті ж прийоми роботи, що і зі звичайною конфігурацією.

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

Запозичені об'єкти не завжди потрібні. Найкраще пояснити це на «побутовому» прикладі, якщо провести аналогію з обідом у ресторані.

Ситуація перша, коли запозичені об'єкти потрібні.

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

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

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

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

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

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

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

Якщо описати це сухою мовою розробників, то вийде, що запозичувати об'єкти потрібно:

• Коли вони потрібні для візуального конструювання. Наприклад, ви розширюєте форму та додаєте реквізит форми типу Довідник Валюти.. Тоді звичайно ви повинні запозичити довідник Валютищоб при підключенні до типової конфігурації бути впевненими в тому, що в ній такий довідник все ще є.
• Коли вони потрібні для роботи коду. Наприклад, у коді розширення ви звертаєтесь до реквізиту довідника Номенклатура - Імпортер. Тоді цей реквізит також треба запозичувати, щоб при підключенні бути впевненим, що у типовій конфігурації все ще існує такий реквізит у довідника Номенклатура.

Підключення розширення

Ви створюєте розширення конфігуратора. Після того, як воно налагоджено та перевірено, ви можете його відкинути, зберігши розширення у файл *.cfe.

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

Робота з розширеннями доступна з вбудованої мови, тому в прикладному рішенні ви можете створити власну обробку, яка завантажуватиме розширення. Щоб розширеннями «не балувалися» всі поспіль, ми додали нове право Адміністрація розширень конфігурації.

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

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

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

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

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

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

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

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

Тепер для вас така ситуація не є проблемою. І вам не потрібно «перелопачувати» весь код розширення, щоб замість Номенклатуранаписати Товари. Працює та . Тому вам достатньо лише змінити ім'я запозиченого об'єкта на Товари, а решту змін у розширенні платформа зробить сама. Або з вашою мінімальною допомогою.

Робота розширення

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

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

Основну концепцію, що використовується при роботі конфігурації і розширення, можна описати так. У тих місцях, де вони не перетинаються, розширення доповнює конфігурацію. У тих місцях, де вони «перетинаються» – застосовується розширення.

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

Візуальна частина форми фіксується у розширенні на момент її запозичення. А в режимі 1С:Підприємство для кожного елемента форми аналізуються зміни щодо цього стану в типовій конфігурації та розширенні.

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

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

Для модулів форм використовується інший підхід. Для запозиченої форми у розширенні створюється власний модуль із власними обробниками всіх подій. У режимі 1С:Підприємство обидва модулі форми (з типової конфігурації та з розширення) об'єднуються в одному контексті. Тому кожне розширення має свій префікс, який додається до обробників всіх подій у модулі форми. Щоб не було збігів з обробниками типової конфігурації. Після цього обробники подій та команд викликаються послідовно та синхронно. Спочатку обробник із розширення. Потім із типової конфігурації. Цю послідовність ви можете змінити, або заборонити виконання оброблювача з типової конфігурації.

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

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

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

Розширювати ролі можна лише додаючи в них об'єкти, створені в розширенні. Видалити щось із існуючої ролі ви теж не можете. Це саме стосується і командного інтерфейсу.

Розширення – це майже конфігурація

Ми говорили спочатку, що розширення схоже на звичайну конфігурацію. Тому на закінчення кілька слів хочеться сказати про те, наскільки розширення інтегровані з іншими механізмами платформи.

У розширення (як і звичайної конфігурації) є основна конфігурація і конфігурація бази даних. Механізм порівняння та об'єднання змін працює з розширеннями так само, як і зі звичайними конфігураціями.

Ви можете вивантажити розширення у файл (щоправда, з іншим розширенням *.cfe), та завантажити з файлу. Розширення можна вивантажувати/завантажувати в XML.

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

З'явилися нові параметри командного рядка для роботи з розширеннями та нові події в журналі реєстрації.

У вбудованій мові основний об'єкт для роботи з розширеннями МенеджерРозширеньКонфігурації.

У цій статті пропоную розглянути, що таке «розширення конфігурації», як додати розширення або вимкнути його. Починаючи з версії 1C 8.3.6.1977 у платформі запроваджено новий механізм – розширення конфігурації. Спочатку трохи теорії.

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

Навіщо потрібні розширення?

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

Зняття з повної підтримки тягне за собою низку незручностей:

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

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

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

Відео - розширення в 1С за 45 хвилин

Отримайте 267 відеоуроків з 1С безкоштовно:

Приклад додавання розширення до 1С

Щоб показати, що таке розширення, краще навести приклад створення в конфігураторі 1С.

У конфігураторі зайдемо в меню Конфігурація і виберемо пункт Розширення конфігурації. Відкриється вікно зі списком розширень (якщо вони є). Натисніть кнопку «Додати» та додамо нове розширення. Тепер можна відкрити конфігурацію розширення:

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

Нещодавно я писав статтю про те, як самим зробити. На її прикладі я хочу зробити її вбудованою за допомогою розширення.

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

Тому довідник ми запозичимо з основної конфігурації:

Тепер натиснемо правою кнопкою мишки на «Обробки» та виберемо «Вставити зовнішню обробку, звіт…» Таким чином, додамо нову обробку до конфігурації розширення. Якщо Ви використовуєте мою обробку, то одразу перейменуйте її, тому що в основній конфігурації вже є обробка з таким ім'ям.

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

Ось така структура в мене вийшла:

Побачимо, що в нас вийшло. Оновлюємо конфігурацію бази даних та запускаємо програму в режимі 1C: Підприємство, і йдемо в меню «Адміністрування». Так, мало не забув, конфігурацію розширення необхідно закрити, інакше програма не запуститься:

Ми випустили новий реліз телефонної панелі для 1С.

• версія 1.2.24.10 для звичайногопрограми
• версія 1.4.26.17 для керованогопрограми

У версії релізу для керованої програми з'явилася можливість вбудовування телефонної панелі з мінімальними доробкамиосновний конфігурації за допомогою механізму розширенняконфігурації.

Переваги використання розширення

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

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

Особливості вбудовування телефонної панелі для 1С

Такі можливості стали доступними розширенням для платформи, починаючи з версії 8.3.9.1818 . Тому, щоб скористатися цим, ми відключили режим сумісності для розширення, оскільки версія 8.3.9 ще не підтримується. Відповідно виникає необхідність відключення режиму сумісності й у основний конфігурації, інакше виникне помилка: " Режим сумісності розширення конфігурації більший за режим сумісності основної конфігурації".

2) В основну конфігурацію ми додаємо роль МИКО_Софтфон, на яку ми знімаємо всі права.

При додаванні нового об'єкта метаданих, в даному випадку ролі, потрібне оновлення довідника Ідентифікатори Об'єктаМетаданих. Коли ми додавали цю роль розширення, то типові конфігурації ігнорували її, тобто за оновлення довідника Ідентифікатори Об'єктаМетаданих роль у ньому не з'являлася. Через це некоректно працював механізм профілів налаштувань панелі телефонії, виникала помилка: " Ідентифікатор об'єкта метаданих для ролі МИКО_Софтфон не знайдено".

Причому ця ситуація виникала не у всіх конфігураціях, так у "Управління торгівлею, 11.2.3.218"і "Комплексна автоматизація, 2.0.3.222"проблем з участю був, коли було додано у саме розширення. Щоб забезпечити певну універсальність запропонованого нами рішення і гарантувати безперебійну роботу в більшості конфігурацій, що підтримуються нами, ми вирішили додавати роль МИКО_софтфонв основну конфігурацію і запозичувати її в розширенні, а вже в розширенні продати налаштування цієї ролі.

Дуже важливою особливістю є той факт, що якщо вбудувавши якось наше розширення, Ви захочете вбудувати панель за нашими старими інструкціями, необхідно вимкнути розширення та видалити роль МИКО_софтфон. Якщо ви хочете знову скористатися розширенням, необхідно спочатку додати роль, а потім вже додати розширення.

Резюмуємо

Навіть включаючи можливість зміни основної конфігурації та вносячи мінімальні зміни в конфігурацію, ми зробили процес вбудовування панелі телефонії більш простим. Тепер Вам не потрібно вносити зміни до модулів керованого додатка, додавати обробки та підсистеми до конфігурації, налаштовувати ролі. Все це за вас зробить розширення! Ми продовжимо вдосконалювати процес вбудовування телефонної панелі для 1С!

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

Задавайте свої питання через форму зворотнього зв'язку.

© 2019. MIKO LLC All Rights Reserved.

Вартість робіт та варіанти перекладів з різних релізів

	Переклад 8.1 → 8.2.13	Переклад 8.2.13 → 8.2.16	Переклад 8.2.16 → 8.3.10
Ціна, руб. *	54 000 ₽	12 000 ₽	76 800 ₽

Список усіх змін у різних версіях платформи доступний за посиланнями:
Для платформи 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm

Перед початком робіт з перекладу на 8.3 потрібно:

Перевірити режим керованих блокувань. Якщо використовується "Автоматичний", то при переході на 8.3 можуть знадобитися додаткові витрати на переведення в режим керованих блокувань.
Якщо використовується режим сумісності з 8.2.16 і вище, потрібно перевірити, чи виконано реструктуризацію таблиць
Визначити, які типи клієнтів використовують (тонкий, товстий, веб-клієнт)
Визначити, чи є машини, які працюють під linux

Переклад конфігурації 8.1 → 8.2.13

Вартість робіт: 54 000 руб.

Переклад конфігурації 8.2.13 → 8.2.16 (включно з реструктуризацією)

Ключові зміни:
Змінено режим зберігання констант та налаштувань регістрів накопичення. Для кожного об'єкта використовується своя таблиця бази даних
Перероблено реалізацію механізму керованих блокувань.
Для події технологічного журналу TLOCK властивість Txt записується тільки в режимі сумісності з версією 8.2.13
Зменшено вплив режиму налагодження на швидкість роботи в режимі «1С:Підприємство» для тонкого клієнта, товстого клієнта, сервера та зовнішнього з'єднання.
Оптимізовано виконання запиту виду «ТипЗначення(Поле1) = ТипЗначення(Поле2)», якщо «Поле1» та «Поле2» містять значення типу посилання.
Для полів керованої форми, що відображають реквізит складового типу, прискорено відкриття списку швидкого вибору в тих випадках, коли до складового типу входять типи посилань з різними налаштуваннями швидкого вибору.
Для нового незалежного та неперіодичного регістру відомостей, індекс за вимірами є кластерним

Зміни, які потребують змін у конфігураціях:

При вимкненому режимі сумісності параметр «Період» методу менеджера періодичного регістру відомостей «Отримати()» є обов'язковим. У режимі сумісності з версією 8.2.13 та версією 8.1 поведінка не змінилася (метод можна використовувати без вказівки параметра, але результат є невизначеним).
При одночасному використанні методів «ВстановитиЗначення()» та «ВикористовуватиДжерелаДаних()» об'єкта «ЕлементБлокуванняДаних» викликається виняток. У режимі сумісності з версією 8.2.13 поведінка не змінилася (пріоритетною вважається значення, встановлене методом «ВикористовуватиДжерелаДаних()»).
Не підтримується розміщення у сховищі значення даних, які не підтримують серіалізацію. У режимі сумісності поведінка не змінилася.
Якщо файлова база, то має бути виконано перетворення інформаційної бази. Після початку перетворення робота з даною інформаційною базою попередніми версіями платформи «1С:Підприємство 8» буде неможлива. Якщо технологія виконується з використанням сховища конфігурацій, перед перетворенням інформаційної бази потрібно обов'язково зробити копію сховища

ВАЖЛИВО. Для отримання ефекту від зміни режиму сумісності необхідно зробити реструктуризацію через конфігуратор: “Адміністрування → Тестування та виправлення → Реструктуризація таблиць інформаційної бази”.

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

У такому разі необхідно зробити таке:
Встановити окремо сервер 1С версії 8.2.19 та розгорнути на ньому досліджувану базу
Відкрити базу конфігуратора на сервері 1С версії 8.2.19, змінити режим сумісності на “Не використовувати”
Виконати реструктуризацію таблиць інформаційної бази
Після того, як реструктуризація буде виконана, перемістити інформаційну базу на вихідний сервер 1С версії 8.3

Вартість робіт із переведення конфігурації з режиму сумісності 8.2.13 до режиму 8.2.16 (режим без сумісності, при використанні платформи 8.2.16, 8.2.19 та режим сумісності 8.2.16 при використанні платформи 8.3) складає 12 000 руб.

Шаблон договору на роботи можна завантажити.

Переклад конфігурації 8.2.16 → 8.3.10

До складу робіт з перекладу конфігурацію входять такі доробки конфігурації:

1. Усунення конфлікту імен властивостей. Зміна імен змінних, що збігаються з новими властивостями, які з'явилися у «1С:Підприємстві 8.3».

2. Усунення конфлікту імен картинок. Перейменування імен зображень з іменами, що збігаються з іменами з бібліотеки зображень.

3. Доопрацювання коду за зміни властивостей фіксованої структури. Заміна вказівки властивостей фіксованої структури на перестворення фіксованої структури або заміна її використання на аналогічний тип "Структура".

4. Заміна приміщення у тимчасове сховище несеріалізованих значень, на код, що підтримується в «1С:Підприємстві 8.3».

5. Заміна використання виклику методу «Показати» для реквізитів керованої форми, використання властивостей «ПоточнийЕлемент», «ПоточнаСторінка», методу «Активувати»

6. Заміна імен об'єктів метаданих з довжиною понад 80 символів, на імена з довжиною імені 80 символів або менше для об'єктів метаданих

7. Перейменування методів та властивостей згідно з методикою переходу на версію 8.3.

8. Доопрацювання механізмів роботи з відборами, умовним оформленням, угрупованнями та порядком у динамічних списках.

9. Доопрацювання коду для запитів із ключовим словом «ПІДСУМКИ ЗА ЗАГАЛЬНІ», вивантажений у режимі «Обхід Результату Запиту. Угрупуванням», з метою збереження колишньої логіки роботи.

10. Зміни імен класів COM-об'єктів. Заміна імен V82.COMConnector на V83.COMConnector і V82.Application на V83.Application.

11. Відмова в коді програми від події «ПочатокВиборуСписку» для полів введення в режимі вибору зі списку

12. Відмова в коді програми від властивості «КнопкаСпискуВибору» для полів введення шляхом встановлення властивості «КнопкаВипадаючогоСписку».

13. Зміна коду з урахуванням зміни типу значення, що повертається методом глобального контексту «БезпечнийРежим()»

14. Зміна коду з урахуванням змінення результату запиту до константів (при зверненні до поля «Значення» таблиці константи, якщо константа зберігає значення типу «СховищеЗначення», «Унікальний Ідентифікатор» або «ЗовнішнійДжерелоДанихТаблицяПосилання»).

15. Заміна якості конфігурації «ОсновнаРоль» на «ОсновніРолі»

16. Відмова від властивостей «Користувач» та «Пароль» для об'єкта «ІнтернетПроксі» та заміна на методи «Встановити()», «Користувач()», «Пароль()».

17. Доопрацювання коду для підтримки команди «Показати у списку» згідно з методикою переходу на версію 8.3.

18. Доопрацювання коду для підтримки колишньої логіки роботи системи при значенні властивості, що змінилося, що повертається СистемнаІнформація.ВерсіяОС,

19. Доопрацювання коду для підтримки колишньої логіки роботи системи при відмові від використання системного перерахування Варіант Відкриття Вікна, яке більше не доступне у версії 8.3.

20. Доопрацювання коду з урахуванням відмови від використання модальних вікон.

21. Доопрацювання коду підтримки веб-клієнта, а саме відмова від серверних дзвінків та відкриття вікон у «ПередЗакриттям», відмова від серверних дзвінків у «ПриЗакритті».

22. Доопрацювання коду для можливості коректного використання функції РольДоступна(), при передачі функції як параметр відсутньої ролі.

23. Для керованого додатка: починаючи з версії 8.3.8 в обробниках подій керованого додатка Перед Завершенням Роботи Системи, При завершенні Роботи Системи, а також в обробниках подій керованої форми, що знаходиться в режимі закриття, Перед Закриттям, При Закритті, заборонено відкривати вікна та виконувати будь-які серверні дзвінки. Необхідно доопрацювати конфігурацію, щоб закриття форм виконувалося коректно — без серверних викликів.

24. Конфлікт імен змінних: у модулі форми не можна використовувати ім'я змінної ПараметриФорми. Тому необхідно доопрацювати всі модулі керованих форм, де використовуються змінні з ім'ям ПараметриФорми, перейменувавши ці змінні.

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

Вартість робіт: 76800 руб.

Шаблон договору на роботи можна завантажити.

Вартість робіт із переведення конфігурації в режим сумісності з 8.3.10 може бути збільшено, якщо:
У конфігурації використовуються керовані форми
Необхідно відмовитись від використання модальності
Потрібно підтримувати працездатність конфігурації в ОС Linux

Колеги, всім здравствуйте.

Днями вийшла тестова Бухгалтерія Підприємства з вимкненим режимом сумісності із платформою 8.3.6.
Отже в цій версії використовується новий двигун, який по-новому малює форми.
Прочитати про це можна у Задзеркаллі.

Разом з типовими на нову платформу слід переробляти свої розширення.
У процесі перекладу сформував собі невеликий чек-лист чи пам'ятку у тому, що треба зробити.

Пам'ятка:

1. Перекладаємо розширення на нову платформу

Для цього слід привести режим сумісності розширення до сумісності конфігурації.
У версії Бухгалтерія Підприємства встановлені такі характеристики:

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

2. Усуваємо проблеми підключення

Для цього запускаємо конфігурацію в режимі підприємства та дивимося злетіло чи ні.
Помилки, через які не вдалося підключити розширення, можна переглянути в журналі реєстрації
(Адміністрація - Підтримка та обслуговування - Журнал реєстрації)
Нас цікавлять події – “Сеанс. Помилка застосування розширення конфігурації”:

Найчастіше проблема підключення вирішується видаленням зайвого реквізиту чи об'єкта.

Основна складність у тому, що розширення не видає відразу всі помилки (до речі, цю проблему вирішено у 8.3.9).
Тому потрібно послідовно запускати конфігурації після виправлення кожної помилки.
Щоб було зручно запускати журнал реєстрації - додамо його у вибране:

3. Оновлюємо форми у розширенні

Для цього у кожній зміненій формі натискаємо на “Оновити розширення форми”
За допомогою цієї команди ми заново підвантажуємо форму основної конфігурації на розширення.

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

4. Наводимо форму до правил нового двигуна.

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

Я склав такий порядок дій:

• Забираємо всі декорації, які використовувалися для відступів
  Натомість тепер використовуються групи.
• Дивимося, що все виглядає добре.
  Якщо щось пішло не так, дивимося статтю.
  Якщо все добре, то рухаємось далі.
• Перевіряємо нові властивості платформи“Об'єднана”, “Автомаксимальна Ширина” та “Автомаксимальна Висота”.
  Просто дивимося, що у цих властивості встановлені замовчування платформи і форма через це не роз'їжджається.