CN111897777A

CN111897777A - 电子发票版式文件的处理方法、装置、设备及存储介质

Info

Publication number: CN111897777A
Application number: CN202010596569.4A
Authority: CN
Inventors: 陈杰; 杨正道; 冯辉; 段伟光; 韩宇菲
Original assignee: Baiwang Co ltd
Current assignee: Baiwang Co ltd
Priority date: 2020-06-22
Filing date: 2020-06-22
Publication date: 2020-11-06

Abstract

本申请公开了一种电子发票版式文件的处理方法、装置、设备及存储介质。电子发票版式文件的处理方法，包括：响应于对电子发票文件的查看或打印申请，发送合并文件请求；检查缓存中是否存在所述电子发票文件的合并文件，如果有则直接返回缓存的合并文件，否则对所述电子发票文件进行合并处理。本申请的电子发票版式文件的处理方法，处理后的版式文件体积小，网络传输快，处理速度快，占用CPU资源较少，可以很好地满足实际需要。

Description

电子发票版式文件的处理方法、装置、设备及存储介质

技术领域

本申请涉及电子发票技术领域，具体涉及一种电子发票版式文件的处理方法、装置、设备及存储介质。

背景技术

在电子发票平台中，客户可以浏览打印历史票据，为了方便操作，常常提供批量操作，如允许同时选择多张发票预览或打印。

常见的处理方式是通过后台将多张发票文件转成图片并传到前端，然后由前端将这些图片按文件顺序重新组织成连续的页面后实现预览或打印功能。其基本流程如下：

1.用户在前端页面勾选部分或全部电子发票文件，点查看或打印功能；

2.前端请求后台生成图片文件并将发票文件列表、分辨率等参数发送给后台；

3.后台根据请求参数将发票文件渲染成图片文件并将图片打包传回前端；

4.前端接收图片文件包，解压后用于显示或打印操作。

5.用户如果放大显示的百分比例或打印的分辨率都需要重复步骤2、3、4。

采用现有技术的处理方式，将页面转成图片文件需要光栅化和图像格式编码，这两种处理不仅速度慢、占用CPU资源多，而且生成的图片文件体积大，在由后端传到前端进行预览时占用网络带宽大。由于用户在前端触发放大操作很常见，缩放电子发票往往需要多次发送请求，造成后台服务器压力大，最终导致系统显示卡顿，打印速度慢等问题，因此，这种基于后台渲染成图片的技术架构常常存在性能问题。

发明内容

本申请的目的是提供一种电子发票版式文件的处理方法、装置、设备及存储介质。为了对披露的实施例的一些方面有一个基本的理解，下面给出了简单的概括。该概括部分不是泛泛评述，也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念，以此作为后面的详细说明的序言。

根据本申请实施例的一个方面，提供一种电子发票版式文件的处理方法，包括：

响应于对电子发票文件的查看或打印申请，发送合并文件请求；

检查缓存中是否存在所述电子发票文件的合并文件，如果有则直接返回缓存的合并文件，否则对所述电子发票文件进行合并处理。

进一步地，所述检查缓存中是否存在所述电子发票文件的合并文件，包括：将所述合并文件请求中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在所述电子发票文件的合并文件。

进一步地，所述检查缓存中是否存在所述电子发票文件的合并文件，包括：首先将所述合并文件请求的请求参数中的文件ID字符串连接起来，然后使用SHA256散列算法计算散列值，并使用散列值作为键值检查缓存中是否存在所述电子发票文件的合并文件。

进一步地，在所述对所述电子发票文件进行合并处理之前，所述方法还包括：统一所述电子发票文件的格式。

进一步地，所述统一所述电子发票文件的格式，包括：使用文件格式转换技术将PDF转成OFD或者将OFD转成PDF。

进一步地，所述统一所述电子发票文件的格式，包括：

计算不同格式文档互相转换的所耗时间以及各格式文档的合并所耗时间；

根据所述互相转换的所耗时间和所述合并所耗时间，选择所述电子发票文件合并后的文档格式。

根据本申请实施例的另一个方面，提供一种电子发票版式文件的处理装置，包括：

第一模块，用于响应于对电子发票文件的查看或打印申请，发送合并文件请求；

第二模块，用于检查缓存中是否存在所述电子发票文件的合并文件，如果有则直接返回缓存的合并文件，否则对所述电子发票文件进行合并处理。

进一步地，所述第二模块包括检查模块，所述检查模块用于将所述合并文件请求中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在所述电子发票文件的合并文件。

根据本申请实施例的另一个方面，提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的电子发票版式文件的处理方法。

