29.09.2016

Перевірка правомірності використання встановлених оновлень типових конфігурацій програм системи 1С Підприємство 8.

Отримати доступ до хмари 1С:Фреш безкоштовно на 30 днів!

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

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

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

Перевірка виконується для прикладних рішень, розгорнутих у файловому варіанті або сервері у версії МІНІ. Перевірка правомірності використання не виконується для прикладних рішень, які використовують базову ліцензію. Процедура перевірки проводиться після завершення оновлення конфігурації системи "1С:Підприємство", при цьому програма виконує запит до "Центру захисту оновлень" (далі ЦЗВ).

Увага! На даний момент можливі технічні проблемиз доступністю сайту Центру захисту оновлень https://1cv8update.com

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

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

Інформацію про результати перевірки також можна побачити у діалозі "Про програму", який містить інформацію про те, як завершилося звернення до ЦЗВ:

Для того щоб прикладне рішення 1С успішно пройшло перевірку в ЦЗО необхідно, щоб були виконані такі умови:

• Програма має бути ліцензійною.
• На програмний продукт має бути оформлена підписка на ІТС.
• Програмний продукт має бути зареєстрований у особистому кабінетікористувача на Порталі 1С
• У конфігурації має бути підключена Інтернет-підтримка користувачів.

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

• Причина 1. Використовується неліцензійна (піратська, зламана, "варезна", "пропатчена" тощо) версія програмного забезпечення 1С.

  Вирішення: Можемо запропонувати два варіанти вирішення проблеми: придбати ліцензійну версію програмного продукту 1С або перейти на роботу в "1С у хмарі".

  Варіант 1: придбати ліцензійну версію програмного продукту 1С.

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

  Вартість програм 1С

  Найменування	Вартість руб.	Коментар
  1С:Бухгалтерія 8 ПРОФ. Електронне постачання
  Найшвидший варіант ліцензування! Термін постачання 3-4 години з моменту оплати! *		Основне постачання на 1 робоче місце із програмною системою захисту.
  1С:Зарплата та управління персоналом 8 ПРОФ. Електронне постачання Найшвидший варіант ліцензування! Термін постачання 3-4 години з моменту оплати! *		Основне постачання на 1 робоче місце із програмною системою захисту.

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

  Варіант 2: Перейти на роботу в "1С у хмарі".

  В даному випадку ви завантажуєте свою базу даних з усіма накопиченими обліковими даними на сервер хмари 1С Фреш (https://1cfresh.com/).
  Придбати програму 1С та встановлювати програму на своїх комп'ютерах не потрібно. Робота в програмі здійснюється через інтернет за допомогою звичайного браузера або "Тонкого клієнта 1С", який можна скачати з офіційного сайту 1С абсолютно безкоштовно.
  Доступ до сервера хмари 1С надається на умовах оренди по бізнес-моделі SaaS (Software as a Service). Вартість доступу до хмарної версії 1С становить 500-600 рублів на місяць за одного користувача. Точна вартість залежатиме від кількості користувачів, кількості баз даних, обраного тарифу та способу оплати.

  Вартість оренди програм 1Су хмарі за моделлю SaaS
  
  

  Найменування	Тариф "ПРОФ"**	Тариф "ТЕХНО"
  Вартість володіння на 1 користувача на місяць під час укладання договору на 12 місяців.	495 руб./міс.	525 руб./міс.
  Точна вартість залежить від умов оплати *: Оплата щомісячно Передплата за 3 місяці Передплата за 6 місяців Передплата за 12 місяців	2970 руб. 8031 руб. 15498 руб. 29664 руб.	1200 руб. 3498 руб. 6546 руб. 12528 руб.
  Кількість одночасно працюючих користувачів	5 користувачів.	2 користувача.
  Доступні програми зі списку: 1С:Бухгалтерія 8 1С:Зарплата та управління персоналом 8 1С:Управління невеликої фірми 8 1С:Бухгалтерія державної установи 8 1С:Зарплата та кадри державної установи 8 1С:Звітність підприємця 8 1С-Камін: Зарплата	Усе	Один із списку на вибір
  Кількість інформаційних баз	Без обмежень	Одна робоча база даних + одна тестова/архівна/демо

  *Вказана вартість дійсна за дотримання безперервності договору.
  ** У вартість підключення за тарифом ПРОФ крім доступу для 5 користувачів до необмеженої кількості баз даних входить ряд додаткових сервісів: 1С-Звітність; нормативно-правова база "1С: Гарант"; повний доступ до інформаційної системи 1С: ІТС; консультації та відповіді аудиторів та експертів на питання користувачів з бухгалтерського обліку, оподаткування та кадрових питань (в особистому кабінеті на сайті 1С:ІТС); доступ до оновлень для коробкових версій платформи 1С:Підприємство та типових конфігурацій 1С та ін.

  Перші 30 днів доступу безкоштовно!
  Для того, щоб ви могли самі оцінити доступність, стабільність, швидкість та зручність роботи, ми можемо надати безкоштовний доступ до хмарного сервісу 1С:Фреш на 30 днів.

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

• Причина 2. Немає чинного договору на інформаційно-технологічний супровід (ІТС).
  
  Рішення: укласти договір на інформаційно-технологічний супровід. Якщо вам необхідно терміново оформити передплату ІТС, то можете оформити її в нашій компанії навіть якщо Ви знаходитесь в іншому регіоні РФ і саму програму 1С купували в іншому місці. Єдина умова – програма має бути ліцензійною.

  Вартість підписки ІТС

  Зверніть увагу на наступні моменти:

• Є два варіанти підписки ІТС: ІТС Техно та ІТС ПРОФ, які відрізняються інформаційним наповненням. ІТС Техно включає мінімальний варіант підтримки (доступ до сайту техпідтримки 1С для самостійного скачування оновлень). ІТС Проф крім доступу до оновлень включає ряд додаткових сервісів і послуг, наприклад, 1С:Звітність, 1С:Контрагент, 1С:Фреш, 1С:Хмарний архів, правова база "ГАРАНТ" і багато інших. Детальніше порівняння ІТС Техно та ПРОФ див.
• Вартість підписки ІТЗ залежить від періоду договору. Мінімальний варіант - це разова підписка на 1 місяць, але враховуючи необхідність регулярного оновлення бухгалтерських програм для 1С:Бухгалтерії, ми рекомендуємо оформлення підписки на більш тривалий період.
• Вартість передплати при безперервному продовженні передплати ІТС менша, ніж при її поновленні.

  Найменування	Ціна при безперервному продовженні руб.	Ціна при поновленні договору руб.
  ІТС ПРОФ разова передплата на 1 місяць		4818
  ІТС Техно на 6 місяців		7854
  ІТС Техно на 12 місяців		15036
  ІТС ПРОФ на 3 місяці		9636
  ІТС ПРОФ на 6 місяців		18600
  ІТС ПРОФ на 12 місяців		35592

• Причина 3. Програмний продукт не зареєстрований у власному кабінеті користувача на порталі 1С.

  Рішення: зареєструвати програмний продукт.
  Інструкція з реєстрації програмних продуктів в особистому кабінеті Порталу 1С: ІТС (portal.1c.ru)
  Якщо користувач раніше не реєструвався на порталі, то перш ніж в особистому кабінеті реєструвати програмний продукт спочатку потрібно користувачеві зареєструватися самостійно на порталі та отримати логін та пароль для доступу до особистого кабінету.
  Інструкція з реєстрації користувачів на Порталі 1С:ІТС (portal.1c.ru)
  

• Причина 4. Не налаштована Інтернет-підтримка користувача в програмі 1С.
  
  Рішення: налаштувати інтернет підтримку.
  Інструкція з підключення інтернет-підтримки до типової конфігурацій 1С:Підприємство 8

Технічні проблеми

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

1. Недоступний сервер ЦЗО https://1cv8update.com
У цьому випадку необхідно перевірити працездатність сервера та його доступність щодо блокування антивірусами, брандмауерами, файрволами або налаштуваннями безпеки проксі-сервера.

2. На сайті https://1cv8update.com було оновлено сертифікат безпеки, а у вас використовується стара платформа 1С:Підприємство (або встановлено режим сумісності) нижче версії 8.3.8. У цьому випадку потрібно оновити версію платформи, настроїти режим сумісності або вручну прописати сертифікат безпеки у файлі cacert.pem у каталозі bin.

3. Можливо, сервер Центру захисту оновлень просто перевантажений, спробуйте повторити процедуру перевірки кілька разів натиснувши на кнопку "Повторити зараз" або виконати перевірку пізніше.

Роз'яснення щодо умов поширення оновлень програм 1С Підприємство

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

Згідно з "Ліцензійною угодою" у вартість програмних продуктів "1С" зараз входить інформаційно-технологічний супровід (ІТС) протягом 3 місяців, який включає в себе щомісячне отримання DVD дисківІТС; отримання оновлень програм, конфігурацій та форм звітності; послуги з лінії консультацій; доступ до сайту технічної підтримки"1С" (з 01.01.2016 р. можна придбати "бездисковий" варіант ІТС).

Після закінчення терміну безкоштовного супроводу обслуговування програм Фірми "1С" здійснюватиметься лише за договором на ІТС на платній основі.

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

Таким чином, не лише самі програми, а й ОБНОВЛЕННЯдо програм виробництва фірми "1С", є об'єктами виключного права фірми "1С" та поширюються за правилами, встановленими фірмою "1С" як правовласником відповідно до ст. 1225 Цивільного кодексу, а несанкціоноване ПОШИРЕННЯі ВИКОРИСТАННЯоновлень розглядається як порушення авторського права та переслідується за законом:

• ст. 1301 Цивільного Кодексу РФ,
• ст. 7.12 Кодексу Російської Федерації про адміністративні правопорушення РФ,
• ст. 146 Кримінального Кодексу РФ.

Оновлення та інформаційні ресурси повинні отримуватися користувачем легальними каналами поширення:

• диски Інформаційно-технологічного супроводу
• сайти фірми «1С»: www.1c.ru, v8.1c.ru, online.1c.ru, its.1c.ru, portal.1c.ru, releases.1c.ru, users.v8.1c.ru
• офіси партнерів фірми «1С»

Оновлення, отримані з інших джерел, є НЕЛЕГАЛЬНИМИ:

• переписали у знайомого
• оновлення встановив «студент Вася» (джерело не відоме)
• скачали з сайту, який не є офіційним сайтом «1С»
• купили в кіоску
• і т.д.

Дізнатися правомочність використання оновлення дуже просто: у фірму 1С подається інформація про всіх легальних передплатників ІТС з реєстраційними номерами встановлених програмних продуктів фірми "1С" та період підписки, у кожного оновлення є унікальний номер і відома дата виходу, дата та час встановлення оновлення на комп'ютері користувача фіксується у самій програмі, тобто. у разі перевірки у користувача на момент виходу та встановлення оновлень має бути оформлена передплата ІТС.

Перевірка наявності підписки ІТС Щоб уникнути претензій з боку правоохоронних органів та уточнення законності використання оновлень та інформаційних ресурсів, рекомендуємо користувачам перевірити наявність підписки на ІТС для свого програмного продукту на сайті фірми "1С": . Після введення реєстраційного номера програми "1С:Підприємство", що використовується, на екрані з'явиться повідомлення про наявність або відсутність чинної підписки ІТС. Перевірте, чи відправлено вами у фірму «1С» реєстраційна анкета Якщо дані змінювалися – повідомте про це у «1С» Переконайтеся, що канал, яким ви отримуєте оновлення, є легальним (офіційний партнер «1С», офіційні сайти «1С») Перед оформленням підписки ІТС перевірте, чи є компанія, яка вас обслуговує. офіційним партнеромфірми «1С» За реєстраційним номером вашої програми переконайтеся, що передплата зареєстрована в «1С» на сайті http://www.1c.ru/rus/support/support.htm Не забудьте вчасно продовжити передплату Не вимагають підписки на ІТС: Базові версії програмних продуктів "1С:Підприємство", "Хмарні" версії програм 1С використовуються в хмарному сервісі 1С:Фреш

Теги: Перевірка легальності отримання оновлень конфігурацій 1с, перевірка лекгальності оновлення 1с 8.3, контроль легальності оновлення 1с, 1с супровід 1з8

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

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

1. Очищення кешу 1С Підприємство;
2. Тестування та виправлення бази 1с 8.3.

Методика видалення кеша 1С докладно викладена у статті. Розглянемо другий сервісний інструмент адміністрування платформи 1С.

Тестування та виправлення бази 1с 8.3 за допомогою вбудованої утиліти

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

Опис утиліти «Тестування та виправлення інформаційної бази 1с»

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

• Реіндексація таблиць інформаційної бази.

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

• Перевірка логічної цілісності інформаційної бази

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

• Перевірка цілісності інформаційної бази

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

• Перерахунок підсумків

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

• Стиснення таблиць інформаційної бази

Видалення об'єктів у базі даних — операція досить копітка і тривала, у конфігураціях 1с процес видалення розділений на 2 етапи. Коли ви видаляєте об'єкти у конфігурації, у базі даних 1с дані зануляються і тому беруть участь у подальших операціях, хоча фізично залишаються дома. Щоб вичистити таблиці від цих записів роблять тестування та виправлення бази 1с 8.3 з пунктом меню «Стиск таблиць інформаційної бази».

• Реструктуризація таблиць інформаційної бази

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

Тестування та виправлення бази 1с 8.3 на практиці

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

Тестування та виправлення бази 1с 8.3 може проводитись у двох режимах:

1. Тестування. У цьому режимі база тестується та виробляються технічні виправлення незначних помилок.
2. Тестування та виправлення. У цьому режимі база 1С тестується і намагається виправити всі помічені помилки (див. рис. вище).

Щоб виконати тестування та виправлення бази 1с 8.3, необхідно натиснути кнопку «Виконати», після чого в інформаційному вікні внизу конфігуратора ви зможете спостерігати за ходом тестування та виправлення.

Подібне

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

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

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

Запустимо програму в режимі конфігуратора:

Вибираємо з меню Адміністрація пункт "Тестування та виправлення":

Які галочки ставити?

Існують різні варіанти налаштування тестування, розглянемо ці галки:

• Реіндексація таблиць інформаційної бази- це перебудова індексів для таблиць бази даних. Реіндексація збільшує швидкість роботи інформаційної бази. Процедура тривала, але ніколи не буде зайвою.
• Перевірка логічної цілісності інформаційної бази- перевіряти логічну та структурну цілісність БД, що виправляє помилки в даних;
• Перевірка цілісності інформаційної бази- Перевірка «битих посилань» у базі даних. Такі помилки можуть виникати при безпосередньому видаленні об'єктів системи або збоях. Існує 3 варіанти дій для виправлення таких помилок:
  • Створювати об'єкти- система створює елементи-заглушки, які можна потім заповнити необхідною інформацією,
  • Очищати посилання- «биті» посилання будуть очищені,
  • Не змінювати- система лише покаже вам помилки.
• Перерахунок підсумків.Підсумки - таблиця попередньо підрахованих результатів у регістрах накопичення, розрахунку та бухгалтерії. Перерахунок підсумків, також як реіндексація, ніколи не буде шкідливим і дасть плюс у швидкості роботи програми;
• Стиснення таблиць інформаційної бази- при видаленні даних 1С не видаляє рядки таблиць, лише «позначає» їх у видалення. Вони не видно користувачеві, але продовжать перебувати у БД. Стиснення бази даних видаляє ці дані безповоротно. Також такого ж ефекту можна досягти вивантаженням і завантаженням файлу інформаційної бази (*.dt);
• Реструктуризація таблиць інформаційної бази- тривалий процес, з допомогою якого система здійснює перестворення таблиць базы. Така процедура відбувається і за внесення змін до структури конфігурації.

У нашому прикладі проставимо всі галочки як показано на малюнку і натискаємо "Виконати":

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

Після закінчення тестування натискаємо “Закрити”:

Результат виконання операцій ми можемо побачити у вікні службових повідомлень.

Тестування та виправлення закінчено.

Якщо конфігуратор не відкривається: утиліта chdbfl.exe

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

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

Після того як натиснули копіювати, натискаємо правою кнопкоюна порожньому місцівікна папки та натискаємо “Вставити”. Копія зроблена, запускаємо утиліту:

З'являється головне вікно утиліти. Ми повинні вказати ім'я файлу бази даних. Натискаємо на три точки. Відкриється вікно вибору файлу БД. Шукаємо каталог вашої бази та в ньому вказуємо на файл 1Cv8.1CD. Натискаємо "Відкрити".

Ставимо галочку "Виправляти виявлені помилки" та натискаємо "Виконати".

Чекаємо на закінчення операції. Вона може тривати тривалий час, залежно від розміру бази.

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

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

Функціональна та технологічна якість системи - особливості та відмінностіФункціональна якість інформаційної системи- Це здатність певної конфігурації вирішувати бізнес завдання компанії, а технологічна якість - це висока продуктивність, відсутність збоїв і стабільна робота. Управління показниками якості значно різняться:

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

Функціональну якість системи можна перевірити за такими показниками:

• ліцензійна програма 1С вирішує всі бізнес-завдання;
• у відповідь на будь-яку коректну дію користувача, система поводиться адекватно і передбачувано.

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

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

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

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

Загальну якість конфігурації можна визначити за допомогою ряду факторів, наприклад:

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

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

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

Однак, незважаючи на поширеність, такий спосіб має кілька негативних якостей:

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

Як скоротити час на перевірку якості системи?Компанія 1С пропонує зручний інструмент"Автоматизована перевірка конфігурацій", який надає можливість:

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

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

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

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

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

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

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

Частково це пояснюється тим, що фірма 1С сама активно просуває ідею дотримання стандартів та використання придатних для цього інструментів лише серед розробників тиражних рішень через сертифікацію “1С:Сумісно”. Вплив ідеї дотримання стандартів та чистоти коду щодо широких мас розробників, які не займаються тиражними рішеннями, відчувається набагато слабше. Навіть ознайомлення з основними стандартами розробки знаходиться під умовним замком – наявністю доступу до ІТС (інформація застаріла, на даний час, на 2018-2019 рік, доступ відкритий без реєстрації) :

Базова інформація про АПК

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

Перше враження про конфігурацію може дати сторінка на сайті 1С:

На ній описані основні можливості цього інструменту та сказано, що він допомагає:

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

створювати та дотримуватися власних правил перевірки конфігурації

дотримуватись стандартів, необхідних для отримання статусу 1С:Сумісно

виконувати перевірки за розкладом

перевіряти орфографічні помилки

надавати виявленим помилкам конфігурації різні статуси, зокрема відзначати їх як “особливості” які потребують виправлення

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

згадана навіть можливість інтеграції із СППР

Іншим джерелом загальної інформаціїможе бути публікація в інтернет-журналі PCMagazine:

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

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

Почнемо з нуля. Завантажити останню версіюАПК можна за наступним посиланням:

На момент публікації цієї статті останнім релізом є 1.1.12.26 від 30.01.17, але спочатку вона писалася для версії 1.1.11.16, тому частина скріншотів та зауважень буде віднесена до цієї версії. Для роботи з АПК 1.1 знадобиться платформа версії не нижче 8.3.6. Після встановлення поставки конфігурації у списку шаблонів конфігурацій з'являються три нові пункти:

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

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

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

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

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

Взагалі принцип роботи АПК схожий роботу “Конвертації даних”. Робота в конфігураторі АПК не потрібна (хоча, як стане зрозуміло далі, без неї навряд чи вийде обійтися зовсім). Інформація про структуру конфігурацій, що перевіряються, завантажується в користувальницькому режимі. У ньому ж задаються й алгоритми перевірок конфігурації як коду мовою 1С:Предприятия, який потім самої системою виконується з допомогою оператора “ Виконати”. У коді можна і потрібно застосовувати вбудовані в АПК (не платформні) методи - процедури та функції, які виконують роботу з об'єктами, що автоматично створюються. Об'єкти необхідні проведення перевірки конфігурації створюються самої системою і стають доступними у коді обробників перевірок. Докладний описцих методів, об'єктів та обробників можна отримати з 6-го розділу "Посібники користувача".

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

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

Після запуску демо бази перед нами постає такий інтерфейс:

Призначення розділів з погляду розробників АПК можна прочитати у посібнику. Ми підемо по порядку і спочатку додамо нову конфігурацію. Натисніть кнопку “Нова конфігурація”. Система пропонує заповнити параметри підключення. Фактично відкривається форма елемента довідника "Конфігурації":

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

Інформація від розробників:

Якщо буде вказано шлях до платформи нижче, при COM-з'єднанні буде видана помилка.Причина у наступному. У зв'язку з розвитком платформи та нових перевірок АПК збираються відомості (властивості метаданих), що з'явилися лише у платформі 8.3.6 або вище. Таким чином, під час перевірки на версії, наприклад, 8.2 при зборі таких відомостей, природно, буде видано помилку. Оскільки ці нові перевірки, як правило, є пріоритетними, то виставлена ​​заборона на запуск перевірки нижче, ніж 8.3.6. У протилежному випадку (якщо клієнту принципова версія платформи нижче), то передбачається, що для перевірки конфігурації він може скористатися попередніми версіямиАПК.

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

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

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

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

Важливий момент для версії 1.1.11.16 і раніше версій АПК (у вірії 1.1.12.26 цю помилку усунуто). Після того, як налаштування задані та елемент довідника “Конфігурації” записаний, можна перевірити підключення. Але вперше система може видати помилку про відсутність підключення.

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

Фактично зараз ми створили новий елемент довідника "Конфігурації". Тепер відкрити його можна різними способами:

• Через меню "Налаштування" -> "Конфігурації"

• У розділі “Перевірки” натисніть “Вибрати конфігурацію”

• Або просто відкрити довідник "Конфігурації" через меню "Операції"

Повернемося до вікна конфігурацій.

На другій вкладці “Перевірені вимоги” можна налаштувати те, які перевірки ми хочемо виконувати над конфігурацією. Доступні два наперед визначені варіанти: “Повна перевірка” - перевірка на відповідність системі стандартів https://its.1c.ru/db/v8stdта контроль орфографії, а також "1С:Сумісно" - перевірка на відповідність стандартам 1С:Сумісно http://1c.ru/rus/products/1c/predpr/compat/soft/requirements.htm

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

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

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

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

Інформація від розробників:

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

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

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

На вкладці "Винятки з перевірки" налаштовується різна фільтрація. Наприклад, можна налаштувати перевірки так, щоб перевірялися тільки додані вами типову конфігурацію об'єкти з певним префіксом на кшталт “ мф_ СуперМитнаДекларація”.

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

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

У версії АПК 1.1.11.16 і попередніх версіях налаштування фільтрації були розділені на дві вкладки - “Фільтри збору вимог” та “Винятки при зборі даних”, але сенс був той самий:

Також у формі налаштування можна задати необхідність проведення перевірок за розкладом:

Це налаштування не для роботи через регламентне завдання. Для запуску перевірки за розкладом потрібно, щоб АПК була запущена в режимі користувача і працювала. При старті системи в модулі звичайної програми викликається метод ПриПочаткуРоботиСистеми()де підключається обробник очікування ЗапускПеревіркиЗа розкладом(), який виконує перевірку за розкладом. Якщо є бажання запускати перевірку регламентним завданням, систему доведеться доопрацювати. Якщо заглянути в конфігурацію АПК то можна побачити, що в ній є лише два регламентні завдання і обидва вони не пов'язані з перевірками за розкладом:

Інформація від розробників:

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

Розклад – це не остання з можливих вкладок. Якщо увімкнути в системі інтеграцію із “Системою проектування прикладних рішень”, то з'явиться ще одна вкладка “Інтеграція із СППР”, що дозволяє налаштувати автоматичну реєстрацію помилок у СППР. Налаштування інтеграції лише на рівні системи виконується у вигляді констант (“Операції” - “Константи”).

Функціонал інтеграції з СППР призначався розробниками АПК для внутрішнього використання у фірмі 1С (про це йдеться в "Посібнику користувача", стор.28). Проте впевнений, що для тих компаній, які у своїй роботі вже використовують СППР або планують її використовувати, цей функціонал буде цікавим. Його можна взяти за зразок для реалізації свого механізму інтеграції або розібратися з ним та використовувати "з коробки":

При цьому можливе як підключення АПК до веб-сервісу, піднятого з боку СППР, так і навпаки, можна в СППР налаштувати підключення до веб-сервісу, піднятого на стороні АПК:

Проведення перевірок

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

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

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

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

Інформація від розробників:

Тут треба також сказати, що тепер склад даних безпосередньо залежить від обраних вимог. Наприклад, вибрано одну вимогу "Орфографія у текстах модулів". Якщо відкрити картку самої вимоги та перейти на вкладку "Етапи перевірки", то можна побачити, що вибрано лише 1 прапорець "Заповнити відомості про модулі":

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

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

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

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

Натискаючи на кнопку “Далі” можна перевизначити всі налаштування, які описувалися в попередньому розділі цієї публікації, включаючи перевірки, що проводяться. Правда слід враховувати, що якщо не вибрати жодної перевірки на відповідному кроці, то система вважатиме, що потрібно виконати ВСІ перевірки, а не просто підключитися та завантажити інформацію про об'єкти з бази, що перевіряється:

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

У цьому випадку список кроків перевірки буде приблизно наступним:

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

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

Тепер залишається натиснути кнопку "Виконати перевірку". Розпочнеться процес проведення перевірок. З миготінням вікон 1С і виведенням лога процесу у вікно повідомлень. Виведення лога зроблено дуже незручно. Вікно перевірки висить модально і якщо заздалегідь не подумати про те, щоб вікно повідомлень було видно, то про те, що відбувається, не можна буде нічого дізнатися, поки процес не закінчиться.

Тому якщо у вас невелика роздільна здатність екрана, то краще відразу подбати про те, щоб зрушити модальне вікно запуску перевірки таким чином, щоб вікно повідомлень було видно.

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

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

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

Вивантаження відбувається без ієрархії – всі файли в одну папку:

Інформація від розробників:

Отже, що і коли збирається ( під час перевірки зі збором даних):

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

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

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

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

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

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

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

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

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

У процесі повної перевірки (або її аналога за кількістю правил та об'єктів) система застрягає на перевірці об'єкта №1 ніяк не повідомляючи про прогрес:

Такий статус із повідомленням про те, що перевіряється об'єкт №1 із 77 тисяч висить протягом 5-10 годин і здається, що АПК зависла. Насправді процес йде, переконатися в цьому можна, подивившись на завантаження процесора в диспетчері завдань або викликавши зупинку з конфігуратора (якщо запуск АПК проводився з нього). Причини тривалої перевірки Об'єкта №1 , саме самої конфігурації, следующие:

1) У рамках цього кроку збирається та кешується інформація, яка використовується далі при проведенні перевірок окремих об'єктів. Завдяки цьому перевірка інших об'єктів виконується швидше.

2) Більшість перевірок, що зачіпають всі об'єкти зміни одночасно, виконується саме в рамках цього кроку. Таких перевірок багато, близько 90. Але найтриваліших, що займають більшу частину часу, всього пари. Це наприклад "Пошук службових експортних методів, що не використовуються". Очевидно, що не можна зробити висновок про те, чи використовується або не використовується метод окремого об'єкта, перевіривши лише один цей об'єкт або якусь окрему підсистему. Такий висновок можна зробити лише проаналізувавши виклики методів у межах всієї конфігурації. І очевидно, що обхід всієї конфігурації оптимально робити один раз, під час перевірки "Об'єкта №1", а чи не багато разів, під час перевірки окремих документів і довідників. Іншим прикладом тривалої перевірки є "Контроль наявності загального модуля, підсистеми, методу та контроль складу параметрів".

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

