Cenários de Faturação no Mundo Real

A vida de faturação de qualquer freelancer é mais desorganizada do que um ficheiro de configuração limpo sugere. Os clientes mudam, os contratos renovam-se, ocorrem erros e, por vezes, faz-se trabalho que não se quer cobrar. Estes cenários descrevem situações reais e como o Vibes to Bucks lida com cada uma delas.

Cenário 1 — Renovação de contrato: mesmo cliente, novo projeto

Quem: Anna, uma desenvolvedora freelancer a trabalhar em github.com/acme/website para o Cliente Acme.

O que aconteceu: Desde janeiro, Anna tem faturado os custos de IA ao projeto “Acme Website Q1–Q2” no Moneybird. A partir de 1 de julho, entra em vigor um novo contrato de 6 meses. O projeto do cliente no Moneybird muda para “Acme Website Q3–Q4” — possivelmente com uma taxa horária diferente. O repositório e a branch mantêm-se os mesmos.

O que Anna deseja:

• A partir de 1 de julho, todos os novos custos de IA sincronizam com o novo projeto.
• Os seis meses de entradas de tempo já no Moneybird sob o projeto antigo permanecem exatamente onde estão.
• O custo de hoje vai para o novo projeto.

O risco sem orientação: Anna altera a sua regra de faturação e executa Sincronizar Agora. A extensão reagrupa de janeiro a junho, não vê entradas de tempo para esses dias sob o novo projeto e cria 180 entradas duplicadas no Moneybird — além das que já existem sob o projeto antigo.

Como o Vibes to Bucks lida com isso: Quando Anna edita a sua regra de faturação para apontar para o novo projeto, a extensão pergunta-lhe o que deve acontecer aos custos históricos. Ela escolhe “Aplicar a partir de hoje”. Os dias passados mantêm a sua associação com o projeto antigo. Apenas hoje e os dias futuros sincronizam sob o novo projeto. Sem duplicados, sem necessidade de limpeza.

Cenário 2 — Mudança de cliente: mover um repositório para um cliente diferente

Quem: Ben, um desenvolvedor a trabalhar em github.com/org/platform.

O que aconteceu: Ben inicialmente faturou este repositório ao Cliente Alpha, que financiou a fase de I&D. A plataforma está agora em produção e o Cliente Beta é o cliente atual. Ben precisa de remapear o repositório.

2a — Corte limpo

O que Ben deseja: Custos futuros vão para o Cliente Beta. As entradas passadas sincronizadas com o Cliente Alpha permanecem intocadas. Nada retroativo.

Como o Vibes to Bucks lida com isso: Ben altera o contacto da regra de faturação de Alpha para Beta. A extensão pergunta o que deve acontecer ao histórico. Ele escolhe “Aplicar a partir de hoje”. As entradas históricas de Alpha permanecem no Moneybird. Beta começa a receber entradas a partir de hoje.

2b — Correção retroativa completa

O que Ben deseja: A faturação para Alpha foi um erro — deveria ter sido Beta desde o início. Ben quer re-sincronizar tudo sob Beta. Ele aceita que terá de limpar manualmente as entradas de Alpha no Moneybird.

Como o Vibes to Bucks lida com isso: Ben escolhe “Aplicar a todo o tempo”. A extensão avisa-o de que as entradas existentes sob Alpha não serão automaticamente eliminadas — ele terá de removê-las no Moneybird. Em seguida, cria novas entradas para cada dia histórico sob Beta.

2c — Sincronizar apenas a lacuna

O que Ben deseja: Ben parou de sincronizar há duas semanas quando percebeu que o mapeamento estava errado. Ele tem 14 dias de custos não sincronizados no livro-razão. Ele quer que esses 14 dias vão para Beta, mas os meses já sincronizados com Alpha devem permanecer.

Como o Vibes to Bucks lida com isso: Ben escolhe “Aplicar apenas aos dias não sincronizados”. A extensão sabe quais os dias que já têm uma entrada de tempo em provider_posts e ignora-os. Apenas os 14 dias não sincronizados são criados sob Beta.

Cenário 3 — Divisão de projeto: redistribuir trabalho por subprojetos

Quem: Clara, uma desenvolvedora a trabalhar num monorepo para o Cliente Gamma.

O que aconteceu: Clara tem faturado todo o trabalho de IA para um projeto abrangente “Desenvolvimento Geral”. Gamma agora quer que os custos sejam divididos por área de funcionalidade. Clara cria regras de faturação baseadas em branches: feature/auth/* → “Módulo de Autenticação” e feature/billing/* → “Módulo de Faturação”.

3a — Divisão apenas para o futuro

O que Clara deseja: Daqui para a frente, os custos são direcionados para o subprojeto correto. Os custos passados já sincronizados sob “Desenvolvimento Geral” permanecem lá.

Como o Vibes to Bucks lida com isso: Quando Clara adiciona as novas regras de branch, a extensão pergunta sobre o histórico para cada uma. Ela escolhe “Aplicar a partir de hoje” para ambas. As entradas históricas sob “Desenvolvimento Geral” permanecem intocadas.

3b — Precisão histórica

O que Clara deseja: Ela quer realmente mover retroativamente os custos passados para os subprojetos corretos. Ela aceita que terá de eliminar manualmente as entradas antigas de “Desenvolvimento Geral” no Moneybird.

Como o Vibes to Bucks lida com isso: Clara escolhe “Aplicar a todo o tempo” para as novas regras. A extensão avisa sobre as entradas existentes sob o projeto antigo e cria entradas corretas por subprojeto por dia. Clara limpa as entradas antigas no Moneybird.

Cenário 4 — Trabalho de cortesia não faturável

Quem: David, um freelancer a trabalhar no repositório do Cliente Delta.

O que aconteceu: David é envolvido numa revisão de código interna e em alguma experimentação que não faz parte do âmbito de Delta — mas mantém o Cursor aberto no seu repositório. Ele não quer que as próximas 2 horas de custo de IA sejam cobradas a Delta.

O que David deseja:

• Alternar a regra de faturação de Delta para o modo “não faturável”. Um indicador visível na barra de estado confirma que a regra é não faturável.
• Os custos de IA ainda são rastreados e visíveis no painel de controlo — ele quer ver quanto este trabalho de cortesia lhe custa — mas marcados como não para faturação.
• A cada hora, uma notificação de lembrete: “A regra de faturação de Delta está não faturável há 2 horas. Ainda a trabalhar não faturável?”
• Quando ele alterna de volta para faturável, a sincronização normal é retomada.
• Os custos não faturáveis aparecem no painel de controlo sob Delta, mas são claramente distinguidos dos custos faturáveis.

Porquê por mapeamento, não global: David pode estar a realizar multitarefas. Se ele mudar para o repositório do Cliente Beta enquanto Delta está não faturável, Beta deve ainda faturar normalmente. Não faturável é uma decisão de cortesia por cliente: “este custo que estou a fazer não é pedido do cliente — estou a fazer isto por cortesia.”

Como o Vibes to Bucks lida com isso: David abre o painel de Configurações e alterna a regra de faturação de Delta para não faturável. Um diálogo pergunta duas coisas: quando deve começar a não faturável (agora, ou retroativo), e quando deve terminar. David escolhe “A partir de agora” e “Fim do dia” — a faturação retoma automaticamente amanhã. A barra de estado mostra $4.23 hoje · Delta [não faturável até ao fim do dia] enquanto ele trabalha no repositório de Delta. Os custos não faturáveis ainda sincronizam com o Moneybird como entradas de tempo não faturáveis (visíveis nos registos mas excluídas da faturação ao cliente). O painel de controlo mostra tanto os custos faturáveis como os não faturáveis para Delta, claramente separados.

Se David espera que o trabalho de cortesia dure mais tempo, ele pode escolher “Data específica” (por exemplo, não faturável até sexta-feira) ou “Até retomar manualmente” com um intervalo de lembrete (a cada 30 minutos, 1 hora, 2 horas, etc.) para não se esquecer de voltar a ativar a faturação.

Variação — não faturável retroativo

O que David deseja: Ele esqueceu-se de alternar antes de começar. Ele quer marcar os últimos 90 minutos como não faturáveis após o facto.

Como o Vibes to Bucks lida com isso: David abre o painel de Configurações, alterna Delta para não faturável, e na secção Início escolhe “Retroceder” com um tempo de 90 minutos atrás. Os custos a partir desse ponto são marcados como não faturáveis. Se a entrada de tempo de hoje já foi sincronizada com o Moneybird, a extensão recalcula e atualiza-a para refletir o montante faturável reduzido. A retroação é limitada a hoje — para correções de vários dias, o Livro-Razão de Sincronização fornece controlos de desfazer e re-sincronizar.

Cenário 5 — Desfazer uma sincronização incorreta

Quem: Eve, uma freelancer que alterou um mapeamento e imediatamente executou Sincronizar Agora.

O que aconteceu: Eve editou uma regra de faturação (alterou o projeto) e executou Sincronizar Agora sem pensar nas consequências. A extensão criou 3 meses de novas entradas de tempo sob o projeto errado no Moneybird, além das entradas corretas existentes sob o projeto antigo.

O que Eve deseja:

• Ver o que acabou de ser sincronizado — um resumo mostrando quantas entradas foram criadas ou atualizadas, para quais dias, sob qual projeto.
• Reverter: ou a extensão elimina as entradas incorretamente criadas, ou informa claramente quais os IDs de entrada que ela deve limpar manualmente.

Como o Vibes to Bucks lida com isso: Após cada sincronização, a extensão mostra uma notificação: “Sincronizado com o Moneybird — Criado 87, atualizado 2, ignorado 14.” Ao clicar em “Mostrar detalhes” abre-se o Livro-Razão de Sincronização — uma vista dedicada mostrando todas as entradas sincronizadas e pendentes, filtrável por cliente, projeto e data. Eve pode ver exatamente quais as entradas que foram criadas, selecionar as incorretas e clicar em “Desfazer sincronização.” A extensão elimina essas entradas do Moneybird e marca-as como pendentes novamente para que possam ser re-sincronizadas corretamente após ela corrigir a regra.

Cenário 6 — Faturação temporária de projeto

Quem: Frank, um desenvolvedor a trabalhar em github.com/acme/api.

O que aconteceu: Frank normalmente fatura ao projeto “Manutenção da API”. Durante duas semanas em março, ele está num sprint especial faturado a “Migração da API v2”. Após o sprint, ele volta ao normal.

O que Frank deseja:

• Alterar a regra de faturação para “Migração da API v2” a 10 de março.
• Alterar de volta para “Manutenção da API” a 24 de março.
• Apenas o período de 10 a 23 de março sincroniza com “Migração da API v2”.
• Tudo antes de 10 de março e após 23 de março sincroniza com “Manutenção da API”.
• Sem confusão retroativa em qualquer direção.

Como o Vibes to Bucks lida com isso: Ambas as vezes que Frank altera a regra de faturação, ele escolhe “Aplicar a partir de hoje”. A 10 de março, a regra começa a faturar para “Migração da API v2”. A 24 de março, volta a “Manutenção da API”. As entradas de cada período permanecem com o projeto que estava ativo na altura.

Cenário 7 — Parar de faturar, continuar a rastrear

Quem: Gina, uma freelancer a encerrar com o Cliente Eta.

O que aconteceu: O contrato terminou, mas Gina ainda faz manutenção menor no repositório de Eta. Ela quer ver os custos de IA no seu painel de controlo — para avaliar se um novo contrato valeria a pena — mas não quer sincronizar nenhuma entrada de tempo.

O que Gina deseja:

• Marcar a regra de faturação como permanentemente não faturável (não um alternador temporário — uma configuração duradoura).
• O painel de controlo ainda mostra os custos atribuídos ao Cliente Eta.
• A sincronização ignora completamente esta regra de faturação.
• Se Eta voltar com um novo contrato, ela muda de volta para faturável e só sincroniza a partir desse ponto — não o período de lacuna.

Como o Vibes to Bucks lida com isso: Gina desmarca “Faturável” na regra de faturação de Eta. Os custos continuam a ser rastreados e aparecem no painel de controlo sob Eta, mas não são criadas entradas de tempo. Quando um novo contrato chega, ela reativa a faturação e escolhe “Aplicar a partir de hoje”. A lacuna não faturável permanece não faturada.

Cenário 8 — Migração de fornecedor

Quem: Hugo, um freelancer que tem sincronizado com o Moneybird há 6 meses.

O que aconteceu: A firma de contabilidade de Hugo muda-o para o Harvest. Ele altera destination: harvest na sua configuração e configura novas regras de faturação no Harvest.

O que Hugo deseja:

• Daqui para a frente, a sincronização vai para o Harvest.
• Os 6 meses de entradas no Moneybird permanecem intocados.
• Não são criadas entradas retroativas no Harvest para o período histórico.

Como o Vibes to Bucks lida com isso: Quando Hugo muda o fornecedor de faturação, a extensão deteta que o Harvest não tem histórico de sincronização. Sem orientação, tentaria criar entradas para cada dia histórico. Em vez disso, aparece o mesmo diálogo de três opções: “Começar de novo a partir de hoje”, “Sincronizar todo o histórico”, ou “Sincronizar apenas dias não sincronizados.” Hugo escolhe “Começar de novo.” A extensão define uma data de corte de migração para que o motor de sincronização ignore todos os dias antes de hoje. Apenas hoje e os dias futuros criam entradas no Harvest. As suas entradas no Moneybird permanecem intocadas.

Cenário 9 — Eliminação acidental de regra

Quem: Ivan, um freelancer a faturar o repositório do Cliente Kappa.

O que aconteceu: Ivan pretendia editar a sua regra de faturação para alterar a taxa horária, mas acidentalmente eliminou-a. Ele percebe imediatamente e recria a regra com as configurações corretas.

O que Ivan deseja:

• Recriar a regra sem causar meses de entradas de tempo duplicadas no Moneybird.
• As entradas passadas que já foram sincronizadas devem permanecer intocadas.
• A faturação deve continuar sem interrupções como se nada tivesse acontecido.

O risco sem orientação: Ivan cria a nova regra. A extensão vê um repositório com dados de custo históricos e sem histórico de regra de faturação correspondente. Uma sincronização ingênua trataria cada dia passado como “nunca sincronizado sob esta regra” e criaria entradas para todo o histórico.

Como o Vibes to Bucks lida com isso: Quando Ivan cria uma regra de faturação para um repositório que já tem dados de custo históricos no livro-razão, a extensão reconhece isso e apresenta o mesmo diálogo de três opções. Ivan escolhe “Aplicar a partir de hoje” — as entradas passadas permanecem como estavam, e a faturação retoma a partir de hoje. Sem duplicados, sem lacunas, sem pânico.

O fio condutor

Cada cenário acima resume-se a uma questão: quando você altera uma regra de faturação, o que deve acontecer ao passado?

O Vibes to Bucks nunca toma essa decisão por si. Cada vez que você edita uma regra de faturação — altera o cliente, projeto, taxa ou estado de faturação — a extensão pede-lhe para escolher:

Esta escolha guiada aparece num diálogo claro sempre que uma alteração de regra de faturação afetaria como os custos históricos são tratados. Sem surpresas, sem refaturação retroativa silenciosa, sem duplicados órfãos.