中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

做汽車后市場的B端產品，比其他類型的B端產品要復雜得多。一是流程比較長，涉及到供應商、用戶等，二是管理難度大，SKU多，發票等處理還需要考慮合規等問題。這篇文章，我們來看看作者總結復盤的發票產品的設計復盤，供大家參考。

我們構建了一個線上門店采購平臺，支持我們下屬的修車廠（簡稱門店）在平臺采購汽修用品。按照規定，我們公司有義務為門店開具進項稅發票。在本項目未上線前，我們開發票的模式是線上申請發票+線下人工開具，人工開具的工作是由我們請的開票外包負責，他們是按照開票張數進行收費。

加之現在國家在大力推進全面數字化的電子發票（簡稱數電發票），數電發票在安全性上較之前的發票有顯著提升。因此，我們決定對發票系統進行升級，在線上申請的基礎上支持線上開票，方便門店即時提交，即時開具，減少門店等待發票時間，同時也減少了我們外包費用。

一、總體流程

1. 開票前的數據準備

1）商品的稅務信息：由總部的業務同學維護好sku的類目或具體sku 的稅收分類編碼、稅率。開票時，系統根據商品的skuid讀取對應的稅務信息。

2）門店的發票抬頭：發票抬頭不支持門店隨意修改，而是根據門店與我司簽署的【采購合同】的簽約主體，由總部業務維護在系統上，在申請開票時，門店可以看到該信息，但是不支持修改。

3）訂單購方信息和銷方信息固化：因為門店如果變了老板，換了公司名稱，是需要變更采購營業執照，他需要與我們重新簽署采購合同。因此這家門店的購方信息是哪個，是存在因為時間段的不同而變化的情況，因此需要訂單下單時，將此部分數據固化下來。

2. 門店開票申請

1）勾選多個訂單進行開票：與C端消費不同，B端消費一般是月底批量申請發票，一次性報稅，且報稅的時候需要錄入每張發票信息。因此如果僅支持單個單個訂單申請發票，那會增加門店的申請發票的操作成本，也會增加門店財務進行報稅時登記發票信息的操作成本。因此，本項目是支持門店勾選多個訂單，一次提交開具一張發票。

3. 開票后續處理

C端消費經常會出現沖動消費，買后再退的場景。但是，B端采購一般都是有計劃性有目的性，即使售后也一般是換貨為主，因此涉及到退貨要開紅沖發票的場景較少。因此，本期暫時不支持線上調接口紅沖，等后續評估紅沖場景多少，再決定是否支持該功能。因為本期，我們在售后的時候會提示門店和總部人員，必須要開具好對應的紅沖發票后，才支持線上申請售后。

門店開發票的業務流程

二、功能介紹

1. 商品稅務信息配置

稅務信息配置時，我們是支持按照類目配置和按照sku配置。他們的使用場景如下：

1. 按類目配置：如果一家企業設置類目和將sku放置在合適的類目下，這個操作比較規范的話，一般同一個類目下的商品的稅務信息相同，那業務就按照類目配置稅務信息即可；
2. 按照sku配置：如果同一個類目下，個別商品的稅務信息與其他商品的稅務信息不同，那業務可以單獨為該sku設置稅務信息，那系統如果發現該sku存在“sku維度的稅務信息”，那優先取該sku該維度的稅務信息。

另外，運費的稅率一般比較固定，因此我們不支持前臺配置的，是直接寫到后臺代碼里面。

1）按照類目配置

主要功能點：

• 類目稅務信息搜索
• 批量配置類目稅率（excel導入）
• 單個類目稅率、稅收分類編碼配置
• 單個類目稅務信息刪除

如果要刪除某個類目的稅務信息，那一定要保證目前【該類目在系統處于作廢狀態】（類目作廢的前提校驗：沒有sku是歸屬該類目）

• 稅率信息導出

2）按照sku配置

主要功能點

• sku稅務信息搜索
• 批量配置sku稅率（excel導入）
• 單個sku稅率配置、刪除
• 稅率信息導出

2. 公司稅務信息維護