Наводжу приклад - початок і закінчення лога виконання перевірки, який показує, що повністю процес на ERP 2.1 і АПК 1.1.11.16 займає близько 15 годин (природно цифра сильно залежить від продуктивності комп'ютера, також швидкість перевірки на АПК 1.1.12 значно вищаі за тих же умов займає близько 10 годин):

: Перевірка підключення до інформаційної бази через COM-з'єднання

: Початок збору відомостей про структуру метаданих конфігурації

: Початок вивантаження конфігурації у файли XML

: Початок очищення відомостей про метадані

: Початок збору відомостей про ролі конфігурації

: Зібрані та записані відомості про ролі конфігурації

: Зібрано відомості про метадані конфігурації

: Платформна перевірка конфігурації завершена

: Початок тестування об'єктів конфігурації

: Початок збору інформації про форми конфігурації з файлів XML

: Стартувала перевірка конфігурації

……...ТУТ ПОВІДОМЛЕННЯ ПОЧИНАЮТЬ ВИСНОВОК В РЯДКУ СТАНУ…..

: Виконано перевірку конфігурації

Результат перевірки

Що отримуємо у результаті виконання першої перевірки? По-перше, заповнюється довідник версій конфігурації (довідник "Версії" підпорядкований довіднику "Конфігурації"). У ньому з'являється елемент, що відповідає версії конфігурації, що перевіряється. Також оновлюється інформація про версію у формі елемента довідника "Конфігурації":

По-друге, створюється документ типу “Перевірка конфігурації” , у якому вказується цей елемент довідника “Версії” та інші параметри перевірок - склад перевірених вимог, склад об'єктів, що перевіряються, та “Журнал перевірки” в який дублюється лог, що виводився раніше у вікно повідомлень:

По-третє, оновлюються дані про структуру конфігурації:

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

І по-четверте, заповнюється регістр “Знайдені помилки”, який власне містить інформацію про те, які помилки були виявлені в процесі перевірки і є основою для звітів АПК:

Для цього регістру не створено форму списку. Звалище в цьому загальному котлі регістру можна буквально за кілька хвилин упорядкувати. Наприклад, додати керовану форму, в режимі користувача або відразу в конфігураторі вивести власника об'єктів (елементів довідника "СтруктураКонфігурації"), до яких прив'язані помилки. Цими власниками будуть версії конфігурацій.

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

Кожен запис цього регістру – це знайдена невідповідність стандартам, орфографічна чи інша помилка. Відкривши якусь із них можна переконатися, що навіть такі надійні та перевірені роками системи, як ERP 2.1 ;)) містять помилки та помилки. Причому досить велика їх кількість:

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

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

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

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

