CN110033573A - 一种开具停车发票的方法、服务器和系统 - Google Patents

Abstract

本发明公开了一种开具停车发票的方法、服务器和系统。本发明开具停车发票的方法，通过接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识；判断指定支付订单是否满足开具停车发票的条件；是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票；将停车发票返回给客户端。如此，用户只需要在移动设备上，就可以随时随地自主地对停车费进行开票操作，节省开票的等待时间，用户可以更加便捷的获得停车发票。而且，采用该方式，可以实现针对具体的支付订单准确地开具发票，避免发票虚开，保障停车场的财务安全。同时，还可以节省停车场的人力资源，降低经营成本。

Description

一种开具停车发票的方法、服务器和系统

技术领域

本发明涉及计算机技术领域，具体涉及一种开具停车发票的方法、服务器和系统。

背景技术

目前，停车场为车主提供发票，多采用卷票或者定额发票，其经济成本和人力成本都很高。采用卷票的方式，需要在每个岗亭配备打印卷票的硬件，且需要每个岗亭配备专门的人员，且车主出场时，必须在出口停留，等待发票的打印，浪费车主的时间，且有可能造成停车场出口堵塞。采用定额发票的方式，每月都需要专人去税务局购买印好的定额发票，出口处也需要专人提供发票，车主才能获取发票，人力投入加大，提高了停车场的运营成本。因此，急需一种便利地提供停车发票的方式。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种开具停车发票的方法、服务器、系统、电子设备和计算机可读存储介质。

依据本发明的一个方面，提供了一种开具停车发票的方法，该方法包括：

接收客户端发送的与指定支付订单对应的开票请求；所述开票请求中包含有与所述指定支付订单对应的停车场的标识；

判断所述指定支付订单是否满足开具停车发票的条件；

是则根据所述标识向对应停车场的税控设备提交开票申请，获取所述税控设备开具的停车发票；

将所述停车发票返回给所述客户端。

优选地，所述指定支付订单包括至少一条停车费支付订单；

所述判断所述指定支付订单是否满足开具停车发票的条件包括：

逐条判断所述停车费支付订单是否满足开具停车发票的条件；

所述是则根据所述标识向对应停车场的税控设备提交开票申请包括：

将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向所述税控设备提交。

优选地，所述指定支付订单中包括支付停车费的用户标识，所述开票请求中包括所述客户端中的用户标识；

所述判断所述指定支付订单是否满足开具停车发票的条件包括：

若所述支付停车费的用户标识与所述客户端中的用户标识一致，则满足开具停车发票的条件；和/或

若所述指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

优选地，所述是则根据所述标识向对应停车场的税控设备提交开票申请包括：

根据所述标识向对应停车场的本地盘上的税控设备提交开票申请；和/或

根据所述标识向对应停车场的网托盘上的税控设备提交开票申请。

优选地，该方法还包括：

保存所述开具的停车发票与对应的指定支付订单信息，并统计所述开具的停车发票的数量和剩余发票的数量；

当所述剩余发票的数量小于预设阈值时，进行库存紧张提醒。

依据本发明的另一方面，提供了一种开具停车发票的服务器，该服务器包括：

接收单元，用于接收客户端发送的与指定支付订单对应的开票请求；所述开票请求中包含有与所述指定支付订单对应的停车场的标识；

提交单元，用于判断所述指定支付订单是否满足开具停车发票的条件；是则根据所述标识向对应停车场的税控设备提交开票申请，获取所述税控设备开具的停车发票；

返回单元，用于将所述停车发票返回给所述客户端。

优选地，所述指定支付订单包括至少一条停车费支付订单；

所述提交单元，进一步用于逐条判断所述停车费支付订单是否满足开具停车发票的条件；将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向所述税控设备提交。

优选地，所述指定支付订单中包括支付停车费的用户标识，所述开票请求中包括所述客户端中的用户标识；

所述提交单元，进一步用于若所述支付停车费的用户标识与所述客户端中的用户标识一致，则满足开具停车发票的条件；和/或

若所述指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

优选地，所述提交单元，进一步用于根据所述标识向对应停车场的本地盘上的税控设备提交开票申请；和/或

根据所述标识向对应停车场的网托盘上的税控设备提交开票申请。

优选地，该服务器还包括：

统计单元，用于保存所述开具的停车发票与对应的指定支付订单信息，并统计所述开具的停车发票的数量和剩余发票的数量；当所述剩余发票的数量小于预设阈值时，进行库存紧张提醒。

依据本发明的又一方面，提供了一种开具停车发票的系统，该系统包括一个或多个客户端、一个或多个税控设备，以及一个如权利要求6-10中任一项所述服务器；

所述客户端，用于发送与指定支付订单对应的开票请求；

所述税控设备设置在与停车场对应的本地盘或网托盘上，用于根据所述开票申请开具停车发票。