前臺沒有提供頁面，也是直接寫在后臺里面，包括公司名稱、公司地址、開戶行、對應銀行賬號、統一社會信用代碼、開票人、收款人、復核人

3. 購方發票抬頭維護

1）發票抬頭應取實際采購人信息

為確保交易的合法性和合規性，任何情況購方的發票抬頭都應與實際的采購方保持一致。因此，本期涉及時，不支持購方自主填寫發票抬頭，而是系統取值，然后購方核對信息正確性，如無誤，則申請開票。

那誰是B端采購的實際人？一般可以從如下幾方面判斷：

（1）基于交易關系的判斷

• 合同關系：首先，應參考采購合同或相關協議。合同中通常會明確標明甲方（采購方）和乙方（供應方）的身份，甲方即為實際采購方。
• 交易行為：觀察交易的實際操作，如誰提出采購需求、誰支付貨款、誰接收貨物等。這些行為通常能夠反映出實際的采購方。

（2）結合其他信息綜合判斷

• 物流信息：物流單據、收貨地址等信息可能反映出實際的采購方。
• 付款憑證：付款憑證如銀行轉賬記錄、支票等，通常能夠顯示付款方（即實際采購方）的信息。
• 溝通記錄：與供應商、采購方等相關方的溝通記錄，如郵件、電話記錄等，也可能包含關于實際采購方的信息。

如果發生了實際支付和采購合同不一致的情況，雖然支付貨款的公司可能與甲方不同，但貨款支付行為本身也是判斷實際采購方的一個重要依據。如果支付貨款的公司是根據甲方的指示或委托進行支付，那么甲方仍然是實際采購方。

2) 本項目以訂單存儲的采購合同簽約主體作為實際采購人

因此，本項目我們的做法是每筆訂單下單成功后，自動存儲采購主體信息，此信息取系統下單時刻每家門店與我司簽署的采購合同的簽約主體。

之所以，要訂單在下單時刻存儲合同的簽約主體，而不是申請發票的時候去讀取。是因為，采購合同可能會發生變更，因此申請發票時候去讀取就無法保證此刻的信息是那筆訂單交易發生時實際的采購人。

另外，這也對業務提出了一定的要求，如果采購合同發生變更，要及時更新系統的信息。比較理想的方案，是運營教練提交申請變更采購合同流程，相關審批結束之后，在線簽署合同，合同簽署之后自動更新系統數據。

3）功能上線前的訂單別忘了刷【采購主體】數據

上線之后，訂單下單成功實時讀取系統數據，但是上線前的訂單也需要記錄該數據，理想的情況是業務告知每家門店在哪段時間對應哪個采購主體，然后按照時間段不同時期的訂單取不同時期的采購主體。但是業務反饋，這個數據之前他們都沒有記錄，系統的采購營業執照變更流程里面也沒有記錄準確的時間點，他們比較難提供這份數據。另外，如果采購合同變更，大概率也不會再申請老主體的發票，而且門店也不是針對每筆訂單都申請發票。最后應用的方案是，減少業務的工作+賭門店不去申請老主體的訂單，業務提供最新的采購合同的簽約主體信息和該合同的開始生效時間，則此時間之后的訂單刷最新數據，此時間之前的訂單不支持線下開票。

4. 門店申請發票

1）B端申請發票的操作習慣

C端消費者申請發票，一般都是在訂單詳情頁針對某個訂單進行申請，但是B端申請發票的操作習慣與之大不同。因為B端申請發票主要有如下操作習慣：

• 一般固定時間點，如月末一次性申請。這是因為門店財務一般在月末月初進行稅務上報，因此到了要報稅的時候，才會統計本公司的本月進項稅有多少，在稅務局進行申報。
• 申請時，是將多個訂單合并成一張發票。這是因為，財務在稅務局報稅時，每張發票都要錄入系統，如果每個訂單對應一張發票，那財務就要操作多次，因此，一定要支持訂單合并開票的邏輯。

2）功能介紹

2.1 勾選多個訂單申請開票