Звіти АПК

Інформацію про знайдені помилки у вигляді звітів дозволяють отримати одразу два розділи системи. Розділ "Помилки":

Він будується на базі звіту ЗнайденіПомилки:

І розділ "Звіти"

Він будується з урахуванням звіту “Результати роботи”:

Насправді у конфігурації АПК лише два основних об'єкти “Звіт”. Але у них чимало різних макетів СКД:

Усі вони базуються на аналізі регістру відомостей "Знайдені помилки". Розділ "Звіти" призначений для отримання зведеної інформації з помилок, у нього статистична спрямованість, тоді як розділ "Помилки" - для отримання детальної інформаціїз помилок та управління ними. У розділі "Помилки" керування можливе як за допомогою спеціальної командної панелі, так і через контекстне меню:

При використанні файлової бази АПК та 32-розрядної платформи 1С спостерігається проблема. Якщо не встановити достатньо фільтрів, то при аналізі помилок великої конфігурації можна отримати повідомлення про нестачу пам'яті. У випадку ERP 2.x, таке повідомлення буде з'являтися постійно. Відбувається ця помилка зазвичай вже на етапі виведення даних у табличний документ. Загалом варто ставити фільтри. У швидкі відбори винесено лише кілька із них. Інші можна встановити за командою “Налаштування звіту”.

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

