一种航运业务结算方法、平台、设备、介质及产品

摘要

本申请提供了一种航运业务结算方法，该方法应用于航运业务结算平台，该平台还包括通过该平台进行航运业务交易的平台用户双方的虚拟账户，虚拟账户与平台用户的银行账户相关联，该平台根据账单文件获取账单金额、账单类型、收款方用户、付款方用户，根据付款方用户在多个账单中确定的支付账单金额，从付款方用户的虚拟账户中扣除对应金额进行支付，该平台根据账单对金额进行分账，将对应金额分账至收款方用户的虚拟账户中，并同时发送账单类型及付款方用户，使收款方用户对支付账单进行核销，然后根据收款方用户对于提现账单的选择，将虚拟账户中对应的金额提现到银行账户中，实现用户双方通过该平台进行的业务交易。

说明书

技术领域

本申请涉及计算机技术领域，尤其涉及一种航运业务结算方法、平台、设备、计算机可读存储介质以及计算机程序产品。

背景技术

在民航货运中，货运销售代理人(以下简称货运代理人)和航空公司之间需要进行频繁的业务资金结算。

通常情况下，货运代理人和航空公司之间的资金结算包括两种模式，一种是通过特定的资金结算系统，但是这种系统通常采用“中心化”的结算模式，收付款双方用户需要依托该系统进行交易，而这种交易模式下，收付款双方必须通过固定的周期进行结算，灵活性较差，并且只能结算与运单有关的销售款账单，结算类型单一；另一种是通过银行转账，但是需要记忆不同航空公司分别对应的银行账号，并且转账资金不会自动与账单关联，需要大量的人力去对账核销。

因此，业界亟需一种能够满足航运业务需求的航运业务结算的方法。

发明内容

本申请提供了一种航运业务结算方法，该方法能够通过航运业务结算平台能够使航运业务交易的双方均通过该平台进行“去中心化”的业务交易，并且能够将账单的基础信息与金额对应，减少了人工成本核销的成本，提高了航运业务结算的效率。本申请还提供了上述方法对应的平台、设备、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种航运业务结算方法，该方法应用于航运业务结算平台，航运业务结算平台包括平台用户的虚拟账户，平台用户的虚拟账户与平台用户的银行账户相关联，该方法包括：

航运业务结算平台根据账单文件获取账单金额、账单类型、收款方用户、付款方用户，收款方用户与付款方用户为航运业务结算平台用户，收款方用户为航空公司或货运代理人中的一方，付款方用户为航空公司或货运代理人中的另一方；

航运业务结算平台根据付款方用户在多个账单中的选择，确定支付账单，并按照账单金额，从付款方用户的虚拟账户中支付支付账单对应的金额总和，付款方用户的虚拟账户中的金额由付款方用户通过付款方用户的银行账户充值获得；

航运业务结算平台将金额总和按照支付账单的收款方用户，分账至收款方用户的虚拟账户，并将支付账单的账单类型和付款方用户发送至收款方用户，使收款方用户对支付账单进行核销；

航运业务结算平台根据收款方用户对于提现账单的选择，从收款方用户的虚拟账户向收款方用户的银行账户中提现对应金额。

在一些可能的实现方式中，该方法还包括：

航运业务结算平台接收账单文件，对账单文件进行识别，获取账单文件对应的账单金额、账单类型、收款方用户、付款方用户，并将账单文件存储至系统中，使用户通过账单金额、账单类型、收款方用户、付款方用户获取账单文件。

在一些可能的实现方式中，航运业务结算平台根据账单文件获取账单金额，包括：

航运业务结算平台根据账单文件，通过电子表格格式导入，获取账单金额。

在一些可能的实现方式中，航运业务结算平台根据账单文件获取账单金额，包括：

航运业务结算平台根据账单文件，通过金额识别模型，获取账单金额，金额识别模型通过机器学习获得，金额识别模型的训练数据包括从多种类型的账单中所提取的账单金额的特征向量。

在一些可能的实现方式中，账单类型包括销售款账单、押金账单、预付款账单、违约金账单以及贷项账单中的至少一种。

在一些可能的实现方式中，平台用户的银行账户为不同银行的银行账户。

第二方面，本申请提供了一种航运业务结算平台，该平台包括：

平台用户的虚拟账户，平台用户的虚拟账户与平台用户的银行账户相关联；

