Заметки
Как учитывать рабочее время в отчётах
Как учитывать рабочее время в отчётах: Календарь, график, выходные.
Как учитывать рабочее время в отчётах. Основной фокус: Календарь, график, выходные.
Задача
Понять, какой отчёт можно собрать штатно, а где нужна собственная витрина или приложение.
Задача — как учитывать рабочее время в отчётах. Календарь, график, выходные.
Главное — не искать один универсальный метод, а сначала определить сущность, права и слой API, через который выполняется действие.
Как это устроено
Отчёты зависят от источника данных. CRM-список, BI-конструктор, REST-выгрузка и D7-запросы дают разный уровень детализации и разные ограничения по правам.
Разложите сценарий на уровни: где появляется исходное значение, какой метод его меняет, кто выполняет действие и какое событие должно сработать после изменения.
Если сценарий проверяется под администратором, отдельно повторите его под обычным пользователем. Для прав, CRM, задач, Диска и приложений это часто даёт другой результат.
Рабочий подход
Сначала сформулируйте вопрос отчёта и источник данных. Если нужны исторические состояния, заранее пишите снимки изменений, потому что текущее поле карточки не хранит всю историю.
Сделайте минимальный тест на одной сущности, сохраните входные данные и ответ метода, а затем расширяйте решение на массовый сценарий.
На коробке удобнее добавлять временное логирование рядом с местом выполнения кода, а в облаке — сохранять входящие и исходящие REST-запросы в свой журнал интеграции.
Частые ошибки
Стандартный отчёт часто показывает не ошибку, а ограничение модели данных: нет нужного среза, нет истории или нет прав на часть записей.
- Проверять сценарий только под администратором и не видеть проблему прав обычного пользователя.
- Смешивать ID разных сущностей: задачу, файл Диска, CRM-дело, товарную строку или пользователя.
- Не логировать фактический запрос и ответ, из-за чего ошибка выглядит случайной.