Можно ли дорабатывать 1С:Фреш: расширения, интеграции и ограничения облачной 1С

Евгений — Wed, 09 Sep 2026 09:50:36 +0000

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

А что будет с доработками?

В локальной 1С всё относительно понятно. Есть информационная база, конфигурация, расширения, внешние обработки, интеграции и инфраструктура, которой управляет сама компания или обслуживающий её подрядчик.

В облачной модели часть контроля над инфраструктурой переходит оператору сервиса. Из-за этого иногда возникает представление, что 1С:Фреш — это полностью закрытая система, в которой ничего нельзя изменить.

На практике всё интереснее.

Разберём, чем облачная модель отличается от локальной 1С с точки зрения разработчика, какие варианты доработки доступны и в каких случаях ограничения облака действительно становятся критичными.

Что меняется при переходе в облако

В классическом локальном варианте организация самостоятельно отвечает за значительную часть инфраструктуры:

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

При использовании 1С:Фреш приложение и информационная база работают в облачной инфраструктуре сервиса.

Пользователь подключается к своей базе через интернет, а значительная часть инфраструктурных задач выполняется централизованно.

Для небольшой компании это может заметно упростить эксплуатацию 1С.

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

Поэтому подход к кастомизации меняется.

Можно ли изменять конфигурацию 1С:Фреш?

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

В облачной модели такой подход противоречил бы самой архитектуре сервиса.

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

Поэтому классическая схема:

снять конфигурацию с поддержки
↓
изменить типовую конфигурацию
↓
самостоятельно сопровождать изменения

для облачного сервиса не является основной моделью работы.

Но это не означает, что кастомизация невозможна.

Для многих задач используются расширения конфигурации.

Расширения как основной механизм доработки

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

Идею можно представить так:

Типовая конфигурация
│
├── стандартная функциональность
│
└── расширение
│
├── дополнительная логика
├── изменение поведения
└── новые возможности

При таком подходе типовая конфигурация продолжает обновляться централизованно, а дополнительная функциональность существует отдельно.

Для облачной модели это принципиально важно.

Вместо изменения основной конфигурации появляется дополнительный слой бизнес-логики.

Какие задачи можно решать доработками

На практике необходимость доработки часто возникает не потому, что нужно полностью изменить программу, а из-за конкретных бизнес-процессов.

Например:

добавить дополнительные реквизиты;
изменить отдельные формы;
автоматизировать специфические операции;
добавить проверки;
реализовать дополнительные отчёты;
автоматизировать заполнение документов;
связать 1С с внешней системой;
реализовать дополнительную бизнес-логику.

Для части таких сценариев возможностей стандартной конфигурации уже достаточно.

Для остальных могут использоваться расширения или внешние механизмы интеграции.

Более подробно варианты и ограничения я разбирал в отдельном материале о доработке 1С:Фреш.

Интеграции становятся особенно важными

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

Это интеграция.

Современная информационная система редко существует изолированно.

Например:

Интернет-магазин
│
▼
API
│
▼
1С
│
├──── CRM
│
├──── Банк
│
└──── Склад / маркетплейс

Вместо попытки перенести всю бизнес-логику внутрь одной системы можно разделять ответственность между несколькими сервисами.

Это особенно актуально для SaaS-модели.

Почему нельзя просто дать полный доступ к серверу

Иногда ограничения облачной 1С воспринимаются исключительно как недостаток.

Но стоит посмотреть на другую сторону архитектуры.

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

Оператору становится сложнее обеспечивать:

обновляемость;
совместимость;
безопасность;
стабильность;
резервное копирование;
стандартизированное окружение.

Поэтому ограничения являются не случайной особенностью, а следствием самой модели SaaS.

Похожий компромисс существует практически в любом облачном сервисе:

меньше контроля над инфраструктурой в обмен на меньшее количество инфраструктурных задач.

Обновления — одно из ключевых различий

Допустим, компания использует сильно изменённую локальную конфигурацию.

Выходит новая версия типового решения.

Перед обновлением необходимо проверить:

какие объекты были изменены;
что изменилось в новой версии;
возникли ли конфликты;
работают ли существующие доработки;
нужно ли адаптировать собственный код.

Чем сильнее изменена типовая конфигурация, тем сложнее может становиться её сопровождение.

Использование расширений позволяет уменьшить связанность собственной логики с основной конфигурацией, хотя совместимость расширений после обновлений всё равно необходимо контролировать.

В облачной модели централизованное обновление является одной из фундаментальных особенностей сервиса.

Когда облако удобно разработчику

На первый взгляд разработчику выгоднее иметь полный доступ к системе.

Но всё зависит от задачи.

Представим небольшую компанию, которой нужны:

бухгалтерия;
несколько пользователей;
удалённый доступ;
одна интеграция;
несколько дополнительных отчётов.

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

Облачная модель позволяет разработчику сосредоточиться на прикладной задаче вместо обслуживания инфраструктуры.

Когда локальная 1С может оказаться предпочтительнее

1С:Фреш подходит не для любого проекта.

Локальное или собственное серверное развертывание может оказаться логичнее, если требуется:

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

Поэтому вопрос лучше формулировать не как:

Что лучше — локальная 1С или 1С:Фреш?

а как:

Какой уровень контроля над системой нужен конкретному проекту?

Архитектурный компромисс

Если сильно упростить, различие можно представить следующим образом.

Локальная 1С
Больше контроля
+
Больше ответственности за инфраструктуру
1С:Фреш
Меньше контроля над инфраструктурой
+
Меньше инфраструктурной нагрузки

При этом прикладная кастомизация не исчезает полностью — просто используются другие механизмы.

Именно поэтому перед миграцией важно смотреть не только на список функций типовой конфигурации, но и на существующие доработки компании.

Если в текущей базе накоплено много изменений, сначала стоит определить:

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

Я бы начал с небольшого технического аудита текущей базы.

[ ] Изменения типовой конфигурации
[ ] Расширения
[ ] Внешние обработки
[ ] Внешние печатные формы
[ ] Регламентные задания
[ ] Интеграции
[ ] Обмены данными
[ ] Дополнительные отчёты
[ ] Используемые внешние компоненты

После этого каждую доработку можно классифицировать.

Доработка
│
├── больше не нужна
│
├── уже есть в типовой конфигурации
│
├── можно реализовать расширением
│
├── можно заменить интеграцией
│
└── требует локальной инфраструктуры

Такой анализ обычно намного полезнее абстрактного сравнения возможностей облачной и локальной 1С.

Итог

1С:Фреш не стоит воспринимать просто как «1С, установленную на чужом сервере».

Это другая модель эксплуатации приложения.

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

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

Поэтому при выборе между локальной 1С и облаком главный технический вопрос звучит так:

Нужен ли проекту полный контроль над платформой и инфраструктурой или достаточно кастомизации на уровне прикладной логики и интеграций?

Для общего понимания устройства сервиса и отличий от локальной установки можно также посмотреть подробный разбор 1С:Фреш

DEV Community: Евгений

Можно ли дорабатывать 1С:Фреш: расширения, интеграции и ограничения облачной 1С

А что будет с доработками?

Что меняется при переходе в облако