获取模块，用于根据账单文件获取账单金额、账单类型、收款方用户、付款方用户，收款方用户与付款方用户为航运业务结算平台用户，收款方用户为航空公司或货运代理人中的一方，付款方用户为航空公司或货运代理人中的另一方；

支付模块，用于根据付款方用户在多个账单中的选择，确定支付账单，并按照账单金额，从付款方用户的虚拟账户中支付支付账单对应的金额总和，付款方用户的虚拟账户中的金额由付款方用户通过付款方用户的银行账户充值获得；

分账模块，用于将金额总和按照支付账单的收款方用户，分账至收款方用户的虚拟账户，并将支付账单的账单类型和付款方用户发送至收款方用户，使收款方用户对支付账单进行核销；

提现模块，用于根据收款方用户对于提现账单的选择，从收款方用户的虚拟账户向收款方用户的银行账户中提现对应金额。

在一些可能的实现方式中，该平台还包括：

识别模块，用于接收账单文件，对账单文件进行识别，获取账单文件对应的账单金额、账单类型、收款方用户、付款方用户，并将账单文件存储至系统中，使用户通过账单金额、账单类型、收款方用户、付款方用户获取账单文件。

在一些可能的实现方式中，识别模块具体用于：

根据账单文件，通过电子表格格式导入，获取账单金额。

在一些可能的实现方式中，识别模块具体用于：

根据账单文件，通过金额识别模型，获取账单金额，金额识别模型通过机器学习获得，金额识别模型的训练数据包括从多种类型的账单中所提取的账单金额的特征向量。

在一些可能的实现方式中，账单类型包括销售款账单、押金账单、预付款账单、违约金账单以及贷项账单中的至少一种。

在一些可能的实现方式中，平台用户的银行账户为不同银行的银行账户。

第三方面，本申请提供一种设备，设备包括处理器和存储器。处理器、存储器进行相互的通信。处理器用于执行存储器中存储的指令，以使得设备执行如第一方面或第一方面的任一种实现方式中的航运业务结算方法。

第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，指令指示设备执行上述第一方面或第一方面的任一种实现方式所述的航运业务结算方法。

第五方面，本申请提供了一种包含指令的计算机程序产品，当其在设备上运行时，使得设备执行上述第一方面或第一方面的任一种实现方式所述的航运业务结算方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例提供了一种航运业务结算方法，该方法应用于航运业务结算平台，该平台还包括通过该平台进行航运业务交易的平台用户双方的虚拟账户，虚拟账户与平台用户的银行账户相关联，该平台根据账单文件获取账单金额、账单类型、收款方用户、付款方用户，根据付款方用户在多个账单中确定的支付账单金额，从付款方用户的虚拟账户中扣除对应金额进行支付，其中虚拟账户中的金额由银行账户充值获得，该平台根据账单对金额进行分账，将对应金额分账至收款方用户的虚拟账户中，并同时发送账单类型及付款方用户，使收款方用户对支付账单进行核销，然后根据收款方用户对于提现账单的选择，将虚拟账户中对应的金额提现到银行账户中，实现用户双方通过该平台进行的业务交易。由此，能够减少系统对于交易过程的干预，提高了交易的自由度，并且能够使收款方用户在获得交易金额的同时获得账单类型等信息，便于核销，减少了人工成本。

附图说明

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

图1为本申请实施例提供的一种航运业务结算平台的架构示意图；

图2为本申请实施例提供的一种航运业务结算方法的流程示意图；

图3为本申请实施例提供的一种航运业务结算方法中账单文件获取的示意图；

图4为本申请实施例提供的一种航运业务结算方法中账单支付的流程示意图；

图5为本申请实施例提供的一种航运业务结算方法中账单提现的流程示意图；

图6为本申请实施例提供的一种航运业务结算方法中交易的流程示意图；

图7为本申请实施例提供的一种航运业务结算平台的架构示意图。

具体实施方式

下面将结合本申请中的附图，对本申请提供的实施例中的方案进行描述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。

为了便于理解本申请的技术方案，下面对本申请涉及的一些技术术语进行介绍。

在民航货运业，货运代理人向航空公司支付销售款通常具有三种渠道：一种是通过国际航空运输协会(international air transport association，IATA)建立的货运账户结算系统(cargo account settlement system，CASS)；另一种是通过中国航空运输协会参照IATA CASS模式开发的另一套资金结算系统，目前由凯塔公司运营(下文将该系统称为凯塔)；还有一种是通过银行转账。

