سيناريوهات الفوترة في العالم الواقعي

حياة الفوترة لكل مستقل أكثر تعقيدًا مما يوحي به ملف الإعدادات النظيف. العملاء يتغيرون، العقود تتجدد، تحدث الأخطاء، وأحيانًا تقوم بعمل لا ترغب في تحصيل رسوم عليه. تصف هذه السيناريوهات مواقف حقيقية وكيفية تعامل ‘Vibes to Bucks’ مع كل منها.

السيناريو 1 — تجديد العقد: نفس العميل، مشروع جديد

من: آنا، مطورة مستقلة تعمل على github.com/acme/website لصالح العميل Acme.

ما حدث: كانت آنا تقوم بفوترة تكاليف الذكاء الاصطناعي لمشروع Moneybird “Acme Website Q1–Q2” منذ يناير. في الأول من يوليو، يبدأ عقد جديد لمدة 6 أشهر. يتغير مشروع العميل في Moneybird إلى “Acme Website Q3–Q4” — ربما مع معدل ساعي مختلف. المستودع والفرع هما نفسهما.

ما تريده آنا:

• من الأول من يوليو فصاعدًا، تتزامن جميع تكاليف الذكاء الاصطناعي الجديدة مع المشروع الجديد.
• تبقى الستة أشهر من إدخالات الوقت الموجودة بالفعل في Moneybird تحت المشروع القديم كما هي.
• تذهب تكلفة اليوم إلى المشروع الجديد.

الخطر بدون توجيه: تغير آنا قاعدة الفوترة الخاصة بها وتقوم بتشغيل المزامنة الآن. يقوم الامتداد بإعادة تجميع الفترة من يناير إلى يونيو، ولا يرى أي إدخالات زمنية لتلك الأيام تحت المشروع الجديد، ويقوم بإنشاء 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.

