كيف تبني إخراج تقارير Excel - COM وOpen XML والقوالب

في استشارات إخراج تقارير Excel كثيراً ما تختلط داخل عبارة «نريد الإخراج إلى Excel» عدّة متطلّبات مختلفة.

• يريد المستخدم أن يعدّل الناتج يدوياً لاحقاً
• نريد الإبقاء على .xlsm الموجود
• نريد الإبقاء على الجداول المحورية والرسوم وإعدادات الطباعة كما هي
• نريد إخراجاً كبيراً في دفعة ليلية
• نريد تشغيلاً بلا مشغّل على الخادم
• نريد PDF أيضاً

لا يحلّ أسلوب واحد كل ذلك بنظافة. ما ينبغي النظر إليه أولاً ليس اسم المكتبة، بل هل ستشغّل تطبيق Excel أم ستنشئ ملف Excel.

إن تجاوزت هذا السؤال فقد يعمل الإصدار الأوّل، لكن الصيانة تصبح مؤلمة لاحقاً. نفترض هنا إخراج تقارير Excel من تطبيقات Windows وأنظمة الأعمال، ونرتّب كيف تختار بين أتمتة COM / Open XML / الإدراج في قالب / الإبقاء على VBA القائمة.

flowchart TB
    accTitle: نقطة الفصل التي ينبغي النظر إليها أولاً
    accDescr: في إخراج تقارير Excel ينبغي النظر قبل اسم المكتبة إلى نقطة الفصل بين تشغيل تطبيق Excel وإنشاء ملف Excel، ويبين المخطّط أن تجاوز هذا السؤال يجعل الصيانة مؤلمة لاحقاً حتى إن عمل الإصدار الأوّل.
    q1{"تشغيل تطبيق Excel أم إنشاء ملف؟"}
    q1 -->|"تشغيل التطبيق"| a1["أسلوب التشغيل التلقائي لـ Excel"]
    q1 -->|"إنشاء الملف"| a2["أسلوب تركيب xlsx مباشرة"]
    q1 -.-> w1["تجاوزه يجعل الصيانة مؤلمة لاحقاً"]

الشكل 1: قبل اختيار المكتبة، قرّر إن كنت ستشغّل Excel أم ستركّب الملف.

الجمهور المستهدف والافتراضات

المقالة موجّهة إلى المطوّر الذي سيقرّر الآن أسلوب إخراج تقارير Excel من نظام أعمال.

الافتراض هو الإخراج من تطبيق أو دفعة C# / .NET تعمل على Windows. نفترض أيضاً حالات تحمل أصول VBA قائمة، لكن حتى عندئذ لا نكتب على أساس «إكمال كل شيء بـ VBA وحدها»، بل على أساس تقسيم الأدوار مع جانب .NET. أمثلة الشيفرة بـ C# / .NET 8.

مصطلحات ينبغي تثبيتها مسبقاً

1. الخلاصة أولاً

نضع الخلاصة أولاً.

• إن كان المستخدم سيفتح التقرير في Excel ويحرّره لاحقاً، فالمرشّح الأوّل هو قالب مع توليد مباشر لـ .xlsx / .xlsm.
• إن كان التوليد التلقائي على خادم / خدمة / جدولة، فالأسلم ألّا تفترض أتمتة Office.
• إن أردت الإبقاء على .xlsm القائم وVBA والرسوم والجداول المحورية وإعدادات الطباعة، فضع التخطيط وميزات Excel الخاصة في جانب القالب، واجعل الشيفرة تقتصر على حقن البيانات؛ هكذا يقلّ الكسر.
• لا تستخدم أتمتة COM إلا عندما تحتاج فعلاً إلى سلوك تطبيق Excel نفسه، واحصرها عندئذ في تشغيل بحضور مستخدم على سطح المكتب.
• إن كان المطلوب مجرّد قائمة، فقد يناسب CSV / PDF / شاشة ويب المتطلّب من البداية أكثر مما تظن.

باختصار، في كثير من تقارير الأعمال يكون الطبيعي «تركيب ملف Excel» لا «تشغيل Excel».