依据本发明的又一方面，提供了一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如上述任一所述的方法。

依据本发明的再一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如上述任一所述的方法。

由上述可知，本发明的技术方案，服务器通过接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识；判断指定支付订单是否满足开具停车发票的条件；是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票；将停车发票返回给客户端。如此，用户只需要在移动设备如手机上，就可以随时随地自主地对停车费进行开票操作，而无需到停车场的服务台处或在停车场的岗亭处等待开具停车发票，节省开票的等待时间，用户可以更加便捷的获得停车发票。而且，采用该方式，可以实现针对具体的支付订单准确地开具发票，避免发票虚开，保障停车场的财务安全。同时，还可以节省停车场的人力资源，降低经营成本。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的一种开具停车发票的方法的流程示意图；

图2示出了根据本发明一个实施例的一种开具停车发票的服务器的结构示意图；

图3示出了根据本发明一个实施例的一种开具停车发票的系统的结构示意图；

图4示出了根据本发明一个实施例的电子设备的结构示意图；

图5示出了根据本发明一个实施例的计算机可读存储介质的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的一种开具停车发票的方法的流程示意图。如图1所示，该方法包括：

步骤S110，接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识。

这里的客户端是停车场的客户端，用户使用客户端可以实现自主停车，从进场停车到支付停车费，完成出场，均可以在客户端上操作。该客户端可以是一个独立的停车场停车APP，也可以是小程序应用，或公众号。

以停车APP为例，当用户在APP内支付停车费完成出场后，APP内记录保存该次的支付订单，以及对应的停车信息，如停车场、停车时间和停车日期、停车金额等。当用户需要发票时，可选中该支付订单提交停车发票的开票请求。根据开票请求中的停车场标识，与该停车场标识对应的停车场的系统处理该开票请求，开具停车发票。上述的指定支付订单，就是指用户选中需要开具停车发票的支付订单。

在另一具体的实施例中，用户使用现金或停车场岗亭处的扫码枪或扫描停车场的收费二维码支付停车费时，只获得停车票据，而支付订单并未记录在客户端中。在该情况下，用户可通过扫描停车票据上的二维码，向服务器发送跳转至客户端的请求。服务器对该请求进行处理，用户即可跳转进入客户端。停车票据上的二维码是记录有本次停车的支付订单以及相应地停车信息的二维码。跳转至客户端后，客户端根据二维码中的信息加载出本次支付订单，用户从客户端中提交该支付订单的开票请求即可。

另外，用户使用其他移动支付方式支付停车费时，可以获得电子停车票据，该电子停车票据中同样包含有记录有本次停车的支付订单以及相应地停车信息的二维码。用户识别该二维码，跳转至客户端，进行开票操作。

另一方面，上述的二维码中还包含有停车场的公众号信息，用户识别或扫描该二维码后，向服务器发送跳转至公众号的请求，服务器对该请求进行处理，返回跳转至停车场的公众号关注页面的信息。在用户关注停车场的公众号后，服务器向用户返回本次支付订单的开票链接，用户通过该开票链接向服务器发送开票请求。

采用上述方式，用户可以随时随地自主地对停车费进行开票操作，而无需到停车场的服务台处或在停车场的岗亭处等待开具停车发票，节省开票的等待时间。

步骤S120，判断指定支付订单是否满足开具停车发票的条件。是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票。

服务器接收到开票请求后，需要核对其中的指定支付订单，确定该指定支付订单满足开具停车发票的条件。例如判断指定支付订单是否已开具停车发票，在指定支付订单已开具停车发票的情况下，则其不满足开具停车发票的条件。或者，判断指定支付订单的支付时间是否已超过可开具停车发票的时间等。在指定支付订单满足开具停车发票的条件的情况下，可进行开票处理。发票一般由税控设备开具，而且各个停车场置有自身专属的税控设备，服务器根据开票请求中的停车场标识，向对应停车场的税控设备提交开票申请，由税控设备开具停车发票。

在一个具体的例子中，开票请求中的停车场标识为1，则服务器向一号停车场的税控设备提交开票申请。通过停车场标识确定各个指定支付订单的收款方，准确地开具发票，避免发票虚开，保障停车场的财务安全。

步骤S130，将停车发票返回给客户端。

服务器获取税控设备开具的停车发票，将其返回给客户端，完成向用户提供停车发票。用户可下载保存停车发票，自行进行打印使用或直接使用电子版的停车发票。这样，既节省了停车场的人力资源，降低经营成本，还可以给用户提供更加便捷的服务。

