ClefinCode - تنفيذ تقسيم البيانات، والأرشفة طويلة الأجل، والوصول إلى البيانات القديمة في ERPNext

1. نظرة عامة على بنية ERPNext و Frappe

طبقة قاعدة البيانات و ORM: تم بناء ERPNext على إطار عمل Frappe ويستخدم بشكل أساسي قاعدة بيانات علائقية (MariaDB/MySQL by default) لتخزين جميع البيانات. كل DocType في Frappe يقابل جدولًا في قاعدة البيانات (مسبوقًا بالبادئة tab) ويتم إنشاؤه عند تعريف الـ DocType[1]. يوفر Frappe طبقة ORM تسمح للمطورين بالتعامل مع هذه الجداول ككائنات Python (Documents) بدلًا من كتابة استعلامات SQL مباشرة[1][1]. يحتوي كل سجل على مفتاح أساسي يسمى name (غالبًا ما يكون سلسلة نصية أو تسلسلًا تلقائي الزيادة) يعرّفه بشكل فريد داخل الجدول[1]. تضمن Frappe ORM أن عمليات إنشاء وقراءة وتحديث وحذف المستندات في الكود ستنفّذ أوامر SQL اللازمة في الخلفية[1]. هذا التجريد يجعل التطبيق إلى حد كبير غير مرتبط بنوع قاعدة البيانات على مستوى الكود، على الرغم من أن MariaDB كانت عمليًا هي الخلفية القياسية (لا يزال دعم PostgreSQL في ERPNext محدودًا حتى الإصدار v15/v16).

عمليات الترحيل وتطور المخطط: يخضع ERPNext لتغييرات متكررة في مخطط قاعدة البيانات مع تحديثات الإصدارات (مثل إضافة حقول جديدة، تغيير أنواع الحقول، إنشاء جداول جديدة لـ DocTypes جديدة، إلخ). يستخدم Frappe نظام ترحيل لمعالجة هذه التغييرات. عند تحديث ERPNext إلى إصدار جديد، يتم تشغيل الأمر bench migrate الذي يطبّق جميع تغييرات المخطط المعلّقة ونصوص تصحيح البيانات لمواءمة قاعدة البيانات مع الكود الجديد[2]. تقوم هذه العملية بإضافة أو تعديل الأعمدة أو الجداول كما هو محدد في بيانات تعريف DocType بصيغة JSON، وتشغيل أي نصوص تصحيح لترحيل البيانات الحالية عند الحاجة[2][2]. ومن الجدير بالذكر أن Frappe لا يدعم عمليات الترحيل العكسية – فبمجرد الترقية وتغيير المخطط، لا توجد طريقة مدمجة للتراجع عن مخطط قاعدة البيانات إلى إصدار أقدم[2]. هذا يعني أن التوافق مع الإصدارات السابقة محدود: بعد الترقية، تصبح قاعدة البيانات مهيأة للإصدار الجديد، وقد لا يعمل كود ERPNext القديم معها. عمليًا، تتضمن الترقيات الرئيسية للإصدارات (v14 ? v15 ? v16) عمليات ترحيل باتجاه واحد، ويتطلب الرجوع إلى إصدار أقدم استعادة نسخة احتياطية بدلًا من التراجع المباشر. يتبع المشروع مبدأ الإصدار الدلالي حيث تتضمن الإصدارات الرئيسية تغييرات جذرية، وتضيف الإصدارات الفرعية ميزات جديدة (غالبًا متوافقة مع الإصدارات السابقة)، بينما تقوم التصحيحات بإصلاح الأخطاء[3]. لكل إصدار رئيسي من ERPNext دورة دعم محدودة (عادةً حوالي 2–3 سنوات)، مع دعم رسمي لآخر إصدارين رئيسيين فقط في أي وقت[4]. على سبيل المثال، من المخطط أن يصل ERPNext v14 إلى نهاية الدعم (EOL) بنهاية عام 2025، وv15 بنهاية عام 2027[4]. يشير ذلك إلى أن المؤسسات قد تحتاج إلى الترقية مرة واحدة على الأقل كل بضع سنوات، ويجب عليها تصميم حلول أرشفة لا تعتمد على الاستمرار إلى أجل غير مسمى على إصدار قديم من ERPNext (لأسباب أمنية ودعمية).

التعددية المستأجرة مقابل تعدد قواعد البيانات: من حيث التصميم، فإن Frappe هو نظام متعدد المستأجرين – حيث يمكنك استضافة عدة sites على خادم واحد، ويكون لكل موقع قاعدة بيانات ودليل بيانات خاص به[5]. تشترك جميع المواقع في نفس قاعدة الكود (apps)، لكن يتم عزل بيانات كل موقع على مستوى قاعدة البيانات[5]. هذا النهج مناسب جدًا لخدمة عدة شركات أو شركات تابعة على بنية تحتية واحدة، لكنه يعني أن قاعدة بيانات كل موقع مستقلة بذاتها. لا يوجد دعم أصلي في Frappe لموقع واحد يقوم بالاستعلام عبر عدة قواعد بيانات. داخل الموقع الواحد، يفترض التطبيق وجود اتصال أساسي واحد بقاعدة البيانات يحتوي على جميع جداول DocType الخاصة بذلك الموقع. لا يمكنك تهيئة موقع ERPNext لسحب بعض DocTypes تلقائيًا من قاعدة بيانات معينة وأخرى من قاعدة بيانات مختلفة – إذ يجب بناء هذا النوع من الوصول عبر قواعد بيانات متعددة بشكل مخصص (وهو أمر غير مُوصى به عمومًا). باختصار، تتوقع بنية ERPNext أن تكون جميع البيانات التشغيلية لموقع واحد موجودة في قاعدة بيانات واحدة، وأي أرشفة إلى قاعدة بيانات منفصلة تعني فعليًا التعامل مع هذا الأرشيف كموقع آخر أو كمصدر بيانات خارجي.

القيود الأصلية (التقسيم، الأرشفة، التوافق): بشكل افتراضي، لا يتضمن ERPNext (حتى الإصدار v15/v16) ميزات مدمجة لتقسيم الجداول أو الأرشفة التلقائية للبيانات إلى تخزين آخر. تم بناء Frappe ORM ونظام الترحيل حول الجداول القياسية. إذا قمت بتنفيذ ميزات SQL مخصصة مثل التقسيم على مستوى قاعدة البيانات، فلن يكون الإطار على دراية بها – وهو أمر ممكن، لكن يجب إدارته يدويًا (سيتم التطرق إلى ذلك بمزيد من التفصيل في القسم 2). أرشفة السجلات القديمة ليست ميزة بنقرة واحدة في ERPNext؛ فعادةً ما يعتمد المستخدمون على النسخ الاحتياطية أو حذف البيانات يدويًا عند الحاجة، ولا توجد وحدة أرشفة رسمية تقوم بنقل البيانات إلى تخزين بارد. في مناقشات المجتمع، أكد المستخدمون أنهم اضطروا إلى ابتكار حلول أرشفة مخصصة لعدم وجود طريقة قياسية متوفرة[6][6]. من القيود الأخرى مسألة التوافق مع الإصدارات السابقة فيما يتعلق بتشغيل الكود القديم: بمجرد الترحيل إلى إصدار جديد من ERPNext، لا يمكنك تشغيل كود الإصدار القديم على قاعدة البيانات التي تم ترقيتها[2]. وبالتالي، تواجه المؤسسات التي تمتلك بيانات طويلة الأجل معضلة – إما الإبقاء على إصدار قديم قيد التشغيل لأجل البيانات التاريخية، أو ترحيل تلك البيانات إلى الإصدارات الأحدث (ولكل خيار مزاياه وعيوبه، كما سيُناقش في القسم 7). أخيرًا، لا يدعم ERPNext بشكل أصلي الاستعلامات “الموحدة” أو الاتصال المباشر بقواعد بيانات متعددة في الوقت نفسه (باستثناء إعدادات النسخ المتماثل لتوسيع القراءة). كل هذه العوامل تعني أن تنفيذ التقسيم أو الأرشفة أو الوصول إلى البيانات القديمة يتطلب تخطيطًا دقيقًا وربما أدوات مخصصة تُبنى فوق نواة ERPNext.

2. استراتيجية تقسيم البيانات في ERPNext

مفاهيم التقسيم: يتضمن Database partitioning تقسيم جدول كبير إلى أجزاء أصغر وأكثر قابلية للإدارة مع الحفاظ على البنية المنطقية للجدول. هناك شكلان رئيسيان:

1. التقسيم الأفقي: تقسيم الصفوف بين عدة أقسام (يحتوي كل قسم على مجموعة فرعية من الصفوف، وعادةً ما يكون ذلك بناءً على مفتاح مثل التاريخ أو نطاق المعرّفات). يمكن اعتبار كل قسم جدولًا منفصلًا خلف الكواليس، لكن بالنسبة للتطبيق فهو جدول واحد. على سبيل المثال، يمكن الاحتفاظ ببيانات السنوات الأقدم في أقسام منفصلة من جدول الأستاذ – أي “تجزئة” الجدول حسب نطاق التاريخ[6][6]. في MySQL/MariaDB، يُعد table partitioning الأصلي شكلًا من أشكال التقسيم الأفقي حيث يتولى نظام إدارة قواعد البيانات إدارة عدة أقسام فعلية لجدول واحد[6]. مثال آخر خارج محرك قاعدة البيانات هو وجود جداول منفصلة لكل سنة واستخدام view أو union للاستعلام عنها معًا (تقسيم أفقي يدوي). التقسيم الأفقي يشبه حرفيًا “أرشفة البيانات القديمة إلى مجموعة بيانات منفصلة، لكنها مرتبطة بقاعدة البيانات الرئيسية بحيث تبقى متاحة”[6].
2. التقسيم العمودي: تقسيم الأعمدة بين عدة جداول (يحتوي كل قسم على مجموعة فرعية من الأعمدة). على سبيل المثال، يمكن تقسيم جدول واسع إلى جدولين بعلاقة واحد إلى واحد، بحيث يتم تخزين الأعمدة قليلة الاستخدام أو الحساسة في جدول منفصل. هذا أقل شيوعًا في سياق ERPNext لأنه يعقّد استخدام ORM. يُعد التقسيم العمودي في جوهره امتدادًا لعملية التطبيع – أي تقسيم الجداول حتى بعد تطبيعها حسب الأعمدة[7]. من حالات الاستخدام الشائعة فصل الحقول النصية الكبيرة أو حقول blob أو سجلات الأرشفة إلى جدول آخر للحفاظ على ضيق الجدول الرئيسي وتحسين الأداء[7]. في ERPNext، قد يظهر التقسيم العمودي في أنماط مثل تخزين مرفقات المستندات في تخزين ملفات منفصل أو نقل بعض السجلات خارج الجداول الأساسية. ومع ذلك، ينصب تركيزنا هنا بشكل أساسي على التقسيم الأفقي (حسب الصفوف) لأن الهدف هو إدارة أحجام كبيرة من المعاملات على مر الزمن.

التقسيم حسب النطاق (مثلًا سنويًا): من بين مخططات التقسيم، يُعد RANGE partitioning على حقل تاريخ مناسبًا جدًا لبيانات ERP. هذا يعني أن كل قسم (partition) يحتوي على الصفوف ضمن نطاق زمني محدد (على سبيل المثال، سنة مالية أو شهر). إذا قمنا بالتقسيم حسب السنة، فقد تكون لدينا أقسام بأسماء مثل p2019, p2020, p2021, ... حيث يحتوي p2019 على جميع الصفوف التي يكون فيها مثلًا posting_date < "2020-01-01"، ويحتوي p2020 على تواريخ عام 2020، وهكذا. تتم إضافة أقسام جديدة مع مرور السنوات، ويمكن حذف الأقسام القديمة لأغراض الأرشفة. يتوافق Range partitioning on dates مع الفترات المالية وسياسات الاحتفاظ. تكون الأقسام الشهرية أدق: مثلًا 12 قسمًا لكل سنة (Jan, Feb, ...)، وقد يكون ذلك مفيدًا إذا كانت بيانات سنة واحدة ضخمة جدًا. تتيح الأقسام الشهرية حذف شهر واحد في كل مرة عند الحاجة، وربما تحقق تقليمًا (pruning) أفضل قليلًا للاستعلامات التي تستهدف أشهرًا محددة. المقايضة هنا هي وجود عدد أكبر من الأقسام التي يجب إدارتها (ولا بد من الإشارة إلى أن كثرة الأقسام – بالآلاف – قد تُدخل حملًا إضافيًا). الأقسام السنوية أسهل في الصيانة وغالبًا ما تكون كافية لمعظم حالات استخدام ERP، حيث تقسّم البيانات حسب السنة المالية.

ما هي جداول ERPNext التي يجب تقسيمها: ليست كل الجداول تستفيد من التقسيم. ينبغي أن نستهدف أكبر الجداول المعاملاتية والأسرع نموًا، خصوصًا تلك التي يتم الوصول إليها غالبًا عبر فلاتر تاريخ. من المرشحين الرئيسيين في تركيب ERPNext كبير الحجم:

1. إدخال دفتر الأستاذ العام (GL) Entry – هذا الجدول (tabGL Entry) يسجل كل قيد محاسبي في الدفتر (قيود اليومية، تأثيرات الفواتير، المدفوعات، إلخ). في الأنظمة عالية الحجم (البنوك، الشركات الكبيرة)، يمكن أن يتراكم جدول GL Entry إلى ملايين الصفوف عبر السنوات. وغالبًا ما يتم الاستعلام عنه وفق نطاقات تاريخ (للتقارير المالية واستعلامات التدقيق). إن تقسيمه حسب تاريخ القيد (سنة أو شهر) سيحصر معظم الاستعلامات في الأقسام الحديثة ويتيح حذف القيود القديمة جدًا بسرعة عند الحاجة.
2. إدخال دفتر أستاذ المخزون (Stock Ledger Entry) – مشابه لـ GL، لكن لحركات المخزون. تولد إعدادات التجزئة الكبيرة أو التصنيع سجلات ضخمة من معاملات المخزون. يمكن أن يؤدي التقسيم حسب التاريخ إلى تحسين أداء تقارير تقييم المخزون ورصيد المخزون عبر تقليم البيانات القديمة.
3. Sales Invoice / Purchase Invoice / Payment Entry – تحتوي جداول هذه المستندات على السجلات المعاملاتية. قد تكون أقل ثِقلاً قليلًا من جداول الدفاتر لأن هناك عادةً إدخال GL واحد لكل عنصر فاتورة، ما يعني أن إدخالات GL قد تفوق عدد الفواتير. ومع ذلك، إذا كانت الشركة تُصدر عشرات الآلاف من الفواتير يوميًا (مثل إيصالات POS)، فقد تصبح هذه الجداول كبيرة أيضًا. يمكن أن يساعد تقسيمها حسب posting date (أو تاريخ الفاتورة)، مع ضرورة مراعاة أن جداول DocType هذه غالبًا ما ترتبط بجداول فرعية (مثل صفوف invoice Item) – ولأجل البساطة، يمكن تقسيم جدول doctype الرئيسي وربما جدول الطفل الخاص به بطريقة مماثلة.
4. جداول Communications/Email و Activity Log – لم تُذكر في السؤال، لكن أنظمة ERPNext تتراكم فيها أيضًا السجلات (مثلًا tabCommunication للبريد/الملاحظات، و tabVersion لتاريخ إصدارات المستندات). يمكن أن تنمو هذه الجداول بشكل كبير ولا تكون مطلوبة دائمًا للوصول السريع. قد يكون تقسيمها أو تنقيتها (purging) مفيدًا. على سبيل المثال، يمكن لـ tabVersion (سجل تغييرات المستند) أن يصبح كبيرًا؛ وأظهرت حالة في المنتدى بطء الاستعلامات على tabVersion حتى تمت إضافة فهارس[6][6]. يمكن أن يكون التقسيم طريقة أخرى لإدارة مثل هذه السجلات حسب التاريخ.

لماذا لا نقسم جداول الماستر/الإعداد: جداول البيانات الرئيسية (مثل tabItem و tabCustomer و tabAccount وغيرها) تكون عادةً أصغر بكثير ولا تنمو بنفس معدل السجلات المعاملاتية. كما أنها غالبًا ما تحتاج إلى الانضمام إليها أو الإشارة إليها دون سياق تاريخ. إن تقسيمها سيضيف تعقيدًا غير ضروري دون فائدة حقيقية – فمثلًا تقسيم tabCustomer إلى أقسام حسب الحرف الأول أو نطاق المعرّف لن يسرّع الاستعلامات بشكل ملحوظ، لأن هذه الجداول غالبًا ما تحتوي على عشرات الآلاف من الصفوف فقط، وهو حجم يمكن للفهرس التعامل معه بسهولة. إضافةً إلى ذلك، تنطبق بعض القيود التقنية: يتطلب تقسيم MySQL/MariaDB أن يتضمن كل مفتاح فريد مفتاح التقسيم[8]. غالبًا ما تمتلك جداول الماستر مفتاحًا أساسيًا هو name (وهو ليس تاريخًا)، وإضافة مفتاح تقسيم شكلي قد يخالف تلك القاعدة. يمكنك التقسيم حسب شيء مثل سنة إنشاء العميل، لكنه ليس نمط وصول شائع (نادرًا ما نستعلم عن العملاء حسب سنة الإنشاء). أما جداول الإعداد (مثل tabCompany و tabUser و tabRole) فهي أصغر حتى من ذلك ولا ينبغي تقسيمها إطلاقًا. باختصار، ركّز التقسيم على الجداول المعاملاتية الثقيلة حيث تكون البيانات بطبيعتها مُقسّمة وفق الزمن أو معيار مشابه.

آلية تقليم الأقسام (Partition Pruning Mechanics): يتمثل مكسب الأداء الأساسي من التقسيم في partition pruning. يحدث ذلك عندما يتمكن محرك قاعدة البيانات من تجاوز أقسام كاملة من البيانات غير ذات الصلة بالاستعلام، بدلًا من فحص الجدول بالكامل. لكي يعمل التقليم، يجب أن يتضمن شرط WHERE في الاستعلام مفتاح التقسيم (مثل التاريخ أو السنة). على سبيل المثال، إذا كان جدول tabGL Entry مُقسّمًا حسب السنة اعتمادًا على posting_date، فإن استعلامًا عن السنة المالية 2025 (WHERE posting_date BETWEEN "2025-04-01" AND "2026-03-31"، بافتراض سنة مالية من أبريل إلى مارس) سيجعل المُحسِّن يقرأ فقط قسم 2025 (و2026 إذا كان النطاق متداخلًا) ويتجاهل جميع الأقسام الأخرى[9][9]. توضح وثائق MariaDB أنه إذا كان شرط WHERE مرتبطًا بتعبير التقسيم، فإن المُحسِّن “يعرف أي الأقسام ذات صلة بالاستعلام” وأن “الأقسام الأخرى لن تتم قراءتها”[9]. يتم ذلك تلقائيًا. يمكنك فعليًا معرفة أي الأقسام يلمسها الاستعلام عبر تشغيل EXPLAIN PARTITIONS <query> – حيث سيعرض مخطط التنفيذ الأقسام المستهدفة[9][9]. يؤكد ذلك أن تقريرًا عن بيانات عام 2023، مثلًا، يقوم فقط بفحص قسم 2023 (وربما جزءًا من 2024 اعتمادًا على حدود التاريخ)، مما يقلل بشكل كبير من عمليات الإدخال/الإخراج مقارنةً بفحص فهرس يمتد على 10 سنوات من البيانات.

التفاعل بين الفهارس والتقسيم (Indexes and Partitioning Interaction): تظل الفهارس تعمل داخل كل قسم. في الواقع، يتم تقسيم البيانات والفهارس معًا – إذ يمتلك كل قسم حصته الخاصة من الفهرس[10]. هذا يعني أن الفهرس على posting_date أو على حقول أخرى يوجد بشكل منفصل داخل كل قسم. إحدى القواعد المهمة في MySQL/MariaDB هي أن مفتاح التقسيم يجب أن يكون جزءًا من كل مفتاح PRIMARY أو UNIQUE في الجدول[8]. يؤدي ذلك غالبًا إلى فرض بعض التعديلات: فعلى سبيل المثال، يكون المفتاح الأساسي لجدول tabGL Entry على الأرجح هو name (وهو تجزئة أو تسلسل). إذا قمنا بالتقسيم حسب التاريخ، فمن الناحية الصارمة يجب تضمين posting_date في المفتاح الأساسي أو إنشاء فهرس فريد منفصل يتضمنه (لتلبية متطلبات المحرك). أحد الحلول الالتفافية هو إزالة أي قيود فريدة غير ضرورية أو الاعتماد على حقيقة أن name فريد على مستوى الجدول بالكامل، ثم إضافة مفتاح تقسيم غير فريد. عمليًا، قام كثيرون بتقسيم جداول Frappe عبر جعل المفتاح الأساسي (name) غير فريد أو عبر إضافة مفتاح مركب. يتطلب ذلك حذرًا، لكنه قابل للتنفيذ (وقد انتقل بعضهم إلى استخدام مفاتيح رقمية ذات زيادة تلقائية لتسهيل التقسيم).

يرجى الملاحظة أيضًا أن المفاتيح الخارجية غير مدعومة على الجداول المُقسّمة في MySQL/MariaDB[8] – لكن ERPNext لا يستخدم قيود المفاتيح الخارجية على مستوى SQL لعلاقات DocType (يعتمد على منطق التطبيق وحقول الربط)، لذلك لا يُعد هذا عادةً عائقًا. فقط كن على علم: إذا كان هناك جدول يحتوي على مفتاح خارجي يشير إلى جدول آخر، فستحتاج إلى إزالة هذا القيد لتتمكن من تقسيم الجدول[8].

أمثلة SQL وأفضل الممارسات: للتوضيح، افترض أننا نريد تقسيم جدول GL Entry حسب السنة المالية. إذا افترضنا أن السنة المالية = السنة الميلادية للتبسيط، فقد يكون بيان DDL في SQL كما يلي:

  

