خروجی اطلاعات آموزشگاه آنلاین را پیش از خرید چگونه آزمایش کنیم؟
با یک نمونهٔ کوچک، خروجی سفارش، مجوز و پیشرفت را بررسی کنید و ببینید آیا در مقصد دوباره قابل استفاده‌اند.
مدیر آموزشگاه از فروشنده می‌پرسد آیا اطلاعات دوره‌ها خروجی دارد. فروشنده یک فایل از فهرست هنرجویان نشان می‌دهد. هنگام بررسی معلوم می‌شود شناسهٔ سفارش، تاریخ انقضای دسترسی و وضعیت تمرین در فایل نیست. این فهرست شاید برای پیدا کردن نام‌ها کافی باشد، ولی تیم نمی‌تواند از روی آن تشخیص دهد چه کسی هنوز حق دیدن درس را دارد یا مبلغ کدام سفارش برگشت خورده است. برای آزمودن خروجی اطلاعات آموزشگاه آنلاین، از کاری شروع کنید که واقعاً قرار است بعداً با داده انجام دهید.
سه نمونه بگیرید. یکی برای فروش، یکی برای مجوز دوره و یکی برای پیشرفت درس. فایل‌ها را با شناسه‌های واقعی همان محیط آزمایشی به هم وصل کنید. یک بار هم چند ردیف را در مقصدی جدا باز یا وارد کنید و نتیجه را با پنل مبدا تطبیق دهید. در این مقاله همهٔ نام‌ها و اعداد ساختگی‌اند. هدف، طراحی آزمون پذیرش است. فهرست امکانات یا قالب خروجی یک سرویس را فقط بعد از مشاهدهٔ نمونهٔ همان پلن قطعی بنویسید. راهنمای عملیات آموزشگاه آنلاین
ابتدا بگویید داده قرار است چه کاری انجام دهد
واحد مالی شاید بخواهد فروش هر نوبت را با پرداخت و استرداد تطبیق دهد. پشتیبان برای پاسخ به هنرجو باید سفارش و مجوز او را پیدا کند. مدرس ممکن است بخواهد بداند کدام افراد تمرین پایان فصل را فرستاده‌اند. یک فایل واحد می‌تواند بخشی از نیاز هر سه را پوشش دهد، اما هر نیاز فیلد و زمان خودش را دارد. از هر نقش بخواهید یک سؤال روزمره بنویسد. سپس مشخص کنید پاسخ آن سؤال از کدام فایل و کدام ردیف به دست می‌آید.
مثلاً مسئول مالی می‌خواهد بداند مبلغ خالص فروش دورهٔ مکالمه در یک هفته چقدر بوده است. برای پاسخ به این سؤال، مبلغ سفارش و وضعیت پرداخت لازم‌اند. اگر سفارش بخشی مسترد شده، مبلغ برگشتی هم لازم است. اگر خرید در یک روز و تأیید در روز دیگری رخ داده، معیار تاریخ را از پیش تعریف کنید. گزارش فروش ایجادشده در هفته با گزارش پرداخت تأییدشده در همان هفته یک جمع واحد نمی‌دهد. این تفاوت را نزدیک عنوان گزارش بنویسید.
پشتیبان سؤال دیگری دارد. هنرجو چرا نمی‌تواند درس دوم را ببیند؟ این سؤال به حساب، دوره، بازه و وضعیت مجوز وابسته است. شاید پرداخت تأیید شده و هنوز مجوز ایجاد نشده باشد. شاید مجوز برقرار است ولی هنرجو با حساب دیگری وارد شده باشد. خروجی فروش به تنهایی همهٔ این حالت‌ها را پوشش نمی‌دهد. برای مدرس هم مشاهدهٔ خرید نشانهٔ تکمیل درس نیست. برای پیگیری آموزشی، نوع فعالیت و زمان آخرین رویداد را در منبع مربوط بررسی کنید.
دامنهٔ کار را برای آزمون کوچک نگه دارید. یک دوره، دو درس و چند حساب آزمایشی کافی‌اند. اگر آموزشگاه چند شعبه دارد، یک حساب از شعبهٔ دیگر اضافه کنید تا محدودیت دامنهٔ گزارش دیده شود. اگر فروش دوره به شرکت و فروش فردی متفاوت‌اند، یک نمونه از هر روش بردارید. در این مرحله دنبال استخراج همهٔ داده‌ها نباشید. ابتدا ببینید تیم می‌تواند پاسخ چند سؤال مشخص را بازسازی کند و برای هر مورد نام فایل و ستون لازم را بگوید.
برای هر فایل یک واحد شمارش و یک شناسه تعیین کنید
پیش از مقایسهٔ تعداد ردیف‌ها، بپرسید هر ردیف چیست. شاید فایل سفارش یک ردیف برای هر خرید داشته باشد و فایل پرداخت یک ردیف برای هر تلاش. در آن صورت دو تلاش برای یک خرید می‌تواند به دو ردیف پرداخت و یک ردیف سفارش منجر شود. فایل مجوز ممکن است یک ردیف برای هر حساب و دوره یا یک ردیف برای هر منشأ دسترسی داشته باشد. فایل پیشرفت هم می‌تواند خلاصهٔ آخرین وضعیت باشد یا مجموعه‌ای از رویدادهای جدا. این چهار شمار را به جای هم استفاده نکنید.
شناسهٔ مرجع مقداری است که بتوانید با آن به همان پرونده برگردید. نام هنرجو یا عنوان دوره می‌تواند عوض شود. شناسهٔ حساب و دوره به تیم کمک می‌کند رکورد را بدون حدس پیدا کند. اگر فروشنده شمارهٔ قابل نمایش و شناسهٔ داخلی جدا دارد، هر دو را در نمونه پیدا کنید. شمارهٔ قابل نمایش برای گفت‌وگو با هنرجو مفید است. شناسهٔ داخلی برای وصل کردن فایل‌ها کاربرد دارد. اگر هیچ کلید مشترکی در دسترس نیست، از فروشنده بخواهید با همان نمونه توضیح دهد ارتباط چگونه بازسازی می‌شود.
برای مجوزهای مستقل، منشأ را هم بررسی کنید. فرض کنید یک هنرجو دوره را خریده و بعد از طرف شرکت به همان دوره اضافه شده است. اگر گزارش فقط یک تاریخ نهایی نشان می‌دهد، ممکن است برای کنترل دسترسی جاری کافی باشد. برای رسیدگی به پایان دسترسی سازمانی، دانستن منشأ هر مجوز لازم است. از همان نمونه بخواهید مشخص کند کدام وضعیت مستقیماً قابل خروج است و کدام باید از گزارش یا فرایند جدا به دست بیاید. در مستند فاکسیمون زمان آغاز، پایان و امکان لغو مجوز شرح داده شده است. وجود این قابلیت‌ها به تنهایی قالب یا دامنهٔ خروجی را تعیین نمی‌کند. مدیریت دسترسی هنرجویان در فاکسیمون
| فایل نمونه | واحد ردیف | شناسهٔ مورد نیاز | آزمون پذیرش |
|---|---|---|---|
| سفارش | سفارش یا قلم سفارش، طبق تعریف سرویس | شناسهٔ سفارش، حساب و دوره | مبلغ، وضعیت و تاریخ با پنل برابر باشند |
| پرداخت و استرداد | تراکنش یا تغییر مالی | شناسهٔ تراکنش و سفارش مرجع | مبلغ برگشت‌خورده برای همان خرید پیدا شود |
| مجوز | حق مشاهده یا خلاصهٔ دسترسی جاری | شناسهٔ مجوز، حساب و دوره | تاریخ و وضعیت برای حساب درست باقی بماند |
| پیشرفت | رویداد یا خلاصهٔ وضعیت درس | شناسهٔ حساب، درس و در صورت وجود رویداد | تعریف شروع یا تکمیل پس از خواندن فایل روشن باشد |
یک نمونه بسازید که اختلاف‌ها را آشکار کند
فرض کنید در محیط آزمایشی سه سفارش دارید. سفارش اول یک میلیون تومان است و کامل تأیید شده است. سفارش دوم ۸۰۰ هزار تومان است و هنوز در انتظار بررسی است. سفارش سوم ۱٫۲ میلیون تومان است و پس از تأیید، ۲۰۰ هزار تومان از آن برگشت خورده است. اگر گزارش شما دریافت تأییدشده پس از استرداد را می‌سنجد و هزینهٔ دیگری در این مثال ندارید، انتظار دو میلیون تومان است. سفارش دوم در فهرست هست ولی هنوز در جمع دریافتی تأییدشده قرار نمی‌گیرد. وضعیت و مبلغ را مستقل مقایسه کنید.
برای دسترسی، حساب اول را با مجوز فعال و حساب دوم را با شروع در آینده بسازید. یک حساب دیگر را با مجوز لغوشده و تاریخ پایان آینده در نمونه بگذارید. این ترکیب نشان می‌دهد تاریخ پایان به تنهایی وضعیت را تعیین نمی‌کند. اگر خروجی فقط زمان شروع و پایان دارد، هنگام ورود به مقصد ممکن است حساب لغوشده دوباره فعال شود. برای همان ردیف از فروشنده بپرسید وضعیت لغو چگونه منتقل می‌شود یا آیا باید آن را از مسیر دیگری تشخیص داد.
برای پیشرفت، یک درس را چند بار با یک حساب باز کنید و یک تمرین نمونه بفرستید. سپس یک حساب دیگر فقط درس را باز کند و تمرین نفرستد. ببینید در خروجی چه فرقی دیده می‌شود. اگر فایل فقط «آخرین مشاهده» دارد، آن را معادل تکمیل تمرین نگیرید. اگر ردیف رویداد دارد، بررسی کنید رویداد تکراری چگونه مشخص می‌شود و آیا شناسهٔ درس در همهٔ فایل‌ها یکسان است. پیشرفت در یک بستهٔ آموزشی و دادهٔ عملیاتی فروش یا مجوز را در دو آزمون جدا بررسی کنید. راهنمای انتقال دوره و تفاوت SCORM و xAPI
برای هر ردیف انتظار را قبل از گرفتن فایل بنویسید. در این صورت وقتی فایل رسید مجبور نیستید برای هر نتیجه توضیح تازه بسازید. نسخهٔ پنل، تاریخ استخراج و محدودهٔ فیلتر را یادداشت کنید. اگر بخشی از نمونه در دمو قابل ایجاد نیست، همان مورد را آزمایش‌نشده بگذارید. مثلاً اگر محیط استرداد آزمایشی ندارد، تصویر یا نمونهٔ مستند فروشنده را جدا ثبت کنید. شاهد مستند با اجرای مشاهده‌شده روی حساب شما یک درجه از اطمینان ندارد.
قالب فایل را با ابزار واقعی تیم باز کنید
اگر خروجی CSV است، آن را در ابزاری باز کنید که مسئول مالی یا پشتیبان واقعاً استفاده می‌کند. نام فارسی، صفر ابتدایی شناسه و مقدار تاریخ را بررسی کنید. تبدیل خودکار به عدد می‌تواند ابتدای یک شناسه را حذف کند. قالب تاریخ هم ممکن است برای خواننده با تنظیم زبان متفاوت نمایش داده شود. مقدار اصلی را از روی فایل نگه دارید و چند ردیف را با صفحهٔ مبدا تطبیق دهید. فایل قابل باز شدن است اگر نرم‌افزار آن را بخواند. فایل قابل استفاده است اگر مقادیر بعد از خواندن همان معنای مورد انتظار را داشته باشند.
برای مبلغ، واحد را در عنوان ستون یا توضیح فایل پیدا کنید. اگر ریال و تومان در دو گزارش فرق دارند، تبدیل را یک بار در مقصد تعریف کنید و با نمونهٔ کوچک کنترل کنید. استرداد ممکن است به شکل مبلغ منفی، ستون جدا یا تراکنش جدا ثبت شود. همان مدل را با تیم مالی بخوانید. اگر فایل یک جمع کل دارد، سه ردیف نمونه را خودتان محاسبه کنید و ببینید به همان عدد می‌رسید. اختلاف را ابتدا از روی تعریف‌ها بررسی کنید. ممکن است جمع شامل مالیات، کارمزد یا سفارش در انتظار باشد.
در دادهٔ زمانی، تاریخ ایجاد و تاریخ تغییر را جدا نگه دارید. اگر خروجی با منطقهٔ زمانی دیگری تهیه می‌شود، یک سفارش نزدیک نیمه‌شب را در نمونه بگذارید. ببینید در کدام روز گزارش قرار می‌گیرد. برای تاریخ پایان مجوز هم یک بازهٔ کوتاه آزمایشی داشته باشید. اگر ساعت خروجی دیده نمی‌شود و وضعیت به زمان حساس است، این محدودیت را در گزارش بگذارید. وقتی مدیر برای بستن نوبت به عدد همان روز تکیه می‌کند، یک روز جابه‌جایی می‌تواند جمع را تغییر دهد.
به خانه‌های خالی هم معنی بدهید. ممکن است تاریخ پایان خالی نشانهٔ دسترسی بدون پایان، دادهٔ قدیمی نامشخص یا مقدار حذف‌شده باشد. این سه تفسیر نتیجهٔ متفاوت دارند. یک نمونهٔ عمدی از هر حالت بسازید، اگر محصول اجازه می‌دهد. سپس رفتار مقصد را ببینید. مقدار خالی را بدون دانستن تعریف به صفر یا تاریخ امروز تبدیل نکنید. اگر فروشنده فقط یک تعریف دارد، همان را همراه نام نسخه و نمونهٔ خروجی ثبت کنید.
چند ردیف را در مقصد آزمایشی بازسازی کنید
برای مقصد یک فایل یا محیط جدا آماده کنید. هدف نخست، بازسازی یک پرونده است. یک حساب، یک سفارش و یک مجوز را از روی شناسه‌ها کنار هم بگذارید. ببینید آیا عنوان دوره، تاریخ و وضعیت به رکورد درست می‌رسند. اگر مقصد سامانهٔ آموزشی است، از حساب آزمایشی درس را باز کنید. اگر مقصد ابزار گزارش‌گیری است، با همان داده جمع نمونه را به دست بیاورید. انتخاب مقصد به هدف بستگی دارد. گزارش مالی قابل خواندن لزوماً به معنی آماده بودن وارد کردن مجوز در سامانهٔ دیگر نیست.
برای اجرای دوباره، همان فایل کوچک را یک بار دیگر وارد کنید یا از مسیر آزمایشی پردازش کنید. ببینید شناسه‌ها ثابت می‌مانند و ردیف‌های قبلی دوباره ایجاد نمی‌شوند. اگر ابزار مقصد تکرار را خودش کنترل نمی‌کند، پیش از ورود دوباره روش تطبیق تعریف کنید. در نمونه یک ردیف با وضعیت تغییرکرده بگذارید. برای مثال مجوز فعال بعداً لغو شود. بررسی کنید گزارش تازه بتواند همان پرونده را به‌روز کند. ساختن یک ردیف فعال تازه در کنار لغو قدیمی می‌تواند نتیجهٔ دسترسی را مبهم کند.
یک نمونهٔ عمداً ناسازگار هم اضافه کنید. مثلاً شناسهٔ دورهٔ یکی از مجوزها در جدول مقصد پیدا نشود. انتظار این است که ردیف به صف بررسی برود. نباید به دوره‌ای با نام شبیه وصل شود. پیام خطا یا نتیجهٔ رد را ثبت کنید. بعد شناسه را اصلاح کنید و فقط همان ردیف را دوباره اجرا کنید. بررسی کنید کار قبلی دوباره تکرار نشده است. اگر مقصد تنها جمع خطا را می‌دهد و شناسهٔ ردیف ندارد، بنویسید تیم برای پیدا کردن مورد به چه ابزار یا کاری نیاز دارد.
برای آزمون دسترسی، یک حساب مجاز و یک حساب بدون خرید انتخاب کنید. از هر دو حساب لینک مستقیم درس را باز کنید. اگر مسیر نیاز به ورود دارد، از یک نشست تازه استفاده کنید. برای مجوز زمان‌دار، پیش و پس از شروع یا پایان را جدا مشاهده کنید. اگر تاریخ در مقصد درست دیده می‌شود ولی فیلم برای حساب غیرمجاز باز است، آزمون تحویل موفق نیست. نتیجهٔ فایل و تجربهٔ واقعی کاربر را در دو ستون نگه دارید تا مشخص شود کدام بخش به اصلاح نیاز دارد.
گزارش تکرارشونده و دسترسی تیم به خروجی را بسنجید
از همان محیط دو بار خروجی بگیرید. اول یک فایل برای یک هفته و بعد یک فایل برای بازه‌ای که همان هفته را در خود دارد. رکوردهای مشترک را از روی شناسه پیدا کنید. اگر شناسه یا عنوان ستون در هر اجرا عوض می‌شود، اتصال خودکار فایل‌ها سخت‌تر می‌شود. در یک آزمون دیگر یک سفارش را پس از خروجی اول به‌روز کنید و خروجی دوم را با همان فیلتر بگیرید. ببینید وضعیت تازه چگونه دیده می‌شود و آیا تاریخ تغییر قابل پیدا کردن است. نتیجه برای آموزشگاهی که هر هفته گزارش می‌بندد کاربرد دارد.
درخواست خروجی را با نقش واقعی انجام دهید. ممکن است مالک پنل همهٔ فایل‌ها را بگیرد ولی مسئول مالی فقط به گزارش سفارش دسترسی داشته باشد. اگر پشتیبان برای یافتن یک پرونده مجبور است هر بار به مالک مراجعه کند، این وابستگی را در ارزیابی بنویسید. در مقابل، دسترسی به فایل کامل را به کسی که فقط وضعیت یک هنرجو را بررسی می‌کند واگذار نکنید. از هر نقش فقط همان عملی را بخواهید که برای کار روزانه لازم دارد. آزمون دسترسی به خود خروجی را جدا از محتوای فایل ثبت کنید.
برای نمونهٔ ارزیابی از اطلاعات ساختگی استفاده کنید. هنگام خروجی واقعی، مسیر دریافت، محل ذخیره و کسانی که اجازهٔ خواندن دارند مشخص باشد. اگر برای بررسی عنوان ستون‌ها لازم نیست دادهٔ کامل همهٔ هنرجویان را ببینید، به همان نمونه بسنده کنید. در گزارش پذیرش هم می‌توانید از شناسهٔ مستعار و شمار ردیف استفاده کنید. اگر فایل پس از خروج باید به واحد دیگری برسد، از قبل معلوم کنید کدام ستون‌ها واقعاً برای آن نقش لازم است.
فاصلهٔ میان دو خروجی را در تمرین انتقال پوشش دهید
فرض کنید تیم روز چهارشنبه از همهٔ سفارش‌ها و دسترسی‌ها خروجی می‌گیرد و قرار است شنبه محیط جدید را باز کند. پنجشنبه هنرجویی پرداخت می‌کند، دسترسی هنرجوی دیگری تمدید می‌شود و یک سفارش برگشت می‌خورد. اگر همان فایل چهارشنبه مبنای راه‌اندازی باشد، هیچ‌کدام از این تغییرها در مقصد دیده نمی‌شوند. در تمرین، این سه اتفاق را پس از گرفتن فایل اول بسازید و با ابزار خود سامانه مشخص کنید کدام رکوردها تغییر کرده‌اند.
اگر خروجی تغییرات وجود دارد، بررسی کنید آیا فیلتر آن با زمان ایجاد رکورد کار می‌کند یا آخرین زمان تغییر. سفارش قدیمی که امروز برگشت خورده، آزمون خوبی برای این تفاوت است. ابتدا یک بازهٔ کوچک با ساعت شروع و پایان ثبت کنید. بعد یک رخداد در مرز دو بازه بگذارید و هر دو فایل را بگیرید. اگر رخداد در هر دو فایل هست، مقصد باید با شناسهٔ ثابت فقط یک بار آن را اعمال کند. اگر در هیچ فایلی دیده نمی‌شود، شیوهٔ انتخاب بازه باید اصلاح شود.
اگر سامانه فقط خروجی کامل می‌دهد، دو فایل کامل را با شناسه مقایسه کنید. یک ردیف می‌تواند تازه، تغییرکرده یا غایب باشد. پیش از اینکه غیبت را حذف تلقی کنید، وضعیت فیلترها و محدودیت صفحه‌بندی را ببینید. مثلاً گزارش صفحهٔ اول با سقف صد ردیف ممکن است سفارش صد و یکم را نشان ندهد. مجموعهٔ کوچک را یک بار با سقف دو ردیف بگیرید تا بررسی صفحهٔ بعد ساده باشد. تعداد شناسه‌های یکتا در همهٔ صفحه‌ها را با تعداد مورد انتظار تطبیق دهید.
هنگام اتصال فایل‌ها، جمع مبلغ را یک بار روی جدول سفارش حساب کنید. فرض کنید یک سفارش ۸۰۰ هزار تومانی سه دسترسی و هر دسترسی چند ردیف پیشرفت دارد. پس از اتصال جدول‌ها ممکن است همان مبلغ در چند ردیف تکرار شود. برای گزارش مالی از جدول سفارش و برای شمارش مجوز از شناسهٔ یکتای مجوز استفاده کنید. اگر همکار دیگری همان فایل‌ها را باز کند، باید از روی توضیح کنار جدول بتواند همان دو عدد را به دست آورد.
در پایان تمرین، زمان واقعی گرفتن فایل، انتقال و تطبیق را یادداشت کنید. اگر قرار است در فاصلهٔ خروجی نهایی تا بازشدن مقصد سفارش‌های تازه ثبت شوند، مسئول تطبیق و زمان بررسی را قبل از انتقال تعیین کنید. سه تغییر تمرین را در گزارش نهایی پیدا کنید و با یک ورود آزمایشی ببینید دسترسی خرید تازه، تمدید و برگشت هر کدام مطابق انتظار عمل می‌کنند.
نتیجه را برای تصمیم خرید روی یک صفحه جمع کنید
پیش از جلسهٔ تصمیم، برای هر فایل یک برگهٔ راهنما آماده کنید. روی آن بنویسید هر ردیف نمایندهٔ چیست، شناسهٔ ثابت کدام ستون است و تاریخ‌ها با چه منطقهٔ زمانی نوشته شده‌اند. اگر مبلغ به ریال است، واحد را کنار نام ستون ثبت کنید تا همکار مالی آن را تومان نخواند. در نمونهٔ پیشرفت هم تفاوت «صفر» و خانهٔ خالی را توضیح دهید. صفر می‌تواند نشان دهد هنرجو هنوز درسی را کامل نکرده است و خانهٔ خالی می‌تواند یعنی اطلاعات آن درس در خروجی موجود نیست. از همکار دیگری بخواهید یک ردیف از هر فایل را با همین راهنما بخواند.
برای مسئله‌هایی که حلشان به فروشنده وابسته است، یک نمونهٔ کوچک همراه درخواست بفرستید. برای نمونه بنویسید «این سفارش در تاریخ تعیین‌شده برگشت خورده ولی در خروجی تغییرات دیده نمی‌شود». شناسهٔ نمونه، زمان تغییر و نام فایل را پیوست کنید. پاسخ را زمانی ثبت کنید که بتوانید همان آزمون را دوباره اجرا کنید و ردیف مورد انتظار را ببینید.
سه برچسب برای گزارش بگذارید. «قبول» یعنی فیلد و نتیجهٔ مورد انتظار در نمونه دیده شده‌اند. «نیازمند اصلاح» یعنی فایل یا فرایند هست و شاهد با انتظار تفاوت دارد. «آزمایش‌نشده» یعنی حساب، داده یا امکان اجرا وجود نداشته است. برای هر مورد نام پلن، تاریخ، نقش حساب و نسخهٔ فایل را نگه دارید. اگر نمونه در دموی فروشنده درست بوده و حساب شما هنوز آن را ندیده، همین تفاوت را در گزارش بیاورید. برای تصمیم خرید، شرط‌های ضروری را پیش از نمایش دمو مشخص کنید.
یک بار گزارش را به همکار دیگری بدهید. او باید بتواند از روی همان فایل‌ها یک سفارش مشخص را پیدا کند، مبلغ خالص را توضیح دهد و وضعیت دسترسی همان حساب را بخواند. اگر برای پیدا کردن کلید اتصال لازم است از شما سؤال کند، آن کلید را در راهنمای کوتاه بیاورید. اگر دلیل بسته بودن مجوز تنها با دیدن پنل مشخص می‌شود، بنویسید این مرحله هنوز به پنل وابسته است. نتیجهٔ ارزیابی زمانی قابل پیگیری است که فرد دیگری بتواند همان کار را تکرار کند.
برای تصمیم نهایی، نیازهای مالی، اجرایی و آموزشی را جدا مرور کنید. ممکن است خروجی فروش برای تطبیق مناسب باشد و پیشرفت فقط به شکل یک جمع کلی ارائه شود. اگر هدف شما انتقال تاریخچهٔ تمرین است، این محدودیت مهم است. اگر فقط به گزارش نوبت جاری نیاز دارید، همان جمع ممکن است نیاز را پوشش دهد. تصمیم و دلیلش را همراه نسخهٔ نمونه ذخیره کنید. پس از تغییر پلن یا عوض شدن ابزار مقصد، همان ردیف‌های نمونه را دوباره بررسی کنید.