本发明的技术方案，服务器通过接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识；判断指定支付订单是否满足开具停车发票的条件；是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票；将停车发票返回给客户端。如此，用户只需要在移动设备如手机上，就可以随时随地自主地对停车费进行开票操作，而无需到停车场的服务台处或在停车场的岗亭处等待开具停车发票，节省开票的等待时间，用户可以更加便捷的获得停车发票。而且，采用该方式，可以实现针对具体的支付订单准确地开具发票，避免发票虚开，保障停车场的财务安全。同时，还可以节省停车场的人力资源，降低经营成本。

在本发明的一个实施例中，如图1所示的方法中，指定支付订单包括至少一条停车费支付订单。步骤S120中的判断指定支付订单是否满足开具停车发票的条件包括：逐条判断停车费支付订单是否满足开具停车发票的条件。是则根据标识向对应停车场的税控设备提交开票申请包括：将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向税控设备提交。

本实施例提供了存在多条支付订单时开具停车发票的具体实施方式。为了更加方便用户开具停车发票，用户可以同时对多条支付订单进行开票操作。例如，使用客户端实现停车的用户，停车费的支付订单会被记录在客户端中。单条支付订单金额较少，其发票可能达不到可以报销的金额。另外，对单条支付订单进行开票操作，当客户端中记录有多条支付订单，需要多次反复提交开票请求，增加了开票操作的繁琐性。

因此，用户需要开具停车发票时，可以选中客户端中记录保存的所有支付订单进行一次开票操作，这样可以简化开票流程，节约用户时间。而且可以获得金额较大的停车发票，便于进行报销。服务器需要逐条判断支付订单是否满足开票条件，将满足开票条件的支付订单进行整合，如获得开票金额、用户输入的发票抬头、销方信息等。将整合后的信息合并生成一条开票申请向税控设备提交。

在该方式下，用户可以自行选择支付订单，以组成所需金额的发票。例如当用户需要100元的停车发票时，可选择4个25元的支付订单提交开具100元停车发票。对于使用现金或扫码枪支付的用户，扫描支付凭证上的二维码后可跳转至客户端，用户只需要在客户端中注册并登陆，该条支付订单将被记录在客户端中，用户可以稍后再对其进行开票操作。

在本发明的一个实施例中，如图1所示的方法中，指定支付订单中包括支付停车费的用户标识，开票请求中包括客户端中的用户标识。步骤S120中的判断指定支付订单是否满足开具停车发票的条件包括：若支付停车费的用户标识与客户端中的用户标识一致，则满足开具停车发票的条件；和/或，若指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

本实施例提供了多种判断指定支付订单是否满足开票条件的具体实现方式。第一种方式为专票专开，也就是支付停车费的用户才可以对支付订单进行开票操作获取停车发票，这样可以确保用户的利益和停车场的财物安全。具体为，用户A使用停车场的客户端支付停车费，则该支付订单的用户标识为A。若用户B通过扫描该支付订单的二维码跳转至客户端，并针对该支付订单向服务器发送开票请求，则开票请求中携带的用户标识为B。这样，客户端中的用户标识B与支付订单中的用户标识A不一致，则服务器返回“用户不符，无法开具停车发票”的信息，以提示用户使用正确的登录名登录客户端。通过该方式，可以确保用户A消费的停车费不被其他人使用开具停车发票，保障用户的权益。

另一方面，判断用户标识是否一致，还可以通过手机号进行判断。例如用户使用某移动支付方式支付了停车费，其中移动支付方式中绑定的手机号为C。用户登录停车场的客户端，其中绑定的手机号也为C。这样，支付订单中的用户标识和客户端中的用户标识均为C，用户就可以对该支付订单进行开票操作。通过该方式，用户可以采用多种支付方式支付停车费，而不限于使用停车场的客户端进行支付，提高停车费支付的便捷性和开票操作的灵活性。

第二种方式为，判断指定支付订单是否未被开具停车发票。对于已开具过停车发票的支付订单，不能再次对其开具停车发票。因此，对已被开具停车发票的支付订单进行标记，与未被开具停车发票的支付订单进行区分。例如，在已被开具停车发票的支付订单的链接中插入标记1，在判断时，过滤具有标记1的指定支付订单。如此，只有未被开具停车发票的指定支付订单通过筛选，从而可以准确地开出停车发票，保障停车场的财物安全。

另外，还可以根据停车场的需求，限制在支付订单的可开票时间。在限制时间内，用户可在客户端上对支付订单进行开票操作。若超过限制时间，则无法在客户端上对相应的支付订单进行开票操作。在该情况下，用户可自行到停车场的服务中心或财务部进行人工开票，确保自己的合法权益。因此，还可以通过判断指定支付订单的支付时间是否超过可开票的时间，如支付时间在三个月内的指定支付订单可开具停车发票，若支付时间至开票时间已超过三个月，则无法进行开票操作。

在本发明的一个实施例中，如图1所示的方法中，步骤S120中的是则根据标识向对应停车场的税控设备提交开票申请包括：根据标识向对应停车场的本地盘上的税控设备提交开票申请；和/或，根据标识向对应停车场的网托盘上的税控设备提交开票申请。

