В статье речь пойдет о специфических для проектных предприятий процедурах документооборота, а точнее, об интеграции технического документооборота (у нас – на основе TDMS) и внешней переписки. На предприятиях других типов тоже могут существовать аналогичные потребности, поэтому, если у вас есть вопросы в отношении интеграции или автоматизации с помощью easla.com, статью также имеет смысл прочитать – тут описываются интересные технические детали.

Я собирался выступить на ежегодной конференции в ПАО «Гипротюменнефтегаз», однако из-за сильной текущей загрузки просто не успел подготовиться. Чем не оправдал ожиданий моих знакомых и коллег (ожидалась небольшая публичная дискуссия). Описываемое далее решение не содержит ничего революционного с организационной точки зрения, но, смею надеяться, некоторого внимания оно все же заслуживает.


Несколько начальных пунктов в статье посвящены «Зачем». Далее — «Каким образом» (VBScript, MS SQL + XML). Если больше интересно, каким образом — листайте до 5-го пункта.

1. РЕВИЗИИ. ЧТО ЭТО ТАКОЕ.


Ревизии – это версии документов. Само слово пришло из иностранных стандартов, где ГОСТы 21-й серии распространения не имеют. Там, «у них», на документах в основных надписях есть поле «Rev.», которое, собственно, и расшифровывается как «Revision».
Примечание
Если честно, сами по себе ревизии несколько ущербны. Например, чтобы проектировщику заменить пару листов в документе, нужно выпускать новую ревизию на весь документ. И если в документе 300 страниц… В ГОСТах 21.*, в отличие от ревизий, подробно рассматриваются все возможные ситуации с листами.

С другой стороны, жизнь ведет нас к тому, что передача документов будет выполняться в электронном виде (и, отмечу, это уже так, как минимум, в 60% наших заказов, даже ГлавГосЭкспертиза принимает документацию в электронном виде). А в электронном виде полистно отслеживать изменения, например, в документах Word, мягко говоря, неудобно. В отношении же файлов, например, с 3D-моделями – вообще непонятно, о каких листах может идти речь.

Компании с иностранным участием начали активно внедрять ревизии примерно 3-4 года назад.
Т.е. ревизиям — быть. Больше того, один из наших Заказчиков после получения первых документов с ревизиями (хотя он не предъявлял таких требований) при получении документов без ревизий начал возмущаться. Дальше станет понятно, почему.

В процессе разработки проектной документации проектировщик не просто чертит чертежи. Проектировщик очень активно общается с экспертами Заказчика и с конструкторами заводов-изготовителей. Как в неформальном, так и в формальном виде. Т.е. передает документацию на согласование с сопроводительным письмом, отвечает на замечания, вносит поправки, снова посылает документацию с сопроводительным письмом и т.д.. До победного конца. Пока не согласуют. Каждый разрабатываемый документ.

Правильный способ работы заключается в том, чтобы перед отправкой сдать документ в архив. При сдаче в архив присваивается инвентарный номер и ставится номер изменения на чертеже. Но сдача в архив – процедура длительная, в ней задействовано, как минимум, два других подразделения. Поэтому проектировщики избегают сдачи документации в архив каждый раз при передаче на согласование. И если бы только проектировщики – избегают ГИПы, Главный Инженер, и даже сам Заказчик не заинтересован в том, чтобы задерживать процедуру согласования документации.
Примечание
Зачем же вообще нужна сдача в архив? Дело в том, что есть небольшая, но важная разница между передачей «готовой документации» и передачей «для согласования». Когда передается готовая документация – оформляется накладная. Это накладывает юридические обязательства на Заказчика. И поэтому там точно должно быть все сделано в соответствии с ГОСТ. А вот в части согласования требования, как правило, не такие жесткие – Заказчик прекрасно понимает, что на сдачу в архив уходит время, которое ему так же важно, как и проектному институту.


Т.е. внедрен учет ревизий или нет – обмен «без архива» идет в любом случае. Ставить номер изменения без сдачи в архив тоже нельзя. А в результате возникает путаница. Документация попадает сначала к Заказчику (можно идентифицировать по исходящему номеру письма от Проектировщика), потом – к эксперту (а вот тут уже исходящий номер от Заказчика! Номер письма Проектировщика пропал!). Специалисты Заказчика могут передать (и передают!) разным экспертам (а экспертов у Заказчика немало) документацию разных версий, и понять это невозможно до тех пор, пока не начинается разбор полетов.

