Kimai для агентства: закрытие месяца и отчёт клиенту по согласованным часам

В конце месяца в Kimai лежит ровно столько часов, сколько люди успели записать. Это не то же самое, что сумма к оплате. Дизайнер потратил сорок минут на внутренний созвон, разработчик полдня разбирался в собственной ошибке, менеджер вёл проект и не выставляет это клиенту. Всё это работа, и всё это учтено. Но оплачиваемой записью становится только та, которую вы готовы показать клиенту и объяснить.

Закрытие месяца в агентстве — это не нажатие кнопки «Создать счёт». Это короткая цепочка решений: что мы записали, что из этого мы продаём, что клиент увидит и что после этого нельзя тихо переписать. Разберём эту цепочку по порядку, с небольшой ведомостью и с одной неприятной ситуацией: ошибка найдена уже после того, как период обработан.

Запись времени как адрес: клиент, проект, активность

Всё, что дальше попадёт в отчёт, начинается с одной строки в timesheet. По документации Kimai записи времени связываются с клиентом, проектом и активностью. Для закрытия месяца это важнее, чем кажется: три этих поля работают как почтовый адрес. Если адрес неточный, письмо дойдёт не туда, а часы окажутся в чужом разделе отчёта.

Полезно относиться к трём уровням как к трём разным вопросам:

• Клиент — кому мы предъявим отчёт.
• Проект — в рамках какой договорённости выполнялась работа: редизайн сайта, сопровождение, разовая доработка.
• Активность — какой тип работы это был: вёрстка, аналитика, управление, тестирование.

Типичная ошибка агентства — делать активности слишком «личными»: «разное», «задачи», «Петя». Тогда в отчёте для клиента нечего показать, кроме описаний, а описания пишутся на бегу. Хорошая схема активностей устроена от обратного: представьте, какие строки вы хотели бы видеть в ведомости клиента, и заведите активности под них. Не сорок штук, а столько, чтобы руководитель проекта мог за минуту понять, на что ушёл бюджет.

Второй момент — граница между клиентскими и внутренними проектами. Если внутренние часы (планёрки, обучение, разбор процессов) записываются в тот же проект клиента, вам придётся каждый месяц разбирать их вручную. Если для них заведён отдельный внутренний проект, часть работы отсеивается ещё до сверки. Это наше организационное решение, а не требование Kimai, но оно сильно сокращает объём спорного материала.

Таймер, который забыли остановить, и описание, которое ничего не говорит

Кимай умеет запускать и останавливать таймер, а также запускать запись повторно; такие операции описаны в документации по timesheet. Удобство у этого механизма обратная сторона: таймер, запущенный в пятницу вечером, может пережить выходные. Утром в понедельник вы видите запись на шестьдесят часов, и никто не помнит, что это было.

Поэтому первая проверка перед закрытием — не суммы, а аномалии. Я бы смотрела на три типа записей:

1. Незавершённые записи. Если таймер ещё идёт, у записи нет конечной точки, и считать её в отчёте нельзя. Сначала выясните у исполнителя, когда работа реально закончилась, и поправьте время вручную.
2. Подозрительно длинные записи. Не обязательно ошибочные, но требующие вопроса. Девять часов подряд без перерыва на одну активность — повод уточнить, а не повод молча верить.
3. Пустые и бессодержательные описания. «Работа над проектом» клиенту ничего не объясняет, а вам через полгода — тем более.

С описаниями удобно договориться о простом правиле: описание должно отвечать на вопрос «что изменилось в результате?» Сравните «правки по сайту» и «исправлена вёрстка карточки товара на мобильных». Вторая запись выдерживает вопрос клиента без звонка исполнителю. Первая — нет.

Здесь пригодится пакетное обновление выбранных записей: оно упомянуто среди документированных возможностей timesheet. Если выяснилось, что десяток записей попал в неправильную активность или нужно одинаково поменять признак, не нужно открывать каждую строку по отдельности. Но пакетные правки требуют аккуратности: прежде чем применять их к выбранному набору, убедитесь, что фильтр выбрал именно то, что вы имели в виду. Одна неверная галочка размножается на всю выборку.

Billable: работа учтена, но не продана

Теперь главное различие. По документации счета в Kimai формируются из данных timesheet, и в них попадают только billable-записи. Это значит, что признак billable — не косметика, а ворота. Всё, что за воротами, в счёт не попадёт, даже если лежит в том же проекте и в том же месяце.

Почему это удобно? Потому что учёт и продажа — разные вещи. Вы можете честно записывать всё, включая время на исправление собственных недочётов, согласование внутри команды или гарантийные доработки. Для управленческой картины это ценно: видно, сколько реально стоит проект. Но клиенту вы предъявляете только то, что согласовано как оплачиваемое.