本实施例提供了部署税控设备的具体实现方式。停车场中需要部署税控设备，才能够开具停车发票。在小型停车场中，开票量较小，不需要较高的开票效率，可以将税控设备部署在停车场的本地电脑上，也就是采用本地盘的部署模式，如此即可满足开票需求。采用该种方式，可以降低停车场的运行和维护成本。

对于大型停车场，开票需求量大，需要提高开票效率才能满足用户的需求，因此最好采取网托盘的部署模式，也就是将税控设备部署在计算机集群上或服务器上，这样数据访问、处理速度都加快，可以提高开票效率。同时服务器的性能优于电脑，更能稳定地支持大数量并发开票。

各个停车场可以根据具体情况选择对应的税控设备部署模式，以满足停车场的不同需求。

在本发明的一个实施例中，如图1所示的方法中，该方法还包括：保存开具的停车发票与对应的指定支付订单信息，并统计已开具的停车发票的数量和剩余发票的数量；当剩余发票的数量小于预设阈值时，进行库存紧张提醒。

为了进一步确保停车场财物安全和方便后期的财务对账，对于已开具的停车发票，需要记录保存其详细信息。例如，服务器每开出一张停车发票，需要记录对应的指定支付订单、发票金额、发票抬头和销方信息等。若停车发票是由多个指定支付订单合并而来，则详细记录每一条指定支付订单的信息，如每条指定支付订单的金额和其中的停车信息等。这样，可以有效避免停车发票虚开，保障停车场的财物安全，而且也更加方便财务人员进行对账。

另一方面，为了加强停车场的停车发票管理，确保有充足的停车发票提供给消费者，还需要对已开具的停车发票数量和剩余的停车发票数量进行统计。例如，每开具一张停车发票，则已开具的停车发票数量加1，剩余的停车发票数量减1。通过查看已开具的停车发票数量，可以获知停车发票的需求量。而通过查看剩余的停车发票数量，可以确保是否还具有充足的停车发票，从而及时采取相应地措施。剩余的停车发票数量小于预设阈值，说明停车发票紧张，进行库存紧张提醒，以使工作人员及时补充停车发票。预设阈值可以自由进行设置，如设置停车发票剩余10张、25张或50张时，进行库存紧张提醒。

在一个具体的例子中，统计每天已开具的停车发票数量和剩余的停车发票数量，由此可以获知停车场每天的发票需求量，这对停车场部署每天的发票数量具有指导性的意义，有利于停车场进行报税。例如，停车场每天所开具的停车发票数量在500张左右，这样每天只需要提供550至600张停车发票，就可以满足每天的发票需求。统计每个月已开具的停车发票，大概为15,000张，则停车场每个月只需要准备15,000张停车发票，减少每月到税局购买发票的次数，节省车场的人力成本。

图2示出了根据本发明一个实施例的一种开具停车发票的服务器。如图2所示，该服务器200包括：

接收单元210，用于接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识。

这里的客户端是停车场的客户端，用户使用客户端可以实现自主停车，从进场停车到支付停车费，完成出场，均可以在客户端上操作。该客户端可以是一个独立的停车场停车APP，也可以是小程序应用，或公众号。

以停车APP为例，当用户在APP内支付停车费完成出场后，APP内记录保存该次的支付订单，以及对应的停车信息，如停车场、停车时间和停车日期、停车金额等。当用户需要发票时，可选中该支付订单提交停车发票的开票请求。根据开票请求中的停车场标识，与该停车场标识对应的停车场的系统处理该开票请求，开具停车发票。上述的指定支付订单，就是指用户选中需要开具停车发票的支付订单。

在另一具体的实施例中，用户使用现金或停车场岗亭处的扫码枪或扫描停车场的收费二维码支付停车费时，只获得停车票据，而支付订单并未记录在客户端中。在该情况下，用户可通过扫描停车票据上的二维码，向服务器发送跳转至客户端的请求。服务器对该请求进行处理，用户即可跳转进入客户端。停车票据上的二维码是记录有本次停车的支付订单以及相应地停车信息的二维码。跳转至客户端后，客户端根据二维码中的信息加载出本次支付订单，用户从客户端中提交该支付订单的开票请求即可。

另外，用户使用其他移动支付方式支付停车费时，可以获得电子停车票据，该电子停车票据中同样包含有记录有本次停车的支付订单以及相应地停车信息的二维码。用户识别该二维码，跳转至客户端，进行开票操作。

另一方面，上述的二维码中还包含有停车场的公众号信息，用户识别或扫描该二维码后，向服务器发送跳转至公众号的请求，服务器对该请求进行处理，返回跳转至停车场的公众号关注页面的信息。在用户关注停车场的公众号后，服务器向用户返回本次支付订单的开票链接，用户通过该开票链接向服务器发送开票请求。