Для того, чтобы путаницы не происходило – внедряется учет ревизий. На каждом переданном в электронном или бумажном виде документе написан номер ревизии, дата ее выпуска и комментарий. Т.о., когда проектировщик с экспертом связываются по телефону, по номеру ревизии становится понятно, одинаковые документы они держат в руках, или нет.

2. КАК ОБЫЧНО РАБОТАЮТ С РЕВИЗИЯМИ.


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

Т.е. для того, чтобы передать документ Заказчику, инженер-проектировщик присваивает номер ревизии, распечатывает документ, идет к начальнику группы, подписывает, потом к главному специалисту, тоже подписывает, потом – к начальнику отдела, потом – к нормоконтролеру, потом, возможно, к согласующим отделам, наконец, к ГИПу, и – может его отсканировать (вручную !!!). После сканирования – нужно составить сопроводительное письмо, подписать его, собрать сканы и передать это все например, помощнику ГИПа или специально выделенному лицу, ответственному за документооборот. Это лицо все проверит, даст Бог – не найдет ошибок (представляете, каково заново все это проходить?). Потом, наконец, письмо с приложениями отправляют (ах да, письмо – тоже отсканировать, т.к. там подписи!).

Заказчики, нужно сказать, попадаются разные. Одним нужно непременно через почту. Даже если там пара гигабайт. Другим – непременно через ссылку на ресурс Проектировщика. Третьим нужно выложить все в определенном порядке на ресурс Заказчика. В общем, много вариантов. Это тоже, как правило, делается вручную.

3. А ЧТО НУЖНО ОТ РЕВИЗИЙ, КРОМЕ ИХ УЧЕТА?


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

И еще нужно учитывать, что согласование – процесс многоэтапный, есть внутренняя экспертиза, есть ГлавГосЭкспертиза, есть привязка к конструкторской документации и т.д…

Такой реестр в «запущенном» случае составить реально, но уйдет недели две, и ошибки будут в 20% случаев. В случае «ручной автоматизации» вроде бы легче – т.к. есть специальный человек, который денно и нощно отслеживает (по крайней мере, должен) передачу документации и ее согласование. Какая-никакая, а все же централизация. Что дает результат примерно «через день» и… 10-15% ошибок. Почему? А потому, что согласование – процесс многоэтапный, а «ответственный» — нередко далек от проектирования, нюансов — не понимает. Корректнее всего процесс согласования отслеживает сам проектировщик.

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

4. КАК АВТОМАТИЗИРОВАЛИ УЧЕТ РЕВИЗИЙ МЫ.


При внедрении учета ревизий мы исходили из 2-х предпосылок. Во-первых, нужно сократить объем работы проектировщику (все эти распечатывания и сканирования). Во-вторых, нужно дать инструмент для отслеживания процесса согласования. Кому-то. Лучше всего – проектировщику. Ну нет у нас специального лица для отслеживания согласования. Поэтому – проектировщику, и инструмент этот должен быть удобным!

Начнем с 1-го пункта. На момент внедрения учета ревизий у нас уже был налаженный процесс сдачи в архив, в котором создавались PDF с подписями. Проектировщики им вовсю пользовались для того, чтобы обойти печать и сканирование с подписями (правда, при этом здорово напрягался архив). Поэтому были добавлены несколько полей в наши объекты и реализована процедура фиксирования ревизий, в которую было включено автоматическое создание PDF с подписями.

Дальше сначала была реализована просто выгрузка файлов документов (исходные и PDF). А после этого была реализована функция, которая разрешила сразу же половину неразберихи в части отслеживания процессов – в TDMS проектировщик на зафиксированной ревизии нажимает кнопку «Добавить к письму», выбирает письмо, и ревизия сама попадает в письмо в easla.com, а также устанавливается ссылка на объект ревизии в TDMS. Вроде бы мелочь, но зато сколько проблем это решает! Проектировщик экономит время на извлечении из TDMS, сборе материалов, их архивировании и передаче в службу документооборота, а ГИП может за 5 минут получить достоверный список того, что отправлено!

