本發(fā)明涉及一種混凝土行業(yè)交易過程中信息管理技術(shù)領(lǐng)域，特別是涉及一種混凝土結(jié)算數(shù)據(jù)的管理方法。

背景技術(shù)：

混凝土結(jié)算服務(wù)系統(tǒng)做為一種交易信息管理，具有開放性，準(zhǔn)確性，高維度，高可用，易擴(kuò)展等特點，在整過交易過程中，記錄了訂單信息，物流配送信息，實現(xiàn)了結(jié)算過程中的雙方確認(rèn)，在數(shù)據(jù)和邏輯層面實現(xiàn)了數(shù)據(jù)的統(tǒng)一。為后續(xù)的結(jié)支付提供了有利的數(shù)據(jù)支撐。

混凝土結(jié)算服務(wù)系統(tǒng)是解決工業(yè)產(chǎn)業(yè)實現(xiàn)互聯(lián)網(wǎng)+的一個層面的縮影，實現(xiàn)了b2p2c的新商務(wù)邏輯，更是大數(shù)據(jù)時代不可割裂的一部分，但在當(dāng)前環(huán)境中，對于安全問題已經(jīng)是不可避免的難題。在混凝土結(jié)算服務(wù)系統(tǒng)中，報文是信息的載體，服務(wù)具有開放性，因此報文信息很容易被攻擊，如監(jiān)聽攻擊、攔截和篡改等。

技術(shù)實現(xiàn)要素：

針對上述問題中存在的不足之處，本發(fā)明提供一種混凝土結(jié)算數(shù)據(jù)的管理方法，使其完善記錄交易結(jié)算的數(shù)據(jù)，實現(xiàn)買賣雙方的數(shù)據(jù)確認(rèn)和統(tǒng)一，為最終的支付提供有效支持。

為了解決上述問題，本發(fā)明提供一種混凝土結(jié)算數(shù)據(jù)的管理方法，其中，包括以下步驟：

s10、設(shè)置項目中混凝土采購/銷售單價；

s20、獲取項目單價；

s30、選擇結(jié)算訂單；

s40、可修改指定訂單的配送單，可逐條修改配送價格和備注信息， 根據(jù)配送價格進(jìn)而影響訂單總價；

s50、填寫備注后，保存生產(chǎn)未生效結(jié)算單；

s60、客戶即對建筑商企業(yè)對結(jié)算單進(jìn)行確認(rèn)。

優(yōu)選的，在所述步驟s10中，施工單位和商混站分別設(shè)置項目的混凝土的單價，按混凝土的屬性的值逐一設(shè)置單價，屬性的單價。

優(yōu)選的，在所述步驟s20中，每個砼訂單對應(yīng)一個項目id，當(dāng)訂單完成后，根據(jù)用戶id可以查詢出完成訂單對應(yīng)的項目id，再根據(jù)項目id查詢項目的信息。

優(yōu)選的，在所述步驟s30中，選擇結(jié)算項目，獲取到項目id，通過項目id和結(jié)算期間取得該項目下未結(jié)算的訂單號；在每個訂單中，都有對應(yīng)的供求雙方的用戶id和項目id，上述3個id可以組成整個系統(tǒng)中唯一的標(biāo)示；每個訂單都存在本身的影響價格因素的屬性及值的集合，通過自定義id(definedid)查詢出之前維護(hù)的影響價格因素的集合與屬性集合(attrlist)循環(huán)比對即相同屬性id時對比不同的值來獲取錄入該值時的價格，全部屬性的價格求和即為訂單單價。

優(yōu)選的，在所述步驟s40中，系統(tǒng)中維護(hù)了每個屬性的價格，對于每個產(chǎn)品都有多個屬性進(jìn)而對應(yīng)多個價格，價格求和后即是單價，價格和備注保存在配送單和結(jié)算單的中間表(ht-mid-delivery-statement)中的單價(price)和備注(memo)中，單價(price)×數(shù)量即單配送單價格。

優(yōu)選的，在所述步驟s50中，在中間表配送單和結(jié)算單的中間表(ht-mid-delivery-statemen)中插入一條記錄，記錄的是更改的配送單信息，并記錄更改的單價(price)，備注(memo)數(shù)據(jù)，在結(jié)算單表(ht_concrete_final_statement)中訂單關(guān)聯(lián)結(jié)算單，記錄更改的訂單的數(shù)量和更改的一方的單價price，最后結(jié)算單表(ht_concrete_final_statement)中正式生成結(jié)算單，結(jié)算單狀態(tài)(status)未確認(rèn)。

優(yōu)選的，在所述步驟s60中，結(jié)算單生效即結(jié)算單表 (ht_concrete_final_statement)中的狀態(tài)(ststus)更改為已確認(rèn)狀態(tài)，結(jié)算單確認(rèn)后，即時寫入狀態(tài)更改記錄中訂單狀態(tài)記錄表(ht_final_statement_status_record)，記錄具體那個用戶在那個時間對結(jié)算單做了怎樣的更改。

與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點：

本發(fā)明旨在完善記錄交易結(jié)算的數(shù)據(jù)，實現(xiàn)買賣雙方的數(shù)據(jù)確認(rèn)和統(tǒng)一，為最終的支付提供有效支持，銷售方發(fā)起結(jié)算，在已完成的訂單中進(jìn)行多選，這里訂單要根據(jù)配送單的施工工藝進(jìn)行分組，訂單對應(yīng)多個配送單，每個配送單的價格都是根據(jù)之前項目管理中維護(hù)的屬性價格和當(dāng)前配送單的施工工藝屬性價格求和獲取，與每個配送單的數(shù)量乘得，因此訂單的總價即訂單包含的全部配送單的總價的和。當(dāng)然，這里的結(jié)算是訂單為最小單位，分組的訂單勾選必須一起結(jié)算，這也是一個邏輯完整的保證。

