درخواست طراحی و پیادهسازی سیستم ERP جامع بازرگانی، حمل، ترخیص و تسویه مالی و مدیریت کارمندان
دو ساعت پیش منتشر شده
تعداد بازدید: 20
کد پروژه: 618240
شرح پروژه
بستر اجرا:
Odoo 19 یا ERPNext (Frappe Framework 15)
هدف طراحی، پیادهسازی و راهاندازی یک سیستم ERP یکپارچه برای مدیریت فرآیندهای بازرگانی، خرید و فروش، تأمین کالا، حملونقل، بارگیری، باسکول، عملیات مرزی و ترخیص، تحویل، مدیریت هزینهها، پرداخت و تسویه مالی، کنترل تناژ و مغایرت، مدیریت طلب از کارخانه، کارتابل و وظایف، گزارشها و داشبوردهای مدیریتی تعریف میشود.
۱. هدف سامانه
سامانه باید یک سیستم یکپارچه برای مدیریت عملیات شرکت بازرگانی بدون انبار باشد؛ از ثبت دستور خرید/فروش تا تأمین کالا، حمل، بارگیری، باسکول، مرز، ترخیص، تحویل، هزینهها، پرداخت، تسویه، مغایرت تناژ و بستهشدن پرونده.
کالا مستقیماً از کارخانه به مشتری یا مرز خروجی منتقل میشود. تمام مراحل، مسئولیتها، وضعیتها، تصمیمات، اسناد و سوابق باید در سامانه متمرکز و قابل پیگیری باشد.
۲. گردش اصلی فرآیند
فرآیند باید شامل موارد زیر باشد:
ثبت دستور خرید یا فروش توسط مدیرعامل و تشکیل پرونده.
ثبت کالا، کارخانه/تأمینکننده، مشتری، مقصد، مرز، تناژ، قیمت و ارز.
پشتیبانی از دو حالت «خرید اول» و «فروش اول».
بررسی حقوقی، مالی، نقدینگی و اعتبار مشتری.
امکان برگشت پرونده برای اصلاح با ثبت علت و رد قطعی با ثبت دلیل و اطلاع مدیرعامل.
تهیه سند حسابداری خارج از سامانه، چاپ و امضای فیزیکی و بارگذاری تصویر سند امضاشده.
جلوگیری از صدور ریزفاکتور تا تکمیل تأییدها و ثبت سند امضاشده.
صدور چند ریزفاکتور برای هر پرونده و چند محموله برای هر ریزفاکتور.
مدیریت محموله از انتخاب راننده و خودرو تا بارگیری، باسکول، مرز، ترخیص، تحویل و تسویه.
ثبت هزینه، درخواست پرداخت و پرداخت واقعی به صورت جداگانه.
کنترل مغایرت تناژ و ثبت طلب از کارخانه.
بررسی نهایی و بستهشدن پرونده.
ارائه گزارش و داشبورد مدیریتی.
در حالت «فروش اول»، تا زمان تکمیل تأمین کالا و سند خرید، پرونده باید در وضعیت «در انتظار تأمین کالا» باشد و صدور ریزفاکتور مجاز نباشد.
۳. ساختار پرونده و اسناد
هر معامله یک پرونده اصلی دارد و میتواند چند نوع کالا داشته باشد. برای هر کالا مشخصات، ابعاد، ضخامت، تناژ قراردادی، قیمت خرید و فروش، ارز، تأمینکننده، مشتری، مقصد، مرز، توضیحات و اسناد ثبت شود.
ساختار اصلی:
پرونده ← کالا ← ریزفاکتور فروش ← محموله
پیشفاکتور خرید و فروش از ریزفاکتور مستقل بوده و باید امکان ایجاد، ویرایش، ورود/خروجی اکسل و نگهداری در پرونده را داشته باشد.
۴. ریزفاکتور فروش
ریزفاکتور سند رسمی فروش است و با پیشفاکتور تفاوت دارد. صدور آن فقط پس از تکمیل تأییدهای لازم و بارگذاری تصویر سند حسابداری امضاشده مجاز است.
هر پرونده میتواند چند ریزفاکتور و هر ریزفاکتور چند محموله داشته باشد.
۵. مدیریت حمل، راننده و خودرو
برای هر محموله پرونده حمل ایجاد شود و اطلاعات زیر قابل ثبت باشد:
راننده، خودرو، پلاک و باربری
شماره بارنامه
مبلغ کل کرایه، پیشکرایه و مانده
بیمه
کارخانه، مشتری و مرز
تاریخ و وزنهای بارگیری
اسناد حمل و وضعیت محموله
اطلاعات راننده و خودرو باید به عنوان اطلاعات پایه نگهداری و در حملهای بعدی قابل استفاده باشد.
برای راننده، مشخصات هویتی، ایرانی/خارجی بودن، موبایل، گواهینامه، کارت هوشمند، وضعیت و تاریخ بررسی و اطلاعات بانکی ثبت شود.
برای خودرو، نوع و شماره پلاک، ظرفیت، بیمه، معاینه فنی و مجوزهای لازم ثبت و کنترل شود.
سامانه باید رانندگان ایرانی و خارجی را با اعتبارسنجی متناسب با وضعیت هرکدام پشتیبانی کند.
۶. بارگیری و باسکول
در بارگیری امکان ثبت و کنترل موارد زیر وجود داشته باشد:
تأیید راننده و خودرو و کنترل مدارک
بارنامه و تطابق آن با حواله
کرایه و بیمه
باسکول کارخانه، وزن پر، خالی و خالص
پکینگلیست و اسناد مرتبط
تکراری بودن پلاک، بارنامه یا اطلاعات راننده نباید باعث رد خودکار شود؛ سوابق قبلی باید نمایش داده شده و امکان بررسی وجود داشته باشد.
۷. مرز و ترخیص
برای هر محموله موارد زیر ثبت شود:
بررسی راننده، کارت هوشمند و وزن
نیاز یا عدم نیاز به بیجک
اظهارنامه و بیجک
ترخیصکار و نماینده مرزی
تاریخ و ساعت و وضعیت ترخیص
هزینه گمرک و حقالعمل ترخیص
تماسها و هماهنگیهای انجامشده
هزینه گمرک و حقالعمل ترخیص باید مستقل از یکدیگر ثبت و گزارش شوند.
۸. تحویل و تسویه
در مرحله تحویل، تأیید اسناد مرزی و ترخیص، رسید تخلیه و تصویر آن، اطلاعات بانکی ذینفع و درخواست هزینه ثبت شود.
رسید تخلیه پیششرط تسویه نهایی کرایه است.
چرخه پرداخت حمل شامل:
پیشکرایه مبدأ ← هزینه گمرک/ترخیص مرز ← صافی نهایی مقصد
بیمه نیز هزینه مستقل باشد.
صافی بر اساس کل کرایه و پیشکرایههای پرداختشده محاسبه شود و قبل از رسید تخلیه امکان پرداخت نهایی وجود نداشته باشد.
۹. هزینهها و پرداختها
نوع هزینه باید قابل تنظیم باشد و افزودن نوع جدید نیازمند تغییر برنامه نباشد. هر هزینه شامل نوع، مبلغ، ارز، ذینفع و وضعیت پرداخت باشد.
چرخه پرداخت:
هزینه ← درخواست پرداخت ← تأیید ← پرداخت واقعی
فقط پرداخت واقعی به عنوان واریزی قطعی محسوب شود. سیستم باید از درخواست یا پرداخت تکراری جلوگیری کرده و پرداختهای قسطی و چندمرحلهای را پشتیبانی کند. ثبت پرداخت واقعی فقط برای کاربران مجاز مالی ممکن باشد.
ورود کرایه از اکسل فقط باید درخواست پرداخت ایجاد کند، نه پرداخت قطعی.
۱۰. تناژ و مغایرت
سه مقدار باید مستقل نگهداری شوند:
تناژ قراردادی
تناژ رزروشده/در جریان
تناژ واقعی و تأییدشده باسکول
وزن واقعی فقط از باسکول تأییدشده محاسبه شود و وزن بارنامه جایگزین آن نباشد.
در صورت کسری و نبود برنامه حمل دیگری برای تکمیل قرارداد، سیستم باید کسری را محاسبه، علت بستن پرونده را ثبت و آن را در دفتر طلب از کارخانه قرار دهد. طلب باید امکان تسویه کامل یا بخشی و ارتباط با معامله جبرانی آینده داشته باشد.
۱۱. کارتابل و وظایف
هر کاربر باید کارتابل متناسب با نقش خود داشته باشد و کارهای ارجاعشده، جدید، منتظر اقدام، فوری، عقبافتاده، پروندهها و حملهای مربوط، فعالیتهای اخیر و اعلانها را ببیند.
هر وظیفه دارای مسئول، زمان انجام و وضعیت باشد. سرپرست بتواند وظیفه را به فرد واجد شرایط دیگری ارجاع دهد و علت ارجاع ثبت شود.
۱۲. همکاری همزمان واحد حمل
بخشهای «اسناد و ناوگان»، «مرز و ترخیص» و «تحویل و تسویه» باید بتوانند همزمان روی یک پرونده کار کنند. وابستگی مراحل فقط در موارد ضروری اعمال شود و یک واحد به دلیل وابستگی غیرضروری متوقف نشود.
۱۳. اعلان و SLA
سامانه باید اعلان داخلی و امکان پیامک قابل تنظیم داشته باشد.
رویدادهای مهم مانند ثبت/ارجاع پرونده، نقص یا رد، تأیید، ثبت راننده و بارنامه، باسکول، بیجک، ترخیص، تحویل، درخواست/انجام پرداخت، بستن پرونده و ثبت طلب کارخانه باید قابلیت اعلان داشته باشند.
پیامک باید قابل فعال/غیرفعال شدن باشد و متن و گیرنده آن قابل تنظیم باشد. ارسال تکراری برای یک رویداد مجاز نباشد.
SLA هر وظیفه باید قابل تنظیم بوده و وضعیت «عادی، نزدیک تأخیر، تأخیرکرده و بحرانی» بر اساس زمان همان وظیفه محاسبه شود.
۱۴. داشبوردها
داشبورد مدیرعامل باید حداقل معاملات، خرید و فروش، سود، تناژ، کارخانهها و مرزها، حملهای جاری، پروندههای متوقف، پرداختهای منتظر، هزینهها، سود هر بار/مشتری/کارخانه، طلب کارخانه و هشدارهای بحرانی را نمایش دهد.
اعداد داشبورد باید قابل کلیک باشند و کاربر را به پروندههای تشکیلدهنده آن عدد هدایت کنند.
برای مالی، حمل، حقوقی، خزانه و وصول نیز داشبورد و کارتابل متناسب با نقش ارائه شود.
۱۵. گزارشها
گزارشها باید از ابتدا جزو هسته سامانه باشند و قابلیت فیلتر، جستوجو، مرتبسازی و مشاهده جزئیات داشته باشند.
حداقل گزارشها:
جامع خرید و فروش
کرایه، پیشکرایه و مانده
گمرک و ترخیص
تناژ
سود و سود هر بارگیری
پرداختها
پروندههای متوقف
پکینگلیست
مانده ردیف کالا
فاکتورهای باز خرید و فروش
بارگیری کارخانهها به تفکیک مرز
خلاصه روزانه، ماهانه و سالانه
دفتر طلب از کارخانه
گزارش جامع خرید و فروش باید تاریخ، شماره، طرف معامله، کالا، تناژ، مبالغ، خروجی و خروجی تجمعی، مازاد و مازاد تجمعی، مانده و وضعیت پرونده را برای خرید و فروش نمایش دهد و ارتباط آنها را در معاملات همزمان حفظ کند.
۱۶. اکسل
باید ورود و خروجی اکسل داشته باشد.
خروجی شامل داده استاندارد و قالب اختصاصی شرکت باشد. قالبهای شرکت باید بدون تغییر در متن، ساختار، فرمول، ادغام سلول، ظاهر و چیدمان استفاده شوند.
ورود اکسل باید ابتدا پیشنمایش و اعتبارسنجی شود و پس از تأیید وارد سامانه گردد. اطلاعات مبهم نباید حدس زده شوند و باید برای بررسی انسانی مشخص شوند.
۱۷. چاپ و اسناد
چاپ فارسی و راستچین با قالب استاندارد برای تاریخ، اعداد، لوگو و مشخصات شرکت الزامی است.
حداقل اسناد:
برگه پرونده و بارگیری
بارنامه
قبض باسکول
رسید تخلیه
پکینگلیست
پیشفاکتور خرید و فروش
صورتحساب باربری
صورتحساب گمرک و ترخیص
۱۸. جستوجو و موبایل
جستوجوی سریع بر اساس شماره پرونده، بارنامه، پلاک، شماره ملی، مشتری، کارخانه و مرز امکانپذیر باشد.
سامانه باید روی موبایل نیز قابل استفاده باشد و همه امکانات را پشتیبانی کند.
۱۹. امنیت و سطح دسترسی
دسترسی بر اساس نقش و مسئولیت کنترل شود. ثبت پرونده، تأیید، پرداخت، عملیات حمل و سایر فعالیتها مجوزهای مستقل داشته باشند.
کاربر حمل نباید امکان پرداخت قطعی داشته باشد و کاربران مالی فقط در محدوده مجاز خود عملیات مالی انجام دهند. حسابرس امکان مشاهده بدون تغییر داشته باشد.
محدودیتهای دسترسی باید در تمام روشهای دسترسی، از جمله API و لینک مستقیم، اعمال شوند و قابل دور زدن نباشند.
۲۰. سابقه و ممیزی
تمام رویدادهای مهم با کاربر، زمان و جزئیات ثبت شوند؛ از جمله ایجاد، تأیید، رد، ارجاع، بازگشت، بارگذاری اسناد، درخواست و انجام پرداخت، بستن پرونده و عبور اضطراری از اعتبارسنجی.
حذف اطلاعات یا اسناد نباید سابقه عملیاتی را از بین ببرد.
۲۱. اعتبارسنجی
شماره ملی، موبایل، شبا، پلاک، گذرنامه، کارت هوشمند و وزن باسکول باید کنترل شوند.
قوانین اعتبارسنجی برای افراد خارجی باید متناسب با شرایط آنها باشد. هرگونه عبور اضطراری از کنترل باید با ذکر دلیل و ثبت در سابقه ممیزی انجام شود.
۲۲. بستن پرونده
پیش از بستهشدن نهایی، کنترلهای خرید، فروش، راننده، بارنامه، باسکول، بیجک در صورت نیاز، ترخیص، تحویل، پرداختها و تأیید مالی انجام شود.
در صورت وجود مغایرت واقعی، سرپرست مجاز بتواند با ثبت دلیل پرونده را دستی ببندد.
۲۳. موارد خارج از نسخه اول
موارد زیر جزو هسته نسخه اول نیستند و نباید موجب پیچیدگی یا تأخیر پروژه شوند:
واتساپ و چت سازمانی، نقشه زنده حمل، فرمساز/گزارشساز/داشبوردساز عمومی، BI مستقل، هوش مصنوعی، OCR، اتوماسیون اداری کامل، رتبهبندی کارکنان، تقویم عمومی و شبیهسازی نرمافزار حسابداری.
۲۴. معیار پذیرش پروژه
مجری باید حداقل سناریوهای زیر را به صورت واقعی و انتهابهانتها اجرا و تست کند:
معامله کامل از دستور تا بستهشدن
فروش اول و تأمین بعدی کالا
چند محموله برای یک ریزفاکتور
خرید و فروش با ارزهای متفاوت
مغایرت تناژ و ثبت طلب کارخانه
پرداخت چندمرحلهای بدون پرداخت تکراری
کنترل کامل سطح دسترسی
کنترل اسناد و امضای فیزیکی
ثبت و گزارش هزینههای حمل
تفکیک گمرک و حقالعمل ترخیص
کارتابل و وظایف کاربران
داشبورد مدیریتی قابل کلیک
ورود و خروجی اکسل
چاپ اسناد فارسی
ثبت کامل سوابق و ممیزی
۲۵. تعهدات مجری و مبنای قیمت
مجری باید سامانهای کامل، عملیاتی و قابل استفاده تحویل دهد، نه صرفاً فرمها و صفحات نمایشی. تمام فرآیندهای اصلی باید از ابتدا تا انتها اجرا و تست شوند و سطح دسترسی با نقشهای واقعی آزمایش شود.
موارد تحویلی حداقل شامل:
سامانه نصبشده و عملیاتی
تنظیمات اولیه و اطلاعات پایه
گزارشها و داشبوردها
فرمهای چاپی
ورود و خروجی اکسل
آموزش کاربران
مستندات لازم
تست سناریوهای اصلی
رفع خطاهای مربوط به قابلیتهای تحویلی
مبنای قیمتگذاری باید کل محدوده فوق باشد. قابلیتهایی که در این سند به عنوان نیازمندی نسخه اول مشخص شدهاند، نباید پس از قرارداد به عنوان «امکانات اضافه» یا هزینه جداگانه اعلام شوند.
این نسخه از سند نیازمندی از نظر حجم بهمراتب فشرده شده است، ولی بخشهای مهمی که برای قیمتگیری، قرارداد و جلوگیری از هزینههای اضافه بعدی لازماند حفظ شدهاند.
نسخه اصلی سند نیازمندی پس از پذیرش پروژه اراده میشود
مهارت ها و تخصص های مورد نیاز
بودجه
25,000 تومان تا 500,000 تومان
مهلت برای انجام
30روز
وضعیت مناقصه
باز (آماده دریافت پیشنهاد)
درباره کارفرما
عضویت دو ساعت پیش
