۸.۱ هدف این چکلیست
این چکلیست برای اطمینان از آمادگی کامل سیستم POS جهت اتصال به محیط Production طراحی شده است. تکمیل تمام موارد این بخش به معنی آن است که:
- ریسک NFC و Reject غیرضروری به حداقل رسیده است
- Live Sync و Resync بهدرستی پیادهسازی شدهاند
- سیستم در برابر خطا، قطعی شبکه و retry مقاوم است
- تیم Vendor میتواند بدون وابستگی دائمی به پشتیبانی، سیستم را اداره کند
تعریف Done:
اگر حتی یکی از آیتمهای حیاتی این چکلیست Done نباشد،
Go-Live توصیه نمیشود.
۸.۲ چکلیست احراز هویت و اتصال (Security & Auth)
- دریافت صحیح
access_tokenوrefresh_tokenاز OAuth2 - پیادهسازی Refresh خودکار توکن قبل از انقضا
- مدیریت خطای 401 / 3003 / 3004 بدون توقف سیستم
- عدم ذخیره client_secret، رمز عبور یا token در UI یا لاگها
- استفاده از HTTPS در تمام درخواستها (POS → Platform)
- تفکیک محیط Sandbox و Production در تنظیمات
۸.۳ چکلیست دادههای محصول، قیمت و موجودی
- ارسال صحیح
vendorCodeدر تمام endpointها - Live Sync موجودی (Stock) در نزدیکترین زمان ممکن به تغییر واقعی
- Live Sync قیمت در هر تغییر واقعی (نه صرفاً تغییر UI)
- عدم تکیه صرف بر Bulk Sync؛ استفاده از Bulk فقط برای Resync
- Batch size در بازه ۱۰۰ تا ۵۰۰ آیتم (قابل تنظیم)
- مدیریت failedItems و Retry فقط روی آیتمهای اصلاحشده
- پیادهسازی کامل Active/Inactive برای کنترل فروشپذیری
یادآوری مهم:
موجودی مهمترین عامل NFC است؛
اگر فقط یک چیز را عالی Sync میکنید، آن موجودی باشد.
۸.۴ چکلیست سفارش و State Machine
- دریافت صحیح سفارش از Webhook (HMAC + form-urlencoded)
- ارسال ACK در کمتر از ۵ ثانیه
- ارسال ACCEPT یا REJECT حداکثر تا ۶۰ ثانیه
- ارسال PICK قبل از تحویل به پیک
- پیادهسازی Idempotency برای Ack / Accept / Reject / Pick
- در REJECT به دلیل OOS: صفر کردن موجودی در POS
- مدیریت صحیح StatusCodeهای تکراری (1059 / 1060 / 1068)
ریسک عملیاتی:
تأخیر در ACK یا ACCEPT مستقیماً باعث تماس مشتری و مرکز تماس میشود.
۸.۵ چکلیست مدیریت خطا و Retry
- تفکیک خطای موقت (5xx/Timeout) از خطای منطقی (400/1023/403)
- Retry فقط برای خطاهای موقت با Backoff نمایی (1s, 2s, 4s, 8s)
- عدم Retry برای خطاهای منطقی یا تکراری
- پیادهسازی Dead-Letter برای آیتمهای مشکلدار دادهای
- لاگ کامل شامل:
(orderCode, action, http_status, error_code, latency)
۸.۶ چکلیست استراتژی سینک و Drift Control
- پیادهسازی Live Sync event-based یا queue-based
- تعریف Weak Signal (lag، failedItems، NFC، timeout)
- اجرای Partial Resync برای SKUهای مشکوک
- اجرای Full Resync فقط بهصورت مرحلهای و batch-شده
- عدم اجرای Full Resync بدون دلیل عملیاتی واضح
- ثبت گزارش Resync برای Audit و تحلیل بعدی
نگاه بیزینسی:
Drift یک باگ نیست؛
اما بدون کنترل، هزینه مستقیم روی SLA و GMV دارد.
۸.۷ مانیتورینگ، داشبورد و KPI
- مانیتور Sync Lag (Price / Stock)
- نرخ failedItems در Bulk
- Retry Rate و Timeout Rate
- تعداد Partial / Full Resync در روز
- سیگنالهای NFC / OOS Reject از سفارشها
قاعده مدیریتی:
اگر Resync زیاد شده، مشکل معمولاً فرآیندی است نه API.
۸.۸ تست نهایی قبل از Go-Live
- ثبت سفارش تست در Sandbox و دریافت صحیح Webhook
- اجرای کامل Ack → Accept → Pick بدون خطا
- تست سناریوی Out of Stock و Reject
- اجرای یک Full Resync بدون failedItems بحرانی
- تطبیق قیمت و موجودی بین POS و پلتفرم
شرط Go-Live:
تا زمانی که تمام موارد بالا تأیید نشدهاند،
ورود به Production توصیه نمیشود.
۸.۹ تأیید نهایی (Sign-off)
با تأیید این چکلیست، Vendor مسئولیت صحت دادههای ارسالی از POS و اجرای صحیح فرآیندهای سینک و سفارش را میپذیرد.
| نقش | نام | امضا / تاریخ |
|---|---|---|
| مسئول فنی Vendor | ||
| مسئول عملیات Vendor | ||
| تأیید فنی اسنپ! مارکت |