虾皮结算周期的起算点怎么定，先看口径

结算周期的起算点怎么定，先看口径

起算点是一个日期，但它不能在纸上随口挑定。它必须在订单流转里对应一个真实发生过的动作。成交、发货、签收、确认收货，每一个都可能被选中。选定哪一个，决定了从哪一天开始计天数。选之前先确认这个动作在订单上是不是真的存在。

有些订单根本没有发货这个动作，虚拟类商品就是常见的一种。也有些订单的签收不由买家触发，而是由物流方回传。把不存在的动作当成起点，算法从一开始就落空了。所以第一步不是选，而是筛。先把不成立的动作去掉，剩下的才有讨论价值。

筛完之后通常还剩两三个候选，谁都可以拿来当起点。这时候要看结算类型，它决定了哪一个候选才成立。有的类型要求从确认那一刻算起，有的要求从履约完成算起。把结算类型和候选日期对齐，起点才能落下来。对齐这一步不做，后面的天数就没法比。

起点定了还要定日历基准，这件事必须同时解决。同一段天数按自然日数还是按工作日数，是两个结果。这项工作不能在算完天数之后再补上去。补上去的数字往往和原来那版对不上，还得从头重算。两件事一起定，口径才算完整。

最后还要写下这套算法的生效范围，它比算法本身更容易被漏掉。它从哪一天起适用，覆盖哪一类订单，遇到规则调整怎么过渡。这些不写清，过两个月自己都会怀疑当初是怎么算的。写下它还能把隐含的假设逼出来。写不清的地方，通常正是假设藏着的位置。

定口径的过程中最容易出现的情况，是把两套算法混着用。前段按一个起点，后段按另一个起点，中间没有标记。混用的结果不是两个数取平均，而是两边都不成立。发现天数忽长忽短又找不到原因时，先查是不是混用了算法。混用常是换人接手留下的痕迹。

另一个常见情况是起点定在了需要人工确认的动作上。人工动作的时间不可控，短则几小时，长则几天。这会让推算出的天数带着一个说不清的浮动区间。能用自动动作做起点的时候，就不要用人工动作。省下的那点精确度，不值得多出这一段不确定性。

起点定得越靠前，算出来的天数越长，看起来越保守。但天数长不等于准确，这一点常被弄反。如果起点对应的动作本身不规律，天数就会一直抖。抖动的估计值比略偏的估计值更难用，因为它无法支撑任何承诺。稳定性比长短更重要，选择时应该先看这一条。

口径里还有一个隐含的选择，就是首日要不要算进去。从成交当天开始数，还是从成交次日开始数，会差整整一天。这一天的差别在单笔上看不出来，按月统计会累积成一笔不小的量。约定清楚比选定哪一种更重要。真正的问题不是选哪个，是有没有统一。

有些站点给的是相对表述，比如成交后若干天内处理。这种表述看起来明确，落到本地还是要变成具体日期。落在哪一天，取决于当地日历和节假日安排。相对表述本身不能直接用来排节点，只能当输入。把它当结论用，排出来的日期一定会偏。

口径一旦定下，短期内不要频繁改，改动的代价被低估得厉害。频繁改会让历史数据失去可比性，趋势也就没有基础。要改就一次性改到位，并把改动的时点记下来。记下改动时点，比记住改动内容更有用。有它在，旧数据和新数据才接得上。

不同的人看同一套口径，理解也可能不一样。避免这个问题的办法，是把判断过程写成几句能复述的话。凡是要解释超过三句的口径，都值得怀疑是不是定得太复杂。简单到能被复述，才可能被执行得一致。复杂到只能靠记忆，几轮之后就一定走样。

口径的边界要说清楚，不然它会不断被拉宽。它不管费用叫什么名字，也不管钱中途停在哪个环节。它只回答一件事，就是从哪一天开始数天数。起点之外的内容留给别的节次去处理。混在一篇里讲，两个问题都会讲不透。

