Данная статья завершает цикл, посвященный возможностям системы БАЗИС по формированию качественной документации для мебельного производства, начатый во втором и десятом номерах журнала за этот год. В ней рассказывается и о тех новшествах, которые появились в финальном релизе 2023 года.
Качественная документация на всех этапах работы над мебельным дизайнпроектом без преувеличения является тем фактором, который напрямую влияет на эффективность, качество и конкурентоспособность производителя. В октябре вышел финальный релиз системы БАЗИС 2023 года, в котором, как и во всех предыдущих релизах, появились новые возможности по работе с документами.
Комплексный отчет
Во всех модулях системы, генерирующих значимую для реализации проектов информацию, можно создавать документы на ее основе. Например, в модуле БАЗИСМебельщик это может быть итоговый отчет о составе изделий, а в модуле БАЗИСРаскрой — спецификации на плитные материалы, статистика по раскрою и карты раскроя. Это объясняется тем, что в модулях документы формируются на основе тех наборов данных, с которыми работает соответствующий модуль. Межмодульного обмена данными до появления нового релиза не существовало. Сегодня же можно объединять в одном отчете наборы данных разных модулей. Как это делается?
Рис. 1. Модель изделия (разработана конструктором мебели Екатериной Румянцевой
(Telegram: @vash_konstruktor))
Рис. 2. Фрагмент отчета в модуле БАЗИС-Мебельщик
Рис. 3. Шаблон и данные для формирования отчета в модуле БАЗИС-Мебельщик
Возьмем модель некоторого мебельного изделия (рис. 1) и сформируем для него локальный отчет в любом из модулей системы, например в модуле БАЗИСМебельщик. Напомним, что все отчеты формируются на основе шаблонов, которые есть в комплекте поставки системы. Кроме того, на их основе или вообще «с нуля» можно быстро создать собственный уникальный шаблон. Возможный вариант отчета показан на рис 2. Он включает структурированную выборку из множества данных, которые содержатся в модели изделия на этапе ее проектирования (рис. 3). В нем нет данных, к примеру, о стоимости отдельных материалов и изделия в целом или о количестве сопутствующих материалов. Этот массив данных формируется и доступен в модуле БАЗИССмета. Соответствующий отчет приведен на рис. 4. Точно так же в модуле БАЗИСМебельщик недоступна информация о картах раскроя листовых материалов, поскольку данный информационный массив создается в модуле БАЗИСРаскрой. Здесь формируются свои отчеты, в которых отражается информация о порядке распиловки полноформатных плит материалов и деталях, передаваемых на последующие технологические участки. Фрагмент отчета модуля БАЗИСРаскрой показан на рис. 5, а соответствующий шаблон — на рис. 6.
Рис. 4. Отчет в модуле БАЗИС-Смета
Рис. 5. Фрагмент отчета в модуле БАЗИС-Раскрой
Рис. 6. Шаблон и данные для формирования отчета в модуле БАЗИС-Раскрой
Для межмодульной интеграции и формирования комплексных отчетов реализована следующая схема. Отчет, созданный в любом из модулей, экспортируется в файл формата xml, которому с целью удобства поиска присваивается расширение *.xmlfr. Для быстрой идентификации нужного отчета можно создать шаблон именования файлов, например имя формируется из номера заказа и номера изделия в заказе. В этом случае имя файла будет автоматически выдаваться в качестве подсказки (рис. 7). Далее в тот же самый файл записываем отчеты, созданные в модулях БАЗИССмета и БазисРаскрой. В результате формируется комплексный информационный массив, в котором отображаются все наборы данных и наименования модулей, где они формируются (рис. 8). Его можно импортировать для создания отчетов, работая в любом модуле. Естественно, для этого необходимо предварительно сформировать шаблон, который будет использовать всю доступную информацию. Пример шаблона комплексного отчета показан на рис. 9.
Рис. 7. Пример шаблона имени файла
Рис. 8. Наборы данных для комплексного отчета
Рис. 9. Шаблон комплексного отчета
Обратим внимание на следующий момент. Любое изменение данных в какомлибо модуле, например «ручное» добавление элементов в смету, после экспорта в соответствующий файл автоматически отразится во всех вновь формируемых отчетах, независимо от того, в каком из модулей это происходит.
Транслитерация: зачем?
В наборе функций генератора отчетов FastReport есть функция транслитерации, преобразующая символы национального алфавита в символы латиницы. На первый взгляд, особой практической ценности она не имеет. Однако это не так. Рассмотрим пример. Предположим, что в отчет необходимо вывести номер позиции детали, ее наименование, количество в изделии, габариты и штриховой код, содержащий наименование панели. Выберем систему кодирования Code128B. При предварительном просмотре отчета видно, что код выводится, но под ним нет наименования детали (рис. 10), то есть нужная информация не кодируется. Проблема в том, что наименования панелей в модели записаны на русском языке, а выбранная система кодирования не поддерживает кириллицу. Именно поэтому штрихкод и не показывает нужную информацию в виде линий.
Рис. 10. Некорректное отображение штрихового кода
Рис. 11. Корректное отображение штрихового кода
Избежать подобных ситуаций поможет транслитерация. Создадим обработчик события OnAfterData объекта BarCode1 (выбранного штрихового кода) и запишем в него обращение к функции транслитерации:
procedure BarCode1OnAfterData(Sender: TfrxComponent);
begin
BarCode1.Text := Transliteration(<Панели."Наименование">);
end;
После этого штриховой код корректно отображает требуемые данные (рис. 11), в чем легко убедиться с помощью сканера.
Теперь попробуем вывести в отчете QRкод, причем для наглядности поставим два идентичных кода. Оба они будут отображать наименование панелей, только в левом столбце без транслитерации, а в правом — с транслитерацией. При печати отчета всё отображается корректно: в левом столбце QRкод с наименованием панелей на русском языке, в правом — на латинице (рис. 12). Однако при чтении сканером снова возникает проблема: наименования на русском языке при любой раскладке клавиатуры выводятся некорректно, а наименования на латинице — корректно только при выборе латинской раскладки. Сканеры имитируют нажатие клавиш в соответствии с текущей раскладкой клавиатуры и по умолчанию распознать ее не могут. Для корректной работы их надо правильно запрограммировать, но это уже совсем другая тема.
Рис. 12. QR-код в отчете
Об эскизах, чертежах и красоте
Среди множества «мебельных» документов выделяется особая группа, для которой важным элементом оформления является «красота», точнее, наглядность и «понятность» для потребителя. Примерами могут служить прайслисты, схемы сборки изделий, иллюстрации, показывающие, где и какая фурнитура устанавливается, таблицы, отражающие связь названий элементов изделий с их внешним видом и т.д. Каждый производитель, заинтересованный в лояльности клиентов, стремится предоставить им исчерпывающий объем доступной для понимания информации.
Одним из вариантов использования отчета является построение именно такой «красивой» документации. Для этого в них включаются различные графические изображения, которые либо упрощают идентификацию «хитрых» деталей, либо повышают эстетические качества документа. В генераторе отчетов присутствуют различные способы добавления изображений. Наиболее распространенными можно считать следующие из них:
- разовая вставка изображений посредством объекта «Рисунок». Она подходит для уникальных случаев, как правило, никак не связанных с наборами данных, например для логотипа фирмы (рис. 13). У объекта «Рисунок» есть свойство Picture, которое можно настроить, указав непосредственный путь к нужному изображению;
- использование изображений, динамически генерируемых в процессе создания модели. К таким видам изображений относятся эскизы и контуры деталей. Они не занимают место на жестком диске, но при этом очень требовательны к оперативной памяти. При создании многостраничного отчета может генерироваться слишком большое количество изображений, что чревато переполнением оперативной памяти. Примерно оценить общий порядок размера изображения в килобайтах можно по формуле: . Соответственно, при формировании отчета на большой заказ и использовании в качестве крепежа, например, евровинтов для каждого из них может генерироваться отдельный эскиз. Поскольку в реальном изделии их может быть сотни, уже на этом этапе может появиться окно с сообщением о переполнении оперативной памяти — Out of memory.
Рис. 13. Объект «Рисунок»
Особо отметим, что в случае фурнитуры интерес представляет не условное ее изображение из модуля БАЗИСМебельщик, а полноценная растровая картинка. Для назначения подобного соответствия можно использовать специальную команду Условные обозначения фурнитуры с вкладки Параметры (рис. 14).
Рис. 14. Условные обозначения фурнитуры
К дополнительным плюсам динамически генерируемых изображений следует отнести их хранение совместно с наборами данных. Это дает возможность экспортировать изображения вместе с обычными данными из файлов *.xmlfr и использовать на других компьютерах, где могут отсутствовать текстуры, назначенные на модель;
- привязка статических изображений к данным из наборов. К примеру, для формирования некоторого документа необходимо к сборочным единицам прикрепить изображения их рендеров или изображения схем сборки. На данный момент это можно сделать за четыре шага:
- Любым способом получить растровое изображение нужной схемы, например, с помощью команды Экспорт -> Изображение.
- В основной модели назначить текстовое пользовательское свойство (назовем его «Изображение»), содержащее относительный или полный путь к файлу с изображением, созданному на первом шаге.
- Добавить в набор данных созданное пользовательское свойство.
- В свойство FileLink компонента Picture добавить ссылку на путь к изображению, которое в случае указания полного пути в пользовательском свойстве может иметь вид: C:\Users\Admin\Documents\Bazis\Шаблоны отчетов\Мебельщик\Изображения\[Сборочные единицы.”Изображение”].jpg.
После выполнения этих шагов в процессе генерации отчета в компонент будет выводиться необходимая картинка (рис. 15 и 16).
Рис. 15. Структура шаблона
Рис. 16. Схема сборки
При выполнении привязки статических изображений к наборам данных достаточно проблемным является генерация пользовательского свойства с указанием пути к графическим файлам. Она решается с помощью скриптов. В качестве примера приведем с краткими комментариями скрипт для назначения пользовательского свойства, содержащего путь к изображениям чертежей в формате wmf и изображениям крепежной фурнитуры в формате jpg для каждой панели (файл настроек находится по адресу
C:\Bazis\Settings\Settings.xml):
const folderwmf = "wmf\\";
const extwmf = ".wmf";
const extjpg = ".jpg";
let SettingsPath = "C:\\Bazis\\Settings\\Settings.xml";
let Filesystem = system. filefxists(SettingsPath);
if (FileSystem == true) {
// путь к файлам чертежей
let SettingsFile = system.readTextFile(SettingsPath);
let PozOne = SettingsFile. indexOF('', 0);
let PozTwo = SettingsFile. indexOF('', 0);
let PathLDW = SettingsFile.slice(PozOne + 9, PozTwo);
// Наименование сборочного чертежа
txt1 = PathLDW + folderwmf;
txt2 = Model.Designation;
txt3 = ‘ – СБ’;
Model.UserProperty[‘Чертеж’] = txt1 + txt2 + txt3 + extwmf;
// Перебор панелей и присвоение пользовательского свойства
Model. forEachPanels (function(obj) {
txt4 = obj.Designation;
txt5 = obj.Name;
obj.UserProperty[‘Чертеж’] = txt1 + txt4 + ' = ' + txt5 + extwmf;
})
// Перебор крепежа и присвоение пользовательского свойства
Model.forEach(function(obj) {
if (obj instanceof TFastener) {
poz = obj.Name. toString().search('\r');
art = obj.Name. toString().substring(poz + 1);
obj.UserProperty[‘Чертеж’] = txt1 + art + extjpg;
};
});
} else {
alert(“Укажите полный путь к файлу Setting.xml”);
Action.OnFinish;
};
Приведенный скрипт может быть доработан для решения целого круга подобных задач.
Об «ошибках» в программе и не только
Часто при работе со скриптами возникает ситуация, когда видимая невооруженным глазом ошибка в отчете дает повод усомниться в качестве программы в целом (разумеется, каждому хочется верить, что лично он не допустил ошибки).
Для определения источника ошибки: что это — системная ошибка или ошибка в логике построения отчета — можно предложить следующий очень простой алгоритм действий.
Вначале с помощью мастера построения отчетов составляем отчет, в котором в виде строк или столбцов будут выведены все атомарные данные (без группировок). Это осуществляется всего в несколько кликов мышью: Файл -> Новый -> Мастер стандартного отчета. По сути, в этот момент перед пользователем появляется структура базы данных в табличной форме. Именно на этом фактически заканчивается работа основного приложения системы БАЗИС. Если таблица построена верно, то к системе претензий нет.
Все, что следует далее (применение и настройка группировок, фильтры данных и т.п.), — это уже ответственность пользователя, и все возникающие ошибки надо искать именно в скрипте. Если, например, в подвале группы вдруг выводится странное значение, допустим, указывается несоответствующая строка данных — значит, в скрипте не совсем корректно настроена группировка данных.
Заключение
Значимость качественной документации для мебельного производства трудно переоценить. Она положительно влияет на все стороны его деятельности: от повышения качества продукции до сохранения лояльности клиентов. Освоив инструментарий формирования отчетов в системе БАЗИС, мебельщики получают уникальные возможности реализации любых своих пожеланий по оформлению документов.