Зауважу, що при використанні 64-розрядної версії 1С або SQL-ної бази АПК помилка з нестачею пам'яті не спостерігається.

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

І нарешті, в системі є інші можливості налаштування. Наприклад регістр відомостей "Вірні Слова" (спочатку порожній). Він бере участь у перевірці правопису, зокрема методі Перевірка. Перевірити Правопис (). Слова, які ми вважаємо вірними в нього, можна внести вручну або завантажити з текстового файлу, в якому кожне слово знаходиться в окремому рядку. Зразок такого txt-файлу можна вивантажити із загального макета "Словників вірних Слов". Але завантажувати цей файл у регістр не потрібно. За замовчуванням система бере вірні слова з цього макета і доповнює його даними з регістру. Також у системі існує обробка " Актуалізація словника". Дуже докладно та зрозуміло її застосування описано у посібнику користувача (див. розділ 4.6).

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

Найцікавішими звітами є “Помилки за вимогами” у розділі “Помилки”, який виводить дані у групуванні, що відповідає структурі довідника “Вимоги”:

та “Аналіз помилок” у розділі “Звіти”, який виводить зведені дані на основі класифікації “1С:Сумісно”, “Обов'язково до виконання” та “Рекомендація”:

Правила перевірки конфігурацій

Створення власних правил на конкретних прикладах тут не буде розглянуто. Спочатку потрібно краще розібратися в цьому питанні. У посібнику користувача з постачання АПК створенню нових правил присвячена досить об'ємна Глава 5 - це наскрізний приклад у вигляді цілих 30 сторінок захоплюючого тексту та ілюстрацій))

