مهاجرت سامانه انبار وردپرس؛ حفظ تاریخچه و کنترل مانده

مسئلهٔ ساختار قبلی

اسناد خرید و انبار میان چند نوع محتوا و فیلد سفارشی توزیع شده بودند. ارتباط سفارش، رسید و حواله به‌سختی دنبال می‌شد و تغییر سند می‌توانست مانده را بدون مسیر روشن اصلاح تحت تأثیر قرار دهد.

برای طراحی مدل تازه، قواعد خرید داخلی، خارجی، cross-dock و برگشت استخراج شدند. انبار، تأمین‌کننده، سند و حرکت به موجودیت‌های مشخص تبدیل شدند تا رابطه‌ها قابل کنترل بمانند.

بازسازی با دفتر حرکت

افزونهٔ اختصاصی با جدول‌های داده، لایه‌های سرویس و REST API ساخته شد. ورود، خروج و اصلاح در دفتر حرکت افزایشی ثبت شدند. اصلاح سند با عملیات معکوس و بازسازی اتمیک انجام شد، نه تغییر بی‌سابقهٔ مانده.

انتقال شامل ۳۲ انبار، بیش از ۱۳هزار سند و بیش از ۲۶هزار حرکت تاریخی بود. مهاجرت به‌صورت افزایشی و قابل تکرار اجرا شد و از سیستم قدیمی فقط خواند. این روش بخشی از حفظ کار روزانه و امکان بازگشت هنگام انتشار بود.

تأیید انتقال فقط شمارش نبود

تعداد اسناد و حرکت‌ها با مبدأ مقایسه شد. علاوه بر آن، ماندهٔ هر کالا در هر انبار کنترل شد تا اثر رابطه‌ها روی موجودی بررسی شود. اختلاف نهایی ثبت‌شده یک شناسهٔ کالای نامعتبر بود؛ این محدودیت از گزارش حذف نشده است.

جدول‌های نتیجه در ادامه همان داده‌های ثبت‌شدهٔ پروژه را نگه می‌دارند. اعداد گرد شده‌اند و اطلاعات شناسایی مشتری برای محرمانگی کنار گذاشته شده‌اند.

کاربرد این تجربه برای پروژهٔ دیگر

از این نمونه می‌توان روش تعریف معیار صحت را گرفت، نه تضمین زمان یا نتیجهٔ یکسان. برای پروژهٔ تازه، منبع تغییرهای حین انتقال، وابستگی داده و مرز انتشار مستقل بررسی می‌شوند.

راهنمای مهاجرت دادهٔ افزونه پرسش‌های قبل از انتقال را پوشش می‌دهد. برای برآورد اجرایی از ساخت افزونه اختصاصی و یک نمونهٔ دادهٔ بدون اطلاعات حساس شروع کنید.

جدول نتیجه‌های ثبت‌شده

چرا مدل حرکت به بررسی موجودی کمک می‌کند؟

عدد مانده به‌تنهایی نمی‌گوید موجودی چگونه به وضعیت فعلی رسیده است. برای پیگیری اختلاف باید بتوان ورود، خروج، برگشت و اصلاح را به سند مربوط وصل کرد. در این پروژه، دفتر حرکت همین رابطه را قابل بررسی کرد. به همین دلیل، نتیجه فقط «انتقال تعدادی ردیف» نبود؛ معنی عملی داده هم باید در ساختار جدید حفظ می‌شد. این توضیح تفسیر روش ثبت‌شده است و قابلیت تازه‌ای به سابقهٔ پروژه اضافه نمی‌کند.

وقتی یک سند تغییر می‌کند، دست‌کاری مستقیم مانده می‌تواند اثر قبلی را بی‌رد باقی بگذارد. روش ثبت‌شدهٔ این اجرا از عملیات معکوس و بازسازی اتمیک استفاده کرد تا اثر اصلاح در مسیر داده بماند. این تصمیم برای همان سامانه و قواعدش گرفته شد؛ از آن نسخهٔ معماری مناسب همهٔ انبارها نتیجه نمی‌گیریم. در پروژهٔ دیگر، نوع سند و توان ابزار موجود باید جدا بررسی شوند.

مقایسهٔ تعداد با مقایسهٔ اثر متفاوت است

شمار اسناد و حرکت‌ها نشان می‌دهد چه حجمی بازسازی شده است. مقایسهٔ ماندهٔ هر کالا و انبار پرسش دیگری را پاسخ می‌دهد: آیا همین داده، موجودی مورد انتظار را می‌سازد؟ ممکن است تعداد ردیف‌ها برابر باشد ولی یک رابطه به کالای نامعتبر اشاره کند. نگه‌داشتن هر دو کنترل کمک کرد اختلاف نهایی به دادهٔ مشخص قابل انتساب باشد، نه اینکه پشت یک جمع کلی پنهان بماند.

در گزارش این نمونه، اختلاف باقی‌مانده همان یک شناسهٔ کالای نامعتبر است. این مورد را نباید به ادعای صحت کامل همهٔ داده‌های تاریخی تبدیل کرد. مقدارهای بیش از ۱۳هزار سند و ۲۶هزار حرکت نیز گرد شده‌اند. جدول نتیجه، دامنهٔ شاهد را روشن نگه می‌دارد و تفسیر آن نباید از شرایط همین اجرای ثبت‌شده فراتر برود.

برای تعریف مهاجرت مشابه چه اطلاعاتی لازم است؟

نوع اسناد، رابطهٔ کالا و انبار، روش محاسبهٔ مانده و تغییرهایی که هنگام انتقال ادامه دارند را فهرست کنید. سپس معیار کنترل را بنویسید: کدام شمارش، کدام مجموع و کدام رابطه باید تطبیق داده شوند. برنامهٔ بازگشت باید تکلیف اطلاعاتی را که بعد از شروع مهاجرت ثبت می‌شوند نیز مشخص کند؛ بازگرداندن فایل برنامه لزوماً وضعیت داده را به گذشته نمی‌برد.

برای بررسی اولیه، یک نمونهٔ دادهٔ بی‌نام و توضیح یک اختلاف معمول کافی است. لازم نیست اطلاعات مشتری یا شناسه‌های حساس را عمومی کنید. هدف این مرحله انتخاب فوری همین معماری نیست؛ باید معلوم شود چه چیزی منتقل می‌شود و با چه شاهدی می‌توان نتیجه را پذیرفت. راهنمای تعریف نیاز افزونه به ثبت این مرز کمک می‌کند.