蝶恋花未恋上个月我把这套系统拉通整理了一遍，发现它已经积累了87个功能点、30多张业务单据，覆盖了从询位到结算的整条地接业务线。我们内部叫它“地接通07Fly”，意思就是目的地接洽的每个环节都要在系统里跑通，07是立项时间，Fly是希望业务能顺畅转起来。很多同行问我，一家地接社搞旅行社ERP系统到底有没有必要，功能清单列出来会不会只是给领导看的花架子。这篇就来聊聊这套系统的功能清单是怎么设计的，每张单子解决什么问题，以及上线两年我们踩过的那些真实坑。
1. 为什么一家地接社会被一套ERP逼疯：立项前的真实痛点
1.1 地接社的业务流程到底有多碎
如果你没在旅行社干过，可能以为地接业务就是“接团、订房、派车、结束”。真做起来才知道，地接社的业务流程是典型的“多品种、小批量、强时效”：几十条常规线路，每条线路有旺季淡季不同价格；酒店资源散落在各个景区周边，有大床房、双标间、三人间；车队有19座、33座、49座等不同车型，还分大座小座新宇通旧金龙；导游有的专跑这条线，有的不想接购物团。组团社的询位单随时会过来，今天问后天有没有12间房，中午问周五能不能排一辆33座车，下午又说客人改了航班要提前一小时接站。
这些琐碎信息在手工状态下全靠人脑和Excel。我们当时最典型的一个场景：操作员翻微信聊天记录找昨天确认的餐厅菜单，翻了三屏才找到截图；财务月底对账时发现车队结账单上的用车日期，跟排团表差了整整一天，最后查出来是操作员口头改过时间但没同步任何单据。所以整个立项的出发点，不是赶时髦上什么中台，而是我们不想再靠“人肉数据库”干活了。
1.2 Excel排团、微信确认、手写凭证：手工状态的三个致命伤
很多人觉得小社就那点业务量，Excel加记账软件够用。但业务量一旦超过每天五六个团，Excel就会暴露三个致命伤。
第一是数据不唯一。同样的一个团队，销售登记表里写“7月12日九寨沟双飞6日”，操作表里写“0712九寨一线”，财务记账时又写成“九寨团6天”。三个名字对应的是同一个团，月底对账时就得靠人去猜。第二是控制不及时。酒店库存有几间能卖，车队哪辆车哪天被订了，导游的档期撞不撞，全靠打电话问，问完不回填，等于没问。超卖是常事，我曾经见过同一个酒店7月15日的房间被锁了两次，最后客人到了前台没房，现场炸锅。第三是历史不追溯。半年前的一个团，为什么餐标从25变成了30？是谁在什么时候改的？手工状态下完全查不到，团队发生投诉或者财务复核的时候，只能听当事人“我记得”。
1.3 系统边界：07Fly到底管哪些事、不管哪些事
立项时我们做过一版边界图，当时最纠结的是要不要把呼叫中心、客户营销、票务出票都做进去。后来达成共识：07Fly只做“从组团社询位到财务结算完成”这条核心链条，其他一律不碰。原因很简单，地接社的核心竞争力在于资源整合和地面执行，把询位、锁位、排团、住房、用餐、用车、门票、导游报账、应收应付管好，就已经能解决80%的混乱。
系统管的事包括：客户与销售线索、线路与产品、资源供应商及价格协议、询位与订单、团队计划、地接执行单据、导游报账、财务结算与报表。不管的事包括：门市收客的CRM营销流程、机票出票、签证办理。这些周边环节我们通过接口或者手动导入做轻关联，不进行深度管理。这个边界很重要，因为需求控制不住，ERP很容易做成一个什么都往里装的“大杂烩”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 07Fly功能清单全景：6大模块87项功能怎么划分
2.1 功能清单的整体逻辑
整理功能清单不是把菜单截图贴上去，而是要按照业务主线来组织。07Fly的功能地图大体可以分成六块：主数据与资源、询位与订单、计划与执行、财务与结算、外部对接、系统管理。每一块下面再拆子功能。我们当时做清单时定了一个原则：每张单据必须回答四个问题——谁创建的、给谁看的、基于什么数据生成的、最终流转到哪个环节。
为了让你对整体有直观感受，我先把最核心的清单结构列出来，后面几节再挑重点拆开讲。
| 模 块 | 核心单据/功能 | 关键功能点 |
|---|---|---|
| 主数据管理 | 客户档案、线路产品、供应商、资源项（房/车/餐/票/导） | 统一的编号规则、价格日历、协议有效期、联系人管理 |
| 询位与订单 | 询位单、报价单、锁位单、订单变更单、取消单 | 自动检查资源余量、锁定期、多方案报价、变更历史 |
| 计划与执行 | 排团单、接站任务、用房单、用餐单、用车单、门票单、导游派团单 | 按团关联资源、生成执行确认书、资源使用清单 |
| 财务结算 | 团款应收单、供应商应付单、导游报账单、发票登记、收付款登记 | 按团归集收入成本、自动生成毛利、结算单与单据联动 |
| 外部对接 | 组团社B2B查询窗口、OTA订单导入、财务软件导出 | 余位实时共享、订单状态回传 |
| 系统管理 | 组织架构、用户权限、编号规则、日志与审批流 | 分社数据隔离、审批流配置、操作留痕 |
整个清单一共87个功能点，其中主数据13个，询位订单19个，计划执行21个，财务结算18个，对接6个，系统管理10个。数字不一定代表绝对合理，但它基本反映了地接社的业务重心：一半以上的功能都花在计划执行和财务结算上，这是资金和风险最集中的地方。
2.2 主数据与资源池设计：先有“货架”才有“买卖”
主数据是所有业务的底座。我们吃过“编号不统一”的亏，所以这次给所有客户、线路、供应商、甚至每一种资源项都定了唯一的编码规则。客户按“ZTS+城市+序号”编码，线路按“路线简写+天数+性质”编码，供应商按类型分：H开头是酒店，C是餐厅，T是车队，P是门票供应商，G是导游。
资源池这个概念很多人会忽视。实际上，每一间可售房、每一辆可用车、每一位导游的日程，都应该是一个可以被占用的“资源”。07Fly里每个资源项都有一个日历式的状态栏，某个时间段被询位锁定、被订单占用、被排团使用，都会在日历上显示。这样做最大的价值是杜绝了超卖。我们曾经有一个合作比较紧密的酒店，十间房的额度直接进了系统，非签约临时用的房则走“外调资源”通道，额度是虚的，每次询位时人工确认。
2.3 询位、订单、锁位：别把销售过程搞成“表格填写”
旅行社ERP最容易做错的地方，是把询位单做成一张Excel录入表。其实询位单的本质是“销售机会+资源可用性试探”。操作员接到组团社的微信或者电话后，把日期、人数、用房数、车型、餐标、景点要求填进去，系统立刻做一次资源预检。预检通过后，系统会按价格日历自动计算基础报价，操作员可以手工调价，再把方案转成报价单发给组团社。
组团社认可后，不是直接占资源，而是先做“锁位”。锁位的意义在于优先预留，一般设24小时或者48小时的有效期，过期没确认自动释放。这个机制非常管用，它把“口头有意向”和“正式要下单”分开，避免操作员为了稳住客户，把资源锁了十天半个月。确认后锁位单转正式订单，系统自动占用资源，并生成该团的编号和状态，之后的排团、执行、结算全部挂在订单和团号下面。
2.4 计划与执行：地接核心“落地动作”的颗粒度
排团是地接社最核心的操作动作。排团单把组团社的订单拆分成本地的执行计划：哪天接站、谁去接、住哪家酒店、吃哪家餐厅、哪天用哪辆车、去哪些景点。每一项执行动作在系统里都对应一张独立的单据，比如用房单、用车单、门票单。
为什么要拆到这么细？因为财务和运营需要不同的颗粒度。运营需要知道导游明天几点到机场，财务需要知道这个团在哪个酒店产生了多少成本。如果不拆，所有的信息都在一张排团单的备注栏里，看起来是省事，但月底对账时根本没法按供应商归集。把所有执行单据统一按“团号+日期+资源类型”编号，供应商结账时，我们拉一张按资源类型汇总的表，谁家该付多少一目了然。这就是“功能清单”背后真正的意义：不是功能越多越高级，而是每个功能都能对应到现实中的一笔动作。
2.5 财务与结算：让毛利算得清，让每笔钱有据可查
财务模块是07Fly里面改动次数最多的，因为地接社的结钱方式太灵活。组团社可能预付定金，也可能滚动月结；车队可能跑完一个月才结算，也可能每团现结；餐厅有的按餐标结，有的按套餐人头结。最开始我们只有一张应收表一张应付表，结果财务对账时发现金额对不上，因为总价和明细拆分之间缺少留痕。
后来我们做了一个“结算单”概念。每个团结算时，系统会汇总所有收入和成本明细，生成一个毛利结算单。这个结算单不是财务自己填的数，而是从应收单据、供应商应付单据、导游报账单自动归集过来的。比如这个团入住的总房费，就是五张用房单的合计；餐费是三天六家用餐单的总和；导游报账里的零星支出，比如停车费、司机加班费，也会自动归到成本里。这样毛利是“算出来”的，不是“填出来”的，财务只做审核和调整，减少了大量重复操作。
3. 询位、锁位、派车、报账：四个功能点的业务逻辑与隐藏需求
3.1 询位单：不只是登记，而是“可用性预检+报价模板”
很多软件会把询位单做成一个简单的记录，只要把组团社的名字和需求填进去就行。但我们后来发现，询位单最大的价值在于它前面的“预检”。比如组团社要12间双标间，日期是8月10日，系统如果先在酒店资源日历里查一下，发现合作酒店只剩8间，那就第一次询位时就得回复“只能做8间，另外4间需要外调”，而不是等正式订房时才发现。
所以询位单设计时有三个隐藏需求：一是自动带出价格日历里的基础价，减少人工查价；二是记录“方案快照”，也就是这次报价用的房费、车费、餐费是多少，就算后面价格调整了，这次的报价记录不能变；三是支持多方案，同一个询位可以生成3个不同的方案，比如“方案A：全程四星酒店；方案B：三晚四星一晚民宿”，组团社选哪个就留哪个。这三个点都需要系统在后台做关联查询，而不是手工录入。
3.2 锁位与控位：10间房的额度谁说了算
锁位功能看起来简单，真正难做的是“控位逻辑”。举个例子，和某家酒店签了协议，每月固定拿10间房。这10间房是全部放在一个销售手里，还是三个销售共享？如果某天旅行社A先锁了6间，旅行社B又来锁6间，系统要不要放行？我们的做法是：每个销售人员可以设置自己分管资源的“可售额度”，比如这个酒店15日有10间，张三分管6间，李四分管4间。张三用了6间后，再锁就提示“超出额度，需向资源经理申请”。
这样做的好处是把资源控制权下沉到人，同时保留例外审批。我们上线前有个争议，说这样做太死板，销售互相借额度不方便。后来加了“临时占用”功能：在锁定界面可以直接占用其他人的剩余额度，但系统会强制在备注里写理由，并通知额度归属人。这样既灵活又有痕迹，扯皮的时候查得到是谁借的、为什么借。
3.3 排团与派车：自动匹配还是人工干预？
排团单里有几块内容：团的基本信息、每日行程安排、资源使用计划、导游委派。最初我们想让系统自动推荐车辆和导游，比如根据人数自动匹配车型，根据导游评价自动推荐导游。但试用两周后我们就明白了，机器推荐可以作为参考，绝对不能一刀切。
因为车型选择不仅看人数，还要看行李舱大小、路况、司机对线路的熟悉程度；导游选择更复杂，有些客户指定要男导、有些团要会讲方言的、有些路线导游正好前一天在隔壁城市下团，档期虽然没冲突但精神状态是个现实问题。所以系统只做两件事：一是给出可用的车辆和导游列表（按时间过滤），二是展示这些资源的近期使用频率和评价分。最终的排定动作，还是由操作员人工决定。这个“人工决策+系统辅助信息”的模式，比全自动更符合行业实际。
3.4 导游报账单：和财务对账的最后一公里
导游报账是所有ERP里最容易被轻视的功能，但也是上线后我们花费精力最多的功能之一。导游每天会产生大量小额支出：给司机买瓶装水、行李生小费、景区停车费、客人临时加餐。以前这些钱全写在导游的“记账本”上，字迹潦草，还有的导游把收据一团就放口袋，回来报账时财务根本看不懂。
07Fly里的导游报账单，是按“排团单”关联生成的。导游在APP（我们配了一个轻量版小程序）里选择对应的团号，逐项登记费用类别，拍照上传小票，系统会自动按类别归集。比如“餐费-加餐”“交通费-停车”“杂项-小费”。每个费用的归属供应商如果是签约的，就直接关联供应商档案；如果不是，就选择“零星付款”，走线下报销。财务审核时，只需要看小票照片是否清晰、金额是否合理，然后一键生成应付单。数字统计下来，一个团的报账审核时间从平均40分钟缩短到了15分钟。
4. 上线实施过后来看：我们踩过的四个真坑
4.1 期初数据迁移：别把Excel里的“脏数据”直接灌进系统
上线最痛苦的不是软件配置，而是历史数据怎么处理。我们有大约两百个在途订单、一百多个长期合作的供应商，以及数以千计的资源价格。起初我想偷懒，直接把Excel整理后导入系统，结果一周后就开始出问题：同一个酒店有两个编号（因为Excel里名字写法不一样），一个团队明明取消了但系统里还是在执行状态。
后来我们花了两周做过一次彻底的“数据清洗”。规则就一条：宁缺毋滥。所有在途订单必须由操作员确认状态（停团、确认、待锁），必须补上完整的价格明细；供应商必须统一名称和签约信息；历史价格只导入“当前有效的协议价”，以前已经结束的团价不导。导完之后还要用测试账号做抽查。这笔投入非常值得，因为导入初期一旦带着脏数据跑，后面所有报表都会失真，财务和业务会互相怀疑。
4.2 权限与数据隔离：多个分社共用一套系统，权限比想象中复杂
我们其实有区域分社，有的分社负责周线，有的负责出境线。上线前想简单一点，所有分社的数据放在一起跑，靠名字区分就行。但实际跑了一周就发现，A分社的财务不小心看到了B分社的结算单；操作员查资源时，把另一个分社锁的用房直接覆盖掉。因此我们紧急补了一套权限体系。
控制粒度是“操作员-数据范围-操作类型”三层。数据范围可以精确到“本分社全部数据”，也可以到“本团队全部数据”，甚至到“本分社房类资源”。操作类型分为查看、编辑、审核、删除。一个重要经验：删除权限必须收归到系统管理员。任何业务单据，不管是询位还是结算单，都只允许作废和红冲，不允许物理删除。这条规则后来救了我们的命，审计的时候每一笔变更都有迹可循。
4.3 报表口径：同一个“毛利”，财务和业务吵了一整周
我印象最深的坑是“毛利”的定义。业务眼中的毛利是用“实际收款-实际付款”算出来的，比如这个团客人临时加了500元，去餐厅加了一桌菜花了200，那毛利就是实际的差。但财务坚持用“应收-应付-预计分摊”来算，比如车费按公里数预提，等到月底才知道准确数字。
两边都没错，但口径不一致就会吵。我们最后在系统里做了“毛利快照”和“月结终版”两个概念。运营过程里，看的是“快照毛利”，数据实时更新，帮助业务判断这单赚不赚；到了结账期，财务审核完所有票证后，系统自动把该团所有应收应付更新为终版，锁定生成“终版毛利”。所有报表都标明口径，不再混在一起。这件事给我一个教训：功能清单里最需要先写清楚的，不是界面有什么按钮，而是每个数字的计算公式。
4.4 自定义字段与流程调整：改一个字段类型，可能一堆单据会崩
上线初期我们经常根据业务反馈调整功能，最典型的是“人数”。有个人下单时填的人数是一个20人的团队，后来因为退团变成17人，再后来又临时加了2个大人1个小孩。第一次我们是把“人数”字段从整数改成字符串，允许填“17+1”，相当于大人加小孩。结果所有统计报表全乱，因为数字排序变成了文本排序，“10”排在了“9”前面。
这个坑的教训是：凡是涉及金额、人数、日期的字段，一开始就要定义清楚是数值、日期还是枚举，千万不要为了图方便用“万能文本”。日期字段更是要区分“出发日期”“确认日期”“实际接站日期”，不能混用。如果你在实施时遇到“多填一点备注就行”的请求，一定要谨慎评估，因为表面上是加个备注，实际上是在破坏后续的统计逻辑。
5. 功能清单之外的落地心得：命名、流程与人员
5.1 单据命名要贴近业务“人话”，别用技术术语
功能清单如果只有技术人员看得懂，那上线一定会受阻。07Fly里的单据名称全部按一线习惯命名：不叫“B2B订单”，叫“组团社订单”；不叫“资源分配单”，叫“用房单/用车单”；不叫“异常处理记录”，叫“变更申请单”。这样做的原因是，真正常用系统的不是程序员，而是操作员和导游。如果界面上出现“库存台账”“标准成本”这种词，他们第一反应就是抵触。
5.2 切换流程时“新旧并行”比“一刀切”更稳
上线初期，我们把Excel和系统并行跑了三周。操作员先在系统里录入，再由另一名核对员和Excel账比对。这个阶段虽然多了一倍工作，但它让团队平稳过渡。最大的好处是，系统中的问题会在小范围内暴露，而不是整个业务直接断掉。三周后，我们发现系统里的数据已经比Excel全，大家自己就同意停用旧表了。硬推往往适得其反。
5.3 培训材料不是录屏，而是“按角色写脚本”
最后说一个容易被忽略的点：培训。我们第一次培训给所有人发了一份几十页的功能说明书，结果没人看。后来改成“角色脚本”：给操作员写一份“如何从询位到排团”的8步操作手册，给财务写“如何审核导游报账”的5步手册，给管理层写“如何看毛利报表”的3步手册。每份手册就是一页纸，配上真实业务案例。这个改动让培训成本降低了七成。
如果让我总结一套ERP的功能清单怎么描述才有效，我会说：不要只罗列“我们可以做什么”，要讲清楚“这些功能对应业务的哪一步，解决什么问题”。清单是给系统开发看的，更是给业务和老板看的。功能点越多不代表系统越好用，把询位、锁位、控位、结算这四个核心链路想明白，这套ERP就能真正帮一个地接社稳住底盘。