Обязательны ли стандарты разработки 1С и как правильно относиться к замечаниям аудиторов?

← На главную

В практике разработки на платформе 1С:Предприятие часто возникает ситуация, когда при проведении внешнего IT-аудита к программисту предъявляются претензии по поводу несоблюдения официальных стандартов фирмы «1С». В качестве примеров аудиторы указывают на отказ от использования расширений конфигурации, применение устаревших технологий обмена (например, COM-соединения вместо EnterpriseData или HTTP-сервисов) или внесение изменений непосредственно в типовые модули. При этом сам код может работать корректно и полностью закрывать потребности пользователей.

В этой статье мы подробно проанализируем, каков реальный статус стандартов разработки 1С, в каких случаях они юридически и технически обязательны, а также разберем архитектурные альтернативы спорным техническим решениям.

1. Юридический и технический статус стандартов 1С

Рассмотрим, что собой представляет «Система стандартов и методик разработки интерактивных конфигураций» (раздел ИТС 1С). С формальной точки зрения все стандарты фирмы «1С» делятся по уровню обязательности на две категории:

Обязательные для тиражных решений и сертификации: Стандарты являются безусловно обязательными для самой фирмы «1С» при создании типовых конфигураций (УТ, БП, ERP, ЗУП), а также для сторонних партнерских продуктов, претендующих на получение статуса «1С:Совместимо!».
Рекомендательные для заказной (In-House) разработки: Если система дорабатывается под конкретного заказчика или разрабатывается собственная уникальная конфигурация «с нуля», стандарты носят исключительно рекомендательный характер.

Заставить разработчика неукоснительно следовать стандартам ИТС в рамках заказной разработки можно только одним способом — зафиксировав это требование во внутреннем регламенте компании, техническом задании (ТЗ) или договоре на разработку. Если такого документа нет, требования аудиторов о соблюдении всех пунктов стандартов юридически и технически безосновательны.

2. Почему аудиторы критикуют COM-соединения и чем их заменить

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

Зависимость от операционной системы Windows: COM-технология не работает под управлением ОС Linux. При переводе серверов 1С на Linux в рамках импортозамещения COM-обмен полностью работоспособен быть не сможет.
Проблемы с разрядностью и регистрацией DLL: На 64-битных серверах 1С требуется настройка компоненты через `Component Services` (dcomcnfg), а при каждом обновлении платформы необходима перерегистрация библиотек.
Утечки памяти и «зомби-процессы»: Незавершенные COM-сеансы могут накапливаться в оперативной памяти сервера, приводя к сбоям в работе платформы.
Несовместимость с облачными сервисами (1С:Фреш): В облаках прямое COM-подключение к базе невозможно из соображений безопасности.

Выясним, какие современные альтернативы рекомендуются для построения обменов данными:

HTTP-сервисы (REST API)

Создание собственного HTTP-сервиса на стороне базы-приемника и отправка данных в формате JSON или XML через объект HTTPСоединение. Это кроссплатформенный и быстродействующий подход.

Пример отправки данных из базы-источника через HTTP-запрос:


Соединение = Новый HTTPСоединение("api.server.ru", 443, , , , Истина);
Заголовки = Новый Соответствие;
Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");

ДанныеСтруктура = Новый Структура;
ДанныеСтруктура.Вставить("Номер", ДокументСсылка.Номер);
ДанныеСтруктура.Вставить("Сумма", ДокументСсылка.СуммаДокумента);

ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ДанныеСтруктура);
СтрокаJSON = ЗаписьJSON.Закрыть();

Запрос = Новый HTTPЗапрос("/v1/exchange/document", Заголовки);
Запрос.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8);

Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Если Ответ.КодСостояния = 200 Тогда
    // Данные успешно приняты
КонецЕсли;

Формат EnterpriseData (ED)

Универсальный стандарт обмена на базе XML/JSON, входящий в состав БСП (Библиотеки Стандартных Подсистем). Он позволяет обновлять конфигурации (например, УТ и БП) независимо друг от друга. Изменение структуры документа в УТ не ломает прием документа в БП, так как обмен идеологически отчужден от структуры конкретных таблиц базы.

3. Использование расширений (.cfe) против изменения типовой конфигурации

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

Преимущества применения расширений:

Основная конфигурация остается на автоматическом обновлении (без необходимости снимать с поддержки или настраивать правила объединения).
Доработки изолированы от типового кода.

Ограничения и подводные камни расширений:

При масштабном обновлении релизов платформы или типовой конфигурации методы, перехваченные аннотациями &Вместо, &Перед или &После, могут измениться по структуре параметров, что приведет к runtime-ошибкам у пользователей.
Сложность трехстороннего сравнения и объединения кода расширений при выходе новых версий поставщика.

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

4. Управление рисками («Фактор автобуса»)

Проанализируем претензии аудиторов с точки зрения бизнеса. Аудиторы действуют в интересах собственников компании и оценивают риски. Основной риск нестандартного кода — это «фактор автобуса» (Bus Factor).

Если разработчик создает уникальный архитектурный «велосипед» (например, собственный COM-обмен с парсингом строк по уникальным алгоритмам), то при его увольнении компания столкнется с высокими затратами на вхождение нового специалиста в проект. Код, написанный по общепринятым стандартам 1С, новый программист сможет понять и доработать значительно быстрее.

Заключение и рекомендации по общению с аудиторами

Запросите нормативную базу: Попросите аудиторов указать, каким именно внутренним стандартом или пунктом ТЗ регламентировано обязательное использование стандартов ИТС в вашей компании.
Оцените стоимость изменений: Объясните руководству, что переписывание работающего COM-обмена на EnterpriseData или HTTP-сервисы, а также перенос кода в расширения требует дополнительных человеко-часов и бюджета.
Примените прагматичный подход: При проектировании новых задач используйте современные механизмы (HTTP-сервисы, БСП, расширения), а существующий работоспособный код модернизируйте планово, по мере появления производственной необходимости.