كيف بدأنا في تسجيل النقد لعملائنا

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



قررنا إنقاذ عملائنا من كل هذا الرعب من خلال تقديم خدمة تسجل كل شيء تلقائيًا تقريبًا بنقرة واحدة. سنتحدث عن هذا الآن.

لماذا نحتاجها

لقد أدركت بالفعل أن تسجيل مكتب التذاكر هو مهمة شاقة متعددة المراحل ، ولكن هذه ليست المشكلة الوحيدة. في كل مرحلة ، تنتظر حديقة الحيوانات واجهات ، يجب ملء نماذجها يدويًا ببيانات التسجيل لكل مكتب تذاكر ، بالإضافة إلى مجموعة كاملة من الأخطاء ذات الصلة (تحيات منفصلة لمتطلبات الضرائب لاستخدام IE أو Yandex.Browser أو متصفحات Sputnik). مئات الفرص لارتكاب خطأ وتدمير الإجراء والبدء من جديد. وإذا قمت بتعيين 5-10 تسجيلات نقدية ، فإن فرصة حدوث خطأ عند إدخال نفس التفاصيل تزداد في بعض الأحيان. ناهيك عن الهدر غير المنتج للوقت ومعرفة سبب رفض مكتب الضرائب الشخصية قبول الرمز ، الذي تم "ابتلاعه" تمامًا أمس فقط.



وعندما شعرنا بوطأة المأساة المذكورة أعلاه ، قررنا أن نأخذ التطور.

خطوات التسجيل

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

ينقسم الإجراء بشكل مشروط إلى مرحلتين:

تسجيل مكتب النقدية - يتم إرسال بيانات جهاز معين إلى دائرة الضرائب الفيدرالية ، ويأتي رقم التسجيل ردًا.

Fiscalization - تفعيل أمين الصندوق باستخدام رقم تسجيل السيارة المعين من قبل مصلحة الضرائب الفيدرالية.

بادئ ذي بدء ، ذهبنا إلى شركائنا للعمل معهم في المرحلة الأولى.

API لخدمة الضرائب الفيدرالية

لم نكن أول من فكر في أتمتة التسجيل. قال الكثيرون إنهم يفعلون شيئًا في هذا المجال ، وهذا التطوير جار ، لكن لا أحد لديه واجهة خارجية جاهزة. تم توفير أحد مشغلي البيانات المالية بواسطة API - جاهز تقريبًا للتفاعل مع الضريبة.

في ذلك الوقت ، تم إرسال حوالي 80 تطبيق اختبار فقط باستخدام البروتوكول. كنا نعتقد أن الواجهة ستعمل قريبًا بكامل طاقتها ، وبدأت في التنفيذ والاختبار على "بذرة".

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

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

Cashier API

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

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


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

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



كان موردونا هم أول من قام بإعداد إرسال معلومات التسجيل تلقائيًا إلى مكتب التذاكر. وسرعان ما ستسهل واجهة برمجة التطبيقات تسجيل تسجيلات النقدية وإعادة تسجيلها بنفس السهولة.

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

تشريح تسجيل السيارات

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

هذه هي مهمة اختيار البنية الصحيحة ، والتي ستسمح لنا بالتحكم في التسجيل غير المتزامن لسجلات النقد في OFD ، مع كل من خدمة الضرائب الفيدرالية والمورد. نظرًا لأنها تستجيب للطلبات بتأخير ، فإن العملية تستغرق وقتًا طويلاً ولديها عدد كبير من عمليات التكامل مع الأنظمة الخارجية. وبسبب هذا ، كان علينا كتابة تطبيقين في Java.

تتواصل خدمة العمل مباشرة مع CRF وأنظمة مصنعي تسجيلات النقدية. على سبيل المثال ، نرسل بيانات العملاء إلى OFD ونتوقع تلقي رقم تسجيل استجابة.

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

إذا قمنا في البداية برصد مرور التطبيقات بعناية ودرسنا يدويًا كل خطأ أعطاه النظام ، فإن العملية الآن تلقائية.

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

التطبيق الثاني ، CashReg ، هو نظام معالجة حيث يتم الاحتفاظ بنموذج حالة ، يتم تقديمه في شكل علاقي.

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

لذلك ، إذا كان التطبيق في نفس الحالة لفترة طويلة جدًا ، على سبيل المثال ، لا يتلقى رقم التسجيل لعدة ساعات ، أو يستجيب CRF بمرحلة أو حالة غير صحيحة للتطبيق ، فإن CashReg سيبلغ عن خطأ.

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

لا تتضمن جميع مكونات نظام التسجيل الثلاثة حمولات عالية ، لأنها منتشرة في بيئات افتراضية.

كيف تتم معالجة الطلب

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


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


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


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

الملف المرسل من OFD رداً مصدق عليه بالتوقيع الإلكتروني ، وباستخدام واجهة برمجة التطبيقات OFD API ، يتم إرساله إلى السلطات الضريبية. هناك تم تعيين الخروج رقم التسجيل.

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

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

مباشرة بعد قيام OFD بإنشاء تقرير تسجيل ، نقوم بتوقيعه للعميل ، ويغادر شباك التذاكر مع شركة الشحن.



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

الخلاصة

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

متوسط ​​الوقت للحصول على رقم التسجيل ، باستثناء الحالات الأكثر سلبية ، هو ثلاث ساعات. بشكل عام ، يستغرق الإجراء بأكمله من 5 إلى 6 ساعات. 90٪ من التسجيلات تنجح. في الوقت الحالي ، تم بالفعل معالجة حوالي 1000 تطبيق.

بشكل عام ، كما تفهم ، نحن في شركتنا نحب مثل هذه الحالات ، والتي يمكن أن تبسط بشكل كبير حياة عدد كبير من الناس. عند حل هذه المشاكل ، تشعر أنك تقوم بشيء مفيد حقًا.

PS إذا كنت مهتمًا ، يمكنك قراءة كيف قمنا نحن بغسل أجهزة الصراف الآلي الخاصة بنا . علاوة على ذلك ، إلى جانب بروتوكولات تبادل البيانات.