简介：这份文档资料面向酒店管理专业学生、酒店一线员工及希望系统了解PMS的从业者，围绕酒店管理系统（Property Management System）系列课程展开，帮助读者建立从信息化概论到前台业务全流程的完整认知。内容涵盖酒店信息化概论、PMS系统概览、客户资料与预订、接待与收银、房务管理与夜审、团队基础等模块，并以肯德基电子优惠券、文华东方酒店客户服务等案例说明信息化对酒店降本增效与提升竞争力的意义，同时强调跨部门信息流通与避免重复客户资料、重复开房等操作要点。资源包共1个doc文件，约240KB，以课程讲义形式呈现，结构清晰，便于按章节学习与查阅。目前已有187人学习，适合作为酒店PMS入门培训、岗位自学或教学参考的配套资料。
1. 酒店管理系统（PMS）到底在管什么：从一张房态图说起
凌晨两点，前台打电话说 803 房间的客人要续住，但系统显示这间房明天已经被预订出去了。你打开后台，发现预订模块和房态模块的数据对不上——预订表里有一条记录，但房态表里那间房还是“可售”状态。这不是玄学，这是酒店管理系统（PMS）里最典型的模块耦合问题。
PMS 全称 Property Management System，直译是物业管理系统，但在酒店行业里它就是酒店的大脑：管房态、管订单、管客人档案、管账务、管渠道对接。一套 PMS 要同时服务前台、客房、财务、销售四个角色，任何一个模块的数据不一致，都会直接变成前台和客人的冲突。这个系列课程要拆的就是这套系统怎么从零搭起来、模块之间怎么串、哪些参数设错了会翻车。适合有后端基础、想切入酒店信息化方向的开发者，也适合正在选型或二次开发 PMS 的技术负责人。
2. 房态、订单、账务三张表怎么设计才不打架
PMS 的复杂度不在代码量，在数据模型。房态、订单、账务这三个模块如果各建各的表、各写各的状态字段，后期一定出现“订单已取消但房态还占着”这类血泪经验。核心思路是：用一张事实表串起生命周期，状态流转只在一个地方改。
2.1 房间、房型、房态的三层关系
先理清三个概念。房间（Room）是物理存在的 803、804；房型（RoomType）是“高级大床房”这种销售单位；房态（RoomStatus）是某个房间在某一天的可售状态。很多新手会把房态直接挂在房间表上，加一个status字段，结果一遇到跨天预订就崩——因为房态是“房间 × 日期”的二维概念，不是房间的属性。
常见做法是建一张room_inventory表，主键是(room_id, stay_date)，每天一行，记录当天这个房间是被占用、预留还是可售。这样查“明天还有几间高级大床房”就是一句聚合查询，不用去遍历订单表反推。
-- 库存表：房间 × 日期 的二维矩阵 CREATE TABLE room_inventory ( room_id INT NOT NULL, stay_date DATE NOT NULL, room_type_id INT NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0可售 1已占 2预留 3维修 order_id BIGINT DEFAULT NULL, -- 关联占用它的订单 version INT NOT NULL DEFAULT 0, -- 乐观锁版本号 PRIMARY KEY (room_id, stay_date), KEY idx_type_date (room_type_id, stay_date, status) );这段建表语句的关键在version字段和联合主键。联合主键保证一个房间一天只有一条库存记录，不会重复；version用于并发下单时的乐观锁——两个请求同时抢 803，只有一个能更新成功。idx_type_date这个联合索引是给“查某房型某天剩余量”用的，少了它，房态查询在旺季会慢到前台砸键盘。
参数上，status用 TINYINT 而不是 ENUM，是因为后续可能要加“锁房”“钟点房”等状态，ENUM 改起来要 ALTER TABLE，TINYINT 加个映射就行。order_id允许 NULL，因为维修状态的房间没有关联订单。
2.2 订单状态机：别让取消和入住互相覆盖
订单模块最容易翻车的地方是状态字段被多处修改。前台点了“取消”，渠道那边又推了一条“确认”，两个操作同时写status，后写的覆盖先写的，结果取消的订单又活了。解决办法是把状态流转收敛到一个状态机里，所有变更走同一个入口。
# 订单状态机：只允许合法流转，非法流转直接抛异常 ORDER_TRANSITIONS = { "pending": ["confirmed", "cancelled"], "confirmed": ["checked_in", "cancelled", "no_show"], "checked_in": ["checked_out"], "checked_out": [], "cancelled": [], "no_show": [], } def transit_order(order, target_status, operator): allowed = ORDER_TRANSITIONS.get(order.status, []) if target_status not in allowed: raise IllegalStateError( f"订单 {order.id} 不能从 {order.status} 转到 {target_status}" ) # 记录流转日志，出问题可追溯 OrderLog.create(order_id=order.id, from_status=order.status, to_status=target_status, operator=operator) order.status = target_status order.save() # 同步释放或占用库存 sync_inventory(order) return orderORDER_TRANSITIONS这张字典就是业务规则的代码化。pending只能转confirmed或cancelled，不能直接跳checked_in；checked_out和cancelled是终态，不允许再变。transit_order里先校验再落日志最后改状态，顺序不能反——先改状态再校验，异常时状态已经脏了。sync_inventory负责在取消时释放库存、在确认时占用库存，保证订单和房态始终一致。
我一般会把这张流转表做成配置，不同酒店对no_show的处理不一样，有的允许从no_show恢复，硬编码在代码里后期改起来要发版。
2.3 账务表：押金、消费、退款要分账记录
账务模块的坑在于把押金和消费混在一个余额字段里。客人入住交 500 押金，消费了 200，退房时该退 300。如果只有一个balance字段，中间任何一笔操作出错都说不清钱去哪了。正确做法是流水记账：每一笔押金、消费、退款都是一条独立记录，余额是聚合出来的。
CREATE TABLE folio_transaction ( id BIGINT PRIMARY KEY AUTO_INCREMENT, folio_id BIGINT NOT NULL, -- 账务单，一个订单一个 txn_type TINYINT NOT NULL, -- 1押金 2消费 3退款 4冲账 amount DECIMAL(12,2) NOT NULL, -- 正数入账 负数出账 ref_type VARCHAR(32), -- 关联业务类型 ref_id BIGINT, -- 关联业务ID created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_folio (folio_id, created_at) );amount用 DECIMAL 不用 FLOAT，钱的计算不能用浮点，这是铁律。txn_type区分类型，退款和冲账分开，因为冲账是纠错、退款是正常业务，财务对账时要分开看。余额查询就是SELECT SUM(amount) FROM folio_transaction WHERE folio_id = ?，永远不存余额字段，避免并发更新丢钱。
3. 从零跑通一个最小 PMS 后端：接口、并发、渠道对接
数据模型立住之后，下一步是让接口跑起来。这一章用一个最小可运行的后端把房态查询、下单、渠道回调三个核心链路串通，重点讲并发下单怎么防超卖、渠道推送怎么幂等。
3.1 房态查询接口：一次查清可用房
前台最常用的接口是“查某天某房型还有几间可售”。这个接口要快，因为前台一边接电话一边查，超过 500ms 体验就崩了。
# GET /api/availability?checkin=2025-06-01&checkout=2025-06-03&type=1 def get_availability(checkin, checkout, room_type_id): dates = date_range(checkin, checkout) # 不含 checkout 当天 rows = db.query(""" SELECT stay_date, COUNT(*) AS total, SUM(CASE WHEN status = 0 THEN 1 ELSE 0 END) AS available FROM room_inventory WHERE room_type_id = %s AND stay_date IN %s GROUP BY stay_date """, (room_type_id, tuple(dates))) # 取所有日期的可用量最小值，就是整个住期的可订量 available = min(r["available"] for r in rows) if rows else 0 return {"room_type_id": room_type_id, "available": available, "detail": rows}逻辑上，一个住期能不能订，取决于住期内每一天都有房。所以取available的最小值，而不是求和。date_range生成的是[checkin, checkout)左闭右开区间，因为退房当天房间可以再卖。SUM(CASE WHEN...)这种写法比先查再在代码里过滤快，数据库一次扫描就出结果。
参数上，checkin和checkout要做格式校验和日期合法性校验，checkout必须大于checkin。room_type_id不存在时返回空而不是报错，前端好处理。
3.2 并发下单：乐观锁 + 重试防超卖
旺季抢房，两个渠道同时下单同一间房，如果不用锁，两个请求都读到“可售”，都写占用，就超卖了。用room_inventory的version字段做乐观锁。
def book_room(order_req): dates = date_range(order_req.checkin, order_req.checkout) for attempt in range(3): # 最多重试3次 try: with db.transaction(): for d in dates: inv = db.query_one(""" SELECT room_id, version FROM room_inventory WHERE room_type_id = %s AND stay_date = %s AND status = 0 LIMIT 1 FOR UPDATE """, (order_req.room_type_id, d)) if not inv: raise NoRoomError(f"{d} 无可用房") affected = db.execute(""" UPDATE room_inventory SET status = 1, order_id = %s, version = version + 1 WHERE room_id = %s AND stay_date = %s AND version = %s """, (order_req.order_id, inv.room_id, d, inv.version)) if affected == 0: raise ConcurrentError("库存被抢占，重试") return {"order_id": order_req.order_id, "status": "confirmed"} except ConcurrentError: continue raise BookingFailedError("多次重试仍失败，请稍后再试")FOR UPDATE在事务里锁住选中的行，防止其他事务读到旧版本。UPDATE ... WHERE version = ?是乐观锁的核心：如果版本号在读取后被别人改了，affected就是 0，说明有并发，抛异常重试。重试 3 次是经验值，再多说明竞争太激烈，应该考虑排队或预扣库存。
注意FOR UPDATE和乐观锁同时用有点冗余，实际生产里二选一即可。这里写出来是为了展示两种思路：FOR UPDATE是悲观锁，适合冲突少的场景；乐观锁适合冲突多但重试成本低的场景。酒店旺季我一般用乐观锁加队列，避免长事务锁表。
3.3 渠道回调：幂等是保命符
OTA 渠道推订单过来，网络抖动导致重复推送是常态。如果回调接口不幂等，同一笔订单会建两次，房态扣两次。幂等的做法是用渠道订单号做唯一键。
def handle_channel_callback(payload): channel_order_no = payload["channel_order_no"] # 唯一键冲突直接返回成功，不重复处理 existing = db.query_one( "SELECT id FROM channel_order WHERE channel_order_no = %s", (channel_order_no,)) if existing: return {"code": 0, "msg": "duplicate, ignored"} try: with db.transaction(): db.execute(""" INSERT INTO channel_order (channel_order_no, hotel_id, room_type_id, checkin, checkout, amount) VALUES (%s, %s, %s, %s, %s, %s) """, (channel_order_no, payload["hotel_id"], payload["room_type_id"], payload["checkin"], payload["checkout"], payload["amount"])) order = create_order_from_channel(payload) book_room(order) return {"code": 0, "order_id": order.id} except DuplicateKeyError: return {"code": 0, "msg": "duplicate, ignored"}channel_order_no上要建唯一索引，这是幂等的物理保证。先查再插在并发下仍有窗口，所以还要捕获DuplicateKeyError兜底。create_order_from_channel和book_room在同一个事务里，要么都成功要么都回滚，不能出现订单建了但库存没扣的情况。
渠道回调的响应格式要按渠道文档来，有的要求返回{"code": 0}，有的要求返回"success"，这个不能想当然。我一般会为每个渠道写一个适配器，把渠道格式转成内部统一格式，回调处理逻辑只写一份。
4. 避坑与排查：PMS 上线后最容易炸的五个地方
PMS 上线不是终点，是问题的开始。下面五条是实际运维里最常遇到的，每条按现象、原因、解决写。
现象：前台说“明明有房，系统显示没房”。原因：库存表里某些日期的记录缺失，比如新加的房间没有初始化未来 90 天的库存。查询时IN条件匹配不到那些日期，聚合结果偏小。 解决：加一个定时任务，每天凌晨为所有房间补齐未来 90 天的库存记录，INSERT IGNORE避免重复。同时加监控，库存记录数低于阈值告警。
现象：订单取消了，但房态还是“已占”，房间卖不出去。原因：取消订单时只改了订单状态，没有调sync_inventory释放库存。或者释放时事务回滚了，订单状态改了但库存没改。 解决：把订单状态变更和库存释放放在同一个事务里，用transit_order统一入口。再加一个对账任务，每天扫一遍“已取消但库存仍占用”的脏数据，自动修复并告警。
现象：渠道订单重复推送，同一间房被扣了两次库存。原因：回调接口没有幂等，或者唯一索引没建，重复插入成功。 解决：channel_order_no建唯一索引，接口先查后插并捕获唯一键冲突。已经产生的重复数据要人工核对后释放多余库存。
现象：账务对不上，客人说押金退少了。原因：押金、消费、退款混在一个余额字段里，某次并发更新覆盖了。或者退款时用了 FLOAT 导致精度丢失。 解决：改成流水记账，余额聚合查询，金额用 DECIMAL。历史数据要逐笔核对，补流水记录。
现象：旺季房态查询接口超时，前台排队。原因：room_inventory表数据量大，查询没走索引，或者IN条件日期太多导致全表扫。 解决：确认idx_type_date索引存在且被使用，用EXPLAIN看执行计划。日期范围超过 30 天时改成分段查询或加缓存，缓存 key 用room_type_id + stay_date，过期时间设短一点，比如 30 秒。
5. 用对账任务兜底：PMS 数据一致性的最后一道防线
前面讲的都是“怎么不出错”，但分布式系统里不出错是理想，出错是常态。PMS 作为交易系统，必须有对账兜底。我一般会写三个对账任务，每天凌晨跑，发现问题自动修复并告警。
第一个是订单-库存对账：扫所有status = confirmed或checked_in的订单，检查对应日期的库存是否都是“已占”且order_id匹配。不匹配的，以订单为准修复库存。
def reconcile_order_inventory(): orders = db.query(""" SELECT id, room_type_id, checkin, checkout FROM orders WHERE status IN ('confirmed', 'checked_in') """) fixed = 0 for o in orders: for d in date_range(o.checkin, o.checkout): inv = db.query_one(""" SELECT room_id, status, order_id FROM room_inventory WHERE room_type_id = %s AND stay_date = %s AND order_id = %s """, (o.room_type_id, d, o.id)) if not inv: # 订单占用了但库存没标记，补上 db.execute(""" UPDATE room_inventory SET status = 1, order_id = %s WHERE room_type_id = %s AND stay_date = %s AND status = 0 LIMIT 1 """, (o.id, o.room_type_id, d)) fixed += 1 return {"checked": len(orders), "fixed": fixed}第二个是账务-订单对账：每个订单的流水汇总应该等于应收金额。不等的话，标记异常订单，人工介入。第三个是渠道-本地对账：拉取渠道当天的订单列表，和本地channel_order表比对，缺的补、多的标记。
对账任务的关键是只修复明确可判定的问题，模糊的留给人工。比如库存缺失可以自动补，但金额对不上不能自动改，因为可能是业务规则差异。告警要发到值班群，附上订单号和差异明细，方便快速定位。
这套对账机制跑顺之后，PMS 的数据一致性基本能兜住。我的习惯是：任何交易系统，先想好对账怎么做，再写业务代码。因为业务代码可以改，数据错了就是事故。希望帮到你。
本文还有配套的精品资源，点击获取
