Про ТабДок или TabDoc Pro

Табличный документ – всем знакомый и привычный компонент продукта 1С. Про оптимизацию работы табличного документа, его проблемы и недостатки в своем докладе на конференции Infostart Event 2024 Education рассказал ведущий программист BIA-Technologies Князьков Алексей.

 

Преимущества табличного документа

 

 

В свое время, когда компания «1С» выпустила версию 7.7, а потом 8.0, табличный документ просто поражал воображение:

  • Главное его отличие от конкурентов в том, что он интерактивный – с помощью расшифровок и обработки событий можно делать «живые» отчеты. 

  • У него очень много интересных возможностей, в частности, различная ширина колонок.

  • Его очень просто использовать и очень просто делать макеты. Это очевидные вещи, прошу прощения, что рассказываю то, что всем известно. Программисты очень быстро осваивают этот инструмент и начинают делать отчеты. Пользователей тоже не нужно учить – бухгалтера, которые никогда не видели компьютер, очень быстро осваивают отчеты, построенные на табличных документах, и очень лихо работают со всякими оборотно-сальдовыми ведомостями, шахматками и прочим. Тыкая в цифры, «проваливаются» и получают расшифровку, откуда эта цифра взялась.

Попытки построить системы, подобные 1С, были очень успешными, пока не возникала необходимость в написании отчетов. Когда же речь заходила про написание отчетов – никто не мог повторить успех.

 

Оптимизация формирования отчетов. «Кэш областей»

 

 

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

  • Считается, что если в отчете используется сложный макет, и нужно использовать «Присоединить», то он формируется очень долго, даже если запросы написаны оптимально, данные подготовлены и заранее посчитаны. 

  • В случае, когда заранее непонятно, какая у финального отчета будет структура – она генерируется только в момент его формирования, не используйте «Присоединить». Вместо этого рекомендуется использовать методологию, которую мы у себя в компании назвали «Кэш областей». 

 

 

Что значит «Кэш областей»? Это – коллекция заранее построенных областей, чтобы не строить их при выводе каждой строки во время формирования отчета. Перед выводом отчета уже понятно, какие области будут использоваться, поэтому мы можем построить их заранее. Важно отметить, что построить нужно сразу все области, которые будут использоваться – это и «Заголовок», и «Шапка», и «Строка», и «Подвал», чтобы они все встали друг над дружкой, и чтобы последующая область не съехала из-за того, что в предыдущей области какие-то ячейки не были выведены (многие знают этот эффект). 

Легко сказать, но как же это сделать? Я, кстати, подобного решения не видел даже в типовых конфигурациях и на Инфостарте поискал специально – никто об этом не говорил.

 

 

Здесь приведен пример упрощенной процедуры, которая генерирует эти области. 

Суть в том, что все эти действия с методом «Присоединить» мы должны сделать заранее при построении только одного экземпляра каждой области – только один раз. При построении этой области мы должны бережно перенести туда все настройки из макета – задать параметры, расшифровки. А потом эти сгенерированные области поместить в какую-нибудь коллекцию – в соответствие или в массив. И во время формирования отчета пользоваться уже заранее построенными областями, заполнять их параметры и выводить.

Это дает профит в виде кратного увеличения скорости при выводе отчета. Например, с 20 минут до нескольких секунд. У нас очень большая база, и некоторые отчеты нам удалось таким образом существенно оптимизировать. Это – реальный факт.

 

Оптимизация для быстрого сохранения отчета

 

 

Еще говорят, что табличный документ с большим количеством строк долго сохраняется – в Excel или в MXL. Чтобы отчет сохранялся быстро, его нужно к этому подготовить – не нужно сохранять тот же отчет, которым пользуются бухгалтеры (с расшифровками, со ссылками, со сложными объектами). Если использовать только примитивы (строки, числа и прочее), отчет сохранится гораздо быстрее (тоже идет кратное увеличение скорости). Это потребует определенной переработки кода, зато даст результат.

 

