Skenario Penagihan di Dunia Nyata

Setiap kehidupan penagihan freelancer lebih berantakan daripada yang terlihat dalam file konfigurasi yang rapi. Klien berubah, kontrak diperbarui, kesalahan terjadi, dan terkadang Anda melakukan pekerjaan yang tidak ingin Anda tagih. Skenario-skenario ini menggambarkan situasi nyata dan bagaimana Vibes to Bucks menangani masing-masing.

Skenario 1 — Pembaruan kontrak: klien yang sama, proyek baru

Siapa: Anna, seorang pengembang lepas yang bekerja pada github.com/acme/website untuk Klien Acme.

Apa yang terjadi: Anna telah menagih biaya AI ke proyek Moneybird “Acme Website Q1–Q2” sejak Januari. Pada 1 Juli, kontrak baru selama 6 bulan dimulai. Proyek Moneybird klien berubah menjadi “Acme Website Q3–Q4” — mungkin dengan tarif per jam yang berbeda. Repositori dan cabang tetap sama.

Yang Anna inginkan:

• Mulai 1 Juli, semua biaya AI baru disinkronkan ke proyek baru.
• Enam bulan entri waktu yang sudah ada di Moneybird di bawah proyek lama tetap di tempatnya.
• Biaya hari ini masuk ke proyek baru.

Risiko tanpa panduan: Anna mengubah aturan penagihannya dan menjalankan Sync Now. Ekstensi mengagregasi ulang dari Januari hingga Juni, tidak melihat entri waktu untuk hari-hari tersebut di bawah proyek baru, dan membuat 180 entri duplikat di Moneybird — bersama dengan yang sudah ada di bawah proyek lama.

Bagaimana Vibes to Bucks menanganinya: Ketika Anna mengedit aturan penagihannya untuk menunjuk ke proyek baru, ekstensi menanyakan apa yang harus dilakukan dengan biaya historis. Dia memilih “Terapkan mulai hari ini”. Hari-hari sebelumnya mempertahankan asosiasi mereka dengan proyek lama. Hanya hari ini dan hari-hari mendatang yang disinkronkan di bawah proyek baru. Tidak ada duplikat, tidak perlu pembersihan.

Skenario 2 — Pergantian klien: pindahkan repo ke klien yang berbeda

Siapa: Ben, seorang pengembang yang bekerja pada github.com/org/platform.

Apa yang terjadi: Ben awalnya menagih repo ini ke Klien Alpha, yang mendanai fase R&D. Platform sekarang dalam produksi dan Klien Beta adalah pelanggan yang berkelanjutan. Ben perlu memetakan ulang repositori.

2a — Pemutusan bersih

Yang Ben inginkan: Biaya di masa depan masuk ke Klien Beta. Entri masa lalu yang disinkronkan ke Klien Alpha tetap tidak tersentuh. Tidak ada yang retroaktif.

Bagaimana Vibes to Bucks menanganinya: Ben mengubah kontak aturan penagihan dari Alpha ke Beta. Ekstensi menanyakan apa yang harus dilakukan dengan sejarah. Dia memilih “Terapkan mulai hari ini”. Entri historis Alpha tetap di Moneybird. Beta mulai menerima entri dari hari ini.

2b — Koreksi retroaktif penuh

Yang Ben inginkan: Penagihan Alpha adalah kesalahan — seharusnya semuanya Beta sejak awal. Ben ingin menyinkronkan semuanya di bawah Beta. Dia menerima bahwa dia harus membersihkan entri Alpha secara manual di Moneybird.

Bagaimana Vibes to Bucks menanganinya: Ben memilih “Terapkan untuk semua waktu”. Ekstensi memperingatkan bahwa entri yang ada di bawah Alpha tidak akan dihapus secara otomatis — dia harus menghapusnya di Moneybird. Kemudian membuat entri baru untuk setiap hari historis di bawah Beta.

2c — Sinkronkan hanya celahnya

Yang Ben inginkan: Ben berhenti menyinkronkan dua minggu lalu ketika dia menyadari pemetaan itu salah. Dia memiliki 14 hari biaya yang belum disinkronkan di buku besar. Dia ingin 14 hari tersebut masuk ke Beta, tetapi bulan-bulan yang sudah disinkronkan ke Alpha harus tetap.

Bagaimana Vibes to Bucks menanganinya: Ben memilih “Terapkan hanya untuk hari-hari yang belum disinkronkan”. Ekstensi mengetahui hari mana yang sudah memiliki entri waktu di provider_posts dan melewatkannya. Hanya 14 hari yang belum disinkronkan yang dibuat di bawah Beta.