走到这里可以定下第一层结论，它有三个组成部分。起算点是从若干候选动作里筛出来的一个，而且必须真实存在。配上一种日历基准，再圈定一个生效范围，口径才算成立。三者缺任何一项，算出来的都只是临时数字。临时数字不能用来排节点，也不能用来做比较。

口径这件事平时不出声，只在算出的日子和实际到账差得远时才被想起。等它被想起来，往往已经错了好几期数据。提前把起点和日历定死，比事后补算省力得多。补算还要面对一个麻烦，就是历史数据要不要跟着改。这个麻烦永久存在，只能靠事前避免。

把起算点定下来不是挑一个日期，而是先筛可行项，再统一日历基准，最后写下生效范围。

按自然日还是按工作日，差出几天

自然日和工作日的区别，全在日历这一层上。自然日把周末和节假日一起算进去，工作日只算可处理的那几天。同一个起点，两套数法的结果可以差出好几成。差别的大小取决于区间里有多少非工作日，而不是周期本身有多长。周期长短只改变数值，日历改变的是差值。

差多少不是固定值，而是跟假期的分布有关。一段跨过春节的周期，工作日比自然日少很多，两边差距最大。一段全都落在平季的周期，两边可能只差一两天。所以不能记一个固定倍数到处套用，只能按区间分别去看。把某个区间的倍数当成通用系数，是最典型的误用。

选择哪一种基准，通常由站点的处理节奏决定。处理动作只在工作日发生的，按工作日算更贴近实际。处理动作全天候都在跑的，按自然日算就不会失真。判断依据是流程本身，不是习惯，也不是同行怎么算。照别人的选择去选，等于把别人的流程假设搬进了自己的账里。

有一类错误是把两套基准前后串起来用。前段按自然日数，后段按工作日数，中间没有做换算。串起来的结果两头单独看都对，合起来却错。这种错最难被发现，因为每一步看上去都合规。只有在拿它和实际到账日对照时，偏差才会露出来。

换算的时候要小心方向问题，来回换算并不对称。从工作日换成自然日，通常要往上加点天数。从自然日换成工作日，通常要往下减点天数。加和减的幅度不一样，不能简单用同一个系数来回套。套着套着，误差会被放大到看不出原始口径。

节假日还要分两种，它们的处理方式完全不同。一种是全国统一的固定假期，日期每年变但可以提前查到。另一种是临时性的停处理，事前没有任何公开安排。前一种可以写进算法里，后一种只能靠留缓冲来兜。把两种混成一种，缓冲就会给得不够。

不同站点的假期表也不一样，这一处最容易照搬出错。同一个假期在不同市场的放假天数可能不同，有的还分成两段。照搬别处的假期表，会系统性算错一批订单的天数。旺季前后这个偏差最明显，因为假期密度本来就高。连错几批之后，偏差会累积成不好解释的缺口。

按工作日算还有一个细节，是处理动作在假期前后是否顺延。有的顺延到下一个工作日，有的照常进行。顺延的话，天数会往后多几天，多几天还跟假期长度挂钩。这一步不确认，天数会稳定地偏短，方向一直不变。稳定偏短比随机偏差更危险，因为它看起来像规律。

什么样的订单受日历影响最大，其实可以提前挑出来。一类是节前成交、假期结束后才被处理的订单。另一类是本来就卡在周末两侧的订单。这两种订单在两套基准下的差距，往往比平均值大得多。把它们挑出来单独看，问题会比看全量清楚得多。

实际做法通常是先选定一种基准，然后全程只用这一种。再在算出的结果上加一段缓冲，用来覆盖非工作日。这样做的好处是算法简单，坏处是缓冲必须给得够。缓冲不够的时候，账面上的日期会显得太乐观。乐观的日期比晚一点知道更麻烦，因为它会误导排期。