Варианты применения табличных документов

 

 

Варианты применения. 

  • Конечно же, печатные формы и отчеты – но это скучно;

  • Табличные документы используются для хранения настроек в макетах конфигурации – для каких-то предопределенных значений и прочего;

  • Простой и быстрый экспорт/импорт небольшого объема данных – можно очень быстро выгрузить данные, чтобы потом их загрузить в другой базе;

  • Можно также строить интерфейсы.

 

 

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

 

Пожелания и проблемы

Почему я вышел с этим докладом? Для того, чтобы обратить внимание на этот компонент 1С, который, к сожалению, в последние годы перестал развиваться. При всей его замечательности у него существует ряд проблем, которые, почему-то не решаются. Хотелось бы обратить внимание, в том числе компании «1С» на эти проблемы.

 

Нет интерактивной работы с областями в режиме предприятия

 

 

Первое, тривиальное пожелание – добавить интерактивную работу с областями в режиме «1С:Предприятие». Для чего это нужно? 

Табличный редактор в режиме конфигуратора сильно отличается от того, который есть в режиме «1С:Предприятие» – в пользовательском режиме мы не можем задавать области, а было бы полезно, чтобы непосредственно пользователи могли создавать по заранее обговоренным соглашениям и инструкциям ценники, бейджики, договоры (некие макеты, которые можно хранить в справочниках, и которые вступают в силу с какого-то определенного числа). Такая задача реально стояла, и она так и осталась в рамках программирования – пользователям было не объяснить, как работать с областями, которых не видно.

 

Нет разделов для вывода разноформатного документа

 

 

Разделы. Хотелось бы, чтобы в табличном документе появились разделы, как, например, в Microsoft Word – когда нужно формировать разноформатный документ, каждая страница которого может иметь свой собственный формат – книжный, альбомный. Это очень важно для бизнеса, например, при групповой печати документов. 

Объект 1С «ПакетОтображаемыхДокументов», который добавили с 8.3.6, не годится, потому что для каждого формата формируется отдельное задание на печать. А при той же групповой печати документов, кстати, задание на печать при попадании в очередь принтера печатается рандомно. То есть, невозможно задать очередность печати этих документов, используя только драйвер принтера, не используя какие-то дорогие принтсерверные приложения.

Хотелось бы, чтобы этим можно было управлять со стороны 1С.

 

Нет возможности программно группировать рисунки

 

 

Нет возможности программно группировать рисунки. Их можно группировать только интерактивно по правой кнопке мышки. 

Почему это важно? Сгруппированный рисунок занимает гораздо меньше места в памяти – в том же задании на печать или при сохранении, чем если все его составляющие будут по-отдельности.

 

Нет возможности назначить обработчик расшифровки произвольно открываемому табличному документу

 

 

Обработчик расшифровки. Почему-то нет возможности назначить обработчик расшифровки с формы владельца произвольно открываемому табличному документу – для этого приходится содержать специальные формы и назначать для них обработчики. Грубо говоря, если вам нужно открывать различные табличные документы и использовать для них расшифровки, нужно специально подготовить для них какие-то формы и хранить их в конфигураторе – мне кажется, что это лишнее.

 

Нет генератора штрихкодов

 

 

Штрихкоды. В платформе 1С почему-то нет какого-то платформенного средства генерации штрихкодов, хотя бы в формате SVG. Если бы генерировалась XML или готовый SVG – было бы прекрасно. Система «1С:Предприятие» предназначена, в том числе, для автоматизации склада и торговли, где штрихкоды используются повсеместно – но почему-то их обошли стороной, приходится пользоваться чем-то сторонним. 