Пройдемося за правилами оглядово. Знаходяться вони в однойменному довіднику системи:

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

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

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

Алгоритм правила можна змінювати, як і створювати нові правила та групи правил. При необхідності писати свої алгоритми доведеться вивчати вбудовані методи та програмні об'єкти. Цьому присвячено відповідний розділ “Синтаксис правил перевірки” 6-го розділу PDF-посібника користувача. Також можна використовувати алгоритми існуючих правил як приклади та зразки для копіювання.

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

Фільтрування об'єктів під час проведення перевірок

На завершення подивимося як поводиться АПК 1.1 під час проведення перевірки з накладеними фільтрами. Чи вони допомагають скоротити час перевірки та зменшити обсяги інформації у звітах. Перевіримо як фільтрацію префіксом, так і підсистемою.

У цьому розділі буде більше "заривання в код", ніж розповіді про можливості АПК. Якщо на цьому етапі це не є вашою метою - цей розділ можна пропустити.

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

апк_Документ_1_1,апк_Документ_1_2і новий_Документ_1_3віднесемо до підсистеми апк_Підсистема_1

апк_Документ_2_1, апк_Документ_2_2і новий_Документ_2_3віднесемо до підсистеми апк_Підсистема_2

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

Додамо два фільтри збору відомостей – на префікс апк_та на підсистему апк_Підсистема_2 (скриншот зроблено на версії АПК 1.1.11.16):

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

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

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

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

