वास्तविक दुनिया के बिलिंग परिदृश्य

हर फ्रीलांसर का बिलिंग जीवन एक साफ़ config फ़ाइल से अधिक उलझा हुआ होता है। क्लाइंट बदलते हैं, कॉन्ट्रैक्ट्स रिन्यू होते हैं, गलतियाँ होती हैं, और कभी-कभी आप ऐसा काम करते हैं जिसके लिए आप चार्ज नहीं करना चाहते। ये परिदृश्य वास्तविक स्थितियों का वर्णन करते हैं और Vibes to Bucks कैसे प्रत्येक स्थिति को संभालता है।

परिदृश्य 1 — कॉन्ट्रैक्ट रिन्यूअल: वही क्लाइंट, नया प्रोजेक्ट

कौन: अन्ना, एक फ्रीलांस डेवलपर जो github.com/acme/website पर क्लाइंट Acme के लिए काम कर रही है।

क्या हुआ: अन्ना जनवरी से Moneybird प्रोजेक्ट “Acme Website Q1–Q2” के लिए AI लागत बिल कर रही है। 1 जुलाई से, एक नया 6-महीने का कॉन्ट्रैक्ट शुरू होता है। क्लाइंट का Moneybird प्रोजेक्ट “Acme Website Q3–Q4” में बदल जाता है — संभवतः एक अलग प्रति घंटा दर के साथ। रिपॉजिटरी और ब्रांच वही रहते हैं।

अन्ना क्या चाहती है:

• 1 जुलाई से, सभी नई AI लागतें नए प्रोजेक्ट के साथ सिंक हों।
• पुराने प्रोजेक्ट के तहत Moneybird में पहले से मौजूद छह महीने के समय प्रविष्टियाँ वहीं रहें।
• आज की लागत नए प्रोजेक्ट में जाए।

मार्गदर्शन के बिना जोखिम: अन्ना अपनी बिलिंग नियम बदलती है और Sync Now चलाती है। एक्सटेंशन जनवरी से जून तक फिर से एकत्र करता है, उन दिनों के लिए नए प्रोजेक्ट के तहत कोई समय प्रविष्टि नहीं देखता है, और Moneybird में 180 डुप्लिकेट प्रविष्टियाँ बनाता है — पुराने प्रोजेक्ट के तहत पहले से मौजूद प्रविष्टियों के साथ।

Vibes to Bucks इसे कैसे संभालता है: जब अन्ना अपने बिलिंग नियम को नए प्रोजेक्ट की ओर इंगित करने के लिए संपादित करती है, तो एक्सटेंशन उससे पूछता है कि ऐतिहासिक लागतों के साथ क्या होना चाहिए। वह “आज से लागू करें” चुनती है। पिछले दिन अपनी पुरानी परियोजना के साथ जुड़े रहते हैं। केवल आज और भविष्य के दिन नए प्रोजेक्ट के तहत सिंक होते हैं। कोई डुप्लिकेट नहीं, कोई सफाई की आवश्यकता नहीं।

परिदृश्य 2 — क्लाइंट स्विच: एक रिपो को एक अलग क्लाइंट में स्थानांतरित करना

कौन: बेन, एक डेवलपर जो github.com/org/platform पर काम कर रहा है।

क्या हुआ: बेन ने शुरू में इस रिपो को क्लाइंट अल्फा के लिए बिल किया, जिसने R&D चरण को वित्त पोषित किया। प्लेटफ़ॉर्म अब उत्पादन में है और क्लाइंट बीटा चल रहे ग्राहक हैं। बेन को रिपॉजिटरी को फिर से मैप करने की आवश्यकता है।

2a — क्लीन ब्रेक

बेन क्या चाहता है: भविष्य की लागतें क्लाइंट बीटा को जाएं। क्लाइंट अल्फा के लिए सिंक की गई पिछली प्रविष्टियाँ अछूती रहें। कुछ भी पूर्वव्यापी नहीं।

