16 يناير 2026·7 دقيقة
سير العمل المتمركز حول المستند: نموذج البيانات وأنماط واجهة المستخدم
شرح سير العمل المتمركز حول المستند مع نماذج بيانات عملية وأنماط واجهة مستخدم لإدارة الإصدارات والمعاينات والبيانات الوصفية والحالات الواضحة.
شرح سير العمل المتمركز حول المستند مع نماذج بيانات عملية وأنماط واجهة مستخدم لإدارة الإصدارات والمعاينات والبيانات الوصفية والحالات الواضحة.
يكون التطبيق متمركزًا حول المستند عندما يكون المستند نفسه هو المنتج الذي ينشئه المستخدمون ويراجعونه ويعتمدون عليه. البنية مبنية حول ملفات مثل PDF وصور ومسحات وإيصالات، وليس حول نموذج حيث الملف مجرد مرفق.
في سير العمل المتمركز حول المستند، يقوم الناس بالعمل داخل المستند فعليًا: يفتحونه، يتحققون مما تغيّر، يضيفون سياقًا، ويقررون ما سيحدث بعد ذلك. إذا لم يكن المستند موثوقًا، يتوقف فائدة التطبيق.
تحتاج معظم التطبيقات المتمركزة حول المستند إلى بعض الشاشات الأساسية مبكرًا:
تظهر المشاكل بسرعة. يحمّل المستخدم نفس الإيصال مرتين. يقوم شخص بتحرير PDF ثم يعيد رفعه دون شرح السبب. المسح لا يحتوي على تاريخ أو بائع أو مالك. بعد أسابيع، لا يعرف أحد أي إصدار تمت الموافقة عليه أو على أي أساس اتخذ القرار.
تطبيق متمركز حول المستند جيد يبدو سريعًا وموثوقًا. يجب أن يستطيع المستخدمون الإجابة عن هذه الأسئلة خلال ثوانٍ:
تأتي تلك الوضوح من التعريفات. قبل بناء الشاشات، قرر ماذا تعني "الإصدار" و"المعاينة" و"البيانات الوصفية" و"الحالة" في تطبيقك. إذا كانت هذه المصطلحات غامضة، ستحصل على نسخ مكررة وتاريخ مربك وسير مراجعة لا يطابق العمل الحقيقي.
تبدو الواجهة غالبًا بسيطة (قائمة، عارض، بعض الأزرار)، لكن نموذج البيانات يحمل العبء. إذا كانت الكائنات الأساسية صحيحة، يصبح سجل التدقيق والمعاينات السريعة والموافقات الموثوقة أسهل بكثير.
ابدأ بفصل "سجل المستند" عن "محتوى الملف". السجل هو ما يتحدث عنه المستخدمون (فاتورة من ACME، إيصال تاكسي). المحتوى هو البايتات (PDF, JPG) التي قد تُستبدل أو تُعاد معالجتها أو تُنقل دون تغيير معنى المستند داخل التطبيق.
مجموعة عملية من الكائنات للتمثيل:
قرر ما يحصل على معرف لا يتغير أبدًا. قاعدة مفيدة: معرف المستند يبقى للأبد، بينما يمكن إعادة توليد الملفات والمعاينات. تحتاج الإصدارات أيضًا إلى معرفات ثابتة، لأن الناس يشيرون إلى "كيف كان يبدو بالأمس" وستحتاج لسجل تدقيق.
مثّل العلاقات صراحة. للمستند العديد من الإصدارات. كل إصدار يمكن أن يحتوي على معاينات متعددة (أحجام أو صيغ مختلفة). هذا يحافظ على قوائم العرض سريعة لأنها يمكن أن تحمل بيانات معاينة خفيفة الوزن، بينما شاشات التفاصيل تحمل الملف الكامل فقط عند الحاجة.
مثال: يحمّل المستخدم صورة إيصال مجعدة. تنشئ مستندًا، تخزن الملف الأصلي، تولد صورة مصغرة Preview، وتخلق الإصدار v1. لاحقًا، يحمّل المستخدم مسحًا أوضح. يصبح ذلك الإصدار v2 دون أن تُكسر التعليقات أو الموافقات أو البحث المرتبط بالمستند.
يتوقع الناس أن يتغير المستند مع مرور الوقت دون أن "يتحول" إلى عنصر مختلف. أبسط طريقة لتقديم ذلك هي فصل الهوية (المستند) عن المحتوى (الإصدار والملفات).
ابدأ بـمعرف document_id ثابت لا يتغير. حتى لو أعاد المستخدم رفع نفس الـ PDF، أو استبدل صورة ضبابية، أو حمّل مسحًا مصححًا، يجب أن يبقى سجل المستند نفسه. تعلق التعليقات والمهام وسجلات التدقيق بسهولة على معرف دائم.
عامل كل تغيير ذي معنى كسجل version جديد. يجب أن يلتقط كل إصدار من أنشأه ومتى، بالإضافة إلى مؤشرات التخزين (مفتاح الملف، checksum، الحجم، عدد الصفحات) والمخرجات المشتقة (نص OCR، صور معاينة) المرتبطة بذلك الملف بالضبط. تجنب "التحرير في المكان". يبدو أبسط في البداية، لكنه يكسر التتبع ويجعل الأخطاء صعبة التراجع.
للقراءة السريعة، احتفظ بـcurrent_version_id على المستند. معظم الشاشات تحتاج فقط "الأحدث"، لذا لا تحتاج لفرز الإصدارات في كل تحميل. عندما تحتاج التاريخ، حمّل الإصدارات بشكل منفصل واعرض خطًا زمنيًا واضحًا.
التراجع هو مجرد تغيير مؤشر. بدل حذف أي شيء، عيّن current_version_id مرة أخرى إلى إصدار أقدم. هذا سريع وآمن ويحافظ على سجل التدقيق.
للحفاظ على فهم التاريخ، سجّل سبب وجود كل إصدار. حقل reason صغير ومتسق (مع ملاحظة اختيارية) يمنع جدولًا زمنيًا مليئًا بتحديثات غامضة. الأسباب الشائعة: استبدال بالرفع، تنظيف المسح، تصحيح OCR، إزالة حساسية، وتعديل للموافقة.
مثال: فريق المالية يحمل صورة إيصال، يستبدلها بمسح أوضح، ثم يصحح OCR حتى يصبح المبلغ مقروءًا. كل خطوة إصدار جديد، لكن المستند يبقى عنصرًا واحدًا في الصندوق الوارد. إذا كان تصحيح OCR خاطئًا، فإن الرجوع إلى الخلف بنقرة لأنك فقط تغيّر current_version_id.
في سير العمل المتمركز حول المستند، تكون المعاينة غالبًا هي الشيء الرئيسي الذي يتعامل معه المستخدمون. إذا كانت المعاينات بطيئة أو متقلبة، يبدو التطبيق عاطلًا.
عامل توليد المعاينات كمهمة منفصلة، لا شيئًا ينتظر شاشة التحميل لإتمامه. احفظ الملف الأصلي أولاً، أعد التحكم إلى المستخدم، ثم تولّد المعاينات في الخلفية. هذا يحافظ على استجابة الواجهة ويجعل إعادة المحاولة آمنة.
خزّن أحجام معاينة متعددة. حجم واحد لا يناسب كل الشاشات: صورة مصغرة صغيرة للقوائم، صورة متوسطة لواجهات الانقسام، وصور صفحات كاملة للمراجعة التفصيلية (صفحة بصفحة لملفات PDF).
تتبّع حالة المعاينة صراحة حتى تعرف الواجهة دائمًا ما الذي تعرضه: pending, ready, failed, needs_retry. اجعل التسميات صديقة للمستخدم في الواجهة، لكن احتفظ بالحالات واضحة في البيانات.
للحفاظ على سرعة العرض، خزّن القيم المشتقة بجانب سجل المعاينة بدلًا من إعادة حسابها في كل عرض. الحقول الشائعة: عدد الصفحات، عرض وارتفاع المعاينة، الدوران (0/90/180/270)، وصفحة "الأفضل" للصورة المصغرة.
صمّم للتعامل مع ملفات بطيئة وفوضوية. ملف PDF مكون من 200 صفحة أو صورة إيصال مجعدة قد يستغرق معالجته. استخدم التحميل التدريجي: اعرض الصفحة الأولى الجاهزة بمجرد وجودها، ثم املأ الباقي.
مثال: يحمّل المستخدم 30 صورة إيصال. قائمة العرض تظهر الصور المصغرة كـ"قيد المعالجة"، ثم يتحول كل بطاقة إلى "جاهز" عند الانتهاء. إذا فشل بعضها بسبب صورة تالفة، تبقى مرئية مع زر إعادة محاولة واضح بدل اختفائها أو حظر الدفعة بأكملها.
تحول البيانات الوصفية كومة الملفات إلى شيء يمكنك البحث فيه، وفرزه، ومراجعته، والموافقة عليه. تساعد الناس على الإجابة عن أسئلة بسيطة بسرعة: ما هذا؟ من أين؟ هل صالح؟ ما العمل التالي؟
طريقة عملية للحفاظ على نظافة البيانات الوصفية هي فصلها بحسب مصدرها:
تمنع هذه الأقسام النقاشات لاحقًا. إذا كان المبلغ خاطئًا، يمكنك أن ترى ما إذا كان من OCR أو تعديل بشري.
للإيصالات والفواتير، مجموعة صغيرة من الحقول تؤتي ثمارها إذا استخدمتها باستمرار (نفس التسمية، نفس الصيغ). الحقول الأساسية الشائعة: البائع، التاريخ، الإجمالي، العملة، ورقم المستند. اجعلها اختيارية في البداية. يحمل الناس مسحات جزئية وصور ضبابية، وإيقاف التقدم لأن حقل مفقود يبطئ سير العمل بأكمله.
عامل القيم المجهولة كأولوية: استخدم حالات صريحة مثل null/unknown، مع سبب عند الحاجة (صفحة مفقودة، غير مقروءة، غير مطبقة). هذا يسمح للمستند بالمضي قدماً مع إظهار ما يحتاج انتباه المراجع.
خزّن أيضًا أصول الحقول وثقة الاستخراج. المصدر قد يكون user, OCR, import, أو API. يمكن أن تكون الثقة قيمة بين 0-1 أو مجموعة صغيرة مثل high/medium/low. إذا قرأ OCR "$18.70" بثقة منخفضة لأن الرقم الأخير مطمس، يمكن للواجهة إبراز ذلك وطلب تأكيد سريع.
المستندات متعددة الصفحات تحتاج قرارًا إضافيًا: ما الذي ينتمي للمستند ككل مقابل صفحة واحدة. الإجماليات والبائع عادةً تخص المستند. ملاحظات الصفحة، الحجب، الدوران، والتصنيف على مستوى الصفحة غالبًا ما تكون على مستوى الصفحة.
الإجابة على سؤال واحد: "أين هذا المستند في العملية؟" اجعلها صغيرة ومملة. إذا أضفت حالة جديدة في كل مرة يسأل فيها شخص ما، ستحصل على فلاتر لا يثق بها أحد.
مجموعة عملية من الحالات التجارية التي تتطابق مع القرارات الحقيقية:
احتفظ بـ"processing" خارج الحالة التجارية. تشغيل OCR وتوليد المعاينة يصفان ما تفعله النظام، وليس ما يجب على الشخص القيام به بعد ذلك. خزّنها كحالات معالجة منفصلة.
فصّل أيضًا التعيين عن الحالة (assignee_id, team_id, due_date). يمكن أن يكون المستند Approved لكنه لا يزال معينًا لمتابعة، أو Needs review بدون مالك بعد.
سجّل تاريخ الحالات، وليس القيمة الحالية فقط. سجل بسيط مثل (from_status, to_status, changed_at, changed_by, reason) مفيد عندما يسأل أحدهم: "من رفض هذا الإيصال ولماذا؟"
أخيرًا، قرر ما الإجراءات المسموح بها في كل حالة. اجعل القواعد بسيطة: يمكن للـImported الانتقال إلى Needs review؛ Approved للقراءة فقط ما لم يُنشأ إصدار جديد؛ يمكن إعادة فتح Rejected لكن يجب الاحتفاظ بالسبب السابق.
معظم الوقت يُقضى في المسح عبر قائمة، فتح عنصر، تصحيح بعض الحقول، والمضي قدمًا. تجعل واجهة جيدة تلك الخطوات سريعة ومتوقعة.
في قائمة المستندات، عامل كل صف كملخص حتى يقرر المستخدم دون فتح كل ملف. صف قوي يظهر مصغرة صغيرة، عنوانًا واضحًا، بعض الحقول الأساسية (التاجر، التاريخ، الإجمالي)، شارة حالة، وتحذيرًا طفيفًا عند الحاجة.
حافظ على عرض التفاصيل هادئًا وسهل المسح. تخطيط شائع هو المعاينة على اليسار والبيانات الوصفية على اليمين، مع عناصر تحكم التحرير بجانب كل حقل. يجب أن يستطيع المستخدمون التكبير، الدوران، والتنقل بين الصفحات دون أن يفقدوا موضعهم في النموذج. إذا كان الحقل مُستخرجًا من OCR، أعرض مؤشر ثقة صغيرًا، ومن الأفضل إبراز المنطقة المصدرية على المعاينة عند تركيز الحقل.
تعمل الإصدارات بشكل أفضل كخط زمني، وليس كقائمة منسدلة. أظهر من غيّر ماذا ومتى، ودع المستخدمين يفتحون أي إصدار سابق بوضع قراءة فقط. إذا قدمت مقارنة، ركّز على اختلافات البيانات الوصفية (تغير المبلغ، تصحيح البائع) بدلًا من مقارنة بكسل-ببكسل لملف PDF.
وضع المراجعة يجب أن يُحسّن السرعة. غالبًا ما يكفي سير فرز يعتمد على لوحة المفاتيح: إجراءات سريعة للموافقة/الرفض، تصحيحات سريعة للحقول الشائعة، وصندوق تعليق قصير للرفض.
حالات الفراغ مهمة لأن المستندات غالبًا في منتصف المعالجة. بدل مربع فارغ، اشرح ما يحدث: "المعاينة قيد التوليد"، "OCR قيد التشغيل"، أو "نوع الملف هذا لا يملك معاينة بعد".
سير عمل بسيط يشعر بأنه "تحميل، فحص، موافقة". تحت السطح، يعمل أفضل عندما تفصل الملف نفسه (الإصدارات والمعاينات) عن المعنى التجاري (البيانات الوصفية والحالة).
يحمل المستخدم PDF أو صورة أو مسح إيصال ويشاهده فورًا في قائمة صندوق وارد. لا تنتظر انتهاء المعالجة. اعرض اسم الملف، وقت التحميل، وشارة واضحة مثل "قيد المعالجة". إذا كنت تعرف المصدر (استيراد بريد إلكتروني، كاميرا الهاتف، سحب وإسقاط)، أظهره أيضًا.
عند التحميل، أنشئ سجل Document (الكيان طويل الأمد) وسجل Version (هذا الملف المحدد). عيّن current_version_id إلى الإصدار الجديد. خزّن preview_state = pending وextraction_state = pending حتى تكون الواجهة صادقة بشأن ما هو جاهز.
يجب أن يفتح عرض التفاصيل فورًا، لكن يعرض عارضًا احتياطيًا ورسالة واضحة "تحضير المعاينة" بدل إطار مكسور.
مهمة في الخلفية تولّد الصور المصغرة ومعاينة قابلة للعرض (صور صفحات لملفات PDF، تغيير حجم الصور للصور). مهمة أخرى تستخرج البيانات الوصفية (التاجر، التاريخ، الإجمالي، العملة، نوع المستند). عند انتهاء كل مهمة، حدّث حالتها وطوابعها الزمنية فقط حتى تتمكن من إعادة المحاولة عند الفشل دون لمس كل شيء.
حافظ على واجهة مضغوطة: أظهر حالة المعاينة، حالة البيانات، وأبرز الحقول ذات الثقة المنخفضة.
عندما تصبح المعاينة جاهزة، يصحّح المراجعون الحقول، يضيفون ملاحظات، وينقلون المستند عبر الحالات التجارية مثل Imported -> Needs review -> Approved (أو Rejected). سجّل من غيّر ماذا ومتى.
إذا حمل المراجع ملفًا مصححًا، يصبح إصدارًا جديدًا ويعود المستند تلقائيًا إلى Needs review.
يجب أن تقرأ عمليات التصدير، مزامنة المحاسبة، أو التقارير الداخلية من current_version_id ولقطة البيانات الوصفية المعتمدة، لا من "آخر استخراج". هذا يمنع تحميلًا نصف معالج يغيّر الأرقام.
تفشل سير العمل المتمركز حول المستند لأسباب مملة: الاختصارات المبكرة تتحوّل إلى ألم يومي عندما يحمّل الناس نسخًا مكررة أو يصححون أخطاء أو يسألون "من غيّر هذا ومتى؟"
معاملة اسم الملف كهوية المستند خطأ كلاسيكي. الأسماء تتغير، يعيد المستخدمون الرفع، وتنتج الكاميرات تكرارات مثل IMG_0001. أعط كل مستند معرفًا ثابتًا، وعامل اسم الملف كوسم.
الكتابة فوق الملف الأصلي عند رفع بديل تسبب أيضًا مشاكل. يبدو ذلك أبسط، لكنك تفقد سجل التدقيق ولا يمكن الإجابة على أسئلة أساسية لاحقًا (ما الذي تمت الموافقة عليه، ما الذي تم تعديله، ما الذي أُرسل). اجعل الملف الثنائي غير قابل للتغيير وأضف سجل إصدار جديد.
خلط الحالات يخلق أخطاء دقيقة. "OCR قيد التشغيل" ليس هو نفسه "Needs review". حالات المعالجة تصف ما يفعله النظام؛ الحالة التجارية تصف ما يجب على الشخص فعله بعد ذلك. عند خلطهما، تنتهي المستندات عالقة في سلة خاطئة.
قرارات واجهة المستخدم يمكن أن تخلق احتكاكًا أيضًا. إذا حجبت الشاشة حتى تُولّد المعاينات، يشعر الناس أن التطبيق بطيء حتى لو نجح التحميل. أظهر المستند فورًا مع عنصر نائب واضح، ثم استبدل الصور المصغرة عند جهوزيتها.
أخيرًا، تصبح البيانات الوصفية غير موثوقة عندما تخزن قيمًا دون أصل. إذا كانت القيمة جاءت من OCR، اذكر ذلك. احتفظ بالطوابع الزمنية.
قائمة فحص سريعة:
مثال: في تطبيق إيصالات، يعيد المستخدم رفع صورة أوضح. إذا طبقت النسخ، احتفظ بالصورة القديمة، علم أن OCR يعيد المعالجة، وحافظ على Needs review حتى يؤكد إنسان المبلغ.
تشعر سير العمل المتمركزة حول المستند بأنها "منجزة" فقط عندما يستطيع الناس الوثوق بما يرون والتعافي عندما تسوء الأمور. قبل الإطلاق، اختبر بمستندات حقيقية وفوضوية (إيصالات ضبابية، PDF مقلوب، رفع مكرر).
خمسة فحوصات تلتقط معظم المفاجآت:
اختبار واقعي سريع: اطلب من شخص مراجعة ثلاث إيصالات متشابهة وقم عمدًا بعمل تغيير خاطئ في واحدة. إذا استطاع تحديد الإصدار الحالي، فهم الحالة، وإصلاح الخطأ في أقل من دقيقة، فأنت قريب.
المصروفات الشهرية مثال واضح على عمل متمركز حول المستند. الموظف يحمّل إيصالات، ثم يراجعهم شخصان: المدير ثم المحاسبة. الإيصال هو المنتج، لذا يقوم تطبيقك أو يفشل بناءً على إدارة الإصدارات، المعاينات، البيانات الوصفية، وحالات الحالة الواضحة.
جامي يحمّل صورة إيصال تاكسي. ينشئ النظام المستند #1842 مع الإصدار v1 (الملف الأصلي)، مصغرة ومعاينة، وبيانات وصفية مثل التاجر، التاريخ، العملة، الإجمالي، ونقطة ثقة OCR. يبدأ المستند في Imported، ثم ينتقل إلى Needs review بمجرد جهوزية المعاينة والاستخراج.
لاحقًا، يحمّل جامي نفس الإيصال بالخطأ مرة أخرى. يمكن لفحص التكرار (hash الملف بالإضافة إلى تشابه البائع/التاريخ/الإجمالي) أن يقترح خيارًا بسيطًا: "يبدو تكرارًا لـ #1842. إرفاقه على أي حال أم تجاهله؟" إذا أرفق، خزّنه كملف آخر مرتبط بنفس المستند حتى تحافظ على سلسلة مراجعة واحدة وحالة واحدة.
أثناء المراجعة، يرى المدير المعاينة والحقول الأساسية والتحذيرات. خمن OCR المبلغ كـ $18.00، لكن الصورة تظهر بوضوح $13.00. يصحّح جامي المبلغ. لا تمحَ التاريخ. أنشئ الإصدار v2 بالحقول المحدثة، احتفظ بـv1 دون تغيير، وسجّل "تصحيح المبلغ بواسطة جامي".
إذا أردت بناء هذا النوع من سير العمل بسرعة، يمكن أن يساعدك Koder.ai (koder.ai) في توليد النسخة الأولى من التطبيق من خطة دردشة، لكن القاعدة نفسها تنطبق: عرّف الكائنات والحالات أولًا، ثم دع الشاشات تتبعها.
خطوات عملية تالية:
تتعامل تطبيقات المتمركزة حول المستند مع المستند باعتباره الشيء الأساسي الذي يعمل عليه المستخدمون، وليس مجرد مرفق جانبي. يحتاج الناس إلى فتحه، الوثوق بما يرونه، فهم ما تغيّر، واتخاذ القرار التالي استنادًا إلى ذلك المستند.
ابدأ بصندوق وارد/قائمة، عرض تفصيلي للمستند مع معاينة سريعة، منطقة إجراءات مراجعة بسيطة (الموافقة/الرفض/طلب تغييرات)، وطريقة للتصدير أو المشاركة. تغطي هذه الشاشات الأربع حلقة العثور، الفتح، اتخاذ القرار، والتسليم.
نمذج سجل المستند الثابت الذي لا يتغير، وخزّن البايتات الفعلية ككائنات File منفصلة. ثم أضف Version كالتقاط يربط المستند بملف محدد (ومخرجاته المشتقة). هذه الفواصل تحافظ على التعليقات والمهام والسجل حتى عند استبدال الملف.
اجعل كل تغيير ذي معنى يسجل كـإصدار جديد بدلاً من التحرير في المكان. احتفظ بـ current_version_id على المستند لقراءات "الأحدث" السريعة، وخزن جدول زمني للإصدارات القديمة للمراجعة والاسترجاع. هذا يمنع الالتباس حول ما تم الموافقة عليه ولماذا.
ولّد المعاينات بشكل غير متزامن بعد حفظ الملف الأصلي، حتى يبدو التحميل سريعًا وتصبح عمليات إعادة المحاولة آمنة. تابع حالة المعاينة مثل pending/ready/failed حتى تكون الواجهة صادقة، وخزّن أحجامًا متعددة حتى تظل قوائم العرض خفيفة والعارض التفصيلي حادًا.
خزّن البيانات الوصفية في ثلاث مجموعات: نظامية (اسم الملف، الحجم، النوع)، مستخرجة (حقول OCR وثقتها)، وتصحيح المستخدم. احتفظ بسجل المصدر حتى تعرف ما إذا كانت القيمة جاءت من OCR أو إنسان، وتجنّب إجبار تعبئة كل حقل قبل استمرار العمل.
استخدم مجموعة صغيرة من الحالات التجارية التي تصف ما يجب على الشخص فعله تاليًا، مثل Imported, Needs review, Approved, Rejected, Archived. تتبع حالة المعالجة بشكل منفصل (تشغيل OCR/توليد المعاينة) حتى لا تعلق المستندات في حالة تمزج بين عمل الإنسان والعمل الآلي.
خزّن قيَم فحص للملفات عند التحميل (checksum) وقارنها، ثم أضف فحصًا ثانويًا باستخدام حقول رئيسية مثل البائع/التاريخ/المجموع عند توفرها. عند الاشتباه بتكرار، قدم خيارًا واضحًا لإرفاقه بنفس سلسلة المستند أو تجاهله حتى لا تنقسم سلاسل المراجعة عبر نسخ متعددة.
احتفظ بسجل لحالة التغيير مع من غيّر ماذا ومتى ولماذا، واجعل الإصدارات قابلة للعرض عبر خط زمني. يجب أن يكون التراجع عملية تغيير مؤشر إلى نسخة قديمة، لا حذفًا، حتى تستعيد بسرعة دون فقدان السجل.
حدد الكائنات والحالات أولاً، ثم اجعل الواجهة تتبع هذه التعريفات. إذا استخدمت Koder.ai لإنشاء تطبيق من خطة دردشة، كن صريحًا حول Document/Version/File، وحالات المعاينة والاستخراج، وقواعد الحالة حتى تتوافق الشاشات المولدة مع سلوك سير العمل الحقيقي.