根据对54-的修订，自今年7月以来，几乎所有贸易企业都必须使用在线收银台，这些收银台通过Internet将数据传输到税务部门。 要购买这种设备，您将必须购买收银台和财务驱动器，签署协议并支付财务数据运营商的服务费用，在联邦税务局和OFD的两个个人办公室进行注册，将详细信息驱入收银员，并收到纸质注册报告。 嗯，您还需要电子数字签名，否则您将不得不去联邦税务局亲自排队。
我们决定通过提供一项服务来几乎一键自动注册所有内容，从而使我们的客户免于所有这些恐惧。 我们现在将讨论这个。
我们为什么需要它
您已经意识到，注册售票处是一个繁琐的多阶段任务，但这不是唯一的问题。 在每个阶段，动物园都处于等待界面，其形式将必须手动填写每个售票处的注册数据以及全套相关错误（分别针对使用IE，Yandex.Browser或Sputnik浏览器的税收要求打招呼）。 数以百计的犯错，破坏程序并重新开始的机会。 而且，如果您设置5-10个收银机，则输入相同详细信息时出错的机会有时会增加。 更不用说浪费时间的浪费，并弄清为什么个人税务部门拒绝接受令牌，而令牌恰好在昨天被“吞噬”了。
当我们感到上述悲剧首当其冲时，我们决定着手发展。
注册步骤
多个参与方立即参与了收银机的注册。 这就是税收服务（FTS），OFD-财务数据的运营商，收银机通过该数据与税务机关进行交互，这是一个颁发电子签名的认证中心，通常，这是一个因官僚动荡而迷惑不解的商人。 我们想干预他们的关系，以至于把所有的困难都带给我们自己。
有条件地，该过程分为两个阶段：
收银台注册-特定设备的数据将发送到联邦税务局，注册号会作为回应。
财政化-使用联邦税务局分配的车辆登记号激活收银员。
首先，我们去了我们的合作伙伴，与他们一起进行第一阶段的工作。
联邦税务局API
我们不是第一个考虑注册自动化的人。 许多人说他们正在这一领域做某事，开发正在进行中，但是没有人拥有现成的外部接口。 API提供了一个财务数据运算符-几乎可以与税收进行交互。
当时，仅使用该协议发送了大约80个测试应用程序。 我们认为，该接口很快就会满负荷工作，并开始在“存根”上进行实施和测试。
转到产品，我们意识到我们的测试和实际应用是不同的，例如白天和黑夜。 我们从OFD收到的“存根”仅包含成功模拟，并复制了成功脚本。 实际上，要实现“成功”并不容易。
热门案例包括：合作伙伴方面几天未处理的申请，联邦税务局和OFD缺乏反馈，签名错误以及我们最喜欢的“未知错误”。 事实证明，FTS协议的文献记录不充分，并且常常以未指定的故障做出响应，尚不清楚是什么原因造成的。 仍然没有明确的规范。 因此，我们首次测试了该协议，并与OFD一起就如何在特定情况下响应联邦税务局的某些响应做出了决定。
收银员API
尽管团队的一部分在实践中研究了联邦税收服务系统的行为，但这项工作并未停滞。 同时，我们安排了与收银机制造商的谈判，邀请他们从我们到他们的平台，从平台到收银机交换数据，并且以相反的顺序设置收银机的自动收款。
我们选择了一对通用的整体式解决方案。 带触摸屏的收银台Evotor和DreamCas适用于那些习惯于使用老式按钮的客户，并认为额外的功能是多余的。 型号不同：有和没有扫描仪。
如果OFD准备好了自己的API，那么对于收银员承包商，则必须从头开始开发。 否则，没有人工输入就不可能使所有注册数据自动到达收银机。
同事们通过他们的平台建立了交互，从而获得了成功，并且很快就做好了准备：用于开设客户个人帐户的API和用于管理收银机的专有协议。
我们的供应商是第一个设置自动向售票处提交注册信息的供应商。 很快，API将使注销和重新注册收银机变得一样容易。
现在，当我们与其他现金供应商进行谈判时，正是对该接口的支持成为关键要求之一。
自动注册剖析
在我们了解了如何与联邦税务局合作，并与供应商一起实现了将注册数据传输到收银员的API之后，就该将所有这些连接到单个系统并建立注册程序了。
这是选择正确的体系结构的任务，这将使我们能够与联邦税务局和供应商一起控制OFD中收银机的异步注册。 由于它们会延迟响应请求，因此该过程非常耗时，并且与外部系统进行了大量集成。 因此，我们不得不用Java编写两个应用程序。
职位服务与CRF和收银机制造商的系统直接通信。 例如，我们将客户数据发送到OFD，并希望收到一个注册号作为回应。
作业服务按特定间隔轮询作业状态。 他再次询问，并再次询问，直到结果返回。 注册编号已保存，Job将应用程序转移到下一个阶段，然后开始计税。
如果一开始我们仔细监控应用程序的通过并手动研究系统给出的每个错误，那么现在该过程是自动化的。
我们立即确定错误原因。 并且，在出现大问题时，已建立了监视系统，该系统记录了异常现象，这些异常现象表明了联邦税务局或OFD的重大故障。 但是，客户只能在以下情况下发现问题：如果响应请求，我们收到了特定的拒绝，则是有理由拒绝注册。
第二个应用程序CashReg是一个处理系统，其中维护了状态模型，以关系形式表示。
它是根据供应商和CRF提供的API开发的，并包括了参加注册过程中每个班级的所有可能转换。 状态模型避免了内部错误，并消除了与标准应用程序处理算法的偏差。
因此，例如，如果应用程序处于相同状态的时间过长（例如，数小时未收到注册号），或者CRF响应错误的阶段或状态，则CashReg将报告错误。
当然，需要管理员来管理该过程。 一个交易决策支持小组与之合作，在注册过程中为收银机提供服务并提供陪同。 现在只有两名员工从事此工作，但是他们的工作界面并不复杂，并且由于拒绝手动输入数据，所以收银台的准备过程非常简单。 因此，我们可以快速轻松地扩展部门。
注册系统的所有三个组件并不意味着高负载，因为它们部署在虚拟环境中。
申请程序如何处理
所有这些都是必需的，以便客户在几天后将请求保留在自己的个人帐户中，以便将激活的收银台准备好在柜台后面工作。
从家用厨房的角度来看，自动注册的魔力看起来更加复杂。 客户将应用程序留在您的个人帐户中，得到我们的法律同意，可以签发电子签名并代表他办理整个程序。
有关公司的信息，特定商店的注册数据和签字人（例如，给总经理的信息）是从银行基础上提取的。 它们在SPARK中更新，通过计分进入票房的主系统。
然后在CASHREG中形成一个应用程序。 它将作为新任务显示在贸易解决方案支持组的员工的管理面板中。 他了解客户需要哪种收银台和财务。 员工在仓库中找到必要的设备，选择财务驱动器，用条形码标记其序列号并确认应用。 因此，将特定的设备连接到该设备，然后将其交付给客户端。 此时，OFD收到一个请求：“为该公司注册这样的收银台申请表。”
OFD作为响应发送的文件通过电子签名进行身份验证，然后使用OFD API发送给税务机关。 在那里结帐处分配了一个注册号。
现在，收银台的全部文件都交给收银机制造商（是的，这里也有涉及）。 同时，管理面板中会显示一个任务-为同一出纳员收款。 这意味着员工仅包括收银员。 供应商的系统“看到”该设备处于联系状态，并将所有必要的注册数据自动加载到其内存中。 人工输入的错误被排除在外，相同的详细信息将发送给联邦税务局和收银员。
收银员打印一份注册报告-一切都从此开始。 报告中的财务数据：打印日期，签名，财务标志，可确认收银台已准备就绪。 这些详细信息再次发送到OFD。
OFD生成注册报告后，我们立即为客户签署报告，而票房则由快递员离开。
OFD尚未准备注册卡，但您迫不及待。 将在两到三天内以电子形式在客户的个人帐户中提供。
结论
为了实施该项目，大约20名来自银行的员工以及来自我们合作伙伴，DFD和现金供应商的更多专家被分散了日常工作的精力，但他们的努力并没有白费。
除最不利的情况外，获得注册号的平均时间为三个小时。 通常，整个过程需要5到6个小时。 90％的注册成功。 目前，已经处理了大约1000个申请。
总体而言，如您所知，在我们公司中，我们喜欢这种情况，它可以大大简化大量人员的生活。 解决这些问题，您会感到自己正在做一些真正有用的事情。
附注：如果您有兴趣，可以阅读我们自己如何冲销
我们的ATM机 。 此外，还有数据交换协议。