5 - 2009

Практическое использование некоторых возможностей Lotsia PDM Plus v4.30

Александр Зайцев (Ведущий инженер по системе документооборота, «Русская Промышленная Компания»)

Наверняка вам в общих чертах известно, что представляют собой базы данных и системы управления ими. Это огромные хранилища информации, иногда совершенно разной по формату и смыслу, приведенной в той или иной степени к общему виду и представленной в удобной для работы форме.
«Русская Промышленная Компания» занимается поставкой ПО и оборудования, сопровождением, поддержкой клиентов и, конечно же, имеет в своем распоряжении большую клиентскую базу, за безграничность объемов и сохранность которой отвечает MS SQL2005, а за наполнение, управление, координацию и безопасность — Lotsia PDM Plus v4.30. Решая множество задач с помощью данного тандема, мы хотим рассказать о реализации одной из них.

Постановка задачи

Нашей задачей было на основании информации из клиентской базы данных подготовить заказ на приобретение ПО и выпустить все необходимые документы для участников сторон. Задача довольно простая и реализованная много раз в виде отдельных приложений той или иной функциональной направленности, но:

  • нам необходимо было решить ее в рамках нашей системы, поскольку все данные по клиентам уже собраны в одном месте;
  • было бы неплохо в нашей же системе работать и с поставщиками, и с номенклатурой товаров, довольно обширной и слабо формализованной.

Задача решаема и вопросов, в принципе, не вызывает, кроме одного: что делать с номенклатурой? Рассмотрим его подробнее. Сам же инструмент — Lotsia PDM Plus v4.30 — отложим в сторону, поскольку ни по функционалу, ни по надежности, ни по удобству работы он нареканий не вызывает.

Итак, номенклатура. Для примера обратимся к одной из программ — AutoCAD 2009 от компании Autodesk. Продукт один, название простое, и, казалось бы, какие могут быть с ним проблемы? Но, оказывается, данное решение может быть представлено не только в одной, но и в нескольких функциональных интерпретациях. В терминах разработчика это выглядит так:

  • Commercial New AutoCAD 2009 SLM;
  • Educational AutoCAD 2009 EDU 20 PK NLM;
  • Subscription for AutoCAD 2009…

А один из поставщиков те же самые решения называет несколько иначе:

  • программное обеспечение AutoCAD 2009 коммерческий, русский, локальный;
  • программное обеспечение AutoCAD 2009 учебный, русский, сетевой на 20 мест + два преподавательских места;
  • программное обеспечение AutoCAD Subscription для AutoCAD 2009…

К тому же поставщиков может быть несколько, а следовательно, всё то же самое может предлагаться в несколько ином свете, например, так:

  • AutoCAD 2009 локальный;
  • AutoCAD 2009 учебный;
  • AutoCAD 2009 подписка…

Все наименования приведены для примера, что, впрочем, не меняет сути дела.

Таким образом, мы имеем:

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

Как же поступить с номенклатурой? Возможно несколько вариантов:

  • полный перечень «правильных» наименований продуктов для каждого поставщика без возможности планирования и анализа;
  • полный перечень «правильных» наименований продуктов для каждого поставщика с дополнительным описанием их характеристик для дальнейшей обработки;
  • сокращенный и формализованный перечень чистых наименований продуктов с дополнительным описанием их свойств (классификатор) и возможностью искусственного формирования максимально достоверного наименования продукта с привязкой к поставщику.

Что выбрать? Это непростой вопрос, затрагивающий множество аспектов — от быстродействия до качества работы — и требующий взвешенного решения. Мы остановились на последнем варианте — формализация и классификатор.

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

Итак, направление задано, инструмент есть.

К делу

База данных. Процесс создания клиентов, поставщиков и продуктов не вызывает трудностей благодаря использованию простого и понятного макроязыка, поддерживаемого системой.

Для клиентов это выглядит следующим образом (рис. 1). В редакторе макроязыка описывается простая последовательность действий по созданию объекта, установке его атрибутов и привязке в дерево проекта.