采用上述方式，用户可以随时随地自主地对停车费进行开票操作，而无需到停车场的服务台处或在停车场的岗亭处等待开具停车发票，节省开票的等待时间。

提交单元220，用于判断指定支付订单是否满足开具停车发票的条件；是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票。

服务器接收到开票请求后，需要核对其中的指定支付订单，确定该指定支付订单满足开具停车发票的条件。例如判断指定支付订单是否已开具停车发票，在指定支付订单已开具停车发票的情况下，则其不满足开具停车发票的条件。或者，判断指定支付订单的支付时间是否已超过可开具停车发票的时间等。在指定支付订单满足开具停车发票的条件的情况下，可进行开票处理。发票一般由税控设备开具，而且各个停车场置有自身专属的税控设备，服务器根据开票请求中的停车场标识，向对应停车场的税控设备提交开票申请，由税控设备开具停车发票。

在一个具体的例子中，开票请求中的停车场标识为1，则服务器向一号停车场的税控设备提交开票申请。通过停车场标识确定各个指定支付订单的收款方，准确地开具发票，避免发票虚开，保障停车场的财务安全。

返回单元230，用于将停车发票返回给客户端。

服务器获取税控设备开具的停车发票，将其返回给客户端，完成向用户提供停车发票。用户可下载保存停车发票，自行进行打印使用或直接使用电子版的停车发票。这样，既节省了停车场的人力资源，降低经营成本，还可以给用户提供更加便捷的服务。

本发明的技术方案，服务器通过接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识；判断指定支付订单是否满足开具停车发票的条件；是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票；将停车发票返回给客户端。如此，用户只需要在移动设备如手机上，就可以随时随地自主地对停车费进行开票操作，而无需到停车场的服务台处或在停车场的岗亭处等待开具停车发票，节省开票的等待时间，用户可以更加便捷的获得停车发票。而且，采用该方式，可以实现针对具体的支付订单准确地开具发票，避免发票虚开，保障停车场的财务安全。同时，还可以节省停车场的人力资源，降低经营成本。

在本发明的一个实施例中，如图2所示的服务器200中，指定支付订单包括至少一条停车费支付订单；提交单元220，进一步用于逐条判断停车费支付订单是否满足开具停车发票的条件；将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向税控设备提交。

本实施例提供了存在多条支付订单时开具停车发票的具体实施方式。为了更加方便用户开具停车发票，用户可以同时对多条支付订单进行开票操作。例如，使用客户端实现停车的用户，停车费的支付订单会被记录在客户端中。单条支付订单金额较少，其发票可能达不到可以报销的金额。另外，对单条支付订单进行开票操作，当客户端中记录有多条支付订单，需要多次反复提交开票请求，增加了开票操作的繁琐性。

因此，用户需要开具停车发票时，可以选中客户端中记录保存的所有支付订单进行一次开票操作，这样可以简化开票流程，节约用户时间。而且可以获得金额较大的停车发票，便于进行报销。服务器需要逐条判断支付订单是否满足开票条件，将满足开票条件的支付订单进行整合，如获得开票金额、用户输入的发票抬头、销方信息等。将整合后的信息合并生成一条开票申请向税控设备提交。

在该方式下，用户可以自行选择支付订单，以组成所需金额的发票。例如当用户需要100元的停车发票时，可选择4个25元的支付订单提交开具100元停车发票。对于使用现金或扫码枪支付的用户，扫描支付凭证上的二维码后可跳转至客户端，用户只需要在客户端中注册并登陆，该条支付订单将被记录在客户端中，用户可以稍后再对其进行开票操作。

在本发明的一个实施例中，如图2所示的服务器200中，指定支付订单中包括支付停车费的用户标识，开票请求中包括客户端中的用户标识；提交单元220，进一步用于若支付停车费的用户标识与客户端中的用户标识一致，则满足开具停车发票的条件；和/或，若指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

本实施例提供了多种判断指定支付订单是否满足开票条件的具体实现方式。第一种方式为专票专开，也就是支付停车费的用户才可以对支付订单进行开票操作获取停车发票，这样可以确保用户的利益和停车场的财物安全。具体为，用户A使用停车场的客户端支付停车费，则该支付订单的用户标识为A。若用户B通过扫描该支付订单的二维码跳转至客户端，并针对该支付订单向服务器发送开票请求，则开票请求中携带的用户标识为B。这样，客户端中的用户标识B与支付订单中的用户标识A不一致，则服务器返回“用户不符，无法开具停车发票”的信息，以提示用户使用正确的登录名登录客户端。通过该方式，可以确保用户A消费的停车费不被其他人使用开具停车发票，保障用户的权益。

