1С: Синхронизация статусов расписания – как устроен обработчик

UnSpot Schedule Status Adapter — внешняя обработка 1С, которая переносит рабочие статусы сотрудников из «ЗУП» в расписание UnSpot: больничные, отпуска, командировки, отсутствия и удалённую работу. Статья описывает устройство обмена: кто кого вызывает, что именно уходит в UnSpot и что остаётся в 1С, где хранятся токен и кэш, что попадает в журнал и какие права нужны обработке. Её можно передать службе информационной безопасности и администраторам 1С при согласовании интеграции. Порядок подключения — в статье 1С: Синхронизация статусов расписания – настройка интеграции, разбор скрипта выбора данных — в статье 1С: Синхронизация статусов расписания – как устроен скрипт. Обработка дополняет синхронизацию пользователей из 1С: та управляет карточками сотрудников и оргструктурой, эта — статусами в расписании.

Кратко

• Обмен односторонний и по инициативе 1С: на каждый статус обработка отправляет один запрос POST в External API UnSpot «Импорт расписания сотрудника».
• В UnSpot уходят только email сотрудника, дата и статус. Имена, должности, сведения о документах остаются в 1С.
• Отправленные статусы запоминаются в кэше в базе 1С, поэтому повторно уходит только изменившееся.
• Настройки, токен и кэш хранятся в справочнике «Файлы», ход запуска — в журнале регистрации.
• Незнакомое слово — загляните в раздел Термины статьи-обзора.

Важно для службы безопасности

• Токен хранится в базе 1С без шифрования и попадает в резервные копии.
• Безопасный режим выключен. Скрипт из настроек выполняется с правами сеанса синхронизации.
• Сертификат сервера UnSpot обработка не проверяет — трафик шифруется, но подлинность сервера не подтверждается.
• Журнал регистрации накапливает рабочие email и сведения об отсутствиях сотрудников.
• Сброс статуса на рабочий день снимает личные брони столов — см. Правила и ограничения.

Как работает обработка

Обработка состоит из двух частей. Движок синхронизации — код самой обработки (модуль объекта): он отправляет статусы в UnSpot по HTTPS, ведёт кэш уже отправленных статусов и пишет подробный журнал. Скрипт выбора данных — код на встроенном языке 1С, который собирает из информационной базы список сотрудников и их статусы по датам. Для конфигурации «ЗУП 3.1» скрипт встроен в обработку и не требует настройки; для нестандартных конфигураций его можно заменить собственным — см. 1С: Собственный скрипт – настройка интеграции.

При каждом запуске обработка выбирает действующих сотрудников с заполненным email; определяет статус каждого сотрудника на каждый день в периоде от −45 до +45 дней от текущей даты (по данным учёта рабочего времени ЗУП: графики, табели, документы отклонений); сравнивает результат с кэшем и отправляет в UnSpot только новые и изменившиеся статусы — по одному запросу на статус, с паузой в 1 секунду. Статусы передаются через External API «Импорт расписания сотрудника», сотрудники сопоставляются по email.

Дни, когда сотрудник работает в обычном режиме, тоже синхронизируются: для них обработка отправляет сброс статуса. Так статус «Отпуск» исчезает из расписания, когда в 1С отпуск закончился или был отменён.

Проверочный запуск устроен так же, но период сокращается до текущего дня, и отправляется один статус (встроенный скрипт выбирает в проверке одну дату; при нескольких датах отправляется по одному статусу на каждую дату). Он запускается кнопкой «Сохранить и проверить» на форме настроек и описан в статье о настройке.

Направление и инициатор обмена

Обмен односторонний: инициатор всегда 1С. Обработка сама открывает исходящее соединение к UnSpot и отправляет запросы; UnSpot к информационной базе не обращается.

Протокол, адрес и шифрование

Аутентификация одна: заголовок Authorization со схемой Bearer и токеном External API. Взаимный TLS, Basic-аутентификация, ключ в строке запроса и получение токена отдельным запросом в этой интеграции не используются.

Что передаётся в UnSpot

Обработка отправляет по одному запросу на каждый статус каждого сотрудника на каждую дату. Обработка задаёт запросу два заголовка — Authorization: Bearer <токен> и Content-Type: application/json (служебные заголовки вроде Host и Content-Length добавляет платформа) — и тело из пяти полей. Других полей в теле нет.

Поля запроса

Итого в UnSpot уходит связка email — дата — статус. Ни идентификаторы 1С, ни имя сотрудника, ни название кадрового документа в запрос не попадают.

Какие статусы передаются

Статус определяется по буквенному коду вида учёта рабочего времени ЗУП (если у вида нет собственного кода — по коду его основного времени). Коды передаются в UnSpot так:

Пример тела запроса для отпуска:

POST /api/external/v1/user-schedule
Authorization: Bearer <токен>
Content-Type: application/json

{
  "userEmail": "employee@company.ru",
  "date": "2026-07-28",
  "statusType": "NOT_WORKING",
  "statusName": "Отпуск",
  "statusCode": "ОТ"
}

POST /api/external/v1/user-schedule
Authorization: Bearer <токен>
Content-Type: application/json

{
  "userEmail": "employee@company.ru",
  "date": "2026-07-28",
  "statusType": "NOT_WORKING",
  "statusName": "Отпуск",
  "statusCode": "ОТ"
}

Цвет плашки статуса в расписании назначает UnSpot автоматически; источником таких изменений UnSpot записывает External API. Подробное описание эндпоинта — в справочнике External API: обновление статуса в расписании.

Что читается в 1С, но не передаётся

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

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

Что не передаётся

• Пароли и учётные данные сотрудников — обработка их не читает и не отправляет.
• ФИО, должность, подразделение, табельный номер — остаются в 1С.
• Телефон, фотография, адрес, дата рождения, паспортные и иные персональные данные — встроенный скрипт их не запрашивает: их нет ни в одном его запросе к информационной базе.
• Основание отсутствия — номер, вид и содержание кадрового документа, номер листка нетрудоспособности, сведения о состоянии здоровья. В UnSpot уходит только обобщённый статус вида «Больничный» без подробностей.
• Данные из UnSpot в 1С — брони, встречи, расписание и события обратно не загружаются: ответ сервера в информационную базу не записывается.
• Пользователи, подразделения и права — обработка их не создаёт и не изменяет; этим занимается отдельная синхронизация пользователей.
• Данные другим адресатам — единственный получатель запросов задан в поле «UnSpot API URL».

Что учитывать. Перечень выше относится к встроенному скрипту для «ЗУП 3.1». Собственный скрипт для нестандартной конфигурации читает из базы то, что в нём написано, но в UnSpot из него всё равно уходят только пять полей запроса.

Где хранятся токен и настройки

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

Значение упаковано в хранилище значения со сжатием, но не зашифровано: сжатие не является средством защиты. Что из этого следует для доступа к токену:

• токен доступен любому пользователю 1С, у которого есть право на чтение справочника «Файлы» и на открытие формы настроек обработки;
• токен попадает в резервные копии информационной базы и в её выгрузки (dt) в том же открытом виде;
• в форме настроек поле «Токен доступа» — обычное текстовое: значение видно на экране целиком и не маскируется;
• автором служебных файлов записывается пользователь 1С, от имени которого выполнялось сохранение настроек или синхронизация.

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

В журнал регистрации 1С токен не пишется: логируется тело запроса, а заголовки в журнал не попадают.

Что кэшируется и где

Каждый успешно отправленный статус (ответ 200) запоминается в кэше. Кэш — тоже служебные файлы в справочнике «Файлы», папка UnSpotScheduleStatus, хранение — внутри информационной базы. Файлов два вида: один индексный, со списком актуальных файлов кэша, и по одному файлу на каждую дату периода синхронизации.

Что пишется в журнал регистрации

Обработка ведёт подробный журнал в штатном журнале регистрации 1С — «Администрирование → Обслуживание → Журнал регистрации». Источник записей — UnSpotScheduleStatus#<дата>, где дата — день первого сохранения настроек; уровень — «Примечание». В журнал попадают:

• запуск и завершение синхронизации, режим запуска (проверочный или полный), а в полном запуске — номер версии кэша;
• период выборки и количество выбранных сотрудников с email — эти записи делает встроенный скрипт; собственный скрипт пишет только то, что в нём запрограммировано;
• полное тело каждого отправленного запроса в формате JSON — то есть рабочий email сотрудника, дата и статус;
• код состояния и тело ответа сервера UnSpot на каждый запрос;
• пропуски с указанием имени сотрудника и даты: статус найден в кэше (пишет движок); у сотрудника больше одного статуса на дату и вид учёта времени без соответствия статусу UnSpot (пишет встроенный скрипт);
• итог запуска — сколько статусов отправлено успешно.

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

Правила и ограничения

• Сопоставление по email. Статус получает пользователь UnSpot с тем же email, что у сотрудника в 1С (email передаётся в нижнем регистре). Архивные и деактивированные пользователи статусы не получают — сервер отвечает «User not found»
• Сотрудник есть в 1С, но не в UnSpot. Сервер возвращает ошибку 400, обработка записывает её в журнал и продолжает работу. Ошибка не кэшируется — когда пользователь появится в UnSpot, его статусы передадутся при следующем запуске автоматически
• Один статус на день. В UnSpot у сотрудника один статус на дату. Если в 1С на день приходится несколько разных отметок (например, полдня отпуска и полдня работы), обработка пропускает этот день для сотрудника и фиксирует это в журнале
• Один сотрудник на физлицо. Если у физического лица несколько мест работы, берётся одно: приоритет у вида занятости (основное место работы, затем внутреннее совместительство, совместительство, подработка), при равенстве — у большего количества ставок; если и ставки равны, остаётся позиция, встретившаяся в выборке первой
• Снятие броней столов. Когда в UnSpot приходит статус графика на дату (из 1С или из любого другого источника), система освобождает рабочее место сотрудника на этот день: личные брони столов, начинающиеся в эту дату, удаляются, а уже начавшаяся бронь останавливается. Завершённые брони и брони, оформленные на гостя, не затрагиваются. Брони переговорных и парковочных мест не затрагиваются вообще. То же происходит при передаче рабочего дня (сброса статуса): по текущему коду сервера личные брони столов, начинающиеся в эту дату, освобождаются независимо от того, был ли на эту дату статус
• Неизвестные виды времени. Вид учёта времени без соответствия в таблице выше и без признака «рабочее время» пропускается; для видов с буквенным кодом это фиксируется в журнале регистрации
• Ограничение частоты. Сервер принимает не более 1 запроса в секунду на токен — обработка соблюдает лимит паузой в секунду между запросами. Паузу делает процедура ВызватьПаузу, которой в самой обработке нет: её должна предоставлять конфигурация. Без неё модуль обработки не скомпилируется и обработка не запустится вовсе
• Только статусы. Обработка не создаёт и не изменяет пользователей, подразделения или права — за это отвечает синхронизация пользователей. Настраивайте её первой
• Ошибка ответа сервера. Запрос с ответом не 200 не переотправляется: обработка пишет код и тело ответа в журнал и переходит к следующему статусу. В кэш попадают только успешные отправки, поэтому неудавшийся статус уйдёт заново при следующем запуске
• Ошибка соединения. Если сервер UnSpot недоступен или не ответил за 60 секунд, запуск прерывается целиком. Что уже записано в кэш, повторно не отправляется; остальное уйдёт при следующем запуске
• Один источник статусов. В периоде ±45 дней 1С считается источником статусов: статус отправляется при первой отправке за дату и каждый раз, когда значение в 1С изменилось, и заменяет статус в расписании UnSpot, в том числе поставленный вручную. Если значение в 1С не менялось, обработка его повторно не отправляет — ручная правка расписания сохранится до сброса кэша или изменения в 1С
• Параллельный запуск. Пока фоновое задание обработки активно, второй запуск не стартует: «Синхронизация уже выполняется, подождите завершения»

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

Требования к сети и правам в 1С

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

Принцип минимальных привилегий здесь упирается в одну особенность. Поле «Код выбора данных для синхронизации» в режиме «Нестандартная конфигурация» хранит произвольный скрипт на встроенном языке 1С, и обработка выполняет его при каждом запуске без безопасного режима. Это значит, что тот, кто может изменить настройки обработки, может выполнить в информационной базе произвольный код с правами пользователя, под которым идёт синхронизация. Право на изменение настроек этой обработки приравнивайте к праву на изменение кода, а для регламентного задания заведите отдельного пользователя 1С с перечисленными выше правами вместо администратора с полными правами.

Связанные статьи

• 1С: Синхронизация статусов расписания – настройка интеграции — подключение, поля формы и возможные ошибки.
• 1С: Синхронизация статусов расписания – как устроен скрипт — разбор встроенного скрипта по блокам.
• 1С: Собственный скрипт – настройка интеграции — как написать скрипт для нестандартной конфигурации.
• 1С: Обзор интеграции — какие бывают интеграции с 1С и с чего начать.
• 1С: Синхронизация пользователей – как устроен обработчик — отдельная обработка для пользователей и оргструктуры.
• External API: обновление статуса в расписании — описание эндпоинта.
• Управление рабочими статусами в расписании — настройка статусов в UnSpot.
• Статусы в расписании: простановка и влияние на брони — как статус влияет на брони.