缓冲给多少可以按历史数据回头算，不必凭感觉。把过去几个月的实际到账日和推算日摆在一起。差值的中位数就能当参考值。不用追求精确，能挡住常见的偏差就够了。给过头会让计划太紧，给太少又频繁失准。

有一个反直觉的现象，按工作日算天数更多，但落点更集中。原因是处理动作集中在工作日，日期天然会向工作日聚拢。这一点对安排付款节点有好处，因为可预测性更高。天数长的方案不一定更差，要看它的分布是什么形状。分布集中本身就是一种价值。

知虾公开页面的站点规则对照表里，各市场的时间规则是分开列的。数据按日更新到前一交易日。把两套基准下的差别和自己手里的记录摆在一起看，能判断该按哪一种来定。对照只做参照，不给结论。用它发现问题可以，用它代替判断不行。

还有一类情形两种基准都适用不了，就是跨时区的订单。订单在一地成交，处理在另一地进行，两边的日历对不齐。这类订单通常要单独定一条规则，不能塞进主口径里。塞进去之后，主口径的天数会忽然多出一块说不清的部分。单独成条，反而更容易解释。

选自然日还是工作日，说到底是在准确和简单之间做取舍。工作日更贴近流程，自然日更好算。选完之后坚持用一种，比反复比较哪种更准更重要。换来换去的结果是两种都不准，而且历史数据也失去了可比性。取舍的意义在于选定，不在于选对。

同一批订单换一个起算方式，天数就会整体平移，越靠后的起点天数越短，但资金到手的时点未必更早。

不同站点的起算口径不一样，别照搬

同一套规则在不同站点落下来的结果经常不同。原因不复杂，各市场的处理节奏、假期安排、物流时效都不一样。照搬别处的算法，差出来的那几天就是这么来的。更麻烦的是偏差方向稳定，不像随机抖动那样会自己摊平。稳定偏差会持续累积，越往后越难解释。

站点之间的差别首先体现在起点的选择上。有的站点从确认那一刻起算，有的从物流回传完成起算。同一笔订单在两个站点对应两个不同的起点。把两个站点的天数直接比较，本身就没有可比性。要比也得先换算到同一个起点上，再比。

差别还体现在天数的表述方式上，这一处最容易被忽略。有的站点用自然日表述，有的用工作日表述。还有的用营业日表述，和工作日接近但不完全等同。三种表述在遇到半休的日子时处理方式不同。放在一起看很容易串，串了之后换算就全错了。

物流时效的差异会直接传导到口径上。直发市场签收快，签收日和成交日离得近。转运市场签收慢，起点往前挪对天数的影响就不一样。所以即使两个站点的规则文字完全相同，实际天数也会分岔。规则相同不等于结果相同，这一点在跨站比较时最容易被忘掉。

有一种做法是拿表现突出的站点做基准，让其他站点向它靠。这在管理上说得通，在算法上却容易出错。因为拉不动的是当地日历和物流，不是谁的态度。强行统一只会让推算普遍偏乐观，而且偏的方向都在同一边。统一的应该是记录格式，不是算法本身。

更可行的做法是每个站点各定一套，但共用同一个记录格式。格式统一之后，站点之间的横向比较才有基础。比较的应该是经过换算的结果，而不是原始天数。原始天数本来就不可比，拿来横向拉平只会制造假象。先分清哪些量能比，再动手比较。

站点差异还会随时间变化，规则表上看不出来。某地新设了一批处理班次，原本按工作日算的地方可能接近自然日节奏。规则文字没变，实际天数变了。只盯着规则表，看不到这种变化。只能靠定期回看实际到账日，才能发现节奏已经挪位。

跨站点经营最常见的麻烦就在这里。一个口径在本地被反复验证过，拿到别处却不成立。验证过的经验会让人更放心地用，错误也更容易被复制。等到发现时，已经有好几个站点的数据都按同一套错的算法记了很久。跨站之前重新定一次，比沿用的成本低得多。

