Реальные сценарии выставления счетов

Жизнь фрилансера с выставлением счетов хаотичнее, чем кажется из чистого конфигурационного файла. Клиенты меняются, контракты обновляются, случаются ошибки, и иногда ты выполняешь работу, за которую не хочешь брать деньги. Эти сценарии описывают реальные ситуации и как Vibes to Bucks справляется с каждой из них.

Сценарий 1 — Обновление контракта: тот же клиент, новый проект

Кто: Анна, фриланс-разработчик, работающая над github.com/acme/website для клиента Acme.

Что произошло: С января Анна выставляет счета за AI-расходы в проект Moneybird “Acme Website Q1–Q2”. 1 июля начинается новый 6-месячный контракт. Проект клиента в Moneybird меняется на “Acme Website Q3–Q4” — возможно, с другой почасовой ставкой. Репозиторий и ветка остаются теми же.

Чего хочет Анна:

• С 1 июля все новые AI-расходы синхронизируются с новым проектом.
• Шесть месяцев записей времени, уже находящихся в Moneybird под старым проектом, остаются на месте.
• Сегодняшние расходы идут в новый проект.

Риск без руководства: Анна меняет правило выставления счетов и запускает Sync Now. Расширение пересчитывает январь-июнь, не видит записей времени за эти дни под новым проектом и создает 180 дубликатов в Moneybird — наряду с теми, что уже существуют под старым проектом.

Как Vibes to Bucks справляется с этим: Когда Анна редактирует правило выставления счетов, чтобы указать на новый проект, расширение спрашивает, что делать с историческими расходами. Она выбирает “Применить с сегодняшнего дня”. Прошлые дни сохраняют свою ассоциацию со старым проектом. Только сегодняшний и будущие дни синхронизируются под новым проектом. Без дубликатов, без необходимости в очистке.

Сценарий 2 — Смена клиента: перемещение репозитория к другому клиенту

Кто: Бен, разработчик, работающий над github.com/org/platform.

Что произошло: Изначально Бен выставлял счета за этот репозиторий клиенту Alpha, который финансировал этап НИОКР. Платформа теперь в производстве, и клиент Beta является текущим заказчиком. Бену нужно переназначить репозиторий.

2a — Чистый разрыв

Чего хочет Бен: Будущие расходы идут клиенту Beta. Прошлые записи, синхронизированные с клиентом Alpha, остаются нетронутыми. Ничего не изменяется задним числом.

Как Vibes to Bucks справляется с этим: Бен меняет контакт в правиле выставления счетов с Alpha на Beta. Расширение спрашивает, что делать с историей. Он выбирает “Применить с сегодняшнего дня”. Исторические записи Alpha остаются в Moneybird. Beta начинает получать записи с сегодняшнего дня.

2b — Полная ретроактивная коррекция

Чего хочет Бен: Выставление счетов Alpha было ошибкой — все должно было быть Beta с самого начала. Бен хочет пересинхронизировать все под Beta. Он принимает, что ему придется вручную очистить записи Alpha в Moneybird.

Как Vibes to Bucks справляется с этим: Бен выбирает “Применить ко всему времени”. Расширение предупреждает его, что существующие записи под Alpha не будут автоматически удалены — их нужно будет удалить в Moneybird. Затем оно создает новые записи за каждый исторический день под Beta.

2c — Синхронизация только разрыва

Чего хочет Бен: Бен прекратил синхронизацию две недели назад, когда понял, что назначение было неправильным. У него есть 14 дней несинхронизированных расходов в книге. Он хочет, чтобы эти 14 дней пошли к Beta, но месяцы, уже синхронизированные с Alpha, должны остаться.

Как Vibes to Bucks справляется с этим: Бен выбирает “Применить только к несинхронизированным дням”. Расширение знает, какие дни уже имеют запись времени в provider_posts, и пропускает их. Только 14 несинхронизированных дней создаются под Beta.

Сценарий 3 — Разделение проекта: перераспределение работы по под-проектам

Кто: Клара, разработчик, работающий над монорепозиторием для клиента Gamma.