Vibes to Bucks इसे कैसे संभालता है: बेन बिलिंग नियम के संपर्क को अल्फा से बीटा में बदलता है। एक्सटेंशन पूछता है कि इतिहास के साथ क्या होना चाहिए। वह “आज से लागू करें” चुनता है। अल्फा की ऐतिहासिक प्रविष्टियाँ Moneybird में बनी रहती हैं। बीटा आज से प्रविष्टियाँ प्राप्त करना शुरू करता है।

2b — पूर्ण पूर्वव्यापी सुधार

बेन क्या चाहता है: अल्फा बिलिंग एक गलती थी — यह सब शुरू से ही बीटा होना चाहिए था। बेन सब कुछ बीटा के तहत फिर से सिंक करना चाहता है। वह स्वीकार करता है कि उसे Moneybird में अल्फा की प्रविष्टियों को मैन्युअल रूप से साफ करना होगा।

Vibes to Bucks इसे कैसे संभालता है: बेन “सभी समय के लिए लागू करें” चुनता है। एक्सटेंशन उसे चेतावनी देता है कि अल्फा के तहत मौजूदा प्रविष्टियाँ स्वचालित रूप से हटाई नहीं जाएंगी — उसे उन्हें Moneybird में हटाना होगा। फिर यह बीटा के तहत हर ऐतिहासिक दिन के लिए नई प्रविष्टियाँ बनाता है।

2c — केवल अंतराल को सिंक करें

बेन क्या चाहता है: बेन ने दो सप्ताह पहले सिंक करना बंद कर दिया था जब उसे एहसास हुआ कि मैपिंग गलत थी। उसके पास लेजर में 14 दिनों की असिंक लागत है। वह चाहता है कि वे 14 दिन बीटा को जाएं, लेकिन अल्फा के लिए पहले से सिंक किए गए महीने वहीं रहें।

Vibes to Bucks इसे कैसे संभालता है: बेन “केवल असिंक दिनों के लिए लागू करें” चुनता है। एक्सटेंशन जानता है कि किन दिनों में पहले से ही provider_posts में एक समय प्रविष्टि है और उन्हें छोड़ देता है। केवल 14 असिंक दिन बीटा के तहत बनाए जाते हैं।

परिदृश्य 3 — प्रोजेक्ट विभाजन: उप-प्रोजेक्ट्स में काम का पुनर्वितरण

कौन: क्लारा, एक डेवलपर जो क्लाइंट गामा के लिए एक मोनोरेपो पर काम कर रही है।