И еще никто не тратит много времени на архивирование материалов и правильную их передачу Заказчику.
Примечание
Карлик, на самом деле, базируется на плечах гигантов. Пока не налажена работа с ревизиями (что, в свою очередь, подразумевает стабильную работу «живого» архива), автоматическая установка подписей в PDF (чтобы избежать сканирования) и т.д. – внедрять такие «мелочи» очень проблематично.



По пункту 2 была реализована следующая функция – в TDMS проектировщик выбирает ревизию документа, нажимает кнопку «Письмо согласования» и выбирает из перечня входящее письмо, в котором есть информация о согласовании документа. Также выбирается, согласован документ, или есть замечания. Все.
Примечание
Можно было автоматизировать процесс согласования более полноценно – проектировщик перечислял бы все замечания, вносил бы ответы, формировал бы письмо. Но было решено ограничиться этими возможностями потому, что большого интереса к составлению подробного отчета со всеми замечаниями нет.

В таком виде реализован процесс согласования конструкторской документации. Там интерес есть, т.к. множество отделов подготавливают один общий документ, что при «ручной автоматизации» невероятно мучительно. В произведении Чуковского (а точнее, Хью Лофтинга) упоминается Тяни-толкай, который, конечно, не являлся аллегорией на наше общество, но символически в смысле способа делать дела очень соответствует. И не только «у нас».

Что имеем в результате? В результате проектировщик:
  • получает способ хранения в системе всех вариантов, которые он разрабатывал для Заказчика и для смежных отделов;
  • может указать прямо в системе, каким письмом какой вариант он отправил;
  • занимается отправкой не день-два, как раньше, а только час (нужна проверка вышестоящими специалистами);
  • сам видит, в каком состоянии находится его работа (документов много, всего не запомнишь).
  • не отвлекается еженедельно по нескольку раз на подготовку отчетов по просьбе Заказчика, ГИП сам подготавливает реестр за 5 минут!
  • и т.д.

Пример реестра:



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


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


5. ТЕХНИЧЕСКИЕ АСПЕКТЫ. ИНТЕГРАЦИЯ TDMS С EASLA.COM.


Интеграция реализована в 3-х точках:
  1. Функция «Добавить к письму»
  2. Функция «Письмо согласования»
  3. Функция «Подготовка реестра»

Особенность задачи заключается в том, что при удалении из письма в easla.com какого-нибудь приложения это должно отразиться на реестре. Кроме того, если проектировщик подготавливает письмо, помещает в него документы, а потом в процессе подготовки понимает, что добавил туда что-то не то, то ему нужно удалить из письма это «что-то не то», и на этом — все! Ссылки на объекты в других системах должны «погибнуть» именно для данного конкретного файла, не более!

В каждом файле приложения имеются поля для хранения информации. Более того, в каждом файле приложения easla.com позволяет хранить не просто поле описания длиной, положим, 256 байт (как это чаще всего сделано в других системах), но целый список «Состав файла», в каждом элементе которого может храниться «Имя», «Номер ревизии», «Наименование ревизии» и «Параметры версии»:


Мы, фактически, являлись заказчиками этой особенности easla.com, и она нам очень пригодилась. Разные Заказчики просят по-разному формировать архивы, в одном архиве может находиться по несколько документов.

5.1. ФУНКЦИЯ «ДОБАВИТЬ К ПИСЬМУ» И ФУНКЦИЯ «ПИСЬМО СОГЛАСОВАНИЯ»

Разработка бизнес-логики в TDMS производится на VBS. За что отдельное спасибо разработчикам TDMS. Да, VBS уже морально устарел, и лучше бы это был .Net, но никакого специального языка программирования, по крайней мере, они изобретать не стали. Чем избавили нас от ограничений и глюков машины собственной разработки. Не говоря о том, что на Бейсике учат писать еще в школе.

Кроме того, в системе easla.com есть COM-интерфейс для работы с системой. Он встроен в агент, который устанавливается на каждое рабочее место. В этом интерфейсе реализовано несколько полезных инструментов. В данном случае мы воспользовались инструментом для выбора элементов списка, который выглядит вот так:


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

Далее несколько кусков кода, которые показывают, как реализована интеграция. Некоторые места кода вызывают удивление не очень профессиональным уровнем, можно и покомпактнее, и покрасивее написать, но что поделать – не боги горшки обжигают. Главное – работает.

