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

1. проблема
2. Документування, інструменти
3. конфігурація
4. Зовнішні друковані форми
5. Обробки для заповнення
6. Лістинг 1. Заготівля для обробки заповнення
7. Модернізація типових форм
8. Ідеї ​​для розширень
9. На що ще здатні розширення
10. Підписки на події
11. Програмна доопрацювання форм
12. модифікація ролей
13. Не лінуйтеся

Компанія 1С міцно закріпилися в ніші програм для автоматизації діяльності підприємств. «Бухгалтерія підприємства», «Управління торгівлею», «Зарплата управління персоналом» і т.д. - стали візитними картками компанії і успішно застосовуються як в маленьких, так і великих підприємствах.

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

проблема

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

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

Документування, інструменти

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

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

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

В реальності розробки рішень під платформу 1С ще не склалася повноцінна культура розробки. Далеко не всі розробники застосовують спеціалізовані інструменти, що спрощують рев'ю коду, документування і т.д. Хочете створювати більш прості в підтримці і супроводі рішення? Починайте знайомитися з практиками розробки, орієнтовані на інші платформи. Багато з них цілком реально перетягнути в 1С.

конфігурація

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

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

Потрібні приклади милиць? Будь ласка! Замовнику завжди не вистачає полів в стандартних документах / довідниках і він хоче додати свої. Виконати це бажання простіше без відкриття конфігуратора. Активувати використання додаткових (див. Малюнок 1) реквізитів в настройках і потім швиденько створити всі необхідні поля. Створені таким чином реквізити не зачіпають конфігурації і вони придатні для використання в звітах, отже, практично нічим не поступаються нативним.

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

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

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

Сучасні типові рішення прекрасно конфигурируются, і багато завдань ефективно вирішуються без відкриття конфігуратора. Не лінуйтеся стежити за технологічними новинками на сайтах на кшталт «Задзеркалля» і застосовувати саме їх, а не рішення в «лоб».

Зовнішні друковані форми

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

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

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

Для створення зовнішньої друкованої форми потрібно описати три службових функції: «СведеніяОВнешнейОбработке», «Друк», «ВиводІнформацііПоДокументу». Вони обов'язково повинні перебувати в модулі обробки, тому що до них звертатимуться механізми БСП.

Функція «СведеніяОВнешнейОбработке» описує структуру з базовою інформацією по обробці. Перераховані відомості необхідно для успішної реєстрації в механізмі зовнішніх друкованих форм. Безпосередня реєстрація відбувається через додавання елемента в довідник «Додаткові звіти і обробки» (див. Рисунок 2).

Особливу увагу варто звернути на наступні властивості:

• МассівНазначеній. Містить назву об'єктів метаданих, для яких буде реєструвати друкована форма. Допускається кілька варіантів вказівки об'єктів: «Документ.ПріходнийКассовийОрдер», «Документ. *». Останній запис на увазі всі документи, доступні в системі.
• Вид. Визначає вид зовнішньої обробки. Обробки різних видів реєструються по-різному. Для друкованих форм вказуємо «ПечатнаяФорма», інші доступні види привів в коментарях.
• Найменування. Назва обробки в системі.
• Ідентифікатор. Використовується в декількох місцях, рекомендується привласнювати осмислене ім'я. Найчастіше тут вказує ім'я обробки, наприклад: «РогаІКОпита_ФормірованіеМакетаКассовогоОрдера».
• Модифікатор. Якщо в якості макета використовується табличний документ, то вказуємо «ПечатьXML».

Процедура «Друк» виконує службову роль і викликається вбудованими механізмами системи. У більшості випадків її вміст залишається незмінним за винятком параметрів виклику «ВивестіТаблічнийДокументВКоллекцію» (див. Тіло процедури).

В обов'язковому порядку необхідно вказати ідентифікатор команди (він повинен відповідати значенням «Ідентифікатор», вказане в процедурі «СведеніяОВнешнейОбработке») і задати синонім (буде використовуватися в заголовку вікна відображення сформованого табличного документа).

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

• Ім'я для збереження параметрів друку. Найчастіше користуються шаблоном: «ПАРАМЕТРИ_ПЕЧАТІ_ІмяПечатнойФорми».
• Макет. У методі «ПолучітьМакет» потрібно вказати ім'я макета.

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

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

Обробки для заповнення

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

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

