برای ورود تاریخ شمسی به CRM، قالب ورودی، نوع فیلد مقصد و روش تبدیل را قبل از انتقال توافق کنید. تاریخ اولیه را کنار نتیجه قابل بررسی نگه دارید و تبدیل رفت‌وبرگشت را روی نمونه امتحان کنید. عوض‌کردن نمایش سلول یا جابه‌جایی سال، تبدیل تقویم معتبر نیست؛ تاریخ بدون ساعت را هم بی‌دلیل به لحظه زمانی تبدیل نکنید.
اول بپرسید این فیلد چه معنایی دارد
تاریخ موعد، روز تولد و زمان ثبت رویداد یک نوع داده نیستند. اگر فقط روز تقویمی لازم است، ساعت فرضی نیمه‌شب اضافه نکنید مگر قرارداد مقصد چنین چیزی خواسته باشد. اگر زمان دقیق رویداد لازم است، ساعت و منطقه زمانی هم باید مشخص باشند. این مقاله روی قرارداد ورود تاریخ تمرکز دارد، نه اختلاف گزارش تماس در مناطق زمانی؛ معنی فیلد قبل از انتخاب ابزار تبدیل تعیین می‌شود.
قالب ورودی را بدون ابهام بنویسید
در فرم بگویید تقویم شمسی است و ترتیب سال، ماه و روز چیست. رقم فارسی و لاتین را در مرحله آزمون جدا بررسی کنید. مقدار ناقصی مثل 02/03 بدون سال، برای تبدیل قطعی کافی نیست. اگر نرم‌افزار شکل خاصی می‌خواهد، مثال معتبر همان شکل را بدهید. مقدار نامعتبر نباید خودکار به تاریخ امروز یا نخستین روز ماه تبدیل شود؛ وضعیت خطا باید قابل مشاهده و نیازمند اصلاح باقی بماند.
روش تبدیل باید شناخته‌شده و نسخه‌دار باشد
از تیم فنی بخواهید نام کتابخانه یا روش پشتیبانی‌شده مقصد و نسخه آن را ثبت کند. نمونه‌هایی مثل PersianCalendar در محیط دات‌نت برای تقویم فارسی روش مشخص دارند، اما انتخاب آن به محیط شما بستگی دارد. از فرمول‌های حدسی جمع و تفریق روز برای همه سال‌ها استفاده نکنید. مرز ماه و سال و روزی که در برخی سال‌ها معتبر نیست، باید در مجموعه آزمون وجود داشته باشد؛ داده آموزشی را با تاریخ واقعی مشتری جایگزین نکنید.
آزمون رفت‌وبرگشت چه می‌خواهد؟
یک تاریخ معتبر نمونه را از قالب مبدأ به مقصد تبدیل کنید، سپس با همان قرارداد به نمایش شمسی برگردانید. روز، ماه و سال باید با ورودی تأییدشده یکسان باشد. اگر فیلد زمان هم دارد، رفتار ساعت جدا کنترل شود. علاوه بر نتیجه درست، ردشدن ورودی نامعتبر را امتحان کنید. این روش خطا را بهتر آشکار می‌کند، ولی جای بررسی دامنه تاریخی مورد پشتیبانی و قواعد خود سامانه را نمی‌گیرد.
مسیر ردیف‌های ناموفق را از قبل تعیین کنید
در فایل ورود، مقدار اولیه، وضعیت تبدیل و علت رد را نگه دارید. ردیف مشکل‌دار را با تاریخ ساختگی پر نکنید تا فایل ظاهراً کامل شود. مسئول اصلاح باید به منبع مجاز دسترسی داشته باشد و نتیجه پیش از ورود دوباره تأیید شود. پس از بارگذاری آزمایشی، نمایش مقصد و خروجی بعدی را کنترل کنید. اگر تاریخ درست ذخیره شده ولی رابط آن را با تقویم دیگری نشان می‌دهد، مسئله نمایش را از خرابی مقدار جدا گزارش کنید.
برگه قرارداد تاریخ ورودی؛ نمونه آموزشی
داده‌های جدول زیر ساختگی‌اند و نتیجه اجرای واقعی هیچ محصولی نیستند. آن‌ها را برای تمرین تیم به کار ببرید و قواعد اجرایی را با مسئول همان فرایند تأیید کنید.
| کنترل آموزشی | قرارداد لازم | انتظار آزمون | در صورت شکست |
|---|---|---|---|
| نوع فیلد | روز بدون ساعت یا زمان رویداد | معنا ثابت بماند | توقف نگاشت |
| قالب ورودی | سال ماه روز شمسی مشخص | خواندن بدون حدس | درخواست اصلاح |
| رفت‌وبرگشت | روش و نسخه ثابت | بازگشت همان روز | بررسی تبدیل |
| ورودی نامعتبر | قاعده رد روشن | تاریخ جعلی ساخته نشود | صف بررسی |
دانلود برگه قرارداد تاریخ ورودی با قالب CSV سازگار با اکسل. فایل از داده آموزشی تشکیل شده و اطلاعات مشتری واقعی ندارد. پیش از استفاده عملی، عنوان ستون‌ها و مقادیر مجاز را با سامانه خودتان تطبیق دهید.
منبع و ادامه مسیر
مستند رسمی Microsoft برای PersianCalendar روش‌های کار با تقویم فارسی را معرفی می‌کند. PersianCalendar Class. این ارجاع، روش اختصاصی این مقاله یا قابلیت اپرا را گواهی نمی‌کند؛ روش و مثال‌های بالا پیشنهاد تحریریه برای طراحی و آزمون هستند.
برای زمینه مرتبط، اتصال ایجنت صوتی به CRM؛ چه اطلاعاتی قبل و بعد از تماس ثبت می‌شود؟ و وقتی CRM قطع است، درخواست‌های مشتری را چگونه ثبت کنیم؟ را بخوانید. اگر دنبال راهکار اجرایی هستید، بسته‌ها و مسیر درخواست پیشنهاد اپرا را بررسی کنید؛ امکان اجرای سناریوی خود را با تیم فروش مشخص کنید. انتخاب بسته به معنی ثبت خودکار درخواست، صدور فاکتور یا فعال‌شدن فوری خدمت نیست.
راهنماهای مرتبط با این مسئله
دیکشنری فیلد CRM؛ معنی ستون‌ها را قبل از اتصال بنویسیم و اختلاف تاریخ تماس بین دو گزارش؛ منطقه زمانی و مرز روز را کنترل کنیم می‌توانند گام بعدی بررسی تیم شما باشند.