第一次用 1688 批量发开票申请的时候，我数着订单是四十七笔，结果跑完显示只发了三十来笔。当时第一反应是它漏了。
后来点开那个"查看排除订单"，才发现剩下的十几笔是被主动剔掉的，每一笔后面都跟着原因，有的是退款，有的是交易关闭。看完我就踏实了，不是漏，是不该发。
这个排除明细我现在每次都会看一遍，因为它能省掉很多瞎猜的时间。
哪些订单会被排除掉
我遇到的主要是三类。
第一类是交易关闭的。这种订单压根没成，钱也没真正结清，拿去要票本来就不合适。我那批里有三笔是这个原因，都是当时下单后商家说没货，我自己关掉的，早忘了。
第二类是退款相关的。退款中和退款完成都算。货都退了还去要发票，商家看到了估计也懒得理。这类我那批里有七笔，占了排除的一多半，那阵子正好赶上几家店发货慢，我退了不少。
第三类是售后中的。还在处理售后流程的订单，状态没定下来，这时候申请发票容易出岔子，等售后走完再说更稳。
这三类是明明白白记在明细里的，不是它自己悄悄跳过的。
明细里能看到什么
点开排除明细，是一张带列的清单。我实际会看的是这几项：页码、订单号、商家、金额、下单时间、订单状态，还有排除原因。
页码这个挺有用。我有一次发现某一页排除得特别多，翻过去一看，那页正好是某一家店的集中退款，心里就有数了。
金额也有用。排除掉的如果都是小额，那不影响什么；要是里面夹着一笔大的，我就得单独看一眼，确认是不是真的该排除，别是状态识别错了。
还能按原因筛选。想只看退款的就筛退款，想看售后就筛售后，不用在一长串里翻。
有一类订单不会被算进排除里
这个细节是我在文档里看到的，后来也验证过：金额或者下单时间识别不出来的订单，不会直接被当成排除订单。
这个设计我觉得是对的。识别不出来和"确定不能申请"是两回事，如果一股脑都扔进排除清单，我就没法分清哪些是真的不能要、哪些只是没读到数据。宁可留在可处理的那边，让我自己再看一眼。
所以排除明细里的每一笔，都是有明确原因的。
选"所有页"的时候，明细是累计的
1688 那边是逐页处理的，一页跑完才进下一页。所以排除明细也是一页一页攒起来的。
选所有页的时候，这些明细会跨页累计，而且按订单号去重。同一笔订单不会因为翻页重复出现两次，这点不用担心。
我一般会先只跑当前页，看一眼排除的情况，确认剔得对不对，再选所有页全量跑。先看一小块，比一口气跑完再回头排查要省事。
为什么先看分析再发，比直接发要省事
我以前是直接在 1688 上挨个找商家聊，复制订单号、金额、抬头，一条条发。那会儿根本没有什么"分析"的概念，全凭肉眼扫，退款的单子经常混在里面一起发出去。
发出去的后果是：商家回一句"这笔你都退款了"，我尴尬地回一句"不好意思搞错了"。来来回回，时间就这么耗掉。
先分析一遍，把这些不该发的挑出来，发出去的每一条都是站得住的，商家的回复率明显高一些。这不是什么高明技巧，就是不浪费彼此的时间。
这一步我现在交给它做
分析和排除是自动做的，我一页打开它就开始扫，不用我点什么额外的按钮。扫完给个汇总，显示总共多少笔、能处理多少笔、排除多少笔，排除那个数字是能点开看明细的。
这套是我用多多开票助手做的，它是装在浏览器上的扩展，1688 那边的动作是在买家订单页上进行的：读取当前页订单、按商家整理好、通过站内消息把开票申请发给商家。安装和第一次提交我写过一篇图文教程。
边界得说清楚：它发的是开票申请消息，不是发票本身。商家收不收、什么时候开、开成什么样，全在商家那边。它也不能替我判断某一笔到底该不该要票。交易关闭和退款它能识别，但比如"这笔虽然退款了但商家答应补开"这种特殊情况，还得我自己拿主意。
看完明细之后我会再做两件事
第一件是扫一眼金额那列。排除的里面要是有一笔明显大的，我就点开那笔订单看一眼状态，确认排除得对。机器判断的依据是订单状态，状态本身如果显示得不规范，判断就可能偏，人工看一眼最保险。
第二件是把排除清单留个底。我一般会记一下这个月排除掉多少笔、都是什么原因。倒不是为了对账，是为了看趋势，要是退款的排除数量突然变多，说明我最近采购的店铺有问题，该换一家了。
常见问题
排除掉的订单还能不能单独再申请？
被排除是因为状态不适合申请，比如交易关闭、退款、售后中。真有特殊情况需要申请，可以等状态变化后重新分析，或者自己联系商家处理，工具不会强行把这些发出去。
为什么我看到的排除数量跟订单总数的差额对不上？
排除明细只统计有明确排除原因的订单。金额或下单时间识别不出来的订单不会被算进排除清单，它们留在可处理的一侧，所以数量可能和你心算的差额不一致。
排除明细会跨页重复统计同一笔订单吗？
不会。用多多开票助手选所有页跑的时候，明细会跨页累计，并按订单号去重，同一笔订单只出现一次。
1688 这边能直接开出票来吗？
不是。它做的是把订单和抬头整理好，通过站内消息向商家发送开票申请。发票仍由商家开具，开不开、什么时候开由商家决定。