flowchart TB
    accTitle: المرشّح الأوّل بحسب المتطلّب
    accDescr: يبين المخطّط أن التقرير الذي سيحرّره المستخدم لاحقاً مرشّحه الأوّل قالب وتوليد مباشر، وأن التوليد التلقائي على خادم أو خدمة لا يفترض أتمتة Office، وأن أتمتة COM تُحصر في تشغيل بحضور مستخدم عندما تحتاج فعلاً إلى سلوك تطبيق Excel.
    r1["تقرير يُحرَّر لاحقاً"] --> s1["قالب وتوليد مباشر"]
    r2["توليد تلقائي بلا مشغّل"] --> s2["لا تفترض أتمتة Office"]
    r3["الحاجة إلى سلوك Excel نفسه"] --> s3["احصر أتمتة COM في تشغيل بحضور مستخدم"]

الشكل 2: انظر من يشغّل وأين يشغّل، فيكاد المرشّح الأوّل يتحدّد.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 29، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما ينبغي تقريره أولاً

نجمع في جدول ما يستحق التقرير مسبقاً في إخراج تقارير Excel.

3. أساليب التنفيذ الرئيسة

3.1 أتمتة Excel عبر COM

تشغّل Excel وتتعامل مع Workbook وWorksheet وRange عبر COM. أسهل تصوّر هو أنك تقود Excel الحقيقي.

القوة أنك تستخدم سلوك Excel نفسه كما هو. يناسب المصنّفات القائمة والرسوم والجداول المحورية وإعدادات الطباعة والماكرو وإخراج PDF، وتتعامل مباشرة مع «كيف يعرض Excel الناتج في النهاية».

غير أن نقاط الضعف واضحة أيضاً.

• يلزم تثبيت Excel
• تحمل عمر العملية وقفل الملفات ومربّعات الحوار وbitness والاعتماد على ملف تعريف المستخدم
• أتمتة Office من خادم بلا مشغّل أو من خدمة لا توصي بها Microsoft نفسها ولا تدعمها

النقطة الثالثة أقوى ادّعاء في هذه المقالة، لذا نذكر المصدر صراحة. مقالة دعم Microsoft «Considerations for server-side Automation of Office» تنصّ على أنها لا توصي بأتمتة Office على جانب الخادم ولا تدعمها. الأسباب المذكورة خمسة:

لبيئة RPA في Microsoft 365 ترتيب منفصل في «Considerations for unattended automation of Office». إن صار هذا البند موضع خلاف عند اختيار الأسلوب، فاجعل هاتين المقالتين المصدر.

flowchart TB
    accTitle: موقع أتمتة جانب الخادم
    accDescr: يبين المخطّط أن أتمتة Office من خادم بلا مشغّل أو من خدمة لا توصي بها Microsoft نفسها ولا تدعمها، وأن مقالتين رسميتين تصلحان مصدراً عندما يصير اختيار الأسلوب موضع خلاف.
    sv1["أتمتة Office من خادم بلا مشغّل"] --> sv2["Microsoft لا توصي ولا تدعم"]
    sv2 -.-> sv3["مقالة الدعم تصبح مستنداً"]
    sv2 -.-> sv4["بيئة RPA في M365 مرتّبة في مقالة أخرى"]

الشكل 3: جواز هذا الأسلوب ليس ذوقاً؛ يُحسم بمصدر رسمي.

3.2 التوليد المباشر لـ .xlsx

.xlsx صيغة Open XML، لذا يمكن تركيب الملف مباشرة دون تشغيل Excel. بوسائل مثل Open XML SDK تتعامل برمجياً مع المصنّف والورقة والخلية والنمط والجدول.

قوة هذا الأسلوب أنه يسهل تشغيله حتى في بيئة بلا Excel، ويناسب الدفعات والخوادم.

في المقابل يصعب قليلاً إن أردت إعادة سلوك Excel ذي الطابع البصري كما هو. المحاذاة التلقائية لعرض الأعمدة وتقسيم الصفحات والمظهر المعقّد والتحرير العميق لمصنّف قائم تجعل عدد الأسطر يتزايد إن حاولت إنجاز كل ذلك بالشيفرة وحدها.

flowchart TB
    accTitle: طابع أسلوب التوليد المباشر
    accDescr: يبين المخطّط أن xlsx صيغة Open XML يمكن تركيبها دون تشغيل Excel وأنها تناسب البيئات بلا Excel والدفعات والخوادم، بينما تتزايد الشيفرة إن أردت إعادة سلوك Excel ذي الطابع البصري.
    dg1["xlsx صيغة Open XML"] --> dg2["التركيب دون تشغيل Excel"]
    dg2 --> dg3["يناسب الدفعات والخوادم"]
    dg2 -.-> dg4["إعادة الجانب البصري تزيد الشيفرة"]

