أتمتة معالجة المستندات باستخدام OpenClaw

كل عمل يعمل على المستندات. الفواتير، والعقود، وأوامر الشراء، وإيصالات التسليم، وتقارير الامتثال، ومطالبات النفقات - لا يتقلص الحجم أبدًا، كما أن تكلفة معالجتها يدويًا هائلة. تشير التقديرات المتحفظة إلى أن متوسط ​​تكلفة معالجة الفواتير اليدوية يتراوح بين 12 إلى 16 دولارًا لكل مستند، مع معدلات خطأ تتراوح بين 3% و5%. اضرب ذلك في آلاف المستندات شهريًا وستكتب حالة التشغيل الآلي نفسها.

يجمع وكلاء معالجة المستندات في OpenClaw بين التعرف الضوئي على الحروف واستخراج البيانات المنظمة وقواعد التحقق من الصحة وتكامل تخطيط موارد المؤسسات (ERP) في مسار واحد مستقل. والنتيجة هي نظام يتلقى المستند، ويفهم نوعه ومحتواه، ويتحقق من صحة البيانات وفقًا لقواعد العمل الخاصة بك، ويوجه المعلومات المستخرجة إلى الوجهة الصحيحة - دون تدخل بشري لغالبية المستندات.

الوجبات الرئيسية

• يتعامل وكلاء مستندات OpenClaw مع ملفات PDF والصور الممسوحة ضوئيًا ورسائل البريد الإلكتروني التي تحتوي على مرفقات وتنسيقات الملفات المنظمة (CSV وXML وEDI) من خلال مسار موحد.
• بوابات تسجيل جودة التعرف الضوئي على الحروف (OCR) استخراج الذكاء الاصطناعي - تؤدي عمليات المسح منخفضة الجودة إلى طلب إعادة المسح قبل متابعة المعالجة.
• تستخدم طبقة الاستخراج مزيجًا من تحليل التخطيط والتعرف على الكيانات المسماة والتحليل المستند إلى LLM لتحقيق أقصى قدر من الدقة عبر تنسيقات المستندات.
• تقوم مهارات التحقق من الصحة بفحص البيانات المستخرجة ومقارنتها بالسجلات الرئيسية للموردين وأرقام أوامر الشراء وأكواد الضرائب وقواعد العمل قبل أن تصل أي بيانات إلى نظام تخطيط موارد المؤسسات (ERP) الخاص بك.
• لا يوجه التعامل مع الاستثناء سوى المستندات الغامضة حقًا إلى البشر - يقدم الوكيل نموذجًا مملوءًا مسبقًا بأفضل تخمين حتى يؤكد الإنسان فقط بدلاً من إعادة الإدخال.
• يتعامل المسار مع أكثر من 300 نوع من المستندات خارج الصندوق؛ يمكن إضافة قوالب مخصصة من خلال محرر مخطط منخفض التعليمات البرمجية.
• متوسط ​​زمن الوصول من طرف إلى طرف من استلام المستند إلى إدخال ERP أقل من 90 ثانية للمستندات النظيفة.
• تقوم ECOSIRE ببناء وإدارة مسارات معالجة مستندات OpenClaw المتكاملة مع Odoo، وSAP، وQuickBooks، وأنظمة تخطيط موارد المؤسسات (ERP) المخصصة.

---

نظرة عامة على بنية معالجة المستندات

يتكون مسار معالجة مستندات OpenClaw للإنتاج من ست مراحل، يتم تنفيذ كل منها كمهارة واحدة أو أكثر:

Document Ingestion
        ↓
[ Classifier Agent ]     — document type detection, routing
        ↓
[ Extraction Agent ]     — OCR + structured data extraction
        ↓
[ Validation Agent ]     — business rule validation, master data lookup
        ↓
[ Enrichment Agent ]     — GL coding, cost center assignment, approver lookup
        ↓
[ Integration Agent ]    — ERP/downstream system write
        ↓
[ Exception Agent ]      — handles ambiguous documents, requests human review

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

---

استيعاب المستند: قبول كل التنسيق

تصل المستندات عبر قنوات متعددة: مرفقات البريد الإلكتروني، وإسقاط نظام الملفات، وتحميلات واجهة برمجة التطبيقات، وبوابات الفاكس إلى البريد الإلكتروني، وبوابات البائعين. تعمل طبقة العرض على تطبيع كل هذه العناصر في مهمة مستند قياسية.

