В цехе соединение называют «семнадцатым», на схеме оно обозначено С-017, а лаборатория получает заявку на стык 17А. Через неделю выходит новая версия чертежа, номер меняется, и в реестре появляется ещё одна строка. Теперь непонятно, выполнены два соединения или одно, а к какому из них относится заключение, знает только составитель заявки.
Проблема решается соглашением об идентификации. Команде нужно различать сам физический объект, его обозначение в документе и отдельные события работы с ним. Ниже — модель внутреннего реестра, которую можно начать вести в таблице и затем перенести в программу.
Эта модель организует данные. Она не устанавливает методы контроля, нормы оценки дефектов, обязательную форму документа или достаточность комплекта для приёмки. Такие вопросы решаются по применимым требованиям проекта.
Разделите три сущности: соединение, обозначение и событие
Соединение — объект учёта с постоянным идентификатором. Например, J-000417. Этот ID присваивается один раз, не зависит от фамилии исполнителя, даты контроля и текущего номера чертежа. В пределах согласованного реестра он однозначен и не выдаётся другому соединению после закрытия карточки.
Обозначение — то, как соединение названо в конкретном документе: С-017 на схеме СХ-08 версии 2. Обозначение удобно людям, но без контекста может повторяться. Его хранят вместе с документом, версией и местоположением на листе.
Событие — действие, относящееся к соединению: выполнение работы, направление на контроль, получение результата, исправление сведений, повторный контроль. У события собственный номер, дата и ссылки на документы. Несколько событий не превращают одно соединение в несколько объектов.
Рекомендации W3C по данным отдельно рассматривают устойчивые идентификаторы и историю версий. Здесь этот принцип применяется к внутреннему учёту: постоянная ссылка на объект сохраняется, а меняющиеся сведения получают историю. Это инженерный подход, а не правило оформления сварочной документации.
Договоритесь, где действует уникальность
Определите границы реестра: предприятие, проект или отдельный договор. Если два проекта могут использовать J-000417, при обмене добавьте идентификатор проекта. Внутри единой системы удобнее присваивать ID, уникальный сразу для всей базы, и хранить проект отдельным полем.
Не собирайте постоянный ID из номера чертежа, версии, статуса или цеха. Эти значения могут измениться, и составной «вечный» номер перестанет быть вечным. Человеко-читаемую строку «Корпус А / СХ-08 / С-017» можно показывать рядом, но связи между записями лучше строить по постоянному ID.
Правила выдачи согласуйте до параллельной работы. Если реестр ведут несколько сотрудников, назначьте единый механизм присвоения номера. Временная таблица тоже требует порядка: один ответственный выдаёт ID, остальные добавляют данные по уже выделенным значениям. Номер строки Excel идентификатором не является.
Составьте словарь полей
Для каждого поля запишите смысл, источник и ответственного за исправление. Стартовый набор можно оформить так:
- Постоянный ID: служебное обозначение объекта учёта; присваивает установленный механизм реестра; пользователи не переименовывают.
- Проект и объект: ссылки на согласованные справочники; подтверждает координатор проекта.
- Узел или изделие: контекст расположения; источник — актуальная документация и сведения ответственного за производство.
- Текущее обозначение: номер на выбранной действующей схеме; источник — конкретный документ.
- Документ и версия: два отдельных поля, а также ссылка на файл; подтверждает ответственный за документацию.
- Лист и местоположение: способ найти соединение в документе; используется при проверке соответствия.
- Прежние обозначения: история соответствий с версиями документов и основанием изменения.
- События контроля: связанные записи со своими ID, датами и документами результата.
- Состояние учёта: например, «сведения уточняются», «карточка подтверждена», «выведено из текущего перечня»; это не техническое заключение.
- Основание изменения: документ или согласованное решение, автор и время внесения.
Не делайте одно поле «статус» ответом на все вопросы. Готовность исходных сведений, выполнение работы, состояние комплекта и технический результат имеют разные основания. Их смешение создаёт ложное впечатление завершённости.
Проверьте модель на заполненном примере
Предположим, на учебном объекте «Корпус А» учитывается одно соединение. Названия и номера ниже условные; пример показывает связи, а не параметры сварки.
- Постоянный ID: J-000417.
- Проект: ПР-26-04; объект: «Корпус А»; узел: У-12.
- Первоначальное обозначение: С-017.
- Исходный документ: схема СХ-08, версия 2, лист 4.
- Текущее обозначение: С-017А.
- Действующий документ: схема СХ-08, версия 3, лист 4.
- Основание изменения: извещение ИЗ-006; ответственный подтвердил, что изменено обозначение того же физического соединения.
- Первое событие контроля: К-0091, ссылка на J-000417, документ результата Р-0091.
- Повторное событие: К-0104, ссылка на тот же J-000417, основание и документ результата Р-0104.
- История обозначений: С-017 связано с версией 2; С-017А — с версией 3.
Заявка, созданная по версии 2, должна оставаться понятной после выхода версии 3. Поэтому в ней сохраняются использованные тогда обозначение и версия документа, а связь с соединением продолжает вести к J-000417. Если показывать в старой заявке только сегодняшнее обозначение, история будет выглядеть иначе, чем в момент работы.
В отчёте из примера будет одно соединение и два события контроля. Если считать строки событий как количество соединений, объём работ по объектам окажется завышен.
Установите правила для изменения схемы
При получении новой версии документа сначала сопоставьте её с предыдущей. Ответственный определяет, какие соединения сохранились, какие только переименованы, а какие добавлены или исключены. Совпадение номера само по себе не доказывает совпадение физического объекта.
Если изменилось только обозначение, оставьте ID и добавьте запись соответствия. Если появилось другое физическое соединение, заведите новый ID с необходимой связью с прежним объектом. При разделении или замене не пытайтесь выразить всю историю простым переименованием.
Неясный случай направьте на подтверждение специалисту, который располагает проектным контекстом. До подтверждения отметьте связь как требующую уточнения. Алгоритм сопоставления может предложить кандидата, но не должен молча объявить два объекта одним из-за похожих строк.
Повторный контроль храните отдельным событием
У повторного контроля собственные исходные данные и основание. Он связан с тем же соединением и, при необходимости, с предыдущим событием. Сохраняйте предусмотренные проектом сведения об объёме и участке контроля: один ID соединения не означает одинаковый объём всех действий.
Отдельно различайте исправление реквизита, повторный выпуск документа и фактическое повторное выполнение контроля. Это разные события. Новая версия файла сама по себе не доказывает, что специалисты ещё раз выполнили работу.
Решение о ремонтных работах и последующих действиях принимается по установленному порядку. Реестр отражает эту последовательность и документы-основания. Он не определяет пригодность соединения по наличию последнего загруженного файла.
Согласуйте обмен между цехом и лабораторией
В передаваемом перечне указывайте ID соединения, проект, обозначение, документ и версию. Возвращаемый результат должен позволять восстановить ту же связь. Если внешняя лаборатория использует собственные номера, заведите соответствие её идентификатора вашему, сохранив источник.
Перед импортом проверяйте три случая: неизвестный ID, обозначение от другой версии и повторную загрузку того же события. Для каждого нужен понятный исход: уточнение, отклонение или подтверждённое обновление. Незаметное создание нового соединения при любом несовпадении быстро испортит реестр.
В описании программных решений TWI учёт сварочной информации и отчётность НК связаны с задачей прослеживаемости. Для собственного процесса начните с общего словаря, затем проверяйте программную поддержку. Связь реестра с первичными записями разобрана также в статье о журнале сварочных работ.
Проведите короткую проверку качества реестра
Выберите десять соединений, включая переименованное и прошедшее повторный контроль. Попросите сотрудника, который не вводил данные, восстановить их историю. Отмечайте не только найденные файлы, но и подтверждение связей.
- Можно найти объект по текущему и прежнему обозначению.
- Постоянный ID одинаков в заявке, карточке и связанных событиях.
- У каждого обозначения известен документ и версия.
- Повторное действие не создало лишнее соединение.
- Старый результат сохранился и отделён от последующего.
- Неясные соответствия видны и имеют ответственного.
Если поиск требует устного объяснения автора, найдите недостающее поле или правило. Исправляйте причину системно, затем расширяйте реестр. Общие принципы такой работы собраны в материале о прослеживаемости производства.
Призма представлена в каталоге ExtentLab как решение для заявок и заданий НК, соединений, дефектов, заключений и документов. Подготовьте два связанных документа с разными обозначениями одного соединения и обсудите учёт контроля в Призме. На этом примере можно проверить нужные связи, историю и порядок уточнений.