الشكل 4: قوة الاستغناء عن Excel وضعف إعادة المظهر وجهان لعملة واحدة.

مكتبات التعامل مع .xlsx من .NET عدّة، وشروط الترخيص تؤثّر عملياً. المرشّحون الشائعون هم تقريباً هؤلاء.

في أسلوب الإدراج في قالب يحمل القالب المظهر، فلا يُطلب من الشيفرة سوى «وضع القيمة في المدخل المتّفق عليه». لذلك يسهل التعامل مع أغلفة أقل حجماً في الكتابة.

3.3 الإدراج في قالب

الأسلوب الأسهل توصيته عملياً هو صنع قالب Excel أولاً، وجعل الشيفرة تقتصر على حقن البيانات.

ضع مظهر التقرير والصيغ والتنسيق الشرطي ونطاق الطباعة والترويسة / التذييل والشعار والرسوم في جانب القالب. جانب الشيفرة ينسخ القالب ويكتب البيانات في «المداخل المتّفق عليها» مثل النطاقات المسمّاة والجداول ونطاقات الخلايا.

بهذا ينفصل تعديل التخطيط عن تعديل منطق الأعمال. ويصير تجنّب جحيم Cells[37, 9] = ... الشائع في تقارير Excel أسهل كثيراً.

flowchart TB
    accTitle: تقسيم الأدوار في الإدراج في قالب
    accDescr: يبين المخطّط أن المظهر والصيغ وإعدادات الطباعة تُوضع في جانب القالب، وأن جانب الشيفرة ينسخ القالب ويكتب البيانات في مداخل متّفق عليها مثل النطاقات المسمّاة والجداول، فينفصل تعديل التخطيط عن تعديل منطق الأعمال.
    tp1["جانب القالب"] --> tp2["يحمل المظهر والصيغ وإعدادات الطباعة"]
    tc1["جانب الشيفرة"] --> tc2["يكتب القيم في المداخل المتّفق عليها فقط"]
    tp2 --> tw1["ينفصل تعديل التخطيط عن تعديل الأعمال"]
    tc2 --> tw1

الشكل 5: جوهر هذا الأسلوب فصل موضع المظهر عن موضع المنطق.

3.4 أسلوب الإبقاء على أصول VBA القائمة

إن كانت .xlsm وVBA القائمة لا تزال حيّة، فالأكثر طبيعية غالباً ألا تعيد بناء كل شيء دفعة واحدة. تقسيم من نوع: واجهة التقرير والتشطيب الأخير يبقيان في VBA، والحساب الثقيل وDB / HTTP ومنطق الأعمال ينتقلان إلى جانب C# / .NET، تقسيم واقعي جداً.

المهم هنا ألّا تبقى المسؤوليات غامضة.

• جانب VBA: السلوك داخل المصنّف
• جانب .NET: جلب البيانات ومعالجة الأعمال
• الحدود بينهما تُثبَّت بنطاقات مسمّاة وجداول وواجهات معلنة

flowchart TB
    accTitle: تقسيم المسؤوليات بين VBA القائمة و.NET
    accDescr: يبين المخطّط أنه عند الإبقاء على xlsm وVBA القائمة يتولّى جانب VBA السلوك داخل المصنّف ويتولّى جانب .NET جلب البيانات ومعالجة الأعمال، وأن الحدود بينهما تُثبَّت بنطاقات مسمّاة وجداول وواجهات معلنة.
    vb1["جانب VBA"] --> vb2["السلوك داخل المصنّف"]
    nt1["جانب .NET"] --> nt2["جلب البيانات ومعالجة الأعمال"]
    vb2 --> bd1["تُثبَّت الحدود بنطاقات مسمّاة ونحوها"]
    nt2 --> bd1

الشكل 6: سرّ الإبقاء على الأصل تثبيت الحدود وألا تبقى المسؤوليات غامضة.

3.5 حالة استخدام Microsoft 365 / Graph

إن كان ملف Excel على OneDrive / SharePoint من البداية، وأردت استخداماً مشتركاً من تطبيق ويب أو جوّال، دخل Excel API في Microsoft Graph ضمن الخيارات.