ALTER TABLE `tabGL Entry`
PARTITION BY RANGE (YEAR(posting_date))
(
    PARTITION p2019 VALUES LESS THAN (2020),
    PARTITION p2020 VALUES LESS THAN (2021),
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION pMax VALUES LESS THAN MAXVALUE
);

يؤدي هذا إلى إنشاء أقسام للأعوام 2019–2024، ويقوم pMax بالتقاط أي بيانات من عام 2025 أو بعده (مما يضمن أن الجدول يمكنه استقبال بيانات جديدة؛ وستقوم لاحقًا بتقسيم pMax عند الحاجة). يمكنك تنفيذ SQL من عميل MySQL أو عبر سكربت يعمل على الخادم (since Frappe migration won’t do it for you). أفضل الممارسات:

1. قم دائمًا بإنشاء نسخة احتياطية قبل تعديل التقسيم على جدول كبير.
2. تأكد من وجود فهرس على مفتاح التقسيم (posting_date هنا) لتحسين أداء الاستعلامات (even though partitioning can prune, an index helps within each partition).
3. راقب أحجام الأقسام؛ يمكنك استخدام SHOW TABLE STATUS أو الاستعلام عن information_schema.PARTITIONS للاطلاع على عدد الصفوف في كل قسم.
4. خطّط لإجراء إضافة قسم جديد كل عام. مع RANGE partitioning، يمكنك استخدام ALTER TABLE ... REORGANIZE PARTITION لتقسيم قسم MAXVALUE إلى قسم جديد أعلى عند بدء سنة جديدة[10]. على سبيل المثال، في نهاية عام 2024، قم بتقسيم pMax إلى p2025 وقسم pMax جديد.
5. إذا احتجت يومًا إلى إزالة البيانات القديمة، يمكنك حذف قسم كامل بأمر واحد (ALTER TABLE ... DROP PARTITION p2019) – وهذا أسرع بكثير من حذف الصفوف، حيث يقوم MariaDB فقط بحذف ملف القسم، وهو ما يتم تقريبًا بشكل فوري لمجموعات البيانات الكبيرة[10]. يُعد استخدام الأقسام لأغراض التنقية السهلة فائدة معروفة: فحذف قسم يحتوي على عدد كبير من الصفوف يكون سريعًا جدًا، بينما قد يكون تنفيذ DELETE لتلك الصفوف بطيئًا للغاية[10].

المخاطر المرتبطة بعمليات الترحيل/الترقية: إن إدخال التقسيم إلى قاعدة بيانات ERPNext يُعد تخصيصًا على مستوى قاعدة البيانات، ولذلك يجب توخي الحذر أثناء الترقيات المستقبلية:

1. إذا أدخل التحديث تغييرًا على جدول مُقسّم (مثل إضافة عمود أو فهرس عبر bench migrate)، ففي معظم الحالات سيتعامل MariaDB مع الأمر بشكل سليم – حيث سيتم تطبيق أوامر DDL ببساطة على جميع الأقسام. إن إضافة الأعمدة أو تغيير أنواع البيانات وما شابه ذلك تنتشر إلى الأقسام بشكل شفاف.
2. ومع ذلك، إذا حاول أحد التحديثات حذف الجدول وإعادة إنشائه (وهو أمر غير شائع في DocTypes الأساسية، لكنه قد يحدث إذا تم إعادة تسمية DocType أو إعادة هيكلته)، فستفقد التقسيم ما لم تقم بإعادة تطبيقه. لذلك يجب دائمًا مراجعة ملاحظات إصدارات ERPNext أو تغييرات المخطط لأي تعديلات جوهرية على الجداول الكبيرة.
3. كما ذُكر، إذا قرر ERPNext في أي وقت إضافة مفتاح خارجي على جدول مُقسّم (وهو أمر غير مرجح، لكنه افتراضيًا ممكن)، فسيفشل ذلك بسبب قيود التقسيم[8]. عندها ستحتاج إما إلى إزالة التقسيم أو تجاوز ذلك القيد (وغالبًا لن تواجه هذا السيناريو لأن Frappe يتجنب استخدام المفاتيح الخارجية الصلبة على البيانات المعاملاتية).
4. الاختبار: من الحكمة اختبار الإعداد المُقسّم في بيئة staging عند تنفيذ أي ترقية. تأكد من أن bench migrate يعمل دون أخطاء. إذا ظهر خطأ (على سبيل المثال، بسبب سلوك خاص في MySQL مع الأقسام)، فقد تضطر مؤقتًا إلى إزالة التقسيم، تنفيذ الترحيل، ثم إعادة تطبيق التقسيم – لكن هذا نادرًا ما يكون مطلوبًا.
5. عبء الصيانة: التقسيم ليس إعدادًا “مرة واحدة وينتهي”. تحتاج إلى مهمة صيانة لإضافة أقسام جديدة بشكل دوري (يمكن تنفيذها عبر مهمة cron سنوية أو يدويًا عند انتقال السنة المالية). كما يجب مراقبة ما إذا كانت الاستعلامات تستخدم partition pruning فعليًا؛ فإذا وجدت استعلامات لا تفعل ذلك (مثل تقرير يستعلم عن جميع التواريخ دون فلترة)، فقد تحتاج إلى إضافة فلاتر تاريخ صريحة أو استخدام تلميح PARTITION في SQL لاستهداف أقسام معينة[9][9].

خلاصة القول، يمكن أن يحقق التقسيم في ERPNext تحسينات كبيرة في الأداء وقابلية الإدارة للجداول الكبيرة، لكنه يتطلب تنفيذًا يدويًا وإدارة مستمرة. من الضروري التأكد من توافق أنماط الاستخدام لديك (فمعظم تقارير ERPNext تسمح بالفلترة حسب التاريخ، وهو أمر مثالي للتقليم). يُعد التقسيم أداة قوية لإدارة البيانات متعددة السنوات، وإذا تم تنفيذه بشكل صحيح، يمكنه تحسين سرعات الاستعلام بشكل ملحوظ مع تبسيط الأرشفة (عبر حذف الأقسام) عند الحاجة[10][10].

3. تحليل الأداء وسلوك الاستعلامات

الخط الأساس (جدول مفهرس بدون تقسيم): في إعداد ERPNext القياسي، تحتوي الجداول الكبيرة مثل GL Entry على فهارس على الحقول الأساسية (مثل posting_date وربما voucher_no، إلخ). افترض أنك تستعلم عن تقرير لفترة محددة – ستستخدم قاعدة البيانات فهرس posting_date لتحديد بداية نطاق التاريخ ثم تقوم بالمسح عبر إدخالات الفهرس حتى نهاية النطاق. يُعد هذا فعالًا إلى حد معقول، ولكن إذا كان النطاق يغطي جزءًا كبيرًا من الجدول (مثل الاستعلام عن سنة كاملة في جدول يحتوي على 10 سنوات من البيانات)، فسيظل مسح الفهرس يمر عبر عدد كبير من الإدخالات وسيقوم المحرك بجلب العديد من صفحات البيانات. عادةً ما تُظهر خطة الاستعلام لاستعلام مُفلتر بالتاريخ على جدول غير مُقسّم عملية مسح نطاقي للفهرس. على سبيل المثال، سيُظهر الأمر EXPLAIN SELECT ... FROM tabGL Entry WHERE posting_date BETWEEN "2023-01-01" AND "2023-12-31" استخدام فهرس posting_date مع شرط نطاق. يتوافق عدد الصفوف التي يتم فحصها مع جميع قيود GL لعام 2023 (وقد تكون بالملايين). يتضمن إدخال/إخراج القرص في هذا السيناريو قراءة جميع عُقد أوراق الفهرس لذلك النطاق الزمني وجلب صفوف الجدول المقابلة. إذا كانت البيانات كبيرة وغير موجودة بالكامل في الذاكرة، فهذا يعني الكثير من عمليات القراءة من القرص. ويُستهلك المعالج في تقييم الصفوف (مثل تجميع القيم) وإدارة عمليات الإدخال/الإخراج. في غياب التقسيم، يجب على قاعدة البيانات على الأقل النظر في الفهرس الكامل للجدول، حتى لو كنت تريد مجموعة فرعية فقط من البيانات – يمكنها القفز إلى بداية النطاق عبر الفهرس، لكنها تظل مضطرة لمعالجة ذلك النطاق بشكل تسلسلي.

جدول مُقسّم مع أقسام معتمدة على التاريخ: الآن، لننظر إلى نفس الاستعلام على جدول GL Entry مُقسّم (مقسّم حسب السنة). سيؤدي الاستعلام WHERE posting_date BETWEEN "2023-01-01" AND "2023-12-31" إلى تقليم النتائج بحيث يقتصر التنفيذ على قسم عام 2023 فقط (وربما جزء صغير من أقسام 2022 أو 2024 إذا تداخلت حدود النطاق قليلًا). ستُظهر خطة التنفيذ في هذه الحالة بشكل صريح أي قسم/أقسام يتم فحصها[9][9]. يقوم المُحسِّن فعليًا بإضافة فلتر مخفي AND partition = p2023 استنادًا إلى شرط التاريخ. ونتيجة لذلك، سيكون عدد الصفوف التي يتم فحصها هو فقط صفوف عام 2023. فإذا كان كل عام يحتوي على نحو مليون قيد وكان الجدول الكامل يحتوي على 10 ملايين قيد، فقد قمت بتقليل حجم المسح بنسبة 90%. يترجم هذا الانخفاض في البيانات التي يتم فحصها إلى انخفاض في عمليات الإدخال/الإخراج على القرص (حيث يتم لمس فهرس وبيانات قسم 2023 فقط) وانخفاض في استهلاك المعالج (عدد أقل من الصفوف التي يجب تقييمها). وعمليًا، فإن التقسيم مع استخدام شرط WHERE مناسب يمكن أن يقلل بشكل كبير جدًا من كل من I/O واستهلاك CPU في الجداول الكبيرة[11][11].

علاوة على ذلك، وبما أن فهرس كل قسم منفصل، فإن الفهرس على posting_date داخل قسم 2023 يكون أصغر بكثير من فهرس يمتد على 10 سنوات. تصبح عمليات الفهرسة (مثل عمليات المسح النطاقي) أكثر كفاءة داخل مجموعة البيانات الفرعية لذلك القسم[11][11]. كما أن التقسيم يُضيّق ضمنيًا نطاق الفهرسة، مما قد يحسن استخدام الذاكرة المؤقتة (حيث يمكن أن تبقى صفحات الفهرس الخاصة بقسم معين في الذاكرة عند العمل ضمن ذلك القسم)[11]. وباختصار، تقوم قاعدة البيانات بعمل أقل.

اختلافات خطة التنفيذ: دعونا نُصوّر ذلك مفاهيميًا:

1. بدون التقسيم: قد يُظهر EXPLAIN SELECT ... FROM tabGL Entry WHERE posting_date >= "2023-01-01" AND posting_date < "2024-01-01" على سبيل المثال key = idx_posting_date, rows = 1,000,000 (estimated).
2. مع التقسيم: سيُظهر EXPLAIN PARTITIONS SELECT ... قيمة partitions = p2023, key = idx_posting_date_in_partition, rows = 1,000,000 (estimated). الفرق الرئيسي هو غياب الأقسام الأخرى من خطة التنفيذ، ما يعني أنه لن يتم حتى فتحها أو فحصها[9]. إذا قمت عن طريق الخطأ بتنفيذ استعلام بدون عامل تصفية بالتاريخ (e.g., تقرير يعرض جميع قيود الأستاذ العام على الإطلاق)، فإن خطة التنفيذ المقسّمة ستسرد جميع الأقسام المطلوب فحصها، وهو ما قد يكون أبطأ قليلاً من الحالة غير المقسّمة بسبب عبء دمج النتائج من الأقسام. ومع ذلك، فإن مثل هذه الاستعلامات الواسعة نادرة في نظام ERP (and if they happen, they’re inherently heavy anyway).

استخدام الإدخال/الإخراج على القرص (Disk I/O) واستخدام المعالج (CPU): من خلال قراءة عدد أقل من الأقسام، يقوم محرك قاعدة البيانات بعمليات قراءة أقل من القرص. إن عملية استبعاد الأقسام غير المطلوبة (partition pruning) «تستبعد تلقائياً أي أقسام متبقية من عملية البحث»[6]، ما يعني أن ملفات البيانات تلك على القرص لا يتم لمسها إطلاقاً. ويكون هذا مفيداً بشكل خاص إذا كانت الأقسام الأقدم موجودة على أقراص أبطأ (يمكن وضع الأقسام على وسائط تخزين مختلفة – e.g., السنة الحالية على SSD والقديمة على HDD – حيث يسمح MariaDB بأن يمتد التقسيم عبر مساحات تخزين/أقراص متعددة[10]). يحتاج المعالج (CPU) إلى معالجة بيانات الأقسام المطابقة فقط، لذلك إذا كان، على سبيل المثال، تقرير ملخّص يقوم بحساب المجاميع، فإنه يجمع عدداً أقل بكثير من الصفوف. والنتيجة النهائية هي أن التقارير والاستعلامات تعمل بسرعة أكبر وبحمل أقل على النظام. على سبيل المثال، تشير وثائق تقسيم MySQL إلى أن الاستعلامات يمكن أن تكون «محسّنة بشكل كبير» من خلال ضمان أن البيانات التي تحقق شرط WHERE موجودة في قسم واحد أو عدد قليل من الأقسام، مع تخطي البقية – وهذا هو بالضبط مبدأ استبعاد الأقسام (partition pruning)، الذي يقلل بشكل كبير من عمليات الإدخال/الإخراج واستهلاك المعالج[6][6].

سيناريو عملي: قد يقوم تقرير قائمة الدخل في ERPNext بجلب مجاميع قيود الأستاذ العام لسنة مالية معينة. بدون التقسيم، قد تقوم قاعدة البيانات بفحص ملايين القيود ثم تصفيتها لتلك السنة؛ أما مع التقسيم، فسيتم فحص قسم تلك السنة فقط – وقد يكون الفرق هو انخفاض زمن تنفيذ الاستعلام من 10 ثوانٍ إلى 1 ثانية إذا كان حجم البيانات كبيراً. سيناريو آخر: تقرير رصيد المخزون اعتباراً من اليوم قد يحتاج إلى أخذ جميع قيود دفتر المخزون حتى تاريخ اليوم بعين الاعتبار. إذا كانت الأقسام مقسّمة حسب السنة، فقد يحتاج الاستعلام إلى لمس جميع الأقسام حتى السنة الحالية – ولكن يمكن حتى ضبط الأقسام الأقدم لتكون للقراءة فقط أو موجودة على مساحة تخزين مضغوطة. وحتى إذا تم لمس عدة أقسام، يمكن معالجة فهارس وبيانات كل قسم بشكل منفصل وربما بالتوازي (مع ملاحظة أن MySQL لن يقوم بتوازي استعلام واحد عبر الأقسام تلقائياً – فخيط تنفيذ واحد للاستعلام سيعالجها واحداً تلو الآخر، وليس في نفس الوقت[8]). وعلى الرغم من غياب التوازي داخل الاستعلام الواحد، يمكن للتقسيم أن يحسّن الإنتاجية الإجمالية إذا كانت الاستعلامات المختلفة تستهدف أقساماً مختلفة (لأنها قد تُخدم من مناطق مختلفة على القرص، مما يقلل من التزاحم). ومع ذلك، فإن المكسب الرئيسي عادةً يكون من الاستبعاد (pruning)، وليس من التنفيذ المتوازي.

تقارير ERPNext واستبعاد الأقسام (Partition Pruning): معظم التقارير المالية الثقيلة في ERPNext تتضمن عوامل تصفية بالتاريخ – حيث يقوم المستخدمون بتشغيل الميزانيات العمومية، وقوائم الأرباح والخسائر، وكشوفات الأستاذ العام لفترة زمنية محددة. مع التقسيم، ستستفيد هذه التقارير بشكل تلقائي لأن استعلامات كل تقرير ستتضمن شروطاً مثل posting_date <= "YYYY-MM-DD" أو بين تاريخ بداية وتاريخ نهاية. ستقوم قاعدة البيانات باستبعاد الأقسام الواقعة خارج هذا النطاق. على سبيل المثال، تقرير General Ledger report لشهر يناير 2025 سيقرأ فقط قسم سنة 2025 من جدول GL Entry وربما جزءاً بسيطاً من 2024 إذا كانت هناك حاجة إلى رصيد افتتاحي من السنة السابقة، لكنه لن يلمس بيانات 2019 أو 2020 وما شابه. مثال آخر: تقارير valuation أو ageing للمخزون حتى تاريخ معين ستنظر فقط إلى الأقسام حتى ذلك التاريخ. وكلما زاد عدد الأقسام التي يمكن استبعادها، أصبحت هذه الاستعلامات أسرع. وهذا مدعوم بوثائق محركات قواعد البيانات، حيث تشير إلى أن محسّن MariaDB لن يقرأ الأقسام الأخرى إذا كان شرط WHERE يقيّد مفتاح التقسيم، كما رأينا[9].

ملخص المقارنة: مع اختيار جيد لمفتاح التقسيم (عادةً تاريخ)، ومع استعلامات تتضمن هذا المفتاح، تقوم خطة التنفيذ بعمل أقل ويلاحظ العتاد عبئاً أقل. نلاحظ انخفاضاً في rows examined ضمن أدوات التحليل، وعدداً أقل من الصفحات المقروءة من القرص (وغالباً ما يكون ذلك واضحاً في أدوات مثل performance schema في MySQL أو EXPLAIN ANALYZE)، وغالباً انخفاضاً كبيراً في أزمنة تنفيذ الاستعلامات. يصبح الفرق أكثر وضوحاً مع نمو حجم البيانات. في مجموعات البيانات الصغيرة (بضع مئات الآلاف من الصفوف)، قد لا يكون عبء التقسيم مجدياً. لكن على نطاق واسع (عشرات الملايين من الصفوف)، يمكن أن يكون الفرق هو الفارق بين تقارير تستغرق دقائق مقابل ثوانٍ. هناك ملاحظة مهمة: إذا كان الاستعلام يحتاج فعلاً إلى كامل مجموعة البيانات (e.g. مدقق حسابات يستخرج جميع العمليات لعشر سنوات)، فلن يؤدي التقسيم إلى تسريعه – بل قد يضيف عبئاً طفيفاً لأن المحرك سيقوم بالمرور على الأقسام. لكن مثل هذه الحالات نادرة ويمكن التعامل معها عبر عمليات تصدير مخصصة أو تنفيذها على نسخة مكررة (replica).

خلاصة القول، التقسيم مع الفهرسة الصحيحة يشكلان ضربة مزدوجة فعّالة: حيث يضمن التقسيم عدم فحص الأجزاء غير ذات الصلة من الأساس، بينما تقوم الفهرسة بتحسين البحث داخل الجزء ذي الصلة[10][10]. يؤدي ذلك إلى تقليل عمليات الإدخال/الإخراج واستهلاك المعالج للعمليات المعتمدة على التصفية بالتاريخ. في البيئات الكبيرة لـ ERPNext، لاحظ المستخدمون تحسناً ملحوظاً في الأداء من خلال تقسيم الجداول الثقيلة – مثل تسريع توليد التقارير وتقليل الحمل على خادم قاعدة البيانات خلال أوقات الذروة (حيث إن كل استعلام يتعامل فقط مع الأقسام الحالية)[6][6]. وبشكل أساسي، يبقي ذلك البيانات التاريخية «بعيدة عن الطريق» إلى أن يتم الاحتياج إليها تحديداً.

(Citing official database refs:) تشير وثائق MariaDB إلى أن الجداول الكبيرة جداً قد تكون بطيئة حتى لو كانت الاستعلامات محسّنة، لكن التقسيم يمكن أن يجعل الاستعلامات “much faster” إذا كانت تحتاج فقط إلى عدد قليل من الأقسام – مع التنبيه المهم إلى أن الاستعلامات يجب أن تكون مكتوبة للاستفادة من مفتاح التقسيم[10]. وهذا يتوافق مع تحليلنا: الاستعلامات المكتوبة بشكل جيد في ERPNext (مع عوامل تصفية بالتاريخ) عند دمجها مع جداول مقسّمة تنتج خطط تنفيذ أفضل ونتائج أسرع بفضل استبعاد الأقسام.

4. النسخ الاحتياطي، الاستعادة، والأثر التشغيلي

إن تطبيق التقسيم (partitioning) في قاعدة البيانات يمكن أن يكون له تأثيرات على إجراءات النسخ الاحتياطي والاستعادة لديك، وكذلك على العمليات العامة مثل التعافي من الكوارث. من المهم فهم هذه التأثيرات لتعديل ممارساتك وفقاً لذلك.

النسخ الاحتياطية مع الجداول المقسّمة: في ERPNext، يتم عادةً أخذ النسخ الاحتياطية عبر أمر bench backup أو عبر تفريغ قاعدة البيانات مباشرةً (e.g., mysqldump أو أدوات التفريغ الخاصة بـ MySQL/MariaDB). من منظور منطقي، لا يتغير الكثير عند أخذ نسخة احتياطية كاملة (تفريغ SQL) لجدول مقسّم – حيث سيتضمن التفريغ عبارة CREATE TABLE مع بنود التقسيم ثم جميع البيانات (أو قد تستخدم تفريغات منفصلة لكل جدول). أما النسخ الاحتياطية المعتمدة على الملفات (مثل نسخ ملفات *.ibd الخام أو استخدام Percona XtraBackup) فستتعامل ببساطة مع الأقسام كجزء من ملفات مساحة تخزين الجدول.