Получение исходящего письма из easla.com
Function GetOutingLetter()
  Set GetOutingLetter = Nothing
  Dim ea
  On Error Resume Next
  Err = 0

  Set ea = CreateObject("Easla.Agent")
  If Err <> 0 Then
    MsgBox "EaslaAgent не установлен. Обратитесь к администратору", VbOKOnly & VbCritical, "Ошибка"
    Set ea = Nothing
    Exit Function
  End If
  
‘получение определения процесса «управление перепиской»
  Set process = ea.getProcessCOM("crs_management")
  If process Is Nothing Then
    MsgBox "EaslaAgent не смог авторизоваться. Обратитесь к администратору", VbOKOnly & VbCritical, "Ошибка"
    Set ea = Nothing
    Exit Function
  End If
  
‘получение определения объекта «исходящее»
  Set object_def = ea.getObjectdefCOM(process, "crs_management_outgoing", 0)
  
  Dim arr1(2)
  arr1(0) = "crs_management_outgoing_regnum"
  arr1(1) = "crs_management_outgoing_document"
  arr1(2) = "crs_management_outgoing_attachments"
  
‘формирование условий поиска, в данном случае – по статусу
  Set d = ea.CreateKeyValuesPairSoapItemCOM("status", Array("crs_management_outgoing_created"))
‘получение результатов выборки
  Set result = ea.getObjectrefsCOM(object_def, arr1, Array(d))

‘задание списка выводимых в диалоге параметров
  Set kvps1 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps1.key = "Идентификатор"
  kvps1.value = "id"
  
  Set kvps2 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps2.key = "Описание"
  kvps2.value = "description"
  
  Set kvps3 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps3.key = "Дата создания"
  kvps3.value = "createtime"
  
  Set kvps4 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps4.key = "Статус"
  kvps4.value = "status.name"
  
‘вывод диалога
  Err = 0
  Set ooo = ea.ShowSelectObjectDialogCOM(result, Array(kvps1, kvps2, kvps3, kvps4))
  If Err = 0 Then
    Set GetOutingLetter = ooo
  End If
  Set ea = Nothing
End Function

Загрузка файла в easla.com и установка параметров

‘o – объект письма
‘commonname – название файла приложения
‘revision – идентификатор ревизии для основного описания
‘filename – название файла для основного описания
‘revdata – описание ревизии для основного описания
 ‘guids – список объектов в TDMS типа TDMSSheet для списка «Состав файла»
Function AddFileToOutingLetter(o, commonname, revision, filename, guids, revdata)
  Set AddFileTotOutingLetter = Nothing
  Dim ea
  On Error Resume Next
  Err = 0
  Set ea = CreateObject("Easla.Agent")
  If Err <> 0 Then
    MsgBox "EaslaAgent не установлен. Обратитесь к администратору", VbOKOnly & VbCritical, "Ошибка"
    Set ea = Nothing
    Exit Function
  End If
  
  Set process = ea.getProcessCOM("crs_management")
  If process Is Nothing Then
    MsgBox "EaslaAgent не смог авторизоваться. Обратитесь к администратору", VbOKOnly & VbCritical, "Ошибка"
    Set ea = Nothing
    Exit Function
  End If

‘сначала – проверка, есть ли такие файлы в письме (прикрепить-то easla.com позволяет, но нам этого не надо)
‘извлекаем атрибуты объекта, файлы приложений – это тоже атрибуты
  set attrs = ea.GetAttrsFromObjectCOM(o)
  colKeys = attrs.Keys
  For Each strKey  In colKeys
    If attrs.Item(strKey).code = "crs_management_outgoing_attachments" Then
      For Each f In attrs.Item(strKey).values
        If f.nowname = commonname And f.isdeleted = "0" Then
          MsgBox "Ошибка прикрепления: удалите из письма и прикрепите единовременно все файлы этого комплекта " & commonname, VbOKOnly & VbCritical, "Ошибка"
          Exit Function
        End If
      Next
    End If
  Next

‘загрузка в easla.com
  Set orss = CreateObject("EaslaAgent.com.easla.ObjectrefSimpleSoap")
  orss.id = o.id
  Err = 0