Вот как может выглядеть небольшая ведомость по условному клиенту за месяц. Числа выдуманы для примера и показывают только логику разделения.

В этой таблице шесть строк и три разных судьбы. Четыре строки очевидны. Последняя — серая зона: работа была, она полезна, но неясно, входит ли она в договорённость. Пока клиент не ответил, держать её в billable опасно: она сразу уйдёт в счёт. Держать вне billable тоже неидеально, если вы потом забудете вернуть. Практичное решение — на время спора оставить запись невыставляемой и отметить в описании, что вопрос открыт; после ответа клиента перевести её в нужное состояние.

Итог по ведомости: оплачиваемых часов 20,5, невыставляемых 4,0, спорных 2,0. Эти три числа вместе дают общий объём работы месяца — 26,5 часа. Клиенту покажут первое число, а руководителю проекта нужны все три.

Согласование до документа, а не после

Самая частая ошибка закрытия месяца — сформировать счёт, отправить его и только потом услышать: «А почему здесь два часа аналитики? Мы это не заказывали». Теперь вы либо убеждаете клиента, либо переделываете документ. Оба пути хуже, чем короткий разговор до формирования.

Важная оговорка: согласование часов — это наш процесс, а не функция Kimai. Программа не знает, прочитал ли клиент ведомость и согласился ли он. Поэтому порядок действий строим сами:

1. Внутренняя сверка: руководитель проекта проходит по записям, исправляет аномалии, проверяет описания и признак billable.
2. Предварительная ведомость клиенту: таблица, подобная приведённой выше, но только с теми строками, которые вы собираетесь предъявить, плюс отдельный короткий список вопросов по спорным часам.
3. Фиксация ответа: письмо или комментарий в задаче, где клиент подтвердил состав. Это ваш документ, не системный.
4. Корректировка признаков по ответу и только потом формирование счёта или выгрузки.

Зачем отдельно говорить, что невыставляемую работу клиенту показывать не обязательно? Затем, что показывать её иногда полезно. Строка «исправление ошибки в расчёте скидки, 2,5 часа, не включено в счёт» говорит клиенту, что вы не прячете проблемы и не берёте за них деньги. Это решение о тоне отношений, а не о технике. Но оно должно быть осознанным: если вы показываете такие строки, показывайте их единообразно из месяца в месяц.

Export flag: почему обработанное исчезает из следующего счёта

Теперь о механизме, который защищает от повторного выставления. По документации счета и экспорты используют общий export flag. После обработки записи получают этот признак; обычные пользователи уже не могут их редактировать, а в последующие счета и выгрузки они по умолчанию не попадают.

Из этого следует несколько практических выводов.

Первый. Флаг общий для счетов и выгрузок. Если бухгалтер или менеджер сделал «просто выгрузку» для просмотра и при этом записи были помечены как обработанные, то счёт по этим же записям уже не получит их по умолчанию. Поэтому перед любым действием, которое отмечает записи, стоит понять, это черновой просмотр или окончательная обработка. Для предварительной сверки лучше смотреть отчёты и фильтры в интерфейсе, а не пользоваться действиями, которые помечают записи.

Второй. Export flag означает «обработано», а не «клиент согласился». Это принципиальная граница. Система знает, что запись уже ушла в документ или экспорт; о том, как к этому отнёсся клиент, она не знает. Согласие по-прежнему остаётся вашим процессом из предыдущего раздела. Не стоит читать флаг как подпись заказчика.

Третий. Блокировка редактирования для обычных пользователей — это защита от случайной правки. Исполнитель не сможет в середине следующего месяца «подтянуть» уже выставленную запись и изменить её часы так, что отчёт перестанет совпадать со счётом. Для агентства это ценное свойство: документ и источник не расходятся тихо.

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

Обычный счёт и электронное выставление — разные дороги

Для формирования счёта в Kimai нужен шаблон; это условие названо в документации по счетам. Шаблон определяет, как данные timesheet превращаются в документ: какие поля, какая группировка, как выглядят строки. От него зависит, будет ли клиент видеть активности по отдельности или одну итоговую строку.

Электронное выставление счёта — отдельная тема. В той же документации e-invoicing описан через Invoice+ plugin. Поэтому не стоит смешивать два сценария:

• Обычное формирование счёта или выгрузки из billable-записей по шаблону — то, о чём вся эта статья.
• Электронное выставление через Invoice+ — отдельное расширение со своей настройкой и своими требованиями.

Если вам нужен именно e-invoicing, плагин нужно изучать самостоятельно, а не предполагать, что всё необходимое уже есть в стандартной выгрузке. И обратное: если вам достаточно понятного отчёта и счёта по шаблону, плагин не нужен только потому, что слово «электронный» звучит солидно. Вопросы налогового оформления и обязательных реквизитов тоже лежат вне Kimai и этой статьи: шаблон, даже хороший, сам по себе не делает документ юридически достаточным.