У звітах видно, що крім інформації про документи, також збирається інформація про кореневий елемент конфігурації в рамках проведення загальних перевірок. І під час проведення перевірок важко не помітити, що саме повідомлення про перевірку цього об'єкта №1 висить у рядку стану майже всі 10 годин (На версії 1.1.11.16). При цьому система повідомляє про майбутню перевірку 65 об'єктів, хоча нам потрібні максимум 6-8 з них. Зупинимо процес у налагоджувачі в той час, коли в рядку стану висить повідомлення “Перевіряється об'єкт №1” та подивимося, які модулі піддаються перевіркам. Можна побачити, що на першому етапі перевірки система також аналізує всі об'єкти, включаючи наприклад зарплатні загальні модулі, які точно не включені до нашої нової підсистеми:

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

Отримати їх можна піднявшись по стеку викликів до методу Перевірити Об'єкти () в модулі об'єкта документа “Перевірка Версії”. З нього також можна отримати інформацію, що для перевірки вибираються ВСІ об'єкти з довідника СтруктураКонфігурації, за якими були зібрані дані, або система вважає, що дані були зібрані:

Ось ці об'єкти:

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

Маючи список цих об'єктів, можна зробити висновки про те, як працює механізм фільтрації та як працюють перевірки з урахуванням фільтрів:

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