还有一种差别在于起算日和结算批次的衔接方式。有的站点起算日当天就进批次，有的要等下一个批次开启。这会让实际天数在一个批次周期内波动。这一段属于流程规则，这里只点出它会放大站点差异。知道有这一层，解释偏差时就多一个方向可查。

判断该不该为某个站点单独定口径，有个简单的标准。如果按统一口径算出来的日期，实际偏差长期偏向同一个方向，就该单独定。如果是随机偏差，多半是数据记录的问题，不是口径的问题。分清这两类，才能决定是改算法还是改记录。改错了地方，等于白改。

单独定口径的成本主要在维护，不在初次设定。每多一套，就多一条需要跟着规则变化更新的线。所以能合并的尽量合并，只在偏差方向稳定的时候才拆分。拆分之后要标明它是从哪一天起单独适用的。不标日期，将来没人能解释为什么这里和别人不一样。

把各站点的口径放在一张表里，比放在各自的文档里好。放在一起才能看出哪些站点的起点相同、哪些的日历基准不同。分散存放的时候，重复和冲突很难被发现。发现不了，就谈不上修正。一张表虽然挤一点，但它能省掉很多来回核对。

翻到知虾公开页面的定价计算，各站点的口径是并列摆出。数据按日更新到前一交易日。把它当作横向对照的底稿，可以确认自己对某个站点的理解是否偏离通常做法。偏离本身不一定是错，但值得查一下原因。多数偏离的背后，都有一处口径没对齐。

站点口径的调整往往有一个触发点，不会无缘无故失效。比如物流合作方换了，或者当地假期安排改了。抓住这些触发点定期重定，比按固定周期重定更有效。因为真正让口径失效的，是这些结构性的变化。定期重定只能挡住时间，挡不住结构。

把站点放在一起看，结论通常不是哪一个更准。而是哪一套更适合当地的处理节奏。适合与否要看节奏，不是看算法简不简洁。简洁的算法用在错的节奏上，误差只会更稳定地出现。稳定出现的误差，比偶然出现的更难处理。

把节假日算进去，是这一处最常犯的毛病

节假日这件事，出错的方式很集中，就两种。要么整段时间忘了扣，要么把不该扣的日子也扣掉。两种情况都会让推算出的日期偏移，而且偏移方向正好相反。混在一起看，表现就是天数有时偏长有时偏短。这种混乱让人很难判断究竟哪一步出了问题。

忘掉扣的原因，通常是算法里根本没有日历这一项。起点和天数都算对了，中间一段假期却被完整算进了处理时间。结果就是推算日期比实际晚，晚的幅度正好等于假期长度。这个幅度很规律，规律到容易被误认为是一种正常现象。它不正常，它只是漏了一项。

把不该扣的也扣掉，问题出在假期表用错了位置。假期表是按处理安排来的，不是按成交来的。成交本身不休息，所以扣假期的位置应该落在处理段而不是整段。位置放错，天数就会偏短，而且偏短的方向也是稳定的。同一个错误位置，会一直重复出现。

还有一种更隐蔽的情况，是假期表更新滞后。当地的假期安排调整了，算法里还是旧的。这种错在单个月份里完全看不出来，因为它和过去几年的表现一致。跨年比较的时候才会显出系统性的偏移。定期核对假期表，是为了堵住这一处。

节假日之外还有一类日子容易被忽略，就是当地的调休日。调休把工作日变成休息日，或者把休息日变成工作日。这一来一回，工作日总数就变了。只看固定假期表，算不出这个变化。算不出，天数就永远差着一点。

有些市场的假期不是全国统一的，而是分地区安排。同一个站点下，不同区域的订单假期安排不一样。这种情况下用一张统一的假期表，偏差几乎躲不开。可行做法是按区域拆开算，或者统一按最保守的那个安排来。两种都不完美，但都比混着用清楚。