إحدى مزايا التقسيم بالنسبة للنسخ الاحتياطي هي إمكانية تنفيذ نسخ احتياطية جزئية أو تزايدية. وبما أن كل قسم يمكن التعامل معه بشكل شبه مستقل، يمكنك أخذ نسخ احتياطية للأقسام الحديثة بشكل متكرر وأرشفة الأقسام الأقدم بوتيرة أقل. على سبيل المثال، إذا كان لديك أقسام سنوية وتعلم أن أقسام 2015-2020 ثابتة (لا تغييرات عليها)، فقد تحتاج فقط إلى أخذ نسخة احتياطية منها مرة واحدة وتخزينها، مع تركيز عملية النسخ الاحتياطي اليومية على السنة الحالية والسنتين الأخيرتين. بعض أدوات أو استراتيجيات النسخ الاحتياطي تسمح بأخذ نسخ احتياطية لأقسام أو جداول محددة. تدعم MySQL Enterprise Backup وغيرها النسخ الاحتياطي/الاستعادة الانتقائية على مستوى الجدول أو القسم[12]. وحتى عند استخدام mysqldump، يمكنك تفريغ أقسام معينة فقط عبر التفريغ باستخدام شرط WHERE (رغم أن ذلك يكون يدوياً). ومع ذلك، بشكل افتراضي فإن bench backup أو تفريغ mysqldump الكامل سيستمر في تفريغ كل شيء، وبالتالي سيستمر زمن النسخ الاحتياطي بالنمو مع ازدياد حجم البيانات ما لم تقم بتقسيمه بوعي.

النسخ الاحتياطية الكاملة مقابل نسخ اللقطات (Snapshot): هناك عدة أساليب:

1. النسخ الاحتياطية المنطقية الكاملة: تفريغ كامل لقاعدة البيانات (جميع الجداول، جميع الأقسام). لا يقلل التقسيم من حجم البيانات، لذلك تظل النسخة الاحتياطية الكاملة كبيرة وتستغرق وقتاً يتناسب مع إجمالي حجم البيانات. وجود الأقسام يعني فقط أن عبارات CREATE TABLE تحتوي على صياغة إضافية. عند الاستعادة من مثل هذا التفريغ، سيتم إعادة إنشاء الأقسام تلقائياً. نقطة واحدة يجب التحقق منها: إذا كنت تستخدم في أي وقت الاستيراد الجزئي في MySQL (e.g., باستخدام --use-threads للاستعادة المتوازية أو ما شابه)، فقد تتطلب الجداول المقسّمة استعادة جميع الأقسام معاً على أي حال، لذلك غالباً ما يتم استعادة الجدول كاملاً.
2. النسخ الاحتياطية الفيزيائية أو نسخ اللقطات: قد تستخدم بعض البيئات لقطات نظام الملفات أو لقطات وحدات التخزين (مثل LVM snapshots أو لقطات الآلات الافتراضية، أو لقطات التخزين السحابي) لالتقاط حالة قاعدة البيانات في نقطة زمنية معينة. لا يؤثر التقسيم سلباً على ذلك؛ بل في الواقع، إذا كانت الأقسام الأقدم للقراءة فقط، فإن القلق الرئيسي عند أخذ اللقطة يكون منصباً على الأقسام النشطة (مع مخاطر أقل لتغير البيانات في الأقسام القديمة). غالباً ما تسمح النسخ الاحتياطية المعتمدة على اللقطات باستعادة سريعة لكامل البيئة. كما أنها تتكامل مع استراتيجيات الأرشفة (المناقشة في Section 5B) حيث يتم أخذ لقطة كنوع من الأرشيف.
3. النسخ الاحتياطية التزايدية: عند استخدام XtraBackup الخاص بـ MariaDB أو النسخ الاحتياطية المعتمدة على binlog، قد يضيف التقسيم بعض التعقيد البسيط إذا قمت بحذف أقسام (لأن حذف قسم هو عملية DDL تؤدي فعلياً إلى حذف عدد كبير من الصفوف فوراً). ومع ذلك، فإن الأدوات مصممة للتعامل مع أحداث DDL. كل ما عليك هو التأكد من أن سلسلة أدوات النسخ الاحتياطي/الاستعادة لديك على دراية بعمليات التقسيم. على سبيل المثال، إذا قمت باستعادة جزئية لملفات بيانات قسم واحد فقط، فستحتاج إلى استيراده بشكل صحيح مع تعريف الجدول.

إحدى الملاحظات المهمة: “قد يؤثر تقسيم MySQL على طريقة تنفيذ تكرار البيانات والنسخ الاحتياطي. هناك اعتبارات خاصة مطلوبة لضمان استمرار عمل هذه العمليات بسلاسة بعد التقسيم.”[11]. يشير هذا إلى أنه إذا كان لديك خوادم تكرار (replication slaves) أو إذا كنت تعتمد على binlog للتعافي حتى نقطة زمنية محددة، فيجب اختبار ذلك بعد إضافة الأقسام. بشكل عام، يعمل الأمر بشكل جيد، لكن بعض الأمور مثل row-based replication قد تواجه مشكلات أداء مع عمليات التقسيم الضخمة (e.g., إذا قمت بحذف قسم، يقوم الخادم الرئيسي بتسجيله كعبارة واحدة وهو أمر جيد؛ أما إذا كنت تحذف ملايين الصفوف بدلاً من ذلك، فسيكون الأمر أسوأ). في الواقع، يمكن أن يجعل التقسيم التكرار أكثر سلاسة من خلال تنفيذ عمليات التنظيف الكبيرة كعملية واحدة (حذف قسم) بدلاً من حذف عدد كبير من الصفوف.

اعتبارات الاستعادة: يجب أن تؤدي استعادة جدول مقسّم من نسخة احتياطية إلى إعادته مع الأقسام سليمة (بافتراض أن النسخة الاحتياطية التقطت تعريفات الأقسام). إذا قمت باستعادة جدول من تفريغ SQL، فتأكد من أن عبارة CREATE TABLE تتضمن بند PARTITION BY ... – حيث يقوم mysqldump بتضمين ذلك افتراضياً. إذا استخدمت bench backup (والذي ينشئ فعلياً ملف SQL وملف GZip للملفات)، فسيحتوي ملف SQL على تلك البنود. هناك حالة خاصة: إذا احتجت في أي وقت إلى استعادة بيانات قسم سنة واحدة فقط (على سبيل المثال، إذا قمت بحذف قسم سنة 2019 عن طريق الخطأ وتريد استعادته دون التأثير على الأقسام الأخرى)، فقد تضطر إلى استعادته في جدول منفصل ثم exchange هذا الجدول إلى القسم المناسب. يدعم MySQL عملية استبدال جدول بقسم (تحويل جدول مستقل إلى قسم ضمن جدول آخر)[10]. يُعد هذا استخداماً متقدماً، لكنه قد يكون مفيداً لإدارة الأرشيف – فعلى سبيل المثال، يمكنك detach قسم إلى جدول مستقل، وأرشفة هذا الجدول، ثم إعادة ربطه لاحقاً عند الحاجة.

الأثر التشغيلي – النسخ الاحتياطية: يمكن أن يؤدي التقسيم (Partitioning) فعلياً إلى تحسين أداء النسخ الاحتياطي إذا تم استثماره بشكل صحيح. فعلى سبيل المثال، يتم استبدال عمليات الحذف الكبيرة بعمليات حذف سريعة للأقسام (partition drops)، ما يعني أن مجموعة البيانات النشطة تصبح أصغر – وبالتالي تصبح النسخ الاحتياطية للبيانات النشطة أسرع. وإذا كانت الأقسام الأقدم ثابتة، يمكنك استثناؤها من النسخ الاحتياطية المتكررة (وتخزينها مرة واحدة بشكل غير متصل). تشير وثائق MariaDB إلى أنه إذا قمت بفصل البيانات التاريخية عن البيانات الحديثة، فغالباً ستحتاج فقط إلى أخذ نسخ احتياطية منتظمة للأقسام الحالية، وليس للجدول بأكمله في كل مرة[10]. يمكن أن يؤدي ذلك إلى تقليل كبير في زمن النسخ الاحتياطي ومساحة التخزين للنسخ اليومية[10]. ستستمر في الاحتفاظ بنسخ احتياطية كاملة بشكل دوري، ولكن ليس بشكل يومي للبيانات غير المتغيرة.

التعافي من الكوارث (Disaster Recovery): في سيناريو DR، لا يغيّر التقسيم الخطوات بشكل جذري: لا تزال بحاجة إلى استعادة قاعدة البيانات من النسخ الاحتياطية أو التحويل إلى نسخة مكررة (replica). عند استخدام DR المعتمد على التكرار، يجب الانتباه إلى أن أوامر صيانة الأقسام (إضافة/حذف أقسام) سيتم تكرارها. وإذا قمت بترقية نسخة مكررة، فيجب أن تحتوي على نفس إعدادات التقسيم. هناك نقطة يجب مراعاتها: إذا كنت تقوم بـ delayed archiving (مثل حذف الأقسام بعد أخذ لقطات)، فتأكد من توثيق أي الأرشيفات تم أخذها وأي الأقسام تم حذفها. في استعادة DR، ستحتاج إلى معرفة “لدينا بيانات حتى سنة X في قاعدة البيانات الرئيسية، والبيانات الأقدم موجودة في الأرشيف Y”. تعني الحوكمة الجيدة (المناقشة لاحقاً) الاحتفاظ بسجل منظم لجميع النسخ الاحتياطية المؤرشفة.

تخفيف المخاطر التشغيلية: بعض الاستراتيجيات:

1. اختبار عمليات الاستعادة باستخدام نسخ احتياطية لجداول مقسّمة. لا تفترض أنها تعمل – بل قم فعلياً بمحاكاة الاستعادة على بيئة اختبارية للتأكد من أن الأقسام تعود بشكل صحيح وأن الأداء مقبول.
2. استخدام التكرار أو بيئة مرحلية (staging): يمكنك الحفاظ على نسخة مكررة من قاعدة بيانات ERPNext مخصصة لتشغيل النسخ الاحتياطية (بحيث لا تؤثر عمليات التفريغ على النظام الأساسي). لا يعيق التقسيم ذلك؛ بل على العكس، قد تتكرر قاعدة بيانات مقسّمة بشكل جيد بسلاسة أكبر من خلال تجنب طفرات الكتابة الضخمة (باستثناء عمليات تعديل الأقسام).
3. مراقبة سكربتات النسخ الاحتياطي: إذا كانت لديك سكربتات نسخ احتياطي مخصصة، فتأكد من أنها تتعامل مع الأقسام بشكل صحيح. على سبيل المثال، إذا كان أحد السكربتات ينفذ عملية لكل جدول دون توقع صياغة التقسيم، فقد يحتاج إلى تعديل. ومع ذلك، فإن معظم الأدوات تتعامل مع ذلك بشكل جيد.
4. الإقفال (Locking) والأداء: من فوائد الأقسام أنه يمكنك أخذ نسخ احتياطية للأقسام القديمة الثابتة دون إقفال البيانات النشطة. على سبيل المثال، يمكنك قفل القسم الحالي فقط لفترة وجيزة لتحقيق الاتساق، بينما لم تتغير الأقسام الأقدم أصلاً. كذلك، فإن عمليات مثل ALTER TABLE ... DROP PARTITION هي عمليات online لا تقفل الجدول بأكمله لفترة طويلة، مما يقلل زمن التوقف أثناء مهام الأرشفة مقارنةً بعمليات DELETE الضخمة التي قد تقفل الجدول وتولد سجلات undo كبيرة.

باختصار، يمكن أن يكون التقسيم عاملاً إيجابياً صافياً لاستراتيجية النسخ الاحتياطي والاستعادة عند استخدامه بشكل صحيح: فهو يوفّر فرصاً لنسخ احتياطية أسرع من خلال عزل البيانات التاريخية[10]. ولكن يجب تحديث نظام النسخ الاحتياطي ليعالج الأقسام بشكل مختلف عند الحاجة (e.g., أخذ نسخ احتياطية للأقسام وفق جداول زمنية مختلفة). كما من المهم الاحتفاظ بنسخ من بيانات الأقسام المؤرشفة (سواء كملفات تفريغ منفصلة أو كجزء من نسخ احتياطية كاملة أقل تكراراً) تحسباً لأي حاجة مستقبلية لاسترجاع بيانات تمت إزالتها من قاعدة البيانات الرئيسية. من الناحية التشغيلية، يضيف التقسيم بعض التعقيد (مهام إضافية لمسؤول قاعدة البيانات لإدارة الأقسام)، لكنه إذا نُفذ بعناية، لا ينبغي أن يضيف مخاطر كبيرة. بل على العكس، من خلال الحفاظ على قاعدة البيانات الحية أكثر رشاقة، فإنه يقلل من مخاطر فترات التوقف الطويلة أثناء الاستعادة – قاعدة بيانات نشطة أصغر = استعادة أسرع.

النسخ الاحتياطية المعتمدة على اللقطات (Snapshot-Based Backups): إذا كنت تستخدم أرشفة قائمة على اللقطات (راجع القسم التالي لنماذج الأرشفة)، فقد تقوم بأخذ لقطة كاملة لقاعدة البيانات في نهاية السنة واستخدامها كأرشيف ثم إزالة البيانات من قاعدة البيانات الحية. تكون هذه اللقطة بمثابة نسخة احتياطية تؤدي أيضاً دور الأرشيف. ولأغراض DR، ستحتفظ بهذه اللقطات بشكل آمن (ربما في تخزين بارد أو على خادم أرشيف). لاستعادة بيانات تعود إلى خمس سنوات مثلاً، قد تقوم بتشغيل تلك اللقطة على نسخة أقدم من ERPNext (أو على خادم معزول). يتطلب هذا الأسلوب انضباطاً في تسمية اللقطات وتخزينها (e.g., “ERPNext_DB_archive_2020_after_year_close.sql.gz”). وهو أقل دقة من حيث الاستعادة على مستوى الأقسام، لكنه أبسط من الناحية المفاهيمية (حيث تكون اللقطة نسخة احتياطية مكتملة للنظام بأكمله في نقطة زمنية محددة).

الخلاصة: إن تأثير التقسيم على النسخ الاحتياطي والاستعادة هو في الغالب إيجابي من ناحية سهولة الإدارة. من خلال التقسيم:

1. يمكنك حذف كتل كبيرة من البيانات بسرعة (بعد التأكد من أخذ نسخة احتياطية لها) بدلاً من تنفيذ عمليات DELETE ضخمة.
2. يمكنك جعل النسخ الاحتياطية الروتينية أصغر وأسرع من خلال استبعاد الأقسام التاريخية الثابتة أو أخذ نسخ احتياطية لها بشكل غير متكرر.
3. تكون استعادة البيانات الحديثة أسرع لأن حجم البيانات المطلوب استعادته في النظام الرئيسي يصبح أقل بعد الأرشفة.
4. تحقق دائماً من أن الجداول المقسّمة مشمولة في إجراءات النسخ الاحتياطي؛ وإذا كنت تستخدم أي منطق مخصص للتضمين/الاستبعاد، فتأكد من عدم تجاوز أي شيء بشكل غير متوقع.

يمكن التخفيف من المخاطر التشغيلية من خلال التوثيق والاختبار. تعامل مع إدارة الأقسام كجزء من مهام الصيانة الدورية لمسؤول قاعدة البيانات (مثل تحسين الفهارس، إلخ). وبالنسبة للتعافي من الكوارث، يجب أن تكون هناك إجراءات واضحة: e.g., “استعادة أحدث نسخة احتياطية كاملة لقاعدة البيانات النشطة، ثم تحميل تفريغ الأرشيف للفترة 2010-2020 بشكل منفصل إذا لزم الأمر للاستعلامات التاريخية.” ستكون هذه الوضوحات حاسمة تحت الضغط.

5. نماذج الأرشفة في ERPNext (الموضوع الأساسي)

تشير الأرشفة في سياق ERPNext إلى الاحتفاظ بالبيانات التاريخية بطريقة تخفف الحمل عن النظام الحي مع الحفاظ على تلك البيانات للرجوع إليها مستقبلاً (لأغراض التدقيق، التقارير، إلخ). دعونا نستعرض ثلاثة نماذج رئيسية للأرشفة (وبعض المتغيرات) مع مزاياها وعيوبها وحالات الاستخدام الخاصة بها:

A. الأرشفة ضمن نفس قاعدة البيانات (الأقسام في مكانها): في هذا النموذج، يتم الاحتفاظ بجميع البيانات في نفس موقع/قاعدة بيانات ERPNext، ولكن يتم استخدام تقنيات مثل التقسيم أو العلامات (flags) للفصل بين البيانات “النشطة” و“المؤرشفة”. عملياً، لا يتم نقل أي بيانات فعلياً خارج قاعدة البيانات. وبدلاً من ذلك، قد تقوم بما يلي:

1. تقسيم الجداول التشغيلية حسب التاريخ ووضع علامة على الأقسام الأقدم على أنها “مؤرشفة” (للقراءة فقط). على سبيل المثال، بعد إغلاق FY2020، يمكنك ضبط قسم 2020 ليكون للقراءة فقط (لضمان عدم تعديل السجلات القديمة عن طريق الخطأ) مع الإبقاء عليه داخل قاعدة البيانات. تبقى جميع البيانات متاحة عبر واجهة ERPNext بشكل طبيعي – يمكن للمستخدمين البحث عن فواتير قديمة، وتشغيل تقارير قديمة، إلخ.
2. بدلاً من ذلك، وبدون استخدام أقسام رسمية، يمكن إضافة علامة “Archived” إلى السجلات وتعديل التطبيق لاستبعاد السجلات المؤرشفة من العروض العادية. ومع ذلك، فإن تنفيذ هذا في ERPNext يتطلب تخصيصات واسعة لكل تقرير وكل استعلام، لذلك يُعد نهج التقسيم أكثر شفافية على مستوى قاعدة البيانات.

الخصائص والمزايا: يُعد هذا النهج الأبسط من حيث شفافية التطبيق – حيث لا يحتاج ERPNext إلى معرفة أي شيء خاص. تبقى جميع السجلات في جداولها الأصلية. لا يحتاج المستخدمون إلى التبديل بين أنظمة أو تشغيل استعلامات خاصة للوصول إلى البيانات القديمة. وإذا قمت بالتقسيم حسب السنة، فإن البيانات القديمة لا تُبطئ الاستعلامات الحالية بشكل كبير تلقائياً (بفضل الاستبعاد)، وبالتالي تحصل على بعض فوائد الأداء مع الحفاظ على مصدر واحد للحقيقة. كما يعني ذلك عدداً أقل من الأجزاء المتحركة: نسخة احتياطية واحدة لقاعدة البيانات تحتوي على كل شيء (عند الحاجة)، ومثيل ERPNext واحد للإدارة.

العيوب: ستستمر قاعدة البيانات في النمو من حيث الحجم إلى ما لا نهاية، مما قد يفرض تحديات مستمرة:

1. يؤثر الحجم الإجمالي على زمن النسخ الاحتياطي (حتى مع تحسينه، تظل النسخة الاحتياطية الكاملة كبيرة)، وزمن الاستعادة، وتكاليف التخزين.
2. على الرغم من أن الأقسام تخفف مشكلات أداء الاستعلامات، إلا أن بعض العمليات قد تظل أبطأ مع أحجام بيانات ضخمة – e.g. البحث الشامل، أو أي استعلام لا يقيّد بالتاريخ (مع أن هذه الحالات قد تكون نادرة أو يمكن التخفيف منها).
3. هناك أيضاً خطر أن يقوم أحدهم بتشغيل تقرير لـ “جميع السنوات”، وعلى الرغم من أن الأقسام سيتم فحصها، إلا أن ذلك قد يرهق الخادم لأن جميع الأقسام يجب قراءتها.
4. من منظور الامتثال، فإن الاحتفاظ بجميع البيانات في قاعدة البيانات النشطة يعني أنه من الممكن تقنياً (مع الصلاحيات الكافية) تعديل السجلات التاريخية. وإذا كان المدققون يطلبون قفل البيانات، فسيتعين الاعتماد على ضوابط على مستوى التطبيق (مثل صلاحيات ERPNext أو أداة Period Closing) بدلاً من الفصل الفيزيائي. (يمكن أن تساعد الأقسام للقراءة فقط، لكن ليس كل عمليات أنظمة قواعد البيانات العلائقية تحترم بسهولة خاصية القراءة فقط على مستوى القسم ما لم يتم استخدام tablespaces وضبطها كقراءة فقط).
5. هناك أيضاً مخاطر تتعلق بالترقية: مع نمو قاعدة البيانات، قد تستغرق الترقيات الرئيسية لإصدارات ERPNext (والتي غالباً ما تتضمن عمليات ترحيل للبيانات) وقتاً طويلاً لأنها قد تمر على حجم كبير من البيانات لتنفيذ التصحيحات. على سبيل المثال، إذا كان هناك سكربت تصحيح يحتاج إلى إعادة احتساب شيء ما لجميع القيود السابقة، فإن مجموعة البيانات الضخمة ستطيل زمن تنفيذ ذلك التصحيح.

باختصار، فإن الأرشفة ضمن نفس قاعدة البيانات هي عملياً نهج “عدم إزالة شيء، مع التقسيم فقط”. وهو سهل التنفيذ ومثالي في السنوات الأولى أو للأنظمة متوسطة الحجم. قد تبدأ العديد من الشركات بهذا النموذج – حيث تقوم بالتقسيم لتحسين الأداء وتأجيل الحاجة إلى إزالة البيانات. إنه يمنحك وقتاً، ومع تقسيم جيد، قد لا تشعر بالألم حتى بعد عقد من البيانات أو أكثر. ومع ذلك، في نهاية المطاف، قد يصبح الحجم الهائل غير عملي، وهذا ما يقود إلى النماذج التالية.

