編輯導語：本文作者回顧了之前做線上電子發票開發的整個過程，總結出了開票這個需求的一些相關事項，希望能給你帶來幫助。

所屬企業以線下業務為主，所以APP的線上交易也一直是走線下人工開具發票，随着線上業務的不斷增長，線上電子發票的開發被提上日程。

隻沒想到，在這個過程中，因各環節各因素影響，這個需求經曆了：換财務、換前後端開發、換測試、換對接爸爸、更改業務主流程等各種阻礙。

鐵打的産品，流水的相關方。發票需求的開發斷斷續續拖了2年，曆經各種磨難，終于守得雲開見日月——要在近期上線了。

回顧了發票需求文件夾各種版本的RP和記事備忘錄，在此整體簡述一下開票這個需求的相關事項：

《中華人民共和國發票管理辦法》第十九條規定，銷售商品、提供服務以及從事其他經營活動的單位和個人，對外發生經營業務收取款項，收款方應當向付款方開具發票。

特殊情況下，由付款方向收款方開具發票。因此，消費者通過網絡購物，都可以要求商家開具發票。

• 網購商品有産生現金支付交易，走開票邏輯
• 網購商品有産生虛拟貨币支付交易，走企業代扣代繳個稅，需要收集購物客戶個人信息

市場開票服務商衆多，百望、51發票、easy API、發票通、發票兒 、金蝶發票雲、航天信息發票等等，哪個是附合自己企業要求的，需要相關人做競品分析進行抉擇。

抉擇後，将符合開票條件的信息實時或定時推供給開票服務商，由開票服務商接口實時開出發票。

用戶下單時填寫發票申請—用戶收到貨觸發第三方開票—開票成功，票據系統保存同步返回用戶端。

觸發開票時間節點：

• 用戶人工點擊确認收貨
• 快遞回傳【簽收】狀态
• 虛拟類商品下發到賬即觸發開票

每月月底已發貨、未簽收訂單未達到自動觸發開票邏輯，财務月度清賬如何處理？——此項需要看自己企業财務的要求。

會産生異常的場景包括：

1. 用戶退款

1）部分退

1. 部分紅沖：紅沖票上會有【銷項負數】字眼，【備注】欄會記錄本張紅票對應正數發票代碼，号碼字段。
2. 全沖：原開的藍票作廢，計算減去退款後的實際支付金額，重新開具新的藍票。

1和2兩種不同的紅沖處理方式，需要根據實際業務和财務、業務部門溝通選擇符合自己業務的處理流程。

此處有細節問題待留意：

• 退款商品數量是否會出現小數？
• 是否有退款隻退現金或隻退虛拟貨币的問題？

2）全部退

此場景全沖，不再開出藍票。

2. 換開發票

此場景通常是票面信息有誤，需要走全沖，按新的發票擡頭信息開出新藍票。

紅沖次數過多會對企業信譽産生影響，産品的規劃，需要考慮如何減少訂單多次退款和票面錯誤申請修改。

同時調研衆多電商平台，會在開票規則中說明，申請退款次數的上次、換開次數的上限。

3. 系統異常，開票失敗

走異常預警，人工介入。

上線前的曆史已有訂單，建議走線下，财務和開票服務商溝通，開一個整張的發票。

本文所寫内容以自身企業涉及到的實操總結，如有錯漏請指正，伏地接受。

電商平台開票，大方向上講，通用邏輯大體一緻。但不同企業、不同業務，不同的開票服務商對發票系統設計的皆會有所不同。

如何将别人經曆轉化為自己的産物，且可以完美避坑，是需要下沉到自己業務的實際需要，多方溝通，站在不同的角度多方位思考。一點點地積累解決，終會輸出符合你自己需要的産品需求。

開票涉及到現金、财務對賬，整體需求需要非常謹慎。

不過，有産品經驗的人都知道，無論需求規劃考慮的有多仔細，測試環境測試案例寫的有多全面，都要做好最後的心理準備：實際上了生産後，一定都會出現各種奇葩問題。

而我們産品作為風箱中的老鼠，一定要堅定信心，那些正在踩或即将要踩的坑最終總會找到解決的辦法。

本文由@seven 授權發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!