غير أنه ليس حلاً عاماً لإنتاج ملفات عشوائية بكميات على جهاز محلّي. الصلاحيات ومكان الحفظ والجلسة والتشغيل تفترض M365 من البداية.

3.6 هل يلزم أن يكون Excel أصلاً؟

إن كان متطلّب التقرير «جدولاً يلمسه إنسان لاحقاً»، فاختيار Excel طبيعي. غير أن متطلّبات كهذه كثيراً ما تكون صيغة أخرى أصدق.

• طباعة وحفظ -> PDF
• إدخال إلى نظام آخر -> CSV / TSV / JSON
• يكفي العرض في المتصفّح -> HTML / شاشة ويب
• الغرض الرئيس تجميع وتصور -> BI أو لوحة معلومات

flowchart TB
    accTitle: التحقق مما إذا كان Excel لازماً
    accDescr: يبين المخطّط أن اختيار Excel طبيعي إن كان المتطلّب جدولاً يلمسه إنسان لاحقاً، أما الطباعة والحفظ أو الإدخال إلى نظام آخر أو العرض في المتصفّح أو التجميع والتتصور كغرض رئيس فكثيراً ما تكون صيغة أخرى أصدق.
    ne1{"هل هو جدول يلمسه إنسان لاحقاً؟"}
    ne1 -->|"يلمسه"| ne2["اختيار Excel طبيعي"]
    ne1 -->|"لا يلمسه"| ne3["ادرس صيغة أخرى"]
    ne3 -.-> ne4["PDF / CSV / شاشة ويب / BI وغيرها"]

الشكل 7: استنتج صيغة الإخراج من الغرض، ولا تجعل Excel القيمة الافتراضية.

4. مقارنة الأساليب

إن صففنا الفروق في جدول واحد صارت كالتالي.

5. الاختيار بحسب المتطلّبات الشائعة

5.1 الإخراج على جهاز المستخدم ثم التحرير مباشرة

هنا قالب مع توليد مباشر خيار قوي جداً. المستخدم يفتح الناتج في Excel بعد الإخراج، فيجوز ترك التحرير النهائي لـ Excel.

5.2 التوليد بكميات كبيرة في دفعة ليلية أو خدمة

إن دخلت دفعة ليلية، فالأسلم أن تبدأ بإخراج أتمتة COM من المرشّحين. اجعل التوليد يميل إلى التوليد المباشر لـ .xlsx، ودع المستخدم يفتح الملف في Excel لاحقاً إن لزم.

flowchart TB
    accTitle: مسار العمل في الدفعة الليلية
    accDescr: يبين المخطّط أنه في التوليد بكميات كبيرة في دفعة ليلية أو خدمة يكون الأسلم إخراج أتمتة COM من المرشّحين أولاً، والميل بالتوليد إلى التوليد المباشر لـ xlsx، وترك المستخدم يفتح الملف لاحقاً إن لزم.
    nb1["نريد توليداً كبيراً في دفعة ليلية"] --> nb2["أخرج أتمتة COM أولاً"]
    nb2 --> nb3["مل نحو التوليد المباشر لـ xlsx"]
    nb3 -.-> nb4["يفتحه المستخدم لاحقاً إن لزم"]

الشكل 8: تصميم التشغيل بلا مشغّل يبدأ بالطرح.

5.3 الإبقاء على .xlsm / VBA القائمة

إن كانت الأصول القائمة حيّة، فالأوقع الإبقاء على .xlsm قالباً والاكتفاء بحقن البيانات من الخارج.

5.4 صفوف التفاصيل كبيرة

حدّ ورقة Excel الواحدة 1,048,576 صفّاً × 16,384 عموداً. إن كانت التفاصيل كبيرة فقرّر هذا أولاً.

• بعد كم صفّاً نقسم الورقة
• بعد كم عنصراً نقسم الملف
• أليس CSV أصدق أصلاً

flowchart TB
    accTitle: ما يُقرَّر مسبقاً عندما تكون التفاصيل كبيرة
    accDescr: يبين المخطّط أن لورقة Excel الواحدة حدّاً لعدد الصفوف والأعمدة، لذا عندما تكون التفاصيل كبيرة يُقرَّر أولاً معيار تقسيم الورقة ومعيار تقسيم الملف وما إذا كان CSV أصدق أصلاً.
    lg1["التفاصيل كبيرة"] --> lg2["للورقة الواحدة حدّ"]
    lg2 --> lg3["قرّر معيار تقسيم الورقة"]
    lg2 --> lg4["قرّر معيار تقسيم الملف"]
    lg2 -.-> lg5["أعد النظر: هل CSV أصدق"]