B. الأرشفة المعتمدة على اللقطات (Snapshot-Based Archiving) (نسخة كاملة لقاعدة البيانات في نقطة زمنية محددة): يتضمن هذا النموذج أخذ لقطة دورية لكامل قاعدة بيانات ERPNext (وربما قاعدة الكود أيضاً) كأرشيف، ثم إزالة البيانات القديمة من النظام الحي. حالة استخدام نموذجية: الأرشفة في نهاية السنة. بعد إغلاق الحسابات لسنة مثل 2025، تقوم بإنشاء نسخة احتياطية كاملة أو استنساخ لموقع ERPNext كما هو في تلك اللحظة. يتم تخزين هذه النسخة (وقد يتم حتى نشرها على خادم للتصفح عند الحاجة). بعد ذلك، في ERPNext الحي، تقوم بحذف أو إسقاط الأقسام لجميع البيانات حتى سنة 2020 (إذا كنت تحتفظ بخمس سنوات فقط على النظام الحي، على سبيل المثال). الأرشيف الذي أخذته لسنة 2025 يحتوي بطبيعته على جميع البيانات حتى 2025 في حزمة واحدة.

يمكن أن تكون هذه اللقطة تفريغ SQL، أو صورة كاملة لآلة افتراضية (VM image). أحياناً تحتفظ المؤسسات حرفياً بـ صورة آلة افتراضية أو نسخة احتياطية للنظام في تلك النقطة الزمنية (سيتم التوسع في نهج الصورة الكاملة في Section 7A). لكننا هنا نركز على المفهوم: الأرشيف هو نسخة كاملة من بيانات ERPNext في وقت محدد.

الإيجابيات (Pros):

1. الحفظ الكامل: تمثل اللقطة (snapshot) حالة متسقة ذاتياً لكامل نظام ERPNext. جميع DocTypes، وجميع السجلات، وجميع العلاقات تبقى تماماً كما كانت. وهذا ممتاز لأغراض التدقيق – حيث يمكنك استعادة تلك اللقطة ورؤية النظام كما كان في ذلك الوقت.
2. عدم الحاجة لمواءمة المخطط (schema): لأنها قاعدة البيانات والكود الكاملين في ذلك الوقت، فلا حاجة لتحويل البيانات لتناسب مخططاً جديداً. إنه حرفياً المخطط القديم. (وإذا اخترت الاحتفاظ بها كتفريغات SQL خام، فلن تقلق حتى بشأن الكود).
3. بساطة حدث الأرشفة: إن أخذ نسخة احتياطية كاملة هو عملية مباشرة (bench backup أو snapshot). هناك مخاطر أقل لفقدان شيء ما بشكل انتقائي لأنك قمت بالتقاط كل شيء.
4. الحوكمة والامتثال: يمكنك تخزين ذلك الأرشيف بطريقة غير قابلة للتلاعب (e.g., وسائط كتابة لمرة واحدة أو قرص غير متصل). وبما أنه غير مطلوب للعمليات اليومية، فيمكن قفله فعلياً. إذا طلب مدقق بعد 5 سنوات بيانات تعود إلى 10 سنوات مضت، يمكنك تزويده بقاعدة البيانات للقراءة فقط أو بنسخة مستعادة مطابقة لذلك الأرشيف. وبما أنك أزلت تلك السجلات من النظام الحي، فإنك تقلل أيضاً من مخاطر التغيير غير المقصود عليها في النظام التشغيلي.

السلبيات (Cons):

1. سهولة الوصول: بمجرد إزالة البيانات من النظام الحي، لن يتمكن المستخدمون النهائيون من الاستعلام عنها عبر واجهة ERPNext. إذا بحثوا عن رقم فاتورة قديم، فلن يتم العثور عليه. للوصول إلى البيانات المؤرشفة، سيتعين على شخص ما تحميل تلك اللقطة (إما عبر إعداد مثيل منفصل أو تشغيل استعلامات SQL على النسخة الاحتياطية). هذا النموذج يبادل الوصول الفوري مقابل الأداء وسهولة الإدارة.
2. تعدد الأرشيفات مع مرور الوقت: إذا قمت بذلك سنوياً، فستتراكم لديك عدة أرشيفات (لقطة 2021، لقطة 2022، إلخ). وقد يصبح الأمر مرهقاً في الإدارة إذا طلب مدقق، على سبيل المثال، نطاقاً زمنياً يمتد عبر عدة أرشيفات (“أعطني جميع الفواتير من 2018 إلى 2022” قد يتطلب استعادة عدة لقطات أو دمج البيانات).
3. ازدواجية البيانات: كل لقطة هي نسخة كاملة من قاعدة البيانات، بما في ذلك البيانات الرئيسية والإعدادات. هناك تكرار بينها (سجلات العملاء ستظهر في عدة لقطات سنوية إذا كانت موجودة لسنوات عديدة). يستهلك ذلك مساحة تخزين إضافية، رغم أن التخزين رخيص نسبياً مقارنة بمشكلات الأداء في قاعدة البيانات الحية.
4. التوافق مع الكود: إذا احتفظت بأرشيف لفترة طويلة، فإن إصدار ERPNext الموجود فيه سيصبح قديماً. وإذا كان الأرشيف عبارة عن تفريغ SQL مثلاً، فقد تحتاج إلى بيئة مناسبة لاستعادته. هناك جهد مطلوب للحفاظ على القدرة على قراءة ذلك الأرشيف (e.g., الاحتفاظ بكود إصدار قديم من ERPNext، أو الاستعداد لتشغيل بيئة متوافقة). سنناقش الخيارات: إما الإبقاء على الإصدار القديم قيد التشغيل أو التخطيط لترحيل بيانات الأرشيف لاحقاً عند الحاجة (وهو ما يرتبط بـ Section 7).
5. العبء التشغيلي: على الرغم من أن عملية الأرشفة نفسها بسيطة، فإن ضمان عدم فقدان أي شيء أو أرشفته بشكل خاطئ يتطلب انضباطاً. يجب التحقق من سلامة الأرشيف قبل الحذف من النظام الحي (e.g., استعادة النسخة الاحتياطية على خادم تطوير للتأكد من أنها تعمل). وقد تكون هذه عملية ثقيلة تحدث مرة واحدة في السنة.

حالات الاستخدام المثالية: تُعد الأرشفة المعتمدة على اللقطات شائعة في السيناريوهات التي يكون فيها إغلاق الفترات واضحاً ونادراً ما تكون هناك حاجة لدمج البيانات القديمة والجديدة. على سبيل المثال، قد تقول شركة خدمات مالية: “نحتفظ بسنتين على النظام الحي، وكل ما هو أقدم يتم تجميده سنوياً.” يكون المدققون مرتاحين لذلك طالما يمكنك استرجاع المعلومات القديمة عند الطلب. وهي مناسبة أيضاً عندما تتطلب المتطلبات التنظيمية حفظاً دقيقاً للبيانات – إذ إن اللقطة لا يتم تعديلها بعد إنشائها، وتحافظ على البيانات بصيغتها الأصلية (ومع التواقيع الرقمية أو checksums يمكنك حتى إثبات عدم تعديلها). وهي تشبه إلى حد كبير أخذ دفاتر الحسابات وطباعتها إلى PDF وتخزينها – باستثناء أن ما يتم حفظه هنا هو قاعدة البيانات.

فوائد الحوكمة والتدقيق: من خلال حذف البيانات القديمة من قاعدة البيانات الحية، تقلل من مخاطر الوصول غير المصرح به أو التلاعب أثناء العمليات اليومية. أما الأرشيف، كونه للقراءة فقط وغير متصل، فيمكن تأمينه بإحكام. هذا النهج ينشئ فعلياً سجلاً تاريخياً غير قابل للتغيير لكل فترة، وهو أمر ممتاز للامتثال. تستخدم العديد من القطاعات الخاضعة للتنظيم هذا الأسلوب بعد التنفيذ: e.g., بعد الترحيل من نظام ERP قديم، يحتفظون بصورة VM للنظام القديم للرجوع إلى السجلات، بدلاً من خلط البيانات القديمة مع النظام الجديد.

C. قاعدة بيانات أرشيف منفصلة (قاعدة تاريخية مستمرة): في هذا النموذج، يتم الاحتفاظ بـ قاعدتي بيانات (أو حتى موقعين لـ ERPNext): إحداهما قاعدة البيانات التشغيلية الحية، والأخرى قاعدة بيانات أرشيف تحتوي على المعاملات التاريخية التي تم نقلها خارج قاعدة البيانات الحية. وعلى عكس الأرشفة المعتمدة على اللقطات (التي قد تنتج عدة أرشيفات في نقاط زمنية مختلفة)، يهدف هذا النموذج إلى وجود قاعدة بيانات أرشيف مُحدَّثة باستمرار تتراكم فيها جميع السجلات القديمة. مع مرور الوقت، تبقى قاعدة البيانات التشغيلية صغيرة نسبياً (تحتوي فقط على البيانات الحديثة)، بينما تنمو قاعدة بيانات الأرشيف بجميع البيانات الأقدم.

لتنفيذ ذلك، يتم عادةً اتباع الخطوات التالية في كل دورة أرشفة (سنوياً أو ربع سنوي مثلاً):

1. نسخ أو نقل جميع المعاملات الأقدم من تاريخ X من قاعدة البيانات الرئيسية إلى قاعدة بيانات الأرشيف.
2. نسخ أي بيانات رئيسية (master data) لازمة أيضاً إلى قاعدة بيانات الأرشيف لضمان اكتمال العلاقات المرجعية. على سبيل المثال، إذا قمت بنقل فواتير مبيعات قديمة، فستحتاج إلى وجود بيانات العملاء والأصناف وغيرها من السجلات الرئيسية في قاعدة بيانات الأرشيف أيضاً (على الأقل تلك المرتبطة بالسجلات المؤرشفة). تميل البيانات الرئيسية إلى التغير (أو البقاء نشطة)، لذا فإن إحدى الاستراتيجيات هي أخذ لقطة من البيانات الرئيسية وقت الأرشفة. وبدلاً من ذلك، يمكن مزامنة جداول البيانات الرئيسية في قاعدة بيانات الأرشيف بشكل دوري لتعكس البيانات الحية (بحيث تحتوي على جميع العملاء/الأصناف).
3. التأكد من أنه بعد النقل، يتم حذف تلك السجلات من قاعدة البيانات الحية.

في جوهره، تصبح قاعدة بيانات الأرشيف مستودعاً تاريخياً لبيانات ERPNext، ولكن مع الحفاظ على نفس مخطط ERPNext (schema)، بحيث يمكن الاستعلام عنها بطريقة مماثلة. يمكنك حتى تشغيل مثيل ERPNext منفصل متصل بقاعدة بيانات الأرشيف إذا رغبت في توفير واجهة مستخدم لها (راجع section 6 و7B). والأهم من ذلك، من خلال إبقاء الأرشيف منفصلاً، فإننا نتجنب الاستعلامات العابرة لقواعد البيانات في العمليات اليومية – حيث يستعلم ERPNext الحي فقط من قاعدة بياناته، وإذا احتاج أحد إلى بيانات قديمة، فإنه يستعلم من قاعدة بيانات الأرشيف.

الإيجابيات (Pros):

1. تقليل الحمل على النظام الحي: تبقى قاعدة البيانات التشغيلية الحية أصغر بكثير وأسرع، بحيث تحتوي فقط على آخر 2-3 سنوات مثلاً. لم تعد البيانات القديمة تؤثر على الأداء إطلاقاً (حتى وإن كان التقسيم يحل ذلك أيضاً، ففي هذا النموذج لا تكون البيانات موجودة أصلاً).
2. سهولة الوصول إلى الأرشيف: على عكس اللقطة المجمّدة، يمكن إبقاء قاعدة بيانات الأرشيف متصلة (online) وقابلة للاستعلام. يمكنك ربط أداة BI أو حتى موقع ERPNext آخر بها للاستعلام عن البيانات التاريخية عند الطلب. وقد يكون للمستخدمين تسجيل دخول منفصل لنظام الأرشيف إذا لزم الأمر.
3. أرشيف واحد لكل التاريخ: على مدى السنوات، سيكون لديك قاعدة بيانات أرشيف واحدة تحتوي على جميع البيانات الأقدم. يمكن أن يبسّط ذلك عملية الاسترجاع لأنك لا تحتاج إلى إدارة عدة نسخ احتياطية سنوية – فجميع البيانات المؤرشفة موجودة في مكان واحد (وإذا أصبح الحجم كبيراً جداً، يمكن تقسيم قاعدة بيانات الأرشيف أيضاً لأنها في الغالب append-only).
4. سلامة البيانات: من خلال نقل السجلات بدلاً من تكرارها، تتجنب الالتباس الناتج عن وجود نسخ متعددة. يكون السجل موجوداً إما في النظام الحي أو في الأرشيف، وليس في كليهما (بافتراض وجود تاريخ قطع واضح). وإذا تم التنفيذ بعناية، فلن يحدث عدّ مزدوج أو فقدان للسجلات.
5. قابلية الصيانة على المدى الطويل: بما أن قاعدة بيانات الأرشيف يمكن أن تكون على خادم منفصل، يمكنك ضبطها بشكل مختلف (e.g., استخدام تخزين أرخص، أو إبقاؤها للقراءة فقط باستثناء عند أرشفة بيانات جديدة). كما يمكنك ترقيتها وفق جدول زمني مختلف. وإذا كان الأرشيف يستخدم في البداية نفس إصدار ERPNext المستخدم في النظام الحي، فقد تقرر لاحقاً الإبقاء عليه عند إصدار معين.

السلبيات (Cons):

1. تعقيد التنفيذ: يُعد هذا النهج الأكثر تعقيداً من الناحية التقنية. تحتاج إلى مزامنة أو نقل البيانات من قاعدة البيانات الحية إلى قاعدة بيانات الأرشيف بشكل موثوق. يمكن أن يتم ذلك عبر سكربتات مخصصة أو ربما باستخدام تكرار MySQL بطريقة مبتكرة (أحد الأساليب التي نوقشت في المجتمع كان استخدام replication للحفاظ على نسخة ثانية ثم إعادة إدراج البيانات المحذوفة فيها[6][6] – إلا أن ذلك يصبح معقداً). وفي الغالب، يتم استخدام سكربت يقوم باختيار السجلات القديمة وإدراجها في الأرشيف.
2. احتمالية مشكلات اتساق البيانات: يجب التأكد من أنه عند نقل المعاملات، يتم نقل جميع البيانات المرتبطة معها. على سبيل المثال، نقل فاتورة مبيعات قديمة يجب أن يتضمن أيضاً نقل صفوف جدول الأصناف الخاص بها، وقيود الأستاذ العام (إذا لم يكن GL مؤرشفاً بشكل منفصل)، وقيود دفتر المخزون (إذا أثرت على المخزون)، إلخ. وبشكل أساسي، تتطلب الأرشفة حسب نوع المعاملة التقاط مجموعة من المستندات المرتبطة. هذا ممكن عبر سكربتات (أو من خلال الاستفادة من علاقات DocType)، لكن الأخطاء قد تؤدي إلى سجلات يتيمة أو روابط مكسورة في الأرشيف.
3. عدم وجود عمليات ربط (Joins) عبر قواعد البيانات في الواجهة: لا يمكن لـ ERPNext إجراء عمليات ربط مباشرة بين البيانات الحية وبيانات الأرشيف. لذا فإن تقريراً يحتاج إلى كليهما يجب تشغيله بشكل منفصل على كل قاعدة بيانات ثم دمج النتائج خارجياً. عملياً، يتم تدريب المستخدمين على أن “الفترة الحالية تُستخدم عبر ERPNext الحي؛ والفترات الأقدم تُستخدم عبر تقارير الأرشيف.” أو يتم بناء حل تقارير مخصص يستعلم من كلا المصدرين عبر اتصالات منفصلة.
4. ترقيات قاعدة بيانات الأرشيف: إذا استمررت في استخدام مثيل ERPNext لعرض بيانات الأرشيف، فستواجه قراراً حول ما إذا كنت ستواصل ترقية ذلك المثيل. افترض أنك أرشفت بيانات من 2010-2020 في موقع أرشيف. وإذا كان موقعك الرئيسي الآن على ERPNext v16، فهل ستقوم بترقية موقع الأرشيف إلى v16 أيضاً (وتشغيل عمليات ترحيل على تلك البيانات التاريخية القديمة)؟ أم ستقوم بتجميده على إصدار أقدم؟ التجميد قد يؤدي في النهاية إلى تدهور البيئة (مشكلات أمنية أو توافق مع نظام التشغيل). أما الترقية فقد تحمل مخاطر تشغيل سكربتات ترحيل جديدة على حجم هائل من البيانات التاريخية (على الرغم من أنها للقراءة فقط، فإن معظم التصحيحات لن تؤثر عليها بعمق). هذا قرار حوكمي – ونستعرض استراتيجيات هجينة في section 7D.
5. بنية تحتية إضافية: ستحتاج على الأرجح إلى خادم قاعدة بيانات منفصل (أو على الأقل قاعدة بيانات منفصلة على نفس الخادم) لاستضافة الأرشيف. هذا مكون إضافي يجب إدارته. وإذا كان على نفس الخادم (مجرد مخطط أو DB مختلفة في MariaDB)، فتأكد من توفر المساحة ومن أن النسخ الاحتياطية تُدار بشكل منفصل.

تجنّب عمليات الربط العابرة لقواعد البيانات (Avoiding Cross-Database Joins): تشير هذه العبارة إلى أنه بوجود قاعدة بيانات أرشيف منفصلة، لا نريد سيناريوهات يحاول فيها استعلام واحد جلب بيانات من النظام الحي ومن الأرشيف معاً. في MySQL، من الممكن تقنياً الاستعلام عبر قواعد بيانات متعددة على نفس الخادم (SELECT ... FROM live.tabGL Entry JOIN archive.tabGL Entry_archive ...)، لكن ذلك غير ممكن ضمن طبقة تطبيق ERPNext، كما أنه يكسر التجريد وقد يكون بطيئاً. لذلك نتجنب ذلك من خلال ضمان أن أي حاجة تقريرية معينة يتم تلبيتها إما من قاعدة البيانات الحية أو من قاعدة بيانات الأرشيف، وليس من كليهما في آن واحد. وإذا كانت هناك حاجة إلى عرض مدمج (مثل تحليل اتجاهات لمدة 10 سنوات)، فإن النهج الأفضل هو استخدام مستودع بيانات أو أداة BI يمكنها السحب من كلا المصدرين بشكل مستقل ودمج النتائج (أو دمج البيانات مسبقاً خارجياً).

التعامل مع البيانات الرئيسية (Master Data Handling): يعد التعامل مع السجلات الرئيسية جانباً مهماً. على سبيل المثال، قد يكون عميل من خمس سنوات مضت قد تم تعديله أو حذفه لاحقاً في النظام الحي. في قاعدة بيانات الأرشيف، سترغب في الحفاظ على نسخة العميل كما كانت وقت ارتباطها بالمعاملات المؤرشفة (لأغراض التدقيق). e.g., إذا تغيّر اسم العميل في 2022، فيجب أن تُظهر فواتير 2020 الاسم القديم في الأرشيف عند الحاجة. هناك عدة طرق لذلك:

1. أرشفة البيانات الرئيسية كما كانت وقت الأرشفة (ربما باستخدام معلومات جدول Version أو ببساطة نسخ السجل الرئيسي في ذلك الوقت إلى الأرشيف). قد يؤدي ذلك إلى وجود عدة إدخالات لنفس العميل في قاعدة بيانات الأرشيف إذا تمت أرشفة ذلك العميل في أوقات مختلفة؟ لتجنب التكرار، يمكن تحديث السجل الرئيسي الموجود في الأرشيف إذا كان موجوداً، أو اختيار عدم تحديثه للحفاظ على المعلومات الأقدم. هذا يدخل في تفاصيل دقيقة، لكن هناك طريقة بسيطة: عند نقل معاملة، إذا لم يكن السجل الرئيسي المرتبط بها (Customer) موجوداً بعد في الأرشيف، يتم نسخه من النظام الحي. وإذا كان موجوداً، فربما لا يتم فعل شيء (وبالتالي تبقى المعلومات التي نُسخت في أول مرة تم فيها أرشفة معاملة لذلك العميل).
2. تقرر بعض المؤسسات أن البيانات الرئيسية صغيرة نسبياً، ولذلك تقوم فقط بالاحتفاظ بنسخة دورية كاملة من البيانات الرئيسية في الأرشيف (مثل تحديث جدول Customer في الأرشيف مرة واحدة في السنة بالمعلومات الحالية). لكن ذلك قد يؤدي إلى استبدال القيم التاريخية. وقد يكون ذلك مقبولاً إذا بقي المفتاح (مثل Customer ID) والحقول الأساسية، لكن يجب مراعاة متطلبات التدقيق (ربما يكون ذلك مقبولاً لأن المستندات التشغيلية غالباً ما تسجل التفاصيل المهمة مثل اسم العميل/العنوان كحقول داخل المعاملة نفسها وقت إنشائها).

باختصار، يهدف نهج قاعدة بيانات الأرشيف المنفصلة إلى إنشاء مستودع واحد طويل الأمد لجميع البيانات القديمة (legacy) خارج النظام الرئيسي. وهو يشبه إلى حد ما مستودع بيانات (data warehouse) لـ ERPNext ولكن دون تجميع – أي أنه يحتوي على البيانات التشغيلية الخام.

مقارنة بين A وB وC:

1. الأداء (Performance): (A) قاعدة بيانات واحدة مع التقسيم توفر تحسناً جيداً في الأداء للعمليات الحالية، لكن مع نمو البيانات إلى حد معين، قد تصبح حتى البيانات الوصفية (metadata) والنسخ الاحتياطية ثقيلة. (B) اللقطات (snapshots) تُبقي قاعدة البيانات الحية صغيرة، وبالتالي أفضل أداء للنظام الحي، ولكن لا يوجد وصول إلى البيانات الأقدم دون استعادة. (C) قاعدة بيانات أرشيف منفصلة تُبقي أيضاً قاعدة البيانات الحية صغيرة (فائدة مماثلة)، وتسمح بالاستعلام عن البيانات القديمة بشكل مستقل – ويكون الأداء في الأرشيف مناسباً للاستعلامات التاريخية (حتى لو كانت أبطأ، فهذا مقبول لأنها خارج العمليات اليومية).
2. التخزين والتكلفة (Storage & Cost): (A) قاعدة بيانات واحدة وتخزين واحد؛ أبسط من حيث الإدارة لكن كل شيء على التخزين الرئيسي. (B) تكرار البيانات مع كل لقطة (حاجة أعلى للتخزين، لكن يمكن نقلها إلى تخزين رخيص أو حتى أشرطة للنسخ القديمة). (C) مجموعتان من التخزين: واحدة للنظام الحي وأخرى للأرشيف – إجمالاً غالباً أكثر قليلاً من (A) ولكن مع تكرار أقل من (B) إذا تم توحيد الأرشيفات.
3. التعقيد (Complexity): (A) الأبسط – لا أنظمة جديدة. (B) متوسط – يتطلب انضباطاً في النسخ الاحتياطي وعملية لحذف البيانات القديمة بعد أخذ اللقطة. (C) الأعلى – يتطلب عملية أرشفة وصيانة مستمرة لقاعدة بيانات الأرشيف.
4. الامتثال للتدقيق (Audit Compliance): (A) توجد مخاطر تعديل لأن جميع البيانات “حية” (حتى مع قفل السنوات المالية في ERPNext، فهو ليس مضموناً بالكامل ضد العبث على مستوى قاعدة البيانات). (B) ممتاز – اللقطات غير قابلة للتغيير بعد أخذها (إذا تم تأمينها بشكل صحيح). لكن استرجاع البيانات أبطأ (يتطلب الاستعادة). (C) جيد – يمكن ضبط قاعدة بيانات الأرشيف لتكون للقراءة فقط للمستخدمين، وتُضاف إليها البيانات فقط عبر عمليات إدارية. طالما تم التحكم في الوصول، فهي عملياً سجل تاريخي append-only. ويمكن أيضاً تطبيق checksums أو فحوصات دورية لضمان سلامة الأرشيف.

سنتعمق أكثر في section 7 و9 في موضوعات الامتثال وعدم القابلية للتغيير (immutability)، والتي ترتبط بشكل مباشر بهذه النماذج.

النهج الهجينة (Hybrid approaches): من الجدير بالذكر أن بعض الاستراتيجيات تجمع بين B وC: على سبيل المثال، قد تقوم بأخذ لقطة كاملة كما في B، وأيضاً تحميل تلك البيانات إلى قاعدة بيانات أرشيف (C). وبهذه الطريقة تحتفظ بنسخة مجمّدة وأخرى قابلة للاستعلام. يتطلب ذلك جهداً أكبر وغالباً لا يكون ضرورياً، ولكن في الحالات شديدة التنظيم قد يتم الاحتفاظ بنسخة احتياطية “أصلية” للقراءة فقط ونسخة أخرى مريحة للاستعلام.

ولختم هذا القسم، فقد استعرضنا النماذج الأساسية الثلاثة:

1. الأرشفة ضمن نفس قاعدة البيانات (مع التقسيم): بسيطة، وتغيّر تجربة المستخدم بشكل طفيف جداً، لكنها تقدم تخفيفاً محدوداً في حجم قاعدة البيانات وقد تحمل بعض القيود من ناحية الامتثال.
2. الأرشفة المعتمدة على اللقطات (نسخة كاملة ثم حذف): فصل واضح للفترات، سهلة التنفيذ، وتقلل حجم قاعدة البيانات الحية إلى الحد الأقصى، لكنها تتطلب جهداً لاسترجاع البيانات المؤرشفة (مناسبة عندما يكون الاسترجاع نادراً).
3. قاعدة بيانات أرشيف منفصلة (مستمرة): تُبقي النظام الحي خفيفاً وتوفر وصولاً مستمراً إلى البيانات القديمة عبر نظام ثانٍ، لكنها تتطلب تنفيذاً وصيانة دقيقة.

غالباً ما يعتمد الخيار الأفضل على الحجم والمتطلبات: يبدأ الكثيرون بالنهج A، ثم ينتقلون إلى B أو C مع نمو البيانات وتشدد متطلبات الامتثال. سنقدّم خارطة طريق موصى بها في Section 10، والتي تقترح فعلياً استخدام هذه النماذج على مراحل.

6. استرجاع البيانات المؤرشفة (ERPNext-Focused)

بعد أرشفة البيانات باستخدام أحد النماذج أعلاه، كيف يمكن للمستخدمين أو الأنظمة استرجاع تلك البيانات التاريخية واستخدامها؟ يقيّم هذا القسم طرق الوصول إلى المعلومات المؤرشفة، مع التركيز بشكل خاص على قدرات ERPNext وحدوده في هذا السياق.

الوصول من داخل مثيل ERPNext (الأرشفة في نفس قاعدة البيانات): إذا اخترت النموذج A (الإبقاء على البيانات في نفس قاعدة البيانات، سواء بالتقسيم أو بالعلامات)، فإن استرجاع البيانات المؤرشفة يكون مباشراً – فهي لا تزال متاحة عبر واجهة ERPNext العادية، وربما تكون أبطأ فقط إذا لم تكن مقسّمة. يمكن للمستخدمين البحث عن السجلات القديمة وتشغيل تقارير لفترات سابقة كما يفعلون عادةً. الفرق الوحيد قد يكون وجود بعض القيود (مثل جعل البيانات للقراءة فقط بعد إغلاق السنة). ستشمل ميزات ERPNext القياسية (مثل تقرير General Ledger report أو Document search) تلك السجلات ما لم يتم استبعادها عبر عوامل تصفية. لذلك، في النموذج A لا توجد عملياً مشكلة في الاسترجاع – البيانات المؤرشفة هي بيانات حية.

الوصول عبر مثيل أرشيف منفصل (قاعدة بيانات أرشيف أو لقطات): بالنسبة للنموذجين B وC حيث يتم نقل البيانات خارج النظام الحي، فإن طرق استرجاع البيانات تشمل:

1. تشغيل مثيل ERPNext ثانوي للأرشيف: قد يكون لديك موقع ERPNext ثانٍ (ربما على نطاق مختلف أو خادم محلي) متصل بقاعدة بيانات الأرشيف. عند استخدام النموذج C (قاعدة أرشيف مستمرة)، يمكنك إعداد موقع ERPNext يشير إلى تلك القاعدة ويكون مهيأً بنفس إعدادات الإنتاج (ولكن للقراءة فقط للمستخدمين). عندها يمكن للمستخدمين تسجيل الدخول إلى “Archive ERPNext” لعرض السجلات القديمة. أما عند استخدام النموذج B (لقطات سنوية)، فيمكنك تشغيل موقع ERPNext من النسخة الاحتياطية عند الحاجة (على سبيل المثال، استعادة لقطة 2020 إلى مثيل ERPNext للإجابة على استفسار تدقيقي، ثم إيقافه بعد الانتهاء). ميزة استخدام واجهة ERPNext هي أن المستخدمين يرون البيانات بتنسيق مألوف (نماذج، تقارير). أما العيب فهو عبء إدارة عدة مثيلات واحتمال حدوث التباس (ستحتاج إلى فصلها بوضوح حتى يعرف المستخدمون أي نظام يستخدمون).
2. تقارير/استعلامات SQL مخصصة: يتيح ERPNext إنشاء Query Reports حيث تكتب SQL لجلب البيانات. إذا كانت البيانات المؤرشفة في نفس قاعدة البيانات (النموذج A) فيمكنك ببساطة الاستعلام عن تلك الجداول (مع عوامل التصفية المناسبة). وإذا كانت البيانات المؤرشفة في قاعدة بيانات مختلفة على نفس الخادم، فمن الناحية النظرية يمكنك تأهيل أسماء الجداول بالكامل في SQL (e.g., SELECT ... FROM archive_db.tabSales Invoice) – لكن مشغّل تقارير الاستعلام في ERPNext افتراضياً قد لا يسمح بالاستعلامات العابرة لقواعد البيانات لأسباب أمنية، كما يجب أن تسمح صلاحيات مستخدم قاعدة البيانات بذلك. عموماً، لا يُنصح بأن يقوم ERPNext الإنتاجي بتنفيذ استعلامات cross-DB أثناء التشغيل؛ فهذا يكسر عزل تعدد المواقع (multi-tenancy).
3. اتصالات مباشرة للقراءة فقط: أحد الأساليب الشائعة هو منح بعض المستخدمين المتقدمين (أو فريق تقنية المعلومات) اتصالاً مباشراً للقراءة فقط بقاعدة بيانات الأرشيف (للنموذج C أو للقطات المستعادة). يمكنهم حينها تشغيل استعلامات SQL أو استخدام أدوات مثل MySQL Workbench أو DBeaver لاستخراج البيانات. هذا مناسب فقط للمستخدمين التقنيين أو للاستجابات لطلبات محددة (مثل طلب مدقق لجميع المعاملات من النوع X في السنة Y – حيث يمكن لمسؤول قاعدة البيانات الاستعلام من قاعدة الأرشيف وتصدير النتائج إلى Excel أو PDF). يتجاوز هذا واجهة ERPNext بالكامل لكنه مباشر لاستخراج البيانات. عيبه أنه يتطلب شخصاً يعرف مخطط البيانات وكيفية الاستعلام عنه.
4. أدوات BI / التقارير: خيار قوي جداً هو استخدام أداة ذكاء أعمال أو حل تقارير مخصص يمكنه الاتصال بقاعدتي البيانات الحية والأرشيف. أدوات مثل Metabase وTableau وPowerBI أو حتى سكربتات Python مخصصة يمكن تهيئتها لجلب البيانات من مصدر الأرشيف. في الواقع، كان أحد اقتراحات المجتمع (كما رأينا) هو بناء data warehouse للبيانات التاريخية[6]. في هذا السيناريو، تستخدم أدوات BI لإنشاء تقارير على البيانات المؤرشفة. وقد يكون لدى المستخدمين لوحات معلومات منفصلة لـ “التقارير التاريخية”. هذا يخفف عبء الاستعلامات عن ERPNext بالكامل. وكما أشار أحد خبراء المنتدى، فإن بناء مستودع بيانات منفصل ليس أمراً بسيطاً، لكنه آمن، قابل للتوسع، ويتجنب تعقيدات مثيل ERPNext ثانٍ، ومشكلات التكرار، أو تغييرات المخطط أثناء الترقيات[6]. وبشكل عام، فإن أداة BI المتصلة بقاعدة بيانات الأرشيف توفر مرونة عالية في الاستعلام، ويمكنها حتى دمج البيانات مع النظام الحي عند الحاجة (بعض الأدوات يمكنها الاتصال بعدة مصادر بيانات ودمج النتائج خارج سياق قاعدة البيانات الأصلية).

قيود الاستعلامات العابرة لقواعد البيانات في ERPNext: لا يحتوي ORM في ERPNext على أي مفهوم مدمج لتعدد مصادر البيانات. فجميع استدعاءات frappe.get_list أو استعلامات التقارير تفترض اتصالاً واحداً بقاعدة بيانات مهيأة للموقع. وإذا حاولت تنفيذ join عابر لقواعد البيانات عبر SQL داخل سكربت خادم ERPNext، فستواجه مشكلات صلاحيات، كما أن الإطار لا يتوقع هذا النوع من الاستخدام. إضافةً إلى ذلك، يفرض إطار Frappe ضوابط أمان معينة – فقد يمنع استخدام أسماء قواعد البيانات في الاستعلامات أو لا يمتلك صلاحيات على مخططات أخرى. لذلك، لا يمكنك توجيه الاستعلامات ديناميكياً داخل موقع ERPNext واحد إلى قواعد بيانات مختلفة بناءً على، مثلاً، السنة المالية للبيانات. لا توجد ميزة مثل “إذا كانت السنة < 2018 فاستعلم من archive_db، وإلا فاستعلم من القاعدة الافتراضية”. تنفيذ هذا المنطق يدوياً في الكود لكل استعلام غير عملي.

لماذا لا يمكن لـ ERPNext توجيه الاستعلامات ديناميكياً: لأن ذلك سيتطلب أن يكون ERPNext على دراية بعدة قواعد بيانات وقادراً على دمج النتائج – أي تحويله فعلياً إلى محرك استعلامات اتحادي (federated query engine). وهذا يتجاوز بكثير تصميمه. يتوقع ERPNext وجود قاعدة بيانات واحدة لكل موقع تحتوي على كامل البيانات. وعندما تحتاج الشركات إلى فصل البيانات حسب المستأجر (tenant)، فإنها تستخدم عدة مواقع (عدة قواعد بيانات) دون تداخل. لا يوجد مفهوم لتقسيم أفقي لبيانات موقع واحد عبر عدة قواعد بيانات مع توجيه تلقائي؛ تنفيذ ذلك سيكون أشبه بمنطق sharding، وهو أمر غير موجود في ERPNext (وغالباً ما يُعالج على مستوى قاعدة البيانات أو بتخصيصات تطبيقية، وليس كميزة مدمجة).

إضافةً إلى ذلك، فإن التوجيه الديناميكي يعني أن أي تقرير أو نموذج يجب أن يعرف من أين يجلب البيانات – ما يعقّد الكود والتخزين المؤقت (caching)، وقد يخرق سلامة البيانات إذا لم يُنفذ بدقة. لذلك، فإن فلسفة الأرشفة عادةً هي: إزالة البيانات من النظام الرئيسي والتعامل معها كبيانات ثابتة في مكان آخر.

مقارنة طرق الاسترجاع:

1. ضمن ERPNext الرئيسي: سريع وسهل للمستخدم (استخدام ERPNext كالمعتاد). لكنه ممكن فقط إذا كان نموذج الأرشفة يُبقي البيانات في مكانها. لا يتطلب جهداً خاصاً.
2. مثيل ERPNext ثانٍ: سهل الاستخدام لأن الواجهة نفسها، لكنه يتطلب من المستخدمين تسجيل الدخول إلى موقع مختلف للبيانات القديمة. قد يسبب التباساً وعبئاً في الصيانة. ومع ذلك، يمكنك تطبيق أدوار قراءة فقط صارمة على هذا المثيل لضمان عدم تعديل أي شيء. وغالباً ستسميه بوضوح “Archive - Read Only”.
3. SQL مباشر أو Query Builder: تقني، وغير مناسب للمستخدمين النهائيين. جيد للطلبات العرضية لمرة واحدة، لكنه ليس حلاً للوصول اليومي من قبل موظفين غير تقنيين.
4. أدوات BI: ممتازة للإدارة والمحللين الذين لا يمانعون استخدام واجهة منفصلة للتقارير. لكنها ليست دقيقة بقدر واجهة ERP (على سبيل المثال، قد تعرض أداة BI المجاميع أو تسمح بالتحليل التفصيلي، لكن إذا أراد شخص رؤية نموذج فاتورة فعلي عمره 5 سنوات بجميع تفاصيله كما في ERPNext، فلن تقوم أداة BI بعرض نموذج ERPNext بتلك التفاصيل بشكل أنيق). تُستخدم أدوات BI أكثر للتحليل والملخصات بدلاً من البحث التفصيلي في المعاملات، ما لم يتم بناء تقارير تفصيلية جداً.

أمثلة على حالات الاستخدام:

1. يأتي مدقق ويطلب: “أرِني قيود اليومية لشهر يناير 2017 للحساب X.” إذا كان لديك النموذج B (snapshot)، فمن المحتمل أن تقوم باستعادة أرشيف 2017 إلى بيئة اختبار أو الاستعلام عنه مباشرة. إذا كان لديك النموذج C (archive DB)، فيمكنك تنفيذ استعلام على قاعدة بيانات الأرشيف أو استخدام موقع ERPNext للأرشيف لفتح التقرير لشهر يناير 2017. أما إذا كان لديك النموذج A (all in one)، فستقوم ببساطة بتشغيل التقرير على النظام الحي (إذا لم تكن قد حذفته).
2. يرغب مستخدم في عرض فاتورة قديمة من خلال الواجهة. في النموذج B، سيتعين على شخص ما جلبها من نسخة احتياطية (وقد لا يكون ذلك ممكنًا للمستخدم نفسه). في النموذج C، ربما يمكنه تسجيل الدخول إلى موقع الأرشيف، البحث عن الفاتورة وعرضها. في النموذج A، يكفي العثور عليها في النظام الحي (إذا لم تتم إزالتها).
3. تحليل تاريخي مجمع: على سبيل المثال، اتجاه المبيعات من 2015 إلى 2025. في النموذج A، يمكنك نظريًا تشغيل تقرير واحد كبير (لكن قد ينتهي بمهلة زمنية إذا كان ضخمًا). في النموذج B أو C، قد تستخدم مستودع بيانات أو تقوم بتصدير البيانات السنوية إلى Excel ثم دمجها. يمكن لحل BI مصمم جيدًا أن يتصل بالأرشيف والنظام الحي وينتج خط اتجاه موحد (قد تكون هناك حاجة لبعض عمليات ETL لتوحيدها إذا اختلفت البُنى أو لأغراض التجميع).

تشغيل التقارير خارج ERPNext: في العديد من البيئات المؤسسية، يتم في النهاية نقل التقارير التاريخية الأساسية إلى مستودع بيانات أو على الأقل إلى خادم قاعدة بيانات للقراءة فقط يحتوي على نسخة من البيانات. تقارير ERPNext المدمجة مناسبة للاحتياجات التشغيلية، لكن للتحليل متعدد السنوات، قد يكون نظام تقارير خارجي أكثر كفاءة. على سبيل المثال، يمكن ربط قاعدة بيانات الأرشيف بخادم تقارير يحتوي على استعلامات SQL مُعدة مسبقًا أو حتى أداة تقارير مفتوحة المصدر حيث يمكن للمستخدمين غير التقنيين تشغيل استعلامات محددة مسبقًا على الأرشيف. هذا يتجنب منحهم وصولًا مباشرًا إلى قاعدة البيانات، كما يتجنب الحاجة إلى واجهة ERPNext كاملة (والتي قد تكون ثقيلة الصيانة لمجرد استعلامات للقراءة فقط).

ملخص القيود:

1. ERPNext (مثيل واحد) لن يتعامل تلقائيًا مع البيانات الموزعة عبر قواعد بيانات متعددة. لذلك، أي حل يقوم بنقل البيانات إلى خارج النظام يعني عمليًا أن تلك البيانات لن تكون قابلة للوصول من واجهة موقع ERPNext الأصلي.
2. إذا حاولت استخدام ميزة “Virtual DocType” في Frappe (والتي تسمح بإنشاء DocTypes تقوم بجلب البيانات من مصدر خارجي عبر API أو استعلام)، فهذا حل متقدم ممكن: يمكن إنشاء DocType افتراضي يجلب البيانات من قاعدة بيانات الأرشيف. لكن الأداء والتعقيد قد يفوقان الفائدة، كما أنها ليست مستخدمة على نطاق واسع لربط بيانات ضخمة بهذا الشكل.
3. عمليات الربط بين قواعد بيانات مختلفة على مستوى SQL (إذا كان الأرشيف على نفس خادم MySQL) ممكنة لكنها معقدة من ناحية الأمان. كما أنها تكسر نموذج العزل متعدد المستأجرين، والربط الثقيل بين جداول أرشيفية ضخمة وجداول حية قد يؤثر سلبًا على الأداء (وهو ما يتعارض مع الهدف من الأرشفة لتخفيف الحمل).

الأمان والحوكمة: عند منح الوصول إلى البيانات المؤرشفة، يجب أيضًا مراعاة أن الأرشيف قد يحتوي على معلومات حساسة ولا يحصل على نفس مستوى العناية (مثل فحوصات صلاحيات المستخدم) التي يوفرها ERPNext الحي. على سبيل المثال، في ERPNext الحي، قد يُسمح للمستخدم فقط برؤية مستندات قسمه. إذا تم منحه تقريرًا مبنيًا على SQL من الأرشيف، فإن ذلك يتجاوز تلك الضوابط. لذلك، غالبًا ما تقيّد المؤسسات الوصول إلى الأرشيف بأدوار معينة (مثل مديري المالية أو تقنية المعلومات فقط). وإذا قمت بإعداد مثيل ERPNext ثانٍ للأرشيف، فيجب عليك تكرار هيكل صلاحيات المستخدمين أو على الأقل قصر الوصول على من يحق لهم رؤية البيانات التاريخية. في كثير من الحالات، قد يكون المستخدمون عددًا محدودًا من المستخدمين المتقدمين أو المدققين فقط.

تدريب المستخدمين والإجراءات: من المفيد توثيق كيفية طلب المستخدمين أو استرجاعهم للبيانات المؤرشفة. ربما سياسة تنص على أن “أي بيانات أقدم من 5 سنوات، يرجى التواصل مع قسم تقنية المعلومات أو فتح موقع Archive ERPNext”. التواصل الواضح وربما أداة بحث بسيطة يمكن أن يساعدا كثيرًا. على سبيل المثال، يمكنك تطوير صفحة ويب داخلية بسيطة حيث يقوم المستخدم بإدخال رقم فاتورة أو معرف مستند، فتبحث في قاعدة بيانات الأرشيف وتعيد ملف PDF أو التفاصيل – مما يجنبهم تعلم SQL أو التعامل مع أنظمة متعددة.

في الختام، يتطلب استرجاع البيانات المؤرشفة إما استخدام أدوات منفصلة أو مثيلات ERPNext منفصلة، لأن موقع ERPNext الأساسي لن يخدم تلك البيانات إذا تمت إزالتها. يجب على المؤسسات اختيار طريقة الاسترجاع التي توازن بين سهولة الاستخدام وتكرار الحاجة إلى الوصول. إذا كانت عمليات التدقيق نادرة، فإن الاستعلام اليدوي كافٍ. أما إذا كان المستخدمون يحتاجون إلى معلومات قديمة بشكل متكرر، فإن ERPNext للأرشيف أو بوابة تقارير تستحق الجهد.

7. إصدارات ERPNext القديمة والحفظ طويل الأمد للبيانات (قسم بالغ الأهمية)

