اتصال ووکامرس به انبار؛ قبل از ساخت افزونه چه مشخص کنیم؟
اتصال فروشگاه به انبار فقط جابهجایی یک عدد موجودی نیست. پیش از انتخاب افزونه آماده یا ساخت افزونه اختصاصی باید معلوم شود کدام سیستم مرجع است، هر وضعیت سفارش چه اثری دارد و اختلافها چگونه پیدا و اصلاح میشوند.
۱. مرجع نهایی موجودی کدام سیستم است؟
اولین تصمیم این است که موجودی قابل فروش را ووکامرس تعیین میکند یا نرمافزار انبار. اگر فروش حضوری، مارکتپلیس یا شعبه دیگری از همان موجودی مصرف میکند، معمولاً انبار مرجع مناسبتری است؛ اما این یک قانون همیشگی نیست. باید مشخص شود موجودی کل، موجودی رزروشده و موجودی قابل فروش در هر سیستم چه معنایی دارند.
نوشتن جملهای روشن مثل «انبار مرجع تعداد است و ووکامرس فقط موجودی قابل فروش را نمایش میدهد» جلوی بسیاری از تعارضهای بعدی را میگیرد. اگر هر دو طرف اجازه تغییر مستقل یک فیلد را داشته باشند، باید قانون حل تعارض و اولویت تغییرها نیز تعریف شود.
۲. کالاها چگونه در دو سیستم به هم میرسند؟
نام محصول شناسه قابل اتکایی نیست. برای محصول ساده، متغیر و بستهای باید کلیدی پایدار مانند شناسه داخلی یا SKU وجود داشته باشد. همچنین واحد شمارش، تنوعها، کالاهای غیرفعال و محصولاتی که هنوز در یکی از دو سیستم ساخته نشدهاند باید تعیین تکلیف شوند.
- آیا هر variation ووکامرس شناسه جداگانهای در انبار دارد؟
- اگر یک SKU تکراری یا خالی باشد، همگامسازی متوقف میشود یا آن ردیف کنار گذاشته میشود؟
- موجودی چند انبار جمع میشود یا فقط یک انبار برای فروش اینترنتی معتبر است؟
- کالای بستهای از موجودی اجزای خود محاسبه میشود یا عدد مستقلی دارد؟
۳. چه رویدادی موجودی را تغییر میدهد؟
«بعد از سفارش موجودی کم شود» تعریف کافی نیست. سفارش ووکامرس وضعیتهای مختلفی مانند در انتظار پرداخت، در حال انجام، لغوشده، ناموفق و مستردشده دارد. باید برای هر مسیر مشخص شود موجودی چه زمانی رزرو، قطعی یا آزاد میشود و تغییر دستی مدیر چه رفتاری دارد.
برای نمونهای فرضی، فروشگاه ممکن است هنگام ایجاد سفارش موجودی را رزرو کند، پس از پرداخت خروج قطعی بسازد و در لغو پیش از ارسال رزرو را آزاد کند. در یک کسبوکار دیگر شاید انبار فقط سفارش پرداختشده را بپذیرد. انتخاب درست از فرایند واقعی فروش و انبار میآید، نه از یک نسخه عمومی.
۴. ارسال لحظهای، زمانبندیشده یا ترکیبی؟
WooCommerce برای سفارشها و محصولات REST API دارد و وبهوک میتواند تغییر رویدادهایی مانند ایجاد یا بهروزرسانی سفارش را به سرویس دیگر اعلام کند. بااینحال وبهوک بهتنهایی تضمین نمیکند که مقصد تغییر را ثبت کرده است. قطع شبکه، پاسخ ناموفق یا توقف سرویس مقصد باید در طراحی دیده شود.
راهکار عملی معمولاً یک مسیر سریع برای تغییرهای روزمره و یک تطبیق دورهای برای کشف اختلافها دارد. فاصله همگامسازی، حجم کالاها، محدودیت API و حساسیت جلوگیری از فروش بیش از موجودی تعیین میکنند کدام مدل مناسب است.
۵. خطا و ارسال تکراری چگونه مدیریت میشود؟
هر عملیات باید شناسهای داشته باشد تا تکرار همان پیام، موجودی را دوباره کم نکند. صف تلاش مجدد، ثبت زمان و نتیجه درخواست، نمایش خطا به مدیر و امکان اجرای دوباره کنترلشده از نیازهای پایهاند. کلیدهای API نیز باید حداقل دسترسی لازم را داشته باشند و امضای وبهوک در سمت دریافتکننده بررسی شود.
برای خطای دائمی—مثلاً SKU ناشناخته—تلاش بیپایان کمکی نمیکند. چنین ردیفی باید از خطای موقت جدا شود، دلیل قابل فهم داشته باشد و تا اصلاح نگاشت در فهرست پیگیری بماند.
۶. برگشت، اصلاح و تطبیق را از ابتدا تعریف کنید
لغو کامل سفارش تنها حالت برگشت نیست. کاهش تعداد یک قلم، تعویض کالا، مرجوعی پس از ارسال و اصلاح دستی انبار هرکدام ممکن است سند متفاوتی بسازند. بهتر است بهجای بازنویسی بیردپا، عملیات اصلاحی قابل پیگیری ثبت شود.
گزارش تطبیق باید بتواند موجودی دو سیستم را برای یک زمان مشخص مقایسه کند، اختلافها را نشان دهد و منبع آخرین تغییر را نگه دارد. داشبورد سبز بدون امکان پیدا کردن یک اختلاف واقعی، معیار کافی برای سلامت اتصال نیست.
چکلیست اطلاعات لازم برای برآورد
- نام و نسخه نرمافزار انبار و لینک مستندات API آن
- سیستم مرجع برای کالا، قیمت، موجودی و وضعیت سفارش
- نمونه داده بدون اطلاعات مشتری و جدول نگاشت شناسه یا SKU
- وضعیتهای سفارش و اثر دقیق هرکدام بر رزرو، خروج و برگشت
- تعداد تقریبی کالا، سفارش روزانه، انبارها و فاصله قابل قبول همگامسازی
- رفتار مورد انتظار هنگام قطعی، داده نامعتبر و پیام تکراری
- گزارش موردنیاز برای خطا، تطبیق و اصلاح
معیار پذیرش را با سناریو بنویسید
پیش از توسعه، چند سناریوی قابل آزمون تعریف کنید: سفارش موفق با دو کالا، پرداخت ناموفق، لغو پس از رزرو، مرجوعی یک قلم، دریافت دوباره یک پیام و قطع موقت API. برای هر سناریو، مقدار مورد انتظار در ووکامرس و انبار و سابقهای که مدیر باید ببیند مشخص شود.
این کار هم برآورد را دقیقتر میکند و هم مرز تحویل را روشن نگه میدارد. برای قالب کاملتر تعریف پروژه، چکلیست سفارش افزونه اختصاصی را ببینید. نمونهای از طراحی دفتر حرکت و مهاجرت داده نیز در شرح بازطراحی سامانه انبار آمده است.