پرش به محتوا
شروع رایگان

گردش تأیید نامه: چرا تأیید باید به نسخهٔ متن گره بخورد؟

نرم‌افزار BPMS در دبیرخانه ابرک؛ قالب‌های آماده و محدودیت‌های واقعی

تیم تحریریهٔ ابرک ۱۴۰۵/۰۸/۱۹ ~9 دقیقه مطالعه
گردش تأیید نامه: چرا تأیید باید به نسخهٔ متن گره بخورد؟

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

سامانهٔ BPMS چیست و گردش تأیید کجای آن می‌نشیند؟

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

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

چرا تأیید باید به نسخه گره بخورد؟

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

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

قالب‌های آماده‌ای که هم‌اکنون در ماژول هستند

ماژول چهار قالب فرایند آماده دارد. هر قالب یک دستهٔ تأیید در Approvals است و یک قانون خودکار دارد که پس از تأیید اجرا می‌شود. قوانین خودکار پیش‌فرض خاموش‌اند، تا پیامک یا فعالیتی بی‌اجازه در تننت‌ها فرستاده نشود و هر شرکت خودش آن‌ها را روشن کند.

  • مرخصی: اگر مدت مرخصی بیشتر از سه روز باشد، برای کاربر منابع انسانی یک فعالیت ثبت می‌شود.
  • خرید کالا و خدمات: اگر مبلغ درخواست به آستانه برسد، فعالیت برای مسئول مالی ثبت می‌شود. آستانه از پارامتر سامانه خوانده می‌شود و مقدار پیش‌فرض آن ۵۰ میلیون ریال است.
  • تنخواه: مبلغ و تاریخ اجباری‌اند. آستانهٔ پیش‌فرض صفر است و تأییدکنندهٔ پیش‌فرض خنثی است، یعنی هیچ کس از پیش انتخاب نشده است.
  • گردش تأیید نامه دبیرخانه: بدون مبلغ و دوره، با تأییدکنندهٔ خنثی که هر دفتر خودش تعیین می‌کند.

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

چه کسی متن نامه را می‌بیند؟

درخواست تأیید در Odoo برای همهٔ کسانی که به Approvals دسترسی دارند دیده می‌شود. به همین خاطر خود درخواست هیچ موضوع، متن یا فایلی ندارد. شمارهٔ نامه و شمارهٔ نسخه در نام درخواست می‌آید و دلیل درخواست یک جملهٔ عمومی است که می‌گوید نامه را از اپ دبیرخانه باز کنید.

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

پیامک و تاریخ شمسی در گردش

وقتی قانون خودکار یک قالب فعال شود، پیامک از مسیر ریل بومی sms.sms تننت ارسال می‌شود. تاریخ‌ها در متن اعلان‌ها با کتابخانهٔ odoo_jalali_pro به شمسی نوشته می‌شوند و کد ماژول خودش تبدیل دستی ندارد. این کار باعث می‌شود تاریخ مرخصی یا مهلت خرید در همهٔ جاها یک‌شکل باشد.

فرض کنید کارشناس خریدی برای ۱۵ مهر خرید ثبت می‌کند و مدیر مالی تا ۲۰ مهر فرصت دارد. متن اعلان همان تاریخ شمسی را نشان می‌دهد و هیچ کس با تبدیل میلادی در ذهنش گیج نمی‌شود. این جزئیات کوچک در عمل بیشتر از بقیهٔ امکانات در حل اختلاف‌ها کمک می‌کنند.

گام به گام راه‌اندازی یک گردش تأیید

  1. برای هر دفتر دبیرخانه یک دستهٔ تأیید انتخاب کنید. بدون آن، درخواستی برای نامه‌های آن دفتر ساخته نمی‌شود.
  2. نامه را ثبت کنید تا نسخهٔ اول ساخته شود. درخواست تأیید فقط برای نسخهٔ ثبت‌شده معنا دارد.
  3. از دکمهٔ درخواست تأیید، تأیید نسخهٔ جاری را بخواهید. اگر نسخه پیش‌تر درخواست فعال داشته باشد، سامانه دوباره درخواست نمی‌سازد.
  4. اگر متن، گیرنده یا پیوست عوض شد، نسخهٔ تازه بسازید. درخواست‌های زندهٔ نسخهٔ قبلی خودکار لغو می‌شوند.
  5. قانون خودکار را روی یک نامهٔ آزمایشی فعال کنید، پیامک و فعالیت را بسنجید، و بعد آن را برای دفتر واقعی بگذارید.

محدودیت‌های این بخش

این ماژول تأیید را به نسخه گره می‌زند، اما قضاوت دربارهٔ محتوای نامه همچنان با انسان است. سامانه نمی‌تواند بفهمد یک بند قرارداد منصفانه است یا نه. قوانین خودکار هم عمداً خاموش شروع می‌شوند و روشن کردن آن‌ها تصمیم مدیر سیستم است.

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

وابستگی‌های این ماژول به دبیرخانه، Approvals و base_automation محدود است. یعنی این بخش به سامانهٔ مؤدیان مالیاتی وصل نیست و چیزی را برای مالیات ارسال نمی‌کند. اگر فرایندی به ارسال مالیاتی نیاز داشته باشد، باید مسیر جدا و تأیید جدا داشته باشد.

یک نامه از ثبت تا تأیید در عمل

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

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

روش گام‌به‌گام برای تصمیم‌گیری درباره‌ی BPMS

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

منابع

مطالب و صفحه‌های مرتبط

می‌خواهید خودتان امتحان کنید؟ آزمایش ۱۴ روزهٔ رایگان ابرک را فعال کنید و طرح‌ها و قیمت‌ها را ببینید.

سؤالات متداول

سامانهٔ BPMS با یک گردش تأیید ساده چه فرقی دارد؟

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

اگر متن نامه بعد از تأیید تغییر کند، تأیید قبلی باطل می‌شود؟

بله. با ساخت نسخهٔ تازه، درخواست‌های زندهٔ نسخهٔ قبلی لغو می‌شوند و در گفتگوی هر درخواست دلیل لغو ثبت می‌شود. نسخهٔ تازه باید دوباره تأیید شود.

چرا قوانین خودکار پیش‌فرض خاموش هستند؟

چون روشن بودن ناخواستهٔ آن‌ها می‌تواند پیامک و فعالیت زیادی بفرستد. با خاموش بودن پیش‌فرض، هر شرکت پیش از اجرا آزمون می‌کند و هزینهٔ پیامک را هم آگاهانه می‌پذیرد.

آیا تأییدکننده‌ها متن نامه را می‌بینند؟

فقط کسانی که به خود نامه دسترسی دارند متن را می‌بینند. تأییدکننده‌ها بعد از ثبت درخواست به‌عنوان شرکت‌کننده اضافه می‌شوند تا همان نسخه را بخوانند.

آیا این ماژول چیزی را برای سامانهٔ مؤدیان مالیاتی می‌فرستد؟

خیر. وابستگی‌های این ماژول به دبیرخانه، Approvals و base_automation محدود است و ارسال مالیاتی در آن وجود ندارد.

برای شروع کوچک از کدام قالب شروع کنم؟

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

ERP ابری ایرانی: معیار انتخاب و آنچه ابرک دارد

ابرک را کامل و رایگان به‌کار بگیرید

۱۴ روز رایگان