ساخت اپ اندروید و کامپیوتر جهت انبار داری

---

شرح پروژه

درخواست انجام پروژه

طراحی و توسعه سیستم مدیریت انبار، محموله، فاکتور و حساب مشتری

1. معرفی پروژه

به یک فریلنسر باتجربه یا تیم کوچک حرفه‌ای برای پیاده‌سازی یک سیستم واقعی مدیریت انبار و فاکتور نیاز داریم.

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

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

2. هدف پروژه

هدف، ساخت سیستمی برای مدیریت موارد زیر است:

- چند انبار

- مشتریان

- محموله‌ها و کالاهای متعلق به مشتری

- ورود کالا

- خروج کالا

- مرجوعی

- موجودی

- فاکتور خروج

- فاکتور مالی

- فاکتور مالی تجمیعی

- حساب مشتری

- بدهی و بستانکاری

- پرداخت و تخصیص پرداخت

- گزارش‌ها

- فایل و PDF

- Audit و کنترل صحت اطلاعات

نسخه اصلی موردنیاز شامل Android APK + Backend/API + PostgreSQL است و در صورت توافق، نسخه Desktop نیز باید با همان Backend و دیتابیس قابل استفاده باشد.

3. امکانات اصلی مورد انتظار

سیستم باید حداقل شامل بخش‌ها و امکانات زیر باشد:

- مدیریت شرکت

- مدیریت کاربران و نقش‌ها

- مدیریت چند انبار

- تعیین دسترسی هر مدیر به انبارهای مجاز

- پرونده مشتری و اطلاعات تماس/آدرس

- ثبت محموله یا کالای مشتری بدون نیاز به Product Catalog عمومی

- ثبت شرح، بسته‌بندی، تعداد، وزن، واحد سفارشی و توضیحات

- ثبت ورود، خروج و مرجوعی

- کنترل موجودی بر اساس وزن، تعداد یا مقدار سفارشی

- جلوگیری از خروج بیش از موجودی

- مشاهده موجودی هر انبار و موجودی تجمیعی مشتری

- صدور فاکتور خروج

- صدور فاکتور مالی از روی خروج‌ها

- امکان تجمیع چند خروج در یک فاکتور مالی

- حساب مالی مشتری

- ثبت پرداخت

- تخصیص یک پرداخت به یک یا چند فاکتور

- ثبت پرداخت بدون تخصیص و نگهداری آن به‌عنوان اعتبار مشتری

- گزارش بدهکاران و بستانکاران

- جستجو و فیلتر

- تولید PDF

- مدیریت فایل‌های مرتبط

- اعلان‌ها

- Audit Log

- Reconciliation برای شناسایی مغایرت اطلاعات

4. معماری فنی

معماری موردنظر:

Android / Desktop → Backend/API → PostgreSQL

اتصال مستقیم اپلیکیشن یا Client به PostgreSQL قابل قبول نیست.

Backend باید مسئول موارد زیر باشد:

- Authentication

- Authorization

- Business Logic

- Validation

- Transaction Management

- Idempotency

- Concurrency / Locking

- کنترل دسترسی به انبارها

- Audit

- API Security

دیتابیس هدف PostgreSQL است.

5. فایل‌ها و طراحی اولیه پروژه

در شروع کار فایل‌های زیر در اختیار مجری قرار می‌گیرد:

- Master Specification پروژه

- SQL1 مربوط به ساختار پایه دیتابیس

- SQL2 مربوط به Business Logic

- فایل تست‌های SQL

- توضیحات و تصمیمات طراحی

- نیازمندی‌های رابط کاربری

این فایل‌ها نسخه غیرقابل‌تغییر و مصون از خطا فرض نمی‌شوند.

مجری موظف است آنها را بررسی کند و اگر مواردی مانند خطای SQL، ناسازگاری بین SQL1 و SQL2، Constraint ناقص، مشکل Transaction، مشکل Concurrency، ضعف امنیتی، مشکل طراحی دیتابیس، ایراد Business Logic، نقص تست‌ها، مشکل Performance یا هر ایراد فنی مهم دیگری وجود داشت، آن را قبل از نهایی‌سازی اعلام کند و پس از تأیید، اصلاحات لازم را انجام دهد.

انتظار می‌رود بررسی فنی فایل‌های اولیه بخشی از اجرای پروژه باشد و صرفاً به اجرای بدون بررسی فایل‌های موجود اکتفا نشود.

6. منطق مهم پروژه

عملیات اصلی مانند ورود، خروج و مرجوعی باید Atomic باشند.

اگر یک عملیات چندقلمی دارای خطا باشد، نباید بخشی از عملیات ثبت شود و کل عملیات باید به وضعیت قبل از شروع برگردد.

خروج نباید باعث منفی شدن موجودی شود.

مرجوعی باید به خروج اصلی قابل ردیابی باشد.

عملیات تکراری نباید به دلیل ارسال دوباره Request باعث ثبت دوباره اطلاعات شوند؛ بنابراین Idempotency الزامی است.

سیستم باید برای استفاده همزمان چند کاربر طراحی شود و در موارد لازم Locking / Concurrency Control داشته باشد.

اطلاعات تاریخی نباید با حذف ساده از بین بروند و عملیات اصلاح یا ابطال باید قابل ردیابی باشند.

7. نقش‌ها و دسترسی

حداقل دو نقش وجود دارد:

مدیر کل

- دسترسی کامل

- مدیریت کاربران

- مدیریت انبارها و دسترسی‌ها

- گزارش‌ها

- عملیات مدیریتی و مالی

مدیر انبار