假期对起点的影响和对中间段的影响不是一回事。如果起点当天正好是假期，起点通常顺延到下一个可处理的日子。如果假期落在中间，天数会整体加长。两处的处理规则不同，不能合并成一条。合并之后，两种情形里至少有一种会被算错。

大促期间的日历比平时更乱，而且乱法不一样。处理量激增，原本一个工作日能完成的动作可能需要更久。这时候按标准日历算出来的天数会偏短。偏差的原因不是假期，而是处理能力被占满。这一段要单独给缓冲，不能用平季的经验去推。

判断自己有没有犯这个毛病，有个直接的办法。挑一批同期成交的订单，看推算日期和实际到账日的差值分布。如果差值集中在某个固定天数上，多半是假期表的问题。如果差值散开，问题可能出在别的地方。分布的形状比平均值更有说明力。

处理办法不复杂，就是把日历明确写进口径里。起点落在哪一天，中间经过哪几个非工作日，逐段加总。写清楚之后，算法会变长一点，但争议会少很多。因为谁都能按同一张日历复核，不用再靠记忆。能被复核的算法，才可能被执行一致。

写日历的时候要标明版本，这一步经常被省掉。同一个市场的假期安排可能在年中调整。只有标了版本，才能解释为什么两个时期算出来不一样。没有版本号的日历，等于没有日历，因为它无法追溯。追溯不了的历史数据，用起来处处要打问号。

过度扣减也是问题，而且是一种反向的错。有人为了保守，把所有可能休息的日子都扣掉。结果天数被拉得很长，长到无法安排任何节点。这种做法会让推算彻底失去参考价值。保守要有上限，超过上限就不是保守，是无效。

知虾公开页面的站点分析一栏把各市场的时间节奏做了并列展示。数据按日更新到前一交易日。把这种节奏和自己手里的假期表对照，能发现哪些日子被自己错误地当成了处理日。差在哪几天可以定位得很具体。定位到具体哪天，改起来就是几行的事。

一个务实的做法是给日历留一层缓冲，而不是追求每天都算准。缓冲可以吸收假期表的误差，也能吸收临时性的调整。缓冲的比例按自己历史的偏差来定，不要凭感觉给。给缓冲的成本，比每次失准后返工的成本低。这一层缓冲，本质上是在给不确定性定价。

节假日这一处最容易犯，恰恰因为它看起来最简单。加一张日历表就能解决的事，很多算法里偏偏就是缺着。缺的不是知识，是承认日历属于口径的一部分。承认了，这一处就不再是毛病。不肯承认，它会在每一期账上重复出现。

同一段周期换套算法，天数差多少

同一批订单，换一个起点，天数会整体平移。平移的方向很明确，起点越靠后，天数越短。但天数短不等于资金到手更早。因为起点晚意味着前面那段时间本来就已经走完了。把两件事混起来看，很容易得出一个反着的结论。

换一套日历基准，天数会按区间里的非工作日多少而变。假期密集的区间差得最多，平季差得最少。同一个换法在不同月份的结果完全不同。所以不能用一次换算的结果，去推全年的情况。真要推，也得按月份分别系数。

两种换法叠加起来，天数差可以很大。起点往前挪一段，日历基准换成工作日，两处一起动，天数能翻倍。这也是为什么两个团队各算一遍，得出的日期能差出半个月。差得多的时候，双方往往都以为自己是对的。因为各自的算法内部都是自洽的。

判断差得对不对，要看两个算法的起点是不是同一个动作。如果两个起点对应不同的业务动作，天数差多少都不奇怪。这种情况下比较天数没有意义，应当比较的是实际到账日。到账日才是两边能对齐的那个事实。其他的都是各自算法里的中间量。

有一种看起来等价其实不等价的换法，很容易被接受。把起点从成交日换成发货日，同时把中间的发货时长也扣掉。表面上天数缩短了，实际上口径变了两次。变两次之后，结果既不能和原来的比，也不能和别处的比。它落在一个只有它自己的位置上。