क्या हुआ: क्लारा ने सभी AI कार्यों को एक कैच-ऑल प्रोजेक्ट “जनरल डेवलपमेंट” में बिल किया है। गामा अब लागतों को फीचर क्षेत्र के अनुसार तोड़ना चाहता है। क्लारा ब्रांच-आधारित बिलिंग नियम बनाती है: feature/auth/* → “ऑथ मॉड्यूल” और feature/billing/* → “बिलिंग मॉड्यूल”।

3a — केवल आगे का विभाजन

क्लारा क्या चाहती है: आगे बढ़ते हुए, लागतें सही उप-प्रोजेक्ट में जाएं। “जनरल डेवलपमेंट” के तहत पहले से सिंक की गई लागतें वहीं रहें।

Vibes to Bucks इसे कैसे संभालता है: जब क्लारा नए ब्रांच नियम जोड़ती है, तो एक्सटेंशन प्रत्येक के लिए इतिहास के बारे में पूछता है। वह दोनों के लिए “आज से लागू करें” चुनती है। “जनरल डेवलपमेंट” के तहत ऐतिहासिक प्रविष्टियाँ अछूती रहती हैं।

3b — ऐतिहासिक सटीकता

क्लारा क्या चाहती है: वह वास्तव में चाहती है कि पिछली लागतों को सही उप-प्रोजेक्ट्स में स्थानांतरित किया जाए। वह स्वीकार करती है कि वह Moneybird में पुराने “जनरल डेवलपमेंट” प्रविष्टियों को मैन्युअल रूप से हटा देगी।

Vibes to Bucks इसे कैसे संभालता है: क्लारा नए नियमों के लिए “सभी समय के लिए लागू करें” चुनती है। एक्सटेंशन पुराने प्रोजेक्ट के तहत मौजूदा प्रविष्टियों के बारे में चेतावनी देता है और प्रति दिन प्रति उप-प्रोजेक्ट सही प्रविष्टियाँ बनाता है। क्लारा Moneybird में पुरानी प्रविष्टियों को साफ करती है।

परिदृश्य 4 — अनबिलेबल शिष्टाचार कार्य

कौन: डेविड, एक फ्रीलांसर जो क्लाइंट डेल्टा के रिपो पर काम कर रहा है।

क्या हुआ: डेविड को एक आंतरिक कोड समीक्षा और कुछ प्रयोगों में खींच लिया जाता है जो डेल्टा के दायरे का हिस्सा नहीं हैं — लेकिन वह उनके रिपो पर Cursor खुला रखता है। वह नहीं चाहता कि अगले 2 घंटे की AI लागत डेल्टा को चार्ज की जाए।

डेविड क्या चाहता है:

• डेल्टा बिलिंग नियम को “अनबिलेबल” मोड में टॉगल करें। स्टेटस बार में एक दृश्य संकेतक पुष्टि करता है कि नियम अनबिलेबल है।
• AI लागतें अभी भी डैशबोर्ड पर ट्रैक और दिखाई देती हैं — वह देखना चाहता है कि यह शिष्टाचार कार्य उसे कितना खर्च कर रहा है — लेकिन बिलिंग के लिए चिह्नित नहीं।
• हर घंटे, एक रिमाइंडर नोटिफिकेशन: “डेल्टा बिलिंग नियम 2 घंटे के लिए अनबिलेबल है। अभी भी अनबिलेबल काम कर रहे हैं?”
• जब वह वापस बिलेबल पर टॉगल करता है, सामान्य सिंकिंग फिर से शुरू होती है।
• अनबिलेबल लागतें डेल्टा के तहत डैशबोर्ड पर दिखाई देती हैं लेकिन बिलेबल लागतों से स्पष्ट रूप से अलग होती हैं।

क्यों प्रति-मैपिंग, न कि वैश्विक: डेविड मल्टीटास्किंग कर सकता है। यदि वह डेल्टा अनबिलेबल रहते हुए क्लाइंट बीटा के रिपो पर स्विच करता है, तो बीटा को सामान्य रूप से बिल करना चाहिए। अनबिलेबल एक प्रति-क्लाइंट शिष्टाचार निर्णय है: “यह लागत मैं बना रहा हूँ वह क्लाइंट की मांग नहीं है — मैं यह उनके लिए शिष्टाचार के रूप में कर रहा हूँ।”

Vibes to Bucks इसे कैसे संभालता है: डेविड सेटिंग्स पैनल खोलता है और डेल्टा के बिलिंग नियम को अनबिलेबल पर टॉगल करता है। एक डायलॉग दो चीजें पूछता है: अनबिलेबल कब शुरू होना चाहिए (अभी, या बैकडेटेड), और यह कब समाप्त होना चाहिए। डेविड “अभी से” और “आज के अंत तक” चुनता है — बिलिंग कल स्वचालित रूप से फिर से शुरू होती है। स्टेटस बार दिखाता है $4.23 आज · डेल्टा [आज के अंत तक अनबिलेबल] जबकि वह डेल्टा के रिपो में काम करता है। अनबिलेबल लागतें अभी भी Moneybird में गैर-बिलेबल समय प्रविष्टियों के रूप में सिंक होती हैं (रिकॉर्ड में दिखाई देती हैं लेकिन क्लाइंट इनवॉइसिंग से बाहर होती हैं)। डैशबोर्ड डेल्टा के लिए बिलेबल और अनबिलेबल दोनों लागतें दिखाता है, स्पष्ट रूप से अलग।

यदि डेविड को उम्मीद है कि शिष्टाचार कार्य अधिक समय तक चलेगा, तो वह “विशिष्ट तिथि” (जैसे शुक्रवार तक अनबिलेबल) या “जब तक मैं मैन्युअल रूप से फिर से शुरू नहीं करता” एक रिमाइंडर अंतराल के साथ (हर 30 मिनट, 1 घंटा, 2 घंटे, आदि) चुन सकता है ताकि वह बिलिंग को फिर से चालू करना न भूले।

भिन्नता — पूर्वव्यापी अनबिलेबल

डेविड क्या चाहता है: वह शुरू करने से पहले टॉगल करना भूल गया। वह पिछले 90 मिनट को बाद में अनबिलेबल के रूप में चिह्नित करना चाहता है।

Vibes to Bucks इसे कैसे संभालता है: डेविड सेटिंग्स पैनल खोलता है, डेल्टा को अनबिलेबल पर टॉगल करता है, और शुरू अनुभाग के तहत “बैकडेट” के साथ 90 मिनट पहले का समय चुनता है। उस बिंदु से आगे की लागतें अनबिलेबल के रूप में चिह्नित होती हैं। यदि आज की समय प्रविष्टि पहले से ही Moneybird में सिंक हो गई थी, तो एक्सटेंशन इसे फिर से गणना करता है और इसे कम बिलेबल राशि को दर्शाने के लिए अपडेट करता है। बैकडेटिंग आज तक सीमित है — बहु-दिवसीय सुधारों के लिए, Sync Ledger पूर्ववत और पुनः सिंक नियंत्रण प्रदान करता है।

परिदृश्य 5 — एक गलत सिंक को पूर्ववत करें

कौन: ईव, एक फ्रीलांसर जिसने एक मैपिंग बदली और तुरंत Sync Now चलाया।

क्या हुआ: ईव ने एक बिलिंग नियम को संपादित किया (प्रोजेक्ट बदला) और Sync Now बिना परिणामों के बारे में सोचे चलाया। एक्सटेंशन ने Moneybird में गलत प्रोजेक्ट के तहत 3 महीने की नई समय प्रविष्टियाँ बनाई, पुराने प्रोजेक्ट के तहत पहले से मौजूद सही प्रविष्टियों के साथ।

ईव क्या चाहती है:

• देखना कि क्या सिंक हुआ — एक सारांश दिखाना कि कितनी प्रविष्टियाँ बनाई गईं या अपडेट की गईं, किन दिनों के लिए, किस प्रोजेक्ट के तहत।
• रोल बैक: या तो एक्सटेंशन गलत तरीके से बनाई गई प्रविष्टियों को हटा देता है, या यह स्पष्ट रूप से उसे बताता है कि कौन से प्रविष्टि IDs को मैन्युअल रूप से साफ करना है।

Vibes to Bucks इसे कैसे संभालता है: हर सिंक के बाद, एक्सटेंशन एक नोटिफिकेशन दिखाता है: “Moneybird को सिंक किया गया — 87 बनाई गईं, 2 अपडेट की गईं, 14 छोड़ी गईं।” “विवरण दिखाएं” पर क्लिक करने से Sync Ledger खुलता है — एक समर्पित दृश्य जो हर सिंक की गई और लंबित प्रविष्टि दिखाता है, जिसे क्लाइंट, प्रोजेक्ट, और तारीख के अनुसार फ़िल्टर किया जा सकता है। ईव देख सकती है कि कौन सी प्रविष्टियाँ अभी बनाई गईं, गलत प्रविष्टियों का चयन करें, और “सिंक पूर्ववत करें” पर क्लिक करें। एक्सटेंशन उन प्रविष्टियों को Moneybird से हटा देता है और उन्हें फिर से सही तरीके से सिंक करने के लिए लंबित के रूप में चिह्नित करता है।

परिदृश्य 6 — अस्थायी प्रोजेक्ट बिलिंग

कौन: फ्रैंक, एक डेवलपर जो github.com/acme/api पर काम कर रहा है।

क्या हुआ: फ्रैंक आमतौर पर “API Maintenance” प्रोजेक्ट को बिल करता है। मार्च में दो सप्ताह के लिए, वह “API v2 Migration” के लिए बिल किए गए एक विशेष स्प्रिंट पर है। स्प्रिंट के बाद, वह वापस स्विच करता है।

फ्रैंक क्या चाहता है:

• 10 मार्च को बिलिंग नियम को “API v2 Migration” में बदलें।
• 24 मार्च को इसे “API Maintenance” में वापस बदलें।
• केवल 10–23 मार्च की विंडो “API v2 Migration” के लिए सिंक होती है।
• 10 मार्च से पहले और 23 मार्च के बाद सब कुछ “API Maintenance” के लिए सिंक होता है।
• किसी भी दिशा में कोई पूर्वव्यापी गड़बड़ी नहीं।

Vibes to Bucks इसे कैसे संभालता है: दोनों बार फ्रैंक बिलिंग नियम बदलता है, वह “आज से लागू करें” चुनता है। 10 मार्च को, नियम “API v2 Migration” के लिए बिलिंग शुरू करता है। 24 मार्च को, यह “API Maintenance” में वापस स्विच करता है। प्रत्येक अवधि की प्रविष्टियाँ उस समय सक्रिय प्रोजेक्ट के साथ रहती हैं।

परिदृश्य 7 — बिलिंग बंद करें, ट्रैकिंग जारी रखें

कौन: जीना, एक फ्रीलांसर जो क्लाइंट एटा के साथ समाप्त हो रही है।

क्या हुआ: कॉन्ट्रैक्ट खत्म हो गया है, लेकिन जीना अभी भी एटा के रिपो पर मामूली रखरखाव करती है। वह अपने डैशबोर्ड में AI लागतें देखना चाहती है — यह आकलन करने के लिए कि क्या एक नया कॉन्ट्रैक्ट सार्थक होगा — लेकिन वह कोई समय प्रविष्टि सिंक नहीं करना चाहती।

जीना क्या चाहती है:

• बिलिंग नियम को स्थायी रूप से अनबिलेबल के रूप में चिह्नित करें (एक अस्थायी टॉगल नहीं — एक स्थायी सेटिंग)।
• डैशबोर्ड अभी भी क्लाइंट एटा के लिए लागतें दिखाता है।
• सिंक इस बिलिंग नियम को पूरी तरह से छोड़ देता है।
• यदि एटा एक नए कॉन्ट्रैक्ट के साथ वापस आता है, तो वह इसे बिलेबल में बदल देती है और केवल उस बिंदु से आगे सिंक करती है — न कि अंतराल अवधि।

Vibes to Bucks इसे कैसे संभालता है: जीना एटा के बिलिंग नियम पर “बिलेबल” अनचेक करती है। लागतें ट्रैक होती रहती हैं और एटा के तहत डैशबोर्ड पर दिखाई देती हैं, लेकिन कोई समय प्रविष्टियाँ नहीं बनाई जाती हैं। जब एक नया कॉन्ट्रैक्ट आता है, तो वह बिलिंग को फिर से सक्षम करती है और “आज से लागू करें” चुनती है। अनबिलेबल अंतराल बिना बिल किए रहता है।

परिदृश्य 8 — प्रोवाइडर माइग्रेशन

कौन: ह्यूगो, एक फ्रीलांसर जो 6 महीने से Moneybird को सिंक कर रहा है।

क्या हुआ: ह्यूगो की अकाउंटिंग फर्म उसे Harvest में स्विच करती है। वह अपने config में destination: harvest बदलता है और नए Harvest बिलिंग नियम सेट करता है।

ह्यूगो क्या चाहता है:

• आगे बढ़ते हुए, सिंक Harvest में जाता है।
• Moneybird प्रविष्टियों के 6 महीने अछूते रहते हैं।
• ऐतिहासिक अवधि के लिए Harvest में कोई पूर्वव्यापी प्रविष्टियाँ नहीं बनाई जाती हैं।

Vibes to Bucks इसे कैसे संभालता है: जब ह्यूगो बिलिंग प्रोवाइडर स्विच करता है, तो एक्सटेंशन यह पता लगाता है कि Harvest के पास कोई सिंक इतिहास नहीं है। बिना मार्गदर्शन के यह हर ऐतिहासिक दिन के लिए प्रविष्टियाँ बनाने की कोशिश करेगा। इसके बजाय, वही तीन-विकल्प डायलॉग दिखाई देता है: “आज से ताजा शुरू करें”, “सभी इतिहास सिंक करें”, या “केवल असिंक दिनों को सिंक करें।” ह्यूगो “ताजा शुरू करें” चुनता है। एक्सटेंशन एक माइग्रेशन कटऑफ तारीख सेट करता है ताकि सिंक इंजन आज से पहले के सभी दिनों को छोड़ दे। केवल आज और भविष्य के दिन Harvest प्रविष्टियाँ बनाते हैं। उसके Moneybird प्रविष्टियाँ अछूती रहती हैं।

परिदृश्य 9 — आकस्मिक नियम हटाना

कौन: इवान, एक फ्रीलांसर जो क्लाइंट कप्पा के रिपो को बिल कर रहा है।

क्या हुआ: इवान ने अपनी बिलिंग नियम को संपादित करने का इरादा किया था ताकि प्रति घंटा दर बदल सके, लेकिन गलती से इसे हटा दिया। वह तुरंत नोटिस करता है और सही सेटिंग्स के साथ नियम को फिर से बनाता है।

इवान क्या चाहता है:

• नियम को फिर से बनाएं बिना Moneybird में महीनों की डुप्लिकेट समय प्रविष्टियाँ बनाए।
• पहले से सिंक की गई पिछली प्रविष्टियाँ अछूती रहें।
• बिलिंग बिना किसी रुकावट के जारी रहे जैसे कुछ हुआ ही नहीं।

मार्गदर्शन के बिना जोखिम: इवान नया नियम बनाता है। एक्सटेंशन एक रिपो को ऐतिहासिक लागत डेटा के साथ देखता है और कोई मेल खाने वाला बिलिंग नियम इतिहास नहीं। एक नासमझ सिंक हर पिछले दिन को “इस नियम के तहत कभी सिंक नहीं किया गया” मानता और पूरे इतिहास के लिए प्रविष्टियाँ बनाता।

Vibes to Bucks इसे कैसे संभालता है: जब इवान एक रिपो के लिए बिलिंग नियम बनाता है जिसमें पहले से ही लेजर में ऐतिहासिक लागत डेटा होता है, तो एक्सटेंशन इसे पहचानता है और वही तीन-विकल्प डायलॉग प्रस्तुत करता है। इवान “आज से लागू करें” चुनता है — पिछली प्रविष्टियाँ वैसी ही रहती हैं, और बिलिंग आज से फिर से शुरू होती है। कोई डुप्लिकेट नहीं, कोई अंतराल नहीं, कोई घबराहट नहीं।

सामान्य धागा

ऊपर के प्रत्येक परिदृश्य का एक ही प्रश्न है: जब आप एक बिलिंग नियम बदलते हैं, तो अतीत के साथ क्या होना चाहिए?

Vibes to Bucks कभी भी आपके लिए यह निर्णय नहीं लेता। हर बार जब आप एक बिलिंग नियम संपादित करते हैं — क्लाइंट, प्रोजेक्ट, दर, या बिलेबल स्थिति बदलते हैं — एक्सटेंशन आपसे चुनने के लिए कहता है:

यह मार्गदर्शित विकल्प एक स्पष्ट डायलॉग में दिखाई देता है जब भी एक बिलिंग नियम परिवर्तन ऐतिहासिक लागतों को प्रभावित करेगा। कोई आश्चर्य नहीं, कोई मौन पूर्वव्यापी पुनः-बिलिंग नहीं, कोई अनाथ डुप्लिकेट नहीं।