ما حدث: كانت كلارا تقوم بفوترة كل عمل الذكاء الاصطناعي لمشروع شامل “التطوير العام”. الآن يريد Gamma تقسيم التكاليف حسب منطقة الميزة. تقوم كلارا بإنشاء قواعد فوترة تعتمد على الفروع: feature/auth/* → “وحدة المصادقة” وfeature/billing/* → “وحدة الفوترة”.

3a — تقسيم للأمام فقط

ما تريده كلارا: من الآن فصاعدًا، تُوجه التكاليف إلى المشروع الفرعي الصحيح. تبقى التكاليف السابقة المتزامنة تحت “التطوير العام” كما هي.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: عندما تضيف كلارا قواعد الفروع الجديدة، يسأل الامتداد عن التاريخ لكل منها. تختار “تطبيق من اليوم فصاعدًا” لكليهما. تبقى الإدخالات التاريخية تحت “التطوير العام” دون تغيير.

3b — دقة تاريخية

ما تريده كلارا: تريد في الواقع نقل التكاليف السابقة إلى المشاريع الفرعية الصحيحة بأثر رجعي. تقبل أنها ستقوم بحذف الإدخالات القديمة “التطوير العام” يدويًا في Moneybird.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: تختار كلارا “تطبيق على كل الوقت” للقواعد الجديدة. يحذر الامتداد من الإدخالات الموجودة تحت المشروع القديم ويقوم بإنشاء إدخالات صحيحة لكل مشروع فرعي لكل يوم. تقوم كلارا بتنظيف الإدخالات القديمة في Moneybird.

السيناريو 4 — عمل مجاملة غير قابل للفوترة

من: ديفيد، مستقل يعمل على مستودع العميل Delta.

ما حدث: يتم استدعاء ديفيد لمراجعة كود داخلي وبعض التجارب التي ليست جزءًا من نطاق Delta — لكنه يبقي Cursor مفتوحًا على مستودعهم. لا يريد أن تُحسب الساعتان التاليتان من تكاليف الذكاء الاصطناعي على Delta.

ما يريده ديفيد:

• تبديل قاعدة فوترة Delta إلى وضع “غير قابل للفوترة”. يظهر مؤشر مرئي في شريط الحالة يؤكد أن القاعدة غير قابلة للفوترة.
• لا تزال تكاليف الذكاء الاصطناعي تُتبع وتظهر على لوحة التحكم — يريد أن يرى ما تكلفه هذا العمل المجامل — ولكن يتم تمييزها على أنها غير قابلة للفوترة.
• كل ساعة، إشعار تذكير: “قاعدة فوترة Delta غير قابلة للفوترة لمدة ساعتين. هل لا تزال تعمل غير قابل للفوترة؟”
• عندما يعيد التبديل إلى قابل للفوترة، تستأنف المزامنة العادية.
• تظهر التكاليف غير القابلة للفوترة على لوحة التحكم تحت Delta ولكنها متميزة بوضوح عن التكاليف القابلة للفوترة.

لماذا لكل تعيين، وليس بشكل عام: قد يكون ديفيد يعمل على عدة مهام في نفس الوقت. إذا انتقل إلى مستودع العميل Beta بينما Delta غير قابل للفوترة، يجب أن يظل Beta قابلًا للفوترة بشكل طبيعي. غير القابل للفوترة هو قرار مجاملة لكل عميل: “هذه التكلفة التي أقوم بها ليست طلب العميل — أنا أفعل ذلك لهم كمجاملة.”

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: يفتح ديفيد لوحة الإعدادات ويقوم بتبديل قاعدة فوترة Delta إلى غير قابل للفوترة. يسأل حوار عن شيئين: متى يجب أن يبدأ غير القابل للفوترة (الآن، أو بأثر رجعي)، ومتى يجب أن ينتهي. يختار ديفيد “من الآن” و**“نهاية اليوم”** — تستأنف الفوترة تلقائيًا غدًا. يظهر شريط الحالة $4.23 اليوم · Delta [غير قابل للفوترة حتى نهاية اليوم] بينما يعمل في مستودع Delta. لا تزال التكاليف غير القابلة للفوترة تتزامن مع Moneybird كإدخالات زمنية غير قابلة للفوترة (مرئية في السجلات ولكن مستبعدة من فواتير العميل). تعرض لوحة التحكم التكاليف القابلة للفوترة وغير القابلة للفوترة لـ Delta، مفصولة بوضوح.

إذا توقع ديفيد أن يستمر العمل المجامل لفترة أطول، يمكنه اختيار “تاريخ محدد” (على سبيل المثال، غير قابل للفوترة حتى الجمعة) أو “حتى أستأنف يدويًا” مع فترة تذكير (كل 30 دقيقة، 1 ساعة، 2 ساعة، إلخ) حتى لا ينسى إعادة تشغيل الفوترة.

تنويع — غير قابل للفوترة بأثر رجعي

ما يريده ديفيد: نسي التبديل قبل البدء. يريد وضع علامة على آخر 90 دقيقة كغير قابلة للفوترة بعد الواقعة.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: يفتح ديفيد لوحة الإعدادات، يبدل Delta إلى غير قابل للفوترة، وتحت قسم البداية يختار “بأثر رجعي” مع وقت 90 دقيقة مضت. يتم تمييز التكاليف من تلك النقطة فصاعدًا كغير قابلة للفوترة. إذا كان إدخال الوقت لليوم قد تم مزامنته بالفعل مع Moneybird، يقوم الامتداد بإعادة الحساب وتحديثه ليعكس المبلغ القابل للفوترة المخفض. يتم تحديد البأثر الرجعي لليوم — لتصحيحات متعددة الأيام، يوفر دفتر المزامنة أدوات التراجع وإعادة المزامنة.

السيناريو 5 — التراجع عن مزامنة غير صحيحة

من: إيف، مستقلة قامت بتغيير تعيين وقامت بتشغيل المزامنة الآن فورًا.

ما حدث: قامت إيف بتحرير قاعدة فوترة (تغيير المشروع) وقامت بتشغيل المزامنة الآن دون التفكير في العواقب. قام الامتداد بإنشاء 3 أشهر من إدخالات الوقت الجديدة تحت المشروع الخاطئ في Moneybird، بجانب الإدخالات الصحيحة الموجودة تحت المشروع القديم.

ما تريده إيف:

• رؤية ما تم مزامنته للتو — ملخص يوضح عدد الإدخالات التي تم إنشاؤها أو تحديثها، لأي أيام، تحت أي مشروع.
• التراجع: إما أن يقوم الامتداد بحذف الإدخالات التي تم إنشاؤها بشكل غير صحيح، أو يخبرها بوضوح عن معرفات الإدخال التي يجب تنظيفها يدويًا.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: بعد كل مزامنة، يعرض الامتداد إشعارًا: “تمت المزامنة مع Moneybird — تم إنشاء 87، تم تحديث 2، تم تخطي 14.” النقر على “عرض التفاصيل” يفتح دفتر المزامنة — عرض مخصص يعرض كل إدخال متزامن ومعلق، قابل للتصفية حسب العميل، المشروع، والتاريخ. يمكن لإيف رؤية بالضبط أي الإدخالات تم إنشاؤها للتو، تحديد الإدخالات غير الصحيحة، والنقر على “التراجع عن المزامنة.” يقوم الامتداد بحذف تلك الإدخالات من Moneybird ويضع علامة عليها كمعلقة مرة أخرى حتى يمكن إعادة مزامنتها بشكل صحيح بعد أن تصلح القاعدة.

السيناريو 6 — فوترة المشروع المؤقتة

من: فرانك، مطور يعمل على github.com/acme/api.

ما حدث: عادةً ما يقوم فرانك بالفوترة لمشروع “صيانة API”. لمدة أسبوعين في مارس، يكون في سباق خاص يتم فوترة لـ “ترحيل API v2”. بعد السباق، يعود إلى الوضع الطبيعي.

ما يريده فرانك:

• تغيير قاعدة الفوترة إلى “ترحيل API v2” في 10 مارس.
• تغييرها مرة أخرى إلى “صيانة API” في 24 مارس.
• فقط نافذة 10–23 مارس تتزامن مع “ترحيل API v2”.
• كل شيء قبل 10 مارس وبعد 23 مارس يتزامن مع “صيانة API”.
• لا فوضى بأثر رجعي في أي اتجاه.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: في كل مرة يغير فرانك قاعدة الفوترة، يختار “تطبيق من اليوم فصاعدًا”. في 10 مارس، تبدأ القاعدة بالفوترة لـ “ترحيل API v2”. في 24 مارس، تعود إلى “صيانة API”. تبقى إدخالات كل فترة مع المشروع الذي كان نشطًا في ذلك الوقت.

السيناريو 7 — إيقاف الفوترة، استمرار التتبع

من: جينا، مستقلة تنهي العمل مع العميل Eta.

ما حدث: انتهى العقد، لكن جينا لا تزال تقوم بصيانة بسيطة على مستودع Eta. تريد رؤية تكاليف الذكاء الاصطناعي في لوحة التحكم الخاصة بها — لتقييم ما إذا كان العقد الجديد سيكون مجديًا — لكنها لا تريد مزامنة أي إدخالات زمنية.

ما تريده جينا:

• وضع علامة على قاعدة الفوترة كغير قابلة للفوترة بشكل دائم (ليس تبديلًا مؤقتًا — إعداد دائم).
• لا تزال لوحة التحكم تعرض التكاليف المنسوبة إلى العميل Eta.
• تتخطى المزامنة هذه القاعدة تمامًا.
• إذا عاد Eta بعقد جديد، تقوم بتبديلها مرة أخرى إلى قابل للفوترة وتزامن فقط من تلك النقطة فصاعدًا — وليس فترة الفجوة.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: تقوم جينا بإلغاء تحديد “قابل للفوترة” على قاعدة فوترة Eta. تستمر التكاليف في التتبع وتظهر على لوحة التحكم تحت Eta، لكن لا يتم إنشاء أي إدخالات زمنية. عندما يصل عقد جديد، تعيد تمكين الفوترة وتختار “تطبيق من اليوم فصاعدًا”. تبقى فجوة غير القابلة للفوترة غير مفوترة.

السيناريو 8 — ترحيل المزود

من: هوجو، مستقل كان يقوم بالمزامنة مع Moneybird لمدة 6 أشهر.

ما حدث: قامت شركة المحاسبة الخاصة بهوجو بنقله إلى Harvest. يغير destination: harvest في إعداداته ويقوم بإعداد قواعد فوترة جديدة لـ Harvest.

ما يريده هوجو:

• من الآن فصاعدًا، تذهب المزامنة إلى Harvest.
• تبقى الأشهر الستة من إدخالات Moneybird دون تغيير.
• لا يتم إنشاء إدخالات بأثر رجعي في Harvest للفترة التاريخية.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: عندما يقوم هوجو بتغيير مزود الفوترة، يكتشف الامتداد أن Harvest ليس لديه تاريخ مزامنة. بدون توجيه، سيحاول إنشاء إدخالات لكل يوم تاريخي. بدلاً من ذلك، يظهر نفس الحوار ذو الخيارات الثلاثة: “ابدأ من اليوم”، “زامن كل التاريخ”، أو “زامن فقط الأيام غير المتزامنة.” يختار هوجو “ابدأ من اليوم”. يقوم الامتداد بتعيين تاريخ قطع للترحيل بحيث يتخطى محرك المزامنة جميع الأيام قبل اليوم. فقط اليوم والأيام المستقبلية تنشئ إدخالات Harvest. تبقى إدخالات Moneybird دون تغيير.

السيناريو 9 — حذف قاعدة بالخطأ

من: إيفان، مستقل يقوم بفوترة مستودع العميل Kappa.

ما حدث: كان إيفان ينوي تحرير قاعدة الفوترة لتغيير المعدل الساعي، لكنه حذفها بالخطأ بدلاً من ذلك. يلاحظ فورًا ويعيد إنشاء القاعدة بالإعدادات الصحيحة.

ما يريده إيفان:

• إعادة إنشاء القاعدة دون التسبب في إدخالات زمنية مكررة في Moneybird.
• تبقى الإدخالات السابقة التي تم مزامنتها بالفعل دون تغيير.
• تستمر الفوترة بسلاسة كما لو لم يحدث شيء.

الخطر بدون توجيه: يقوم إيفان بإنشاء القاعدة الجديدة. يرى الامتداد مستودعًا به بيانات تكلفة تاريخية ولا يوجد تاريخ لقاعدة الفوترة المطابقة. ستعامل المزامنة الساذجة كل يوم ماضٍ على أنه “لم يتم مزامنته أبدًا تحت هذه القاعدة” وتقوم بإنشاء إدخالات لكل التاريخ.

كيف يتعامل ‘Vibes to Bucks’ مع الأمر: عندما يقوم إيفان بإنشاء قاعدة فوترة لمستودع يحتوي بالفعل على بيانات تكلفة تاريخية في الدفتر، يتعرف الامتداد على ذلك ويقدم نفس الحوار ذو الخيارات الثلاثة. يختار إيفان “تطبيق من اليوم فصاعدًا” — تبقى الإدخالات السابقة كما هي، وتستأنف الفوترة من اليوم. لا تكرارات، لا فجوة، لا ذعر.

الخيط المشترك

كل سيناريو أعلاه ينحصر في سؤال واحد: عندما تقوم بتغيير قاعدة الفوترة، ماذا يجب أن يحدث للماضي؟

‘Vibes to Bucks’ لا يتخذ هذا القرار نيابة عنك أبدًا. في كل مرة تقوم بتحرير قاعدة فوترة — تغيير العميل، المشروع، المعدل، أو حالة الفوترة — يسألك الامتداد لتختار:

يظهر هذا الاختيار الموجه في حوار واضح كلما كان تغيير قاعدة الفوترة سيؤثر على كيفية التعامل مع التكاليف التاريخية. لا مفاجآت، لا إعادة فوترة بأثر رجعي صامتة، لا تكرارات يتيمة.