其中，CASS和凯塔都是“中心化”的资金结算模式，即CASS或凯塔指定银行，货运代理人和航空公司分别在该银行开具账户，然后按照CASS或凯塔制定的“结算日历”，定期通过指定银行从对应的货运代理人账户中扣款，并将销售款划拨给航空公司。在这种模式下，货运代理人需要向CASS或凯塔预先缴纳高额的保证金，并且货运代理人与航空公司必须按照CASS或凯塔指定的时间进行结算，灵活度较差，并且只能结算与货运单相关的销售款，类型单一。并且，IATA CASS需要账单格式为标准格式，从而能直接生成数据文件，一旦账单格式有误则无法进行后续步骤。然而中国民航货运企业技术水平参差不齐，很多中小型航空公司、货运代理人没有结算系统，很多账单为电子表格格式(excel)。

而直接通过银行账户转账，需要货运代理人记忆不同航空公司分别的银行账户，并且记忆每家航空公司每笔交易对应的账期，如果产生疏漏可能导致账单逾期，或者出现多付、少付等错付的情况。并且，通过银行直接进行转账，资金不能与账单自动关联，由此需要收款方与付款方花费大量的人力去核对应付账款、应收账款，进行对账核销。

有鉴于此，本申请提供了一种航运业务结算方法。该方法应用于航运业务结算平台，如图1所示，该平台包括平台用户的虚拟账户，平台用户的虚拟账户与平台用户的银行账户相关联。其中，航运业务结算平台可以为软件，该软件可以集中或者分布式地部署在计算机集群中。该航运业务结算平台也可以是硬件，该硬件用于使航运业务交易双方进行交易。

具体地，该平台根据账单文件获取账单金额、账单类型、收款方用户、付款方用户等信息，根据付款方用户确定的支付账单，按照账单金额从付款方用户的虚拟账户中扣除对应金额总和，将金额总和按照收款方根据收款方用户分账至收款方用户的虚拟账户中，并将对应账单信息发送至收款方用户，然后根据收款方用户对于提现账单的选择，将对应金额从虚拟账户中提现至银行账户中。如此，提供一种“去中心化”的交易模式，提高了交易的自由度，并且平台可以自动提供付款明细，以便收付款双方进行核销结算。

接下来，将结合附图对本申请实施例提供的航运业务结算方法进行介绍。

参见图2所示的航运业务结算方法的流程图，该方法包括如下步骤：

S202：航运业务结算平台根据账单文件获取账单金额、账单类型、收款方用户、付款方用户。

其中，收款方用户与付款方用户为该航运业务结算平台用户，收款方用户为航空公司或货运代理人中的一方，付款方用户为航空公司或货运代理人中的另一方。

账单类型可以包括销售款账单、押金账单、预付款账单、违约金账单以及贷项账单，在本实施例中，交易双方可以进行多种交易，该平台对此不做限制。

航运业务结算平台接收账单文件，对账单文件进行识别，获取账单文件对应的账单金额、账单类型、收款方用户、付款方用户，并将账单文件存储至系统中，使用户能够通过账单金额、账单类型、收款方用户、付款方用户获取账单文件。

具体地，该平台可以采用开源流处理平台(例如kafka)作为消息中间件与分布式文件系统(例如Hadoop分布式文件系统(Hadoop distributed file system，HDFS))作为文件服务器进行存储相结合的方式实现对于账单文件的传递，如图3所示。

kafka中的数据能够持久化到本地磁盘中，并且kafka可以配置多集群服务，支持数据备份，断点续传，防止数据丢失，如果一个节点宕机其他节点还能继续工作，保障数据正常传输。

航空公司的货运收入结算系统生成账单后，将账单文件传到HDFS文件服务器上，同时将文件在HDFS上的存储地址以及提取的账单信息通过Kafka传递给平台，其中账单文件通常为excel或便携式文档格式(portable document format，PDF)，账单信息可以为账单金额、账单类型、收款方用户、付款方用户。

货运收入结算系统按照约定的主题和约定的账单表头格式将消息发送到kafka中，航运业务结算平台通过kafka接收账单信息和存储地址。

平台用户想要查看账单文件时，平台通过账单文件存储地址在HDFS上获取原始账单文件返回给用户。

