Проект "Сумісно"

Вимоги до програмних продуктів, які подаються на сертифікацію за проектом "Сумісно" з продуктами BAS

1. Загальні вимоги

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

1.2. Продукт повинен мати документацію (посібник користувача) українською мовою.

1.3. У посібнику користувача явно повинна описуватися взаємодія продукту з платформою.

1.4. Програмний продукт повинен використовувати тільки штатні і документовані можливості роботи.

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

1.6. Використання логотипу "BAS" в оформленні програмного продукту і назви "BAS" в його найменуванні можливо тільки за спеціальним погодженням з правовласником торгової марки, наприклад, для спільних розробок. У разі успішної сертифікації фірма-розробник має право використовувати для оформлення логотип "BAS Сумісно".

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

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

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

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

2. Вимоги до конфігурацій, які подаються на сертифікацію за проектом "Сумісно"

2.1. Загальні відомості про конфігурацію

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

2.1.2. Номер версії вказується у властивостях конфігурації. Номер версії формується за правилами, описаними в статті "Нумерація редакцій і версій" документа "Система стандартів і методик розробки конфігурацій для платформи", опублікованого на сайті ІТС.

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

2.1.4. Конфігурація повинна бути однаково розрахована на роботу з усіма СУБД, операційними системами, веб-браузерами і різними режимами роботи, які підтримує платформа.

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

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

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

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

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

2.2. Початкові дії при роботі конфігурації

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

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

2.3. Оформлення об'єктів конфігурації

2.3.1. Імена об'єктів метаданих не повинні перевищувати 80 символів.

2.3.2. Синонім об'єкта метаданих обов'язково заповнюється. Синонім повинен визначатися так, щоб осмислено і лаконічно описувати об'єкт.

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

2.3.2.2. У разі якщо в об'єкта метаданих є стандартні реквізити (стандартні табличні частини), для них слід вказувати синоніми, виходячи з прикладного сенсу кожного реквізиту.

2.3.2.3. Для стандартних реквізитів Батьківський елемент і Власник, слід завжди вказувати синоніми, відмінні від синонімів за замовчуванням.

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

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

2.3.5. Об'єкти метаданих верхнього рівня, такі як Довідники, Документи, Загальні модулі і т.д. впорядковуються в дереві метаданих по імені. Підлеглі об'єкти метаданих, такі як реквізити, вимірювання, форми, розташовуються в дереві метаданих відповідно до проектної логіки.

Виняток становлять:

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

2.3.6. Конфігурація в цілому і її основні об'єкти, що мають властивість "Довідкова інформація", повинні мати опис для користувача. Для об'єктів довідкова інформація повинна містити відомості:

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

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

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

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

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

2.4. Інтерфейси і форми

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

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

2.4.3. Для всіх типізованих об'єктів метаданих, а також для стандартних реквізитів, які відповідно до логіки об'єкта є обов'язковими до заповнення, властивість "Перевірка заповнення" повинна мати значення "Видавати помилку", або подібна перевірка повинна прописуватися розробником самостійно в модулі.

2.4.4. Якщо продукт призначений для роботи в режимі керованого додатку, він повинен відповідати наступним вимогам:

2.4.4.1. Останнім розділом в інтерфейсі завжди повинен бути розділ для адміністрування, налаштування і виконання сервісних дій.

2.4.4.2. Робочий стіл є обов'язковим розділом і не може бути відключений.

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

• основна форма списку;
• основна форма звіту;
• основна форма обробки.

2.4.5. Якщо продукт призначений для роботи в звичайному режимі, він повинен відповідати таким вимогам:

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

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

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

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

2.5. Загальні принципи оформлення модулів

2.5.1. Тексти модулів оформлюються за принципом "один оператор в одному рядку". Наявність кількох операторів допускається тільки для "однотипних" операторів присвоювання, наприклад: А = 0; Б = 0; С = 0.

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

2.5.3. Конфігурація не повинна містити помилок, які виявляються при синтаксичному контролі модулів.

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

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

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

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

• секція "Опис" – містить короткий опис призначення і/або принципів роботи процедури (функції), може бути єдиною секцією для функцій без параметрів;
• секція "Параметри" – описує параметри процедури (функції), якщо їх немає, секція пропускається, їй передує рядок "Параметри:";
• секція "Значення, що повертається" – описує тип і зміст значення функції, що повертається, їй передує рядок "Значення, що повертається:". Для процедур ця секція відсутня;
• секція "Приклад" містить приклад використання процедури, або функції. Їй передує рядок "Приклад:". Далі з нового рядка приклад використання.

2.5.8. Тексти модулів в складних алгоритмах повинні містити коментарі.

