旅行社团期与地接结算：报名、行程节点与团费对账

一个团的账，为什么总在微信群里对不清

做旅行社的都熟悉这样的场面:一个 30 人的团要出发了,报名名单散在三个地方——门店收的现金记在小票本上,线上渠道的订单在另一个后台,老客户微信直接转的定金在导游手机里。人数在出发前一周还会变:有人加、有人退、有人临时改双人间。而机票、房间、大巴车位是按最初报价订的,谁改了什么、几时改的,没人说得清。

回团之后进入算账阶段,问题更集中:

• 地接社报来一张总额,报价单还在上一季的微信对话里,想核也翻不到;
• 导游垫付的门票、餐费、临时打车,靠拍照发群,月底对不上是哪一笔没报;
• 客人在群里问「说好的古城夜游怎么没走」,当时是航班延误还是导游漏排,没有记录可以举证;
• 老板想知道这个团到底赚了多少,得把报名表、地接账单、导游垫付三样拼起来算,拼一次要半天。

这类问题看起来是「表格不够用」,实际上是三件本来不同性质的事被混在一起记了:团的计划(这一团哪天走、几个人、走哪条线)、团的成员(谁报了名、交了多少、占不占床)、团的实际发生(几点落地、几点入店、临时加了什么、地接怎么结)。三者混在一张表里,任何一个变动都会把另外两个搅乱:人数一改,金额被覆盖;金额一改,历史报名看不到了。

Inkwell AI 构建器的做法是把这三件事拆成三张表,再用引用关系串起来。整套东西不需要写代码,用一句话需求描述清楚给 AI 构建器,它在沙箱里生成模块、你在页面上继续调整字段与流程,发布后 PC 与手机端同时可用。

建模第一步:团期主表,一团一行

团期是整个业务的主档。一个「9 月 18 日云南六日游」就是一个团期,一条记录。

主表建议的字段:

• 团号:系统内唯一的编码,建议规则如「线路代码+出发日」,设成唯一约束——同一团被两个渠道各建一次档案,是最常见的重复数据来源;
• 线路产品:这团走哪条线,如果线路体系复杂,可以单独建一个「线路产品」小台账做引用,不要在主表里自由填文字,否则同一线路会被写成七八种叫法,后面按线路统计就废了;
• 出发日 / 返程日:两个独立日期字段,不要用一个「行程周期」文本;
• 计划人数 / 实收人数:计划人数是排车订房用的,实收人数不手填,由报名明细汇总出来。这一条很关键——人数如果由人手工填,系统和实际永远差一步;
• 集合地与集合时间:导游与客人看的都是这两个值;
• 领队 / 内部负责人:人员从组织架构里选,不要自由填名字;
• 地接社:引用供应商档案,不填文字;
• 状态:收客中、已成团、已出发、已回团、已结算、已取消——选项走数据字典统一维护(做法见数据字典:管好下拉选项的统一口径),不要在每个页面各写一套,否则「已出发」和「在途中」同时存在,统计永远筛不全;
• 备注:只放对整团生效的说明,比如「本团含两晚民宿」。

主表不要存这些字段:团费合计、已收金额、已付地接款、毛利。这四个数都是汇总结果,一旦落成字段,就会和明细打架:报名有人退团,主表金额没同步;地接款分两次付,已付金额被后一次覆盖。正确做法是让主表只回答「这一团是什么、走到哪一步」,钱和人都从明细表汇总出来看。

报名明细:一人一行,退团不删行

报名明细挂在团期下面,一位客人一条记录。这是全系统出入最大的表,字段要一次设计到位。

几条实务决定:

1. 退团不删行。状态改为「已取消」,退款另起退款记录并写原因。删行会让「这团原本报了几个人、为什么最后少了两个」变成永远查不到的事,地接社来对账时也无从解释。
2. 儿童与占床分开记。房费按「房间数×床位」算,人数算不清房间,占床与否必须单独一个字段,不然后台永远在猜。
3. 渠道不要写成另一个团期。同一线路两个渠道报名,是同一团的明细里的两条不同「报名渠道」,不是两个团。这一点定错,后面所有人数与成本都会被拆成两份。
4. 一人一档可复用。如果客人是回头客,姓名+证件号可以做成客人档案的引用,下次报名直接选人,省去重录。但档案归档案,报名明细里的应收团费必须留在明细行上——价格随团期走,不随人走。

行程节点:计划与实际两列并存,一行一个动作

行程节点子是这套方案里最能防纠纷的一张表。一条记录代表一个动作:集合、出发、落地、入住、用餐、景点、返程、散团,节点类型走字典。

字段建议:所属团期、节点类型、计划时间、实际时间、执行人、异常说明、附件。

两个原则:

• 计划值不覆盖。实际落地晚了两个半小时,实际时间另填,计划时间保留原值。只有两列并存,才能在客人投诉时回答「原计划几点、实际几点、原因是什么」。用一个「实际时间」字段覆盖计划值,是最省事也最没用的做法。
• 异常另起一行。航班延误、酒店降级、临时加景点,都作为一条独立节点记录,写清影响与处理结果。写进备注里等于没写,后面既筛不出来,也没法统计「本季度延误了几团」。

附件直接挂在节点行上:登机牌照片、酒店确认单、客人签字的变更单。挂在节点行而不是团期主表,是因为核对时总是从具体节点开始反查——「这次入店为什么换了酒店」点开节点就能看到当时的确认件。

钱分三层记:团费收入、地接成本、团内杂费

团期赚不赚钱,取决于三层钱各自记清楚、彼此不串。这三层是三个不同的表,不是一个「金额合计」字段能替代的。

第一层:团费收入。 应收团费落在报名明细行上,一位客人一个金额;实际收款用收款记录子表,一次收到一行,记收款时间、金额、收款方式(现金/转账/线上/渠道代收)、经办人、凭证附件。分三次付清的客人就是三行,不做「改金额」操作。退款单独一行,记退款原因与退款方式,不与收款行混在一起。

第二层:地接成本。 一团一张或多张地接结算单。字段:所属团期、地接社(引用供应商档案)、结算周期、报价口径(人均单价/整团包价)、项目明细(住宿、用车、门票、导游服务、餐)、数量与单价、金额。

结算单的金额建议分三列存:报价金额、报审金额、审定金额。地接社报来的数、计调核过的数、财务最终认定的数,三段进程各有依据。很多团队踩过的坑是先只留一个「结算金额」,核完直接覆盖,等到月底发现某团成本比预算高一大截,已经查不到原始报价长什么样了。差异金额非零时,差异原因必填,这一条可以由数据流规则在保存时校验并拦截,不依赖提交人自觉。

第三层:团内杂费。 导游垫付的门票、临时用车、客人医药、小费,统一走垫付报销单:一单一笔或一类一行,记事项、金额、发生日期、票据照片。报销单挂到团期上,审批通过后进入这一团的成本归集。

三层都记好之后,毛利不再是一个需要人填的字段:收入来自报名明细与收款记录,成本来自地接结算单的审定金额与报销单金额,两边的取数口径在建模时就固定下来,汇总出来多少就是多少。这里要提醒一句:如果地接结算还没走完审定,毛利数字就是「未定稿」,页面上应该显式标出这个状态,而不是把一个半成品数字当作结论。

谁能看到什么:四类角色四个页面

系统页面按角色拆,不做成一张大表让所有人自由筛选——权限不是筛出来的,是配出来的(做法见角色与权限配置:从内置角色到自定义授权)。

计调/操作是团期的主要维护人:团期列表(按出发日、状态、线路筛)、报名名单(可批量导入,见下文上线部分)、排房与排车视图(谁跟谁同房、几间双人几间单人)、行程节点计划维护。

导游/领队只需要手机端:今天这一团的行程节点打卡、异常上报、垫付登记与票据拍照上传。他们的页面上不该出现团费金额与地接结算,这是最基础的隔离。

财务看结算单:待审的地接结算、待核的收款、按团期与按地接社两个视角的应付汇总。

管理者看汇总:按月份看各团的收客人数与收入、按线路看成本结构、按报名渠道看转化。这一类视图建议只读,不提供编辑入口。

数据范围也要一起定:导游只能看自己带的团,计调按线路分组看,财务看全量但不可改报名明细。这些都能在角色授权里按模块与数据范围配置,不需要为每个导游单独做一套页面。

三条自动化,把靠人记的事变成系统动作

第一,审批流。地接结算单提交后走「计调核对 → 财务审定」两级;导游垫付报销走「领队确认 → 计调核 → 财务付」。审批节点的搭法见工作流与定时任务:让重复性工作自动跑。审批不通过的退回要写明退回原因,原因字段保留在单据上——这是后续追责与改进的唯一依据。

第二,数据流规则。适合放在这里的校验有:差异金额非零而原因为空时阻止提交;实收人数改为由报名明细汇总,不允许手工覆盖;报名行「已取消」后该行的应收金额不计入团期收入汇总;出发日已过的团期自动改状态为「已出发」,避免靠人手动推进。

第三,定时任务。几条最实用的:

• 出发前固定天数,推送「证件与名单核对」提醒给计调,名单里证件号空缺或有效期早于返程日的行自动列出;
• 回团后固定天数仍未提交地接结算的团期,每天提醒一次责任人;
• 客人证件(护照、港澳通行证)有效期临近到期,提前提醒,方便续办;
• 按月的固定日期,生成上月各团的收入与成本汇总清单,供对账。