الشكل 9: لا تنتظر الاصطدام بالحد؛ قرّر سياسة التقسيم مسبقاً.

6. بنية يسهل توصيتها عملياً

ما يصعب كسره عملياً بنية من أربع طبقات.

حسن هذا التقسيم أن الشيفرة تقلّ تبعيتها لمظهر Excel.

6.1 ماذا يسري بين الطبقات

المهم ما يعبر حدود الطبقة. إن تحدّد ذلك أمكن المضي في تغيير التخطيط وتغيير منطق الأعمال كلٍّ على حدة.

flowchart LR
    DB[("DB / API / ملف")] -->|"بيانات خام"| RM["ReportModel<br/>يشكّل القيم اللازمة<br/>للتقرير ويحفظها"]
    TP["Template<br/>xlsx أو xlsm<br/>المظهر والصيغ وإعدادات الطباعة"] -->|"مصنّف منسوخ"| BD
    RM -->|"أزواج اسم وقيمة"| BD["Binder<br/>تكتب القيم في النطاقات المسمّاة<br/>والجداول"]
    BD -->|"مصنّف فيه القيم"| FN["Finisher<br/>تحويل إلى PDF أو استدعاء VBA<br/>عند الحاجة فقط"]
    FN -->|"ناتج"| OUT["xlsx / xlsm / PDF"]
    BD -.->|"إن لم تلزم Finisher<br/>يكتمل هنا"| OUT

الشكل 10: ما يسري بين الطبقات الأربع أزواج اسم وقيمة فقط، وعناوين الخلايا لا تخرج من Binder.

ما يعبر الحدود أزواج اسم وقيمة فقط، ولا تُخرج عناوين الخلايا خارج Binder. إن وصلت اعتبارات القالب حتى ReportModel، فالتصميم بدأ ينهار عند تلك النقطة.

6.2 أصغر مثال تنفيذ

كتابة الإدراج في قالب بـ ClosedXML تكون كالتالي. عرّف مسبقاً في قالب Invoice.xlsx النطاقات المسمّاة Rpt_Title وRpt_IssuedOn وRpt_CustomerName وRpt_DetailRows.

// C# / .NET 8 + ClosedXML（MIT ライセンス）
//   dotnet add package ClosedXML
using ClosedXML.Excel;

// ReportModel 相当。セル番地は一切持たない
var rows = new (string Code, string Name, int Qty, decimal UnitPrice)[]
{
    ("A-100", "محمل كروي", 12, 480m),
    ("A-205", "عمود", 3, 12800m),
    ("B-010", "حامل تثبيت", 30, 260m),
};

const string TemplatePath = @"templates\Invoice.xlsx";
string outputDir = "output";
Directory.CreateDirectory(outputDir);

// ファイル名は「秒までの時刻」で作らないこと。1件ずつ回すバッチでは、
// 2件が同じ秒に入った瞬間に同じ名前になり、後から保存したほうが
// 先の帳票を上書きします。消えたことに誰も気づかないのが厄介なところです。
// 帳票を一意に決める業務上の識別子(ここでは請求書番号)を必ず入れます。
string invoiceNo = "INV-2026-000123";     // 呼び出し側から受け取る
string outputPath = Path.Combine(outputDir, $"Invoice_{invoiceNo}.xlsx");

// 1. テンプレートを開く。保存は別名にするので、テンプレート自体は書き換わらない
using var workbook = new XLWorkbook(TemplatePath);

// 2. ヘッダーは名前付きセルへ。コードにセル番地が出てこないのが要点
workbook.Cell("Rpt_Title").Value = "فاتورة";
workbook.Cell("Rpt_IssuedOn").Value = DateTime.Today;   // 値として入れる。表示形式はテンプレート側
workbook.Cell("Rpt_CustomerName").Value = "شركة العينة";

