بومی‌سازی اودو با ماژول آماده؛ ۵ معیار پیش از نصب

اودو (Odoo) برای بسیاری از کشورها بسته‌ی بومی‌سازی رسمی دارد که سرفصل حساب، مالیات و گزارش‌های قانونی همان کشور را می‌آورد. برای ایران چنین بسته‌ای وجود ندارد. به همین دلیل اولین کاری که بسیاری از تیم‌های فنی می‌کنند، جست‌وجو در فروشگاه اودو و مخزن‌های عمومی برای پیدا کردن ماژول آماده است. این کار برای بخشی از بومی‌سازی Odoo جواب می‌دهد، اما انتخاب اشتباه یک ماژول می‌تواند تا چند سال بعد، و در هر ارتقای نسخه، هزینه بسازد. در این مطلب پنج معیاری را مرور می‌کنیم که پیش از نصب هر ماژول بومی‌سازی باید سنجید. چه ماژول‌های آماده‌ای برای ایران وجود دارد؟ چند نمونه از ماژول‌هایی که در مخزن‌های عمومی دیده می‌شوند: Iran - Base از OCA (l10n_ir_base): برچسب تاریخ‌ها را شمسی می‌کند و فیلد شناسه‌ی ملی را اضافه می‌کند. نسخه‌ی منتشرشده‌ی آن 14 است و هنوز در مرحله‌ی بتاست. تاریخ‌نماهای جلالی در فروشگاه اودو: برای نسخه‌های مختلف، از جمله نسخه‌ی 19، منتشر شده‌اند و بیشترشان پولی‌اند. سال مالی شمسی (l10n_ir_fiscalyear): سال و دوره‌های مالی شمسی را خودکار می‌سازد و برای نسخه‌های 16 تا 18 منتشر شده است. تعطیلات رسمی ایران (ir_public_holidays): برای نسخه‌های 18 و 19. هر کدام از این ماژول‌ها یک تکه از کار را پوشش می‌دهند. هیچ‌کدام بسته‌ی کامل نیست و بخش‌هایی مثل حقوق و بیمه، گردش چک و سامانه‌ی مودیان همچنان کار جداگانه می‌خواهند. برای همین پیش از نصب هر ماژول، این پنج معیار را بسنجید. معیار 1: برای همان نسخه‌ی شما منتشر شده است؟ تقویم شمسی و بخش بزرگی از بومی‌سازی به رابط وب اودو وابسته است، و این رابط در نسخه‌های اصلی پشت‌سرهم بازنویسی شده است. ماژولی که برای نسخه‌ی 16 نوشته شده، روی 18 یا 19 خودبه‌خود کار نمی‌کند. فرق «منتشرشده برای نسخه‌ی 19» با «سازگار با 19» را جدی بگیرید و ماژول را روی همان نسخه‌ای آزمایش کنید که قرار است مستقر شود. معیار 2: مجوز و سورس‌کد مجوز ماژول آزاد (LGPL یا AGPL) است یا اختصاصی (OPL)؟ سورس‌کد کامل را تحویل می‌گیرید یا فقط اجازه‌ی استفاده؟ ماژولی که سورسش در اختیار شما نیست، شما را به فروشنده‌اش وابسته می‌کند؛ اگر فروشنده آن را برای نسخه‌ی بعدی منتشر نکند، ارتقای کل سیستم متوقف می‌شود. معیار 3: هسته‌ی اودو را تغییر می‌دهد؟ ماژول خوب هسته‌ی اودو را گسترش می‌دهد، نه این‌که مستقیم تغییرش دهد. پیچیده‌ترین مشکل پروژه‌های اودو در ایران همین است: سیستمی که با تغییر مستقیم هسته بومی شده، دیگر به‌راحتی ارتقا پیدا نمی‌کند. اگر فایل‌های هسته‌ی اودو پس از نصب ماژول تغییر کرده‌اند، آن را کنار بگذارید. معیار 4: پوشش واقعی، نه فقط تاریخ‌نما بیشتر ماژول‌های تقویم فقط تاریخ‌نما را شمسی می‌کنند. یک آزمون ساده کافی است تا پوشش واقعی معلوم شود: فهرست فاکتورها را بر اساس ماه گروه کنید؛ باید فروردین و اردیبهشت ببینید، نه ژانویه و فوریه. فیلتر «این ماه» را بزنید و ببینید با ماه شمسی حساب می‌شود یا میلادی. یک فاکتور و یک حواله را چاپ کنید؛ تاریخ PDF هم باید شمسی باشد. سال مالی را ببینید؛ پایان اسفند در سال‌های کبیسه جابه‌جا می‌شود و دوره‌ها باید با تاریخ دقیق ساخته شوند. معیار 5: چه کسی نگهداری‌اش می‌کند؟ اودو هر سال یک نسخه‌ی اصلی منتشر می‌کند و فقط چند نسخه‌ی آخر را پشتیبانی می‌کند. بپرسید آخرین به‌روزرسانی ماژول کی بوده است و چه کسی آن را برای نسخه‌ی بعدی منتقل می‌کند. ماژولی که دو سال به‌روز نشده، احتمالاً در ارتقای بعدی شما را تنها می‌گذارد. وقتی ماژول آماده کافی نیست برای بخش‌هایی از بومی‌سازی ماژول آماده‌ی قابل اتکا پیدا نمی‌شود. حقوق و دستمزد یک نمونه است: ماژول حقوق اودو اینترپرایز برای هر کشور بسته‌ی جداگانه دارد و ایران در میان آن‌ها نیست، و در نسخه‌ی کامیونیتی هم باید از ماژول‌های جامعه یا ماژول اختصاصی استفاده کرد. سامانه‌ی مودیان هم ماژول رسمی در اودو ندارد. در این بخش‌ها ماژول اختصاصی ساخته می‌شود، و همان چند قاعده باید رعایت شود: بومی‌سازی در ماژول‌های جدا بماند و هسته‌ی اودو دست نخورد. نرخ‌ها و جدول‌های قانونی، مثل مالیات، بیمه و تعطیلات، داده باشند نه کد، تا هر سال بدون برنامه‌نویسی به‌روز شوند. برای محاسبه‌های حساس، یعنی مالیات، حقوق و تاریخ شمسی، آزمون خودکار نوشته شود تا بعد از ارتقا معلوم شود چیزی نشکسته است. سورس‌کد همه‌ی ماژول‌ها متعلق به خود سازمان باشد تا ارتقا به یک مجری خاص گره نخورد. مراحل انتقال این ماژول‌ها به نسخه‌ی جدید و تفاوت کامیونیتی و اینترپرایز در آن، در راهنمای ارتقای نسخه‌ی اودو آمده است. جمع‌بندی ماژول آماده می‌تواند زمان پروژه را کوتاه کند، به شرطی که برای همان نسخه منتشر شده باشد، سورسش در اختیار شما باشد، هسته را تغییر ندهد، پوشش واقعی داشته باشد و کسی نگهداری‌اش کند. اگر یکی از این پنج شرط برقرار نیست، ساخت ماژول اختصاصی با سورس باز و آزمون خودکار در بلندمدت ارزان‌تر تمام می‌شود. تیم وستا (وستا AI، vestaai.ir) نسخه‌ی بومی‌سازی‌شده‌ی اودو را روی نسخه‌های 18، 19 و 20 با همین اصول مستقر می‌کند و سورس‌کد و ماژول‌ها را بدون قفل و بدون لایسنس پنهان تحویل سازمان می‌دهد؛ و وقتی داده‌ی فروش، انبار و مالی در اودو یک‌جا جمع شد، هوش مصنوعی وستا روی همان داده سوار می‌شود.