Skenario 3 — Pemisahan proyek: distribusikan ulang pekerjaan ke sub-proyek

Siapa: Clara, seorang pengembang yang bekerja pada monorepo untuk Klien Gamma.

Apa yang terjadi: Clara telah menagih semua pekerjaan AI ke satu proyek umum “General Development”. Gamma sekarang ingin biaya dipecah berdasarkan area fitur. Clara membuat aturan penagihan berbasis cabang: feature/auth/* → “Auth Module” dan feature/billing/* → “Billing Module”.

3a — Pemisahan ke depan saja

Yang Clara inginkan: Ke depan, biaya diarahkan ke sub-proyek yang benar. Biaya masa lalu yang sudah disinkronkan di bawah “General Development” tetap di sana.

Bagaimana Vibes to Bucks menanganinya: Ketika Clara menambahkan aturan cabang baru, ekstensi menanyakan tentang sejarah untuk masing-masing. Dia memilih “Terapkan mulai hari ini” untuk keduanya. Entri historis di bawah “General Development” tidak tersentuh.

3b — Akurasi historis

Yang Clara inginkan: Dia sebenarnya ingin memindahkan biaya masa lalu secara retroaktif ke sub-proyek yang benar. Dia menerima bahwa dia akan menghapus entri “General Development” lama secara manual di Moneybird.

Bagaimana Vibes to Bucks menanganinya: Clara memilih “Terapkan untuk semua waktu” untuk aturan baru. Ekstensi memperingatkan tentang entri yang ada di bawah proyek lama dan membuat entri yang benar per sub-proyek per hari. Clara membersihkan entri lama di Moneybird.

Skenario 4 — Pekerjaan gratis yang tidak dapat ditagih

Siapa: David, seorang freelancer yang bekerja pada repo Klien Delta.

Apa yang terjadi: David terlibat dalam tinjauan kode internal dan beberapa eksperimen yang bukan bagian dari ruang lingkup Delta — tetapi dia tetap membuka Cursor di repo mereka. Dia tidak ingin 2 jam biaya AI berikutnya dibebankan ke Delta.

Yang David inginkan:

• Mengaktifkan aturan penagihan Delta ke mode “tidak dapat ditagih”. Indikator yang terlihat di bilah status mengonfirmasi aturan tidak dapat ditagih.
• Biaya AI masih dilacak dan terlihat di dasbor — dia ingin melihat berapa biaya pekerjaan gratis ini — tetapi ditandai sebagai tidak untuk penagihan.
• Setiap jam, notifikasi pengingat: “Aturan penagihan Delta telah tidak dapat ditagih selama 2 jam. Masih bekerja tidak dapat ditagih?”
• Ketika dia mengaktifkan kembali ke dapat ditagih, sinkronisasi normal dilanjutkan.
• Biaya yang tidak dapat ditagih ditampilkan di dasbor di bawah Delta tetapi jelas dibedakan dari biaya yang dapat ditagih.

Mengapa per-mapping, bukan global: David mungkin multitasking. Jika dia beralih ke repo Klien Beta sementara Delta tidak dapat ditagih, Beta harus tetap menagih secara normal. Tidak dapat ditagih adalah keputusan per-klien: “biaya ini bukan permintaan klien — saya melakukan ini untuk mereka sebagai kebaikan.”

Bagaimana Vibes to Bucks menanganinya: David membuka panel Pengaturan dan mengaktifkan aturan penagihan Delta ke tidak dapat ditagih. Sebuah dialog menanyakan dua hal: kapan tidak dapat ditagih dimulai (sekarang, atau mundur), dan kapan harus berakhir. David memilih “Mulai sekarang” dan “Akhir hari ini” — penagihan dilanjutkan secara otomatis besok. Bilah status menunjukkan $4.23 hari ini · Delta [tidak dapat ditagih hingga akhir hari] saat dia bekerja di repo Delta. Biaya yang tidak dapat ditagih masih disinkronkan ke Moneybird sebagai entri waktu yang tidak dapat ditagih (terlihat dalam catatan tetapi dikecualikan dari penagihan klien). Dasbor menunjukkan biaya yang dapat ditagih dan tidak dapat ditagih untuk Delta, jelas terpisah.

Jika David memperkirakan pekerjaan gratis ini akan berlangsung lebih lama, dia dapat memilih “Tanggal tertentu” (misalnya tidak dapat ditagih hingga Jumat) atau “Sampai saya melanjutkan secara manual” dengan interval pengingat (setiap 30 menit, 1 jam, 2 jam, dll.) agar dia tidak lupa mengaktifkan kembali penagihan.

Variasi — tidak dapat ditagih secara retroaktif

Yang David inginkan: Dia lupa mengaktifkan sebelum memulai. Dia ingin menandai 90 menit terakhir sebagai tidak dapat ditagih setelah fakta.

Bagaimana Vibes to Bucks menanganinya: David membuka panel Pengaturan, mengaktifkan Delta ke tidak dapat ditagih, dan di bawah bagian Mulai memilih “Mundur” dengan waktu 90 menit yang lalu. Biaya dari titik itu ke depan ditandai sebagai tidak dapat ditagih. Jika entri waktu hari ini sudah disinkronkan ke Moneybird, ekstensi menghitung ulang dan memperbaruinya untuk mencerminkan jumlah yang dapat ditagih yang dikurangi. Mundur dibatasi hingga hari ini — untuk koreksi multi-hari, Buku Besar Sinkronisasi menyediakan kontrol undo-dan-resync.

Skenario 5 — Batalkan sinkronisasi yang salah

Siapa: Eve, seorang freelancer yang mengubah pemetaan dan segera menjalankan Sync Now.

Apa yang terjadi: Eve mengedit aturan penagihan (mengubah proyek) dan menjalankan Sync Now tanpa memikirkan konsekuensinya. Ekstensi membuat 3 bulan entri waktu baru di bawah proyek yang salah di Moneybird, bersamaan dengan entri yang benar yang sudah ada di bawah proyek lama.

Yang Eve inginkan:

• Melihat apa yang baru saja disinkronkan — ringkasan yang menunjukkan berapa banyak entri yang dibuat atau diperbarui, untuk hari apa, di bawah proyek mana.
• Membatalkan: baik ekstensi menghapus entri yang dibuat secara salah, atau dengan jelas memberi tahu dia ID entri mana yang harus dibersihkan secara manual.

Bagaimana Vibes to Bucks menanganinya: Setelah setiap sinkronisasi, ekstensi menunjukkan notifikasi: “Disinkronkan ke Moneybird — Dibuat 87, diperbarui 2, dilewati 14.” Mengklik “Tampilkan detail” membuka Sync Ledger — tampilan khusus yang menunjukkan setiap entri yang disinkronkan dan tertunda, dapat difilter berdasarkan klien, proyek, dan tanggal. Eve dapat melihat dengan tepat entri mana yang baru saja dibuat, memilih yang salah, dan mengklik “Batalkan sinkronisasi.” Ekstensi menghapus entri tersebut dari Moneybird dan menandainya sebagai tertunda lagi sehingga dapat disinkronkan kembali dengan benar setelah dia memperbaiki aturan.

Skenario 6 — Penagihan proyek sementara

Siapa: Frank, seorang pengembang yang bekerja pada github.com/acme/api.

Apa yang terjadi: Frank biasanya menagih ke proyek “API Maintenance”. Selama dua minggu di bulan Maret, dia berada dalam sprint khusus yang ditagih ke “API v2 Migration”. Setelah sprint, dia beralih kembali.

Yang Frank inginkan:

• Mengubah aturan penagihan ke “API v2 Migration” pada 10 Maret.
• Mengubahnya kembali ke “API Maintenance” pada 24 Maret.
• Hanya jendela 10–23 Maret yang disinkronkan ke “API v2 Migration”.
• Semua sebelum 10 Maret dan setelah 23 Maret disinkronkan ke “API Maintenance”.
• Tidak ada kekacauan retroaktif ke arah mana pun.

Bagaimana Vibes to Bucks menanganinya: Kedua kali Frank mengubah aturan penagihan, dia memilih “Terapkan mulai hari ini”. Pada 10 Maret, aturan mulai menagih ke “API v2 Migration”. Pada 24 Maret, aturan beralih kembali ke “API Maintenance”. Setiap periode entri tetap dengan proyek yang aktif pada saat itu.

Skenario 7 — Berhenti menagih, tetap melacak

Siapa: Gina, seorang freelancer yang menyelesaikan pekerjaan dengan Klien Eta.

Apa yang terjadi: Kontrak sudah berakhir, tetapi Gina masih melakukan pemeliharaan kecil pada repo Eta. Dia ingin melihat biaya AI di dasbornya — untuk menilai apakah kontrak baru akan bermanfaat — tetapi dia tidak ingin menyinkronkan entri waktu apa pun.

Yang Gina inginkan:

• Tandai aturan penagihan sebagai tidak dapat ditagih secara permanen (bukan toggle sementara — pengaturan yang bertahan lama).
• Dasbor masih menunjukkan biaya yang diatribusikan ke Klien Eta.
• Sinkronisasi sepenuhnya melewati aturan penagihan ini.
• Jika Eta kembali dengan kontrak baru, dia mengaktifkannya kembali ke dapat ditagih dan hanya menyinkronkan dari titik itu ke depan — bukan periode celah.

Bagaimana Vibes to Bucks menanganinya: Gina menghapus centang “Billable” pada aturan penagihan Eta. Biaya terus dilacak dan muncul di dasbor di bawah Eta, tetapi tidak ada entri waktu yang dibuat. Ketika kontrak baru tiba, dia mengaktifkan kembali penagihan dan memilih “Terapkan mulai hari ini”. Celah yang tidak dapat ditagih tetap tidak ditagih.

Skenario 8 — Migrasi penyedia

Siapa: Hugo, seorang freelancer yang telah menyinkronkan ke Moneybird selama 6 bulan.

Apa yang terjadi: Firma akuntansi Hugo memindahkannya ke Harvest. Dia mengubah destination: harvest dalam konfigurasinya dan mengatur aturan penagihan Harvest baru.

Yang Hugo inginkan:

• Ke depan, sinkronisasi pergi ke Harvest.
• 6 bulan entri Moneybird tetap tidak tersentuh.
• Tidak ada entri retroaktif yang dibuat di Harvest untuk periode historis.

Bagaimana Vibes to Bucks menanganinya: Ketika Hugo mengganti penyedia penagihan, ekstensi mendeteksi bahwa Harvest tidak memiliki riwayat sinkronisasi. Tanpa panduan, itu akan mencoba membuat entri untuk setiap hari historis. Sebaliknya, dialog tiga opsi yang sama muncul: “Mulai baru dari hari ini”, “Sinkronkan semua sejarah”, atau “Sinkronkan hanya hari-hari yang belum disinkronkan.” Hugo memilih “Mulai baru.” Ekstensi menetapkan tanggal batas migrasi sehingga mesin sinkronisasi melewati semua hari sebelum hari ini. Hanya hari ini dan hari-hari mendatang yang membuat entri Harvest. Entri Moneybird-nya tidak tersentuh.

Skenario 9 — Penghapusan aturan yang tidak disengaja

Siapa: Ivan, seorang freelancer yang menagih repo Klien Kappa.

Apa yang terjadi: Ivan bermaksud mengedit aturan penagihannya untuk mengubah tarif per jam, tetapi secara tidak sengaja menghapusnya. Dia segera menyadari dan membuat ulang aturan dengan pengaturan yang benar.

Yang Ivan inginkan:

• Membuat ulang aturan tanpa menyebabkan bulan-bulan entri waktu duplikat di Moneybird.
• Entri masa lalu yang sudah disinkronkan harus tetap tidak tersentuh.
• Penagihan harus berlanjut dengan lancar seolah tidak ada yang terjadi.

Risiko tanpa panduan: Ivan membuat aturan baru. Ekstensi melihat repo dengan data biaya historis dan tidak ada riwayat aturan penagihan yang cocok. Sinkronisasi naif akan memperlakukan setiap hari sebelumnya sebagai “tidak pernah disinkronkan di bawah aturan ini” dan membuat entri untuk seluruh sejarah.

Bagaimana Vibes to Bucks menanganinya: Ketika Ivan membuat aturan penagihan untuk repo yang sudah memiliki data biaya historis di buku besar, ekstensi mengenali ini dan menyajikan dialog tiga opsi yang sama. Ivan memilih “Terapkan mulai hari ini” — entri masa lalu tetap seperti sebelumnya, dan penagihan dilanjutkan dari hari ini. Tidak ada duplikat, tidak ada celah, tidak ada panik.

Benang merah

Setiap skenario di atas berujung pada satu pertanyaan: ketika Anda mengubah aturan penagihan, apa yang harus terjadi pada masa lalu?

Vibes to Bucks tidak pernah membuat keputusan itu untuk Anda. Setiap kali Anda mengedit aturan penagihan — mengubah klien, proyek, tarif, atau status dapat ditagih — ekstensi meminta Anda untuk memilih:

Pilihan yang dipandu ini muncul dalam dialog yang jelas setiap kali perubahan aturan penagihan akan memengaruhi bagaimana biaya historis ditangani. Tidak ada kejutan, tidak ada penagihan ulang retroaktif diam-diam, tidak ada duplikat yang terabaikan.