根据本申请实施例的另一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述的电子发票版式文件的处理方法。

本申请实施例的其中一个方面提供的技术方案可以包括以下有益效果：

本申请实施例提供的电子发票版式文件的处理方法，处理后的版式文件体积小，网络传输快，处理速度快，占用CPU资源较少，可以很好地满足实际需要。

本申请的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者，部分特征和优点可以从说明书中推知或毫无疑义地确定，或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了现有技术的多张电子发票预览或打印的处理方法的流程图；

图2示出了本申请的一个实施例的电子发票版式文件的处理方法流程图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，下面结合附图和具体实施例对本申请做进一步说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本申请的第一个实施例提供了一种电子发票版式文件的处理方法，包括：

S10、响应于对电子发票文件的查看或打印申请，发送合并文件请求；

S20、检查缓存中是否存在所述电子发票文件的合并文件，如果有则直接返回缓存的合并文件，否则对所述电子发票文件进行合并处理。

在某些实施方式中，检查缓存中是否存在所述电子发票文件的合并文件，包括：将所述合并文件请求中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在所述电子发票文件的合并文件。

在某些实施方式中，所述检查缓存中是否存在所述电子发票文件的合并文件，包括：首先将所述合并文件请求的请求参数中的文件ID字符串连接起来，然后使用SHA256散列算法计算散列值，并使用散列值作为键值检查缓存中是否存在所述电子发票文件的合并文件。

在某些实施方式中，在所述对所述电子发票文件进行合并处理之前，所述方法还包括：统一所述电子发票文件的格式。

在某些实施方式中，所述统一所述电子发票文件的格式，包括：使用文件格式转换技术将PDF转成OFD或者将OFD转成PDF。

在某些实施方式中，所述统一所述电子发票文件的格式，包括：

本申请的另一个实施例提供了一种电子发票版式文件的处理装置，包括：

在某些实施方式中，所述第二模块包括检查模块，所述检查模块用于将所述合并文件请求中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在所述电子发票文件的合并文件。

本申请的另一个实施例提供了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的电子发票版式文件的处理方法。

本申请的另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述的电子发票版式文件的处理方法。

就本说明书而言，“计算机可读存储介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读存储介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

本申请的另一个实施例提供了一种电子发票版式文件的处理方法，采用文件合并的方式，通过后台将多张电子发票合并成一个版式文件，然后由前端直接对版式文件进行解析、渲染，实现显示和打印等功能。由于通过网络传输的是文件而非图片，所以体积明显小很多，更重要的是用户对页面进行缩放时只需要本地渲染就可以，而不需要再次请求后台处理，从而大大提升显示速度，同时降低服务器压力。

具体地，本实施例的电子发票版式文件的处理方法，包括以下步骤：

S1.1当用户在前端页面勾选部分或全部电子发票文件，点击查看或打印功能时，由前端向后台发送合并文件请求。

前端响应于用户对电子发票文件的查看或打印申请，向后台发送合并文件请求。

S1.2后台响应请求，首先将合并文件请求参数中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在这些电子发票文件的合并文件，如果有则直接返回缓存的合并文件，否则继续合并处理。

合并多张电子发票文件的处理过程中要考虑文件的存储格式问题，因为目前支持PDF、OFD两种版式文件存储格式，所以合并前需要考虑先将文件格式统一，使用文件格式转换技术将PDF转成OFD或者将OFD转成PDF。选择何种存储格式主要取决于哪种格式的文件占多数，因为格式转换也是需要时间开销的，因此总时间消耗可以参考如下两个粗算公式：

经过测算和统计，合并后的PDF文件和OFD文件体积大致相同，所以合并后的目标文件选择什么格式只需要考虑上述时间因素而忽略文件大小的差异。最后实施真正的电子发票文件合并工作，合并结果文件保存至缓存并返回前端使用。这里需要前端采用支持PDF、OFD双格式的显示技术以支持电子发票预览和打印功能。

在本实施例的方法中，前端请求的是多个文档；前端同时支持PDF、OFD两种版式格式的预览和打印；后台保存已合并的文档用于多次请求时快速响应；后台使用格式转换技术PDF转OFD或OFD转PDF将合并的文档格式统一；后台使用粗算公式T_{(合并PDF时间)}、T_{(合并OFD时间)}计算合并文档的时间开销；后台返回的对象是一个合并的文档。

如图2所示，本申请的另一个实施例提供了电子发票版式文件的处理方法，包括以下步骤：