由于航空公司账单包含重要的商务和财务数据，是交易双方进行付款的唯一依据，因此必须保证账单的及时性、完整性、以及能够准确传递。而这种将原始文件保存在HDFS中的处理，使平台不需要将账单原始文件下载到本地存储，能够避免同一份账单文件在不同系统中存储多份，保证了数据一致性，并且减少了服务器运行压力。

并且，kafka的高吞吐、低延迟、可持久性、容错性和高并发等特点非常适合销售账单的传递。

在实际中，平台要接收多家航空公司多个货运收入结算系统的账单数据，且账单生成时间相对集中，同时有几千条账单数据需要通过平台传递。kafka每秒钟可以处理几十万条消息，延迟只有几毫秒。即便多个系统同时向平台推送大量消息也不会导致消息丢失，不会因为高并发造成的冲突导致消息丢失。

并且，各航空公司销售账单的格式不一定相同，即便同一航空公司的不同类型的账单格式也不同，各航空公司使用的货运收入结算系统可能来自不同的系统供应商，系统架构各有不同，因此使用kafka结合HDFS的方式可以提高平台接口的兼容性。

以上对于该平台如何获取账单文件进行了介绍，下面对通过账单文件识别获得账单文件对应的账单金额、账单类型、收款方用户、付款方用户等信息进行介绍，以账单金额为例。

在本实施例中，账单不仅包括与运单有关的销售款账单，还可以包括任何具有款项收付属性的账单，例如：押金、预付款、违约金等，也可以包括贷项账单。

在一些可能的实现方式中，用户也可以手动上传账单。

当平台用户手动上传excel账单时，平台自动识别excel文件中的总金额，具体地，在excel中寻找带有标记的行，然后在这些行里寻找带有总金额标记的列，定位excel栏后读取该栏数值，将所有数值金额加总等到一份excel生成总金额。

在一些可能的实现方式中，一个账单可能具有多个账单文件，则对excel的总金额再次加总，得到最终账单总金额。

对于其他格式的账单，平台可以通过图像识别技术，对带有金额标记的文字和区域内的数字进行提取，获取账单金额。在一些可能的实现方式中，通过图像识别技术识别的金额均需要人工确认。确认后的金额和对应的识别方式、识别特征可以被系统记录在平台用户名下，在下次识别时优先调用。

在一些可能的实现方式中，通过机器学习，为每个平台客户建立账单识别模式，可以提高识别正确率。

例如，可以使用了easypoi读取excel数据。poi是专门用于给Java程序提供格式文档读写功能的应用程序接口(application programming interface，API)，包括多种微软的格式文档(如excel、word等)。Easypoi是在poi接口基础上进行了封装，能够简化操作。easypoi能够实现基于注解的导入导出，仅修改注解就可以修改excel。

由于需要获取账单总金额数据，而excel账单格式不同，文件内记录数多且条数不定，因此可以在代码写法上进行简化，从而减少硬代码的编写。因此，可以采用pojo及注解的形式将需要读取的数据组织成一个实体类，通过使用@Excel这一最基本的注解，注解在模型字段上，由此可以添加列名、列的排序、列宽、格式等属性，能够有针对性地读取excel中某列的单元格而无需读取全部单元格，提高读取效率。

并且，easypoi-web耦合了spring-mvc基于AbstractView，能够简化spring-mvc下的导出功能。同时采用“easypoi-annotation”基础注解包与easypoi父包相分离，方便maven多工程的依赖管理。

对于pdf或图片格式的账单，可以采用图像识别和机器学习进行账单金额的识别。由于账单类型不同，开账方不同，账单总金额的位置也会不同，因此需要对模型进行训练。

可选地，收集多份不同开账方不同类型的账单，基于账单总金额位置的进项分类，然后提取账单金额的特征向量，如“总”“金”、“额”、“T”、“o”、“t”、“a”、“l”和数字的特征，将获取的特征向量存入数据区。这个数据区包含了从训练用账单中提取出的‘账单总金额’的所有特征向量，而任何含有该数据区的某个特征向量都将被视为账单总金额。将收集到的账单图片重命名，把正确的账单总金额写到文件名中，方便机器识别出的账单金额和正确的账单金额进行比对。识别出包含“总金额”或“Total”区域，将其后的数字做为账单总金额和文件名做比较，如果是一致则标记true(正确)，如果不一致则标记false(错误)。如果无法获取金额则按false处理。