另一方面，判断用户标识是否一致，还可以通过手机号进行判断。例如用户使用某移动支付方式支付了停车费，其中移动支付方式中绑定的手机号为C。用户登录停车场的客户端，其中绑定的手机号也为C。这样，支付订单中的用户标识和客户端中的用户标识均为C，用户就可以对该支付订单进行开票操作。通过该方式，用户可以采用多种支付方式支付停车费，而不限于使用停车场的客户端进行支付，提高停车费支付的便捷性和开票操作的灵活性。

第二种方式为，判断指定支付订单是否未被开具停车发票。对于已开具过停车发票的支付订单，不能再次对其开具停车发票。因此，对已被开具停车发票的支付订单进行标记，与未被开具停车发票的支付订单进行区分。例如，在已被开具停车发票的支付订单的链接中插入标记1，在判断时，过滤具有标记1的指定支付订单。如此，只有未被开具停车发票的指定支付订单通过筛选，从而可以准确地开出停车发票，保障停车场的财物安全。

另外，还可以根据停车场的需求，限制在支付订单的可开票时间。在限制时间内，用户可在客户端上对支付订单进行开票操作。若超过限制时间，则无法在客户端上对相应的支付订单进行开票操作。在该情况下，用户可自行到停车场的服务中心或财务部进行人工开票，确保自己的合法权益。因此，还可以通过判断指定支付订单的支付时间是否超过可开票的时间，如支付时间在三个月内的指定支付订单可开具停车发票，若支付时间至开票时间已超过三个月，则无法进行开票操作。

在本发明的一个实施例中，如图2所示的服务器200中，提交单元220，进一步用于根据标识向对应停车场的本地盘上的税控设备提交开票申请；和/或，根据标识向对应停车场的网托盘上的税控设备提交开票申请。

本实施例提供了部署税控设备的具体实现方式。停车场中需要部署税控设备，才能够开具停车发票。在小型停车场中，开票量较小，不需要较高的开票效率，可以将税控设备部署在停车场的本地电脑上，也就是采用本地盘的部署模式，如此即可满足开票需求。采用该种方式，可以降低停车场的运行和维护成本。

对于大型停车场，开票需求量大，需要提高开票效率才能满足用户的需求，因此最好采取网托盘的部署模式中，也就是将税控设备部署在计算机集群上或服务器上，这样数据访问、处理速度都加快，可以提高开票效率。同时服务器的性能优于电脑，更能稳定地支持大数量并发开票。

各个停车场可以根据具体情况选择对应的税控设备部署模式，以满足停车场的不同需求。

在本发明的一个实施例中，如图2所示的服务器200中，该服务器200还包括：统计单元，用于保存开具的停车发票与对应的指定支付订单信息，并统计开具的停车发票的数量和剩余发票的数量；当剩余发票的数量小于预设阈值时，进行库存紧张提醒。

为了进一步确保停车场财物安全和方便后期的财务对账，对于已开具的停车发票，需要记录保存其详细信息。例如，服务器每开出一张停车发票，需要记录对应的指定支付订单、发票金额、发票抬头和销方信息等。若停车发票是由多个指定支付订单合并而来，则详细记录每一条指定支付订单的信息，如每条指定支付订单的金额和其中的停车信息等。这样，可以有效避免停车发票虚开，保障停车场的财物安全，而且也更加方便财务人员进行对账。

另一方面，为了加强停车场的停车发票管理，确保有充足的停车发票提供给消费者，还需要对已开具的停车发票数量和剩余的停车发票数量进行统计。例如，每开具一张停车发票，则已开具的停车发票数量加1，剩余的停车发票数量减1。通过查看已开具的停车发票数量，可以获知停车发票的需求量。而通过查看剩余的停车发票数量，可以确保是否还具有充足的停车发票，从而及时采取相应地措施。剩余的停车发票数量小于预设阈值，说明停车发票紧张，进行库存紧张提醒，以使工作人员及时补充停车发票。预设阈值可以自由进行设置，如设置停车发票剩余10张、25张或50张时，进行库存紧张提醒。

在一个具体的例子中，统计每天已开具的停车发票数量和剩余的停车发票数量，由此可以获知停车场每天的发票需求量，这对停车场部署每天的发票数量具有指导性的意义，有利于停车场进行报税。例如，停车场每天所开具的停车发票数量在500张左右，这样每天只需要提供550至600张停车发票，就可以满足每天的发票需求。统计每个月已开具的停车发票，大概为15,000张，则停车场每个月只需要准备15,000张停车发票，节省停车场财税人员到税局购买发票的人力。

图3示出了根据本发明一个实施例的一种开具停车发票的系统。如图3所示，该系统300包括一个或多个客户端310、一个或多个税控设备320，以及一个如上述中任一实施例的服务器200。

客户端310，用于发送与指定支付订单对应的开票请求。