真正的换算应该只动一个变量，一次只改一处。要么只动起点，要么只动日历基准。这样差值才能被归因，出了问题也知道往哪里查。同时动两个，差值就成了一笔糊涂账。糊涂账没法解释，也没法传递给别人。

换算之后的数值要不要用，取决于两个算法覆盖同一批订单没有。起点选成交日的算法覆盖所有订单，起点选签收日的算法覆盖不了还没签收的。覆盖范围不同，两个数直接并列比较就是错的。要先对齐覆盖范围，再比数值。顺序颠倒，比出来的都是假的差异。

天数差还有一个不太显眼的来源，就是首日是否计入。有的算法从起点当天起算，有的从次日起算。只差一天，但如果两套算法在这上面不同，差值里就混进了这一天。核对的时候要把这一项单独拉出来看。不拉出来，它就会混在别的差异里难以分辨。

如果换算法的目的是比较两种处理方式的优劣，那要固定其他条件。同一批订单、同一段日历、同一个首日约定，只改起点。这样才能看出起点选择本身值多少天。条件不固定，比出来的是混乱，不是差异。比差异需要先控制住其他变量。

差多少天可以用历史数据估，不必依赖理论推算。把同一批订单按两套算法各算一遍。差值的中位数，就是这两套算法在典型情况下的差距。极端情况会有更大的差，但它们不该被拿来当普遍结论。用中位数描述常态，用尾部描述风险。

换算法之后建议保留旧值一段时间，不要立刻清掉。旧值可以用来解释历史数据为什么和新值不一致。直接换掉，会让过去的记录看起来像错的。其实它们只是按另一套口径算的，并不算错。留一段重叠期，是给将来省解释成本。

有一类换法是不得不做的，就是平台调整了规则。原来的起点不再成立，只能改。这种情况下最重要的是记下切换日，并在切换日前后各留一段重算区间。不留的话，切换当期的数据会两头不靠。两头不靠的数据，谁都解释不了。

把知虾公开页面的多站点数据拉出来横看时，各市场的天数差异会集中显出来。数据按日更新到前一交易日。这种对照能帮你判断自己两套算法的差值是否落在合理范围里。超出范围的那些，通常有一处口径没对齐。先找对齐问题，再考虑改算法。

换算法本身不可怕，可怕的是换了之后不留痕。一处不留痕，两处不留痕，几轮之后账上就并存着几套互不兼容的数字。那时候再想理清，成本比当时记一笔高得多。留痕的方式很简单，写清切换日和生效范围就够。这两项不写，后面谁都不敢动它。

回到最开始的问题，换一套算法天数差多少，答案是一个区间而不是一个数。区间的宽度取决于两套算法在起点、日历、首日这三处的差异总数。差异越多，区间越宽。差异为零，区间也就收成了一个点。把区间说成一个数，本身就是在掩盖不确定性。

普通现货单的口径最稳，跨境直发单受日历影响最大，大促批量单则常常不能用统一算法。

起算点该重新定，一般是在什么情况发生时

重定起算点通常不是主动的选择，而是被事件推着做的。识别哪些事件值得重定，比记住什么时候该重定更有用。值得重定的事件，往往改变了起点对应的那个动作本身的形态。形态变了，原来的天数推算就不再成立。不成立的东西继续用，只会错得更久。

第一种事件是起点动作的时点整体移动。比如发货确认从人工改成系统自动，动作时点就从白天散开变成了即时。起点时点变了，原有的天数推算就不再成立。这种变动往往在流程里已经发生，只是口径还没跟上。口径落后于流程，是这类问题最典型的样子。

第二种事件是结算类型发生变化，它比流程变动更隐蔽。原来按周期批量处理，改成按订单逐笔处理。起点要求也随之改变。这种变化通常由平台侧公告，容易被当成无关调整放过。等发现天数都对不上，已经过了好几期。

