拼多多发票助手里找不到订单，我是怎么从完整订单里补申请的，多多开票助手开发经验分享

我做多多开票助手，起因并不复杂。

自己处理拼多多采购订单时，我发现申请一两张发票不难，麻烦的是订单多了以后，拼多多APP里的发票助手并不一定展示全部采购订单。

明明订单还在，商品也收到了，但发票助手的“待申请”列表里找不到。遇到一笔还能打开订单详情慢慢查，几十笔混在一起，就很难判断到底漏了哪些。

后来我才意识到，这个问题不能只在发票助手里解决。

发票助手不是采购订单台账

拼多多APP里的发票助手，主要用来处理平台当前展示的发票申请。它不是完整订单列表，也不适合拿来核对某个月的全部采购。

订单没有出现在发票助手里，可能有几种情况：

• 已经申请过，状态进入处理中；
• 订单发生退款或售后；
• 当前订单不符合在线申请条件；
• 发票助手没有展示，但订单对应的申请页面仍然存在。

最后一种情况很容易漏掉。

以前我看到发票助手里没有订单，也会下意识认为这笔不能申请。后来在做插件时，我换了一个思路：不要从“待申请发票列表”开始找，而是先获取采购订单，再逐笔判断发票状态。

两种处理方式的差别很大。

APP发票助手：
平台先筛选订单
→ 用户只能看到筛选后的结果
→ 再从结果中申请

订单工具：
先读取采购订单
→ 检查每笔订单的状态
→ 尝试进入对应申请页
→ 由页面返回最终结果

第二种方式不会直接把“没显示”判断为“不能申请”。

我先解决的是“订单看不全”

开发多多开票助手时，我没有把APP发票助手里的订单作为唯一来源。

插件先查询当前拼多多买家账号的采购订单，再显示商品、店铺、金额、订单状态和发票状态。这样做的目的不是绕过平台，而是先把采购范围还原出来。

例如要处理8月份的发票，我会先查询8月1日至8月31日的订单。订单列表出来后，再区分：

• 哪些已经申请；
• 哪些已经开票；
• 哪些正在退款或售后；
• 哪些还没有发票记录；
• 哪些需要进入申请页面进一步确认。

到了这一步，发票缺口才比较清楚。

如果只盯着APP发票助手，我只能看到平台给出的“待申请”；从采购订单开始检查，才能知道还有哪些订单没有进入这个列表。

不是所有订单都值得打开一次

最初做批量功能时，一个很直接的方案是：用户选多少订单，我就打开多少个申请页面。

代码很好写，但实际不好用。

已经申请过的订单会重复打开，退款订单没有处理价值，待支付订单也不应该进入申请流程。订单一多，浏览器会花大量时间处理本来就应该跳过的数据。

所以我在批量任务前增加了一层过滤。目前会优先排除：

• 待支付或待付款的订单；
• 退款、售后中的订单；
• 已经出现发票详情的订单；
• 已申请或已开票的订单。

待发货订单则允许用户自己选择是否跳过。默认跳过更稳妥；如果用户明确需要检查，也可以继续尝试进入申请页面。

因此，在多多开票助手里可以直接全选当前查询到的订单。系统先过滤，不需要用户手工把已经申请过的订单一笔笔取消。

APP没显示，不代表插件一定能申请

这个边界必须讲清楚。

插件能找到APP发票助手没有显示的采购订单，也能尝试进入订单对应的申请页面，但它不能修改拼多多对订单的判断。

我在页面自动化脚本里做了两层检查。

第一层检查页面文字。如果出现“已申请”“处理中”“已开票”，说明订单已经处理过；如果出现“不支持”“无法申请”“订单异常”“已退款”等提示，就记录原因并结束当前订单。

第二层才查找“申请发票”按钮。只有页面上真的存在可操作入口，程序才会继续点击并等待结果。

逻辑可以简化为：

if (页面显示已经申请或开票) {
记录为已处理;
} else if (页面显示不支持或订单异常) {
记录失败原因;
} else if (找到申请发票按钮) {
点击并等待提交结果;
} else {
记录为未找到申请入口;
}

所以我不会把产品描述成“APP不能开的订单，插件都能开”。

更准确的说法是：部分没有出现在APP发票助手里的订单，仍可能存在申请入口；插件帮助用户找到这些订单、逐笔检查并自动提交可以处理的部分。

为什么批量任务要逐笔执行

既然要自动化，为什么不同时打开几十个页面？

我试着推演过这种方案，很快就放弃了。

并发打开大量页面会带来几个问题：

• 浏览器容易卡顿；
• 页面加载顺序不可控；
• 很难判断结果属于哪笔订单；
• 登录失效后仍可能继续打开页面；
• 用户想暂停时，不知道应该停在哪里。

最后采用的是顺序队列：当前订单处理完成后，再把同一个窗口导航到下一笔订单。

每笔订单都有独立状态：

待处理 → 处理中 → 已提交
↘ 失败
↘ 跳过

这样速度不一定看起来最夸张，但结果比较清楚。中途可以暂停、继续或停止；拼多多登录过期时，后续任务也会结束。

我作为使用者，更关心的是任务跑完后能不能知道哪几笔没处理，而不是界面上的进度条跑得多快。

申请提交以后，事情还没结束

插件显示“已提交”，只代表买家端申请动作完成。

最终发票仍然由商家开具。商家什么时候处理、是否需要补充资料，以及订单是否支持对应类型的发票，都不是浏览器插件能决定的。

我的处理习惯是把状态分开：

• 未申请；
• 已提交；
• 已开票；
• 已下载；
• 需要人工处理。

过一段时间重新查询，已经开具的进入下载范围；还在处理中的继续等待；失败的只处理失败项，不需要把整批订单重新执行。

如果不用插件，可以怎么做

这套方法并不依赖某个工具。订单不多时，用表格也能完成：

多多开票助手做的是把第3步到第6步中的重复操作自动化。订单只有三五笔，手工完全够用；每个月需要处理几十笔甚至更多时，批量队列才有明显价值。

最后说一下产品边界

多多开票助手是我开发并在使用的第三方浏览器插件，与拼多多官方没有隶属关系。

它能读取当前登录账号的采购订单，过滤明显不需要处理的订单，并按顺序尝试提交发票申请。它不能替商家开票，也不能保证每笔订单都有申请入口。

我写这篇文章，是想把一个容易混淆的问题说清楚：

拼多多APP发票助手里没有显示订单，不等于这笔订单一定不能申请。先回到采购订单，再检查具体页面，得到的结果会更完整。