Формування друкованих форм

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

1.1. Для формування друкованої форми користувачеві має бути достатньо прав:

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

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

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

Див. також: Використання привілейованого режиму

2. Якщо функція друку передбачає множинний друк кількох об'єктів, то з міркувань продуктивності (зниження навантаження на СУБД) необхідно виконувати вибірку даних в одному запиті, результати якого потім обходяться в циклі.

Див. також: Багаторазове виконання однотипних запитів

Винятком із цього правила можуть бути випадки, коли вибірка даних для кількох об'єктів в одному запиті

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

3.1. Друкована й екранна форми об'єктів (довідників, документів та ін.), у яких виводяться табличні частини, повинні відповідати одна одній за складом і порядком рядків табличних частин. Зокрема, під час виведення на друк не слід будь-яким чином додатково групувати рядки табличних частин.

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

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

4.1. У табличних частинах друкованих форм слід завжди виводити колонку зі значенням реквізиту «Номер рядка». У цьому разі користувачі завжди зможуть легко зіставити рядки табличних частин у друкованих та екранних формах.

4.2. У тих випадках, коли на екранній формі не відображається реквізит «Номер рядка», рядки в друкованій формі нумеруються в порядку їх виведення.

4.3. Заголовок колонки з номером рядка залежить від прикладної специфіки друкованої форми й може відрізнятися в різних друкованих формах. Наприклад, у ТОРГ-12 колонка має суворо регламентовану назву «Номер за порядком», а в нерегламентованих друкованих формах – може називатися «№».

5. Рядки табличних частин слід виводити в друкованих формах відсортованими за полем «Номер рядка», оскільки порядок виведення може бути різним у різних СУБД.

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

Див. також: Упорядкування результатів запиту

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

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

Загалом розмір полів табличного документа рекомендується не змінювати (залишати за замовчуванням), крім тих випадків, коли вони явно регламентовані або стандартизовані. Наприклад, згідно з ГОСТ Р 6.30-2003 "Уніфіковані системи документації. Уніфікована система організаційно-розпорядчої документації. Вимоги до оформлення документів" у документі мають бути задані поля: 20 мм ліве, 10 мм праве, 20 мм верхнє, 20 мм нижнє.

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

Приклад некоректного коду:

// Задамо параметри друкованої форми за замовчуванням
ТабДокумент.ПолеСверху = 0;
ТабДокумент.ПолеСлева = 0;
ТабДокумент.ПолеСнизу = 0;
ТабДокумент.ПолеСправа = 0;

8. Якщо в конфігурації передбачена можливість того, що макет друкованої форми може бути відредагований користувачем у режимі підприємства (наприклад, засобами підсистеми «Друк» Бібліотеки стандартних підсистем), то необхідно розраховувати на те, що будь-які параметри в ньому можуть бути змінені або видалені. Тому для підвищення стійкості коду формування друкованої форми слід уникати явного присвоєння значень параметрів у областях друку. Замість цього слід використовувати глобальний метод ЗаполнитьЗначенияСвойств або метод Заполнить колекції ПараметрыМакетаТекстовогоДокумента.

Неправильно:

ОбластьПечати.Параметры.Организация = ДанныеПечати.Организация;

// буде помилка за відсутності в макеті параметра Организация
ОбластьПечати.Параметры.Контрагент = ДанныеПечати.Контрагент;

Правильно:

ЗаполнитьЗначенияСвойств(ОбластьПечати.Параметры, ДанныеПечати);

або

ОбластьПечати.Параметры.Заполнить(ДанныеПечати);

Примітка: у змінній ДанныеПечати у прикладах може бути Структура, Соответствие, ВыборкаИзРезультатаЗапроса або будь-яка інша колекція зі значеннями параметрів.

Див. також

• Назви друкованих форм облікових документів і команд для їх виведення на друк