本申请涉及电子信息管理技术领域，更具体地，涉及一种询价信息管理方法、服务器和计算机可读存储介质。
背景技术：
随着计算机和互联网技术的迅猛发展，在银行、外汇、债券等金融领域，电子化交易平台得到了飞速的发展，询价交易作为一种成熟的交易模式，被广泛地运用在各大交易平台。询价交易是一种报价驱动的交易模式，交易平台的各交易商向市场提供公开的买卖双向报价，交易对手方(普通会员或其他交易商)据此发起交易请求并最终达成交易。各交易商提供的报价通常是指导性报价(indicative price)，交易发起方通过询价的方式向报价方发出询价请求，进而达成交易。
在现有的询价交易平台中，对于具体产品的业务要素采取不同的交易框架，不便实现平台的复用和业务扩展开发。
技术实现要素：
有鉴于此，本申请公开了一种询价信息管理方法、服务器和计算机可读存储介质，以使得询价交易中不同的询价产品采用统一的框架，实现询价管理系统的复用并且便于业务扩展开发。
第一方面，提供一种询价信息管理方法，包括：
在接收到询价交易请求后，将交易单状态设置为初始状态并检查消息业务字段的合法性；
在确认所述询价交易请求合法后，发送所述询价交易请求并将所述交易单状态更新为提交状态；
在接收到询价交易被接起的反馈消息后，将所述交易单状态由提交状态更新为谈判状态；
在接收到所述询价交易的回价消息并校验确认业务字段合法后，向发起端发送所述回价消息并将所述交易单状态由谈判状态更新为定价状态；
在接收到所述回价被接受的消息后，向对手端发送回价确认信息并将交易单状态由定价状态更新为记录状态；
在接收到所述询价交易的确认消息后，将所述交易单状态由所述记录状态更新为完成状态。
进一步地，所述方法还包括：
在接收到所述询价交易被挂起的反馈消息后，将所述交易单状态由谈判状态更新为挂起状态；
在接收到所述询价交易被重新接起的反馈消息后，将所述交易单状态由挂起状态更新为谈判状态。
进一步地，所述方法还包括：
在接收到所述回价被撤销的消息时，向发起端发送所述回价撤销消息并将所述交易单状态由定价状态更新为谈判状态。
进一步地，所述方法还包括：
在有效时间内未收到所述回价被接受的消息，将所述交易单状态由定价状态更新为谈判状态。
进一步地，所述方法还包括：
在接收到询价交易被行权的消息后，将所述交易单状态由完成状态更新为行权状态；
在接收到询价交易被弃权的消息后，将所述交易单状态由完成状态更新为失效状态。
进一步地，所述方法还包括：
在接收到应急成功删除所述询价交易的消息后，将所述交易单状态由完成状态更新为删除状态。
进一步地，所述方法还包括：
在接收到应急成功插入所述询价交易的消息后，将所述交易单状态由初始状态更新为完成状态。
进一步地，所述方法还包括：
在所述交易单状态处于提交、谈判、挂起或定价时，接收到所述询价交易被取消的消息后，将所述交易单状态更新为取消状态；
在所述交易单状态处于谈判、定价或记录时，接收到所述询价交易被拒绝的消息后，将所述交易单状态更新为拒绝状态；
在有效时间内没有接收到所述询价交易的任何消息时，自动将所述交易单状态更新为撤回状态。
第二方面，提供一种服务器，包括：
至少一个处理器；
存储器，用于存储所述处理器可执行的指令；
所述处理器被配置为执行以上描述的任一项所述的方法。
第三方面，提供一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令在被处理器执行时实现以上描述的任一项所述的方法。
在本申请实施例中，交易单的所有交易状态构成了询价状态机，各交易状态由不同的交易动作连接。询价状态机用于对交易系统中受事件驱动的动态行为进行建模，它由某个询价事件触发，然后执行特定的询价操作并导致特定的询价结束状态。完成了询价产品可统一采用的询价交易框架，实现了涉及的复用，降低了成本并且易于业务扩展。
附图说明
通过以下参照附图对本申请实施例的描述，本申请的上述以及其它目的、特征和优点将更为清楚，在附图中：
图1是本申请实施例的询价特征模型图；
图2是本申请实施例的完成交易的交易单状态图；
图3是本申请实施例的未完成交易的交易单状态图；
图4是本申请实施例的询价信息管理方法的流程图；
图5是本申请实施例的电子设备的示意图。
具体实施方式
以下基于实施例对本申请进行描述，但是本申请并不仅仅限于这些实施例。在下文对本申请的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本申请。为了避免混淆本申请的实质，公知的方法、过程、流程、元件和电路并没有详细叙述。
此外，本领域普通技术人员应当理解，在此提供的附图都是为了说明的目的，并且附图不一定是按比例绘制的。
除非上下文明确要求，否则整个说明书和权利要求书中的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。
在申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。
图1是本申请实施例的询价特征模型图。如图1所示，在询价交易过程中，包含了发起询价、接起询价、挂起询价、取消询价、询价回价、拒绝询价、确认交易、查看交易和应急操作等询价特征。所述询价特征为在询价交易过程中所发生的询价交易动作。其中，所述发起询价、接起询价、询价回价、确认交易和查看交易为必选询价特征。所述挂起询价、拒绝询价为可选询价特征。所述必选询价特征为完成一笔询价交易所必需的询价特征。所述可选询价特征是某些情况下在询价交易中才会出现的询价特征。例如，只有当询价交易中的对手端接起询价交易后又放弃询价回价时才会在此笔交易中出现挂起询价的询价特征。
询价特征是交易单状态转移的条件，当询价交易动作发生后，服务器将交易单状态更新为对应询价交易动作发生后的状态。询价交易中的发起端可以实现发起询价、取消询价、确认交易和查看交易等询价特征。询价交易中的服务器被配置为处理询价交易。所述处理询价交易包括为修改交易单状态、向发起端和对手端发送消息和检验发起端和对手端的请求的合法性等。询价交易中的对手端可以实现接起询价、挂起询价、询价回价、拒绝询价、确认交易和查看交易等询价特征。询价交易中的场务端被配置为权限控制、应急开闭市、业务参数设定、监控交易和交易应急操作等，所述交易应急操作包括应急插入交易和应急删除交易等。所述询价交易中的发起端和对手端是普通会员，场务端是场务会员(也即询价平台管理人员)。
所述发起询价的方式包括普通询价(Request For Quote，RFQ)、多笔询价(Multi-Request For Quote，MRFQ)和竞争询价(Competition-Re quest For Quote，CRFQ)。所述普通询价是指询价交易过程中包含一个发起端和一个对手端，发起端通过询价流程，可以最多完成一笔询价交易。所述多笔询价是指一个发起端可以同时向多个对手端发起交易，发起端可以选择与所有的对手端达成交易。所述竞争询价是指一个发起方端可以同时向多个对手端发起交易，发起端只能选择跟其中一个对手端达成交易。
所述询价回价的方式包括多次回价和单次回价。所述多次回价是指对手端可以在发起端没有接受回价的时候，在交易时间范围内多次修改回价报价的操作。单次回价是指对手端只能回复一次价格给发起端，若发起端不接受此回价，则对手端需要重新接起询价才能再次回价。
在本申请实施例中，采用普通询价和多次回价的方式对询价交易中的状态转移和询价交易流程进行描述。
在询价交易的过程中，询价特征的发生会使得交易单状态发生转移，而交易单所处的状态又影响下一个询价特征的发生。因此，在询价交易过程中，询价特征和交易单状态是相互制约不可分割的。
图2是本申请实施例的完成交易的交易单状态图。如图2所示，一笔询价交易完成的交易单状态包括初始状态21、提交状态22、谈判状态23、挂起状态24、定价状态25、记录状态26、完成状态27、行权状态28、失效状态29和删除状态210。
在发起端向服务器发送询价请求后，服务器设置该笔交易的交易单并将交易单状态设置为初始状态21。所述询价请求包括发起端信息、询价产品和报价等。
在服务器校验所述询价请求的业务字段合法后，服务器将交易单状态由初始状态21更新为提交状态22。
服务器将所述询价请求推送给所有在线的对手端。当对手端接起询价交易后发送反馈消息给服务器，服务器将所述交易单状态由提交状态22更新为谈判状态23。
当对手端接起询价交易后，若服务器接收到所述询价交易被挂起的反馈消息，则将交易单状态由谈判状态23更新为挂起状态24。若服务器接收到对手端的回价信息并校验所述回价信息的业务字段无误后，将交易单状态由谈判状态23更新为定价状态25。
当交易单状态为挂起状态24时，其他对手端可以重新接起所述询价交易。当服务器接收到所述询价交易被重新接起的反馈消息后，将交易单状态由挂起状态24更新为谈判状态23。
当发起端接收到所述回价信息后，若发起端在有效时间内未向服务器反馈消息或向服务器反馈不接受所述回价的消息，则服务器将交易单状态由定价状态25更新为谈判状态23。若发起端向服务器发送接受回价并确认交易的消息，则服务器将交易单状态由定价状态25更新为记录状态26。
当服务器将发起端接受回价并确认交易的消息发送给对手端后，对手端自动将确认交易的消息发送给服务器。服务器将交易单状态由记录状态26更新为完成状态27。
如果交易为可以行权弃权的询价交易，若发起端和对手端执行了行权操作，服务器将交易单状态由完成状态27更新为行权状态28。若发起端和对手端执行了弃权操作，服务器将交易单状态由完成状态27更新为失效状态29。行权交易是指发起端和对手端已经达成在未来的某一日以约定好的价格进行交易。若按照约定执行了交易表示进行了行权操作。若取消了交易表示进行了弃权操作。
另外，当发起端和对手端已经通过其他方式(如电话、邮件等)达成了交易协商，发起端和对手端提供完成的材料给场务端，场务端对所提交材料进行校验无误后向服务器发送确认交易消息执行应急插入交易操作。服务器将交易单状态由初始状态21更新为完成状态27。所述材料包括交易发起端和对手端的信息、询价产品、交易价格等。
当已经达成交易的发起端和对手端不执行此项交易时，可以向场务端申请应急删除交易，场务端审查申请信息无误后执行应急删除交易操作并向服务器发送删除交易的信息。服务器将交易单状态由完成状态27更新为删除状态210。
当询价交易过程中，发起端和对手端的任一方放弃该笔交易，则该笔交易为未完成交易。
图3是本申请实施例的未完成交易的状态图。如图3所示，一笔询价交易未完成的交易单状态包括取消状态31、拒绝状态32和撤回状态33。
当交易单状态处于提交、谈判、挂起或定价状态时，发起端可以向服务器发送取消询价交易的消息以取消该项询价交易。服务器将交易单状态更新为取消状态31。
当交易单状态处于谈判、挂起、定价或记录状态时，对手端可以向服务器发送拒绝询价交易的消息以拒绝该项询价交易。服务器将交易单状态更新为拒绝状态32。
当交易单状态处于提交、谈判、挂起、定价或记录状态时，在有效时间内，若发起端和对手端对该项询价交易未做出任何回应和操作，则服务器自动将交易单状态更新为撤回状态33。
在本实施例中，交易单的所有交易状态构成了询价状态机，各交易状态由不同的交易动作连接。询价状态机用于对交易系统中受事件驱动的动态行为进行建模，它由某个询价事件触发，然后执行特定的询价操作并导致特定的询价结束状态。完成了询价产品可统一采用的询价交易框架，实现了涉及的复用，降低了成本并且易于业务扩展。
图4是本申请实施例的询价信息管理方法的流程图。如图4所示，在步骤S110，服务器接收到发起端发起询价交易的消息后。服务器对询价交易信息进行业务字段校验，确认无误后将交易单状态由初始状态更新为提交状态。所述询价交易信息包括发起端信息、询价产品和报价等。
在步骤S120，服务器将所述询价交易信息发送给所有的在线用户。
在步骤S130，服务器接收到所述询价交易被对手端接起的反馈消息后，将交易单状态由提交状态更新为谈判状态。
在步骤S140，服务器接收到对手端的回价信息后，服务器对回价信息进行业务字段校验，确认无误后服务器将交易单状态由谈判状态更新为定价状态。
在步骤S150，服务器向发起端发送回价信息。
在步骤S160，服务器接收到所述回价被发起端接受并确认交易的反馈信息后，将交易状态由定价状态更新为记录状态。
在步骤S170，服务器将发起端确认交易的信息发送给对手端。
在步骤S180，服务器接收到对手端确认交易的信息后，将交易单状态更新为完成状态。发起端和对手端达成交易。
在实施例的其他实施方式中，当对手端接起询价后挂起询价，服务器将交易单状态由谈判状态更新为挂起状态。若其他对手端重新接起所述询价交易，服务器将交易单状态由挂起状态更新为谈判状态。重复步骤S140-S180完成交易。
当发起端不接受对手端的回价时，在采用多次回价模式中，对手端可以重新发送回价。重复步骤S150-S180完成交易。
当发起端和对手端以其他方式(如电话、邮件、面谈等)达成了交易，可以向场务端发送完整的交易资料以申请应急插入交易。所述交易资料包括发起端和对手端的信息、询价产品和交易价格等。场务端确认交易资料无误后执行应急插入交易的操作并发送插入交易的信息给服务器，服务器设置交易单并将交易单状态由初始状态更新为完成状态。
当发起端和对手端达成交易后不准备执行此交易，向场务端发送删除该笔交易的请求。场务端审查确认无误后，执行应急删除交易的操作删除该笔交易并发送删除交易信息给服务器，服务器将交易单状态由完成状态更新为删除状态。
另外对于可以行权弃权的询价交易，发起端和对手端在约定日执行了行权操作并发送行权信息给服务器，服务器将交易单状态由完成状态更新为行权状态。发起端和对手端在约定日之前执行了弃权操作并发送弃权信息给服务器，服务器将交易单状态由完成状态更新为失效状态。
在本申请实施例中，交易单的所有交易状态构成了询价状态机，各交易状态由不同的交易动作连接。询价状态机用于对交易系统中受事件驱动的动态行为进行建模，它由某个询价事件触发，然后执行特定的询价操作并导致特定的询价结束状态。完成了询价产品可统一采用的询价交易框架，实现了涉及的复用，降低了成本并且易于业务扩展。
图5是本申请实施例的电子设备的示意图。图5所示的电子设备为通用数据处理装置，其包括通用的计算机硬件结构，其至少包括处理器51和存储器52。处理器51和存储器52通过总线53连接。存储器52适于存储处理器51可执行的指令或程序。处理器51可以是独立的微处理器，也可以是一个或者多个微处理器集合。由此，处理器51通过执行存储器52所存储的指令，从而执行如上所述的本申请实施例的方法流程实现对于数据的处理和对于其它装置的控制。总线53将上述多个组件连接在一起，同时将上述组件连接到显示控制器54和显示装置以及输入/输出(I/O)装置55。输入/输出(I/O)装置55可以是鼠标、键盘、调制解调器、网络接口、触控输入装置、体感输入装置、打印机以及本领域公知的其他装置。典型地，输入/输出装置55通过输入/输出(I/O)控制器56与系统相连。
本领域的技术人员应明白，本申请的实施例可提供为方法、或计算机程序产品。本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品。
本申请是参照根据本申请实施例的方法、和计算机程序产品的流程图来描述的。应理解可由计算机程序指令实现流程图中的每一流程。
这些计算机程序指令可以存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现流程图一个流程或多个流程中指定的功能。
以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域技术人员而言，本申请可以有各种改动和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。