صيغة الدفع التي لا تنتقل أبدا
الدولة الأولى تقوم بترميز ملف البنك بشكل ثابت لأن "نحن ندفع هنا فقط". الدولة الثانية تنسخ دفتر الدفع وتطلب صيغة X++ جديدة. بحلول الوقت الذي تدفع فيه للبائعين في شيكاغو، والموظفين في ليون، والموردين في نيروبي، يكون لديك ثلاثة محركات دفع وشعار واحد.
هذا هو نفس الفشل الذي كان يفترض أن يكون هناك محرك ضريبي واحد. مسار الدفع جزء من النواة العالمية. الملف الذي سيقبله البنك هو طبقة الدولة.
بوابة واحدة، أي بنك
DisbursementFlow 365 على Finance & Operations. يدفع للبائعين ويدفع للموظفين. ملفات تعريف الاتصال بالبنوك تغطي أي بنك. التحقق من صحة الحساب يستخدم قواعد IBAN ل 89 دولة. الدفعات تتحرك بعد موافقة صانع المراجع. الملف ISO 20022 pain.001. لا يمكن تعديل سجل الحالة بعد الحدث.
نشر دولة جديدة هو رسم خرائط ملفات في السنة Azure لصيغ البنوك الخاصة بتلك الدولة. ليس تخصيصا، ولا هو دفتر دفع ثان. الهند وأستراليا والولايات المتحدة وأوروبا ترتبط بنفس الطريقة التي تفعل بها كينيا وجنوب أفريقيا.
حساب الرواتب. البوابة تدفع.
PayrollFlow 365 تقع على النواة العالمية، وعلى Finance & Operations وعلى Business Central. يغطي المحتوى القانوني المنشور كينيا ونيجيريا وجنوب أفريقيا: الأرباح، PAYE، العوائد، ونشر الدفاتر الحسابية. تقوم الدولة بتكوين الأسعار والتقويمات. لا تضع كشوف رواتب ثانية حتى تصل الرواتب إلى البنك.
مدفوعات الموظفين تغادر عبر البوابة، إلى نفس الدفاتر، مع نفس مدقق الصانع. تقرير الممول أو حزمة المجموعة يكتمل عندما يرى تلك المدفوعات.
ما لن نبنيه
لن نكتب صيغة بنكية ب X++ أو AL لأن الدولة جديدة. لن نسمح لسوق أو نظام جانبي للرواتب "بإرسال الشبكة فقط" إلى دفتر المدفوعات. لن نحتفظ بنمط تكامل خاص لكل جهة لكل جهة.
إذا كان برنامجك على وشك إضافة دولة، اطرح سؤالا واحدا في اجتماع التوجيه: هل البنك الجديد ملف خريطة على البوابة التي تديرها بالفعل، أم تقدير تطوير؟ إذا كان تقديرا، فأنت تشتري مشروعا محليا بسعر عالمي.