一个点位一年换过几个客户，销售和媒介各有各的版本
户外媒体和本地广告的资源很具体：商圈大牌、社区灯箱、候车亭、电梯框架、道闸、LED 屏。这些点位的生意，本质是把一段时间卖出去——同一个位置，三月卖给这家，六月卖给那家，中间还要留几天换画。
麻烦也就从这里长出来：
- 一个点位同一时间被卖了两家。销售甲说三月的档期已经签给客户了，销售乙从表里看还是「可售」，第二次签约才发现重了，只能赔档期或临时换点位。
- 哪天上刊、哪天到期，答案在微信群里。客户问「我那块牌子挂了几天了」，媒介执行要翻聊天记录找当时的安装照片；到期没下刊，客户还要再算钱，这也是纠纷。
- 到期没人提醒。档期结束日散在合同、Excel、备忘录里，等到客户投诉「画面还挂着别人的广告」，才发现上一家没下刊。
- 上刊有没有真的上，没有凭据。安装师傅说挂了，客户说没看到，谁也不服。照片在师傅手机里，三个月后连手机都换了。
- 画稿版本对不上。客户改到第三稿，安装用的是第二稿；审稿（内容合规、敏感词、行业限制）过没过，只在某个人的微信里说过一句「可以了」。
- 刊例价与成交价两张皮。点位标准价、给不同客户的折扣、赠送档期，越到月底越说不清，对账时得先猜口径。
- 空置看不出来。哪些点位这个月空着、哪些被长期低价占着，没有一张能看的清单，谈新客户时手里没有底价依据。
这些问题的同一个根子：点位的「占用」是一段有起止日期的档期，把它当成人表里的一个字段（「当前客户」「当前画面」），历史就查不到，冲突也拦不住。 再往下一层，是三个东西没有分开记：点位（长期存在的资源）、档期（一段时间的占用）、执行（上刊下刊这些动作）。混在一张表里，谁改一次就丢一次历史。
这正是 Inkwell AI 构建器能交付的部分：不需要买一套行业专用软件，先把点位、档期、执行三张底表搭起来，PC 端给销售和媒介用，手机端给现场安装师傅用，很快就能跑通第一版。整体思路可以看 AI 构建器 的能力说明。
数据怎么建：点位是资源，档期是占用，执行是动作
用 AI 构建器搭模块，第一步不是画页面，而是把数据描述清楚——用日常语言说明白「点位有哪些信息、档期怎么记、上刊下刊怎么留痕」，它会生成对应的数据表和页面，再在页面上微调字段即可。下面是这套方案最小可用的一套表，也是落地时最值得先定死的部分。
一、点位主档：一个点位一行，编号唯一
主档只放「这个点位本身是什么」：
- 点位编号，设唯一约束。建议用「城市-媒体类型-流水」，比如
QD-DP-0142。这个编号是全系统认点位的唯一凭据——排期、上刊、验收、对账都靠它，现场师傅报编号就能定位，不要用「XX 商场那块大牌子」这种描述当主键。 - 名称与位置：商圈/路段、建筑或社区名称、楼层与朝向、可视方向。
- 媒体类型：大牌 / 灯箱 / 候车亭 / 电梯框架 / 道闸 / LED 屏 / 其他（走数据字典，别让人自由填，否则同一类多媒体会分裂成十来种写法）。
- 规格：宽 × 高，面积让表单自动算，画稿尺寸要求由此得出。
- 是否可售、可售起始日、维护停用原因。有点位会因施工、拆改、产权方调整而停售，这个状态必须能标出来，否则销售会一直拿它报价。
- 标准刊例价口径：按周 / 按月 / 按季计价，以及是否含制作、是否含上刊服务。这里只存定价口径与标准价，金额由企业按自己的价格体系维护，本模块不做任何价格判断。
- 点位来源：自有 / 代理 / 合作分成，以及合作方名称。这决定了后面成本与分成怎么归集。
- 现场照片：全景一张、周边环境一张，新销售接手时不用再跑一趟。
两个刻意不放进主档的东西：
- 不放「当前客户」「当前画面」「本档期结束日」。它们是档期的结果，塞进主档必然要和档期打架，还得靠人两处手改。
- 不放「已收金额」。钱在合同与开票侧记一次，主档再记一份就会重复计数。
关于点位牌体这类实物本身（自有大牌、灯箱的结构与折旧），属于固定资产的账，建议走 固定资产台账，本模块只管「这块牌子的档期卖给了谁」，两边靠点位编号对应，不合并成一张表。
二、客户与合同的分工：本模块不自建一套客户账
排期单要写客户名，但客户档案不该在这里重复建一遍：
- 客户档案引用现成的客户管理模块（平台的引用机制是一种软外键，可以在本模块直接选另一个模块的客户数据，档案改名这边跟着变），见 客户管理。
- 客户签的广告发布合同（起止、总金额、付款节点、违约条款）走合同台账，见 合同台账与到期预警。本模块的排期单只记这一单要执行哪些点位、哪段时间，合同总额以合同为准，不在排期单上再记一遍——同一笔钱记两处，对账时永远差一个数。
这条分工要在上线前和财务讲清楚，否则会出现「合同一份金额、排期单一份金额、开票又一份金额」的三本账。
三、排期单主表：一次销售一单
一张排期单代表一次对客户的销售行为，一行记一次：
- 单号（唯一，建议「日期+流水」）、客户、签约人/销售、下单日期、合同编号（可选引用）。
- 档期起止：整单的最早起日与最晚止日，由明细行汇总得出，不手填。
- 状态：待确认 → 已签约 → 待上刊 → 在刊 → 待下刊 → 已下刊 → 已结算（异常走「已取消／已挂起」）。状态用数据字典集中维护，一处改动全站生效，避免「已完成」「完成了」并存导致清单筛不干净。
- 本单金额：只记这一单成交的合计，明细行一行行算出来由规则汇总，不让人手填。
- 不上主表的东西：已收款、已开票金额。它们在收款与开票记录里，见 开票申请与发票台账。
四、排期明细行：点位 × 时段，一行一记
这是整套方案的核心表，也是最容易建错的一张：
- 每行：排期单号、点位编号、起日、止日、档期类型（正常档期 / 赠刊 / 换画期 / 预留）、刊例价、成交单价、折扣原因、画面版本号、备注。
- 一行只表示一次占用。同一个点位卖给同一个客户的连续三个月，可以一行（起止跨三个月），也可以三行（按月），但口径上线前要统一定死——否则月度统计会重复计数。
- 只增不改。续刊另起一行、换点位另起一行，旧行保留。客户问「去年这块牌子什么时候是我们的」，答案就在历史行里。
- 时段重叠靠规则拦，不靠人看。同一时间段的两次占用，用数据库唯一约束表达不出来（起止是区间，不是单值），所以由数据流规则在保存时比对同一点位的起止日期：有重叠就拦截提交并提示冲突的档期行。这一条是本模块最有价值的一个自动化——它把「签重了」从事后扯皮变成事前报错。
- 软冲突只提示不拦截：同一客户同一天多个点位上刊是正常业务，不拦；同一点位相邻档期之间没有留换画缓冲期，可以提示执行方确认，避免日子卡死。
五、上下刊执行记录：一个动作一行，只增不改
档期说「这段日子该挂着」，执行记录说「到底哪天挂上、哪天下掉」。这张表是给现场师傅和客户验收用的：
- 每行：点位编号、关联排期明细行、动作类型（上刊 / 下刊 / 换画 / 维护）、实际执行日期、执行人、操作开始与结束时间、画面版本号、实拍照片（走平台的文件上传，画面上传原图，不压缩到看不见档期内容）、客户验收人、异常说明。
- 照片挂在执行行上，不挂主表。一张排期单可能涉及二十个点位，主表挂一堆照片谁也说不清哪张对应哪块牌子；挂在执行行上，就能按点位、按档期反查。
- 上刊与下刊是两行，不是一行的两个字段。一行的两个字段意味着「还没下刊」只能靠留空表示，一旦下刊时间改过一次就丢了原值；两行则天然表示「已上未下」，做超期清单时直接查「有上刊行、无下刊行」的档期。
- 异常单独留痕：点位被遮挡、被城管拆改、产权方临时占用、画面破损需要加急重做——这些都不改原上刊行，另起一行记异常，写清处理方式。以后再遇到同一块牌子的老问题，翻历史就能看到。
六、画面版本与确认：一稿一行
上刊用的是哪一稿、客户有没有书面认可、内部合规审没审过，这三件事必须能答：
- 每稿一行：画稿文件、版本号（V1、V2…）、提交日期、客户确认人及确认时间、内部审核结论（通过/修改/退回）、退回原因、审核人。
- 旧版本不覆盖。客户改到第三稿说「还是按第一稿做」，第一稿的文件和确认记录必须还在，所以这张表只允许新增行。
- 上刊行引用版本号。这样客户投诉「挂的不是我确认的那稿」时，能直接对上是哪一版、谁传的、谁确认的。
- 需要走审批的场景（大客户减免、内容敏感的行业客户）用平台的审批流处理，审批通过后再由上刊行引用，不靠微信里一句「可以了」。
七、到期提醒与超期清单：定时任务算出来，不另建提醒表
- 到期清单：定时任务按日扫描排期明细，把「止日还有 N 天」的档期推给销售与媒介执行，N 由企业按自己的销售节奏定（提前联系续刊的时间点各家公司不一样）。到期未下刊的单独进一张超期占用清单，按点位和客户列出来，谁都能看。
- 空置清单：按点位主档与档期明细做差，得出「某段时间没有任何档期」的点位，这是谈新客户时的现货清单，也顺带暴露长期低价占位的点位。
- 不建中间提醒表。提醒只是定时任务查出来的清单，建一张提醒表就要人去维护它的状态，最后清单和事实对不上。定时任务怎么配、执行记录怎么看，见 工作流与定时任务。
八、钱算在哪一层：一处一义
广告排期的金额容易冒出好几份，这套方案的分工是：
- 合同层记与客户约定的总额与付款节点（在合同台账里）。
- 排期单记本次执行的成交额，由明细行（点位 × 时段 × 成交单价）汇总得出。
- 赠刊与折扣在明细行的折扣原因里写清，不删掉金额只留 0——「送了两周」这件事本身要留痕，否则续刊谈判时没有依据。
- 实收与开票走财务侧记录与开票台账，回填到排期单只作为状态依据，不影响明细金额。
- 点位采购成本（代理点位的租金或分成）按点位 × 期间单独记，不混进销售收入里，否则毛利永远是猜的；取数来源是点位来源字段与采购/合作记录，没有这两项基础数据的话，先别急着算毛利。
一句话：同一笔钱只记一次，其他位置引用来引用去，不复制。
页面怎么用：每个角色只看他要做决定的那一屏
底表建好之后，页面不是「把表铺出来」，而是按人分工。这套方案建议四类页面：
销售：点位列表 + 排期单
- 点位列表：按媒体类型、区域、可售状态筛选，一眼看到哪些点位现在空着、标准价口径是什么、上一次是哪个客户在刊。谈客户时这一屏就是底牌。
- 排期单：新建时选客户、选点位、填档期起止，成交价与折扣原因一并填。保存时如果撞上别人的档期，系统当场报错并指出冲突行——这是「签重了」唯一有效的防线。
- 只读与可写要分开：销售能建排期单，不能改上刊执行记录（那是媒介执行的事实）。
媒介执行：上下刊执行页
- 按「今日待上刊／今日待下刊」列出今天要干的活，每行点位编号、位置、规格、画面版本、客户验收人。
- 执行完就地填实际日期、上传实拍照片、勾验收。手机端是这一屏的主战场（见下）。
- 异常（点位不可用、画面损坏）在这一屏直接登记，不回到 PC 补。
财务与客户执行：对账视图
- 按客户、按期间、按点位三种口径核对：这个月哪些点位在刊、哪些是赠刊、哪些报损需要折让。
- 与合同、开票两份记录对账，差异必须写原因再提交，不能只把数字改对。
管理者：在刊与空置
- 在刊率（有档期占用的点位 / 可售点位）与空置清单、超期占用清单，按媒体类型和区域拆开看。
- 这一屏不追求花哨图表，先要能回答两个问题：哪块牌子在空着、哪块牌子该下没下。
权限按角色分，点位与排期是一类、执行记录是一类、金额字段建议单独收敛——不是所有能看排期的人都需要看成交价。角色怎么配见 角色与权限配置。
四类自动化，把重复核对交给系统
- 数据流规则（保存时校验与联动）：同一点位档期重叠拦截、排期单金额由明细汇总、档期结束自动把状态推进到「待下刊」、下刊行填完后回写排期明细的完成状态。这些都在保存时执行，PC、手机、Excel 导入三个入口同一套口径，不靠人记得检查。
- 审批流：折扣超出自定范围、赠刊档期、占用超过某个长度的排期走审批。阈值由企业按自己的管理权限定，不自带默认值。
- 定时任务：每日扫描到期档期生成待下刊清单、每周生成空置清单、月末汇总在刊率。执行日志可查，谁改过规则也有记录。
- 站内通知：把待上刊/待下刊/超期占用推给对应的人，手机端也能收到。通知是提醒，不是承诺——真正拦住的还是保存时那条校验。
移动端：现场那一步必须在手机上完成
上下刊这件事发生在楼顶、路口和商场后场，让师傅回办公室补录，等于没录。手机端的配合方式：
- 师傅登录后在待办里看到今天的上下刊任务，点开就是点位编号、位置描述、规格、画面版本。
- 完成任务时当场拍照上传，填写实际时间与异常说明，签收人姓名留档。
- 拍照上传的照片按点位与档期归档，客户来查「某块牌子哪天换的画」，直接按点位编号搜。
- 网络不好时先拍下来、有信号再提交，实际发生时间与录入时间分开填——两个时间不一致不影响记录有效性，但必须如实填，事后补录的行要能看出来。
- 这里不承诺「离线自动同步」这类能力；现场实在无信号，允许先纸质登记，回到有信号处补录，补录时勾选「事后补录」并写明实际发生时间。手机端能做什么、怎么装、怎么用，见 移动端 与 移动端使用指南。
上线前查这几项
把它当成一张验收清单，一项项过：
- 点位编号是否全部唯一，并且现场人员认这个编号（贴牌、印在点位卡上）。
- 点位状态字典一次定死：可售 / 在刊 / 预留 / 维护停用 / 自用，五态够了，别边用边加。
- 期初数据要导入完整的「当前在刊」：正在刊的档期（含起日、止日、画面版本、当前客户）必须先进系统，只建点位档案不建在刊档期，系统上线第一天所有点位都显示「可售」，销售会立刻签重。
- 冲突校验规则先在测试环境跑一遍：拿两条重叠的档期试保存，确认真的被拦住，而不是只弹个提示。
- 必填字段定死：点位编号、档期起止、客户、画面上刊版本、执行人。留太多可空字段，三个月后表单里全是空白。
- 权限与字段可见性：成交价、折扣原因这些字段谁能看，上线前定，别上线后一层层往回收。
- 发布走预检：模块先在测试环境试跑，用平台的预检功能过一遍再正式发布、挂菜单、同步到手机端，步骤见 模块的测试与发布。
之后怎么延伸
这套底表搭起来之后，能顺着业务继续长：
- 上刊前的画面制作：画稿从设计到印刷、喷绘、安装材料，走 广告制作与印刷订单——那边管一单成品的工序与打样，这边管点位档期与上刊执行，两者用排期单号串起来，不合并成一套。
- 点位采购与合作分成：代理点位按期间记成本，与在刊收入对照，算出每个点位的实际贡献。
- 客户续刊与信用：把历史在刊档期与客户的合同、回款放在一起看，续刊谈判时有据可依。
- 多城市扩展：点位编号分段、区域维度加一层组织，同一套模块复制到新城市，不用重写。
这套方案的边界：它不做什么
写清楚不做什么，比承诺什么更重要：
- 不做广告效果监测。曝光量、人流量、屏幕播放次数这类数据来自第三方监测或硬件设备，本模块只记录「挂了多久、挂的是哪一稿」，不做效果归因，也不对接监测平台。
- 不做画面内容自动识别。画面合规靠内部审核记录留痕（谁审的、结论是什么），平台不做图像内容判别。
- 不做广告位自动排布或档期优化算法。哪个客户该配哪个点位、怎么排能提高在刊率，是人的判断；系统只保证你看到的是真实占用情况。
- 不对接产权方或代理方的系统。点位来源与合同在系统里登记，外部系统的实时状态不在本模块范围内。
- 不做线上投放。这里是线下媒体点位的排期台账，不是竞价投放平台。
- 不承诺收入增长或上刊率提升的具体幅度。这套东西的价值在于「查得到、拦得住、对得上」：档期查得到、冲突拦得住、合同与执行对得上。
如果贵司同时管着制作端的订单与点位端的档期，建议两边各建一个模块、靠单据号互链，而不是塞进同一套表——生命周期不同的东西合在一起，最后一定会被拆开。