定时任务的周期与提前天数属于企业内部管理口径,按自己的作业节奏配置即可,系统不内置「应该提前几天」这种默认值。

手机上怎么用:导游端只要三个动作

导游和领队在团上,不可能坐在电脑前填表。手机端要解决的就是三件事:

节点打卡。 打开今天这一团的行程,选中节点(落地、入店、景点、返程),填实际时间,有异常就加一行说明和照片。这是选节点+填时间,不是扫码打卡——行程节点没有码可扫,别按扫码思路去设计流程。

垫付登记。 一件一笔,拍照上传票据,填金额与事项。属于哪一团、哪一天,从当前团期带出来,不用重选。回到城里再一起提交审批。

名单查看。 客人姓名、电话、紧急联系人、房号。这是导游在机场最常翻的一页。

移动端不需要单独搭建:PC 端建好的模块发布后,同一套数据与权限在手机上就可用,字段、状态、审批都是同一份(使用方式见移动端使用指南:工作台、模块页与手机上的 AI 构建)。这里有一个常见误解要说明白:手机端不是离线可用的。景区、山区信号不稳定时,不要期待表单填完自动补传,这套方案不做离线同步。稳妥的做法是导游包里备一份纸质记录卡,现场手写,回到有网络的地方补录——补录时实际发生时间与录入时间是两个字段,时间不一致如实填写即可,不影响记录的有效性。这个兜底办法要写进导游作业手册,而不是假设「应该会有信号」。

上线前,按这张清单逐项过

1. 团号唯一约束先建好。凡是两人都能新建团期的地方,一定会出现同一个团两套档案。
2. 字典一次定死。团期状态、报名状态、人数类型、节点类型、收款方式、费用项目这六组选项在数据字典里统一维护,不要边用边加——中途加一个「在途中」状态,前期数据和后期数据就分成了两套口径。
3. 存量团期要导入,不能只建空系统。正在走的团、还没结清的地接款,必须在第一天就录进去。用 Excel 直接建成模块或批量导入(见用 Excel 一步建模块),比手输三十个团快得多。只导入新团,超期未结算的清单就永远是空的,业务方不会再信它。
4. 权限按角色和数据范围各验一遍。用导游账号登录,确认看不到团费;用财务账号试改一次报名金额,应该被拦住。
5. 数据流规则逐条试跑。差异金额填了数但原因为空,提交应当被拦;把一条报名行改成「已取消」,团期收入汇总应当随之减少。
6. 定时任务先跑一次。提前提醒只发给该发的人,发错人比不提醒更糟。
7. 双端核对后再发布。发布预检会检查页面与接口的完整性,发布后确认菜单已挂载、手机端已同步(见模块的测试与发布:预检、挂载菜单与移动端同步)。

这套台账跑起来之后,往哪延伸

• 地接社/酒店/车队要建档立信:报价历史、合作评价、结算及时率,放在供应商管理里,团期上的地接社字段直接引用它,不要在两个地方各存一份名称。
• 团费的应收与实收,如果公司已经用应收应付体系管钱,团期方案的收款记录只做「这一团谁交了」,对外账龄与开票结算走应收应付台账,两处按团号与单据号对得上即可,不重复记两遍金额。
• 客人意外险是旅行社的常规动作,保单与理赔进度适合独立建账,与团期按「团号+客人」关联,做法参考保险保单与理赔台账。
• 渠道获客到报名这一段,如果线索量大,可以在展会与活动线索里管线索,成交后再落到报名明细,两边分工明确:一个管「还没交钱的人」,一个管「已经在这一团里的人」。

这套方案明确不做什么

写清边界比罗列功能更有用,以下几件事不在这个方案范围内:

• 不做在线售卖与支付通道对接。收款记录只登记「收到了什么」,不对接支付网关、不做对账自动匹配。
• 不做证件自动识别。证件号靠人工录入或 Excel 导入,没有 OCR 识别,也没有与证件系统的对接。
• 不做排班与资源调度算法。排车、排房靠人排,系统负责记录结果与查冲突,不做最优解计算;也没有动态定价、智能打包这类算法能力。
• 不做发票开具与税务申报。开票走财务既有流程,需要留痕就另开票申请与发票台账。
• 不做客人自助端。客人看不到系统,告知与确认靠领队当面或电话完成,系统只留「已告知时间、告知人」的记录。

把这三张表(团期、报名、行程与费用)认真建起来,再加上地接结算与移动端补录,一个团从头到尾的账就有了共同依据:人查得到、钱对得上、时间追得回。不需要先上一套庞大的旅游 ERP,从下一次出团开始用,是最容易验证的做法。