Как ведомость становится проектом заявки
Мы предлагаем начинать интеграцию BIM с 1С с одной согласованной ведомости. Для каждой строки сервис проверяет происхождение, единицу и количество, ищет соответствие в учётном справочнике и сохраняет решение ответственного. Снабженец получает проект заявки с проверенными позициями и отдельный список строк, которым нужна ручная проверка.
Такой обмен можно построить и вокруг выгрузки в таблицу, и вокруг данных IFC, формата обмена данными строительной модели, если ваш инструмент передаёт нужные поля. В первой версии важнее договориться, какие данные принимает снабжение и кто их подтверждает. В неё включаем загрузку ведомости, таблицу соответствий, разбор исключений, согласование и сверку следующей версии.
Иллюстрация предлагаемого процесса: подтверждённое соответствие связывает элемент с закупочной позицией, варианты остаются на проверке.
Три решения принимают разные ответственные. BIM-менеджер подтверждает исходную ведомость и смысл количества. Снабжение принимает соответствие артикулу и допустимую замену. Сотрудник с нужными полномочиями утверждает заявку по правилам компании.
Что мы уже связали с 1С
В «Бакаеве» мы помогли перенести локальную 1С в облако и настроили двусторонний API-обмен с админ-панелью мобильного магазина. Сотрудник меняет фотографию товара в админке, и изменение доходит до 1С. Заказ из приложения меняет остаток в админке и учётной системе; изменения из 1С возвращаются к приложению.
Реальный проект 13FOX
Каталог в связанном торговом процессе
В админ-панели команда магазина управляет товарами, которые участвуют в обмене с 1С.
Экран управления каталогом Бакаева. Проект относится к продуктовому ритейлу.
Для BIM-ведомости мы отдельно проектируем правила количества, единиц и соответствий закупочной номенклатуре.
В строительной задаче к обмену добавляется согласование проектных данных со снабжением. Например, обозначение трубы в модели может описывать тип и геометрию, а закупочная карточка содержит конкретное исполнение и фасовку. Этот переход разбираем с вашим BIM-менеджером и специалистом по 1С до настройки записи.
Сохраняем происхождение каждой строки
Перед импортом мы согласуем состав ведомости: проект, раздел, версию модели, дату выгрузки, идентификатор элемента или список элементов агрегированной строки, название величины, значение и единицу. Сохраняем исходный файл и его контрольную сумму, чтобы можно было установить, какая выгрузка попала в обработку. Номер строки помогает найти запись в файле, но после сортировки он может измениться.
Мы проверяем идентификатор элемента в вашей выгрузке. В IFC для объектов, наследующих IfcRoot, предусмотрено поле GlobalId, как указано в документации IFC 4.3.2.0 RELEASE. До настройки сверки версий проверяем на двух ваших выгрузках, сохраняет ли экспортёр нужные идентификаторы.
Допустим, ведомость уже объединяет трубы одинакового типа по этажу. Тогда закупочная строка должна хранить связь со всеми исходными элементами и правило объединения. Мы проверяем состав выгрузки, чтобы один и тот же участок не попал в количество через две связанные модели или одновременно через элементы и их итоговую строку.
Проверяем единицу и смысл количества
Число в ведомости получает смысл вместе с названием величины. Сначала выбираем, какое поле вашей выгрузки передаёт нужное количество. Для трубы это может быть длина, для детали указывают количество штук. В IFC набор IfcElementQuantity допускает разные физические величины и указание метода измерения. У одного элемента могут быть наборы, рассчитанные разными методами. Поэтому мы фиксируем версию схемы IFC, набор и тип величины, название поля и метод измерения, если он указан. Выбор согласуем с BIM-менеджером, опираясь на описание IfcElementQuantity.
Для простых физических величин в IFC сначала читаем единицу самой величины. Если её нет, используем единицы проекта. Это правило для IfcPhysicalSimpleQuantity указано в схеме IFC. При выгрузке в таблицу мы просим передать явную единицу рядом со значением: так смысл количества сохраняется за пределами модели.
Перевод миллиметров в метры выполняем по согласованному правилу. Перевод метров трубы в упаковки требует данных о закупочной позиции и правил округления. Если этих данных нет, строка ждёт уточнения. Запас, раскрой и монтажные потери согласуем отдельно; исходное количество модели сохраняем рядом с закупочным, чтобы снабженец видел причину разницы.
Таблица соответствий, которую можно проверить
Мы предлагаем хранить соответствие отдельной записью: признаки исходного типа, идентификатор учётной позиции, единицы с обеих сторон, правило преобразования, версия правила и подтверждение ответственного. Название помогает найти кандидатов. Допуск к заявке зависит от проверенных параметров: материала, размера, исполнения и других признаков вашего ассортимента.
Ниже условный пример для инженерной ведомости. Артикулы в нём условные.
- Подтверждённая труба. Исходная строка: тип «Труба А», длина 24 м, список ID элементов и версия ведомости. В учёте выбран артикул Т-01 с единицей «метр». Материал, диаметр и исполнение подтверждены снабжением. В проекте заявки остаётся 24 м; сохраняем исходные ID и версию ведомости.
- Клапан с двумя кандидатами. Для типа «Клапан Б» количество задано в штуках, а в учёте подходят К-01 и К-02. Нужно уточнить исполнение. Строка остаётся в карантине до решения ответственного.
- Труба в упаковках. Ведомость содержит длину типа «Труба В» в метрах, а артикул Т-03 закупают упаковками. Проверяем состав упаковки и правило округления. До согласования закупочное количество не формируем.
- Новый тип. Принятого соответствия ещё нет, учётная позиция не выбрана. Показываем причину и исходные свойства. Снабжение выбирает существующий артикул либо запускает свой порядок создания карточки.
Подтверждённое правило можно применять к следующим строкам с теми же согласованными признаками. Если у элемента изменился значимый параметр, в 1С закрыли учётную позицию или поменялись единица, упаковка либо версия правила, соответствие возвращаем на проверку. Уже согласованную заявку сохраняем; изменения в ней требуют отдельного решения. Такое поведение фиксируем в задании вместе с правами на изменение правил.
Карантин строк помогает разобрать исключения
Карантин — отдельный список позиций, которые пока нельзя включить в проект заявки. В нём показываем исходную строку, причину остановки, возможные артикулы и ответственного за решение. Сотрудник видит, что именно требуется уточнить, и может вернуться к элементу модели.
Схема проверки ведомости. Решение по исключению сохраняется вместе с исходными данными и версией правила.
Например, у клапана совпало название, но подходят два исполнения. Сервис показывает оба кандидата и недостающий признак. После подтверждения снабжением фиксируем выбор и его основание. Если меняется техническое исполнение проекта, согласование с проектировщиком проходит по принятому у заказчика порядку.
- Нет соответствия: уточнить свойства и выбрать учётную позицию.
- Несовместимые единицы: проверить исходную величину и допустимое преобразование.
- Пустое или некорректное количество: вернуть строку владельцу ведомости.
- Неясное происхождение или повтор элементов: проверить состав выгрузки перед объединением.
Мы согласуем, можно ли утвердить проверенную часть отдельно. Если компания требует полную ведомость, нерешённые строки останавливают её согласование целиком. В обоих вариантах исключения остаются видимыми и не превращаются в закупочную позицию по догадке.
Согласуем заявку и сравниваем версии
Проект заявки показывает закупочную позицию, количество, единицу, исходные строки, версию ведомости и принятое соответствие. До передачи в 1С ответственный подтверждает состав. Отдельно определяем целевой документ, обязательные реквизиты, права и допустимые действия после создания. Объект и правила записи зависят от вашей конфигурации.
Стандартный REST-интерфейс 1С позволяет читать и изменять данные опубликованного приложения. Документация указывает, что при таком доступе действуют проверки прав и обработчики событий, за исключением проверки заполнения. Поэтому доступность API дополняем проверкой обязательных реквизитов и бизнес-правил на тестовой базе. Способ подключения выбираем при проектировании обмена с 1С.
Повтор той же выгрузки должен показывать уже обработанную версию и связанную заявку. Мы предлагаем сохранять идентификатор операции до отправки и связывать с ним результат в 1С. Перед повторной записью проверяем предыдущую попытку. Если ответ от 1С потерялся, сначала выясняем, создался ли документ. Этот сценарий включаем в приёмку API-интеграции.
Допустим, после согласования проектировщик изменил длину труб. Новую ведомость сравниваем с принятой: показываем добавленные, удалённые и изменённые строки, их количества и затронутые заявки. Изменения отправляем ответственному на решение. Для уже размещённого заказа определяем отдельный порядок корректировки; уменьшение количества в модели само по себе не отменяет закупку.
Как принять первую версию обмена
Для проверки возьмите ведомость с обычными строками и исключениями, а затем её изменённую версию. Мы заранее запишем ожидаемый результат каждого сценария. Снабженец и BIM-менеджер смогут сверить заявку с исходными данными, а специалист по 1С сможет проверить создание документа и обработку сбоя.
- Подтверждённая строка: в проекте заявки нужный артикул, единица и количество; доступна связь с исходными элементами.
- Два кандидата или неизвестная единица: строка ждёт решения и не попадает в утверждённую закупочную часть.
- Повторный импорт: система узнаёт ту же обработанную выгрузку; проверяем обычный повтор и две одновременные попытки. Ожидаемый результат: одна связанная заявка.
- Изменённая версия: разница видна до утверждения, включая исчезнувшие элементы и смену артикула.
- Сбой обмена: причина доступна сотруднику; проверяем потерю ответа после записи. Повтор учитывает результат предыдущей попытки, а итог сверяется с 1С.
Объём разработки зависит от качества исходной ведомости, состава справочника, правил объединения и закупочных единиц, маршрута согласования и возможностей 1С. Для оценки мы разделяем разбор данных, разработку соответствий, интерфейс ручной проверки, подключение и приёмку. Границы первой версии фиксируем на выбранной ведомости.
Что уточнить перед началом
Можно ли начать с таблицы без прямого подключения к BIM?
Да, если ведомость передаёт согласованные поля, версию и происхождение строк. Сначала проверяем эту выгрузку и правила соответствий. Прямой доступ к модели добавляем, когда он нужен для повторяемого процесса.
Можно ли сопоставить произвольные названия автоматически?
Сервис может предлагать кандидатов по названиям и свойствам. Для допуска в заявку мы согласуем признаки соответствия и подтверждение снабжением. Неоднозначные строки остаются на ручной проверке.
Откуда берётся количество для закупки?
Из проверенной ведомости и согласованных правил преобразования в закупочную единицу. Упаковки, округление, запас и потери требуют отдельных исходных данных и решений ответственных. В заявке сохраняем исходное количество и объяснение преобразования.
Разберём одну ведомость и её соответствия
Пришлите одну ведомость, несколько учётных позиций и правила подтверждения. Разберём соответствия и предложим карту преобразования, ручной проверки и приёмки обмена.
Оставьте контакт. В разговоре уточним вашу BIM-систему и 1С и согласуем удобный канал для передачи обезличенной ведомости.