• Якщо коментар відноситься до модуля в цілому, він розташовується на початку модуля (заголовок модуля).
• Якщо коментар відноситься до оператора або групи операторів, він розташовується перед оператором, який коментується (групою операторів).
• Довгі коментарі повинні починатися з великої літери і закінчуватися крапкою. Слід перевіряти текст коментаря на відсутність граматичних і синтаксичних помилок.
• Текст довгого коментаря слід вирівняти за лівою границею оператора, який коментується (першого оператора групи операторів).
• Між символами коментарю "//" і текстом коментарю повинен бути пробіл.
• Рядки не повинні бути довшими 120 символів, за винятком тих випадків, коли перенесення неможливе.

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

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

2.5.11. Програмні модулі не повинні мати зайвих або порожніх процедур і функцій і закоментованих фрагментів коду.

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

2.5.13. Забороняється використовувати оператор Перейти в загальних модулях з ознакою "Клієнт (керований додаток)", модулях команд і в клієнтському коді модулів керованих форм, так як даний метод не підтримується платформою в режимі веб-клієнта.

2.5.14. Не слід розміщувати експортні процедури і функції в модулях форм. Винятки з цього правила можливі в окремих, обґрунтованих випадках. Деякі з них перераховані у системі стандартів і методик розробки конфігурацій, опублікованій на сайті ІТС в розділі "Правила створення модулів форм".

2.5.15. Властивість Змінює дані має бути встановлена в значенні Істина для всіх команд, які змінюють або можуть змінювати дані об'єкта.

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

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

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

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

2.5.20. У процедурі ПриЗавершенніРоботиСистеми модуля керованого додатку неприпустимо використовувати асинхронні виклики.

2.5.21. Якщо в процедурі ПередЗавершеннямРоботиСистеми модуля керованого додатку використовуються асинхронні виклики, то в ній необхідно встановити значення параметра Відмова = Істина і з процедури сповіщення про завершення асинхронного виклику продовжити завершення роботи системи.

2.6. Стандартні ролі

2.6.1. Якщо в конфігурації є розмежування прав доступу користувачів до даних, то в конфігурації потрібно визначити три обов'язкові ролі, що призначені для "прикладного" і системного адміністрування інформаційної бази, а також для інтерактивного відкриття зовнішніх звітів і обробок: ПовніПрава (синонім "Повні права"), АдміністраторСистеми (синонім "Адміністратор системи") і ІнтерактивнеВідкриттяЗовнішніхЗвітівІОбробок (синонім "Інтерактивне відкриття зовнішніх звітів і обробок").

2.6.2. ПовніПрава – обов'язкова роль, яка надає необмежений доступ до всіх "прикладних" даних інформаційної бази, але не дає прав доступу для адміністрування інформаційної бази в цілому (оновлення конфігурації, робота в конфігураторі і т.п.). Ця роль повинна:

• дозволяти самостійне використання (може бути призначена користувачам);
• надавати необмежений доступ до всіх даних області (до розділених даних), крім права інтерактивного вилучення;
• дозволяти виконувати всі адміністративні дії з областю даних (адміністрування користувачів, настройка програми, вилучення позначених об'єктів і т.п.);
• включати в себе перераховані права: Адміністрування даних, Активні користувачі, Журнал реєстрації, Монопольний режим, Тонкий клієнт, Веб-клієнт, Збереження даних користувача, Виведення.

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

2.6.3. АдміністраторСистеми – обов'язкова роль, яка надає додаткові права на адміністрування інформаційної бази в цілому (оновлення конфігурації, робота в конфігураторі і т.п.). Ця роль повинна:

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

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

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

2.6.5. Ролі АдміністраторСистеми, ПовніПрава і ІнтерактивнеВідкриттяЗовнішніхЗвітівІОбробок повинні встановлюватися як основні ролі конфігурації (властивість ОсновніРолі).

2.6.6. Для жодної ролі, включаючи ПовніПрава і АдміністраторСистеми, не повинно бути встановлено (крім окремих обґрунтованих випадків) наступних прав:

• Право інтерактивного вилучення;
• Інтерактивне вилучення напередвизначених даних;
• Інтерактивна позначка вилучення напередвизначених даних;
• Інтерактивне знімання позначки вилучення напередвизначених даних;
• Інтерактивне вилучення позначених напередвизначених даних.

Право вилучення рекомендується залишити тільки для ролей ПовніПрава і АдміністраторСистеми.

2.7. Оформлення текстів запитів

2.7.1. Усі ключові слова мови запитів пишуться великими літерами.

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

2.8. Повідомлення, попередження, сповіщення

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

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

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

2.8.4. Модальні діалоги, питання, попередження не повинні викликатися всередині транзакцій запису і проведення.

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

Приклад 1. Якщо користувачеві необхідно вибрати між пунктами "Вилучити" та "Відмітити для вилучення", вибором за замовчуванням повинен бути "Відмітити для вилучення".

Приклад 2. Якщо користувачеві пропонується вибір між відповідями "Друкувати без попереднього перегляду" та "Друкувати з попереднім переглядом", вибором за замовчуванням повинен бути "Друкувати з попереднім переглядом".

2.8.6. Інформація про помилки, виявлені під час перевірки заповнення, повинна виводитися в панелі повідомлень форми.

2.8.7. Інформація про помилку повинна доводитись до користувача в модальному діалозі.

2.8.8. Інформація про успішне виконання дії в формі повинна виводитися в разі, якщо факт виконання команди не очевидний для користувача.

2.8.9. Інформація про успішне виконання дії в умовах відсутності форми на екрані має також виводитися в тому випадку, коли для користувача може виявитися неочевидним той факт, що дія виконана.

2.8.10. Для виведення повідомлень користувачеві у всіх випадках слід використовувати об'єкт ПовідомленняКористувачеві, навіть коли повідомлення не "прив'язується" до деякого елементу управління форми. Метод Повідомити застосовувати не слід.

2.9. Документація конфігурації

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

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

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

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

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

2.10. Поставка конфігурації

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

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

2.10.3. Конфігурація має постачатися разом із встановленою підтримкою.

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

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

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

2.10.7. Конфігурація може бути захищена у апаратний або програмний спосіб. У цьому випадку:

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

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

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

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

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

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

3.3. Документація надається українською мовою.

3.4. У документації потрібно вказувати, для якої конфігурації цей продукт можна застосовувати.

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

3.6. Усі додані об'єкти і реквізити конфігурації повинні мати в назві префікс, що виділяє їх від об'єктів конфігурації, або відноситися до іншої підсистеми. При використанні декількох (різних) префіксів, необхідно обґрунтувати їх застосування.

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

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

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

3.10. Додатки повинні поставлятися з прикладом в окремій Інформаційній Базі для демонстрації можливостей продукту. Опис прикладу повинен міститися у документації.

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

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

4. Вимоги до комплекту сервісних звітів і обробок, які подаються на сертифікацію за проектом "Сумісно"

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

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

4.3. Документація надається українською мовою.

4.4. У документації повинно бути вказано, для якої конфігурації цей продукт можна застосовувати.

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

4.6. Всі змінні модулів повинні мати коментарі. Коментарі повинні бути досить детальними, щоб пояснювати призначення змінних. Коментарі ставляться в тому ж рядку після змінної.

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

• секція "Опис" – містить короткий опис призначення і/або принципів роботи процедури (функції), може бути єдиною секцією для функцій без параметрів;
• секція "Параметри" – описує параметри процедури (функції), якщо їх немає, секція пропускається, попереду повинен бути рядок "Параметри:";
• секція "Значення, що повертається" – описує тип та зміст значення функції, що повертається, попереду повинен бути рядок "Значення, що повертається:", для процедур ця секція відсутня.

5. Вимоги до зовнішніх компонент системи програм, які подаються на сертифікацію за проектом "Сумісно"

5.1. Для розширення функціональних можливостей використовуються зовнішні компоненти. Зовнішні компоненти повинні бути розроблені відповідно до технології створення зовнішніх компонент, яка поставляється правовласником. Вона дозволяє створювати зовнішні компоненти для ОС сімейства Windows і ОС сімейства Linux, а також для веб-клієнта, що працює в веб-браузерах Microsoft Internet Explorer версії 8 і вище, Google Chrome 4 і вище (для OC Windows), Mozilla Firefox версії 17 і вище (для OC Windows і Linux). У даній категорії сертифікуються зовнішні компоненти, не призначені для роботи з торговим обладнанням. Сертифікація зовнішніх компонент для торгового обладнання проводиться за категорією Торгове обладнання.

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

5.3. Усі варіанти компоненти повинні упаковуватися в ZIP-архів з маніфестом.

5.4. Документація надається українською мовою.

5.5. У документації повинно бути вказано, для якої конфігурації цей продукт можна застосовувати.

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

5.7. Усі властивості і методи зовнішньої компоненти повинні описуватися у документації.

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

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

5.10. У текстах модулів усі місця підключення і використання методів зовнішньої компоненти повинні виділятися коментарями.

6. Вимоги до систем віддаленого банківського обслуговування

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

6.2. Для програми може бути відсутнім "коробковий" вид продукту.

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

6.4. Для проходження процедури сертифікації необхідно надати дистрибутив (при наявності) з демонстраційною базою або забезпечити доступ до тестового стенду для перевірки взаємодії.

7. Вимоги до продуктів, які використовують різні способи взаємодії та обміну даними з системою "BAS"

7.1. У посібнику користувача повинно бути вказано, для якої версії "BAS" інтегровано продукт.

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

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

7.4. У посібнику користувача повинна описуватися технологія і механізм взаємодії між програмами з приведенням наочних прикладів.

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

7.6. Якщо продукт надається на відповідність обміну даними EnterpriseData, він повинен бути виконаний відповідно до технології його створення, опублікованій у статті "Обмін даними з прикладними рішеннями в форматі EnterpriseData" на сайті ІТС.

8. Вимоги до розширень конфігурацій, які подаються на сертифікацію за проектом "Сумісно"

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

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

8.3. Розширення повинно мати одне з наступних призначень:

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

8.4. Розширення конфігурацій повинні коректно враховувати наступні припущення:

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

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

8.6. Якщо розширювані методи містять будь-які параметри, то всі розширюючі методи зобов'язані мати в точності такий самий опис, як і розширюваний метод, з точністю до ключових слів в описах параметрів методів.

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

8.8. У розширеннях допускається застосовувати тільки програмний захист.

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

8.10. Документація надається українською мовою.

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

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

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

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

---

Додаток 1

Регламент реєстрації назв розробників конфігурацій

Інформація для спеціалістів

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

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

Рекомендації щодо встановлення прикладних рішень

Установка прикладних рішень (конфігурацій) повинна виконуватися відповідно до рекомендацій, викладених у розділі 3 "Установка конфігурацій" книги "Посібник адміністратора".

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

<Каталог програми>\tmplts\<каталог розробника>\<каталог конфігурації>\<каталог версії>

Наприклад, версія 1.1.8.1 конфігурації "Управління видавництвом", редакція 1, буде встановлюватися в каталог:

\Program Files\NetHelp\tmplts\service\publish\1_1_8_1\

У каталозі версії повинен розташовуватися файл-маніфест *.mft, в якому описуються встановлені шаблони конфігурації (інформаційні бази).

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

Приклад файлу-маніфесту (усі назви і коди умовні)

Vendor = Фірма "Сервіс"
Name = Видавництво_ред.1
Version = 1.1.8.1
[Main]
Source = 1cv8.cf
Catalog = Сервіс:Видавництво\УправлінняВидавництвом
Destination = SERVICE\Publish
[Demo]
Source = 1cv8.dt
Catalog = Сервіс:Видавництво\УправлінняВидавництвом(Демо)

Destination = SERVICE\PublishDemo

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

• У рядку Catalog файлу-маніфесту, в найменування шаблону конфігурації (частина значення до символу "\") включати назву розробника. Назва розробника може бути присутня в будь-якому місці найменування шаблону конфігурації, наприклад:
Фірма "Сервіс": Управління видавництвом
або
Управління видавництвом (Фірма "Сервіс")
• У рядку Destination рекомендований каталог створення інформаційної бази вказувати у вигляді:
Destination = <каталог розробника>\<каталог інформаційної бази>
<каталог розробника> повинен містити назву розробника, але в цьому випадку – адаптовану для використання в іменах файлових каталогів.

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

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

Порядок реєстрації назв розробників

• Розробник прикладних рішень надсилає на адресу hotline@bas-soft.eu лист (в кодуванні UTF-8), а також його скан-копію, з наступним змістом:
До відділу технічної підтримки продуктів для автоматизації бізнесу
Назва розробника: <повна назва організації-розробника>
Код партнера (для партнерів – членів САБ): <код партнера>
Прошу зареєструвати назву розробника:
• для файлових каталогів: <ім'я каталогу розробника>
• для найменувань шаблонів конфігурацій <рекламна назва розробника>
<ім'я каталогу розробника> рекомендується вказувати в форматі MS-DOS (8.3).
<рекламна назва розробника> не повинна містити символів "\" і "/".
Приклад (усі назви і коди умовні)
До відділу технічної підтримки продуктів для автоматизації бізнесу
Назва розробника: Фірма "Сервіс"
Код партнера: 11111-11
Прошу зареєструвати назву розробника:
• для файлових каталогів: service
• для найменувань шаблонів конфігурацій: Сервіс
Лист повинен бути підписаний керівником організації.

• У тижневий термін після одержання листа відповідальна особа відділу технічної підтримки продуктів для автоматизації бізнесу відправляє або підтвердження реєстрації імені каталогу і назви розробника, або відмову в реєстрації із зазначенням причин і рекомендаціями щодо їх усунення.
• Після отримання прикладним рішенням сертифіката "Сумісно", правовласник публікує зареєстроване ім'я каталогу і назву розробника на сайті http://www.bas-soft.eu.
• Розробникам прикладних рішень не слід використовувати назви, зареєстровані іншими розробниками.