Ошибка найдена после закрытия: исправляем без второй оплаты

Теперь самая неприятная ситуация. Месяц закрыт, записи обработаны, счёт ушёл. Через неделю выясняется: разработчик записал три часа на проект А, хотя работал над проектом Б. Или наоборот, клиенту предъявлено лишнее. Что делать?

Опасность здесь двойная. Первая — переписать запись тихо, чтобы источник стал правильным, а документ остался прежним: отчёт и счёт разойдутся, и через полгода никто не поймёт почему. Вторая — снять признак обработки, исправить запись и снова выгрузить: старые часы выставятся второй раз, уже вместе с новой правкой. Это и есть скрытая повторная оплата.

Безопасный порядок я бы строила на том, что записи нужно сопоставлять со счётом, а не просто менять. Разберём два случая.

Случай первый: часы выставлены не тому клиенту

1. Определите, какой счёт содержит ошибочную строку и сколько часов затронуто.
2. Решите вместе с клиентом, как корректируется документ: отдельной корректировкой или в следующем периоде. Форму документа определяйте по вашим правилам учёта; Kimai это решение за вас не принимает.
3. Только после этого вносите правку в запись силами пользователя с достаточными правами, оставив в описании пометку о причине и дате исправления.
4. Проверьте, что исправленная запись не попадёт в следующий счёт повторно. Для этого посмотрите её состояние в списке: помечена она как обработанная или нет.

Случай второй: выставлено лишнее или не выставлено нужное

Если часы нужно вернуть клиенту, корректировка идёт в следующий период с понятной строкой, на которую можно сослаться. Если часы не попали в счёт, а должны были, их выставляют отдельно, но только после того, как убедились, что они действительно не обработаны и не были оплачены ранее. Простое правило: прежде чем что-то выставлять заново, найдите, где эта запись уже фигурировала.

Во всех вариантах работает одно общее правило: исправление должно оставлять след. Описание записи, комментарий в задаче и переписка с клиентом вместе дают цепочку, по которой видно, что было, что изменилось и почему. Без неё export flag защищает вас от случайной двойной выгрузки, но не от осознанной, но плохо задокументированной.

Где живёт Kimai и что это меняет в закрытии месяца

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

В публичном предложении MAATRIX на странице аренды VPS указаны NVMe-диски, процессоры AMD EPYC и root-доступ, а также локации UK, US, RU и FR. Тарифы начинаются с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и идут через Uab (2 vCPU, 4 ГБ, 80 ГБ) и Heka (4 vCPU, 8 ГБ, 160 ГБ) к Maat, Djed и выше. Для одного небольшого агентства с десятком сотрудников ресурсов младших тарифов может хватить, но это зависит от числа пользователей, объёма записей и используемых плагинов; цифры тарифов не являются обещанием ёмкости, а реальную нагрузку нужно смотреть на своих данных.

Одно замечание для тех, кто рассчитывает на резервные копии: в публичном предложении автоматические бэкапы для всех тарифов не заявлены. Поскольку timesheet — это ваши основные данные для выставления счетов, порядок копирования базы лучше продумать самостоятельно и проверить восстановление до первого закрытого месяца, а не после первой потери записей.

Строка отчёта, у которой есть родословная

Теперь соберём всё вместе на одной строке. Допустим, в клиентском отчёте за месяц стоит:

Фильтры каталога по характеристикам — 11,0 ч.

Что стоит за этой строкой, если процесс выстроен правильно? Во-первых, это одна или несколько записей timesheet с клиентом, проектом «Сайт каталога» и активностью «Разработка». Во-вторых, у них непустые описания, из которых понятно, что именно сделано. В-третьих, они не содержат незавершённых таймеров и подозрительных интервалов, потому что внутренняя сверка прошла до формирования документа. В-четвёртых, все они отмечены как billable, потому что входят в согласованный объём. В-пятых, клиент до выпуска счёта получил предварительную ведомость и подтвердил состав письмом. И наконец, после обработки записи получили export flag, так что в следующий месяц они не уйдут и не будут случайно изменены обычным пользователем.

Если клиент спросит: «А что входит в эти одиннадцать часов?» — вы открываете записи, из которых состоит строка, и читаете описания. Если он спросит: «Почему нет двух с половиной часов исправления скидки?» — вы показываете невыставляемую запись и объясняете, что это наш дефект. Если через месяц обнаружится неточность, вы находите счёт, идёте по цепочке исправлений и не выставляете то же самое дважды.

Вот и весь смысл закрытия месяца в Kimai: не получить красивую цифру, а добиться того, чтобы любая строка отчёта вела назад к конкретным записям времени, а любая запись знала, в каком документе она уже побывала.