على مدى سنوات أو عقود طويلة، سيمر ERPNext بالعديد من الإصدارات، وستتراكم بياناتك تحت إصدارات برمجية مختلفة. قد يتطلب الحفظ طويل الأمد للبيانات التعامل مع بيئات ERPNext قديمة. هنا نناقش عدة استراتيجيات لضمان بقاء البيانات التاريخية قابلة للوصول والتحقق، مع مراعاة اختلاف إصدارات البرمجيات والحاجة إلى موثوقية السجلات القديمة.

A. حفظ صورة كاملة للخادم (تجميد النظام القديم): تتضمن هذه الاستراتيجية الاحتفاظ بلقطة كاملة لبيئة نظام ERPNext بالكامل كما كانت خلال الفترة الزمنية المعنية. على سبيل المثال، إذا قمت بإيقاف ERPNext v12 بعد الانتقال إلى v14، فقد تحتفظ بصورة VM أو خادم تحتوي على ERPNext v12 وFrappe وقاعدة البيانات بجميع البيانات حتى تلك النقطة، وحتى نظام التشغيل مهيأ كما كان. وبشكل أساسي، تقوم بتجميد نسخة من التطبيق مع بياناتها في الزمن.

الإيجابيات:

1. دقة 100%: بما أنه لم يتم تغيير أي شيء، فإن هذا النظام المحفوظ سيعرض البيانات تمامًا كما رآها المستخدمون في ذلك الإصدار من ERPNext. ستبقى الواجهة والتقارير والسلوكيات كما هي – ما يعني أنه حتى لو كانت طرق الحساب أو الواجهات مختلفة آنذاك، فستتوفر لديك تلك البيئة نفسها. قد يكون هذا أمرًا بالغ الأهمية لأسباب تدقيقية أو قانونية: إذ يمكنك إثبات ما كان سيشاهده مدقق في عام 2021 داخل النظام، على سبيل المثال.
2. عدم وجود مخاطر ترحيل: لا تقوم بلمس البيانات القديمة أو محاولة تحويلها لأنظمة أحدث. هذا يتجنب أي خطر تلف البيانات بسبب الترحيل. إذا كان النظام القديم يحتوي على أخطاء أو ميزات معينة أثرت على كيفية تخزين البيانات أو حسابها، فستبقى تلك كما هي (للأفضل أو للأسوأ)، وقد يكون ذلك مهمًا لتفسير الأرقام التاريخية.
3. عزل تشغيلي: يمكن إيقاف تشغيل الصورة القديمة وتخزينها. ولن تتداخل مع نظامك الحالي. يكون خطر الأمان منخفضًا إذا كانت غير متصلة (وسيتم التطرق لذلك في السلبيات إذا تم إبقاؤها قيد التشغيل).

السلبيات:

1. الصيانة وتلف الزمن (Bit-Rot): إذا احتجت في أي وقت إلى تشغيل تلك الصورة، فستحتاج إلى منصة قادرة على تشغيلها (hypervisor، إلخ). إذا كانت VM تحتوي مثلًا على Ubuntu 18 وERPNext v12، فبعد خمس سنوات يجب التأكد من توفر البرمجيات اللازمة لتشغيل تلك VM. عادة لا تكون مشكلة كبيرة عند استخدام تقنيات افتراضية قياسية (VMWare، VirtualBox، إلخ، أو لقطات سحابية). ولكن إذا كانت تعتمد على إصدارات قديمة من التبعيات (Python، Node، إلخ)، فيجب الحفاظ على تلك البيئة كاملة. كما أنه إذا بقيت مطفأة لفترة طويلة، قد تكتشف مشكلات عند تشغيلها لاحقًا (مثل انتهاء صلاحية الشهادات، أو اتصالها بخدمات خارجية لم تعد تعمل).
2. مخاطر أمنية إذا بقيت قيد التشغيل: نظام ERPNext قديم (خصوصًا الإصدارات الأقدم) لن يتلقى تصحيحات أمنية بعد EOL. إذا أبقيته قيد التشغيل على شبكة (حتى داخلية)، فقد يكون عرضة للهجمات. من الأفضل الاحتفاظ بصور الخوادم الكاملة غير متصلة أو على شبكة معزولة عندما لا تكون قيد الاستخدام الفعلي. وعند وقت التدقيق، يمكن تشغيلها مؤقتًا، ولكن حتى حينها يجب توخي الحذر (مثل حظر الاتصال بالإنترنت الخارجي، إلخ). تشغيل نظام قديم بشكل مستمر أمر محفوف بالمخاطر.
3. تكلفة البنية التحتية: الاحتفاظ بخوادم قديمة (مادية أو افتراضية) له تكلفة، رغم أن VM يمكن أرشفتها كملفات بتكلفة منخفضة. قد يختار البعض الاحتفاظ بها “على الرف” (بالمعنى المجازي) وتحميلها على hypervisor فقط عند الحاجة. يتيح مزودو الخدمات السحابية الاحتفاظ بلقطات VM بتكلفة منخفضة ضمن التخزين البارد.

حالات الاستخدام: يُستخدم هذا الأسلوب غالبًا من قبل المؤسسات التي تقوم بتغيير أنظمتها؛ على سبيل المثال، عند الانتقال من نظام ERP إلى آخر، يتم الاحتفاظ بصورة النظام القديم لمدة X سنوات للرجوع إليها. وفي سياق الاستمرار في ترقيات ERPNext، قد تستخدم هذا الأسلوب عندما يكون لديك تغيير جوهري في المخطط أو الوحدات. على سبيل المثال، إذا قام ERPNext v17 بإعادة تصميم كاملة لكيفية عمل وحدة معينة، فقد تحتفظ بمثيل v16 لعرض البيانات القديمة بصيغتها القديمة. كما أنه مفيد في القطاعات عالية التنظيم؛ فمثلًا، قد تتطلب قطاعات مثل البنوك أو الرعاية الصحية القدرة على تقديم السجلات تمامًا كما تم التقاطها في الأصل، بما في ذلك البرنامج نفسه. وفي النزاعات القانونية، يمكن أن يعمل النظام الأصلي كدليل.

فكّر في الأمر على أنه شبيه بالاحتفاظ بجهاز كمبيوتر قديم يمكنه قراءة صيغة بيانات مملوكة لأن أجهزة الكمبيوتر الجديدة لم تعد تدعمها. هنا، الصيغة المملوكة هي مزيج البيانات + التطبيق.

من منظور الحوكمة، إذا اعتمدت هذا النهج، فيجب توثيقه ضمن السياسات: على سبيل المثال، “بعد إيقاف كل إصدار رئيسي من ERPNext، سنقوم بتحويل النظام القديم إلى حاوية أو أخذ لقطة snapshot له والاحتفاظ به لمدة 10 سنوات.” ويجب ضمان إجراء عمليات تشغيل اختبارية دورية للتحقق من أن الصورة تعمل.

B. مثيل ERPNext منفصل للبيانات المؤرشفة (مثيل قديم مستمر): يشبه هذا النهج أسلوب قاعدة بيانات الأرشيف المنفصلة، لكنه يركز على الاحتفاظ بمثيل تطبيق ERPNext للتعامل مع البيانات المؤرشفة. وبشكل أساسي، يكون لديك موقعان لـ ERPNext يعملان بالتوازي: أحدهما على أحدث إصدار للعمليات الحالية، والآخر على إصدار أقدم ثابت يحتوي على جميع السجلات التاريخية (للقراءة فقط).

على سبيل المثال، لنفترض أنه في عام 2030 تستخدم ERPNext v20 للاستخدام اليومي، ولكن لديك موقع ERPNext v15 يعمل ويحتوي على جميع البيانات حتى عام 2025 ويعمل كبوابة أرشيف. قد يتم تهيئة موقع v15 لمنع أي إنشاء أو تعديل للمستندات (ربما عن طريق تعيين جميع المستخدمين لأدوار للقراءة فقط أو تخصيص الكود لتعطيل الكتابة). وغالبًا ما يعمل على نطاق فرعي أو خادم منفصل ويتم وسمه بشكل واضح.

الإيجابيات:

1. سهولة الوصول للمستخدم: يمكن للمستخدمين (مع الصلاحيات المناسبة) تسجيل الدخول إلى ERPNext للأرشيف واستخدام الواجهة المألوفة للبحث عن المستندات أو عرضها. كما يمكنهم تشغيل التقارير على تلك البيانات باستخدام التقارير المدمجة في ذلك الإصدار. وهذا أسهل بكثير للمدقق أو المستخدم العادي مقارنة بإجبارهم على استخدام SQL أو أدوات غير مألوفة.
2. تثبيت الإصدار: أنت تتعمد عدم ترقية مثيل الأرشيف بعد إصدار معين، وبالتالي تتجنب أي مخاطر قد تنشأ من تغييرات التحديثات على تمثيل البيانات التاريخية. يكون النظام مستقرًا وثابتًا. وفي الوقت نفسه، يمكن لمثيل الإنتاج الاستمرار في التقدم دون حمل كامل التاريخ معه.
3. الحوكمة: يمكنك فرض أن يكون مثيل الأرشيف للقراءة فقط من خلال السياسات والتقنيات. على سبيل المثال، يمكن إبقاؤه في وضع يسمح فقط لمجموعة محدودة من المستخدمين بتسجيل الدخول، وحتى هؤلاء لا يمتلكون صلاحيات الإنشاء أو الحذف. وقد تقوم بإزالة جميع مشغلات سير العمل والبريد الإلكتروني ليكون النظام سلبيًا. وبشكل أساسي، يكون بمثابة مكتبة مرجعية للسجلات القديمة.
4. فصل الاهتمامات: يمكن ضبط مثيل الأرشيف بشكل مختلف. ربما يتم تشغيله على عتاد أقل تكلفة لأنه غير حرج للمهام (على افتراض أن عددًا قليلاً فقط من الأشخاص يصلون إليه في نفس الوقت). وإذا تعطل، فلن تتأثر عملياتك الرئيسية – يمكنك استعادته بشكل منفصل. كذلك، إذا قام شخص ما بتشغيل تقرير ضخم على بيانات الأرشيف وأبطأ ذلك الخادم، فلن يؤثر ذلك على ERPNext الرئيسي.

السلبيات:

1. العبء على الموارد: تقوم بصيانة نظامين لـ ERPNext، ما يعني مجموعتين من مهام الصيانة (النسخ الاحتياطي، إدارة المستخدمين، إلخ). وحتى لو كان الأرشيف ثابتًا إلى حد كبير، فلا يزال يتعين التأكد من أمانه (تطبيق تحديثات نظام التشغيل، إلخ، حتى لو لم يتم ترقية تطبيق ERPNext نفسه).
2. الأمان: كما ذُكر، إذا كان يعمل على إصدار ERPNext أقدم، فقد توجد ثغرات معروفة. يجب عليك التخفيف من ذلك (بعزله على الشبكة، أو تشغيله فقط عند الحاجة، أو الاعتماد على كون الوصول الداخلي محدودًا). قد تفكر في ترقيته ضمن نفس الإصدار الرئيسي لتطبيق تصحيحات أمنية دون الانتقال إلى إصدارات رئيسية جديدة تغيّر البيانات. ومع ذلك، بمجرد وصول v15 إلى EOL، لن تكون هناك تصحيحات رسمية – وبالتالي تعتمد إما على تصحيحات المجتمع أو على نهج العزل.
3. مزامنة البيانات: إذا كنت تخطط للاستمرار في إضافة بيانات إلى مثيل الأرشيف (مثل نقل المزيد من البيانات إليه كل عام)، فستحتاج إلى عملية لترحيل البيانات من مثيل الإنتاج (على إصدار أعلى) إلى مثيل الأرشيف (إصدار أقدم). وهذا أمر معقد – فقاعدة بيانات الإصدار الأحدث قد لا تكون قابلة للاستيراد مباشرة إلى كود الإصدار الأقدم. على سبيل المثال، إذا تغيّر مخطط Sales Invoice بين v15 وv20، فلا يمكنك ببساطة نسخ الصفوف من قاعدة بيانات v20 إلى قاعدة بيانات v15 دون فقدان أو تحويل المعلومات. إحدى الاستراتيجيات للتخفيف من ذلك هي ترقية مثيل الأرشيف بالتوازي حتى نقطة الفصل، ثم تجميده. على سبيل المثال، تقوم بتشغيل موقع ERPNext واحد عبر v16 وv17 وv18 كالمعتاد، ثم في عام 2025 تقرر تجميد الأرشيف، فتقوم بنسخ قاعدة البيانات وتصبح تلك النسخة هي الأرشيف (متوقفة عند v18)، ثم تقوم بترقية النظام الرئيسي إلى v19+. بعد ذلك، لا تحاول إدخال بيانات v19+ إلى الأرشيف (لأن الأرشيف لا يعرف تلك التغييرات). وبذلك، سيحتوي الأرشيف على جميع البيانات حتى نقطة التجميد فقط، ولا شيء بعدها. وإذا أردت الاستمرار في الأرشفة بعد نقطة التجميد، فقد يكون من الأفضل الاكتفاء بقاعدة بيانات أرشيف دون تطبيق، أو التخطيط لإنشاء مثيلات جديدة بشكل دوري لكل فترة زمنية (وهو ما يشبه وجود عدة مثيلات قديمة لعصور مختلفة).
4. ارتباك المستخدمين: يجب على المستخدمين معرفة أين يبحثون. إذا لم يتمكن موظف من العثور على سجل في النظام الحي ولم يدرك أن السبب هو أنه تم أرشفته، فقد يفتح تذكرة دعم. يساعد التدريب وربما تلميحات في الواجهة (على سبيل المثال، بعد عام 2025، قد تظهر ملاحظة على الشاشة تقول “للسجلات قبل 2023، استخدم Archive ERPNext”).

عمليًا، يُعد وجود موقع ERPNext منفصل للأرشيف حلًا مناسبًا للشركات متوسطة الحجم حيث يحتاج المدققون أو المستخدمون أحيانًا إلى استرجاع سجلات قديمة. فهو يضمن استمرارية الوصول مع حد أدنى من التدريب، مقابل تكلفة تشغيل برمجيات قديمة. وقد يستخدمه الكثيرون لنافذة بيانات تتراوح بين 5 إلى 10 سنوات.

C. ترحيل البيانات القديمة إلى إصدارات ERPNext الجديدة: تمثل هذه الاستراتيجية عكس التجميد – فبدلًا من ذلك، تقوم بأخذ بياناتك المؤرشفة أو القديمة واستيرادها أو ترقيتها إلى إصدار ERPNext الحالي، بحيث تعيش جميع البيانات في النظام الأحدث. وقد يعني ذلك:

1. تشغيل عملية الترقية/الترحيل القياسية على نسخة احتياطية قديمة لنقلها إلى أحدث إصدار. على سبيل المثال، لديك قاعدة بيانات أرشيف من v12. تقوم بتثبيت ERPNext v16 وتشغيل bench migrate على تلك القاعدة القديمة، مرورًا بالترقيات الوسيطة (v13 وv14، إلخ) حتى تصبح على مخطط v16. عندها يمكنك نظريًا دمجها مع القاعدة الحالية أو الاحتفاظ بها كموقع منفصل على نفس الإصدار.
2. أو تصدير البيانات من النظام القديم وإعادة استيرادها إلى النظام الجديد كسجلات تاريخية. يشبه هذا إلى حد كبير مشروع ترحيل بيانات – حيث يتم تعيين الحقول القديمة إلى الحقول الجديدة. على سبيل المثال، إذا أعاد ERPNext تصميم وحدة معينة، فقد تكتب سكربتات لملء جداول الوحدة الجديدة بالبيانات القديمة بطريقة تسمح بإعداد التقارير عليها.

المخاطر والتحديات:

1. تغييرات المخطط والميزات: يمكن لـ ERPNext تغيير طريقة هيكلة الأمور. إذا حاولت ترحيل البيانات عبر إصدارات رئيسية متعددة دفعة واحدة، فقد تحدث حالات فشل. غالبًا ما يتطلب الأمر المرور عبر كل إصدار رئيسي بشكل تسلسلي (وهو أمر يستغرق وقتًا وقد يتطلب تثبيت إصدارات وسيطة). ومع وجود كميات كبيرة من البيانات، قد تكون كل خطوة ترحيل ثقيلة. كما توجد مخاطر فشل سكربتات الترحيل عند مواجهة حالات بيانات قديمة غير متوقعة. هذا الأسلوب معرّض للأخطاء — وسيتعين عليك اختبار العملية بعناية للتأكد من أن جميع البيانات انتقلت بشكل سليم.
2. تغييرات سلوكية: حتى إذا تم ترحيل البيانات، فقد يختلف تفسير النظام الجديد لها. على سبيل المثال، قد تتغير طريقة احتساب الضرائب في إصدار لاحق — وعند فتح فواتير قديمة في الإصدار الجديد قد تتم إعادة احتساب الضرائب تلقائيًا بشكل مختلف (إذا تم تشغيل المشغلات)، مما قد يسبب ارتباكًا (“لماذا تظهر فاتورة من عام 2015 بإجمالي مختلف الآن؟”). بشكل عام، لا تتم إعادة الحساب عند فتح المستندات المُعتمدة، ولكن إذا حاولت إعادة اعتمادها أو تعديلها، فقد تمنع قواعد التحقق الجديدة ذلك لأنها لم تكن مستوفاة في البيانات القديمة.
3. اختلافات التقارير: قد لا تتطابق الملخصات أو التقارير المالية تمامًا مع ما كان يظهر في الأصل إذا تغير منطق الكود. يمكن أن يؤدي ذلك إلى مشكلات تدقيقية — ويجب توخي الحذر في توضيح أن هذه بيانات مُرحّلة معروضة وفق منطق حالي قد يكون مختلفًا قليلًا.
4. الجهد مقابل الفائدة: إن إجراء ترحيل كامل للبيانات المؤرشفة يعني عمليًا حمل كامل تاريخك معك باستمرار. قد يكون ذلك جهدًا ضخمًا بعائد متناقص إذا كانت تلك البيانات نادرًا ما تُستخدم. وقد يكون مبررًا فقط إذا كنت — على سبيل المثال — تحتاج إلى إعداد تقارير تحليلية عبر كامل التاريخ داخل النظام الجديد، أو إذا كانت اللوائح تتطلب وجود جميع البيانات في النظام الحالي.

متى يكون الترحيل مبررًا؟ إذا لم تكن بيانات الأرشيف كبيرة جدًا وكانت الفروقات طفيفة، فقد تقرر دمجها. على سبيل المثال، إذا كان لديك مثيل v10 منفصل لشركة تابعة وتريد جلب تلك البيانات إلى ERPNext v16 الرئيسي لإعداد تقارير موحدة، فقد تسلك مسار ترحيل. أو إذا كان نشاطك التجاري يحتاج بشكل حتمي إلى تحليل اتجاهات على مدى 15 سنة داخل ERPNext نفسه (ربما لأغراض AI أو غير ذلك)، فستفكر في تحميلها.

بديلًا عن ذلك، إذا كنت بصدد إيقاف نظام أرشيف وترغب في توحيد كل شيء، فقد تقوم باستيراد لمرة واحدة للبيانات القديمة كسجلات للقراءة فقط (ربما مع تمييزها بطريقة ما).

عمومًا، يُعد ترحيل البيانات القديمة إلى الإصدارات الجديدة أقل شيوعًا بسبب المخاطر والجهد. وبدلًا من ذلك، تميل الشركات إلى إبقاء البيانات القديمة منفصلة. ويشير القائمون على ERPNext أنفسهم إلى أن الإصدارات الرئيسية تحتوي على تغييرات كاسرة، وأنهم يدعمون فقط الترقيات التسلسلية[4] دون تخطي الإصدارات، ما يعني أن ترحيل مثيل عمره 10 سنوات إلى الوقت الحالي ممكن ولكنه مهمة كبيرة. ومع ذلك، فهو قابل للتنفيذ مع تخطيط دقيق (أخذ نسخ احتياطية في كل خطوة، وتطبيق أي إصلاحات مخصصة مطلوبة، إلخ).

D. استراتيجية هجينة (استكشاف موصى به): في الواقع، قد تستخدم المؤسسة مزيجًا من الاستراتيجيات السابقة لشرائح مختلفة من خطها الزمني للبيانات. ومن الأمثلة على نهج هجين معقول:

1. الأرشيفات الحديثة (شبه القديمة): الاحتفاظ بها على إصدارات أحدث أو حتى مدمجة. على سبيل المثال، الحفاظ على مثيل ERPNext للأرشيف لآخر 5-7 سنوات من البيانات وإبقاؤه مُحدّثًا إلى إصدار غير بعيد عن الإصدار الرئيسي. أو ربما تقرر الإبقاء على بيانات 2018 حتى الحاضر في النظام الرئيسي (مع التقسيم)، وأرشفة ما قبل 2018 في نظام قديم.
2. البيانات القديمة جدًا: للبيانات الأقدم من حد معين (ربما بعد فترة الاحتفاظ القانونية، أو من نظام قديم جدًا لا يستحق الترحيل)، استخدم حفظ الصورة الكاملة أو حتى الاستخراج إلى مستودع بيانات أو ملفات ثابتة. قد تكون هذه بيانات نادرًا ما تُطلب إلا في نزاع قانوني. يمكنك الاحتفاظ بها في VM نادر التشغيل أو حتى الاحتفاظ فقط بتفريغات قواعد البيانات ونسخة من كود ERPNext، مع الثقة بإمكانية إحيائها عند الحاجة.

معايير قرار واضحة:

