Вернуться к статьям Новая дата в карточке ещё не означает, что заказчик и подрядчик согласовали перенос срока. Исполнитель мог оценить оставшуюся работу, клиент — изменить свой календарь, а синхронизация просто передала последнее поддерживаемое изменение. Чтобы автоматический обмен не заменял деловую договорённость, сроку нужен владелец и понятный порядок изменения.
«Межпортальные задачи и коллабы» передаёт поддерживаемые поля в разрешённых направлениях. Решение о переносе принимают люди. Ниже — регламент, который можно применять при двух самостоятельных порталах Битрикс24.
Назначьте владельца срока
Определите, кто вправе изменить согласованную дату после обсуждения. Это может быть руководитель проекта клиента или менеджер подрядчика — важно, чтобы правило было одинаково понятно обеим сторонам.
Владелец срока не обязан выполнять всю работу. Его задача — проверить влияние переноса, получить решение уполномоченных участников и обновить поле. Остальные сотрудники могут предложить изменение новым сообщением, не редактируя дату параллельно.
Что должно быть в запросе на перенос
| Сведения | Зачем нужны |
|---|---|
| Текущий срок | Чтобы стороны обсуждали одну исходную договорённость |
| Предлагаемый срок | Чтобы было что согласовать |
| Причина | Чтобы отличить нехватку материалов от изменения объёма |
| Влияние | Чтобы проверить зависимые работы и ожидания клиента |
| Варианты | Чтобы выбрать перенос, сокращение объёма или поэтапную передачу |
Пример сообщения: «Для завершения проверки нужны исходные материалы. Предлагаем перенести передачу с 12 на 14 число. Если сохранить прежнюю дату, можем передать только уже проверенную часть. Просим подтвердить выбранный вариант». Это условный шаблон, который нужно дополнить реальными обстоятельствами.
Последовательность действий
- Инициатор описывает изменение новым сообщением в общей задаче.
- Уполномоченная сторона подтверждает дату либо предлагает другой вариант.
- Владелец срока фиксирует решение отдельной репликой и изменяет поле.
- Вторая сторона проверяет дату в своей карточке после обработки обмена.
- Руководители обновляют зависимые договорённости в своих процессах.
Последний шаг важен: перенос срока одной задачи не означает автоматического пересчёта всех внешних обязательств или графиков. Такие возможности нельзя приписывать приложению без отдельной настройки соответствующего процесса.
Проверьте направление передачи
Если срок меняет партнёр, а перенос изменений партнёр → клиент отключён, клиентская карточка не обязана получить новую дату. Перед запуском регламента администраторы должны убедиться, что выбранная организационная схема соответствует направлениям приложения.
Разрешение передавать сообщения задаётся отдельно. Поэтому возможна ситуация, когда обсуждение дошло, а изменение поля не разрешено, или наоборот. Принципы настройки разобраны в статье об односторонней и двусторонней синхронизации.
Если обе стороны уже изменили дату
Остановите параллельное редактирование, определите согласованный срок и внесите его один раз с разрешённой стороны. Поддерживаемые изменения могут заменять друг друга; приложение не понимает, какая реплика была последним деловым соглашением.
Не пытайтесь разрешить спор быстрым повторным изменением даты. Такая гонка создаёт новые события и усложняет проверку. Сначала договорённость, затем одно действие и проверка второй карточки.
Срочный перенос и разные часовые пояса
Для срочных случаев заранее определите контакт и порядок решения. Если дата включает время, укажите в сообщении часовой пояс. Формулировка «до вечера» недостаточна, когда команды работают в разных регионах.
Синхронизация не гарантирует мгновенной доставки, поэтому критичное решение должно быть подтверждено участником процесса, а не только фактом редактирования поля. После этого проверьте обе карточки.
Начните с короткого правила: кто предлагает, кто согласует и кто меняет дату. С «Межпортальными задачами и коллабами» перенос поддерживаемых данных становится частью этого правила, а ответственность за решение остаётся понятной.