附圖說明

圖1是本發(fā)明的實施例流程示意圖。

具體實施方式

為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，下面結(jié)合附圖與實例對本發(fā)明作進(jìn)一步詳細(xì)說明，但所舉實例不作為對本發(fā)明的限定。

如圖1所示，本發(fā)明的實施例包括以下步驟：

s10、設(shè)置項目中混凝土采購/銷售單價。施工單位(買方)和商混站(賣方)分別設(shè)置項目的混凝土的單價，按混凝土的屬性的值逐一設(shè)置單價，屬性pro(i)的單價proprice(i)。如強(qiáng)度等級屬性，選項分別c10，c20，c30…等則對應(yīng)需要設(shè)置c10價格100元，c20價格150，c30價格200，全部設(shè)置完成后，即可以根據(jù)供求雙方和項目信息查詢到一個關(guān)于價格的集合。

s20、獲取項目單價。每個砼訂單對應(yīng)一個項目id(projectid)，當(dāng)訂單完成后，根據(jù)用戶id可以查詢出完成訂單對應(yīng)的項目id，再根據(jù) 項目id查詢項目的信息。

s30、選擇結(jié)算訂單。選擇結(jié)算項目，獲取到項目id，通過項目id和結(jié)算期間取得該項目下未結(jié)算的訂單號(orderno)；在每個訂單中，都有對應(yīng)的供求雙方的用戶id和項目id，這時，上述3個id可以組成整個系統(tǒng)中唯一的標(biāo)示，即有自定義id(definedid)＝項目id(projectid())+″_″+供應(yīng)商id(supplierid())+″_″+客戶id(customerid())；每個訂單都存在本身的影響價格因素的屬性及值的集合，通過自定義id(definedid)查詢出之前維護(hù)的集合，與屬性集合(attrlist)循環(huán)比對即相同屬性id時對比不同的值來獲取錄入該值時的價格，全部屬性的價格求和即為訂單單價。利用訂單號(orderno)取得該訂單下的配送單，獲取到該配送單簽收數(shù)量(receiveeamout)；利用訂單的單價(proprice(i))×配送數(shù)量(count)＝配送單價(deliveryprice)，訂單的總價(orderprice)＝∑配圣單價(deliveryprice(i))。

s40、可修改指定訂單的配送單，可逐條修改配送價格和備注信息，根據(jù)配送價格進(jìn)而影響訂單總價。關(guān)于訂單的單價產(chǎn)生是本發(fā)明特有的算法，系統(tǒng)中維護(hù)了每個屬性的價格，對于每個產(chǎn)品都有多個屬性進(jìn)而對應(yīng)多個價格，價格求和后即是單價。價格和備注保存在配送單和結(jié)算單的中間表(ht-mid-delivery-statement)中的單價(price)和備注(memo)中，根據(jù)上述原理，單價(price)×數(shù)量即單配送單價格。

s50、填寫備注后，保存生產(chǎn)未生效結(jié)算單。這時，在中間表配送單和結(jié)算單的中間表(ht-mid-delivery-statement)中插入一條記錄，記錄的是更改的配送單信息，并記錄更改的價格(price)，備注(memo)數(shù)據(jù)。在結(jié)算單表(ht_concrete_final_statement)中訂單關(guān)聯(lián)結(jié)算單，記錄更改的訂單的數(shù)量和更改的一方的單價(price)，最后結(jié)算單表(ht_concrete_final_statement)中正式生成結(jié)算單，結(jié)算單狀態(tài)(status)未確認(rèn)。

一條結(jié)算信息對應(yīng)多條訂單信息，一個訂單多應(yīng)多條配送信息，并且同一訂單或配送單不能被重復(fù)結(jié)算。

s60、客戶即對建筑商企業(yè)對結(jié)算單進(jìn)行確認(rèn)。此時結(jié)算單生效即結(jié)算單表(ht_concrete_final_statement)中的狀態(tài)(ststus)更改為已確認(rèn)狀態(tài)。結(jié)算單確認(rèn)后，即時寫入狀態(tài)更改記錄中結(jié)算單狀態(tài)記錄表(ht_final_statement_status_record)，記錄具體哪個用戶在哪個時間對結(jié)算單做了怎樣的更改，包新狀態(tài)(new_status)，舊狀態(tài)(old_status)，執(zhí)行用戶操作用戶id(actionuserid)等，對提高數(shù)據(jù)的可靠性和減少后續(xù)爭議起了積極作用。

本發(fā)明面向整個混凝土結(jié)算信息管理。對結(jié)算業(yè)務(wù)管理，數(shù)據(jù)格式，數(shù)據(jù)處理進(jìn)行了詳細(xì)介紹，本發(fā)明適用于混凝土行業(yè)也可適用砂漿等訂單的管理。

對所公開的實施例的上述說明，使本領(lǐng)域?qū)I(yè)技術(shù)人員能夠?qū)崿F(xiàn)或使用本發(fā)明。對這些實施例的多種修改對本領(lǐng)域的專業(yè)技術(shù)人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本發(fā)明的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本發(fā)明將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。