第三种事件是新站点开出来，这一种最容易识别。新市场的日历、物流、处理节奏都是新的，沿用旧口径会持续偏。新站点宜在开始记账之前就把口径定下来，避免中途切换。中途切换的代价是前后数据不能相加。不能相加的数据，等于一段历史白记了。

第四种事件是当地假期安排出现结构性变化。不是每年的例行调整，而是处理班次安排本身变了。这种情况下，旧的假期表即使日期更新过，逻辑也已经不对。需要重新确定哪些日子算处理日。处理日的边界一变，整条算法都要跟着重排。

第五种事件是偏差方向开始稳定，这一种最容易被忍着不管。连续几个周期，实际到账日总是比推算日早或者晚。偶然偏差不需要重定口径，稳定的偏差需要。稳定偏差是口径错的信号，而且比随机偏差更好修。忍着的代价是每一期都要重新解释一遍。

重定之前要先做一次回溯，这一步不能省。拿过去一到两个周期的数据，用新旧两套算法各算一遍。看差值是稳定的还是发散的，它决定了这次是微调还是重来。跳过回溯直接改，很容易改出更差的结果。不知道原来错在哪里，就不知道新算法会不会踩同一个坑。

重定的时点宜落在账期边界上，不要落在中间。落在账期中间，当期的数据会一半按旧口径一半按新口径，看起来像异常。落在边界上，前后可以清楚地切分。切分清楚了，复核的人也不容易误解。账期边界是天然的分界线，用它最省事。

重定之后要同步更新所有引用了口径的地方。常见的问题是主表改了，附加的说明没改，两个版本同时存在。过一段时间，谁也不知道该信哪一个。改动一次就全改一遍，这一条不能打折。打折留下的残余，会在下一次复核时变成争议。

有一种情况不需要重定，就是偏差来自数据记录本身。比如到账日填错了，或者状态回传漏了一次。这类问题修数据就行，动口径反而会把原本正确的地方改错。分清问题出在口径还是出在数据，是重定之前必做的一步。做错这一步，会把小问题改成大问题。

还有一种情况是过渡期，新旧规则会并行一段。这时候要明确说明以哪一套为准，以及过渡期的数据怎么归。含糊处理会让过渡期变成一段谁也不敢引用的空白。宁可写清一段短过渡，也不要长期悬着。悬着的过渡期越长，被误用的机会越多。

重定口径时容易被忽略的是下游影响。口径变了，之前按旧口径定的付款节点和备货计划都要跟着调。只改口径不改计划，口径对了，安排还是错的。改一次就顺着往下捋一遍，成本并不高。不捋的话，错会一直传到最下游。

判断这次重定值不值，有个朴素的尺子。重定后能不能解释过去解释不了的偏差。能不能让未来的推算更稳。两条都做不到，这次重定只是在换一个说法。换说法解决不了口径问题，只会让并存的版本更多，复核成本更高。

口径这件事不需要经常动，但需要经常看。定期看一次实际到账日和推算日的差值，就知道该不该动。等到差值大到影响排期才去看，那时候已经多付了代价。定期看的成本几乎为零，回报是提前发现。提前发现的价值，在于还有时间调整。

定完了还要留一句话，说明它为什么这么定。这句话在下次重定的时候最有用。因为它记录了当时的判断依据，而不是只记了结果。没有依据记录的口径，下次重定时只能重新推一遍。重新推的结论未必和上次一样，而且不一定更好。

两套日历基准起步时接近，越往后差得越多，假期密集的那几批会把差距推得最开。

起算口径讲完，名目不重复列一遍

起算口径讲完，需要交代清楚本文的边界。本篇只回答一件事，天数从哪一天开始数。它不回答钱被哪些名目挂着，也不回答钱在流程里分几段走。这两个问题分别属于前后两篇。读的时候不要互相代入，代入之后两边都读不清。