客户端是停车场的客户端，用户使用客户端可以实现自主停车，从进场停车到支付停车费，完成出场，均可以在客户端上操作。该客户端可以是一个独立的停车场停车APP，也可以是小程序应用，或公众号。

税控设备320，设置在与停车场对应的本地盘或网托盘上，用于根据开票申请开具停车发票。

在小型停车场中，开票量较小，不需要较高的开票效率，可以将税控设备320部署在停车场的本地电脑上，也就是采用本地盘的部署模式，如此即可满足开票需求。采用该种方式，可以降低停车场的运行和维护成本。对于大型停车场，开票需求量大，需要提高开票效率才能满足用户的需求，因此最好采取网托盘的部署模式，也就是将税控设备部署在计算机集群上或服务器上，这样数据访问、处理速度都加快，可以提高开票效率。同时服务器的性能优于电脑，更能稳定地支持大数量并发开票。

各个停车场可以根据具体情况选择对应的税控设备部署模式，以满足停车场的不同需求。

服务器200为上述任一实施例的服务器，开具停车发票的系统300的具体实现原理可参照上述实施例，此处不再进行赘述。

综上所述，本发明的技术方案，服务器通过接收客户端发送的与指定支付订单对应的开票请求；开票请求中包含有与指定支付订单对应的停车场的标识；判断指定支付订单是否满足开具停车发票的条件；是则根据标识向对应停车场的税控设备提交开票申请，获取税控设备开具的停车发票；将停车发票返回给客户端。如此，用户只需要在移动设备如手机上，就可以随时随地自主地对停车费进行开票操作，而无需到停车场的服务台处或在停车场的岗亭处等待开具停车发票，节省开票的等待时间，用户可以更加便捷的获得停车发票。而且，采用该方式，可以实现针对具体的支付订单准确地开具发票，避免发票虚开，保障停车场的财务安全。同时，还可以节省停车场的人力资源，降低经营成本。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的开具停车发票的服务器中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

例如，图4示出了根据本发明一个实施例的电子设备的结构示意图。该电子设备包括处理器410和被安排成存储计算机可执行指令(计算机可读程序代码)的存储器420。存储器420可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器420具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代码431的存储空间430。例如，用于存储计算机可读程序代码的存储空间430可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代码431。计算机可读程序代码431可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图5所述的计算机可读存储介质。图5示出了根据本发明一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读存储介质500存储有用于执行根据本发明的方法步骤的计算机可读程序代码431，可以被电子设备400的处理器410读取，当计算机可读程序代码431由电子设备400运行时，导致该电子设备400执行上面所描述的方法中的各个步骤，具体来说，该计算机可读存储介质存储的计算机可读程序代码431可以执行上述任一实施例中示出的方法。计算机可读程序代码431可以以适当形式进行压缩。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明还提供了A1、一种开具停车发票的方法，其特征在于，该方法包括：

接收客户端发送的与指定支付订单对应的开票请求；所述开票请求中包含有与所述指定支付订单对应的停车场的标识；

判断所述指定支付订单是否满足开具停车发票的条件；

是则根据所述标识向对应停车场的税控设备提交开票申请，获取所述税控设备开具的停车发票；

将所述停车发票返回给所述客户端。

A2、如A1所述的方法，其特征在于，所述指定支付订单包括至少一条停车费支付订单；

所述判断所述指定支付订单是否满足开具停车发票的条件包括：

逐条判断所述停车费支付订单是否满足开具停车发票的条件；

所述是则根据所述标识向对应停车场的税控设备提交开票申请包括：

将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向所述税控设备提交。

A3、如A1所述的方法，其特征在于，所述指定支付订单中包括支付停车费的用户标识，所述开票请求中包括所述客户端中的用户标识；

所述判断所述指定支付订单是否满足开具停车发票的条件包括：

若所述支付停车费的用户标识与所述客户端中的用户标识一致，则满足开具停车发票的条件；和/或

若所述指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

A4、如A1所述的方法，其特征在于，所述是则根据所述标识向对应停车场的税控设备提交开票申请包括：

根据所述标识向对应停车场的本地盘上的税控设备提交开票申请；和/或

根据所述标识向对应停车场的网托盘上的税控设备提交开票申请。

A5、如A1所述的方法，其特征在于，该方法还包括：

保存所述开具的停车发票与对应的指定支付订单信息，并统计已开具的停车发票的数量和剩余发票的数量；

当所述剩余发票的数量小于预设阈值时，进行库存紧张提醒。

本发明还提供了B6、一种开具停车发票的服务器，其特征在于，该服务器包括：

接收单元，用于接收客户端发送的与指定支付订单对应的开票请求；所述开票请求中包含有与所述指定支付订单对应的停车场的标识；

提交单元，用于判断所述指定支付订单是否满足开具停车发票的条件；是则根据所述标识向对应停车场的税控设备提交开票申请，获取所述税控设备开具的停车发票；