Рис. 1

Всегда возникает вопрос, нужно ли использовать программирование. Конечно, всё можно сделать и руками, но зачем? Макроязык является неотъемлемой частью системы, и одному администратору, прошедшему обучение, вполне по силам создать ряд необходимых процедур для всей компании в целом. Кроме того, существует ряд настроек для быстрого старта, где всё это уже есть и можно сразу начать работу.

Рис. 2

Создание поставщиков ничем существенным не отличается, за исключением двух новых папок — «Продукция» и «Прайс» (рис. 2). Как видно из рис. 2, наименование продукта не содержит дополнительных характеристик — они будут присвоены на этапе добавления продукта в заказ. Таким образом, здесь только минимум «чистых» наименований с версией, хотя и версию можно вынести в характеристики продукта, тем самым еще сократив количество наименований. Но, как показывает практика, всё хорошо в меру.

Теперь рассмотрим сам классификатор свойств продуктов. Как мы уже говорили, классификатор необходим нам для искусственного создания наименования продукта, максимально похожего на его название у поставщика. Losia PDM Plus v4.30 содержит специальную структуру под классификаторы, последовательно формирующую строку значений по атрибутивной информации. То есть для каждой позиции классификатора — одно значение. К сожалению, нам этого оказалось явно недостаточно, поскольку, помимо названия того или иного свойства продукта, нам нужен был и его код, и второе название, и целый ряд служебных параметров. В связи с этим был создан классификатор на объектах, имеющих достаточное количество необходимых атрибутов (рис. 3).

Рис. 3

В общей сложности классификатор включает все разновидности свойств продуктов с привязкой к каждому поставщику или к их группе. Стоит отметить еще один момент — некоторые свойства продукта имеют достаточно длинные названия, неудобные в выборе, поэтому в классификаторе используются только их короткие аналоги и код позиции. Как мы увидим далее, этих двух условий вполне достаточно для формирования «правильного» наименования продукта (рис. 4).

Рис. 4

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

То, что вы видите на рис. 4, — это возможности системы: тот же макроязык, не более того. Но, конечно, если есть желание, можно воспользоваться API и работать, откуда вам удобно, — для этого реализована поддержка скриптовых языков и прямой работы с базой через SQL, то есть можно работать, ни в чем себя не ограничивая.

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

Вся информация, набранная таким образом по заказу, сохраняется в базе данных и доступна для дальнейшего редактирования. То есть первая часть задачи по подготовке заказа решена. Осталось создать документы. Это можно сделать в том же окне, выбрав необходимый тип документа. Выглядит это следующим образом:

  • Lotsia PDM PLUS v4.30 предлагает нам генератор отчетов — другими словами, инструмент, формирующий SQL-запросы к базе по предварительно заданным условиям и отображающий найденную информацию в требуемом виде. Мы можем использовать его как самостоятельно с ручным вводом критериев поиска, так и автоматически из макросов, передавая критерии в виде параметров. Именно таким образом мы производим отбор необходимых параметров заказа из базы данных (рис. 5).
  • После выполнения отчета запускается скрипт (VBScript), формирующий необходимые документы в требуемом формате. Конечно же, Lotsia PDM Plus v4.30 может генерировать файлы напрямую, без скриптов, но нам было удобнее именно так.

Рис. 5

После формирования документов файлы автоматически сохраняются в электронном архиве системы и открываются оттуда для просмотра и редактирования. Таким образом, задача по подготовке заказа на приобретение ПО и выпуска всех необходимых документов для участников сторон решена.

Цель данной статьи не в рекламе Lotsia PDM Plus v4.30, мы лишь хотели показать, что, используя ее, мы решаем свои повседневные задачи, не испытывая никаких ограничений в функционале со стороны разработчика.

Получить подробные консультации и демо-версии упомянутых в статье программных продуктов можно у специалистов «Русской Промышленной Компании»
(www.cad.ru).

САПР и графика 5`2009