關於對接保稅倉物流系統或支付系統推送報關單的一些瑣碎的問題

最近公司的一個商城的客戶,作保稅倉發貨的功能,該功能須要對接到一些第三方的物流倉報關係統以及支持系統的報關功能,中途碰上了N多個坑,所以記錄下來,省的下次忘了

 

 

1.因爲本來的系統並無計算稅費的功能,所以須要在訂單中增長稅費的計算,這時候,就須要在商品詳情裏增長几個字段:增值稅、消費稅、付稅方；

   增值稅通常爲：16%，消費稅爲15%，付稅方： 顧客/商家(若是爲商家,即爲保稅) 

   通常跨境電商的須要交一個綜合稅,計算方式爲:

   若是消費稅=0,則爲 16%*70%=11.2%

   若是消費稅>0,則爲 ((16% + 15% )/(1-16%) )*70%

 

2.在實際的銷售過程當中,有可能出現包稅的狀況存在,若是一張訂單裏出現包稅和不包稅的商品,則推送報關單的時候,須要拆分紅兩張子訂單,付款單號能夠相同,只要多張子訂單的付款金額加起來不超過該付款單的總金額便可。

  在包稅的子訂單裏，須要將商品金額中，拆分出稅金，這就是爲何上面須要存一個付稅方字段，而不是把兩個稅率都設爲0的緣由了

  計算方式爲：  商品總金額=原商品總金額-（(商品總金額 / 1+稅率) * 稅率）

                     商品單價   = 新的商品總金額/商品數量    (可能會出現除不盡,建議保留小數點後4位)

                     依次類推,合計數子訂單的商品金額和稅金

 

3.因爲商城還可能出現一種狀況,就是包郵/不包郵的狀況。

   若是不包郵的狀況下，其實運費= 實際運費+運費的稅金（運費*綜合稅率），

   若是包郵的狀況下，其實是商家替用戶支付了運費的稅費，若是實在非要算個一下稅費的話，那就將稅費平攤到商品裏便可

   有些對接的系統是須要傳一個總稅金的字段，那麼總稅金=運費稅金+商品稅金總和

 

4.可能還會再出現一種狀況就是包稅不包郵,這時候須要拆單的狀況下,運費能夠根據兩張訂單佔總商品金額的比例將運費和運費稅平攤到兩張子訂單中,在子訂單中進行分配

 

5.若是出現一張訂單中,都是跨境電商的商品,那麼還算簡單,原有的訂單結構不須要變化,只是在推送的時候,將訂單進行拆分推送就好,子訂單的訂單號能夠簡單的在主訂單號後加一個後綴標識一下便可，若是出現跨境電商爲分倉庫發貨或者存在跨境電商+直郵商品的狀況的，則最好在下單的時候，將訂單各自拆分紅訂單，因爲付款單號能夠共用，所以 只須要讓用戶支付一次便可

 

6.還有個很細節的地方須要特別注意的，，就是因爲報關單通常是三單對碰成功以後，才能夠，但，支付單是由支付平臺推送的，而訂單和物流單是另一個物流報關係統推送的 ，所以這裏會存在一個問題就是，物流系統是以什麼方式取到支付單的，，根據對接這幾天的總結，有兩種，一種是經過支付單號匹配，一種是經過訂單號取支付單號。。。若是是支付平臺提示報關成功，而物流平臺提示沒法找到支付單的狀況，，必定要使用微支付或支付寶的原始交易單號進行提交，不能用支付平臺提供的內部支付單號提交，不然就會出現沒法匹配到支付單的狀況。

 

7.有些支付平臺會要求必須拆單推送，即無論是否存在包稅+不包稅的狀況下，必須拆分紅子訂單提交，所以，對接時，請跟你的支付商肯定好這個問題 

 

8.若是對接的物流系統的商品信息推送接口過程當中,,凡有叫編號或者ID的字段的,無論是否寫着可空或者能夠默認與xxx字段相等,也都直接添加在界面上,讓客戶本身去填寫,不然可能會出現匹配不到商品的錯誤 

 

9.因爲報關是個很複雜的事情，所以說上面所說的，只是本人碰到的比較簡單的狀況，，實際對接，請跟對接平臺肯定好細節 

 

最後的最後,,,若是須要四捨五入的話,必定要使用 System.Math.Round(value , 2, MidpointRounding.AwayFromZero) 這個方法,而且 value必須

是decimal