export const DocumentIngester = defineSkill({
  name: "document-ingester",
  tools: ["email", "storage", "queue"],
  async run({ input, tools }) {
    let rawFile: Buffer;
    let mimeType: string;

    if (input.source === "email") {
      const attachment = await tools.email.getAttachment(input.emailId, input.attachmentIndex);
      rawFile = attachment.buffer;
      mimeType = attachment.mimeType;
    } else if (input.source === "storage") {
      rawFile = await tools.storage.get(input.storageKey);
      mimeType = detectMimeType(rawFile);
    }

    // Normalize to PDF for consistent downstream processing
    const normalizedPdf = mimeType === "application/pdf"
      ? rawFile
      : await convertToPdf(rawFile, mimeType);

    const storageKey = `incoming/${Date.now()}-${generateId()}.pdf`;
    await tools.storage.put(storageKey, normalizedPdf);

    return {
      storageKey,
      originalSource: input.source,
      originalMimeType: mimeType,
      pagCount: await getPdfPageCount(normalizedPdf),
    };
  },
});

تقوم خطوة التسوية بتحويل مستندات Word وملفات Excel وملفات الصور (JPEG وPNG وTIFF) ونصوص HTML الخاصة بالبريد الإلكتروني إلى PDF قبل تمريرها في اتجاه مجرى النهر. لا يتلقى وكلاء المصب سوى ملفات PDF - وهذا يبسط بشكل كبير التعرف الضوئي على الحروف وتحليل التخطيط.

---

تصنيف المستندات: معرفة ما لديك

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

يستخدم المصنف نهجا من مرحلتين:

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

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

export const ClassifyDocument = defineSkill({
  name: "classify-document",
  tools: ["storage", "classification-model"],
  async run({ input, tools }) {
    const pdfBuffer = await tools.storage.get(input.storageKey);
    const layoutFeatures = await extractLayoutFeatures(pdfBuffer);
    const textContent = await performOcr(pdfBuffer, { mode: "fast" });

    const classification = await tools.classificationModel.classify({
      layoutFeatures,
      textContent: textContent.slice(0, 2000), // First 2000 chars for speed
    });

    if (classification.confidence < 0.70) {
      return {
        type: "unknown",
        confidence: classification.confidence,
        requiresManualClassification: true,
      };
    }

    return {
      type: classification.label,
      confidence: classification.confidence,
      requiresManualClassification: false,
      extractionTemplate: TEMPLATE_MAP[classification.label],
    };
  },
});

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

---

التعرف الضوئي على الحروف والاستخراج: إخراج البيانات بدقة

عامل الاستخراج هو المكان الذي تعيش فيه معظم التعقيدات التقنية. فهو يجمع بين مخرجات التعرف الضوئي على الحروف (OCR) وتحليل التخطيط والتحليل المستند إلى LLM لإنتاج بيانات منظمة من مستندات غير منظمة.

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

بالنسبة للمستندات التي اجتازت اختبارات جودة التعرف الضوئي على الحروف، تتم عملية الاستخراج عبر ثلاث مراحل:

الممر 1 — مطابقة القالب: بالنسبة للموردين المعروفين وتنسيقات المستندات، يوفر قالب الاستخراج مواضع الحقل (الإحداثيات أو نقاط ارتساء التعبير العادي). تعتبر مطابقة القالب سريعة ودقيقة للمستندات المنظمة من مصادر معروفة.

الممر 2 — التعرف على الكيان المسمى: يحدد NER المبالغ والتواريخ والعناوين والمعرفات (أرقام الفاتورة وأرقام أوامر الشراء وأرقام ضريبة القيمة المضافة) وحدود العناصر التي فاتتها مطابقة القالب.

التمرير 3 — استدلال LLM: بالنسبة للحقول الغامضة أو عندما ينتج عن التمريرين الأولين قيم منخفضة الثقة، يقوم LLM بتحليل سياق النص المحيط لاستنتاج القيمة الصحيحة.