‘собственно загрузка
  set uploadfile = ea.uploadFileCOM(orss, code, filename)
  If Err <> 0 or uploadfile is Nothing  Then
      MsgBox "Во время прикрипления документа к письму возникла ошибка. Обратитесь к администратору", VbOKOnly & VbCritical, "Ошибка"
      Set ea = Nothing
      Exit Function
  End If

  Set kvps1 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps1.key = "srcname"
  kvps1.value = commonname
  
  Set kvps2 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps2.key = "revcode"
  kvps2.value = revision

  Set kvps4 = CreateObject("EaslaAgent.com.easla.KeyValuePairSoap")
  kvps4.key = "revdata"
  kvps4.value = revdata

‘обновление основной информации о файле
  set ooo = ea.updateFileCOM(uploadfile, Array(kvps1, kvps2,kvps4))  
  If Err = 0 Then

    Dim arrFCSS()
    ReDim Preserve arrFCSS(0)

‘обновление списка «Состав файла»
    For Each ob in guids.Objects
      n = UBound(arrFCSS)
      ReDim Preserve arrFCSS(n + 1)
      arrFCSS(n) = ob.description ‘описание объекта
      
      n = UBound(arrFCSS)
      ReDim Preserve arrFCSS(n + 1)
      arrFCSS(n) = ob.guid ‘связь с объектом TDMS
      
      n = UBound(arrFCSS)
      ReDim Preserve arrFCSS(n + 1)
      arrFCSS(n) = ob.Attributes("REV_LETTER").Classifier.Code & ob.Attributes("REV_NUM") ‘ревизия
      
      n = UBound(arrFCSS)
      ReDim Preserve arrFCSS(n + 1)
      arrFCSS(n) = ob.Attributes("REV_DESCRIPTION") ‘описание ревизии
    Next
    ‘обновление описания приложения
    Set AddFileTotOutingLetter = ea.updateFileConsistCOM2(ooo, arrFCSS)

  End If

  Set ea = Nothing
End Function


Функции «Добавить к письму» и «Письмо согласования» в части получения номеров писем похожи, как близнецы, поэтому тратить время читателя на получение номера исходящего письма из easla.com я не буду.

5.2. ФУНКЦИЯ «ПОДГОТОВКА РЕЕСТРА»

Данные в системах о связи писем и ревизий есть, теперь стоит озаботиться извлечением этих данных для подготовки отчета. Отчет можно построить на основе выборок TDMS с использованием события «QueryAfterExecute» для связи с информацией, получаемой из easla.com, но по соображениям скорости обработки мы решили сделать это через SQL, благо, что easla.com обладает возможностью получения данных в запросах SQL. Для этого к серверу MS SQL устанавливается расширение, позволяющее извлекать любую информацию из БД easla.com.

Весь код запросов приводить не буду, остановлюсь на ключевых моментах.

Получение перечня писем по перечню идентификаторов документов

CREATE PROCEDURE [dbo].[PR_TDMSReport_GetDocList_SENT]
(
	@guid uniqueidentifier –элемент дерева, с которого начинать поиск документов
)
AS
BEGIN

	declare @id bigint
	select @id = f_objid from tngptdms.dbo.tobject (nolock)  where f_guid = @guid;

	declare @temp_revs table
	([guid_rev] uniqueidentifier	--GUID ревизии
	,descr varchar(max)		--описание ревизии
	,letter varchar(10) 		--1-е поле ид-ра ревизии
	,id varchar(10) 		--2-е поле ид-ра ревизии
	,t datetime			--время фиксирования ревизии
	,objid_rev bigint		--системный ид-р ревизии
	);
	
--заполнение таблицы документами, находящимися ниже по дереву 
	insert into @temp_revs
	EXEC [TNGP].[dbo].[PR_TDMSRevision_GetListByObject] @guid = @guid

--формирование перечня GUID-ов для XML-запроса в ESLA
	declare @subquery varchar (MAX)
	set @subquery = cast ((select '{'+cast([guid_rev] as varchar(50))+'}'
				from @temp_revs
			for xml path('item'), elements, type) as varchar(MAX))