// 3. 明細は名前付き範囲を入口にし、範囲内の相対位置で書く
var detail = workbook.Range("Rpt_DetailRows");
if (rows.Length > detail.RowCount())
{
    // 用意した行数を超えた。黙って切り捨てず、ここで止める
    throw new InvalidOperationException(
        $"عدد بنود التفاصيل {rows.Length} لكن Rpt_DetailRows في القالب {detail.RowCount()} صفّاً." +
        " زِد صفوف القالب أو قسّم الورقة.");
}

for (int i = 0; i < rows.Length; i++)
{
    var row = rows[i];
    detail.Cell(i + 1, 1).Value = row.Code;        // 範囲内の 1 始まりの相対位置
    detail.Cell(i + 1, 2).Value = row.Name;
    detail.Cell(i + 1, 3).Value = row.Qty;
    detail.Cell(i + 1, 4).Value = row.UnitPrice;
}

// 4. 別名で保存する。テンプレートは読み取り専用の資産として残す。
//    書き込みは同じフォルダーの一時ファイルへ行い、書き切ってから本来の名前へ
//    付け替えます。outputPath へ直接書くと、途中で失敗したとき(ディスク満杯、
//    ブックの不整合など)に「途中まで書けた .xlsx」が業務上のファイル名で残ります
string tempPath = Path.Combine(
    Path.GetDirectoryName(outputPath) ?? string.Empty,   // 付け替えを同一ボリューム内に収める
    $".{Path.GetFileName(outputPath)}.{Guid.NewGuid():N}.tmp");

try
{
    using (var stream = new FileStream(tempPath, FileMode.CreateNew, FileAccess.Write, FileShare.None))
    {
        workbook.SaveAs(stream);
    }

    // 既に同名があれば IOException。同名が来たときに黙って上書きせず、
    // その場で気づけます(FileMode.CreateNew と同じ方針)
    File.Move(tempPath, outputPath);
}
catch
{
    // 失敗したら痕跡を残さない。残すと、次の実行が同じ名前で再試行できなくなる
    try { File.Delete(tempPath); } catch (IOException) { }
    throw;
}
Console.WriteLine($"تمّ الإخراج: {outputPath}");

ما تنتبه إليه هذه الشيفرة خمس نقاط.

• عناوين الخلايا لا تظهر في الشيفرة. مدخل الحقن نطاقات مسمّاة فقط. حتى إن أضفت صفّاً في القالب لا تتغيّر هذه الشيفرة
• لا تُكتب فوق القالب. المصنّف المفتوح يُحفظ دائماً باسم آخر
• التاريخ والرقم يُدخلان قيماً. إن أدخلتهما نصّاً منسّقاً تعطّل الترتيب والتجميع في Excel
• فيض التفاصيل يوقف التنفيذ باستثناء. أسوأ كسر في تقرير هو الاقتطاع دون تنبيه. هنا تُسقط سياسة 5.4 في التنفيذ
• الاسم الأصلي يُعطى بعد اكتمال الكتابة. قد يفشل SaveAs بعد أن يبدأ الكتابة. امتلاء القرص، وانقطاع المشاركة، وعدم اتساق محتوى المصنّف، كلها تقع. إن كتبت مباشرة إلى outputPath بقي عندئذ ملف مقطوع باسم مثالي مثل Invoice_INV-2026-000123.xlsx. يحكم الناس بالاسم فلا يميّزونه عن تقرير مكتمل. وفوق ذلك يرفض FileMode.CreateNew الملف الموجود، فيتوقف إعادة التشغيل أيضاً لأن «الملف موجود سلفاً». إن كتبت إلى ملف مؤقّت ثم بدّلت بـ File.Move لم يظهر ذلك الاسم إلا بعد اكتمال المحتوى. جعل وجهة التبديل المجلد نفسه لأن Move عبر الأقراص يصبح نسخاً وقد ينقطع في المنتصف

حتى إن حملت المبلغ بـ decimal، فإنه يصير عند دخول صيغة ملف Excel عدداً عشرياً مزدوج الدقة. إن كان معيار التقريب مهمّاً للأعمال، فالأسلم صنع قيمة مقرّبة مسبقاً في جانب ReportModel لا ترك الأمر لصيغ Excel.

إن جعلت .xlsm قالباً فالمسار نفسه، لكن اجعل امتداد الحفظ .xlsm. البنية التي تبقي الماكرو مع الحقن كما في 3.4.