Есть какой-то парк нативных компонент, которые генерируют png, есть какие-то процедуры на том же Инфостарте, я сам писал процедуры. Чаще всего для генерации мы используем компоненту «Печать штрихкодов», которая поставлялась ранее на дисках ИТС. У нее есть существенный недостаток – она работает только в толстом клиенте. Но нам приходится использовать ее и не уходить в управляемый интерфейс, потому что эта компонента не дает эффекта, про который я вам сейчас расскажу.

 

При печати ТабДока с картинками сильно «пухнет» задание на печать 

 

 

При печати табличного документа с картинками сильно «пухнет» задание на печать. Проводились тесты – печать 1000 штрихкодов, сам MXL занимает, допустим, 4Мб, а задание на печать в 10 раз больше – 47 Мб. При печати еще большего количества картинок задание может доходить даже до гигабайта и более. 

У нас был реальный опыт, когда мы в той же групповой печати документов перешли на новую нативную компоненту, и задание на печать вместо ожидаемых 1-2 минут стало уходить на печать по 20-30 минут и увеличилось до нескольких гигабайт. Это было очень печально. 

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

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 EDUCATION. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.

26 Comments

  1. Светлый ум

    А пример сложного интерфейса в виде обработки есть возможность выложить? интересно пощупать…

    Reply
  2. dreamadv

    Штрихкода где возможно стараемся использовать в виде шрифтовых решений, реальные интеграции EAN-13, CODE 39, CODE 128. Меньше проблем с печатью и не пухлый размер спулл задания.

    Reply
  3. AKnyazkov

    (1) Такие обработки обычно не имеют смысла без конфигурации, если интересно могу попробовать сделать демо-пример конфигурации

    Reply
  4. AKnyazkov

    (2) Штрихкоды построенные спец.шрифтами это немного не то, чего хотелось бы и не удовлетворяют всем требованиям макетов, таких как рзмер например.

    Reply
  5. kiser

    Ещё не хватает возможности при формировании отчёта точно знать влезет ли очередная область на страницу или перенесется. Как пример нельзя при печати расчетников узнать сколько их влезет на лист. 3, 4 или даже 5 если коротенькие

    Reply
  6. AKnyazkov

    (5) Есть же метод «ТабДок.ПроверитьВывод()»? Правда он тоже замедляет фоормирование, и применять его тоже лучше с умом, как вариант не при каждой итерации в цикле, а только когда наступает «критически» момент и т.д.

    Reply
  7. for_sale

    (6)

    С этим методом тоже есть проблемы. Например, нужно было выводить длинную таблицу с товарами, а в конце каждой страницы печатать «Лист 1 из Х». Во-первых, эти Х вообще никак не посчитаешь, пока всё не выведешь. Во-вторых, когда ПроверитьВывод говорит, что уже не влазит, эту область туда уже поздно вставлять, уже не влазит.

    Reply
  8. AKnyazkov

    (7) Метод не идеальный, и сильно зависит от внешних факторов (драйвера принтера, например).

    Но иногда без него никак не обойтись, и если область не влазит, а нужно, чтоб влезла, как вариант можно уменьшить масштаб ТабДока.

    Reply
  9. Yashazz

    Напомню, что некоторые проблемы можно обходить, сериализовав табдок в хмл, и покурочив уже сам этот хмл. Вопросы с областями-секциями и некоторые фишки «конфигураторного» табдока я так делал в своё время.

    Reply
  10. Светлый ум

    (3) Пример был бы на пользу многим.

    Reply
  11. ZloyProger

    Поддержу (10) пример был бы познавательным, делал нечто подобное — рабочий стол для службы снабжения, скрещивал 1с с Excel (отборы, формулы и т.д.), дойдут руки мб и выложу тоже, вдруг кому поможет)

    Ещё из проблем — отсутствие возможности платформенными методами (через грабли конечно можно подгоняя под конкретные ситуации, даже видел статью здесь, где на мой взгляд оригинальный подход) определить что текст не помещается в ячейку (при этом платформа ведь понимает, что не влезает если сделать Переносить — переносит!!).

    Reply
  12. milanse

    Хотелось бы ещё про скорость и вообще механизм передачи с сервера на клиент замолвить слово. Отчёт после формирования целиком лежит на сервере, поэтому сразу быстро открывается , стрелками вверх вниз и клавишами pgup pgdown передается с сервера порциями по 100 строк, клавиша end тоже отрабатывает, по типу dbf last, а вот потом если ещё раз нажать pgup весь документ начинает скачиваться с сервера порциями по 100 строк, что это ? В итоге фриз всей системы на несколько секунд.

    Reply
  13. AKnyazkov

    (10) (11) ОК, сделаю тестовую конфу с примером и выложу. )

    Reply
  14. Evil Beaver
    в пользовательском режиме мы не можем задавать области

    Так можем же! В толстом клиенте точно, и по-моему в тонком тоже. Можно задавать и области и имена ячеек, 1С:Свод отчетов на этом и держится, там полноценный редактор таб. макета в режиме Предприятия.

    Reply
  15. dreamadv

    (4) каких-то не возможных проблем с размером не возникало практически всегда можно подогнать размером шрифта и выравниванием в ячейке и размером самой ячейки по высоте

    Reply
  16. AKnyazkov

    (14) Да, с какойто версии платформы это стало возможно, согласен…

    Reply
  17. Evil Beaver

    (16) в 8.1 точно было, причем с очень ранних версий. Грубо говоря, в 2009 году я уже это использовал

    Reply
  18. AKnyazkov

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

    Reply
  19. Evil Beaver

    (18) Аа, это да 🙂

    Reply
  20. BackinSoda

    Увидеть бы использование Кэша областей в варианте до ускорения и после. Или просто пример с вызовом этой процедуры

    Reply
  21. AKnyazkov

    (20) Я готовлю тестовую ЦФ-ку, т.к. много людей попросили сделать это, может пример с кэшем областей «до/после» включу туда

    Reply
  22. vano-ekt

    самая боль в ТабДоке — ПроверитьВывод(), долго проверяет…

    когда, например, есть длинный-длинный прайс с нефиксированной высотой строк / заголовков групп

    до половины можно примерно «на глазок» пропустить проверку, но когда появляется неопределенность — все равно начинаешь проверять вывод каждой строки, чтобы на следующую страницу вывести, например, шапку и название текущей товарной группы

    если это каталог на сто листов и несколько тысяч позиций, то очень долго формируется печ.форма, ну и замер производительности указывает ПроверитьВывод() 99,9% времени выполнения. На разных компах/серверах/сетях, с разными драйверами/принтерами, в терминале/локально

    Reply
  23. vano-ekt

    (7) запихнуть страницы в ТаблицуЗначений, посчитать количество строк(Х), пробежаться по ТаблицеЗначений, вывести страницы, заполняя поля-«колонтитулы»,

    Reply
  24. AKnyazkov

    (22)

    ПроверитьВывод() — не такая уж и медленная…

    Просто нужно правильно ее готовить )

    Если у вас большой прайс, где много страниц, не нужно выводить сразу в результирующий документ все строки…

    В (23) уже был предложен ответ…

    Попробуем разобраться, что имелось ввиду

    вывод результата -> кэш -> Финальный документ

    где «кэш» это массив, где каждый элемент табличный документ, содержащий только одну страницу.

    т.е. если страница «готова», складываем ее в массив и начинаем вывод в новый табдок.

    когда все строки выведены, выводим каждую страницу из кэша в табдок — результат.

    таким образом можно решить и ту проблему, которая была озвучена в (7).

    Reply
  25. vano-ekt

    (24)именно так, складываем в массив страницу, но перед складыванием страницы, ты все равно вызываешь ПроверитьВывод() перед помещением её в массив. Один или одиннадцать раз. Для каждой страницы/элемента массива. Таких страниц 100.

    Reply
  26. Светлый ум

    В итоге решили не выкладывать пример?

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *