Синхронизация статусов сотрудников из 1С: как устроен обмен
UnSpot Schedule Status Adapter — внешняя обработка 1С, которая ежедневно переносит рабочие статусы сотрудников из 1С:ЗУП в расписание UnSpot: больничные, отпуска, командировки, отсутствия и удалённую работу. Статья описывает устройство обмена: кто кого вызывает, что именно уходит в UnSpot и что остаётся в 1С, где хранятся токен и кэш, что попадает в журнал. Она адресована службе информационной безопасности и администраторам 1С — по ней согласовывают использование интеграции. Порядок подключения описан в статье Настройка синхронизации статусов из 1С (Schedule Status Adapter). Обработка дополняет синхронизацию пользователей из 1С (UnSpot SCIM Adapter): та управляет карточками сотрудников и оргструктурой, а эта — ежедневными статусами в расписании.
Как работает обработка
Обработка состоит из двух частей. Движок синхронизации — скомпилированный код обработки: он отправляет статусы в UnSpot по HTTPS, ведёт кэш уже отправленных статусов и пишет подробный журнал. Код выбора данных — скрипт на встроенном языке 1С, который собирает из информационной базы список сотрудников и их статусы по датам. Для типовой конфигурации ЗУП 3.1 скрипт встроен в обработку и не требует настройки; для нестандартных конфигураций его можно заменить собственным.
При каждом запуске обработка: выбирает действующих сотрудников с заполненным email; определяет статус каждого сотрудника на каждый день в окне ±45 дней от текущей даты (по данным учёта рабочего времени ЗУП — графики, табели, документы отклонений); сравнивает результат с кэшем и отправляет в UnSpot только новые и изменившиеся статусы — по одному запросу на статус, с паузой в 1 секунду. Статусы передаются через External API «Импорт расписания сотрудника» — сотрудники сопоставляются по email.
Дни, когда сотрудник работает в обычном режиме, тоже синхронизируются: для них обработка отправляет сброс статуса. Так статус «Отпуск» автоматически исчезает из расписания, когда в 1С отпуск закончился или был отменён. В пределах окна синхронизации (±45 дней) статусы в расписании UnSpot приводятся в соответствие с данными 1С — на этот период источником статусов выступает 1С.
Проверочный запуск устроен так же, но окно сокращается до текущего дня и отправляется ровно один статус: это делается кнопкой на форме настроек и описано в статье о настройке.
Направление и инициатор обмена
Обмен односторонний: инициатор всегда 1С. Обработка сама открывает исходящее соединение к UnSpot и отправляет запросы; UnSpot к информационной базе не обращается.
| Вопрос | Как в этой интеграции |
|---|---|
| Кто инициирует обмен | Всегда 1С. Обработка открывает исходящее соединение к адресу из поля «UnSpot API URL» и отправляет запросы методом POST |
| Есть ли входящие подключения к контуру клиента | Нет. Обработка не публикует ни веб-сервисов, ни HTTPS-сервисов; UnSpot не вызывает 1С ни по расписанию, ни по событию. Публиковать информационную базу в интернет для этой интеграции не нужно |
| Есть ли обратный поток | Нет. Ответ сервера используется двумя способами: записывается в журнал регистрации 1С и показывается на экране при проверочном запуске. В данные информационной базы ответ не попадает |
| Что запускает обмен | Регламентное (фоновое) задание 1С либо администратор вручную кнопкой на форме обработки. Обработка выполняется в фоновом задании на сервере 1С, а не в браузере или на рабочей станции |
| Сколько адресатов | Один. Единственный получатель данных — адрес, введённый в настройках обработки. Никаких других доменов, телеметрии и внешних служб обработка не вызывает |
Протокол, адрес и шифрование
| Параметр | Значение |
|---|---|
| Протокол | HTTPS. Метод — POST, тело — JSON в UTF-8, без метки порядка байтов |
| Порт | 443. Порт определяется схемой адреса и в настройках не задаётся; нестандартный порт в строке адреса не поддерживается |
| Адрес | Ровно то значение, которое администратор ввёл в поле «UnSpot API URL», — обычно https://<домен>/api/external/v1/user-schedule. Обработка разбирает адрес на узел и путь и обращается только по нему |
| Шифрование | Защищённое соединение включается, когда адрес начинается со схемы https. Если в поле указать адрес без буквы s в схеме, обработка откроет незашифрованное соединение на порт 80, и токен уйдёт в открытом виде. Карточка в UnSpot всегда выдаёт https-адрес — вводите его без изменений |
| Проверка сертификата | Обработка не задаёт собственное хранилище доверенных сертификатов и не отключает проверку явно: действует поведение платформы 1С по умолчанию и её централизованные настройки |
| Таймаут | 60 секунд на запрос |
| Прокси | В обработке не настраивается — параметр соединения оставлен пустым |
Аутентификация одна: заголовок Authorization со схемой Bearer и токеном External API. Взаимный TLS, Basic-аутентификация, ключ в строке запроса и получение токена отдельным запросом в этой интеграции не используются.
Что передаётся в UnSpot
Обработка отправляет по одному запросу на каждый статус каждого сотрудника на каждую дату. У запроса два заголовка — Authorization: Bearer <токен> и Content-Type: application/json — и тело из пяти полей. Других полей в теле нет.
Поля запроса
| Поле | Что содержит | Откуда берётся в 1С | Когда заполняется |
|---|---|---|---|
| userEmail | Рабочий адрес электронной почты сотрудника, приведённый к нижнему регистру. Единственные персональные данные, которые уходят в UnSpot | Реквизит «EMailПредставление» сотрудника организации | Всегда |
| date | Дата, на которую ставится статус, в формате гггг-ММ-дд | Дата из данных учёта рабочего времени ЗУП | Всегда |
| statusType | Тип статуса: NOT_WORKING или REMOTE_WORK | Вычисляется по буквенному коду вида учёта рабочего времени | Пусто (null) для рабочего дня — это и есть сброс статуса |
| statusName | Название статуса: «Больничный», «Отпуск», «Командировка», «Отсутствие», «Удаленная работа» | Фиксированный список внутри обработки, из 1С не берётся | Пусто (null) для рабочего дня |
| statusCode | Короткий код статуса: БЛ, ОТ, К, НН, Д | Фиксированный список внутри обработки, из 1С не берётся | Пусто (null) для рабочего дня |
Итого в UnSpot уходит связка «email — дата — статус». Ни идентификаторы 1С, ни имя сотрудника, ни название кадрового документа в запрос не попадают.
Какие статусы передаются
Статусы определяются по буквенным кодам видов учёта рабочего времени ЗУП (включая основное время вида) и передаются в UnSpot так:
| Ситуация в 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": "ОТ"
}Цвет плашки статуса в расписании назначает UnSpot автоматически; в отчётах такие изменения отображаются с местом действия «внешний API». Подробное описание эндпоинта — в справочнике External API: обновление статуса в расписании.
Что читается в 1С, но не передаётся
Встроенный запрос к ЗУП забирает из информационной базы больше реквизитов, чем нужно для запроса. Они используются внутри 1С и в UnSpot не уходят:
- Фамилия и имя — складываются в имя сотрудника и подставляются только в сообщения журнала регистрации 1С;
- подразделение, должность, табельный номер — читаются запросом, но обработкой не используются и никуда не отправляются;
- вид занятости, количество ставок, дата приёма — нужны, чтобы у совместителя выбрать одно место работы;
- идентификатор физического лица — служебный ключ, по которому статусы связываются с сотрудником внутри обработки и кэша.
Что не передаётся
- Пароли и учётные данные сотрудников — обработка их не читает и не отправляет.
- ФИО, должность, подразделение, табельный номер — остаются в 1С, см. раздел выше.
- Телефон, фотография, адрес, дата рождения, паспортные и иные персональные данные — обработка их не запрашивает вовсе: их нет ни в одном её запросе к информационной базе.
- Основание отсутствия — номер, вид и содержание кадрового документа, номер листка нетрудоспособности, сведения о состоянии здоровья. В UnSpot уходит только обобщённый статус вида «Больничный» без каких-либо подробностей.
- Данные из UnSpot в 1С — брони, встречи, расписание и события обратно не загружаются: ответ сервера в информационную базу не записывается.
- Пользователи, отделы и права — обработка их не создаёт и не изменяет; этим занимается отдельная синхронизация пользователей.
- Данные другим адресатам — единственный получатель запросов задан в поле «UnSpot API URL».
Где хранятся токен и настройки
Все настройки обработки — адрес API, токен доступа, выбранная конфигурация, пользовательский код выбора данных и служебный номер версии кэша — хранятся внутри информационной базы 1С. Это служебный файл с именем UnSpotScheduleStatusSettings в справочнике «Файлы», в папке UnSpotScheduleStatus, с типом хранения «в информационной базе». Файлов на диске сервера, записей в реестре и переменных окружения обработка не создаёт.
Значение упаковано в хранилище значения со сжатием, но не зашифровано: сжатие не является средством защиты. Практические следствия для доступа к токену:
- токен доступен любому пользователю 1С, у которого есть право на чтение справочника «Файлы» и на открытие формы настроек обработки;
- токен попадает в резервные копии информационной базы и в её выгрузки (dt) в том же открытом виде;
- в форме настроек поле «Токен доступа» — обычное текстовое: значение видно на экране целиком и не маскируется;
- автором служебных файлов записывается тот пользователь 1С, от имени которого выполнялось сохранение настроек или синхронизация.
Что с этим делать: ограничьте штатными средствами 1С круг пользователей, которым доступны дополнительные обработки и справочник «Файлы», и защитите резервные копии базы. Токену задавайте срок действия при подключении карточки в UnSpot — доступно значение от 1 до 24 месяцев — и обновляйте его в настройках обработки после ротации. Сама обработка использует токен только для одного эндпоинта — импорта расписания сотрудника.
В журнал регистрации 1С токен не пишется: логируется тело запроса, а заголовки в журнал не попадают.
Что кэшируется и где
Каждый успешно отправленный статус (ответ 200) запоминается в кэше. Кэш — тоже служебные файлы в справочнике «Файлы», папка UnSpotScheduleStatus, хранение — внутри информационной базы. Файлов два вида: один индексный, со списком актуальных файлов кэша, и по одному файлу на каждую дату окна синхронизации.
| Вопрос о кэше | Ответ |
|---|---|
| Что лежит внутри | Соответствие «идентификатор физического лица → числовой код статуса». Ни email, ни ФИО, ни название статуса, ни данные UnSpot в кэш не попадают |
| Где хранится | В информационной базе 1С, в справочнике «Файлы» (папка UnSpotScheduleStatus). Внешних файлов и временных каталогов на диске обработка не создаёт |
| Зачем нужен | При следующем запуске статус отправляется повторно только если он изменился — поэтому регулярные запуски проходят быстро и не нагружают API |
| Срок жизни | Временем не ограничен. Файлы дат, вышедших из окна ±45 дней, удаляются на очередном запуске |
| Как сбросить | Любым сохранением настроек: номер версии кэша увеличивается, и следующий запуск проходит полностью, а файлы прошлой версии удаляются. Файлы кэша можно и удалить вручную из справочника «Файлы» — обработка создаст их заново |
| Проверочный запуск | Кэш не читает и не изменяет |
Что пишется в журнал регистрации
Обработка ведёт подробный журнал в штатном журнале регистрации 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 запроса в секунду на токен — обработка соблюдает лимит автоматически (пауза между запросами). |
| Только статусы | Обработка не создаёт и не изменяет пользователей, отделы или права — за это отвечает синхронизация пользователей (SCIM). Настраивайте её первой. |
| Поведение при ошибке | Неуспешный запрос в рамках запуска не переотправляется: обработка пишет код и тело ответа в журнал и переходит к следующему статусу. В кэш попадают только успешные отправки, поэтому неудавшийся статус уйдёт заново при следующем запуске. |
| Один источник статусов | В окне ±45 дней статусы в расписании UnSpot приводятся к данным 1С. Изменения, внесённые в расписание вручную или из другого источника, будут перезаписаны на очередном запуске, если в 1С на эту дату есть свой статус. |
Что делать с каждой из ошибок — в разделе «Возможные ошибки» статьи Настройка синхронизации статусов из 1С (Schedule Status Adapter).
Требования к сети и правам в 1С
Поскольку инициатор обмена всегда 1С, входящих правил на межсетевом экране интеграция не требует.
| Что нужно | Подробности |
|---|---|
| Исходящее правило | Одно: с сервера 1С (точнее, с машины, где выполняется фоновое задание) к домену вашего рабочего пространства UnSpot, TCP/443. Рабочим станциям сотрудников доступ не нужен |
| Входящие правила | Не нужны. UnSpot не устанавливает соединений с контуром клиента, и публиковать информационную базу наружу не требуется |
| Прокси | В обработке не настраивается. Если исходящий трафик идёт через прокси, вопрос решается настройками платформы 1С и сети, а не обработкой |
| Права на установку | Регистрация внешней обработки в разделе «Дополнительные отчеты и обработки» — полные права либо право на работу с дополнительными обработками |
| Безопасный режим | Обработка регистрируется с отключённым безопасным режимом: платформа не ограничивает ей доступ к внешним ресурсам. Без этого обработка не смогла бы обратиться к сети |
| Права на данные | В информационной базе обработке нужны: • чтение кадровых данных и данных учёта рабочего времени ЗУП; • чтение регистра сведений «Дистанционная работа сотрудников»; • чтение и запись справочников «Файлы» и «Папки файлов»; • запуск фоновых заданий |
| Учётная запись | Обработка работает от имени того пользователя 1С, который запустил команду или под которым выполняется регламентное задание. Отдельная учётная запись операционной системы и отдельная служба не создаются |
Принцип минимальных привилегий здесь упирается в одну особенность. Поле «Код выбора данных» в режиме «Нестандартная конфигурация» хранит произвольный скрипт на встроенном языке 1С, и обработка выполняет его при каждом запуске без безопасного режима. Это значит, что тот, кто может изменить настройки обработки, может выполнить в информационной базе произвольный код с правами пользователя, под которым идёт синхронизация. Право на изменение настроек этой обработки приравнивайте к праву на изменение кода, а для регламентного задания заведите отдельного пользователя 1С с перечисленными выше правами вместо администратора с полными правами.