- دسترسی فقط به انبارهای اختصاص‌یافته

- انجام عملیات مجاز همان انبار

کنترل دسترسی نباید فقط در رابط کاربری انجام شود و باید در Backend/API نیز به‌صورت واقعی enforce شود.

8. رابط کاربری

رابط کاربری باید:

- کاملاً فارسی

- RTL

- ساده و تمیز

- حرفه‌ای

- قابل استفاده برای کاربر غیرمتخصص

- مناسب موبایل

باشد.

صفحات اصلی شامل بخش‌هایی مانند:

- داشبورد

- مشتریان

- انبارها

- موجودی

- ورود

- خروج

- مرجوعی

- فاکتورها

- حساب مالی

- پرداخت‌ها

- گزارش‌ها

- بدهکاران

خواهد بود.

قبل از اجرای کامل UI، طراحی اولیه صفحات اصلی برای بررسی و تأیید ارائه شود.

9. تکنولوژی

تکنولوژی پیشنهادی:

- PostgreSQL

- Backend/API مناسب و قابل نگهداری

- Flutter / FlutterFlow یا راهکار فنی مناسب برای Client

- Android APK

- در صورت توافق Desktop

فریلنسر می‌تواند تکنولوژی مناسب‌تری پیشنهاد دهد، ولی باید دلیل فنی انتخاب خود را توضیح دهد.

10. تست و کیفیت

تحویل صرفاً کد نیست. پروژه باید واقعاً اجرا و تست شود.

حداقل تست‌های مورد انتظار شامل موارد زیر است:

- ورود

- خروج

- موجودی ناکافی

- Rollback

- مرجوعی

- Idempotency

- دسترسی کاربران

- دسترسی انبار

- فاکتور خروج

- فاکتور مالی

- فاکتور تجمیعی

- پرداخت

- تخصیص پرداخت

- پرداخت بدون تخصیص

- Void / Correction

- Reconciliation

- تست همزمانی چند کاربر

- سناریوهای خطا

- تست سازگاری SQL1 و SQL2

به‌خصوص اجرای واقعی PostgreSQL و تست عملی پروژه الزامی است و صرفاً بررسی کد یا اعلام «بدون خطا» کافی نیست.

تست‌ها باید در محیط واقعی اجرای PostgreSQL انجام شوند و موارد مربوط به Transaction، Rollback، Idempotency و Concurrency نیز به‌صورت عملی بررسی شوند.

11. تحویل پروژه

تحویل نهایی باید شامل موارد زیر باشد:

- سورس کامل Backend

- سورس کامل Android/Flutter/FlutterFlow

- SQL و Migrationهای نهایی

- دیتابیس نهایی

- API

- APK قابل نصب

- فایل‌های لازم برای Build

- مستندات نصب و راه‌اندازی

- اطلاعات لازم برای Deployment

- مستندات مختصر ساختار پروژه

- نتایج تست‌های اصلی

سورس پروژه باید کامل و قابل انتقال و ادامه توسعه توسط توسعه‌دهنده دیگر باشد.

12. قابلیت توسعه آینده و AI

AI جزو هسته اجباری نسخه اول نیست.

اما معماری پروژه باید به‌گونه‌ای باشد که در آینده بتوان یک AI Gateway / AI Module به Backend اضافه کرد و آن را به سرویس‌ها یا مدل‌های مختلف متصل نمود، بدون اینکه هسته اصلی سیستم دوباره طراحی شود.

هدف فعلی، آماده بودن معماری برای اتصال آینده به AI است، نه پیاده‌سازی کامل AI در نسخه اول.

13. روش اجرای پروژه

ترجیح ما اجرای مرحله‌ای است:

مرحله 1: بررسی Specification، SQL و معماری و اعلام ایرادات احتمالی

مرحله 2: اجرای واقعی PostgreSQL، اصلاح و نهایی‌سازی Database

مرحله 3: تکمیل Backend/API

مرحله 4: طراحی و پیاده‌سازی UI

مرحله 5: اتصال Client به Backend

مرحله 6: تست کامل و رفع خطا

مرحله 7: تولید APK و تحویل کامل سورس

مرحله 8: در صورت توافق، نسخه Desktop و Deployment

پرداخت نیز ترجیحاً بر اساس تحویل واقعی هر مرحله انجام شود.

14. لطفاً در پیشنهاد خود مشخص کنید

1. تجربه شما در PostgreSQL و Backend/API چیست؟

2. با Flutter یا FlutterFlow چه میزان تجربه دارید؟

3. آیا تجربه ساخت اپلیکیشن Android واقعی دارید؟

4. نمونه‌کار مشابه دارید؟

5. زمان تقریبی اجرای پروژه چقدر است؟

6. قیمت کل پروژه چقدر است؟

7. هزینه هر مرحله چقدر است؟

8. دقیقاً چه مواردی در تحویل شما خواهد بود؟

9. آیا PostgreSQL را واقعاً اجرا و تست می‌کنید؟

10. آیا تست Concurrency و Transaction را انجام می‌دهید؟

11. چه مدت پشتیبانی پس از تحویل ارائه می‌کنید؟

12. چه تکنولوژی Backend را پیشنهاد می‌کنید و چرا؟

نکته مهم

ما به دنبال Prototype، Demo یا صرفاً چند صفحه UI نیستیم.

هدف، ساخت یک نسخه واقعی، قابل استفاده، قابل تست و قابل توسعه است.

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

لطفاً پیشنهاد خود را بر اساس بررسی این شرایط و با قیمت و زمان واقع‌بینانه ارائه کنید.

مهارت ها و تخصص های مورد نیاز

---

---