Menurut amandemen 54-, sejak Juli tahun ini, hampir semua perusahaan dagang wajib menggunakan meja kas online yang mengirimkan data melalui Internet ke layanan pajak. Untuk mendapatkan peralatan seperti itu, Anda harus membeli meja kas dan drive fiskal, menandatangani perjanjian, dan membayar layanan operator data fiskal, mendaftar di dua kantor pribadi Layanan Pajak Federal dan OFD, memasukkan rinciannya ke kasir, dan menerima laporan pendaftaran kertas. Nah, Anda juga akan memerlukan tanda tangan digital elektronik, jika tidak, Anda harus datang ke Layanan Pajak Federal dan secara pribadi mengantre.
Kami memutuskan untuk menyelamatkan pelanggan kami dari semua kengerian ini dengan membuat layanan yang mendaftarkan semuanya secara otomatis hampir dalam satu klik. Kami akan membicarakan ini sekarang.
Mengapa kita membutuhkannya?
Anda sudah menyadari bahwa mendaftarkan kantor tiket adalah pencarian multi-tahap yang membosankan, tetapi ini bukan satu-satunya masalah. Pada setiap tahap, kebun binatang sedang menunggu antarmuka, yang bentuknya harus diisi secara manual dengan data pendaftaran untuk setiap kantor tiket, serta set lengkap bug yang relevan (salam terpisah dengan persyaratan pajak untuk menggunakan browser IE, Yandex.Browser atau Sputnik). Ratusan peluang untuk melakukan kesalahan, merusak prosedur dan memulai dari awal. Dan jika Anda mengatur 5-10 register kas, kemungkinan kesalahan saat memasukkan rincian yang sama meningkat pada waktu-waktu tertentu. Belum lagi pemborosan waktu yang tidak produktif dan mencari tahu mengapa kantor pajak pribadi menolak untuk menerima token, yang benar-benar "tertelan" baru kemarin.
Dan ketika kami merasakan beban terberat dari tragedi di atas, kami memutuskan untuk mengambil perkembangan.
Langkah Pendaftaran
Beberapa pihak terlibat dalam mendaftarkan mesin kasir sekaligus. Ini adalah layanan pajak (FTS), OFD - operator data fiskal yang melaluinya register kas berinteraksi dengan otoritas pajak, pusat sertifikasi yang menerbitkan tanda tangan elektronik dan, sebagai suatu peraturan, seorang pengusaha kecil yang bingung hilang dalam pergolakan birokrasi. Kami ingin campur tangan dalam hubungan mereka, untuk mengambil semua kesulitan pada diri kita sendiri.
Secara kondisional, prosedur ini dibagi menjadi dua tahap:
Registrasi meja kas - data perangkat tertentu dikirim ke Layanan Pajak Federal, dan nomor registrasi datang sebagai tanggapan.
Fiskalisasi - aktivasi kasir menggunakan nomor registrasi kendaraan yang ditugaskan oleh Layanan Pajak Federal.
Pertama-tama, kami pergi ke mitra kami untuk mengerjakan tahap pertama bersama mereka.
API untuk Layanan Pajak Federal
Kami bukan yang pertama berpikir tentang otomasi pendaftaran. Banyak yang mengatakan bahwa mereka melakukan sesuatu di bidang ini, pengembangan sedang berlangsung, tetapi tidak ada yang memiliki antarmuka eksternal yang sudah jadi. Salah satu operator data fiskal disediakan oleh API - hampir siap untuk berinteraksi dengan pajak.
Saat itu, hanya sekitar 80 aplikasi uji yang dikirim menggunakan protokol. Kami percaya bahwa segera antarmuka akan bekerja pada kapasitas penuh, dan mulai implementasi dan pengujian pada "rintisan".
Pergi ke prod, kami menyadari bahwa tes kami dan aplikasi nyata berbeda, seperti siang dan malam. "Rintisan bertopik" yang kami terima dari OFD hanya menyertakan tiruan sukses, dan mereproduksi skrip yang sukses. Sebenarnya, mencapai "kesuksesan" itu tidak mudah.
Hit termasuk: aplikasi di sisi mitra yang tidak diproses selama beberapa hari, kurangnya umpan balik dari Layanan Pajak Federal dan OFD, kesalahan tanda tangan dan "kesalahan tidak dikenal" favorit kami. Protokol FTS ternyata tidak terdokumentasi dengan baik dan, seringkali, merespons dengan kegagalan yang tidak ditentukan, yang tidak jelas penyebabnya. Spesifikasi yang jelas masih belum ada. Jadi pertama kali kami menguji protokol, dan, bersama dengan OFD, kami membuat keputusan tentang bagaimana menanggapi tanggapan tertentu dari Layanan Pajak Federal dalam kasus-kasus tertentu.
API Kasir
Sementara bagian dari tim mempelajari perilaku sistem Layanan Pajak Federal dalam praktiknya, pekerjaan itu tidak berhenti. Secara paralel, kami mengatur negosiasi dengan produsen mesin kasir, mengundang mereka untuk bertukar data dari kami ke platform mereka, dari platform ke mesin kasir dan dalam urutan terbalik untuk mengatur fiskal otomatis register kasir.
Kami memilih sepasang solusi one-piece universal. Meja kas Evotor dengan layar sentuh dan DreamCas diperuntukkan bagi para pelanggan yang terbiasa dengan tombol-tombol lama yang bagus dan menganggap fungsi tambahan itu berlebihan. Modelnya berbeda: dengan dan tanpa pemindai.
Jika OFD memiliki API sendiri siap, maka untuk kontraktor mesin kasir itu harus dikembangkan dari awal. Kalau tidak, mustahil untuk membuat semua data pendaftaran datang ke mesin kasir secara otomatis, tanpa entri manual.
Kolega berhasil dengan mengatur interaksi melalui platform mereka, dan segera siap: API untuk membuka akun pribadi klien dan protokol kepemilikan untuk mengelola kasir.
Pemasok kami adalah yang pertama mengatur pengiriman informasi pendaftaran secara otomatis ke kantor tiket. Dan segera API akan membuatnya mudah untuk deregister dan mendaftar ulang register kas.
Sekarang, ketika kita bernegosiasi dengan vendor uang lain, justru dukungan dari antarmuka ini yang menjadi salah satu persyaratan utama.
Anatomi Pendaftaran Otomatis
Setelah kami mempelajari cara bekerja dengan Layanan Pajak Federal dan mengimplementasikan API dengan vendor untuk mentransfer data registrasi ke kasir, tiba saatnya untuk menghubungkan semua ini ke dalam satu sistem dan membuat prosedur registrasi.
Ini adalah tugas untuk memilih arsitektur yang tepat, yang akan memungkinkan kita untuk mengontrol pendaftaran kasir asinkron dalam OFD, baik dengan Layanan Pajak Federal dan vendor. Karena mereka menanggapi permintaan dengan penundaan, prosesnya memakan waktu dan memiliki banyak integrasi dengan sistem eksternal. Karena itu, kami harus menulis dua aplikasi di Java.
Layanan pekerjaan berkomunikasi langsung dengan CRF dan sistem pabrikan mesin kasir. Misalnya, kami mengirim data pelanggan ke OFD dan berharap untuk menerima nomor registrasi sebagai tanggapan.
Layanan pekerjaan memilih status pekerjaan pada interval tertentu. Dia bertanya lagi dan bertanya lagi sampai hasilnya kembali. Nomor registrasi disimpan, Ayub mentransfer aplikasi ke tahap berikutnya dan fiskalisasi dimulai.
Jika pada awalnya kita dengan hati-hati memantau jalannya aplikasi dan secara manual mempelajari setiap kesalahan yang diberikan sistem, sekarang prosesnya otomatis.
Kami segera menentukan penyebab kesalahan. Dan jika terjadi masalah besar, sistem pemantauan telah dibuat yang mencatat anomali yang mengindikasikan kegagalan besar pada Layanan Pajak Federal atau OFD. Klien, bagaimanapun, mengetahui tentang masalah-masalah dalam satu-satunya kasus: jika, dalam menanggapi permintaan, kami menerima pengurangan spesifik, penolakan yang beralasan untuk mendaftar.
Aplikasi kedua, CashReg, adalah sistem pemrosesan di mana model status dipertahankan, disajikan dalam bentuk relasional.
Ini dikembangkan berdasarkan API yang disediakan oleh vendor dan CRF, dan mencakup semua kemungkinan transisi untuk setiap kelas yang berpartisipasi dalam proses pendaftaran. Model status menghindari kesalahan internal dan menghilangkan penyimpangan dari algoritma pemrosesan aplikasi standar.
Jadi, jika aplikasi telah dalam status yang sama terlalu lama, misalnya, ia tidak menerima nomor pendaftaran selama beberapa jam, atau CRF merespons dengan tahap atau status aplikasi yang salah, CashReg akan melaporkan kesalahan.
Tentu saja, admin diperlukan untuk mengelola prosedur. Kelompok pendukung keputusan perdagangan bekerja dengannya, melayani dan menyertai register kas selama pendaftaran. Sekarang hanya dua karyawan yang terlibat dalam hal ini, tetapi antarmuka kerjanya tidak rumit, dan proses persiapan meja kas, berkat penolakan entri data manual, sederhana. Jadi, kita dapat dengan cepat dan mudah menskala departemen.
Ketiga komponen sistem pendaftaran tidak menyiratkan beban tinggi, karena mereka ditempatkan di lingkungan virtual.
Bagaimana proses pengerjaan aplikasi
Semua ini diperlukan agar klien, meninggalkan permintaan di akun pribadinya, beberapa hari kemudian meletakkan meja kas yang diaktifkan siap untuk bekerja di belakang meja.
Dari sudut pandang dapur domestik, keajaiban registrasi otomatis terlihat sedikit lebih rumit. Meninggalkan aplikasi di akun pribadi Anda, klien memberi kami izin hukum untuk mengeluarkan tanda tangan elektronik dan menjalani seluruh prosedur atas namanya.
Informasi tentang perusahaan, data registrasi untuk toko tertentu dan penandatangan (misalnya, kepada direktur umum) diekstraksi dari basis perbankan. Mereka diperbarui dalam SPARK, melalui penilaian dan memasuki sistem master di box office.
Kemudian aplikasi dibentuk di CASHREG. Ini ditampilkan sebagai tugas baru di panel admin seorang karyawan dari grup pendukung solusi perdagangan. Dia melihat meja kas dan fiskal mana yang mendorong kebutuhan klien. Karyawan tersebut menemukan perangkat yang diperlukan di gudang, memilih drive fiskal, barcode nomor seri mereka dan mengkonfirmasi aplikasi. Jadi, ada perangkat khusus yang terpasang padanya, yang akan dikirim ke klien. Pada titik ini, OFD menerima permintaan: "Formulir aplikasi untuk pendaftaran meja kas ini dan itu, untuk perusahaan ini dan itu."
File yang dikirim oleh OFD sebagai tanggapan diautentikasi oleh tanda tangan elektronik dan, menggunakan API OFD, dikirim ke otoritas pajak. Di sana kasir diberi nomor pendaftaran.
Sekarang paket lengkap dokumen di meja kas sampai ke pabrik mesin kasir (ya, mereka juga terlibat di sini). Pada saat yang sama, tugas muncul di panel admin - untuk memfitalisasi kasir yang sama. Ini berarti bahwa karyawan hanya memasukkan kasir. Sistem vendor "melihat" bahwa perangkat tersebut bersentuhan dan memuat semua data pendaftaran yang diperlukan ke dalam memori secara otomatis. Kesalahan dengan entri manual dikecualikan, detail yang sama pergi ke Layanan Pajak Federal dan kasir.
Kasir mencetak laporan pendaftaran - sesuatu yang semuanya dimulai. Data fiskal dari laporan: tanggal cetak, tanda tangan, tanda fiskal, berfungsi sebagai konfirmasi bahwa meja kas siap untuk bekerja. Rincian ini dikirim lagi ke OFD.
Segera setelah OFD membuat laporan pendaftaran, kami menandatanganinya untuk klien, dan box office pergi dengan kurir.
OFD belum menyiapkan kartu pendaftaran, tetapi Anda tidak bisa menunggu. Ini akan tersedia dalam bentuk elektronik di akun pribadi klien dalam dua hingga tiga hari.
Kesimpulan
Untuk melaksanakan proyek ini, sekitar dua puluh karyawan dari seluruh bank dan banyak lagi spesialis dari mitra kami, DFD dan vendor uang teralihkan dari tugas-tugas mereka yang biasa, tetapi upaya mereka tidak sia-sia.
Waktu rata-rata untuk mendapatkan nomor pendaftaran, dengan pengecualian untuk kasus yang paling negatif, adalah tiga jam. Secara umum, seluruh prosedur memakan waktu 5 hingga 6 jam. 90% pendaftaran berhasil. Saat ini, sekitar 1.000 aplikasi telah diproses.
Secara umum, seperti yang Anda pahami, di perusahaan kami, kami menyukai kasus seperti itu, yang dapat sangat menyederhanakan kehidupan sejumlah besar orang. Memecahkan masalah seperti itu, Anda merasa sedang melakukan sesuatu yang benar-benar bermanfaat.
PS Jika Anda tertarik, Anda dapat membaca bagaimana kami sendiri
mencuci ATM kami . Apalagi bersama dengan protokol pertukaran data.