1. تكرار الوصول: البيانات التي قد يتم الوصول إليها أحيانًا من قبل مستخدمي الأعمال (مثل آخر 5-10 سنوات لتحليل الاتجاهات أو لخدمة العملاء) تستحق الاحتفاظ بها في صيغة سهلة الوصول (مثل نظام أرشيف يعمل أو مُرحّلة إلى النظام الحالي). أما البيانات الأقدم من ذلك، والتي قد لا تُطلب إلا نادرًا جدًا من قبل التدقيق، فيمكن الاحتفاظ بها بصيغة أبرد وأكثر تقنية (مثل VM أو تفريغات).
2. المتطلبات التنظيمية: إذا كان القانون ينص على أن 7 سنوات يجب أن تكون متاحة فورًا للتدقيق، فيجب التأكد من أن تلك السنوات السبع موجودة إما في النظام الحي أو في مثيل أرشيف يمكن للمدققين استخدامه. وأي شيء أقدم يمكن أن يكون ضمن صور قديمة.
3. تغييرات النظام: إذا أدخل إصدار معين من ERPNext تغييرات كبيرة ولا ترغب في تشغيل ذلك الإصدار القديم بعد الآن، فقد تكون تلك نقطة مناسبة لأخذ snapshot والتوقف، بدل محاولة الاستمرار في الترقية. على سبيل المثال، إذا قام ERPNext v17 بتغيير كبير في محرك قاعدة البيانات أو أمر جوهري آخر، فقد تجمّد مثيلًا عند v16 بالبيانات القديمة وتوجّه البيانات الجديدة فقط إلى v17.
4. البنية التحتية والمهارات: صيانة الأنظمة القديمة تتطلب الحفاظ على المعرفة أو التوثيق لكيفية تشغيلها. إذا كان فريقك صغيرًا، فقد يكون وجود عدة مثيلات قديمة عبئًا — وعندها يكون الدمج في أرشيف واحد أو الترحيل إلى الجديد أبسط على المدى الطويل. وعلى العكس، إذا كان الترحيل معقدًا جدًا، فستختار التجميد.

مثال على سيناريو هجين:

1. تحتفظ الشركة بمثيل ERPNext للأرشيف مُحدّثًا حتى عام 2030 ويحتوي على بيانات من 2020 إلى 2025. بعد عام 2030، يتم تجميد ذلك المثيل عند v20، ويتم إنشاء مثيل أرشيف جديد لبيانات 2025-2030 إذا لزم الأمر، أو تقرر الإبقاء على بيانات 2025-2030 في النظام الرئيسي حتى عام 2035، وهكذا. وفي الوقت نفسه، تكون البيانات قبل 2020 من نظام أقدم بكثير، لذا يتم الاحتفاظ بها فقط ضمن VM لذلك النظام القديم.
2. أو: تمتلك الشركة ERPNext رئيسيًا يحتوي على 5 سنوات من البيانات، وERPNext للأرشيف (للقراءة فقط) يحتوي على الخمس سنوات السابقة، وأي بيانات أقدم من 10 سنوات يتم تخزينها في مستودع بيانات أو تخزين ملفات (مثل صادرات CSV أو سجلات PDF للامتثال) والتي تُعتبر “أرشيفًا عميقًا”.

الخلاصة هي تحديد العتبات: على سبيل المثال، “البيانات التشغيلية = آخر 3 سنوات (وصول سريع)، بيانات الأرشيف = 3-10 سنوات (متاحة عبر Archive ERPNext)، الأرشيف العميق القديم = >10 سنوات (محفوظة في snapshots أو بصيغة مُصدّرة).”

هذا يلبّي معظم متطلبات التدقيق (نظرًا لأن معظم اللوائح تحدد فترات الاحتفاظ بنحو 7-10 سنوات[13][13]) ويحافظ على عبء النظام ضمن حدود يمكن إدارتها.

أخيرًا، يجب إعادة التقييم بشكل دوري: فمع مرور السنوات، ستقوم بترحيل ما كان يُعد “حديثًا” إلى “الأرشيف”، وما كان “أرشيفًا” إلى “قديم (legacy)”. لذلك، فإن وجود خارطة طريق (كما هو موضح في نهج المراحل في القسم 10) يضمن التعامل مع هذا الانتقال بسلاسة في كل مرة وبأقل قدر ممكن من الاضطراب.

8. مقارنة خيارات البنية المعمارية

لتلخيص الاستراتيجيات التي تمت مناقشتها، فيما يلي مقارنة بين خيارات معمارية مختلفة لإدارة بيانات ERP على المدى الطويل. سنقارنها بناءً على عوامل رئيسية مثل التعقيد، والتكلفة، وقابلية التوسع، وجاهزية التدقيق، والمخاطر التشغيلية:

ملاحظات حول المقارنة: يمكن لكل نهج أن يكمل غيره (حلول هجينة). على سبيل المثال، قد يتم استخدام التقسيم في جميع الحالات للمساعدة في إدارة أحجام قواعد البيانات. أو استخدام مستودع بيانات بالإضافة إلى أساليب أرشفة أخرى لتقارير أكثر مرونة.

من الجدول:

1. التعقيد: أبسط خيار للتنفيذ هو المثيل الواحد مع التقسيم (لا يوجد نظام جديد، فقط مهام DBA). جميع الخيارات الأخرى تزيد التعقيد بسبب تعدد الأنظمة أو العمليات.
2. التكلفة: بشكل عام، كلما زاد عدد الأنظمة زادت التكلفة. أسلوب snapshot يترتب عليه في الغالب تكلفة تخزين فقط (وهي منخفضة مقارنة بتكلفة نظام حي). أما مستودع البيانات فعادة ما يكون الأعلى تكلفة بسبب البنية التحتية الإضافية وربما البرمجيات.
3. قابلية التوسع: يتفوق مستودع البيانات هنا لأنه مُصمم خصيصًا للبيانات الضخمة. المثيلات المزدوجة وsnapshot تُبقي المثيل الحي خفيفًا، وهو أمر إيجابي. أما المثيل الواحد فقد يصل في النهاية إلى حدود التوسع العمودي.
4. جاهزية التدقيق: أعلى مستوى ثقة تدقيقية يتحقق عندما تكون البيانات مقفلة وغير قابلة للتعديل. المثيل القديم المجمّد وsnapshot يوفّران هذه الثباتية على حساب سهولة الاستخدام[13]. يمكن للمثيلات المزدوجة تحقيق الثباتية إذا تم ضبط الأرشيف للقراءة فقط والتحكم به جيدًا (لكن البرنامج المشغّل قد لا يفرض كل القيود مثل منع الحذف ما لم تتم إزالة تلك الصلاحيات). أما مستودع البيانات فيمكنه الاحتفاظ بكامل التاريخ، لكنه كونه نسخة، فإن إثبات الأصالة قد يتطلب أدلة إضافية (مثل checksums أو سجلات من المصدر الأصلي).
5. المخاطر التشغيلية: مع زيادة عدد الأجزاء المتحركة، ترتفع مخاطر الخطأ (مثل أخطاء المزامنة، وصيانة نظامين، إلخ). المثيل الواحد لديه أجزاء أقل لكنه يحمل مخاطر نقطة فشل واحدة وحمل مرتفع. أما نهج التجميد فله مخاطر تشغيلية مستمرة منخفضة، لكنه يحمل خطرًا كبيرًا إذا اكتشفت يومًا أن الـ VM لا يقلع بينما تكون بحاجة ماسة إليه.

أخيرًا، يجب إجراء إعادة تقييم دورية: فمع مرور السنوات، ستقوم بترحيل ما كان يُعد “حديثًا” إلى “الأرشيف”، وما كان “أرشيفًا” إلى “قديم (legacy)”. لذلك، فإن وجود خارطة طريق (كما هو موضح في نهج المراحل في القسم 10) يضمن التعامل مع هذا الانتقال بسلاسة في كل مرة وبأقل قدر ممكن من الاضطراب.

9. الحوكمة، التدقيق والامتثال

إن إدارة البيانات المالية وبيانات ERP على المدى الطويل ليست مجرد تحدٍ تقني — بل تحكمها اللوائح والمتطلبات التدقيقية. هنا نوضح لماذا يُعد وجود بيانات تاريخية غير قابلة للتغيير أمرًا بالغ الأهمية، وكيفية فرض حوكمة البيانات لتحقيق الامتثال.

عدم القابلية للتغيير وإمكانية التتبع: يتوقع المدققون والجهات الرقابية أنه بمجرد اعتماد السجلات المالية، لا يمكن العبث بها دون ترك دليل. وبعبارة أخرى، يجب أن تكون بياناتك التاريخية محمية من الكتابة لضمان سلامتها. على سبيل المثال، بعد إقفال دفاتر السنة المالية 2025، يجب قفل معاملات تلك السنة؛ وأي تعديلات يجب أن تتم عبر قيود جديدة في السنة المالية 2026 (مع الموافقات المناسبة)، وليس من خلال تعديل قيود 2025. توفر العديد من أنظمة ERP، بما في ذلك ERPNext، مستوى معينًا من إقفال الفترات أو قفل المستندات، لكن هذه الضوابط تكون على مستوى التطبيق ويمكن تجاوزها من خلال أدوار المشرف. وغالبًا ما تتطلب عدم القابلية للتغيير الحقيقية إما ضوابط تقنية (تخزين يُكتب مرة واحدة، أدوار قواعد بيانات للقراءة فقط) أو ضوابط إجرائية صارمة.

تُبرز اللوائح الحديثة هذه الحاجة. على سبيل المثال، تفرض القاعدة الهندية MCA Rule 11(g) (اعتبارًا من 2023) على الشركات الاحتفاظ بمسار تدقيق غير قابل للتعديل لجميع المعاملات المحاسبية، وتحظر صراحةً حذف أو تعديل تلك السجلات[13][13]. ويعني ذلك أن أي تغيير على سجل يجب أن يكون متعقّبًا مع الحفاظ على القيم الأصلية. عمليًا، تحتوي إصدارات ERPNext الحالية على تتبّع للإصدارات الخاصة بالمستندات (DocType Version يسجّل التغييرات)، ولكن ليس لكل الحقول وليس بشكل محصّن تمامًا ضد العبث (إذ يمكن نظريًا للمشرف تعديل سجل الإصدارات). وتتوقع اللوائح أنه بمجرد تسجيل المعاملة، يتم تسجيل أي تعديل والاحتفاظ بالقيم السابقة لمدة لا تقل عن 8 سنوات[13][13].

لتحقيق الامتثال:

1. تفعيل والاحتفاظ بسجلات مسار التدقيق: تأكد من عدم حذف مستند Version في ERPNext (الذي يسجّل التغييرات) أو أي سجل تدقيقي مماثل. لا يقوم ERPNext بحذف Version افتراضيًا، ولكن إذا أصبح الحجم مشكلة، فخطّط لذلك (ربما تقسيم أو أرشفة السجلات الأقدم أيضًا، ولكن بطريقة تضمن بقاءها قابلة للوصول).
2. استخدام إقفال الفترات وحالة المستند: يتيح ERPNext وسم السنة المالية كمقفلة (عبر Period Closing Voucher). بعد ذلك، لن يسمح النظام بإدخالات GL جديدة في تلك الفترة ما لم تتم إعادة فتحها. كما أن المستندات المُعتمدة (مثل الفواتير المعتمدة) لا يمكن تعديلها مباشرة — بل يجب إلغاؤها وإنشاء تعديل (Amendment)، ما يؤدي إلى إنشاء قيد إلغاء (وبذلك يتم الحفاظ على الأصل كملغى). شجّع الاستخدام الصارم لهذه الميزات. هذا ينشئ مسار تدقيق للتعديلات (على سبيل المثال، فاتورة أُلغيت في 2024 واستُبدلت بنسخة معدلة؛ يحتفظ النظام بالسجلين).
3. صلاحيات الأدوار: قيّد من يمكنه حذف المستندات. من الناحية المثالية، لا ينبغي لأي شخص حذف قيود محاسبية أو مخزون بعد اعتمادها؛ بل ينبغي فقط إلغاؤها (ما يحتفظ بالسجل). في قاعدة البيانات، يظل المستند الملغى موجودًا مع قيمة docstatus تشير إلى الإلغاء.
4. أرشيفات للقراءة فقط: بالنسبة للبيانات المؤرشفة (في قاعدة بيانات أو مثيل منفصل)، قم بفرض وضع القراءة فقط على مستوى قاعدة البيانات. على سبيل المثال، يمكنك ضبط صلاحيات المستخدم بحيث يمتلك مستخدم قاعدة بيانات الأرشيف صلاحيات SELECT فقط دون DELETE/UPDATE. وإذا كنت تستخدم موقع ERPNext منفصلًا للأرشيف، فقم بضبط جميع DocTypes للقراءة فقط لجميع المستخدمين عبر صلاحيات الأدوار (أو ببساطة لا تُنشئ أي أدوار لديها صلاحيات كتابة).

توقعات الجهات التنظيمية والتدقيق:

تختلف القواعد حسب الاختصاص القضائي، لكن هناك محاور مشتركة:

1. فترات الاحتفاظ بالبيانات: عادةً يجب الاحتفاظ بالبيانات المالية لمدة X سنوات (7 سنوات شائعة، و10 في بعض الحالات، إلخ)[13]. وقد تكون لبيانات الرواتب أو الموارد البشرية قواعد منفصلة (مثل الاحتفاظ بسجلات الموظفين لمدة سنتين بعد انتهاء الخدمة في بعض قوانين العمل[14]).
2. سهولة الوصول: تتوقع الجهات الرقابية أن تتمكن من تقديم السجلات عند الطلب خلال وقت معقول. إذا قمت بأرشفة البيانات خارج الموقع، فيجب أن تكون قادرًا على استرجاعها عند الحاجة. وهنا تبرز أهمية وجود عملية استرجاع موثقة (حتى تتمكن من الاستجابة بسرعة لاستفسارات التدقيق).
3. الحفاظ على الصيغة الأصلية: تتطلب بعض المعايير الاحتفاظ بالبيانات بالصيغة التي أُنشئت بها أو بصيغة تمثل الأصل بدقة[13]. على سبيل المثال، تتطلب Rule 3(5) في الهند الاحتفاظ بالسجلات الإلكترونية بالصيغ الأصلية أو بصيغة تمثل المعلومات بدقة[13]. وهذا يعني أنه إذا قام ERPNext بتخزين فاتورة، فيجب أن تكون قادرًا على عرض تلك الفاتورة بجميع الحقول كما سُجلت أصلًا. وإذا فُقدت بعض المعلومات أو تغيرت أثناء الترحيل أو الأرشفة، فقد تكون غير متوافق. لذلك، يجب أن تضمن أي طريقة أرشفة مختارة عدم تغيير محتوى السجل.
4. مسار التدقيق (السجلات): إلى جانب البيانات المعاملاتية، قد يلزم الاحتفاظ بسجلات التغييرات نفسها. إذا أراد المدقق معرفة من قام بتعديل قيد ومتى (خصوصًا بعد قوانين من نوع Rule 11(g))، فيجب توفر ذلك. يُعد جدول Version في ERPNext أحد المصادر، لكن فكّر أيضًا في سجلات النظام أو سجلات الوصول. ولتحقيق امتثال عالٍ، يقوم البعض بتنفيذ مشغلات على مستوى قاعدة البيانات لتسجيل التغييرات أو استخدام أنظمة تسجيل خارجية.

فرض وضع القراءة فقط: قد يتطلب تحقيق دفتر أستاذ غير قابل للتغيير ما يلي:

1. بالنسبة للمعاملات الأساسية (GL، الفواتير، إلخ)، بعد الترحيل، يتم منع أي تعديلات مباشرة. ويتم الاعتماد على الإلغاء (والذي يترك بحد ذاته أثرًا).
2. بالنسبة للأجزاء المؤرشفة، يمكن ضبط الجداول أو الأقسام (partitions) بالكامل على وضع القراءة فقط. في MySQL، يمكنك ربط الأقسام الأقدم بمساحات تخزين للقراءة فقط أو استخدام صلاحيات المستخدم لمنع التغييرات. وبطريقة أبسط، إذا كانت قاعدة بيانات منفصلة، فلا تمنح أي شخص بيانات اعتماد تسمح بالكتابة (أو قم بضبط قاعدة البيانات بالكامل على وضع read_only إذا كان خادم MySQL يدعم تبديل ذلك لمخطط معين).
3. على مستوى التطبيق: إذا كنت تستخدم موقع ERPNext للأرشيف، يمكنك إزالة وظائف “Cancel” و “Amend” عبر تعديل الكود أو الصلاحيات، لضمان ألا يحاول أي شخص — حتى عن طريق الخطأ — تعديل بيانات تم إقفالها تاريخيًا.

سياسات الاحتفاظ بالبيانات: يجب أن توضح وثيقة سياسة الحوكمة ما يلي:

1. المدة التي تبقى فيها البيانات في النظام الحي مقابل الأرشيف مقابل إجمالي فترة الاحتفاظ.
2. متى وكيف تتم أرشفة البيانات أو التخلص منها. على سبيل المثال: “سيتم أرشفة بيانات المعاملات بعد 5 سنوات من النظام الحي إلى نظام الأرشيف، وسيتم التخلص منها (حذفها نهائيًا) بعد 15 سنة، ما لم تكن خاضعة لحجز قانوني.”
3. من يملك الصلاحية للوصول إلى البيانات المؤرشفة. ربما يقتصر ذلك على مسؤول الامتثال أو تقنية المعلومات فقط عند استرجاع بيانات أقدم من 10 سنوات، إلخ.
4. سياسة الاحتفاظ بالنسخ الاحتياطية: التأكد من الاحتفاظ بنسخ احتياطية للأرشيف أيضًا، وليس فقط للنظام الحي. تتطلب العديد من أطر الامتثال وجود نسخ احتياطية خارج الموقع كذلك (قاعدة النسخ الاحتياطي 3-2-1 الكلاسيكية: على الأقل 3 نسخ، على وسيطين مختلفين، ونسخة واحدة خارج الموقع).

حفظ الأدلة: في حال النزاعات القانونية، قد تحتاج إلى إثبات أن البيانات لم يتم العبث بها. بعض الاستراتيجيات:

1. Checksums أو التواقيع الرقمية: عند الأرشفة، قم بإنشاء قيمة تجزئة (hash) لمجموعات البيانات المهمة أو قم بتصديرها إلى PDF موقّع. على سبيل المثال، بعد إقفال نهاية السنة، قم بتصدير دفتر الأستاذ العام أو ميزان المراجعة إلى PDF، واطلب توقيعه من مدقق أو توقيعه رقميًا. إذا ادّعى أحد لاحقًا أن البيانات قد تم تعديلها، فسيكون لديك التقارير الأصلية الموقعة. وبالمثل، يمكنك حساب checksums لقاعدة البيانات أو الجداول وقت الأرشفة وتخزينها بشكل آمن. وعند الشك في السلامة، يمكنك إظهار أن checksum للبيانات المؤرشفة يطابق ما كان عليه.
2. التخزين غير القابل للتغيير: تستخدم بعض الشركات حلول تخزين WORM (write once read many) لأرشيفات الامتثال. على سبيل المثال، كتابة النسخ الاحتياطية على أشرطة أو على حلول تخزين تمنع الحذف أو التعديل لمدة X سنوات.
3. سجلات التدقيق للوصول: تتبع من يقوم بالوصول إلى الأرشيف وماذا يفعل به. إذا حضر مدقق، فقد يسأل: “من الذي اطّلع على هذه البيانات أو استخرجها؟”. إذا كان الأرشيف نظامًا قيد التشغيل، فتأكد من تسجيل الاستخدام (سجلات التطبيق أو حتى سجلات استعلامات قاعدة البيانات إن أمكن). في بنك، على سبيل المثال، قد يتم تسجيل كل مرة يسترجع فيها شخص معلومات تاريخية لمنع سوء الاستخدام.

الاستعداد للتدقيق: عند وصول المدققين (داخليين أو خارجيين):

1. يجب أن تكون قادرًا على شرح استراتيجية الأرشفة الخاصة بك (سيسألون: “كيف تضمنون تأمين البيانات الأقدم من 5 سنوات؟”).
2. تزويدهم بالسجلات التي يطلبونها خلال وقت معقول. إذا كان لديك ERPNext للأرشيف، يمكنك إنشاء مستخدم تدقيق لهم بصلاحية قراءة كل شيء في الأرشيف. وإذا لم يكن كذلك، فكن مستعدًا لتشغيل الاستعلامات أو استعادة النسخ الاحتياطية بسرعة.
3. عرض التوثيق: إن وجود سياسة إدارة بيانات رسمية أو SOPs تغطي النسخ الاحتياطي، والأرشفة، والاحتفاظ، والتحكم بالوصول سيعزز الثقة. تحب الجهات التنظيمية أن ترى أن لديك خطة وأنك تطبقها.
4. إذا كنت تستخدم التشفير للنسخ الاحتياطية (وهو موصى به للبيانات الحساسة)، فتأكد من قدرتك على فك التشفير بعد سنوات (إدارة مفاتيح التشفير بشكل سليم على المدى الطويل).
5. التأكد من أن البيانات المؤرشفة تلتزم أيضًا بقوانين الخصوصية (على سبيل المثال، إذا كان قانون مثل GDPR ينطبق، فهل تحتاج إلى حذف البيانات الشخصية بعد فترة معينة؟ قد يتعارض ذلك مع الاحتفاظ المالي — وغالبًا ما تتغلب القوانين المالية، ولكن فكّر في إخفاء الهوية (pseudonymization) عند الحاجة).

خلاصة القول، إن البيانات التاريخية غير القابلة للتغيير أمر حيوي لأنها تمنح مصداقية للبيانات المالية وتحمي من الاحتيال. العديد من قضايا الاحتيال البارزة تتضمن تأريخًا رجعيًا أو تعديل قيود، لذلك تُعد الأنظمة التي تستطيع قفل البيانات السابقة وإظهار دليل على أي تغييرات أمرًا بالغ الأهمية. كما أن الجهات التنظيمية أصبحت تطلب صراحةً ميزات عدم القابلية للتغيير[13]، لذا يجب أن تتماشى أي استراتيجية أرشفة مع تلك المتطلبات:

1. استخدام أرشيفات للقراءة فقط،
2. الاحتفاظ بمسارات تدقيق شاملة،
3. منع حذف سجلات التدقيق نفسها (أي عدم حذف جدول Version دون وجود نسخة احتياطية)،
4. والمراجعة الدورية للتأكد من أن هذه الضوابط تعمل فعليًا (على سبيل المثال، اختبار أن مستخدمًا بلا صلاحية لا يمكنه فعلًا تعديل قيد في فترة مقفلة).

من خلال دمج ممارسات الحوكمة هذه ضمن بنية بيانات ERPNext لديك، فإنك تحوّل النظام إلى مستودع موثوق للحقيقة التاريخية، بما يلبّي متطلبات المدققين ويتجنب غرامات عدم الامتثال.

10. خارطة طريق وأفضل الممارسات والتوصيات

أخيرًا، دعونا نضع خارطة طريق مرحلية لتطبيق هذه الاستراتيجيات في بيئة ERPNext يُتوقع أن تستمر في النمو والتحديث على مدى السنوات. صُمّمت خارطة الطريق لبناء القدرات تدريجيًا، بحيث يمكنك البدء بأقل قدر من الاضطراب ثم تعزيز الأرشفة والحفظ بشكل متدرّج مع زيادة الاحتياجات:

المرحلة 1: تنفيذ التقسيم وتحسينات الأداء (السنة 0–1)

الهدف: معالجة أي مشكلات أداء ناتجة عن حجم البيانات بشكل فوري، وتهيئة النظام للنمو المستقبلي.

1. تفعيل التقسيم على الجداول الرئيسية: ابدأ بتقسيم الجداول المعاملاتية الكبيرة (GL Entry، Stock Ledger Entry، إلخ) حسب السنة أو الربع حسب ما هو مناسب[10][6]. سيؤدي ذلك إلى تحسين سرعة التقارير وتقليل التنافس على أقفال الجداول. نفّذ ذلك مبكرًا، ويفضّل عندما يكون حجم النظام ما يزال قابلًا للإدارة، بحيث تكون عملية التقسيم نفسها أسهل. أنشئ روتينًا (script/cron) لإضافة أقسام جديدة (مثل كل سنة مالية جديدة)، وربما لاحقًا فصل/أرشفة الأقسام القديمة.
2. تحسين الفهارس والاستعلامات: إلى جانب التقسيم، أضف أي فهارس مفقودة تتسبب في بطء الاستعلامات (كما يتضح من سجل الاستعلامات البطيئة)[6][6]. يساعد التقسيم، لكن تظل الفهرسة الصحيحة داخل الأقسام ضرورية. قلّل طول قوائم المعاملات الطويلة جدًا في واجهة المستخدم عبر تطبيق فلاتر افتراضية (حتى لا يقوم المستخدمون بسحب 100 ألف صف عن غير قصد).
3. إعداد السياسات: قم الآن بإعداد وثيقة سياسة الاحتفاظ بالبيانات والأرشفة. يجب أن تنص مثلًا على: “سنحتفظ بعدد X من السنوات من البيانات على النظام الحي، ونقوم بالأرشفة سنويًا، إلخ”. حتى وإن لم تنفّذ الأرشفة فورًا، فإن موافقة الإدارة على سياسة واضحة ستساعد لاحقًا في فرضها. كذلك، قم بإعداد إقفال الفترات في ERPNext مع أول إقفال لنهاية السنة لفرض عدم إدخال قيود جديدة في الفترات المقفلة. درّب مستخدمي المالية على إقفال الفترات وعدم حذف القيود.
4. النتيجة: بنهاية المرحلة 1، يجب أن يعمل النظام بكفاءة مع أحجام البيانات الحالية، وأن تكون الأسس (التقسيم، السياسات) اللازمة للأرشفة قد وُضعت. لن يشعر المستخدمون بفارق كبير سوى تسارع التقارير.

المرحلة 2: إدخال الأرشفة عبر Snapshot عند نهاية السنة المالية (السنة 1–2)

الهدف: البدء بعملية الأرشفة عبر أخذ لقطات كاملة بعد نهاية السنة وتقليص حجم قاعدة البيانات الحية.

1. نسخة احتياطية كاملة لنهاية السنة والأرشفة: عند إقفال أول سنة مالية ضمن هذه المرحلة، نفّذ نسخة احتياطية كاملة لقاعدة بيانات ERPNext (ومخزن الملفات) فور الانتهاء من إقفال الدفاتر. قم بالتحقق من النسخة الاحتياطية (مثل استعادتها على خادم اختبار للتأكد من اكتمالها). قم بتسميتها بوضوح (مثل ERPNext_Archive_FY2025.zip). خزّنها في عدة مواقع آمنة (داخل الموقع وخارجه) مع ضوابط أمان مناسبة. هذه هي أرشيف النقطة الزمنية لتلك السنة.
2. تنقية/إزالة البيانات القديمة من النظام الحي: بافتراض أن سياستك هي الاحتفاظ — مثلًا — بسنتين في النظام الحي ثم أرشفة الأقدم، يمكنك الآن إزالة البيانات الأقدم من هذا الحد من قاعدة البيانات الحية. مع التقسيم، يكون ذلك سهلًا: مثلًا حذف قسم يعود إلى ثلاث سنوات مضت. وبدلًا من ذلك، استخدم أدوات Data Import/Export في ERPNext أو سكربتات مخصصة لحذف السجلات الأقدم (بحذر: الحفاظ على سلامة العلاقات — من الأفضل حذف الأقسام أو استخدام أوامر bench مثل bench trim-tables والتي تم التلميح لها في الوثائق[2]). النتيجة هي أن النظام الحي يصبح أخف وزنًا.
3. إعداد الوصول إلى الأرشيف (إذا كان مطلوبًا فورًا): إذا كنت تتوقع وصولًا متكررًا إلى بيانات السنة المؤرشفة، ففي هذه المرحلة يمكنك إعداد مثيل للقراءة فقط باستخدام النسخة الاحتياطية. على سبيل المثال، استعادة النسخة الاحتياطية إلى موقع جديد باسم “erpnext-archive” على الخادم (ربما يعمل على نفس إصدار ERPNext الذي أُخذت منه النسخة). قم بقفل أدوار المستخدمين على وضع القراءة فقط. وإذا لم تكن هناك حاجة فورية لمثل هذا الوصول، يمكنك تجاوز تشغيل المثيل والاكتفاء بتخزين النسخة الاحتياطية.
4. اختبار طلبات التدقيق: كتمرين تجريبي، افترض أن مدققًا يطلب تقريرًا من سنة مؤرشفة. تأكد من قدرتك على توليده إما من مثيل الأرشيف أو عبر استعادة النسخة الاحتياطية. وثّق الخطوات والوقت المستغرق. سيكشف ذلك أي نقاط ضعف قبل أن تكون في موقف ضغط حقيقي.
5. النتيجة: تكون المؤسسة قد نفّذت دورة أرشفة واحدة بنجاح. تخلّصت قاعدة البيانات الحية من البيانات الأقدم (ما يحسّن الأداء والصيانة)، وتوفرت نسخة احتياطية مُثبتة لتلك البيانات خارج النظام الحي. وهذا يرسّخ الروتين للسنوات اللاحقة.

المرحلة 3: إنشاء نظام أرشيف منفصل (السنة 2–5)

الهدف: مع نمو البيانات وأرشفة عدة سنوات، يتم نشر حل أكثر ديمومة للوصول إلى السجلات المؤرشفة (لتجنب عمليات الاستعادة المتكررة).

1. نشر مثيل ERPNext للأرشيف: قم بإعداد موقع ERPNext مخصص (وربما خادم) للبيانات المؤرشفة. على سبيل المثال، مثيل باسم “ERPNext Archive” يعمل على إصدار ERPNext الموافق للفترة التي تم فيها تجميد البيانات (أو أحدث إصدار يمكنه التعامل بسلاسة مع جميع البيانات المؤرشفة). قم باستيراد البيانات المؤرشفة المتراكمة إلى هذا المثيل. قد يعني ذلك استعادة أحدث snapshot ثم استيراد بيانات snapshots السابقة أيضًا. وبدلًا من ذلك، يمكن الحفاظ على أرشيف تراكمي — وبما أنك تملك نسخًا احتياطية لكل سنة، يمكنك استعادتها بشكل تسلسلي إلى قاعدة بيانات واحدة (مع ضمان عدم حدوث تعارضات). وإذا كنت تستخدم التقسيم، فيمكنك أيضًا إرفاق الأقسام الأقدم بقاعدة بيانات الأرشيف. الهدف النهائي: أن يحتوي مثيل الأرشيف على جميع المعاملات الأقدم من X سنوات.
2. إدارة الإصدارات: قرّر ما إذا كان مثيل الأرشيف سيبقى على إصدار معين أو سيتم ترقيته دوريًا. اقتراح: إبقاؤه على أحدث إصدار رئيسي كان عليه النظام الرئيسي عندما كانت تلك السجلات نشطة، لتقليل مشكلات نموذج البيانات. على سبيل المثال، إذا انتقل النظام الرئيسي في السنة الثالثة من v14 إلى v15، وقمت بأرشفة كل شيء حتى تلك النقطة على v14، فقد تُبقي الأرشيف على v14 دون ترقيته لاحقًا. وثّق هذا القرار وكن على دراية بأنه بعد ~سنتين إضافيتين سيكون v14 غير مدعوم (EOL نهاية 2025)[4]. عند تلك النقطة، قم بتخفيف المخاطر الأمنية عبر عزله (تفعيل جدار ناري، إلخ).
3. القراءة فقط والأمان: قم بتهيئة نظام الأرشيف ليكون للقراءة فقط. على سبيل المثال، أنشئ دورًا باسم “Archive Viewer” بصلاحيات قراءة فقط على جميع DocTypes. عيّن المستخدمين (غالبًا عددًا محدودًا من المالية أو الامتثال) لهذا الدور. أزل جميع الأدوار الأخرى من ذلك الموقع. هذا يضمن عدم الإنشاء أو التعديل. كما يمكنك التفكير في ضبط db_read_only على مستوى MariaDB لذلك المستخدم إن أمكن (مع العلم أن ERPNext قد يحتاج إلى الكتابة لسجلات محاولات تسجيل الدخول، إلخ — ويمكنك على الأقل حظر عمليات DML على الجداول الرئيسية عبر صلاحيات قاعدة البيانات). راقب السجلات في مثيل الأرشيف لأي محاولات كتابة أو سلوكيات غير طبيعية.
4. تدريب المستخدمين: أبلغ الموظفين المعنيين بكيفية الوصول إلى البيانات المؤرشفة الآن. على سبيل المثال، يمكن للمدققين أو فريق المالية تسجيل الدخول إلى Archive ERPNext للحصول على السجلات القديمة. قدّم دليلًا مختصرًا — “دليل مستخدم نظام الأرشيف” — يشرح كيفية العثور على الفواتير التاريخية، وتشغيل تقرير لسنة مقفلة، إلخ، مع التأكيد بوضوح على أن الأرشيف للقراءة فقط (ولا ينبغي محاولة إجراء تغييرات).
5. استمرار الأرشفة الدورية: في نهاية كل سنة، واصل الأرشفة: خذ snapshot، ثم استورد بيانات تلك السنة إلى Archive ERPNext (وبما أنه يعمل على إصدار أقدم، فقد تحتاج إلى التصدير من النظام الرئيسي والاستيراد عبر أداة استيراد البيانات إذا لم يكن نقل قاعدة البيانات المباشر ممكنًا بسبب اختلاف الإصدارات — وقد يكون ذلك عبر سكربت مخصص لإدخال السجلات). وبدلًا من ذلك، إذا كان مثيل الأرشيف على إصدار قريب نسبيًا، يمكنك ترقيته مؤقتًا بالتوازي واستخدام النسخ المتماثل أو نسخ قاعدة البيانات المباشر للأرشفة. اختر نهجًا والتزم به. وربما بحلول السنة الخامسة، قد تقرر تجميد مثيل الأرشيف وبدء مثيل جديد للسنوات اللاحقة إذا لزم الأمر (اعتمادًا على حجمه أو اتساع فجوة الإصدارات).
6. النتيجة: في هذه المرحلة، تمتلك الشركة منصة أرشيف مستقرة. يظل النظام الحي سريعًا مع عدد محدود من السنوات؛ ويوفر نظام الأرشيف الوصول إلى البيانات الأقدم دون التأثير على النظام الحي. يمكن التعامل مع عمليات التدقيق عبر نظام الأرشيف. يتحسن الامتثال لأن البيانات القديمة معزولة ومحمية.

المرحلة 4: الحفظ طويل الأمد للأنظمة القديمة وخطة الترحيل (السنة 5 وما بعدها)

الهدف: معالجة الأسئلة المستقبلية: كيفية التعامل مع بيانات الأرشيف القديمة جدًا وكيفية الحفاظ على قابلية إدارة أنظمة الأرشيف عبر الترقيات.

1. تقييم مستودع البيانات/BI للتحليلات التاريخية: في هذه المرحلة تقريبًا، قد يكون لديك — على سبيل المثال — أكثر من 10 سنوات من البيانات إجمالًا (جزء في النظام الحي وجزء في الأرشيف). إذا رغبت الإدارة في تحليلات عبر كامل النطاق، ففكّر في تنفيذ مستودع بيانات أو حل BI. قد يتضمن ذلك استخراج بيانات مُلخّصة (مثل المبيعات السنوية والاتجاهات) إلى قاعدة بيانات تحليلية منفصلة يمكنها السحب من النظام الحي ومن الأرشيف معًا. هذا اختياري، لكنه قد يحقق قيمة من البيانات المؤرشفة تتجاوز مجرد التخزين. إذا قررت المضي قدمًا، فأنشئ خطوط تغذية (pipelines) من كل من ERPNext الحي وERPNext للأرشيف إلى المستودع. تأكد من وجود فحوصات اتساق للبيانات بين الأنظمة. يعمل هذا بالتوازي مع مثيلات ERPNext، موفّرًا لوحات معلومات وتقارير دون إثقال ERPNext.
2. التخطيط لنهاية عمر مثيل الأرشيف (EOL): إذا كان مثيل الأرشيف يعمل على إصدار قديم (وربما على نظام تشغيل/بايثون قديم)، فحدّد نقطة إيقاف له. الخيارات:
3. إذا سمحت اللوائح بحذف البيانات بعد X سنوات، فقد تقوم في النهاية بإيقاف أقدم البيانات. على سبيل المثال، إذا كان يمكن حذف ما يزيد عمره عن 15 سنة، وعند الوصول إلى تلك النقطة، قد تُتلف بأمان الـ VM القديمة لتلك السنوات (بعد إخطار المدققين أو التأكد من عدم وجود حجز قانوني على البيانات).
4. إذا كان يجب الاحتفاظ بها، ففكّر في تحويل ذلك المثيل القديم إلى صورة مجمّدة. على سبيل المثال، عندما يصبح عمره 10+ سنوات ونادر الوصول، قم بتصديره إلى VM وأوقف تشغيله. وثّق كيفية استعادته عند الحاجة.
5. بدلًا من ذلك، يمكنك محاولة إجراء ترحيل لمرة واحدة لتلك البيانات القديمة إلى نظام أرشيف أحدث أو إلى مستودع البيانات إن كان ذلك أسهل، ثم إيقاف البرمجيات القديمة. على سبيل المثال، ربما بحلول السنة العاشرة تقرر دمج بيانات أرشيف ERPNext (v14) في أرشيف ERPNext جديد على v20 باستخدام سكربتات استيراد البيانات، لتتمكن من إيقاف نظام v14. هذا مشروع ترحيل صغير — وازن الجهد مقابل الاكتفاء بالإبقاء على القديم دون اتصال.
6. الترقيات المستمرة للأنظمة النشطة: سيستمر النظام الرئيسي لـ ERPNext في الترقية إلى إصدارات جديدة (v16، v17، ...). خطّط للأرشفة بالتوازي مع الترقيات: عادةً، هل تُؤرشف بعد الترقية أم قبلها؟ نصيحة: قم بالأرشفة قبل الترقية الرئيسية، بحيث إذا حدث خلل أو تغيّر نموذج البيانات، يكون لديك حدّ فاصل نظيف. مثال: أنت على وشك الانتقال من v15 إلى v16، ولديك 8 سنوات من البيانات في الأرشيف على v15 وآخر سنتين في النظام الرئيسي على v15. قم بأرشفة آخر السنتين (ليحصل الأرشيف عليها على v15)، ثم يصبح النظام الرئيسي نحيفًا، وقم بترقيته إلى v16 (ببيانات أقل — ترحيل أسهل). يبقى الأرشيف على v15 للبيانات القديمة. هذا يعني أن الأرشيف والنظام الرئيسي أصبحا على إصدارات متباعدة، وهو أمر مقبول. وقد تقوم لاحقًا بإنشاء موقع أرشيف جديد لإصدارات v16 وما بعدها عند الحاجة.
7. المراجعة الدورية للسياسات: أعد النظر بانتظام في سياسة الاحتفاظ بالبيانات. قد تتغير احتياجات العمل أو القوانين (مثل صدور قانون خصوصية جديد قد يتطلب حذف بعض البيانات الشخصية بعد X سنوات — أدرج ذلك في استراتيجية الأرشفة عبر إخفاء الهوية (anonymization) لمعرّفات شخصية في الأرشيف بعد فترة السماح إذا سمحت اللوائح المالية). راجع أيضًا قوائم وصول المستخدمين إلى الأرشيف — أزل أي مستخدمين غادروا أو لم يعودوا بحاجة إلى الوصول (كما تفعل في النظام الرئيسي).
8. اعتبار التخزين غير القابل للتغيير: إذا لم يتم ذلك بعد، ففكّر في تخزين نسخة واحدة من القوائم المالية لنهاية كل سنة أو سجلات التدقيق في تخزين غير قابل للتغيير (مثل دفتر قائم على blockchain أو ببساطة نسخها على أقراص Blu-ray WORM). هذا إجراء متطرف، لكن بعض معايير التدقيق قد تتطلبه. وعلى أقل تقدير، تأكد من أن النسخ الاحتياطية ليست سهلة الحذف — على سبيل المثال، استخدام نسخ احتياطية سحابية مع أقفال احتفاظ Write-Once لنسخ الأرشيف (توفر العديد من خدمات التخزين السحابي أوضاع امتثال لا يمكن حتى للمشرف فيها حذف الأرشيف قبل انتهاء فترة الاحتفاظ).

المرحلة 4 وما بعدها تضمن بشكل أساسي أنه مع تطور منظومة ERP لديك، لا تتراكم الديون التقنية:

1. التخلص التدريجي من الأنظمة المتقادمة.
2. الحفاظ على إتاحة البيانات مع تأمينها.
3. التكيّف مع متطلبات الامتثال الجديدة.

ملخص الممارسات الموصى بها:

1. ابدأ ببساطة ثم تطوّر: لا تحاول نشر حل أرشفة معقّد ومستودع بيانات (DW) منذ اليوم الأول. نفّذ الحد الأدنى (التقسيم + نسخ احتياطية جيدة) ثم ابنِ فوقه مع نمو البيانات وتبرير الحاجة.
2. أتمتة ما أمكن: تساعد السكربتات الخاصة بإضافة الأقسام، وأخذ النسخ الاحتياطية، ونقل البيانات إلى قاعدة بيانات الأرشيف، إلخ، على تقليل الأخطاء البشرية. اختبر سكربتات الأتمتة هذه بعناية.
3. المراقبة والتدقيق على العملية: كل سنة، نفّذ تدقيقًا داخليًا على إدارة البيانات: تحقّق من أن ما يجب أرشفته قد تم أرشفته، وما يجب حذفه قد تم حذفه، وأنه لم تحدث أي تغييرات غير مصرّح بها في الأرشيف. كذلك، اختبر استعادة النسخ الاحتياطية مرة واحدة على الأقل سنويًا.
4. التواصل: أبلغ أصحاب المصلحة (وخاصة المالية والامتثال) بجدول الأرشفة. على سبيل المثال: “سنقوم بأرشفة بيانات السنة المالية 2022 بتاريخ 31 مارس 2025. بعد هذا التاريخ، ستكون تلك البيانات متاحة في نظام الأرشيف.” هذا يمنع المفاجآت.

باتباع هذا النهج المرحلي، تقوم بتحويل نشر ERPNext لديك تدريجيًا من إعداد بسيط إلى نظام متين بمستوى مؤسسي قادر على التعامل مع بيانات واسعة النطاق على مدى فترات طويلة، دون تدهور في الأداء أو الامتثال. المفتاح هو الالتزام طويل الأمد بهذه الممارسات، مع تعديلها عند الحاجة كلما تغيّر ERPNext نفسه (مثل ظهور ميزات جديدة لأرشفة البيانات أو التدقيق في الإصدارات المستقبلية، عندها يتم دمجها).

في النهاية، تضمن هذه التوصيات ما يلي:

1. سلاسة العمليات الحالية (استعلامات سريعة بفضل التقسيم).
2. استدامة النمو المستقبلي (من خلال الأرشفة وربما التوسع باستخدام مستودعات البيانات).
3. الحفاظ على البيانات التاريخية بطريقة موثوقة (أرشيفات للقراءة فقط، وسجلات غير قابلة للتغيير).
4. استمرار الترقيات بشكل منتظم (البقاء ضمن الإصدارات المدعومة) مع إدارة البيانات الأقدم بالتوازي.
5. التزام المؤسسة بالقوانين ومعايير التدقيق طوال دورة حياة البيانات.

تُعد هذه الخارطة مرجعًا وورقة عمل داخلية لفرق تقنية المعلومات والامتثال لتخطيط السعات والمسؤوليات. تبني كل مرحلة على السابقة، مع مواءمة الإجراءات التقنية مع متطلبات الأعمال (الأداء، التدقيق، التكلفة). وبحلول المرحلة 4، سيكون لديك بنية بيانات ناضجة لنظام ERPNext، شبيهة بما تستخدمه المؤسسات الكبرى (مثل البنوك) لتحقيق التوازن بين الاحتياجات الحالية وإدارة البيانات التاريخية[6].