Ситуация
Заказчик выпускает медицинские изделия. Продав их, он по закону должен сообщить Росздравнадзору о вводе продукции в гражданский оборот. Для этого в личном кабинете на портале ведомства подаются уведомления.
Портал принимает их двумя способами: можно заполнить форму вручную или загрузить XML-файл. Учет заказчик вел в 1С:ERP, но готовой выгрузки по утвержденному Росздравнадзором шаблону в системе не было, и все заполняли вручную.
Раз в неделю сотрудник формировал в 1С отчет об отгруженной готовой продукции. Какими накладными оформлены продажи, из отчета видно не было, поэтому отчет уходил в отдел продаж, а сотрудник ждал ответа со списком накладных и их датами.
Потом начиналась работа на портале. Для каждого уведомления он указывал регистрационное удостоверение, искал в списке нужную модель, вписывал накладную и ее дату. Затем по каждому изделию заполнял пять полей: дату ввода в оборот, дату производства, срок годности, серийный номер и количество.
Обычно за неделю набиралось 5–10 уведомлений. Вместе с ожиданием ответа из отдела продаж на них уходило 2–3 часа. В недели с крупными отгрузками времени требовалось заметно больше: в одном из отчетов заказчика только по одной модели за четыре дня прошло 60 изделий. Сотруднику пришлось вручную заполнить 300 полей, и это была лишь часть недельного отчета.
Задача
Заказчик обратился в implecs, чтобы избавиться от ручного ввода на портале Росздравнадзора. Нам поставили задачу создать в 1С:ERP обработку, которая сама собирает сведения о проданных за неделю изделиях и формирует из них файл для пакетной загрузки.
Решение
Мы начали с разбора ручного процесса. Изучили, как сотрудник собирал сведения, и попросили показать, как заполняется уведомление в личном кабинете. Без этого нельзя было понять, как поля формы соотносятся с полями XML.
Настроили отбор отгрузок
Первым делом обработка должна была находить отгрузки, по которым подаются уведомления. За основу взяли отчет, по которому сотрудник собирал сведения, и повторили его параметры: период, организацию, склад и бизнес-регион. Часть получателей в выгрузку попадать не должна была, и для них добавили отдельный фильтр. Чтобы сотрудник не выбирал настройки каждую неделю заново, сделали их сохранение между сеансами.
Кроме отгрузок со склада, в сведения попадали изделия из документов интеркампани, которыми в 1С оформляют передачу товаров между собственными организациями. С расходными ордерами такой документ связан не был, и запрос его не находил. Но появлялся он раз в неделю, с той же частотой, что и выгрузка, так что выбрать его вручную было проще, чем строить отдельный поиск. Поэтому решили, что документ и его позиции пользователь будет указывать в обработке сам.
Связали отгрузки с документами продажи
Для уведомления в Росздравнадзор требовалась еще и накладная, а в расходных ордерах ее не было. Раньше накладные присылал отдел продаж, теперь их предстояло брать из документов продажи в 1С:ERP.
Сложность была в том, что напрямую расходный ордер и документ продажи не связаны. Общим у них был только заказ клиента, а по одному заказу оформляли 2, 3 или 5 ордеров и столько же продаж. Отгрузка по заказу могла идти в разные дни, а в один день по одной номенклатуре проходило по нескольку ордеров и продаж. Однозначно понять, какая строка к какой относится, в таких случаях было нельзя.
Сначала рассчитывали обойтись без участия человека. Обработка должна была сама находить для каждой отгрузки документ продажи и сразу формировать XML. Добиться этого не удалось, хотя на попытки ушло немало времени.
Тогда отгрузки и продажи стали связывать по трем признакам: дате, количеству и номенклатуре. Совпавшие строки обработка связывала сама, а остальные выводила в таблицу с пустыми полями, чтобы пользователь дополнил их вручную. Внешне таблицу сделали похожей на еженедельный отчет, с которого раньше начиналась подача сведений, только большинство накладных в ней уже проставлено.
Настроили выгрузку из 1С:ERP для пакетной загрузки в Росздравнадзор
Оставалось собрать из этих данных файл по шаблону ведомства. После тестовых загрузок часть реквизитов доработали, чтобы он проходил проверку по XSD-схеме.
Отдельно разобрались с идентификатором уведомления NotificationId. В системе Росздравнадзора это внутренний номер уведомления, и готового аналога для него не было. Сначала исходили из того, что один документ в 1С — это одно уведомление. Но по шаблону в уведомлении может быть только одна модель изделия, а в документе продажи их бывает несколько. Поэтому обработка стала заводить уведомление на каждую модель и генерировать для него случайный уникальный NotificationId.
Больше всего времени ушло на поле MedDevicesId. В 1С такого значения не было, а шаблон не объяснял, откуда его брать. Путь к нему оказался неочевидным, но в конце концов мы нашли источник значения.
Теперь раз в неделю сотрудник подает сведения так:
- Открывает обработку и выбирает период.
- Проверяет строки без документа продажи и дополняет их.
- Формирует XML-файл и загружает его в личном кабинете Росздравнадзора.
Непредвиденные трудности
Поле MedDevicesId. В шаблоне Росздравнадзора оно было подписано как «Идентификация модели медицинского изделия», и к нему шло единственное требование: значение должно совпадать с данными в системе ведомства. В ручной форме на портале сотрудник выбирал модель по регистрационному удостоверению, а в XML на ее месте стояло число без каких-либо пояснений. Было непонятно, что это за идентификатор и где он хранится.
Попробовали подставить в поле номер регистрационного удостоверения (РУ) — портал вернул ошибку. Обыскали весь сайт Росздравнадзора, но ответа там не нашли. Сдвинуть дело с мертвой точки помог ChatGPT. Он предложил проверить реестр изделий, введенных в гражданский оборот. По удостоверению там открылся список всех моделей заказчика, у каждой по несколько кодов. Их пришлось перебирать по очереди, и подошел только уникальный номер модели медицинского изделия.
Чтобы идентификатор попадал в выгрузку, в справочник «Номенклатура» добавили дополнительный реквизит «Уникальный номер модели». Заказчику передали ссылку на реестр и объяснили, как найти в нем свое изделие по регистрационному номеру.
Оценка сроков. Фактические трудозатраты превысили первоначальную оценку вдвое. Сверхплановые часы ушли на поиск MedDevicesId и попытки полностью автоматизировать сопоставление документов. Обе сложности выявились только в ходе работ.
Результат
Раньше сотрудник формировал отчет о проданных изделиях и вручную заводил на портале уведомления с десятками позиций. Теперь сведения собираются в 1С автоматически и отправляются в Росздравнадзор одним файлом.
Подача уведомлений занимает 15–20 минут вместо 2–3 часов. Сотрудник больше не перепечатывает серийные номера и не заводит каждое уведомление отдельно.
Длительность. На задачу ушло 51,5 часа.
Команда. С нашей стороны участвовали два специалиста: разработчик 1С и руководитель проекта. Со стороны заказчика — главный бухгалтер и постановщик задачи.