返回单元，用于将所述停车发票返回给所述客户端。

B7、如B6所述的服务器，其特征在于，所述指定支付订单包括至少一条停车费支付订单；

所述提交单元，进一步用于逐条判断所述停车费支付订单是否满足开具停车发票的条件；将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向所述税控设备提交。

B8、如B6所述的服务器，其特征在于，所述指定支付订单中包括支付停车费的用户标识，所述开票请求中包括所述客户端中的用户标识；

所述提交单元，进一步用于若所述支付停车费的用户标识与所述客户端中的用户标识一致，则满足开具停车发票的条件；和/或

若所述指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

B9、如B6所述的服务器，其特征在于，所述提交单元，进一步用于根据所述标识向对应停车场的本地盘上的税控设备提交开票申请；和/或

根据所述标识向对应停车场的网托盘上的税控设备提交开票申请。

B10、如B6所述的服务器，其特征在于，该服务器还包括：

统计单元，用于保存所述开具的停车发票与对应的指定支付订单信息，并统计已开具的停车发票的数量和剩余发票的数量；当所述剩余发票的数量小于预设阈值时，进行库存紧张提醒。

本发明还提供了C11、一种开具停车发票的系统，其特征在于，该系统包括一个或多个客户端、一个或多个税控设备，以及一个如A6-A10中任一项所述服务器；

所述客户端，用于发送与指定支付订单对应的开票请求；

所述税控设备设置在与停车场对应的本地盘或网托盘上，用于根据所述开票申请开具停车发票。

本发明还提供了D12、一种电子设备，其特征在于，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如A1-A5中任一所述的方法。

本发明还提供了E13、一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如A1-A5中任一项所述的方法。

Claims (10)

1.一种开具停车发票的方法，其特征在于，该方法包括：

接收客户端发送的与指定支付订单对应的开票请求；所述开票请求中包含有与所述指定支付订单对应的停车场的标识；

判断所述指定支付订单是否满足开具停车发票的条件；

是则根据所述标识向对应停车场的税控设备提交开票申请，获取所述税控设备开具的停车发票；

将所述停车发票返回给所述客户端。

2.如权利要求1所述的方法，其特征在于，所述指定支付订单包括至少一条停车费支付订单；

所述判断所述指定支付订单是否满足开具停车发票的条件包括：

逐条判断所述停车费支付订单是否满足开具停车发票的条件；

所述是则根据所述标识向对应停车场的税控设备提交开票申请包括：

将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向所述税控设备提交。

3.如权利要求1所述的方法，其特征在于，所述指定支付订单中包括支付停车费的用户标识，所述开票请求中包括所述客户端中的用户标识；

所述判断所述指定支付订单是否满足开具停车发票的条件包括：

若所述支付停车费的用户标识与所述客户端中的用户标识一致，则满足开具停车发票的条件；和/或

若所述指定支付订单信息未被开具停车发票，则满足开具停车发票的条件。

4.如权利要求1所述的方法，其特征在于，所述是则根据所述标识向对应停车场的税控设备提交开票申请包括：

根据所述标识向对应停车场的本地盘上的税控设备提交开票申请；和/或

根据所述标识向对应停车场的网托盘上的税控设备提交开票申请。

5.如权利要求1所述的方法，其特征在于，该方法还包括：

保存所述开具的停车发票与对应的指定支付订单信息，并统计已开具的停车发票的数量和剩余发票的数量；

当所述剩余发票的数量小于预设阈值时，进行库存紧张提醒。

6.一种开具停车发票的服务器，其特征在于，该服务器包括：

接收单元，用于接收客户端发送的与指定支付订单对应的开票请求；所述开票请求中包含有与所述指定支付订单对应的停车场的标识；

提交单元，用于判断所述指定支付订单是否满足开具停车发票的条件；是则根据所述标识向对应停车场的税控设备提交开票申请，获取所述税控设备开具的停车发票；

返回单元，用于将所述停车发票返回给所述客户端。

7.如权利要求6所述的服务器，其特征在于，所述指定支付订单包括至少一条停车费支付订单；

所述提交单元，进一步用于逐条判断所述停车费支付订单是否满足开具停车发票的条件；将所有满足开具停车发票的停车费支付订单进行合并，生成一条开票申请向所述税控设备提交。

8.一种开具停车发票的系统，其特征在于，该系统包括一个或多个客户端、一个或多个税控设备，以及一个如权利要求6-7中任一项所述服务器；

所述客户端，用于发送与指定支付订单对应的开票请求；

所述税控设备设置在与停车场对应的本地盘或网托盘上，用于根据所述开票申请开具停车发票。

9.一种电子设备，其特征在于，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如权利要求1-5中任一所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如权利要求1-5中任一项所述的方法。