تحتاج مراجعة التغييرات إلى معرفة الحدث والمستخدم والتوقيت والقيمة قبل التعديل وبعده، ثم ربط الحدث بطلب أو سبب معتمد. وجود سجل طويل لا يثبت أن التغييرات روجعت. ابدأ بتحديد الأحداث التي تؤثر في قرار مالي أو تشغيلي، ومن يفحصها، وما الذي يفعله عند اكتشاف تغيير بلا تفسير كافٍ.
توضح وثائق Microsoft الخاصة بتدقيق Dataverse أن نطاق التسجيل يعتمد على إعدادات التدقيق والجداول والأعمدة المعنية. هذه معلومة عن تلك المنصة، وليست إثباتًا أن أي ERP يسجل كل حدث. لذلك يجب سؤال المورد عن النطاق الفعلي والاحتفاظ والوصول وتجربة حالة محددة، بدل قبول عبارة «يوجد Audit Trail» كإجابة نهائية.
حدد أحداث المراجعة المهمة
قد تشمل تغيير بيانات طرف، أو تعديل وحدة صنف، أو إلغاء مستند، أو إعادة فتح فترة، أو منح صلاحية حساسة. رتّبها وفق أثرها على العمل. لا تبدأ بمراجعة كل نقرة يوميًا؛ غالبًا ستغرق الأحداث المهمة وسط الضوضاء. حدد أيضًا الفرق بين تعديل مسودة وتصحيح مستند معتمد وفق آلية النظام وسياسة المنشأة، لأن المسارين قد يحتاجان أدلة ومسؤوليات مختلفة.
اطلب رؤية الحدث من البداية للنهاية
في بيئة اختبار، أنشئ حالة خيالية وعدل حقلًا مؤثرًا بالمسار المسموح. اطلب إظهار السجل وربطه بالمستند، ومراجعة ما إذا كان يعرض المستخدم والتوقيت والتغيير نفسه. اختبر التصدير أو البحث إذا كانا من احتياجاتك، دون افتراض توافرهما. اسأل عن الأحداث التي لا تسجل، وعن أثر تغيير إعدادات الاحتفاظ، ومن يستطيع الوصول للسجل أو حذفه وفق صلاحيات المنصة.
لا تجعل خانة السبب بديلًا عن الدليل
سبب مثل «تصحيح» لا يشرح مصدر الرقم الجديد. اطلب وصفًا يربط التصحيح بمرجع وموافقة مناسبة. إذا كان التغيير يتعلق باسم أو بيانات شخصية، لا تنسخ التفاصيل الحساسة إلى ملف مراجعة واسع التداول. احتفظ بمرجع محدود الوصول، واكتب في سجل المتابعة وصف الأثر ونتيجة التحقق. المطلوب قابلية المراجعة مع تقليل كشف البيانات غير اللازمة.
مثال افتراضي: تغيير معامل عبوة
يظهر في منشأة افتراضية تعديل معامل كرتونة من 10 إلى 12. المراجع لا يحكم على المستخدم فورًا؛ يبحث عن تاريخ السريان ومرجع العبوة، وهل التغيير يخص صنفًا واحدًا، وهل يؤثر في حركات سابقة أم مستقبلية. يطلب من المختص تفسير سلوك النظام واختباره. إذا لم يوجد مرجع، تسجل الحالة للمراجعة بدل إعادة المعامل عشوائيًا بما قد يسبب خطأ آخر.
استخدم كشف متابعة قصيرًا
يحتوي الكشف على رقم الحالة ونوع الحدث ووقته والمرجع والمالك وقرار المراجعة. صنف النتيجة إلى موثق ومقبول، أو يحتاج استكمالًا، أو يحتاج معالجة مختصة. سجّل تاريخ الإغلاق ودليله. لا تعتبر إرسال سؤال إغلاقًا، ولا تستنتج من غياب حدث في التصدير أنه لم يقع قبل التحقق من المرشحات والنطاق والفترة والإعدادات.
راجع جودة السجل نفسه
تحقق من المنطقة الزمنية ومعرفات المستخدمين والحسابات المشتركة وإمكانية الربط بين الحدث والمستند. احتفظ بأدلة المراجعة وفق سياسة المنشأة، وحدد كيف يصل إليها المسؤول عند تغيير الموظفين. سجل لا يمكن البحث فيه أو تفسيره قد لا يلبي احتياجك حتى إن كان كبيرًا. أدرج هذا الاختبار ضمن تقييم الشراء، ثم أعد التحقق عند تغير الإعدادات المؤثرة بواسطة الفريق المخول.
قائمة مراجعة عملية
- أحداث محددة بناءً على أثرها، لا عددها فقط.
- تحقق من المستخدم والوقت والمرجع والتغيير حيث يتاح.
- سبب قابل للفهم ودليل اعتماد مناسب.
- نطاق احتفاظ ووصول معروفان وحدود موثقة.
- استثناءات لها مالك وقرار وإثبات إغلاق.
هل السجل يثبت أن التعديل صحيح؟
يثبت ما يسجله من حدث، أما صحة التعديل فتحتاج مقارنة بالمرجع والسياسة ونتيجة العمل. التسجيل والمراجعة وظيفتان مختلفتان.
لماذا لا يظهر تعديل أعرف أنه حدث؟
راجع المرشحات والوقت والبيئة والحقول المشمولة والاحتفاظ مع المختص. لا تفترض حذفًا أو تلاعبًا قبل فحص التفسيرات المتاحة.
اقرأ https://www.mini-tax.com/ar/insights/invoice-vs-payment/ وhttps://www.mini-tax.com/ar/insights/inventory-differences/ لأمثلة اختلاف أثر المستند عن رصيده.
يمكن عرض متطلبات سجل المراجعة في جلسة عبر https://www.mini-tax.com/ar/demo/.
المصدر: https://learn.microsoft.com/en-us/power-platform/admin/manage-dataverse-auditing
السجل الضريبي: 653-417-004