训练模型使模型具有一定的准确率，例如如果模型无法达到60％的识别正确率，调整模型或增加训练用的账单数量，直到正确率达到并超过60％，可以将模型保存到服务器中。

在一些可能的实现方式中，可以要求用户上传的账单文件为图片格式。可以根据文件的后缀名判断文件格式，进一步判断是否具有“账单”图片的特征，如：有文字、数字、英文、签章图形等，如果不符合账单特征，则提示用户上传正确的账单图片。

当确定为账单图片时，则提取该图片的“账单总金额”的特征向量，并比较图片的特征向量和数据区中的特征向量是否匹配，如果找到匹配的特征向量则表示在该文件中识别出了账单金额，将识别出的账单金额显示在系统界面上供用户确认。

如果用户对系统识别出的账单金额直接确认，则标记为“true”；如果用户修改了该值，且与系统识别的金额不同，则标记为“false”。

S204：航运业务结算平台根据付款方用户在多个账单中进行的选择，确定支付账单，并按照账单金额，从付款方用户的虚拟账户中支付对应的金额总和。

其中，平台用户可以通过第三方支付工具进行支付交易。具体地，平台用户在该支付工具上开设的虚拟账户对应的银行账户可以为不同银行旗下的账户。平台用户的虚拟账户中的金额可以为通过该平台用户的银行账户充值获得的，也可以为该平台用户收到其他用户所支付的账单金额。一个平台用户具有一个虚拟账户，但是该虚拟账户可以绑定多个银行账户。

具体地，付款方用户可以通过合并付款功能，勾选多个账单作为支付账单，其中多个账单中可以包括多个收款方以及多种账单类型，进行付款。

航运业务结算平台根据付款方对于支付账单的选择，从付款方用户的虚拟账户中扣除对应的金额总和。

在一些可能的实现方式中，在付款方用户选择账单过程中，平台不限制账单数量、账单类型、账单的收款方，而只检查这些账单是否为可支付状态，对于已支付或其他用户正在支付的账单则提示不可支付，设置为不可选择状态。平台用户通过点击“确认支付”按钮将这些账单锁定。平台对所选的支付账单的金额进行加总，通过跳转到第三方支付工具的收银台页面使平台用户选择对应的银行账号进行支付。可选地，可以通过银行账户将金额充值到对应的虚拟账户中，待充值完成后第三方支付工具返回平台接口，告知充值成功，平台通知第三方支付工具对付款方虚拟账户金额进行扣款。通过人工点击确认按钮进行支付，后续的支付过程由平台和第三方支付工具之间完成，不再需要人工参与。

在本实施例中，付款方对于账单的选择可以通过和收款方协商确定，付款的时间、金额、账单类型均可以由交易双方自由确定，减少了平台对于交易的控制，实现“去中心化”。

S206：航运业务结算平台将金额总和按照支付账单的收款方用户，分账至收款方用户的虚拟账户，并将支付账单的账单类型和付款方用户发送至收款方用户，使收款方用户对所述支付账单进行核销。

具体地，当付款方用户付款完成后，平台根据账单的收款方对金额总和进行分账，将分账金额计入收款方分别对应的虚拟账户中，将账单标记为已支付状态。并且，将支付账单的账单类型和付款方用户发送至收款方用户，使收款方用户对所述支付账单进行核销。

具体支付流程如图4所示，其中，以货运代理人(货代)为付款方，德付通为第三方支付工具为例。

S208：航运业务结算平台根据收款方用户对于提现账单的选择，从收款方用户的虚拟账户向收款方用户的银行账户中提现对应金额。

可选地，收款方用户可以添加实体银行账户作为提现账户，并进行该虚拟账户与实体银行账户之间的关联。进一步地，收款方用户可以为不同的提现账户设置提现账户的入账条件，根据入账条件匹配该收款方用户应收账单中符合条件的已付款未提现账单，将其金额与提现账户相关联，如此可以实现自动将同一用户的账单提现至对应的提现账户中。

收款方用户可以自主选择所要提现的账单，平台检查对应的账单能否提现，如果可以则冻结该账单，防止重复提现。平台向第三方支付工具发出提现指令，第三方支付工具与对应的提现账户的开户银行系统进行连接，并向平台返回结果状态，结果状态包括处理中、成功或失败。如果提现成功，平台将账单标记为已提现，如果提现失败，则解冻账单，并给出错误提示。具体提现过程如图5所示，其中以航空公司(航司)为收款方为例。

