Розширення конфігурацій – як додати функціонал у типову конфігурацію, не знімаючи з підтримки (20 хвилин відео). Зміна або вимкнення режиму сумісності Для чого потрібні розширення

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

Переклад 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

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

Насамперед необхідно знати про обмеження, які мають розширення.

Обмеження на об'єкти, що створюються

На даний момент можна створювати:

  • Довідники
  • Документи
  • Реєстри відомостей
  • Плани обміну

Можна додавати реквізити до:

  • Довідники
  • Документи

Що ми маємо у результаті? Додавати можна не всі типи метаданих об'єктів. Найпоширеніші та затребувані, але все-таки не всі. Крім того, до регістрів відомостей не можна додавати нові вимірювання та ресурси. Можна лише створити повністю новий регістр.

Функціонал розширень залежить від режиму сумісності конфігурації, до якої застосовується розширення.

Режим сумісності 8.3.8- можна змінювати лише форми об'єктів та їх модулі, додавати свої звіти та обробки.

Режим сумісності 8.3.10- можна змінювати загальні модулі, модулі об'єкта та менеджера, ролі, використовувати директиви "Перед", "Після", "Замість" для будь-яких модулів.

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

На даний момент типовий УТ 11.3 стоїть режим сумісності 8.3.8. В УТ 11.4 режим сумісності 8.3.10, тобто, наприклад, для УТ, більшість функціоналу розширень недоступна, включаючи створення об'єктів метаданих.

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

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


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


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

Висновки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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