--здесь заполняется секция условий для XML-запроса
	declare @query XML
	set @query = 
		'<conditions>
			<item>
				<key>crs_management_outgoing_attachments</key>
				<values>'
				+ @subquery +
				'</values>
			</item>
		</conditions>'

--временная таблица для хранения результатов, получаемых из easla.com 
	declare @temquerytbl table
	(
		regnum varchar(32),
		regdate varchar(32),
		revguids xml,
		[SentStatus] varchar(40)
	)

--параметры, необходимые для запроса в easla.com
	DECLARE @organization_id AS INT;
	DECLARE @process_id AS INT;
	DECLARE @objectdef_id AS INT;
	DECLARE @user_id AS INT;
	declare @ret int
	declare @logined int
	set @logined = 0

	if(@subquery is not NULL)
	begin
-- пользователь,пароль – можно завести пользователя с правами просмотра всей информации в БД ESLA, чтобы не указывать системного администратора
-- EASLAlogin – функция из расширения для easla.com
		select @logined = [master].[dbo].[EASLAlogin](пользователь,пароль)
	
		IF (@logined = 1)
		BEGIN
--выборка параметров для запроса в easla.com
			SELECT @organization_id = organization.id, @process_id = process.id, @objectdef_id = objectdef.id
				FROM [master].[dbo].[EASLAgetOrganization] ('TNGP') AS organization
				LEFT JOIN [master].[dbo].[EASLAgetAllProcesses] () AS process ON process.oid = organization.id
				LEFT JOIN [master].[dbo].[EASLAgetAllObjectdefs] () AS objectdef ON objectdef.pid = process.id
				WHERE process.code = 'crs_management' AND objectdef.code = 'crs_management_outgoing';

-- ид-р пользователя в easla.com
			SELECT @user_id = id FROM [master].[dbo].[EASLAgetOrganizationUser] (@organization_id, пользователь)

--запрос в easla.com необходимой информации
			insert into @temquerytbl
				SELECT	attributerefs.value('(ArrayOfAttributerefSimpleSoap[1]/AttributerefSimpleSoap[1]/values/item/node())[1]','varchar(30)') as letternum
						,attributerefs.value('(ArrayOfAttributerefSimpleSoap[1]/AttributerefSimpleSoap[2]/values/item/node())[1]','varchar(30)') as regdate
						,cast(attributerefs.query('(ArrayOfAttributerefSimpleSoap[1]/AttributerefSimpleSoap[3]/values/item/consist/item/revdata)')as varchar(max)) as revguid
						,cast([status].query('(StatusSimpleSoap[1]/name[1]/node())')as varchar(max)) as sentstatus

						
				from master.[dbo].[EASLAgetobjectrefs](
					@process_id, 
					@objectdef_id
--перечень запрашиваемых полей
					,CAST('
					<attributerefs>
						<item>crs_management_outgoing_regnum</item>
						<item>crs_management_outgoing_sentdate</item>
						<item>crs_management_outgoing_attachments</item>
					</attributerefs>
						' AS XML)
					,@query,
					@user_id
				);
					
		end

		declare @temquerytbl1 table
		(
			revguid varchar(50),
			regnum varchar(30),
			regdate varchar(30),
			sentstatus varchar(40)
		)

		insert into @temquerytbl1	
		select cast(t2.loc.query('(./node())') as varchar(50)), regnum,replace(regdate,'/','.'),sentstatus
		from @temquerytbl as T
		CROSS APPLY revguids.nodes('/revdata') as T2(Loc)

	END
	
	IF (@logined = 1)
	BEGIN
		select @logined = 1 - [master].[dbo].[EASLAlogout]()
	end
…


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

Есть набор процедур, через операцию JOIN объединяющих все эти данные с данными из TDMS (район проектирования, площадка строительства, позиция по генплану и т.д., около 50 параметров). Процедур несколько, т.к. есть довольно специфические требования некоторых Заказчиков. Они вызываются из макросов в документах MS Excel. Шаблонов документов существует около 10 штук – отчеты различаются, каждому из Заказчиков – свой вариант.

ЗАКЛЮЧЕНИЕ


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

Серьезную роль сыграло и наличие хорошего рабочего контакта с разработчиками easla.com. Оправданные запросы на реализацию возможностей (такие, как «Состав файла»), всегда обсуждались и вполне своевременно реализовывались.