مفت ماہانہ رینڈر کریڈٹس سب سے سستے پہلے کیسے لاگو ہوتے ہیں

دیکھیں کہ ہر بلنگ سائیکل کے مفت رینڈر کریڈٹس کیسے شمار ہوتے ہیں اور رینڈرز اور AI enhancements پر کیسے خرچ ہوتے ہیں، اور per-seat اسکیم میں کیا تبدیل ہوتا ہے۔

1. ہر بلنگ سائیکل میں ہر org کو اس کے لائسنسوں سے مفت رینڈر کریڈٹس ملتے ہیں: لائسنس صارفین کی تعداد × متناسب استعمال کا تناسب × ترتیب شدہ free-credits-per-license مقدار۔ یہ مفت کریڈٹس کچھ بھی وصول کرنے سے پہلے خودکار طور پر لاگو ہوتے ہیں، اور وہ سب سے سستے پہلے لاگو ہوتے ہیں: سائیکل کی تمام قابلِ بل اشیاء — رینڈرز اور AI enhancements (ہر ایک 0.2 کریڈٹس) ملا کر — کریڈٹ لاگت کے بڑھتے ہوئے ترتیب میں رکھی جاتی ہیں، اور مفت کریڈٹس اسی ترتیب سے انہیں جذب کرتے ہیں؛ حد پر موجود شے کو جزوی فیصد رعایت ملتی ہے۔ سائیکل کی وصول شدہ رقم max(0, کل استعمال شدہ کریڈٹس − کل مفت کریڈٹس) ہے۔ غیر استعمال شدہ مفت کریڈٹس اگلے سائیکل میں منتقل نہیں ہوتے (واحد carry-over grace-period settlement میں ہے، جہاں غیر ادا شدہ بلوں کے غیر استعمال شدہ complimentary کریڈٹس grace استعمال کا ازالہ کرتے ہیں)۔ لہٰذا اگر کوئی کلائنٹ پوچھے کہ ایک سستا رینڈر 100% رعایت کیوں دکھاتا ہے جبکہ مہنگا مکمل وصول ہوتا ہے، تو یہ سب سے سستے پہلے کی تقسیم ہے، کوئی خرابی نہیں۔ مفت کریڈٹس لائیو لائسنس ڈیٹا سے دوبارہ شمار ہوتے ہیں، اس لیے سائیکل کے دوران لائسنس شامل کرنے سے pool متناسب طور پر بڑھتا ہے۔

   وہ organisations جو نئی per-seat اسکیم پر منتقل ہو چکی ہیں مختلف طریقے سے کام کرتی ہیں: ہر seat کا اپنا ماہانہ allowance ہوتا ہے، اور ہر صارف کے رینڈرز اور AI enhancements صرف ان کے اپنے seat کے allowance پر وصول ہوتے ہیں — seats کے درمیان غیر استعمال شدہ allowance کا کوئی pooling نہیں، اور سب سے سستے پہلے کی ترتیب لاگو نہیں ہوتی۔ سائیکل کے دوران خریدے گئے لائسنس کے seats کو متناسب allowance ملتا ہے۔

2. جب کوئی رینڈر یا AI enhancement خرابی RENDER_OVERAGE_CAP_EXCEEDED کے ساتھ بلاک ہو، تو org نے render overage cap ترتیب دیا ہوا ہے اور اس job کا قابلِ وصول حصہ سائیکل کے paid render credits کو cap سے آگے بڑھا دے گا۔ یہ جانچ رینڈر شروع کرنے سے پہلے اور ہر AI enhancement (enhance، create-and-enhance، re-enhance) سے پہلے چلتی ہے۔ اہم باریکیاں: باقی مفت کریڈٹس سے مکمل ڈھکے رینڈرز پھر بھی گزر جاتے ہیں، اور 0-credit HD رینڈرز کبھی بلاک نہیں ہوتے، کیونکہ cap صرف ان کریڈٹس کو گنتا ہے جو واقعی وصول ہوں گے۔ کون سے مفت کریڈٹس لاگو ہوں گے یہ org کے بلنگ موڈ پر منحصر ہے: نئی per-seat اسکیم پر ہر صارف اپنے seat کے ماہانہ allowance سے لیتا ہے (سائیکل کے دوران لیے گئے seat کے لیے متناسب)، جبکہ پرانی اسکیم پر org ایک مشترکہ free-credit pool بانٹتی ہے۔ کیا کرنا ہے: catalog manager، project manager، یا accounts manager کردار رکھنے والا org صارف cap بڑھا یا ہٹا سکتا ہے (self-service store setting؛ اسے unset کرنے کا مطلب unlimited ہے)، یا کلائنٹ اگلے بلنگ سائیکل کا انتظار کر سکتا ہے، جب وصول شدہ استعمال صفر پر reset ہو جاتا ہے۔ per-seat اسکیم پر، وہ صارف جس نے اپنا seat allowance ختم کر لیا ہے، اسے کریڈٹس والے seat پر منتقل کیا جا سکتا ہے، یا اگر اس کے پاس seat نہیں تو اسے seat دیا جا سکتا ہے۔ کلائنٹ کو cap ہٹانے کا مشورہ دینے سے پہلے اس سے تصدیق کریں کہ آیا cap جان بوجھ کر بجٹ کنٹرول کے طور پر لگایا گیا تھا — بہت سی orgs اسے خاص طور پر حیران کن overage بل روکنے کے لیے لگاتی ہیں۔