مجموعة Postman تكشف تفاصيل خدمات SEFAZ للفواتير في البرازيل، القائمة على SOAP 1.2
أي منتج يتعامل مع الفواتير الإلكترونية في أي بلد يرث شهادات وتوقيعات وبيئات اختبار مهما كانت تقنياته حديثة، وهي تكلفة نادرًا ما تدخل في تقدير الوقت.
وصلت إلى صدارة Hacker News في 15 سبتمبر 2026 مجموعة Postman منشورة على GitHub، تضم 29 طلبًا موثّقًا للتعامل مع خدمات SEFAZ، وهي الجهة الضريبية البرازيلية التي تمر عبرها الفواتير الإلكترونية. وتغطي المجموعة 4 أنواع من المستندات: NF-e وNFC-e وCT-e وMDF-e. وكلها تعمل عبر SOAP 1.2.
وتكشف المجموعة حجم التفاصيل التي يتطلبها التكامل مع هذه الخدمات:
- الاتصال يتطلب mTLS، أي أن يثبت العميل هويته بشهادة رقمية، وهي هنا شهادة e-CNPJ A1 بصيغة .pfx.
- المستندات التي تُصدر أو تُلغى، وكذلك الأحداث، تتطلب توقيع XMLDSig، بينما لا تتطلبه الاستعلامات.
- اسم العملية لا يُرسل في ترويسة SOAPAction كما في SOAP 1.1، بل داخل Content-Type، وهذا من الفروق بين الإصدارين.
- يُعطَّل التحقق من SSL، لأن شهادات الجهة البرازيلية المصدرة ICP-Brasil غير معترف بها افتراضيًا.
- لكل نوع مستند خصوصيته: CT-e يغلّف طلبات التوزيع في عنصر cUFAutor، وMDF-e لا يفعل، وMDF-e يطلب أيضًا ضغط البيانات بـ GZip ثم ترميزها بـ base64.
وهذا ليس نظامًا قديمًا مهملًا، بل هو ما تعمل عليه الفواتير في الاقتصاد البرازيلي اليوم.
وللمنظومة المصرية للفاتورة الإلكترونية تعقيدات من النوع نفسه، وإن اختلف شكلها. فلها SDK رسمي، والتوثيق فيها يتم عبر OAuth، وتشغيل بيئة الاختبار يتطلب أولًا تنزيل root certificate وتثبيتها على الجهاز.
والنمط واحد في الحالتين. فأي منتج يتعامل مع الفواتير في أي بلد يحمل معه شهادات وتوقيعات وبيئات اختبار، مهما كانت تقنياته حديثة. وهذه تكلفة نادرًا ما تظهر في تقدير الوقت حين تُضاف ميزة إصدار الفواتير إلى خطة منتج، وقلما يوجد لها توثيق خارج تجارب من عملوا عليها.