چرا نرمافزار تولید قرارداد نباید فقط «قالب ورد» باشد؟
بیشتر سازمانها قرارداد را با یک فایل Word تنظیم میکنند: یک نسخهی «تیپ» که هر بار کپی میشود، اسم طرفین و مبلغ داخلش عوض میشود و به امضا میرسد. این روش تا چند ده قرارداد کار میکند، ولی سه مشکل جدی دارد که معمولاً دیر معلوم میشوند.
مشکل اول: بند مشترک، بیصدا واگرا میشود
فرض کنید ده نوع قرارداد دارید و هر دهتا یک بند «حل اختلاف» مشترک دارند. حالا مشاور حقوقی میگوید این بند باید اصلاح شود. باید هر ده فایل را باز کنید و دستی عوض کنید.
در عمل چه اتفاقی میافتد؟ هشتتا اصلاح میشوند، دوتا جا میمانند. شش ماه بعد کسی در یکی از فایلها یک کلمه را تغییر میدهد. یک سال بعد، ده نسخهی متفاوت از بندی دارید که قرار بود یکی باشد — و هیچکس نمیداند کدام درست است.
راهحل، چیزی است که در نرمافزارهای مدیریت چرخهی عمر قرارداد به آن کتابخانه بند (Clause Library) میگویند: هر ماده و بند یک جزء مستقل است، و قالبها به آن ارجاع میدهند بهجای اینکه کپیاش کنند. تغییر در یک نقطه انجام میشود.
مشکل دوم: سند باید ثابت بماند، حتی وقتی قالب عوض میشود
اینجا یک تلهی مهم وجود دارد. اگر قرارداد را «زنده» از روی قالب بسازید، یعنی هر بار که چاپش میکنید دوباره از قالب مونتاژ شود، آنوقت اصلاح بند در کتابخانه متن قراردادی را که پارسال امضا شده هم عوض میکند — بدون اینکه هیچ خطایی داده شود و کسی متوجه شود.
راهحل، سه لایه نسخهبندی است که باید هر سه با هم باشند:
- بند تغییرناپذیر است. ویرایش یک بند، آن را بازنویسی نمیکند؛ یک نسخهی جدید میسازد.
- قالب به نسخهی دقیق بند قفل است، نه به «آخرین نسخه». پس بروزرسانی قالب یک تصمیم آگاهانه و ثبتشده است، نه یک اتفاق خودکار.
- سند نهایی متن کامل خودش را نگه میدارد. بهمحض نهاییشدن، متن رندرشده روی خود سند ذخیره و قفل میشود و دیگر هرگز از قالب بازتولید نمیشود.
با این سه لایه، هیچ تغییری در کتابخانه نمیتواند به یک قرارداد امضاشده دست بزند. و تغییر شرایط بعد از امضا، یک الحاقیهی جدید میسازد، نه ویرایش سند قبلی.
مشکل سوم: شمارهی ماده، شناسهی ماده نیست
این ظریفترین مشکل است. وقتی در متن قرارداد مینویسید «مطابق ماده ۷»، در واقع به یک جایگاه ارجاع دادهاید، نه به یک محتوا. کافی است بعداً یک ماده در وسط قرارداد اضافه شود تا مادهٔ ۷ بشود مادهٔ ۸ — و همهی ارجاعهای داخل متن بیصدا غلط شوند.
استانداردهای جهانی تدوین متون حقوقی این را سالها پیش حل کردهاند. در Akoma Ntoso — استاندارد OASIS برای متون قانونی که پارلمان اروپا، سازمان ملل و چند پارلمان ملی از آن استفاده میکنند — هر عنصر یک شناسهی پایدار دارد که هرگز عوض نمیشود، و شمارهی نمایشی هنگام چاپ محاسبه میشود. ارجاعها به شناسه داده میشوند، نه به عدد.
همین استاندارد دو نکتهی دیگر را هم حل کرده که هر کسی که قرارداد فارسی تنظیم میکند با آنها روبهرو میشود:
- نوع هر عنصر صریح ذخیره میشود، نه اینکه از عمق آن در ساختار حدس زده شود. دلیلش در متون فارسی کاملاً روشن است: تبصره زیرمجموعهی ماده است، اما «بند» نیست و شمارندهی مستقل خودش را دارد. اگر نوع را از جایگاه حدس بزنید، تبصره مدل شما را میشکند.
- متن درآمد ماده (آن جملهای که بعد از عنوان ماده و قبل از شروع بندها میآید) یک عنصر شناختهشده است. یعنی مادهٔ تکبندی و مادهٔ دارای بند، دو حالت از یک قاعدهاند، نه دو استثنا.
در سامانه باجه
ماژول قراردادهای سامانه هوشمند باجه بر همین اصول طراحی شده است. امروز ثبت قرارداد و پیمان، صورتوضعیت و تعدیل، ضرایب حق بیمه پیمان موضوع ماده ۳۸ و پیگیری مفاصاحساب تأمین اجتماعی روی سامانه فعالاند. ماژول تولید متن قرارداد از کتابخانه بند — با شمارهگذاری ابجد مطابق عرف حقوقی ایران، شمارندهی مستقل برای تبصرهها، و اثر انگشت SHA-256 روی متن نهایی — در دست توسعه است.
اگر میخواهید ببینید اینها روی دادههای واقعی سازمان شما چطور کار میکنند، با ما تماس بگیرید.