最近大半个月光是我这边收到的咨询里就有三四个是关于 Odoo 19 里礼品卡和电子钱包的。问的人背景很不一样有做连锁餐饮的想做节日礼品卡有做跨境零售的想把售后退货款转到客户钱包里而不是原路退回还有做知识付费的想把会员费包装成礼品卡转赠。这个需求不是突然冒出来的——你去社交平台上翻翻礼品卡相关的热门问题常年霸榜比如买卡时账单地址怎么填、在第三方平台买卡靠不靠谱、礼品卡怎么转赠给别人。大家习以为常地在消费端买卡送人反过来说明商家侧其实更需要一套自己的礼品卡和电子钱包体系否则客户数据、核销记录、账务沉淀全在别人手里营销玩法也做不了。Odoo 19 把礼品卡Gift Card和电子钱包E-Wallet都原生做进了销售模块不需要额外安装一堆社区模块。这对实施顾问、企业内部 IT 和电商运营来说是个好消息配置链路短、客户门户直接看得见、账务也能在后台追踪。这篇文章是我自己从规划到上线、再跑了一段时间后整理出来的实操记录包含完整配置步骤、底层原理说明以及真实项目里踩过的坑。如果你正准备在公司里搭一套预付卡或客户余额体系这篇应该能让你少走不少弯路。1. 礼品卡与电子钱包的定位差异别用一套逻辑管两类业务很多人第一次买 Odoo 的销售模块时会把礼品卡和电子钱包当成同一个东西。我一开始也这样结果配置到一半发现账对不上才回头把这两个概念重新捋了一遍。1.1 一个是预付卡一个是客户资产账户礼品卡本质上是预付卡。客户先付钱买一张面值固定的卡之后拿着这个卡来抵扣商品或服务。对商家来说收款发生在交付之前资金在账上形成一笔负债而不是已经赚到的收入。Odoo 19 里礼品卡的核销记录会跟着卡片代码走一张卡可以被一个订单部分使用、在下一个订单用完。电子钱包则是客户余额账户。它的资金来源通常不是客户主动充钱而是退款、补偿、积分兑现、优惠券转存这类场景。比如客户买了一个商品又退货按传统流程退款原路回到信用卡或支付宝但在 Odoo 19 里你可以把钱退到客户的钱包账户里让这笔钱留在你的平台内下次购物直接抵扣。这个动作看似简单实际上能显著降低退款带来的客户流失。这里面的差异直接决定了配置方式。礼品卡需要创建产品因为它是可以销售的商品电子钱包更像是一个账户体系不需要单独建产品而是靠支付环节去触发。很多人第一次配置时卡住就是因为把这两件事混在一起操作。我做了个简单的对比表方便你对照对比维度礼品卡电子钱包资金来源客户主动购买退款、补偿、奖励自动入账是否商品是需要创建产品否属于客户账户资产生命周期从售出到核销或过期从入账到扣减通常长期有效账务处理售卡时计递延收入/负债入账时即产生对应的收入调整或负债适用场景送人、节日促销、预充值退货款留存、售后补偿、会员回馈Odoo 中的入口产品配置 卡券记录支付方式 钱包账户1.2 为什么这两个能力会被放进销售模块Odoo 19 把礼品卡和电子钱包的开关放在销售模块的设置里很多人觉得奇怪这难道不该放在财务或者客户关系模块里吗原因其实很简单这两个功能的触发点都在销售流程中。礼品卡要经历销售订单卖出卡片、客户下单时核销卡片这两个关键动作全在销售和结账环节。电子钱包的入账、扣减也是一样客户在商城下单时选择钱包余额支付这一步就是在销售订单的支付界面完成的。Odoo 的产品设计思路是让流程发生在它该发生的地方所以销售模块成了它们的主场。此外Odoo 19 里礼品卡和电子钱包可以和客户门户、在线支付、POS、电子发票等多个模块联动。比如客户在门户里能看到自己的钱包余额下单时直接勾选钱包作为支付方式全程不需要人工介入。这个体验对电商业务很重要但如果只盯着财务模块配置这些联动入口是看不全的。2. 动手配置前必须想清楚的三个决策我见过不少项目功能开关打开了产品创建好了结果上线第二天就出问题原因全都是上线前没有把业务规则定清楚。Odoo 能做的只是把规则落地规则本身得先由你来定。下面这三个决策是我每次做此类项目都会先问客户的。2.1 决策一卖实体卡还是虚拟码礼品卡有两种交付形式。第一种是实体卡线上卖出去之后需要打印卡片、线下邮寄或者门店自提。第二种是虚拟码客户付款之后Odoo 生成一个唯一的卡代码通过邮件或短信发给客户客户在下次下单时输入这个代码完成抵扣。这两种形式在 Odoo 里的配置路径大体相同差别主要在交付环节。实体卡需要考虑物流、印刷成本、卡片丢失风险需要一个已验证交付的流程来避免客户没收到卡却要求核销。虚拟码则要重点防泄漏——邮件的送达率、短信通道的稳定性、代码被他人看到后的归属问题这些都要提前设计。我在实际项目里一般建议中小商家优先做虚拟码。成本低、上线快、客户即时收到也符合现在电子礼品卡的使用习惯。如果一定要做实体卡至少给代码加上激活操作客户收到卡后在门户里手动激活降低盗用的风险。2.2 决策二钱包余额是否跨店铺、跨公司使用如果你只运营一个店铺一个公司主体这个决策基本不用考虑。但连锁零售往往会有多个门店、多个法人主体甚至同一个 Odoo 实例里跑着好几家品牌公司此时电子钱包的适用范围就成了一个必须提前锁定的规则。Odoo 19 的多公司架构下钱包账户、礼品卡记录默认跟着公司隔离A 公司的钱包余额不能直接在 B 公司核销除非你做额外的对接。这个行为有时是好事——各主体账务清晰有时却是坏事——客户拿着 A 店的礼品卡去 B 店消费店员一核销发现找不到记录现场体验直接崩了。我的建议是如果你的业务允许跨店核销就在上线前明确约定礼品卡的发行主体和核销主体并通过 Odoo 的多公司设置或者自定义字段把卡片的适用门店范围标识出来。别等到客户真拿卡来了才临时解释那场面非常被动。2.3 决策三有效期、单卡上限与风控策略Odoo 的礼品卡默认可以设置有效期但这个有效期不会自己跑出来等你设置需要你在产品配置或者卡记录里指定过期日。更关键的是过期策略决定客户的钱算谁的——如果过期未核销的余额直接作废商家确认收入如果永久有效负债一直挂在账上。除了有效期还要考虑单卡面值上限。面值设太高一旦卡片代码泄露损失会很大。我见过一个客户把电子礼品卡面值设到五千结果促销活动期间被人批量尝试代码好在 Odoo 会记录核销历史及时发现后批量作废了但还是吓出一身冷汗。常规做法是设置一个合理的上限比如单卡不超过 2000 元同时开启后台的核销日志监控。风控方面核心是保证卡代码的唯一性和不可猜解性。Odoo 生成的代码本身具备随机性但如果你的业务会把代码外发给客户建议额外加上每张卡只能绑定一个客户的规则避免一个代码被多人重复使用造成的对账混乱。3. 完整配置链路从功能开关到客户钱包余额到账定好业务规则之后配置本身就不难了。下面的步骤是基于 Odoo 19 标准界面写的如果你的版本菜单略有差异以实际界面显示为准但底层逻辑是一致的。3.1 打开销售模块里的功能开关进入销售模块的配置 设置往下翻到支付这一块你会看到礼品卡和电子钱包两个选项。勾选启用之后系统会自动创建相关的产品分类、支付方式以及后台模型。这一步看似简单但有一个容易遗漏的地方启用电子钱包后销售订单的支付界面里会出现一个钱包余额的支付选项你需要同步检查一下这个支付方式的显示名称、图标和说明文案避免客户在结算时看到一串英文或默认技术名。启用开关之后还要确认客户门户的设置是开着的。电子钱包和礼品卡在客户门户里的展示非常依赖门户功能如果门户没启用客户就看不到自己的余额和卡券很多自服务流程就走不通。3.2 创建礼品卡产品关键要勾对礼品卡属性接下来创建礼品卡产品。操作路径是销售 产品 创建产品类型建议选服务——因为礼品卡不是一个需要库存管理的实物商品而是一种服务型的预付凭证。在产品的销售选项卡里有一个礼品卡勾选项把这一项勾上就完成了核心配置。价格方面有两种主流做法一是把售价设成一个固定面值比如 100 元、300 元、500 元适合标准化销售二是把价格留空让销售人员在下单时手动输入面值适合面值不固定的场景。最容易被忽略的是税率。在不少法域礼品卡的销售在税务上属于预收款不应在售卡时就计销项税而应在核销时再按实际消费的商品税率处理。如果你在礼品卡产品上配置了正常税率会出现售卡时交一次税、核销时又按商品交一次税的情况。我在项目里都会先把礼品卡产品的税率设为免税或 0%同时备注给客户的财务负责人务必按当地税务要求复核。3.3 卖出礼品卡并激活卡代码礼品卡产品创建好之后正常的销售流程是新建销售订单加入礼品卡产品确认订单并开票、收款。订单确认后Odoo 会生成一条礼品卡记录里面包含唯一的卡代码、初始余额、关联客户、过期日期等信息。卡代码可以理解成这张卡的钥匙。客户后续下单时输入代码系统会根据代码找到对应的礼品卡记录核销余额。代码的展示位置通常在销售订单的其他信息选项卡中或者直接以链接的形式显示在订单确认界面里。虚拟码模式下你可以在这一步把代码复制出来发给客户。电子钱包的初始入账则不是靠销售产品而是通过后台的钱包账户来操作。在客户表单上会有一个钱包相关的标签页你可以直接关联一笔钱包账户并调整余额。常见的入账方式包括手动调整余额适用于退款补偿以及通过退款单的退到钱包功能自动入账。4. 结账环节的实操礼品卡和钱包余额如何正确扣减配置完成只是第一步真正考验系统的是结账环节的闭环。礼品卡和电子钱包在销售订单里的支付逻辑和普通线上支付有点不一样下面几点是我实际测试中比较关键的。4.1 在线结账时选择钱包支付当一个客户提交订单时如果他的账户里有钱包余额结账页面会多出一个钱包余额的支付选项。客户选择之后系统会显示当前可用余额并允许客户输入本次希望使用的金额。这个过程和支付宝、微信支付的体验类似但需要注意一点钱包支付本质上是内部账务划转不是在线支付通道。如果订单总额超过了钱包余额客户需要同时选择另一个支付方式补齐差额。Odoo 的支付界面对这种组合支付的支持很灵活我建议在测试环境里至少跑一遍钱包余额 银行卡的组合支付确认支付行记录和余额扣减都正确。给客户端的提示文案也很重要。默认提示可能不太友好我配置时一般会写当前钱包余额 ¥XX本次可使用剩余金额请选择其他支付方式避免客户看到一堆技术术语产生困惑。4.2 部分支付、混合支付与余额拆分逻辑再讲一个实操中很容易误解的地方一张面值 500 元的礼品卡客户分三次消费第一次扣了 200 元第二次扣了 100 元第三次想全部用完这时候系统怎么知道卡片还剩下多少钱Odoo 会在每次核销后实时更新礼品卡记录的余额这个余额存在卡记录上而不是存到订单里。下次使用同一张卡时系统读取的是最新余额所以不会出现卡片被重复消费的问题。关键是别把卡代码当成一个静态字符串——客户第一次支付之后代码没有变但代码指向的卡片记录余额已经变了。电子钱包的逻辑类似但多了一个账户维度。每个客户可以有一个主钱包账户余额在账户级别统一管理。这样客户购买时不需要处理一张张卡系统直接从钱包账户里扣减。如果你需要同时支持多张礼品卡在同一订单中使用就要在订单支付行里分别录入每张卡的代码和金额Odoo 支持这种逐行核销的方式。4.3 退款到钱包是我最推荐的策略Odoo 19 的电子钱包天然支持退款到钱包的场景。客户退货时创建退货单并选择退款退款方式里可以指定退回电子钱包。系统会自动增加客户钱包余额同时生成对应的会计条目。这个操作表面上只是改变了退款路径实际上对业务的帮助很大一是退款不再经过第三方支付通道省下一笔手续费二是退款留存率明显提升客户账户里有余额复购的意愿会更高三是账务更简单退款不再牵扯到信用卡、支付宝等外部流水。不过要注意退款到钱包之后客户如果长期不来消费这笔钱就一直挂在你的负债里时间久了可能成为一笔沉睡负债。建议每个季度跑一次余额报表清理长期未使用的钱包账户必要时通过邮件提醒客户使用。5. 客户门户端余额查询、转赠与自助核销Odoo 19 的一个优势是客户门户内置了对礼品卡和电子钱包的支持客户不需要打电话问客服自己就能看到余额、查看流水、使用礼品卡。这一节讲门户端的功能细节和扩展玩法。5.1 客户门户里的我的钱包客户登录门户后会看到一个我的钱包板块里面分开展示电子钱包余额和礼品卡列表。每张礼品卡会显示卡代码、面值、已使用金额、剩余余额和到期时间。顺带一提这里的展示模板是标准的如果你希望改成中文文案或者加上品牌 Logo一般要调整门户页面的模板新手实施顾问记得把这步列入配置清单。门户的余额信息是实时读取的客户下单后余额立即变化。我在实施完成后会专门测试一次门户外下单 钱包支付的全流程因为很多时候后台配置正确门户端样式却跑偏尤其是自定义主题下新板块的样式容易被漏调。5.2 礼品卡转赠场景怎么落地之前提到礼品卡转赠是社交平台上讨论度很高的话题。在 Odoo 里转赠的本质是卡代码的持有人发生变化技术实现并不复杂你把礼品卡的卡代码和链接发给朋友朋友在下单时使用这个代码即可。但纯手工转赠有几个风险点一张卡被转发给多个人码被公开在群里或者转赠之后原持有人不承认。实际业务中我通常建议配合权益码系统来做转赠。Odoo 可以生成一次性兑换码客户用兑换码去兑换自己的礼品卡兑换后具备排他性后续只能由兑换人使用。转赠场景还可以做成营销活动买一张两百的卡系统配置转发给你的朋友对方首次使用后你获得二十元钱包余额。这种社交裂变玩法在礼品卡体系里很成熟客户留存和拉新效果都不错而且 Odoo 的自动化规则能够很好地支撑。5.3 客户没有门户账号怎么办不是所有客户都在你的门户里注册过账号。线下门店的客户、代购客户、企业团购客户很可能既没有账号也没有注册意愿。这种情况下礼品卡照样可以用因为核销本质上只需要卡代码不强制要求门户登录。在门店收银场景中店员可以在销售订单里选择礼品卡支付输入客户提供的卡代码完成核销。如果连门店都没有只靠线上销售我建议客服可以把卡代码直接绑定到已存在的客户记录上或者干脆以匿名卡的方式在后台核销。但要小心匿名卡的核销记录对账相对麻烦最好配套一张内部登记表能追溯到渠道来源。6. 配置与使用中的高频坑位排查做实施和运维最耗时间的环节就是排查问题。以下三个坑是我在 Odoo 18、19 的项目里真实遇到过的每个都花了不少时间我在这里直接把排查链路和解决办法写出来。6.1 订单里选不到礼品卡产品现象产品明明创建了但新建销售订单时搜索不到。这个问题多半是产品的基础设置出了问题。排查顺序先看产品类型是不是服务再看销售选项卡里可销售是否勾选最后确认礼品卡属性确实已勾上。很多时候是产品类型选成了可消耗品或者产品在创建时被加上了服务追踪属性导致销售环节行为异常。还有一种情况是产品没有归属到正确的公司或产品分类多公司环境下尤其容易出现。6.2 钱包余额和实际对不上现象客户明明退了两笔款到钱包后台钱包账户里的余额却低于预期甚至出现负数。这是电子钱包最典型的对账问题。排查链路是先把客户账号对应的钱包账户调出来点击账本看每一笔流水的来源再对照源的退款单确认退款单上的支付方式是不是真的是钱包最后检查是否有人重复提交了退款单导致同一笔退款入了两次账。负余额往往是由后台手动直接调整余额时填错数字造成的而账本功能可以把这类操作记录下来找到操作人就好办。另外如果你在开发环境里做过数据迁移还可能出现钱包账户和销售订单支付行关联断裂的情况表现为订单里显示已用钱包支付但钱包账户的账本里没有对应流水。这种要检查数据库中销售订单支付行的外键关联关系必要时通过技术支持重建关联。6.3 过期卡被后台任务误判作废不少商家设置礼品卡有效期后会出现一种矛盾场景客户手里拿着卡系统里显示正常但后台某个定时任务却把过期卡的余额自动清零了客户来投诉白投诉。问题根源在于过期策略的自动化程度。Odoo 的礼品卡记录有到期时间字段但到期后余额是否作废并不总是自动执行而是需要定时操作。如果你启用了自动作废的定时动作且卡片记录里的到期时间没有正确更新就可能误伤未过期的卡。排查思路是先看卡片记录上的到期时间是否正确再看定时动作的过滤条件是否覆盖了正确的卡片状态最后检查卡片的状态字段——如果状态已经变成已作废是否是因为动作执行日期设置错误。我建议在正式启用自动作废之前先在测试库用几张三张卡分别模拟正常卡到期卡已使用卡三种状态确认结果符合预期再上生产。7. 进阶扩展充值码、会员权益与第三方礼品卡市场的联动最后聊一下进阶玩法。如果你的需求不只是卖一张卡、核销一张卡而是想把礼品卡和电子钱包变成营销基础设施下面几个方向值得投入。7.1 用充值码把买会员变成送会员礼品卡转赠充值会员的场景在知识付费、游戏点卡、内容订阅行业非常常见。本质上是把会员资格变成一种可赋予的权益凭证。Odoo 里可以通过礼品卡产品 一次性权益码来实现客户购买礼品卡后获得一个权益码把权益码转赠给朋友朋友激活后一次性获得会员资格或等值余额。这种模式的好处是购买行为和消费行为被拆开你可以让 A 付款、让 B 享受权益客单价明显提升。我在一个内容平台的客户项目里落地过这个方案礼品卡渠道的 GMV 大概占了活动期间的 30%并且这部分收入的账务追踪比纯人工核销清晰得多。7.2 把礼品卡接到第三方卡商平台时的数据对接思路很多人会在电商平台上购买第三方礼品卡这催生了一大批卡商渠道。如果你想在 Odoo 里自建礼品卡体系同时和外部卡商平台对接最稳妥的做法不是让 Odoo 直接暴露内部接口给卡商而是走兑换码导入 核销状态回传这个模式。具体来说Odoo 生成一批兑换码在内部把面值和权益关系配置好然后将这批兑换码以文件或 API 的方式同步给卡商。卡商销售后把已售出的码回传Odoo 标记为已销售核销后状态再同步回去。这样做有三个好处一是卡商始终拿不到你系统的直接写权限安全性可控二是数据格式简单两边都好排查三是核销状态有一份明确的日志发生纠纷时能追溯。做这类对接时我特别强调幂等性。回传状态的消息如果重复了好几次Odoo 那边要能识别为同一条消息不能把同一个码核销两次。实现时可以考虑以兑换码 回调流水号作为唯一标识。7.3 报表监控礼品卡发行量、核销率与钱包负债礼品卡和电子钱包上线后一定要建立日常监控。我看数据主要看三个指标礼品卡发行量确认多少面值售出、核销率实际消费占发行量的比例、钱包负债总额客户钱包里躺着的钱。Odoo 的标准报表对礼品卡和钱包的支持不算特别丰富但你可以通过自定义报表或直接查看卡片记录和钱包账户的账本数据来实现。个人建议至少每周跑一次这三个数的快照一旦发现发行量很高但核销率长期偏低就要警惕是否卡券没被真正送达客户或者产品面值对客户不具吸引力。另外钱包负债总额会在资产负债表里体现为一项负债。财务同事问起来时你要能说清楚这个数字的来源最好附上客户明细列表方便审计时逐笔核对。我自己的体会是礼品卡和电子钱包在 Odoo 19 里的原生能力已经足够支撑大多数中小商家的业务场景真正决定项目成败的往往不是功能本身而是上线前的规则设计和上线后的对账机制。如果你正准备做建议先从小范围试点开始把礼品卡的售出、核销、退款到钱包这几条链路在测试环境完整跑通再逐步铺开到所有店铺。遇到比较特殊的业务规则优先考虑用 Odoo 的自动化动作和定时任务来落地而不是急着开发新模块。这样一套系统做下来你会发现客户预付资产的管理其实比想象中要简单很多。