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

  • Обновлено
  • Чтение ≈ 2 минуты

Краткий ответ

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

В этой статье
  1. Что именно происходит
  2. Как отличить причины
  3. Пошаговая диагностика и устранение
  4. Проверка результата
  5. Когда обращаться к администратору

#Что именно происходит

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

#Как отличить причины

Возможная причинаКак узнатьЧто делать
Робот рассчитывает срок в неподходящей временной зонеУсловия расписания и время аккаунта могут различатьсяНовые задачи сдвинуты, старые отображаются верноСверить расчёт правила
Внешняя система передаёт UTC как местное времяВ интеграции неверно преобразованы временные отметкиСдвиг постоянный и равен нескольким часамИсправить преобразование
Задача создаётся от времени перехода, а не от местного часаОтносительный интервал и фиксированное время не одно и то жеСрок меняется с моментом срабатыванияУточнить тип условия

#Пошаговая диагностика и устранение

  1. Зафиксируйте учебный примерСоздайте одну тестовую сделку без реальных клиентов, запишите время запуска робота, часовой пояс сотрудника и созданный срок задачи. Старые рабочие задачи не изменяйте: сначала отличите ошибку нового расчёта от смены отображения.
  2. Сверьте время у двух участниковОткройте настройки профиля с разрешённой информацией о часовом поясе и посмотрите ту же тестовую задачу у двух сотрудников. Если различается только отображаемое время, разбирать надо настройки просмотра; если в задаче реально другой срок — правило создания.
  3. Проверьте условие создания задачиАдминистратор в «Сделки» → «Настроить» найдёт этап с действием «Создать задачу». Сравните запланированный срок: фиксированное время, задержка после события или ближайшая дата могут рассчитываться по-разному.
  4. Проверьте, где выполняется действиеЕсли задача создаётся внешней интеграцией, разработчик сверит полученный timestamp с местным временем по известной временной зоне. Не вручную прибавляйте три часа ко всем задачам: сезонный переход на летнее время делает такое исправление ошибочным.
  5. Запустите управляемый тестУстановите на тестовом правиле явно согласованный интервал до срока, например один час, и создайте одну учебную сделку. Сравните дату выполнения с текущим временем; не запускайте массовое создание задач для всей воронки.
  6. Исправьте источник расчётаЕсли ошибается робот, согласуйте правильные параметры срока. Если внешняя система, передавайте временные отметки с зоной или UTC и преобразуйте только при отображении. Сохраните исходные значения для отката в случае расхождения.
  7. Проверьте результат после повторного входаСоздайте ещё одну тестовую задачу, перезапустите отображение интерфейса и проверьте срок у адресата. Успех — уведомление запланировано на согласованный момент, а существующие рабочие задачи не получили массовый сдвиг.

#Проверка результата

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

#Когда обращаться к администратору

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

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.