Початок процесу розробки обробки заповнення стандартне: створюємо нову обробку і описуємо в модулі службову функцію - «СведеніяОВнешнейОбработке» (див. Лістинг 1).

Лістинг 1. Заготівля для обробки заповнення

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

Розглянутої функції досить для створення каркаса обробки-заповнення. Далі все залежить від розв'язуваної задачі. Якщо потрібно створити форму обробки і налагодити зв'язок з об'єктом заповнення, вам буде потрібно описати в формі кілька параметрів:

• Об'ектиНазначенія (Довільний) - масив посилань на об'єкти заповнення.
• Ідентифікатор (Рядок) - ідентифікатор команди.
• ДополнітельнаяОбработкаСсилка (СправочнікСсилка.ДополнітельниеОтчетиІОбработкі).

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

Модернізація типових форм

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

Після розширення типових об'єктів необхідно відредагувати основну форму. У самому просто випадку вивести створені елементи і прописати для них якусь логіку. Банальне редагування форми - подібно смерті, тому що ми відразу напаривается на проблему, описану на початку статті. Для елегантного вирішення подібних завдань на платформенном рівні був створений механізм розширень.

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

Нові розширення створюються в конфігураторі за допомогою менеджера розширень ( «Конфіугурація» -> «Розширення конфігурації»). У вікні менеджера Ви бачите все встановлене розширення (див. Рисунок 3) і інтерфейс для створення нових.

Для створення нового розширення натискаємо кнопку «Додати» і у вікні заповнимо поля (малюнок 4):

• Ім'я. Стандартні правила іменування об'єктів метаданих 1С.
• Синонім.
• Префікс. Додаткове значення, яке буде автоматично додаватися для всіх створених сутностей в розширенні.

Натискаємо "Ok" і перед вами з'явиться додаткове дерево конфігурації (малюнок 5).

Принцип роботи з деревом конфігурації розширення мало чим відрізняється від роботи зі стандартним деревом конфігурації інформаційної бази. Відмінність полягає в обмеженнях ( http://its.1c.ru/db/v839doc#bookmark:dev:TI000001513 ).

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

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

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

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

Я розширив документ «КонтСтраховойПоліс» (додав табличну частину і нові реквізити), а потім додав основну форму документа в створене розширення (контекстне меню «Додати в розширення»).

Разом з формою будуть перенесені пов'язані реквізити, а також ряд інших об'єктів (рисунок 6).

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

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

Ідеї ​​для розширень

Не варто думати про розширення, як про своєрідні милицях для модифікації об'єктів. Це повноцінна система плагінів з великим потенціалом на розвиток. Уже сьогодні розширення дозволяють створювати: підсистеми, загальні модулі, ролі, загальні форми, обробки, звіти, HTTP-сервіси, WS-посилання, XDTO-пакети. Перерахованих об'єктів вистачить для вирішення багатьох реальних задач.

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

Аналогічним чином йдуть справи з інтеграцією КІС і CMS. Стандартні механізми обмінів у вигляді громіздкого CommerceML - не самий зручний і швидкий спосіб вивантажувати номенклатуру на сайт. Розширення від розробників CMS можуть запросто вирішити цю проблему і не створити користувачу типових рішень проблем з подальшим оновленням.

Можлівість! Застосування в Розширення HTTP-сервісів - масштабно розшірює Можливі Патерно! Застосування. Інтеграція з зовнішнімі сервісамі, обміні - все це Досить просто реалізується функціоналом HTTP-сервісів. Кілька цікавих прикладів ви можете подивитися в однойменній статті, опублікованій в минулому номері нашого журналу.

На що ще здатні розширення

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

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

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

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

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

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

Підписки на події

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

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

Програмна доопрацювання форм

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

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

модифікація ролей

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

В ідеальному варіанті - намагайтеся максимально дробити ролі. Виділяйте ролі на читання і запис документів / довідників, які не поєднуйте права в одну роль. Звичайно, не варто це робити для кожного документа / довідника конфігурації, але робити треба хоча б для груп об'єктів. Розглянемо приклад - «Касові документи». До них відносяться як мінімум «ПКТ» і «РКО». Таким чином легко формувати гнучкі профілі безпеки (БСП).

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

Не лінуйтеся

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

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

Чи не лінуйтеся!

Стаття опублікована в журналі "Системний адміністратор" (http://samag.ru/). Лютий 2017 р