مرور Registry ماژولها
ماژول را بر اساس خانواده، وضعیت و نوع استقرار جستوجو کنید. شناسه، نسخه، وابستگیها و وضعیت فعال بودن را با سورس و تنظیمات محیط تطبیق دهید.
ماژول ثبتشده به import اجباری در Core وابسته نباشد.مدیریت سامانه
حاکمیت ماژولها و دسترسی لایسنس
راهنمای بررسی Registry، قرارداد معماری، وضعیت ماژول، اتصال به لایسنس شرکت و تشخیص علت دیدهنشدن قابلیت.
قبل از شروع
هدف آموزش و مسیر ورود در سامانه
وجود کد یک ماژول بهتنهایی به معنی قابل استفادهبودن آن نیست. ماژول باید در Registry معتبر باشد، قرارداد معماری و وضعیت عملیاتی روشن داشته باشد، در لایسنس شرکت فعال شود و نقش کاربر نیز مجوز لازم را داشته باشد. این تفکیک اجازه میدهد Core مستقل بماند و حذف یا غیرفعالشدن یک ماژول، سامانه اصلی را از کار نیندازد.
مسیر در پنلمدیریت سامانه ← ماژولها و لایسنس
پیشنیازها
قبل از اجرای مراحل، این موارد آماده باشد
شناسه، عنوان و خانواده ماژول مورد بررسی مشخص باشد.قرارداد توسعه و فایلهای معماری ماژول در دسترس باشند.شرکت و کاربر نمونه برای آزمون دسترسی لایسنس آماده باشند.
مراحل انجام کار
گامهای عملی در SysLink ERP
هر مرحله را انجام دهید و همان لحظه کنترل پیشنهادی را بررسی کنید تا خطا دیرتر در گزارش مالی یا عملیاتی دیده نشود.
بررسی قرارداد معماری
جزئیات ماژول را باز و سرویسهای مصرفی، مرز داده، مسیرهای API و الزام حذفپذیری را مرور کنید. وابستگی مستقیم Core به ماژول عملیاتی باید به سرویس عمومی یا قرارداد رسمی تبدیل شود.
با حذف پوشه ماژول اختیاری، Core و ماژولهای نامرتبط همچنان بالا بیایند.
فیلتر و کنترل وضعیت عملیاتی
ماژولهای اختیاری، غیرفعال یا نیازمند بررسی را جدا کنید. ماژول ناقص نباید فقط به دلیل وجود route در منو به مشتری عرضه شود و وضعیت آن باید برای تیم استقرار روشن باشد.
ماژول قابل فروش، API، UI، دسترسی، migration و تست سلامت مشخص داشته باشد.
اتصال ماژول به لایسنس شرکت
در لایسنس شرکت فقط ماژولهای توافقشده را انتخاب کنید. پس از ذخیره، با کاربر همان شرکت وارد شوید و دسترسی منو و API را همراه با نقش کاربر کنترل کنید.
Registry فعال، لایسنس شرکت و مجوز نقش هر سه برای دسترسی نهایی معتبر باشند.
کنترل نهایی
بعد از انجام کار چه چیزی را بررسی کنیم؟
هر ماژول شناسه یکتا، مالک و قرارداد توسعه داشته باشد.
ماژول اختیاری باعث import اجباری یا crash در Core نشود.
فعالسازی لایسنس بدون مجوز نقش، دسترسی حساس ایجاد نکند.
خطاهای رایج
مواردی که نباید از کنارشان عبور کرد
قرار دادن route ماژول در Core بدون feature gate
عرضه ماژول ناقص فقط به دلیل نمایش در Registry
رفع مشکل دسترسی با فعالکردن همه ماژولهای لایسنس
خروجی مورد انتظار
بعد از پایان این آموزش باید به این نتیجه برسید
Registry تمیز و قابل ممیزیقرارداد معماری قابل بررسیدسترسی ماژولی هماهنگ با لایسنس و نقش
راهنمای اجرایی تکمیلی
چطور این آموزش را در کار واقعی اجرا کنیم؟
صفحه «حاکمیت ماژولها و دسترسی لایسنس» باید فقط به خواندن چند مرحله محدود نشود. قبل از اجرای عملی، کاربر باید بداند این کار در کدام شرکت فعال، با کدام نقش، در کدام مسیر پنل و روی کدام داده انجام میشود. اگر مسیر اجرا روشن نباشد، حتی یک عملیات ساده میتواند باعث گزارش اشتباه، دسترسی نامناسب یا اختلاف بین واحدهای فروش، خرید، انبار، خزانه و حسابداری شود.
مخاطب این راهنما سوپرادمین، معمار نرمافزار، مدیر محصول و تیم استقرار است و به همین دلیل باید نتیجه کار برای نقشهای مختلف قابل توضیح باشد. کاربر عملیاتی باید بداند چه چیزی را ثبت میکند، حسابدار باید اثر مالی را ببیند، مدیر باید خروجی قابل اتکا بگیرد و مدیر سیستم باید مطمئن باشد دسترسیها با مسئولیت واقعی افراد هماهنگ است.
مسیر پیشنهادی کنترلمدیریت سامانه ← ماژولها و لایسنس
Registry تمیز و قابل ممیزی
قرارداد معماری قابل بررسی
دسترسی ماژولی هماهنگ با لایسنس و نقش
کنترل و audit
قبل از اتکا به خروجی، این موارد را بررسی کنید
در ERP تجاری، خروجی زمانی قابل اتکا است که مسیر ایجاد آن روشن باشد. اگر یک رکورد از عملیات مبدأ ساخته شده، اصلاح آن هم باید از همان مبدأ انجام شود. همچنین هر تغییر مهم باید دلیل، کاربر، زمان و اثر قابل پیگیری داشته باشد تا بعداً در گزارش رسمی، بستن دوره یا بررسی اختلاف بتوان علت عدد را توضیح داد.
| کنترل | اقدام پیشنهادی |
|---|---|
| 01 | هر ماژول شناسه یکتا، مالک و قرارداد توسعه داشته باشد. |
| 02 | ماژول اختیاری باعث import اجباری یا crash در Core نشود. |
| 03 | فعالسازی لایسنس بدون مجوز نقش، دسترسی حساس ایجاد نکند. |
تمرین کنترل روزانه
بعد از خواندن این راهنما، چه چیزی باید در پنل تست شود؟
برای اینکه آموزش «حاکمیت ماژولها و دسترسی لایسنس» به استفاده واقعی تبدیل شود، یک سناریوی کوچک اما کامل را اجرا کنید. داده نمونه باید به همان شکلی باشد که کاربر در روز کاری با آن روبهرو میشود: شرکت فعال، تاریخ درست، طرف حساب یا کالا، وضعیت سند و نقش کاربر باید مشخص باشد. سپس خروجی را از مسیر گزارش کنترل کنید تا معلوم شود عملیات فقط در فرم ثبت نشده، بلکه در گزارشهای وابسته هم اثر قابل توضیح دارد.
اگر این تمرین برای چند نقش انجام شود، کیفیت استقرار بهتر میشود. کاربر عملیاتی مسیر ثبت را میبیند، حسابدار اثر مالی یا کنترلی را بررسی میکند، مدیر خروجی تصمیمگیری را میسنجد و مدیر سیستم مطمئن میشود داده شرکتها و دسترسیها با هم مخلوط نشدهاند. این مدل مرور باعث میشود خطا قبل از ورود داده واقعی پیدا شود، نه هنگام بستن دوره یا تهیه گزارش رسمی.
یک نمونه عملیات واقعی را انتخاب کنید و مسیر آن را از شروع تا گزارش نهایی دنبال کنید.
همان عملیات را با نقش کاربر محدودتر بررسی کنید تا مطمئن شوید فقط داده و اقدام مجاز دیده میشود.
گزارش وابسته را بعد از ثبت یا اصلاح عملیات دوباره بازبینی کنید و اختلاف عدد را یادداشت کنید.
اگر خطایی رخ داد، پیام خطا، داده مبدأ و اثر گزارش را کنار هم بررسی کنید؛ اصلاح نباید فقط روی خروجی انجام شود.
ریسکهای رایج
چه چیزهایی باعث خطا در استفاده از این بخش میشود؟
بیشترین خطاها زمانی رخ میدهد که کاربر فقط فرم را پر میکند اما به وابستگیهای بعدی توجه ندارد. برای مثال، اگر عملیات روی طرف حساب، کالا، سند، پرداخت یا دوره مالی اثر میگذارد، باید مطمئن شوید گزارش وابسته هم بعد از ثبت قابل توضیح است. در سامانه چندشرکتی، این کنترل اهمیت بیشتری دارد چون داده هر شرکت باید از شرکتهای دیگر جدا بماند.
اگر در این صفحه با عملیات مالی، انبار، خزانه، حقوق یا مالیات سروکار دارید، هیچ اصلاحی نباید صرفاً برای درست شدن ظاهر گزارش انجام شود. ابتدا داده مبدأ، وضعیت تایید، دوره مالی، وابستگی سند و سطح دسترسی را بررسی کنید؛ بعد تصمیم بگیرید اصلاح، ابطال یا ثبت تکمیلی لازم است.
قرار دادن route ماژول در Core بدون feature gateعرضه ماژول ناقص فقط به دلیل نمایش در Registryرفع مشکل دسترسی با فعالکردن همه ماژولهای لایسنس
تحویل به تیم
چه چیزهایی باید قبل از استفاده عمومی روشن باشد؟
راهنمای SysLink زمانی کامل است که بعد از آموزش، مسئولیت هر نقش روشن باشد. اگر کاربر نداند چه دادهای را وارد میکند، تأییدکننده نداند چه چیزی را کنترل میکند یا مدیر نداند گزارش از کدام منبع ساخته شده، حتی بهترین پنل هم به مرور به فایلهای موازی و اصلاح دستی برمیگردد. بنابراین بهتر است تیم، بعد از مطالعه راهنما، یک چکلیست کوتاه برای اجرای همان فرآیند آماده کند.
مسئول ورود داده بداند کدام فیلدها اجباریاند و چرا بدون آنها گزارش قابل اتکا نیست.مسئول تأیید بداند چه چیزی را کنترل میکند: مبلغ، تاریخ، طرف حساب، کالا، وضعیت یا اثر مالی.مدیر یا حسابدار بداند خروجی این بخش در کدام گزارش بعدی دیده میشود.مدیر سیستم بداند کدام نقشها مجاز به مشاهده، اصلاح، تأیید یا ابطال عملیات هستند.
آموزشهای مرتبط
برای کامل شدن جریان کاری، این بخشها را هم ببینید
اشتراک و لایسنسراهاندازی مشتری، پلن و لایسنس شرکتراهنمای ساخت پلن، راهاندازی شرکت مشتری، صدور لایسنس، انتخاب ماژولها و کنترل تاریخ و وضعیت اشتراک.مدیریت دسترسیمدیریت امن نقشها و کاربرانراهنمای طراحی نقش، تخصیص حداقل دسترسی، ساخت کاربر، کنترل دسترسیهای حساس و بازبینی دورهای مجوزها.عملیات سامانهپشتیبانگیری، انتقال و آزمون بازیابیراهنمای کنترل منابع، سیاست بکاپ، اجرای نسخه پشتیبان، صحتسنجی، مقصدهای انتقال و آزمون بازیابی امن.
آموزش محصول
برای اجرای دقیقتر، آموزش را با داده نمونه انجام دهید
اگر این عملیات به فروش، خرید، انبار، خزانه یا حسابداری وصل است، بعد از ثبت، گزارش مرتبط را هم کنترل کنید.