Вопрос подписчика
«Вы внедряете и развиваете 1С:ERP. А доработки, обмены, интеграции и технические задания вы тоже делаете? Или это уже отдельная история?»
Ответ ERP-Мастер
Да, это часть нашей продуктовой линейки. Но мы специально разделяем три разных типа работ: обмены и интеграции, технические задания для разработки и сами программные доработки 1С. Это не одно и то же. У каждого типа работ разные риски, результаты, критерии приёмки и технология выполнения.
Эта статья — материал третьего уровня в подборке ERP-Мастер. Она дополняет статьи про внедрение и развитие 1С:ERP, справочную структуру предприятия, интеграцию инженерных систем, бизнес-процессы и автоматизированные инструкции.
1. Обмены и интеграции: главная практическая задача
Вопрос подписчика
«Что чаще всего заказывают после внедрения или в процессе развития 1С:ERP?»
Ответ ERP-Мастер
Чаще всего — обмены. Нужно связать 1С:ERP с другой базой 1С, с 1С:ЗУП, бухгалтерским контуром, PDM/PLM, MES, складской системой, внешним сервисом, корпоративным порталом или старой учётной системой.
На производственном предприятии 1С:ERP редко живёт одна. Рядом могут быть 1С:ЗУП, 1С:Бухгалтерия, отдельная база регламентированного учёта, инженерная система PDM/PLM, система диспетчеризации производства, складские терминалы, весы, внешние отчёты, CRM, документооборот, старые базы и Excel-файлы.
Главная ошибка — думать, что интеграция означает «просто сделать выгрузку». Настоящий обмен начинается не с кнопки, а с ответа на вопросы: какие данные передаются, откуда они берутся, кто является владельцем данных, как часто они обновляются, что делать с дублями, какие статусы нужны, где фиксируются ошибки, кто отвечает за восстановление после сбоя.
В 1С есть много технологий обмена: файловый обмен, XML, EnterpriseData, планы обмена, веб-сервисы, REST/JSON, SOAP/XML, OData, внешние источники данных, 1С:Шина. В нормальном проекте не выбирают одну технологию «на всё». Выбирают технологию под тип данных и задачу.
Реплика ERP-Мастер
Для справочников может подойти EnterpriseData или планы обмена. Для оперативных данных — REST или веб-сервисы. Для отчётности — OData. Для внешней старой системы — файловый обмен. Для сложного ландшафта — 1С:Шина как единая точка маршрутизации, мониторинга и гарантированной доставки сообщений.
В наших проектах встречались архитектуры, где есть несколько контуров 1С:ERP: управленческий учёт, отдельный хаб, регламентированный учёт, 1С:ЗУП и внешние системы. В таких случаях особенно важно не создавать «паутину» случайных обменов, а проектировать управляемую архитектуру: какие потоки идут напрямую, какие через хаб, какие через шину, какие остаются файловыми, какие запускаются по расписанию, а какие работают почти в реальном времени.
2. Почему обмен надо проектировать, а не просто программировать
Вопрос подписчика
«А если мы просто попросим программиста сделать обмен? Зачем отдельный технический проект?»
Ответ ERP-Мастер
Потому что программист без технической архитектуры быстро сделает работающий кусок кода, но потом предприятие получит не интеграцию, а технический долг.
Хороший технический проект обмена должен описывать не только «откуда выгрузить» и «куда загрузить». Он должен задавать архитектуру: системы-участники, направления обмена, состав данных, периодичность, правила преобразования, контроль дублей, фильтры, статусы, журналы, ошибки, резервные каналы, порядок тестирования и ввод в эксплуатацию.
Например, в одном проекте справочники могут идти по изменению, производственные данные — ежечасно, агрегированные документы — раз в день, зарплатные данные — после расчёта, а итоговые проводки — после закрытия периода. Для каждого потока может быть своя технология. Это нормально. Ненормально — когда всё сваливается в один обмен «раз в ночь», а потом никто не понимает, почему себестоимость не сошлась.
Реплика ERP-Мастер
Мы не начинаем обмен с кода. Мы начинаем с карты потоков данных: источник → правило преобразования → получатель → контроль качества → протокол ошибок → ответственный за исправление.
3. 1С:Шина: когда она нужна
Вопрос подписчика
«А 1С:Шина нужна всем?»
Ответ ERP-Мастер
Нет. 1С:Шина нужна не потому, что это модный продукт, а тогда, когда обменов много, системы разные, потоков несколько, нужна гарантированная доставка, маршрутизация, трансформация сообщений и единый мониторинг.
Если у предприятия один простой обмен между двумя типовыми базами 1С, шина может быть избыточной. Но если есть несколько систем, разные протоколы, внешние сервисы, очереди сообщений, сложные маршруты и требования к контролю доставки, 1С:Шина становится серьёзным архитектурным вариантом.
В этом смысле ERP-Мастер рассматривает 1С:Шину не как замену всем механизмам обмена, а как инфраструктурный слой. Она может принять сообщение, сохранить его, преобразовать, маршрутизировать, передать получателю и дать администратору единую точку контроля.
4. Технические задания: отдельный продукт
Вопрос подписчика
«А если нам не нужно, чтобы вы сами программировали? Нам нужно только грамотное ТЗ, а разработку выполнит наша команда или франчайзи».
Ответ ERP-Мастер
Это нормальный вариант. Техническое задание — отдельный продукт ERP-Мастер.
Часто заказчику не хватает не программиста, а правильно поставленной задачи. Внутри предприятия есть понимание боли: «не обновляются данные», «не хватает отчёта», «нужно связать ЛОЦМАН и 1С:ERP», «нужно обновлять производственные операции после изменения ресурсной спецификации», «нужно настроить обмен с другой базой». Но между болью и разработкой должен появиться документ, который можно передать исполнителю.
ТЗ должно описывать цель, исходные данные, ограничения, бизнес-логику, объекты 1С, статусы, правила отбора, алгоритм, сценарии исключений, требования к тестированию и критерии приёмки. Если это обмен, нужны источники данных, правила мэппинга, форматы, периодичность, протокол ошибок. Если это отчёт — состав показателей, отборы, группировки, источники данных и контрольные примеры. Если это доработка документа — роли, права, события, статусы и влияние на учёт.
Реплика ERP-Мастер
Хорошее ТЗ экономит деньги не потому, что оно красивое. Оно экономит деньги потому, что разработчик меньше додумывает, заказчик меньше спорит, а приёмка становится проверяемой.
5. Программные доработки 1С: что мы выполняем
Вопрос подписчика«А сами доработки вы делаете?»
Ответ ERP-Мастер
Да, но с важным ограничением: мы не берёмся за “доработки любой сложности вообще”. Мы выполняем те доработки, где понятны бизнес-задача, границы, тестовая среда, доступы, результат, критерии приёмки и ответственность сторон.
Мы выполняем программные доработки 1С вручную и с использованием искусственного интеллекта как инструмента ускорения разработки, анализа, подготовки кода, документации и тестовых сценариев. Но ИИ не заменяет проектную ответственность. Код должен быть проверен специалистом, установлен в тестовую среду, пройти испытания и только потом попадать в рабочую систему.
Типовые задачи: обработка обменов, дополнительные проверки данных, формы ввода, отчёты, обработки загрузки, правила отбора, обновление связанных документов, сервисные механизмы, контрольные отчёты, вспомогательные модули для пользователей и администраторов.
Мы не продаём магию «сейчас ИИ всё запрограммирует». Наша позиция другая: ИИ помогает быстрее готовить решение, но проектная дисциплина остаётся прежней — заявка, оценка, техническое описание, тестирование, протокол приёмки и сопровождение изменений.
6. Интеллектуальная собственность: кому принадлежат доработки после оплаты
Вопрос подписчика
«Если вы написали обработку, отчёт, модуль обмена или другое техническое решение для нашей 1С, кому потом принадлежат права на эту разработку?»
Ответ ERP-Мастер
Если по договору и рабочему дополнительному соглашению предусмотрена передача исключительных прав заказчику, то после полной оплаты результата эти исключительные права передаются заказчику. В бытовом языке это часто называют “передачей авторских прав”, но юридически точнее говорить именно о передаче исключительных прав на результат разработки.
Для заказчика это важный вопрос. Если предприятие оплачивает индивидуальную разработку под свою бизнес-задачу, оно должно понимать, что именно получает: исходный код, обработку, отчёт, расширение, техническое задание, инструкцию, модуль обмена, документацию, право использования или исключительные права на результат.
В каждом РДС это должно быть прописано прямо: какой результат создаётся, в каком формате передаётся, где размещается, какие права передаются заказчику и с какого момента. Практическая формула ERP-Мастер простая: исключительные права на индивидуально созданные для заказчика результаты передаются заказчику после 100% оплаты соответствующих работ, если это прямо закреплено в договоре или РДС.
Юридическая логика опирается на нормы Гражданского кодекса РФ. Статья 1234 ГК РФ описывает договор об отчуждении исключительного права, по которому правообладатель передаёт или обязуется передать исключительное право в полном объёме другой стороне. Статья 1296 ГК РФ устанавливает общее правило для произведений, созданных по заказу: исключительное право на программу для ЭВМ, базу данных или иное произведение принадлежит заказчику, если договором между исполнителем и заказчиком не предусмотрено иное.
Реплика ERP-Мастер
Поэтому вопрос прав нельзя оставлять “по умолчанию”. В нормальном проекте результат разработки, формат поставки, момент передачи прав, порядок оплаты и критерии приёмки фиксируются в договоре и РДС. Это защищает обе стороны: заказчик понимает, что получает, а исполнитель понимает, какой именно результат он обязан передать.
7. Как оформляется работа: заявка, РДС, результат, приёмка
Вопрос подписчика
«Как понять, что работа не расползётся и не превратится в бесконечный чат?»
Ответ ERP-Мастер
Для этого нужна технологическая процедура: заявка, рабочее дополнительное соглашение, перечень артефактов, приёмочные испытания и акт.
Работа начинается с заявки заказчика. В заявке должна быть описана бизнес-задача, ожидаемый результат и предварительные пожелания по срокам. После этого формируется рабочее дополнительное соглашение: состав работ, трудоёмкость, стоимость, сроки, проектная группа, доступы, результаты, критерии приёмки.
Результат работы должен быть не «что-то настроили», а конкретный артефакт: техническое задание, настроенный обмен, обработка, отчёт, исходный код, инструкция, протокол тестирования, описание настроек, файл поставки, ссылка на репозиторий или объект в тестовой базе.
Приёмка должна включать проверку результата. Для этого фиксируются сценарии приёмочных испытаний: что запускаем, какие данные используем, какой результат ожидаем, какие ошибки допустимы, кто подписывает протокол.
Реплика ERP-Мастер
Если результат нельзя проверить, его нельзя нормально принять. Поэтому мы привязываем доработки и интеграции к артефактам, тестам и протоколам.
8. Что мы не делаем
Мы не берёмся за хаотичные задачи в стиле «поправьте там что-нибудь в базе». Не делаем доработки без понятной бизнес-задачи. Не начинаем промышленную установку без тестирования. Не обещаем, что любой обмен можно быстро сделать без анализа данных. Не подменяем проектирование интеграции разовой выгрузкой. Не берём на себя ответственность за чужую инфраструктуру, если у нас нет доступа к тестовой среде, журналам, исходным данным и ответственным специалистам заказчика.
Это не формальность. Именно такие ограничения защищают и заказчика, и исполнителя.
9. С чего начать
Вопрос подписчика
«Если нам нужна интеграция, ТЗ или доработка 1С, что прислать в ERP-Мастер первым сообщением?»
Ответ ERP-Мастер
Напишите, какую бизнес-задачу нужно решить, какая система сейчас используется, какая 1С участвует в задаче, какие данные должны измениться, кто будет принимать результат и есть ли тестовая база.
Для обмена важно указать системы-участники, направления передачи, пример данных и желаемую периодичность. Для ТЗ — описать проблему и ожидаемый результат. Для доработки — показать текущий сценарий, желаемое поведение и ограничения.
Дальше мы помогаем определить формат работы: техническое задание, проект обмена, программная доработка, консультация, аудит существующей интеграции или рабочее дополнительное соглашение на выполнение конкретной задачи.
Финальная реплика ERP-Мастер
Обмены, интеграции, технические задания и доработки 1С — это не “мелкие работы программиста”. Это способ удержать 1С:ERP в живой архитектуре предприятия: связать системы, убрать ручные разрывы, оформить требования, проверить результат и сопровождать изменения.
Куда перейти дальше: внедрение и развитие 1С:ERP; интеграция инженерных систем PDM/PLM/CAD и 1С:ERP; справочная структура предприятия; бизнес-процессы в 1С:ERP; Vanessa Automation и автоматизированные инструкции; обучение 1С:ERP и подготовка команды.