关于对接保税仓物流系统或支付系统推送报关单的一些琐碎的问题

最近公司的一个商城的客户,作保税仓发货的功能,该功能须要对接到一些第三方的物流仓报关系统以及支持系统的报关功能,中途碰上了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