Что произошло: Клара выставляла счета за всю AI-работу в один общий проект “Общая разработка”. Gamma теперь хочет, чтобы расходы были разбиты по функциональным областям. Клара создает правила выставления счетов на основе веток: feature/auth/* → “Auth Module” и feature/billing/* → “Billing Module”.

3a — Разделение только вперед

Чего хочет Клара: В дальнейшем расходы направляются в правильные под-проекты. Прошлые расходы, уже синхронизированные под “Общая разработка”, остаются там.

Как Vibes to Bucks справляется с этим: Когда Клара добавляет новые правила веток, расширение спрашивает о истории для каждого. Она выбирает “Применить с сегодняшнего дня” для обоих. Исторические записи под “Общая разработка” остаются нетронутыми.

3b — Историческая точность

Чего хочет Клара: Она действительно хочет ретроактивно переместить прошлые расходы в правильные под-проекты. Она принимает, что ей придется вручную удалить старые записи “Общая разработка” в Moneybird.

Как Vibes to Bucks справляется с этим: Клара выбирает “Применить ко всему времени” для новых правил. Расширение предупреждает о существующих записях под старым проектом и создает правильные записи по под-проектам за каждый день. Клара очищает старые записи в Moneybird.

Сценарий 4 — Небиллинговая работа в качестве любезности

Кто: Дэвид, фрилансер, работающий над репозиторием клиента Delta.

Что произошло: Дэвид участвует во внутреннем код-ревью и некоторых экспериментах, которые не входят в сферу Delta — но он держит Cursor открытым на их репозитории. Он не хочет, чтобы следующие 2 часа AI-расходов были начислены Delta.

Чего хочет Дэвид:

• Переключить правило выставления счетов Delta в режим “небиллинговый”. Видимый индикатор на статусной панели подтверждает, что правило небиллинговое.
• AI-расходы все еще отслеживаются и видны на дашборде — он хочет видеть, сколько ему стоит эта работа в качестве любезности — но помечены как не для выставления счетов.
• Каждый час уведомление-напоминание: “Правило выставления счетов Delta небиллинговое уже 2 часа. Все еще работаешь небиллингово?”
• Когда он переключается обратно на биллинговый режим, нормальная синхронизация возобновляется.
• Небиллинговые расходы отображаются на дашборде под Delta, но четко отделены от биллинговых расходов.

Почему по назначению, а не глобально: Дэвид может работать над несколькими задачами одновременно. Если он переключается на репозиторий клиента Beta, пока Delta небиллинговый, Beta все равно должен выставляться счет. Небиллинговый режим — это решение вежливости для каждого клиента: “эти расходы я делаю не по просьбе клиента — я делаю это для них в качестве любезности.”

Как Vibes to Bucks справляется с этим: Дэвид открывает панель настроек и переключает правило выставления счетов Delta на небиллинговый режим. Диалог спрашивает две вещи: когда начать небиллинговый режим (сейчас или задним числом) и когда закончить. Дэвид выбирает “Сейчас” и “Конец дня” — выставление счетов автоматически возобновляется завтра. Статусная панель показывает $4.23 сегодня · Delta [небиллингово до конца дня], пока он работает в репозитории Delta. Небиллинговые расходы все еще синхронизируются с Moneybird как небиллинговые записи времени (видимые в записях, но исключенные из клиентских счетов). Дашборд показывает как биллинговые, так и небиллинговые расходы для Delta, четко разделенные.

Если Дэвид ожидает, что работа в качестве любезности продлится дольше, он может выбрать “Конкретная дата” (например, небиллингово до пятницы) или “Пока я не возобновлю вручную” с интервалом напоминания (каждые 30 минут, 1 час, 2 часа и т.д.), чтобы не забыть включить выставление счетов снова.

Вариация — ретроактивное небиллинговое

Чего хочет Дэвид: Он забыл переключиться перед началом. Он хочет отметить последние 90 минут как небиллинговые задним числом.

Как Vibes to Bucks справляется с этим: Дэвид открывает панель настроек, переключает Delta на небиллинговый режим и в разделе Начало выбирает “Задним числом” с указанием времени 90 минут назад. Расходы с этого момента помечаются как небиллинговые. Если сегодняшняя запись времени уже была синхронизирована с Moneybird, расширение пересчитывает и обновляет ее, чтобы отразить уменьшенную сумму для выставления счетов. Заднее датирование ограничено сегодняшним днем — для многодневных исправлений Sync Ledger предоставляет возможности отмены и повторной синхронизации.

Сценарий 5 — Отмена неправильной синхронизации

Кто: Ева, фрилансер, которая изменила назначение и сразу запустила Sync Now.

Что произошло: Ева отредактировала правило выставления счетов (изменила проект) и запустила Sync Now, не задумываясь о последствиях. Расширение создало 3 месяца новых записей времени под неправильным проектом в Moneybird, наряду с существующими правильными записями под старым проектом.

Чего хочет Ева:

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

Как Vibes to Bucks справляется с этим: После каждой синхронизации расширение показывает уведомление: “Синхронизировано с Moneybird — Создано 87, обновлено 2, пропущено 14.” Нажатие на “Показать детали” открывает Sync Ledger — специальный вид, показывающий каждую синхронизированную и ожидающую запись, фильтруемую по клиенту, проекту и дате. Ева может увидеть, какие записи были только что созданы, выбрать неправильные и нажать “Отменить синхронизацию.” Расширение удаляет эти записи из Moneybird и отмечает их как ожидающие, чтобы они могли быть правильно пересинхронизированы после того, как она исправит правило.

Сценарий 6 — Временное выставление счетов за проект

Кто: Фрэнк, разработчик, работающий над github.com/acme/api.

Что произошло: Обычно Фрэнк выставляет счета за проект “API Maintenance”. В течение двух недель в марте он участвует в специальном спринте, который выставляется за “API v2 Migration”. После спринта он переключается обратно.

Чего хочет Фрэнк:

• Изменить правило выставления счетов на “API v2 Migration” 10 марта.
• Изменить его обратно на “API Maintenance” 24 марта.
• Только окно с 10 по 23 марта синхронизируется с “API v2 Migration”.
• Все до 10 марта и после 23 марта синхронизируется с “API Maintenance”.
• Без ретроактивного беспорядка в любом направлении.

Как Vibes to Bucks справляется с этим: Оба раза, когда Фрэнк меняет правило выставления счетов, он выбирает “Применить с сегодняшнего дня”. 10 марта правило начинает выставлять счета за “API v2 Migration”. 24 марта оно переключается обратно на “API Maintenance”. Записи каждого периода остаются с проектом, который был активен в то время.

Сценарий 7 — Прекращение выставления счетов, сохранение отслеживания

Кто: Джина, фрилансер, завершающий работу с клиентом Eta.

Что произошло: Контракт завершен, но Джина все еще выполняет мелкие работы по обслуживанию репозитория Eta. Она хочет видеть AI-расходы на своей панели — чтобы оценить, стоит ли заключать новый контракт — но не хочет синхронизировать записи времени.

Чего хочет Джина:

• Пометить правило выставления счетов как постоянно небиллинговое (не временное переключение — постоянная настройка).
• Дашборд все еще показывает расходы, отнесенные к клиенту Eta.
• Синхронизация полностью пропускает это правило выставления счетов.
• Если Eta вернется с новым контрактом, она переключает его обратно на биллинговое и синхронизирует только с этого момента — не за период разрыва.

Как Vibes to Bucks справляется с этим: Джина снимает галочку “Биллинговое” в правиле выставления счетов Eta. Расходы продолжают отслеживаться и отображаются на дашборде под Eta, но записи времени не создаются. Когда появляется новый контракт, она снова включает выставление счетов и выбирает “Применить с сегодняшнего дня”. Небиллинговый разрыв остается небиллинговым.

Сценарий 8 — Миграция провайдера

Кто: Хьюго, фрилансер, который синхронизировался с Moneybird в течение 6 месяцев.

Что произошло: Бухгалтерская фирма Хьюго переводит его на Harvest. Он меняет destination: harvest в своей конфигурации и настраивает новые правила выставления счетов для Harvest.

Чего хочет Хьюго:

• В дальнейшем синхронизация идет в Harvest.
• 6 месяцев записей Moneybird остаются нетронутыми.
• В Harvest не создаются ретроактивные записи за исторический период.

Как Vibes to Bucks справляется с этим: Когда Хьюго переключает провайдера выставления счетов, расширение обнаруживает, что у Harvest нет истории синхронизации. Без руководства оно попыталось бы создать записи за каждый исторический день. Вместо этого появляется тот же диалог с тремя вариантами: “Начать с сегодняшнего дня”, “Синхронизировать всю историю”, или “Синхронизировать только несинхронизированные дни.” Хьюго выбирает “Начать с сегодняшнего дня.” Расширение устанавливает дату отсечения миграции, чтобы механизм синхронизации пропускал все дни до сегодняшнего. Только сегодняшний и будущие дни создают записи в Harvest. Его записи в Moneybird остаются нетронутыми.

Сценарий 9 — Случайное удаление правила

Кто: Иван, фрилансер, выставляющий счета за репозиторий клиента Kappa.

Что произошло: Иван хотел отредактировать правило выставления счетов, чтобы изменить почасовую ставку, но случайно удалил его. Он сразу замечает это и воссоздает правило с правильными настройками.

Чего хочет Иван:

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

Риск без руководства: Иван создает новое правило. Расширение видит репозиторий с историческими данными о расходах и без соответствующей истории правил выставления счетов. Наивная синхронизация рассматривала бы каждый прошлый день как “никогда не синхронизированный по этому правилу” и создавала бы записи за всю историю.

Как Vibes to Bucks справляется с этим: Когда Иван создает правило выставления счетов для репозитория, который уже имеет исторические данные о расходах в книге, расширение распознает это и предлагает тот же диалог с тремя вариантами. Иван выбирает “Применить с сегодняшнего дня” — прошлые записи остаются как были, и выставление счетов продолжается с сегодняшнего дня. Без дубликатов, без разрыва, без паники.

Общая нить

Каждый из приведенных выше сценариев сводится к одному вопросу: когда ты меняешь правило выставления счетов, что должно произойти с прошлым?

Vibes to Bucks никогда не принимает это решение за тебя. Каждый раз, когда ты редактируешь правило выставления счетов — меняешь клиента, проект, ставку или статус биллинга — расширение предлагает тебе выбрать:

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