flowchart TB
    accTitle: مسار الحفظ عبر ملف مؤقّت
    accDescr: يبين المخطّط مسار الكتابة كاملة إلى ملف مؤقّت في المجلد نفسه ثم التبديل إلى الاسم الأصلي بـ File.Move، وحذف الملف المؤقّت عند الإخفاق، حتى لا يبقى ملف مقطوع باسم الملف التشغيلي.
    sv1["اكتب إلى ملف مؤقّت في المجلد نفسه"] --> sv2{"هل اكتملت الكتابة؟"}
    sv2 -->|"نجاح"| sv3["بدّل إلى الاسم الأصلي بـ File.Move"]
    sv2 -->|"إخفاق"| sv4["احذف الملف المؤقّت وأبلغ بالاستثناء"]
    sv3 -.-> sv5["لا يظهر الاسم إلا بعد اكتمال المحتوى"]

الشكل 11: اسم الملف التشغيلي لا يُعطى إلا لملف مكتمل.

7. المطبات

7.1 لا تجعل عنوان الخلية مواصفة أعمال

إن بدأ Cells[12, 7] يمثّل قاعدة أعمال، صار تغيير التخطيط تغييراً في المواصفة كما هو. الشيفرة التي تلمس التقرير عبر نطاقات مسمّاة أو أسماء جداول تعيش أطول.

flowchart TB
    accTitle: لا تجعل عنوان الخلية مواصفة أعمال
    accDescr: يبين المخطّط أنه إن بدأ عنوان الخلية يمثّل قاعدة أعمال صار تغيير التخطيط تغييراً في المواصفة، لذا تعيش الشيفرة أطول إن لمست التقرير عبر نطاقات مسمّاة أو أسماء جداول.
    ad1["عنوان الخلية يمثّل قاعدة أعمال"] --> ad2["تغيير التخطيط يصير تغييراً في المواصفة"]
    nm1["المرور عبر نطاق مسمّى أو اسم جدول"] --> nm2["الشيفرة تصمد حتى مع تغيير التخطيط"]

الشكل 12: اللمس بالاسم لا بالعنوان هو ما يحدّد عمر شيفرة التقرير.

7.2 لا تجعل الخلايا المدمجة مدخل بيانات

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

7.3 لا تملأ الأرقام والتواريخ «نصّاً بمظهر جاهز»

أدخل القيمة قيمة، ومل بالمظهر إلى تنسيق الخلية؛ هذا أصدق.

7.4 لا تترك تغيير القالب تشغيلاً بلا ضوابط

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

7.5 إن استخدمت COM فلا تتهاون في bitness وإدارة العمر

في أتمتة COM والربط مع VBA تؤثّر بهدوء فروق 32-bit / 64-bit وتنظيف عملية Excel وقفل الملفات وفروق بيئة المستخدم.

8. الخلاصة

يبدو إخراج تقارير Excel سطراً واحداً هو «الإخراج إلى Excel»، بينما ينبغي في الواقع تقرير عدّة تفرّعات مسبقاً.

• هل تشغّل تطبيق Excel
• أم تنشئ ملف Excel
• جهاز المستخدم أم تشغيل بلا مشغّل
• هل تبقي VBA القائمة أو .xlsm
• هل الناتج النهائي Excel أم PDF أو CSV

عملياً المرشّح الأوّل قالب مع توليد مباشر قوي جداً. ثم تضيف عند الحاجة إعادة استخدام VBA القائمة أو معالجة Excel النهائية على جهاز المستخدم؛ هذا الشكل يسهل تماسكه.

flowchart TB
    accTitle: كيف تُبنى بنية يسهل تماسكها
    accDescr: يبين المخطّط أن الوضع العملي يضع قالباً وتوليداً مباشراً محوراً، ثم يضيف عند الحاجة إعادة استخدام VBA القائمة أو المعالجة النهائية لـ Excel على جهاز المستخدم.
    sm1["ضع القالب والتوليد المباشر محوراً"] --> sm2["أضف إعادة استخدام VBA القائمة إن لزم"]
    sm1 --> sm3["أضف المعالجة النهائية على جهاز المستخدم إن لزم"]

الشكل 13: حدّد محوراً واحداً ثم أضف الاستثناءات فقط فيسهل التماسك.

9. روابط مرجعية

مرتّبة بترتيب القراءة.

9.1 ما يُقرأ قبل تقرير الأسلوب

