Підвищення зарплати не повинно переписувати історію

У таблиці зарплата зазвичай живе в одній комірці. Людині підняли ставку — комірку перезаписали. Через тиждень власник відкриває звіт по проєкту, зданому пів року тому, і бачить іншу маржу, ніж бачив тоді. Проєкт не змінився. Змінилась комірка.

Друга цифра не просто неточна — вона неправдива. У березні агенція справді заробила 24,1 %. Липневе підвищення не може заднім числом зробити березень гіршим.

Як має бути влаштовано

Ставка — це не число, а послідовність записів: сума і дата, з якої вона діє. Розрахунок будь-якого періоду бере ту ставку, яка діяла в дні роботи. Підвищення додає новий запис, а не змінює старий.

• Закриті періоди лишаються незмінними — звіт, роздрукований торік, збігається з тим, що система показує сьогодні.
• Перерахунок заднім числом можливий, але лише свідомо: новий запис із минулою датою дії видно в історії.
• Видно, як змінювалась собівартість команди в часі — це окрема корисна картина.

Практична перевірка вашої системи: підніміть комусь зарплату й подивіться на маржу закритого торішнього проєкту. Якщо вона змінилась — історії у вас немає.

Те саме стосується ставки продажу

Ставка, за якою ви продаєте годину, теж змінюється: індексація, новий прайс, перегляд умов із клієнтом. Якщо вона зберігається одним числом, то після підвищення прайсу всі старі проєкти виглядають так, ніби продавались дорожче, ніж насправді, — і маржа минулого року стає вигаданою.

У Systemer ставки версіонуються датою початку дії, а розрахунок собівартості завжди бере ставку на дату запису часу. Плюс кожна зміна ставки потрапляє в журнал аудиту: хто, коли, значення до і після. Це не параноя — це єдиний спосіб відповісти на питання «чому маржа проєкту змінилась», коли воно виникне через півроку.