Незважаючи на фільтри, накладені нами для перевірок, АПК збирає інформацію про модулі ВСІХ об'єктів конфігурації. Дані про модулі застосовуються АПК під час проведення загальних для всієї конфігурації перевірок. Нижче буде продемонстровано, що станеться, якщо відключити такі перевірки.

Частина загальних об'єктів буде присутня у списку на перевірку у будь-якому випадку, незалежно від наших фільтрів. У тому числі верхній кореневий об'єкт - сама конфігурація. Знову ж таки, це необхідно для проведення "загальних" перевірок. Оскільки конфігурація, що потрапила до списку, як і раніше перевіряється за тими самими правилами як і раніше, і загальні модулі, їх тексти та деякі інші дані не піддавалися фільтрації при зборі даних, то тривала багатогодинна перевірка об'єкта №1, як і раніше, буде виконуватися. Радикального прискорення процесу від застосування фільтрів одержати не вдасться.

Система вирішила перевіряти не лише документи, що задовольняють обом нашим фільтрам, а задовольняють будь-якому з них. На перевірку будуть відправлені і ті об'єкти, які починаються з префіксу апк_і ті об'єкти, що входять до підсистеми апк_Підсистема2, включаючи документ новий_Документ_2_3. З переліку об'єктів, що перевіряються, зник лише документ новий_Документ_1_3, що не підходить ні під один фільтр. Результат стане зрозумілим, якщо зазирнути у функцію фільтрації. Дозволяючі фільтри працюють за "АБО", а не за "І". Якщо це необхідно змінити, то знову ж таки доведеться внести невеликі зміни до цього методу:

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

Штучно в коді методу Перевірити Об'єкти документа Перевірка Версії пропустимо перший елемент вибірки при обході результату запиту. Тобто пропустимо кореневий елемент довідника СтруктураКонфігурації:

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

У цьому випадку від старту процесу до його завершення проходить лише 50 хвилин замість 10 годин:

: Створено документ Перевірка версії 8 від 11.01.2017 20:51:37

………………..

: Початок вивантаження конфігурації у файли XML

: Вивантаження конфігурації у файли XML завершено.

………………..

: Стартувала перевірка конфігурації

: Виконано перевірку конфігурації

Тепер звіт:

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

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

Підсумок:

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

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

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

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

Навіть найпростіші операції, що вимагають збору даних із таких конфігурацій як ERP, займають у АПК понад 20 хвилин. Тому, для розробки та налагодження своїх правил перевірки слід або створювати свої невеликі демо-конфігурації та демо-бази, в яких деякі модулі це правило порушуватимуть, або проводити перевірки за раніше зібраними даними. Обидва прийоми допоможуть прискорити процес налагодження нових правил.

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