本发明涉及一种混凝土行业交易过程中信息管理技术领域，特别是涉及一种混凝土订单的数据管理方法。
背景技术：
订单服务系统做为一种交易信息管理，具有开放性，准确性，高维度，高可用，易扩展等特点，在整过交易过程中，记录了产品信息，买卖双方及其他详细信息，实现了交易中的双方确认，在数据和逻辑层面实现了数据的统一。为后续的结算和支付提供了有利的数据支撑。
订单服务系统是解决工业产业实现互联网+的一个层面的缩影，实现了b2p2c的新商务逻辑，更是大数据时代不可割裂的一部分，但在当前环境中，对于安全问题已经是不可避免的难题。在订单服务系统中，报文是信息的载体，服务具有开放性，因此报文信息很容易被攻击，如监听攻击、拦截和篡改等。
技术实现要素：
针对上述问题中存在的不足之处，本发明提供一种混凝土订单的数据管理方法，使其完善记录交易订单的数据，实现买卖双方的数据确认和统一，以及实现数据流的闭环。
为了解决上述问题，本发明提供一种混凝土订单的数据管理方法，其中，包括以下步骤：
s10、选择自方已经在建并录入系统中的需要混凝土的项目；
s20、获取已经发布混凝土产品的商混企业做为供应商；
s30、填写订单信息，包括需要混凝土的具体属性、强度等级、施工工艺、早强要求等13种混凝土属性；
s40、供应商即对应商混企业对订单进行确认。
优选的，在所述步骤s10中，用户登录后，在会话控制(session)中获取固定id，在项目表(ht_project)中通过用户id(userid)的匹配过滤查询出多个项目的集合，显示在前台。勾选后，在表单中记录项目id(projectid)。
优选的，在所述步骤s20中，通过供应商表(ht_supplier)中比对客户(customer)和用户id(userid)获取供应商(supplier)的集合，根据集合和发布过混凝土产品的用户的比对筛选出满足需求的供应商，在通过用户匹配查询对应全部企业的集合。
优选的，在所述步骤s30中，还包括以下步骤：
s301、填写浇注时间，计划浇筑量等8个订单信息，其中属性的集合通过接口获取，包含控件的输入类型，输入长度，是否为空，输入规范等，在前台通过js脚本生成html，对用户是否输入及输入的格式进行判断和提示；
s302、待用户完全填写后，将产品信息和订单信息转成json数据格式，保存在订单信息(orderinfo)和属性数组(optionsarray)中，并且在代码中将json转为新的集合保存在订单信息结果表(ht_order_info_result)中，这样即保留了根据属性统计订单的可能，又保证了查询的多入口多方式的可能。
优选的，在所述步骤s40中，根据用户和用户选择的订单号(orderno)就只能查询出唯一条订单，随即更改订单状态，即时写入订单状态记录表(ht_order_status_record)状态更改记录中。
与现有技术相比，本发明具有以下优点：
本发明依据线下实际交易流程，整合互联网优势，使工业产品互联网化交易得以实现，直戳线下交易中买卖双方的痛点，为友好，公平解决切实问题提供了有效，有力的数据支持，完整的数据是交易公平，公正，公开的体现，是建立完善的买卖双方信用体系的基础，更是加速实现工业行 业互联网+的一个具体实现的范例，对其他行业加速实现互联网化提供了更多可以借鉴的经验。
附图说明
图1是本发明的实施例流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，下面结合附图与实例对本发明作进一步详细说明，但所举实例不作为对本发明的限定。
如图1所示，本发明的实施例包括一下步骤：
s10、选择自方已经在建并录入系统中的项目即需要混凝土的项目。用户登录后，在会话控制(session)中获取固定id，在项目表(ht_project)中通过用户id(userid)的匹配过滤查询出多个项目的集合，显示在前台，勾选后，在表单中记录项目id(projectid)。
s20、获取已经发布混凝土产品的商混企业做为供应商。通过供应商和客户中间表(ht_supplier)中比对客户(customer)和用户id(userid)获取供应商(supplier)的集合，根据集合和发布过混凝土产品的用户的比对筛选出满足需求的供应商，在通过用户匹配查询对应全部企业的集合。
s30、填写订单信息，其中包含需要混凝土的具体属性，包括强度等级，施工工艺，早强要求等13种混凝土属性。
s301、填写浇注时间，计划浇筑量等8个订单信息，其中属性的集合通过接口获取，实际上是一个空白的属性框架，其中包含控件的输入类型，输入长度，是否为空，输入规范等，在前台通过js脚本生成html，对用户是否输入及输入的格式进行判断和提示。
s302、待用户完全填写后，将产品信息和订单信息转成json数据格式，保存在订单信息(orderinfo)和属性数组(optionsarray)中，并且在代码中将json转为新的集合保存在订单信息结果表 (ht_order_info_result)中。这样即保留了根据属性统计订单的可能，又保证了查询的多入口多方式的可能。另外，在订单修改过程中也记录了更改的字段，更改人等重要信息。
s40、供应商即对应商混企业对订单进行确认。根据用户和用户选择的订单号(orderno)就只能查询出唯一条订单，随即更改订单状态(这里的订单状态是用枚举方式控制，页面请求是下一步操作码和订单号(orderno)的组合，表单方式提交，保证了数据不可见，消除在地址栏处手动更改状态码的可能，提高安全等级)，即时写入订单状态记录表(ht_order_status_record)状态更改记录中，记录具体那个用户在那个时间对订单做了怎样的更改，对提高数据的可靠性和减少后续争议起了积极作用。
本实施例是面向整个工业产业订单信息管理，对订单业务管理，数据格式，数据处理进行了详细介绍，本实施例中的说明图和表格对本发明的原理及实施方式进行了阐述，本实施例即可适用于混凝土行业也可适用砂浆等订单的管理。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。