對于可以申請發票的訂單，我們支持勾選，會在訂單上展示可開票金額，即可開票金額=實付金額-售后完成的金額，對于售后中的訂單我們是不支持申請發票，因此售后中的金額未參與可開票金額校驗。

但是，部分訂單我們是不支持開票的如：

a.未完成訂單；

b.“訂單完成”超365天；

c.額度付款未全額支付的訂單；

d.退貨退款中的訂單；

e.已全部退款的訂單；

f.訂單實付金額=0；

g.已成功提交發票申請的訂單;

針對【額度付款未全額支付的訂單】這條，我介紹一下，這是因為我們商城支持門店用額度支付，即我方財務評估門店的交易流水，授予門店每個月可以使用的額度，門店就可以不使用現款而是使用額度進行付款，等下一個月再用現款償還額度。因為，如果這筆訂單你使用了額度但是沒有進行還款，那這個貨的貨權還不算真正到門店，因為門店無法申請開票。

2.2 點擊【去申請】提交發票申請

點擊【去申請】按鈕，進入發票申請頁面。但是部分場景會提示錯誤

2.3 填寫發票申請信息，點擊【提交】申請開票

一般情況下多個訂單會合并成一張發票申請單。但是滿足如下任一條件，會拆分為多張申請單：1）成品油和非成品油；2）不同的銷方主體；3）不同的購方主體。

申請單頁面支持用戶選擇開票類型、填寫收票郵箱，其他內容為系統自動帶出。

點擊【提交】按鈕，部分場景會進行報錯

哪些場景會自動開票失敗

2.4 符合開票條件的申請單，系統會將多個商品明細行合并成一行，目前的合并規則如下

發票明細行合并規則

5. 發票詳情查看

提交成功的發票，門店可在開票歷史中查看開票進度、預覽和下載發票。

總部可以在后臺查看申請單，對于異常的開票申請，可修正問題后點擊【重試】按鈕，重新調三方接口開票。

6. 訂單詳情里面可以查看對應的發票

門店側和總部側，可以基于訂單詳情頁展示實際開出的發票信息

7. 成功提交發票申請的訂單，要先紅沖，才能支持售后

因為本期我們沒有做紅沖流程，因此我們是在門店側和總部側申請售后的按鈕處，判斷該訂單是否已成功提交發票申請，如提交則進行提示。

tips：如果實際已經開出發票，一定要透出發票號碼，因為后續的紅沖處理需要拿著原發票號進行操作

門店側申請售后按鈕交互流程

8. 線下發票回傳系統

雖然本期實現了線上直接開具發票的功能，但是為了應對異常場景，如系統異常無法開票但是門店著急要票、門店的發票抬頭非系統指定抬頭且有相關材料佐證但系統無法及時調整數據，因此都需要支持線下開發票功能。但是為了防止多開發票，需要線下開過發票的訂單線上就不支持申請發票，因此系統需要支持將線下開過的發票回傳系統。

在之前的總部側的發票申請單列表透出【線下發票上傳】按鈕，點擊該按鈕，支持將線下發票的信息回填系統。并支持查看導入記錄。

1）導入模板

線下開發票的時候，一般也是多個訂單開在一張發票上。我們之前糾結過線下的發票是否要支持線上紅沖，如果要支持線上紅沖的話，因為如果要支持部分紅沖，就要支持某個訂單的某個商品對應藍字發票的某一行，但是這對于業務要求過于嚴格。因此，后來與業務協商，線上發票導入系統之后，不支持后續的紅沖操作，因此我們的業務是與門店協商，在售后結束之后才給門店進行線下發票開具。

財務會關注每個訂單開了多少發票，因此我們在線下發票上傳時也會要求填寫每個訂單對應該發票的開票金額，方便后期財務統計。

2）導入之后，系統支持查看導入記錄

3）線下發票回傳系統后，系統的相應處理

• 對應訂單不允許線上申請發票
• 對應訂單不允許線上申請售后
• 門店側、總部側均無法看到對應的申請單和發票信息
• 上述發票不支持線上紅沖