Когда в CRM и смарт-процессах важно понимать, кто, когда и на что поменял значение, бизнес быстро упирается в потребность «аудита» данных. Это особенно заметно в KPI-полях, статусных строках, контрольных признаках и любых полях, по которым строится отчетность.
Проблема пользователя
На коробочном портале Битрикс24 пользователь настроил приложение на отслеживание нескольких полей в смарт-процессе. На очередном поле возникла ошибка вида «Некорректный код поля (internal error)». Причина оказалась не в типе поля (оно было обычной строкой), а в том, что поле было создано с корректным системным кодом, а затем вручную переименовано в «красивый» код — без сохранения обязательной части идентификатора.
Почему стандартный подход ломается
В Битрикс24 у пользовательских полей в смарт-процессах есть ожидаемый системный шаблон. При создании поле получает код вида:
UF_CRM_ХХ_1764235181626
Где «ХХ» — это идентификатор смарт-процесса. Когда код «чистят» до произвольного вида вроде UF_CRM_KPI_NEW, из него исчезает «ХХ». Для части решений (включая те, что создают связанные служебные поля или строят привязки по схеме сущности) это критично: приложение больше не может однозначно понять, к какому смарту относится поле — отсюда и «некорректный код».
Решение: не менять код поля — или менять по правилам
Самый надежный вариант — не переименовывать код поля после создания и работать с тем, что дал Битрикс24. Это избавляет от сюрпризов при интеграциях, роботах, активити и приложениях, которые завязаны на системные шаблоны.
Если же бизнес-логика требует «читаемых» кодов, переименование допустимо, но по правилам:
- Сохраняйте префикс и идентификатор смарт-процесса.
- Правильная логика переименования — не «переписать все», а заменить только хвост. Например:
- UF_CRM_ХХ_KPI_NEW
- (где «ХХ» — тот же идентификатор смарт-процесса, который был в исходном коде).
- Проверьте код поля-дубля (служебного поля), которое создает решение для истории.
- После настройки отслеживания обычно появляется дополнительное поле, куда пишется «история». Его код тоже должен соответствовать ожидаемому шаблону. В рабочем варианте это выглядит так:
- UF_CRM_ХХ_KPI_NEW_DFS_HISTORY
- Если суффикс или середина отличаются — их важно привести к ожидаемому виду, иначе история может не писаться или настройка будет падать ошибкой.
Практически это означает: приложение «История изменения полей» корректно работает, когда в кодах сохраняется системная часть UF_CRM_ХХ_, а «человекочитаемость» достигается только за счет аккуратного хвоста после идентификатора сущности.
Пример логики подхода (в обычном тексте)
Было (системное): UF_CRM_ХХ_1764235181626
Хотим красиво: UF_CRM_ХХ_KPI_NEW
Проверяем служебное поле истории: UF_CRM_ХХ_KPI_NEW_DFS_HISTORY
Результат
После сохранения идентификатора смарт-процесса в коде поле снова становится «валидным» для схемы сущностей, настройка отслеживания проходит без internal error, а история изменений записывается стабильно — без необходимости пересоздавать поля и переносить данные вручную.
Вывод
Если вам нужна история изменений в CRM/смарт-процессах, главный принцип простой: не ломайте системный шаблон кода поля. А если переименование неизбежно — сохраняйте UF_CRM_ХХ_ и обязательно контролируйте код служебного поля истории. В таких сценариях приложение «История изменения полей» особенно полезно: оно закрывает задачу аудита, но ожидает от портала корректной структуры идентификаторов — ровно той, которую задает сам Битрикс24.