• Considerations for server-side Automation of Office — مصدر عبارة 3.1 «أتمتة Office على جانب الخادم غير موصى بها وغير مدعومة». أكثر ما نستخدمه سنداً لاختيار الأسلوب
• Considerations for unattended automation of Office in the Microsoft 365 for unattended RPA environment — شروط بيئة RPA في M365، وهي الاستثناء للمقالة أعلاه
• Excel specifications and limits — قائمة الحدود ومنها 1,048,576 صفّاً × 16,384 عموداً في 5.4

9.2 ما يُستخدم في التوليد المباشر

• About the Open XML SDK for Office — أساس تركيب .xlsx دون Excel
• ClosedXML — الغلاف المستخدم في مثال 6.2. ترخيص MIT
• NPOI — خيار عندما يلزم التعامل مع .xls القديم. Apache License 2.0
• EPPlus — راجع شروط ترخيص الإصدار 5 وما بعده حتماً قبل الاعتماد

9.3 عند التعامل على M365 / SharePoint

• Microsoft Learn, Working with Excel in Microsoft Graph
• Microsoft Learn, Use the Microsoft Graph API to access OneDrive and SharePoint

9.4 ما يُتعمّق فيه عند التعامل مع مصنّفات كبيرة

• Microsoft Learn, How to: Copy a worksheet using SAX (Simple API for XML) — أسلوب التعامل مع مصنّف لا يسعه الذاكرة بـ Open XML SDK. لا يلزم عادة في نطاق الإدراج في قالب

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

أيّهما أختار لإخراج تقارير Excel: أتمتة COM أم توليد الملف مباشرة؟

ما ينبغي النظر إليه أولاً ليس اسم المكتبة، بل هل ستشغّل تطبيق Excel أم ستنشئ ملف Excel. في كثير من تقارير الأعمال يكون الطبيعي «تركيب ملف Excel» لا «تشغيل Excel»، وإذا كان المستخدم سيحرّر التقرير لاحقاً فإن المرشّح الأوّل هو قالب مع توليد مباشر لـ .xlsx/.xlsm. لا تستخدم أتمتة COM إلا عندما تحتاج فعلاً إلى سلوك تطبيق Excel نفسه، واحصرها عندئذ في تشغيل بحضور مستخدم على سطح المكتب.

هل يجوز استخدام أتمتة COM لـ Excel على خادم أو في دفعة ليلية؟

الأسلم تجنّبها. Microsoft نفسها لا توصي بأتمتة Office من خادم بلا مشغّل أو من خدمة، ولا تدعمها. تتطلّب أتمتة COM تثبيت Excel، وتحمل مشكلات عمر العملية وقفل الملفات ومربّعات الحوار وbitness والاعتماد على ملف تعريف المستخدم. في الدفعات الليلية والإخراج بكميات كبيرة انحَ نحو التوليد المباشر لـ .xlsx، ودع المستخدم يفتح الملف في Excel لاحقاً إن لزم.

هل يمكن بناء إخراج التقارير مع الإبقاء على أصول .xlsm وVBA القائمة؟

نعم. إذا كانت الأصول القائمة لا تزال حيّة، فلا تعد بناء كل شيء دفعة واحدة؛ الأوقع الإبقاء على .xlsm قالباً والاكتفاء بحقن البيانات من الخارج. أبقِ واجهة التقرير والتشطيب الأخير في VBA، وانقل الحساب الثقيل وDB وHTTP ومنطق الأعمال إلى جانب C#/.NET. المهم ألا تبقى المسؤوليات غامضة، وثبّت الحدود بين الجانبين بنطاقات مسمّاة وجداول وواجهات معلنة.

ما المطبات التي ينبغي تجنّبها عند تنفيذ تقارير Excel؟

الأهم أولاً ألا تجعل عنوان الخلية مواصفة أعمال؛ المس التقرير عبر نطاقات مسمّاة أو أسماء جداول بدل Cells[12, 7]. الخلايا المدمجة للعرض فقط فلا تجعلها مدخل حقن، وأدخل الأرقام والتواريخ قيماً واترك المظهر لتنسيق الخلية، وعامل القالب مواصفة فعلية تخضع لإدارة الإصدارات والمراجعة. وحدّ ورقة Excel الواحدة 1,048,576 صفّاً × 16,384 عموداً، فإن كانت التفاصيل كبيرة فقرّر مسبقاً سياسة تقسيم الأوراق أو الملفات.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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