S2.1用户在前端页面中勾选了8个OFD电子发票(都是单页的)和2个PDF电子发票(分别有1个详单页)，然后点查看功能，为了方便用户查看。前端发送这10个文件的ID，请求后台将这些文档按顺序合并成一个文件；

S2.2后台接收到前端的合并请求，首先将请求参数中的文件ID字符串连接起来，然后使用SHA256散列算法计算散列值V，并使用V值作为键值检查缓存中是否存在已经合并过的电子发票文件；如果有则直接跳转到2.7，反之开始合并前的分析；

S2.3合并前的分析使用T_{(合并PDF时间)}、T_{(合并OFD时间)}的计算公式计算合并文档的时间开销；

例如，单页OFD转PDF时间记Top等于10毫秒，单页PDF合并时间是15毫秒，那么T_{(合并PDF时间)}公式就是：

如，单页PDF转OFD时间记Top等于10毫秒，单页PDF合并时间是20毫秒，那么T_{(合并OFD时间)}公式就是：

可见先将PDF转成OFD，然后合并OFD文件用时较短，所以分析结论是采用OFD格式。

S2.4调用PDF转OFD模块将2个PDF文件先转成OFD文件；

S2.5将10个OFD文件按顺序合并成1个12页的OFD文件F₁₀；

S2.6将F₁₀保存在缓存中并设置键值为V；

S2.7后台F₁₀文档返回给前端；

S2.8前端接收F₁₀文档用于显示。

本申请提供的方法，在对多个文档的连续显示或打印处理中，前端接收的不是图片而是合并后的版式文件，这大大降低了网络传输的数据量，同时前端对页面的放大操作不需要再次请求后台服务器重新渲染，而是由前端直接解析版式文档格式二次渲染。另外，后台对与多种文档格式的合并处理需要一个预算时间开销的步骤，这也降低了采用固定格式可能带来的额外转换开销。

当前税局开具的最新版OFD电子发票大约15kb左右，因为合并后部分文件结构可以复用，所以10张电子发票大约80kb左右。而10张这样的电子发票按照72dpi，150dpi，300dpi分别渲染成图片的体积是：

10张*8.47英寸*5.47英寸*72dpi*32bpp/8≈130k

10张*8.47英寸*5.47英寸*72dpi*32bpp/8≈275k

10张*8.47英寸*5.47英寸*300dpi*32bpp/8≈550k

可见合并后的文件分别是图片文件的62％，29％，15％，文件体积所带来的压缩优势很明显，同时客户选择放大文件查看或者选择更高分辨率的打印设置都需要请求后台重新渲染图片，这给后台带来的压力是翻倍的。

本申请实施例提供的电子发票版式文件的处理方法，处理后的版式文件体积小，网络传输快，处理速度快，占用CPU资源较少，在由后端传到前端进行预览时占用网络带宽小，可以根据客户操作实现任意比例放大效果而不用多次请求后端生成各种分辨率的图像，可以很好地满足实际需要。

术语“模块”并非意图受限于特定物理形式。取决于具体应用，模块可以实现为硬件、固件、软件和/或其组合。此外，不同的模块可以共享公共组件或甚至由相同组件实现。不同模块之间可以存在或不存在清楚的界限。

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

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

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述实施例仅表达了本申请的实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims

1.一种电子发票版式文件的处理方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述检查缓存中是否存在所述电子发票文件的合并文件，包括：将所述合并文件请求中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在所述电子发票文件的合并文件。

3.根据权利要求1所述的方法，其特征在于，所述检查缓存中是否存在所述电子发票文件的合并文件，包括：首先将所述合并文件请求的请求参数中的文件ID字符串连接起来，然后使用SHA256散列算法计算散列值，并使用散列值作为键值检查缓存中是否存在所述电子发票文件的合并文件。

4.根据权利要求1所述的方法，其特征在于，在所述对所述电子发票文件进行合并处理之前，所述方法还包括：统一所述电子发票文件的格式。

5.根据权利要求4所述的方法，其特征在于，所述统一所述电子发票文件的格式，包括：使用文件格式转换技术将PDF转成OFD或者将OFD转成PDF。

6.根据权利要求4所述的方法，其特征在于，所述统一所述电子发票文件的格式，包括：

7.一种电子发票版式文件的处理装置，其特征在于，包括：

8.根据权利要求7所述的装置，其特征在于，所述第二模块包括检查模块，所述检查模块用于将所述合并文件请求中的文件列表信息生成Hash值，并使用Hash值检查缓存中是否存在所述电子发票文件的合并文件。

9.一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-6中任一所述的电子发票版式文件的处理方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以实现如权利要求1-6中任一所述的电子发票版式文件的处理方法。