export const ExtractInvoiceData = defineSkill({
  name: "extract-invoice-data",
  tools: ["storage", "ocr-service", "llm"],
  async run({ input, tools, memory }) {
    const buffer = await tools.storage.get(input.storageKey);
    const ocrResult = await tools.ocrService.extract(buffer, { enhanceScannedPages: true });

    if (ocrResult.averageConfidence < 0.80) {
      return { success: false, reason: "LOW_OCR_QUALITY", ocrConfidence: ocrResult.averageConfidence };
    }

    // Pass 1: Template matching
    const templateFields = applyTemplate(ocrResult, input.extractionTemplate);

    // Pass 2: NER for missing fields
    const nerFields = await extractWithNer(ocrResult.text, { fieldTypes: ["amount", "date", "id"] });

    // Pass 3: LLM for remaining low-confidence fields
    const lowConfidenceFields = mergeAndFindGaps(templateFields, nerFields, { minConfidence: 0.85 });
    const llmFields = lowConfidenceFields.length > 0
      ? await tools.llm.extractFields(ocrResult.text, lowConfidenceFields)
      : {};

    const extracted = mergeExtractions(templateFields, nerFields, llmFields);
    await memory.working.set("extractedData", extracted);

    return { success: true, data: extracted, fieldConfidences: getFieldConfidences(extracted) };
  },
});

---

التحقق من الصحة: اكتشاف الأخطاء قبل أن تصل إلى نظام تخطيط موارد المؤسسات (ERP) الخاص بك

لا يتم أبدًا كتابة البيانات الأولية المستخرجة مباشرة إلى نظام تخطيط موارد المؤسسات (ERP) الخاص بك. يقوم وكيل التحقق بفحص كل حقل وفقًا لقواعد عملك وبياناتك الرئيسية قبل نشر أي شيء.

تتضمن عمليات التحقق من صحة فاتورة البائع ما يلي:

• المورد موجود: يتطابق اسم المورد ورقم ضريبة القيمة المضافة مع سجل في مدير البائع.
• مطابقة أمر الشراء: يتطابق رقم أمر الشراء الموجود في الفاتورة مع أمر شراء مفتوح، وتكون المبالغ ضمن حدود التسامح (عادةً ±5% لمرونة تحرير الفواتير).
• كشف التكرارات: لم تتم معالجة رقم الفاتورة من هذا البائع خلال آخر 180 يومًا.
• حساب الضريبة: إجماليات البنود بالإضافة إلى الضريبة تساوي إجمالي الفاتورة، ضمن تفاوت التقريب.
• العملة وسعر الصرف: يتم التحقق من صحة الفواتير بالعملة الأجنبية مقابل سعر الصرف في تاريخ الفاتورة.
• فترة دفتر الأستاذ: يقع تاريخ الفاتورة ضمن فترة محاسبية مفتوحة.

export const ValidateInvoice = defineSkill({
  name: "validate-invoice",
  tools: ["erp", "vendor-master"],
  async run({ input, tools }) {
    const errors: ValidationError[] = [];

    // Vendor validation
    const vendor = await tools.vendorMaster.findByVatNumber(input.data.vendorVat);
    if (!vendor) errors.push({ field: "vendorVat", code: "VENDOR_NOT_FOUND" });

    // PO match
    if (input.data.poNumber) {
      const po = await tools.erp.getPurchaseOrder(input.data.poNumber);
      if (!po) errors.push({ field: "poNumber", code: "PO_NOT_FOUND" });
      else if (Math.abs(po.totalAmount - input.data.totalAmount) / po.totalAmount > 0.05) {
        errors.push({ field: "totalAmount", code: "PO_AMOUNT_MISMATCH" });
      }
    }

    // Duplicate check
    const isDuplicate = await tools.erp.invoiceExists({
      vendorId: vendor?.id,
      invoiceNumber: input.data.invoiceNumber,
    });
    if (isDuplicate) errors.push({ field: "invoiceNumber", code: "DUPLICATE_INVOICE" });

    return {
      valid: errors.length === 0,
      errors,
      validatedData: errors.length === 0 ? input.data : null,
    };
  },
});

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

---

الإثراء: إضافة سياق الأعمال

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

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

---

تكامل تخطيط موارد المؤسسات (ERP): كتابة البيانات بدقة من المرة الأولى

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

