ساخت نرم‌افزار انبارداری با هوش مصنوعی؛ ورود، خروج و موجودی قابل بررسی

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

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

چهار تصویر مقاله مستقیماً از HTMLهای ارسالی، داخل قاب روشن نمایشی کُندا تهیه شده‌اند؛ چیدمان و اجزای طرح‌ها حفظ شده‌اند. آمار، پیش‌بینی، اتصال حسگر، بارکدخوان و نتایج آزمون نوشته‌شده داخل تصاویر، تأیید قابلیت یا کارکرد کُندا نیستند. آزمون عددی این راهنما جداگانه، با کالای ساختگی و یک سرور مستقل محلی در ۸ آبان ۱۴۰۵ انجام شده است؛ دادهٔ آزمون با اعداد داخل طرح‌ها فرق دارد.

چه کسی به این نسخهٔ کوچک نیاز دارد؟

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

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

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

قبل از پرامپت، کد و واحد کالا را مشخص کن

«بست»، «بست کوچک» و «بست سری جدید» نباید بی‌قاعده به جای یکدیگر وارد شوند. برای هر کالا یک کد ثابت و یک واحد پایه تعیین کن. در مثال این مقاله، کد CAP-01 نام «درپوش نمونه» و واحد «عدد» دارد.

افتتاحیه را هم بدون توضیح در یک عدد پنهان نکن؛ نقطهٔ شروع باید مشخص باشد. در این تمرین کالای وزنی نداریم و تبدیل کارتن به عدد هم پیاده نشده است. اگر واقعاً هر کارتن ۱۲ عدد است، این رابطه را برای همان کالا تعریف و آزمون کن؛ یک واحد عمومی «عدد / کارتن» بدون قاعده، جواب قابل بررسی نمی‌دهد.

فرمول موجودی چه باشد؟

برای این نسخه، رابطه کوتاه است:

موجودی فعلی = موجودی افتتاحیه + مجموع ورودهای معتبر − مجموع خروج‌های معتبر

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

به یک عدد نهایی اکتفا نکن. باید بتوانی تاریخچه را باز کنی و به همان عدد برسی. اگر فقط «موجودی = ۲۰» ذخیره شده باشد، هنوز نمی‌دانی این ۲۰ از کدام دریافت و حواله ساخته شده است.

پرامپت ساخت سیستم انبار را چطور بنویسیم؟

درخواست را به رفتار محدود کن. به‌جای «انبار هوشمند کامل با همهٔ امکانات»، از کُندا بخواه ورود و خروج یک کالا را درست نگه دارد و بخش‌های متصل‌نشده را روشن معرفی کند.

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

قبل از ارسال، نام کالاها، واحد و نقش‌ها را برای کار خودت تنظیم کن. می‌توانی قالب‌های کُندا را هم بررسی کنی، اما ظاهر آماده را با ذخیره و منطق آماده یکی ندان. معیار نسخهٔ اول این است: «با یک دفتر حرکت معلوم، همان موجودی محاسبه شود و ارسال دوبارهٔ همان درخواست، تعداد را عوض نکند.»

ورود و خروج را با یک مثال کوچک دنبال کن

از ۲۰ درپوش نمونه شروع می‌کنیم. ۸ عدد دریافت می‌شود و موجودی به ۲۸ می‌رسد. بعد ۵ عدد خارج می‌شود؛ انتظارمان ۲۳ است. درخواست همان خروج را دوباره می‌فرستیم؛ چون همان ثبت است، موجودی باید ۲۳ بماند. در پایان یک خروج تازهٔ ۳عددی ثبت می‌کنیم و به ۲۰ برمی‌گردیم.

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

با تعداد اشتباه چه کنیم؟

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

در آزمون محلی، صفر، منفی، ۱٫۵، مقدار متنی، مقدار خالی، مقدار تهی، مقدار بولی و مقدار بیشتر از حد تعریف‌شده رد شدند. خروج ۲۴عددی در زمانی که ۲۳ عدد موجود بود نیز رد شد و ردیفی به دفتر اضافه نکرد. در رابط واقعی، هم پیام را بررسی کن و هم داده را دوباره بخوان؛ پیام «رد شد» به‌تنهایی اثبات نمی‌کند چیزی ذخیره نشده است.

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

اگر دکمه دوبار زده شد، کالا دوبار خارج نشود

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

برای همان عمل ثبت یک شناسه نگه دار. سرور باید سه حالت را از هم جدا کند:

• شناسهٔ تازه با دادهٔ معتبر: حرکت را یک بار ثبت کند.
• همان شناسه با همان داده: همان ثبت قبلی را شناسایی کند و حرکت دوم نسازد.
• همان شناسه با دادهٔ متفاوت: تعارض را اعلام کند؛ درخواست قبلی بی‌صدا عوض نشود.

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

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

اگر دو نفر هم‌زمان حواله ثبت کنند چه؟

یک آزمایش جدا انجام دادیم: موجودی کالای آزمایشی ۵ عدد بود و دو درخواست مستقل، هر کدام برای خروج ۴ عدد، هم‌زمان فرستادیم. تنها یکی ثبت شد، دیگری رد شد و موجودی ۱ ماند. در آزمایش دیگری، یک درخواست ۲عددی را با همان شناسه سه بار هم‌زمان فرستادیم؛ فقط یک حرکت ساخته شد.

هدف این نیست که از یک آزمایش کوچک، ظرفیت سامانهٔ عمومی را نتیجه بگیریم. هدف این است که «بررسی موجودی» و «ثبت خروج» از هم جدا و آسیب‌پذیر نباشند. اگر هر دو درخواست ابتدا عدد ۵ را ببینند و بعد بی‌هماهنگی بنویسند، یک بررسی ظاهراً درست ممکن است به خروج نامعتبر برسد.

در این تمرین محلی، بررسی و نوشتن در یک تراکنش انجام شدند. مستندات تراکنش SQLite مرجع فنی این رفتار است. نتیجهٔ محدود محلی، آزمون فشار، ظرفیت چندانبار یا تضمین همهٔ شرایط قطع ارتباط نیست.

پس از رفرش، از دادهٔ ذخیره‌شده بخوان

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

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

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

داشبورد چه چیزی را روشن کند؟

داشبورد باید به سؤال عملی جواب بدهد: الان از این کد کالا چند عدد داریم و این عدد از کدام حرکت‌ها آمده است؟ لینک به دفتر کالا، زمان و مرجع حرکت‌ها از یک عدد درشتِ بدون توضیح مفیدتر است.

جمع «۱۰ عدد»، «۵ کیلوگرم» و «۳ کارتن» یک موجودی معنادار نمی‌سازد. واحد و کالا را در گزارش نگه دار. اگر حد کمبود تعریف می‌کنی، ابتدا یک آستانهٔ مشخص و قابل بررسی بگذار؛ هشدار رسیدن به حداقل با پیش‌بینی تقاضا توسط هوش مصنوعی یک قابلیت نیست.

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

قبل از استفاده، کدام بررسی‌ها ضروری‌اند؟

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

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

اگر ثبت سفارش و موجودی را بعداً به هم وصل می‌کنی، زمان کاهش موجودی و وضعیت سفارش را دقیق تعریف کن؛ این اتصال در نمونه وجود ندارد. راهنمای سایت ثبت سفارش با هوش مصنوعی می‌تواند مسیر مستقل آن بخش را روشن کند.

قدم بعدی: اول یک دفتر موجودی قابل توضیح بساز

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

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