Что значит «модель сервиса» в 1С и как с ней работать

Термин «модель сервиса» в контексте 1С встречается в нескольких ситуациях, и пользователи часто путают их между собой. Чаще всего речь идёт о модели обслуживания в облачном сервисе 1С:Фреш, где приложение может работать в разных моделях сервиса — например, «сервис 1С:Фреш» или «локальный режим». Реже термин используют в конфигурациях для сферы услуг, где модель сервиса описывает порядок оказания и тарификации услуг.

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

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

Что означает термин «модель сервиса» в экосистеме 1С

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

В интерфейсе менеджера сервиса 1С:Фреш «модель сервиса» — конкретный технический параметр приложения и абонента. Он определяет, как именно приложение публикуется и обслуживается: через центральный сервис фирмы «1С», через сервис партнёра или в локальной инфраструктуре заказчика с использованием технологий сервиса.

В конфигурациях для автоматизации услуг (например, решения для сервисных центров) «модель сервиса» может обозначать шаблон оказания услуг: разовое обслуживание, абонентский договор, SLA с фиксированным временем реакции. Это прикладной, а не технический смысл термина, и смешивать его с облачной терминологией не следует.

Какие модели сервиса существуют и чем они отличаются

Практически пользователь сталкивается с тремя базовыми вариантами. Первый — облачная модель: приложение работает в сервисе 1С:Фреш или у партнёра, обновления и резервное копирование выполняет оператор сервиса, оплата идёт по подписке. Второй — локальная (on-premise) модель: база развёрнута на сервере организации, обновления и копии — зона ответственности собственного администратора. Третий — смешанный вариант, когда технологии сервиса применяются внутри контура заказчика.

Различия между моделями удобно свести по ключевым параметрам:

Сравнение вариантов

Облачная модель

Подходит малому и среднему бизнесу без своего ИТ-отдела. Ограничение: доработки возможны только через расширения, доступ зависит от интернет-канала.

Локальная модель

Подходит организациям с требованиями к размещению данных и нестандартными доработками. Ограничение: нужны сервер, администратор и регламент обновлений.

Сервис у партнёра

Компромисс: облачная схема, но сопровождение ведёт франчайзи. Ограничение: условия и регламенты зависят от конкретного партнёра.

Как определить текущую модель сервиса вашей базы

Если вы работаете через браузер по адресу вида «1cfresh.com» — это облачная модель сервиса 1С:Фреш. Точный вариант обслуживания виден в личном кабинете абонента сервиса: там указаны подключенные приложения, тариф и оператор. Если вход выполняется через тонкий или толстый клиент по адресу внутреннего сервера — модель локальная.

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

1. 1
   Определите способ подключения: браузер с адресом сервиса или клиент с адресом своего сервера
2. 2
   Откройте личный кабинет абонента сервиса и проверьте тариф, оператора и список приложений
3. 3
   Если есть доступ к менеджеру сервиса — проверьте модель сервиса в свойствах приложения и абонента
4. 4
   Зафиксируйте результат в учётной записи ИТ-отдела, чтобы при переносе или смене тарифа не было путаницы

Как модель сервиса влияет на повседневную работу

В облачной модели пользователь не управляет платформой и СУБД: версии обновляет оператор, а окна обслуживания объявляются заранее. Это снимает нагрузку, но накладывает ограничения: нельзя самостоятельно откатить обновление, нельзя ставить произвольные внешние компоненты, а доработки реализуются только через расширения, прошедшие проверку сервиса.

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

Как сменить модель сервиса без потери данных

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

Обратный переход — из облака на локальный сервер — делается через выгрузку данных из сервиса (в 1С:Фреш есть штатная функция выгрузки области данных) и последующее развёртывание базы на своём сервере. Важно учитывать, что расширения, адаптированные под сервис, могут потребовать доработки, а некоторые сервисные механизмы в локальной версии работать не будут.

Контрольные точки

Как проверить результат

Сверка ОСВ до и после переноса

Норма

Обороты и сальдо совпадают по всем счетам

Тревожный признак

Есть расхождения — перенос неполный, нужен разбор

Работа обменов (банк, ЭДО, сайт)

Норма

Обмены выполняются без ошибок авторизации

Тревожный признак

Ошибки подключения — не перенастроены внешние подключения

Доступы пользователей

Норма

Все сотрудники входят и видят свои данные

Тревожный признак

Часть пользователей не может войти или видит лишнее

Типичные ошибки при работе с моделью сервиса

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

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

Маршрут решения

Как выбрать действие

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

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

Планируете сменить модель сервисаСначала сделайте полную выгрузку, разверните тестовую копию и сверьте контрольные отчёты

Перед переносом между моделями полезно зафиксировать «контрольный срез»: распечатать или сохранить в файл ОСВ, остатки по складу и взаиморасчётам на дату переноса. Это занимает минуты, но позволяет доказательно сверить результат и быстро локализовать расхождения.

Частые вопросы

Где в интерфейсе 1С:Фреш посмотреть модель сервиса?

Конечному пользователю параметр напрямую не показывается — достаточно понимать, что работа через браузерный доступ к сервису означает облачную модель. Точные настройки (оператор, тариф, модель обслуживания) видны в личном кабинете абонента сервиса, а администратору сервиса — в менеджере сервиса в карточке приложения и абонента.

Можно ли из облачной модели вернуться на локальную версию?

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

Кто отвечает за резервное копирование в облачной модели?

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

Почему в облачном сервисе нельзя доработать конфигурацию напрямую?

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

Что проверить в первую очередь после смены модели сервиса?

Сверьте оборотно-сальдовую ведомость до и после переноса, проверьте работу обменов с банком и ЭДО, убедитесь, что все пользователи могут войти и видят только свои данные.