export const PostToErp = defineSkill({
  name: "post-to-erp",
  tools: ["erp"],
  async run({ input, tools }) {
    const correlationId = hashDocument(input.storageKey);

    const result = await tools.erp.createVendorBill({
      correlationId, // ERP uses this for idempotency
      vendorId: input.enrichedData.vendorId,
      invoiceNumber: input.enrichedData.invoiceNumber,
      invoiceDate: input.enrichedData.invoiceDate,
      lineItems: input.enrichedData.lineItems,
      taxLines: input.enrichedData.taxLines,
      paymentTerms: input.enrichedData.paymentTerms,
      glCodes: input.enrichedData.glCodes,
    });

    return {
      erpRecordId: result.id,
      erpRecordUrl: result.url,
      posted: true,
    };
  },
});

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

---

التعامل مع الاستثناءات: التدخل البشري عندما يكون الأمر مهمًا

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

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

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

---

الأسئلة المتداولة

ما هي دقة المستند المطلوبة للتعرف الضوئي على الحروف بدقة؟

بالنسبة للمستندات المطبوعة، فإن 150 نقطة في البوصة هو الحد الأدنى لنتائج التعرف الضوئي على الحروف المقبولة؛ يوصى بـ 300 نقطة في البوصة لاستخراج موثوق. بالنسبة للمستندات المكتوبة بخط اليد أو المستندات ذات أحجام الخطوط الصغيرة جدًا، يفضل 400 نقطة في البوصة أو أعلى. تحدد مهارة تقييم جودة التعرف الضوئي على الحروف (OCR) المستندات التي تقل عن الحد الأدنى قبل بدء الاستخراج، مما يؤدي إلى طلب إعادة المسح تلقائيًا.

كيف يتعامل النظام مع المستندات متعددة الصفحات؟

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

هل يمكن للنظام أن يتعلم من التصحيحات التي يجريها البشر؟

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

كيف يتم التعامل مع المستندات المكتوبة بخط اليد؟

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

ما هي اللغات المدعومة للاستخراج؟

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

كيف يتم الحفاظ على سرية الوثيقة؟

يتم تشفير المستندات أثناء النقل (TLS 1.3) وفي حالة عدم النشاط (AES-256). تتم معالجة كل مستند في سياق معزول، ولا تتم مشاركة محتوى المستند بين المؤسسات. بالنسبة للمستندات الحساسة للغاية (العقود القانونية والبيانات المالية)، يمكنك تكوين المسار لاستخدام LLM محليًا لطبقة الاستدلال، مع الاحتفاظ بمحتوى المستند بالكامل داخل محيط شبكتك.

ما هو معدل الدقة النموذجي لمعالجة الفاتورة؟

بالنسبة للفواتير المنظمة من الموردين المعروفين مع مطابقة القالب، تتجاوز الدقة على مستوى الحقل عادةً 99.5% بعد معايرة القالب. بالنسبة للفواتير غير المنظمة من الموردين الجدد، تتراوح الدقة عادةً بين 95 و98% في المحاولة الأولى، وتتحسن مع تعلم النظام لتنسيق البائع. المقياس الرئيسي الذي يجب تتبعه هو معدل الاستثناء — حيث ترى خطوط الأنابيب التي تم تكوينها جيدًا معدلات استثناء أقل من 5% من إجمالي حجم المستند.

---

الخطوات التالية

تعد المعالجة اليدوية للمستندات بمثابة مركز تكلفة لا يضيف أي قيمة تنافسية. تعمل أتمتة معالجة المستندات في OpenClaw على تحويلها من عملية كثيفة الموظفين إلى مسار آلي يتعامل مع 95%+ من حجم المستندات الخاصة بك دون تدخل بشري.

يتخصص [فريق تنفيذ OpenClaw] (/services/openclaw) التابع لـ ECOSIRE في بناء مسارات معالجة المستندات المتكاملة مع Odoo وSAP وQuickBooks وأنظمة تخطيط موارد المؤسسات (ERP) المخصصة. نحن نتعامل مع تصميم قالب تصنيف المستندات، ومعايرة التعرف الضوئي على الحروف، وتكوين قاعدة التحقق من الصحة، وتكامل تخطيط موارد المؤسسات (ERP)، وإعداد سير العمل الاستثنائي - مما يوفر نظامًا جاهزًا للإنتاج في غضون ستة إلى ثمانية أسابيع.

اتصل بـ ECOSIRE للبدء بمراجعة معالجة المستندات للعملية الحالية.