如此，航运业务的交易双方能够通过该平台进行“去中心化”的交易，如图6所示，其中以货运代理人为付款方，航空公司为收款方为例。

基于上述内容描述，本申请实施例提供了一种航运业务结算方法，应用于航运业务结算平台，该平台包括平台用户的虚拟账户，平台用户的虚拟账户与平台用户的银行账户相关联，该平台用户为航空公司或货运代理人，该平台根据账单文件获取账单金额、账单类型、收款方用户、付款方用户，根据付款方用户在多个账单中的选择，确定支付账单，并按照账单金额，从付款方用户的虚拟账户中支付对应的金额总和，其中，付款方用户的虚拟账户中的金额由付款方用户通过付款方用户的银行账户充值获得，将金额总和按照支付账单的收款方用户，分账至收款方用户的虚拟账户，并将支付账单的账单类型和付款方用户发送至收款方用户，使收款方用户对支付账单进行核销，根据收款方用户对于提现账单的选择，从收款方用户的虚拟账户向收款方用户的银行账户中提现对应金额。

如此，能够实现航运业务“去中心化”交易，交易的类型、时间、金额均可以由交易双方决定，而不受平台限制，并且交易双方也无需在特定的银行开卡，减少了流程。

并且，付款方可以合并不同收款方、不同的账单类型进行付款，收款方也可以自主决定对哪些账单进行提现，增加了交易的自由度。同时，收款方无需人工比对收到的款项与账单，该平台能够自动提供，减少了人工核销的工作量。

以上结合图2对本申请实施例提供的航运业务结算方法进行了详细介绍，接下来，将结合附图对本申请实施例提供的航运业务结算平台进行介绍。

参见图7所示的航运业务结算平台的结构示意图，该平台700包括：平台用户的虚拟账户、获取模块702、支付模块704、分账模块706、提现模块708。

平台用户的虚拟账户，平台用户的虚拟账户与平台用户的银行账户相关联；

获取模块702，用于根据账单文件获取账单金额、账单类型、收款方用户、付款方用户，收款方用户与付款方用户为航运业务结算平台用户，收款方用户为航空公司或货运代理人中的一方，付款方用户为航空公司或货运代理人中的另一方；

支付模块704，用于根据付款方用户在多个账单中的选择，确定支付账单，并按照账单金额，从付款方用户的虚拟账户中支付支付账单对应的金额总和，付款方用户的虚拟账户中的金额由付款方用户通过付款方用户的银行账户充值获得；

分账模块706，用于将金额总和按照支付账单的收款方用户，分账至收款方用户的虚拟账户，并将支付账单的账单类型和付款方用户发送至收款方用户，使收款方用户对支付账单进行核销；

提现模块708，用于根据收款方用户对于提现账单的选择，从收款方用户的虚拟账户向收款方用户的银行账户中提现对应金额。

在一些可能的实现方式中，该平台还包括：

识别模块，用于接收账单文件，对账单文件进行识别，获取账单文件对应的账单金额、账单类型、收款方用户、付款方用户，并将账单文件存储至系统中，使用户通过账单金额、账单类型、收款方用户、付款方用户获取账单文件。

在一些可能的实现方式中，识别模块具体用于：

根据账单文件，通过电子表格格式导入，获取账单金额。

在一些可能的实现方式中，识别模块具体用于：

根据账单文件，通过金额识别模型，获取账单金额，金额识别模型通过机器学习获得，金额识别模型的训练数据包括从多种类型的账单中所提取的账单金额的特征向量。

在一些可能的实现方式中，账单类型包括销售款账单、押金账单、预付款账单、违约金账单以及贷项账单中的至少一种。

在一些可能的实现方式中，平台用户的银行账户为不同银行的银行账户。

根据本申请实施例航运业务结算平台700可对应于执行本申请实施例中描述的方法，并且航运业务结算平台700的各个模块的上述和其它操作和/或功能分别为了实现图2中的各个方法的相应流程，为了简洁，在此不再赘述。

本申请提供一种设备，用于实现航运业务结算方法。所述设备包括处理器和存储器。所述处理器、所述存储器进行相互的通信。所述处理器用于执行所述存储器中存储的指令，以使得设备执行航运业务结算方法。

本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在设备上运行时，使得设备执行上述航运业务结算方法。

本申请提供了一种包含指令的计算机程序产品，当其在设备上运行时，使得设备执行上述航运业务结算方法。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。