为什么不在这里重列名目，因为名目是另一条轴上的东西。名目讲的是钱的状态，口径讲的是时间的算法。两者的组织方式不一样，放在一篇里讲，读者会在两个体系之间来回跳。跳来跳去，最后两套概念都会记混。分开讲，两件事都能讲透。

不重列也不代表两者无关，这一点要说清。名目里确实有一些条件会影响起算点的选择。比如某个动作是否需要等到确认才算完成。但这类关联只用到具体那一条，不需要把整张名目表复述一遍。用到哪条说哪条，就够了。

边界划清之后有一个实际的好处，就是口径的结论可以独立检验。如果口径里混进了名目内容，一旦名目表变化，口径的结论就要跟着改。分开之后，名目调整不会影响口径的稳定性。稳定，才让口径有资格被反复引用。被反复引用的口径，价值会随时间增加。

同样地，本篇也不去拆流程分段。钱在流程里走几段，每段停多久，是另一个视角的问题。口径只关心起点，不关心中间有几站。把段落结构搬进来，会把一个单点问题讲成一张流程图。图一出来，起点反而被淹没了。

至于钱最后归在哪一期，本文完全不涉及。归账是周期走完之后的事，和起点不在一处。起点错了会让归账出错，但纠正方式完全不同。一个改算法，一个改归属。两件事混在一起讲，会互相干扰，最后谁也说不清。

有一种提问很常见，就是问起算口径定完之后下一步该做什么。下一步不属于本文要处理的内容。本文只负责把起点定清楚，让后面的事有一个明确基准。基准的作用是让后续判断可比，不是直接给出动作。它提供的是尺子，不是结论。

口径的实用价值体现在相邻两期的对比上。起点稳定，两个周期的天数就可以直接相减，差值有意义。起点不稳定，相减得到的是一个混合量，读不出任何东西。稳定本身，就是口径能提供的主要价值。它不制造信息，它让已有的信息变得可比。

口径还有一个容易被忽略的用途，是让讨论有共同的参照。两人讨论回款快慢时，如果起点不同，讨论永远无法收敛。先统一起点，再讨论快慢，几句话就能有结论。统一口径的价值，很多时候就体现在这类沟通上。省下的不是计算时间，是来回解释的时间。

如果确实需要把口径和别的层放在一起看，建议先各自算完再并列。先在各自体系里得出结果，再把两个结果摆在一起比较。这个顺序能避免一个体系的概念污染另一个体系的算法。污染之后再清洗，成本比一开始就分开高得多。顺序本身就是一种成本控制。

口径的失效通常也是独立失效的，和别的层不同步。日历变了、规则变了，口径跟着变。名目不会因此变，流程分段也不会因此变。这种独立性说明，把口径单独成篇是有道理的。它不是人为切分，而是本来就分开的两件事。

判断口径有没有定好，可以用一个简单的方法。把定好的规则交给另一个人，让他按规则复述一遍。他能说清起点、日历和适用范围，口径就算定住了。说不清，说明还有隐含的假设没被写出来。写不出来的假设，别人永远猜不到。

隐含假设是口径最常见的隐患，也是最容易被忽略的一种。它平时不显形，只在别人接手或者自己隔了几个月回看时才暴露。把假设写出来，成本很低。收益会在之后每一次复核上兑现。写假设比写结论更值得花时间。

最后把本文的范围合上。本文回答的是起算点怎么从候选动作里筛出来、自然日和工作日怎么选。也回答了站点之间为什么不能照搬、节假日为什么最容易出错。还回答了换算法天数会差多少、什么时候该重定。名目怎么分，钱走几段，归在哪一期，都不在这里。

口径这一层看上去只是一天两天的差别。累积起来就是可预测和不可预测的差别。起点定住了，后面每一步才有可复核的依据。定不住，后面的数字再精细也只是自洽的假象。自洽而不落地的数字，看久了会让人失去对真实节奏的判断。

常见问题（FAQ）