零售分期计划跟踪与催款提醒

原文要点

该n8n模板用三条流共用一个Google Sheets台账：POST webhook（路径layaway-intake-0927）接收新分期计划，规范化生成plan_id（形如LAY-YYYYMMDD-1234）、balance_due和next_due_date，校验顾客名、商品和到期日后写入15列的Plans页并邮件确认顾客；每天08:00扫描进行中的计划，算days_until_due，0到3天为due_soon、超过为overdue，分别记入Alerts页并给客人发提醒，逾期件另汇总成一封升级邮件发店里（日期按Asia/Pontianak）；每月1号09:00把活跃计划数、欠款总额、逾期名单交给名为gpt-6-luna的聊天模型写180词以内的店长复盘。

这次做成什么

在n8n里搭好这套「录入→每日扫描→月度复盘」三段式收款管家，并用本站设计的一笔虚构分期订单和两行台账数据走通webhook录入与每日扫描逻辑，验证余额、到期日和提醒分类都算对。

准备什么

• 一个可公网访问的n8n实例（自托管需启用tunnel或正式域名）
• Google Sheets OAuth2与Gmail OAuth2凭据各一份
• 任一可用聊天模型的API凭据（模板里写的模型名gpt-6-luna需换成你实际可用的模型）
• 已建好的Google Sheet，含Plans与Alerts两个标签页
• 能发POST请求的表单或POS系统，或用curl/HTTP工具做测试

具体怎么做

1. 建台账表格

   新建Google Sheet，第一个标签页命名Plans，A1到O1依次填入plan_id、customer_name、customer_email、customer_phone、item、price_total、deposit_paid、balance_due、installment_amount、installments_total、interval_days、next_due_date、payments_made、status、created_at；再建Alerts页，表头为alert_id、plan_id、customer_name、item、alert_type、sent_to、sent_at、customer_email、office_email九列。

2. 接录入webhook

   在n8n添加Webhook节点，方法POST、路径填layaway-intake-0927；后接Code节点做规范化：用本站下方提示词逻辑生成plan_id、用price_total减deposit_paid算balance_due、按interval_days（缺省30天）算next_due_date；再接IF节点校验customer_name、item、next_due_date非空，空则走「拒收邮件」分支通知店办，非空则Google Sheets节点追加到Plans页，Gmail节点发确认信（金额、首付、余额、下期金额与到期日、计划编号）。

3. 接每日扫描

   添加Schedule Trigger设为每天08:00（确认n8n时区与店铺一致），接Google Sheets读Plans全表，Code节点对status非COMPLETE/CANCELLED的行计算days_until_due：小于0标overdue，0到3标due_soon，其余ok。两个分支各自先追加Alerts页再发对应邮件，overdue分支最后用一个汇总节点把本轮所有逾期计划拼成一封主题为「Overdue layaway plans:」的邮件发office_email。

4. 接月度复盘

   再加一个Schedule Trigger设为每月1号09:00，读Plans后用一个Code节点聚合出活跃计划数、balance_due总和、逾期笔数与逾期金额、due_soon笔数、按余额降序的前8名逾期顾客；把这些统计作为事实数据发给聊天模型节点（用下方提示词），输出180字以内的纯文本复盘，Gmail节点发给店长。

5. 用测试数据走一遍

   激活工作流前，用下方示例JSON向webhook测试URL发一次POST，确认Plans页多了一行且balance_due=2600000、next_due_date=2026-11-05；再手工把该行next_due_date改成明天，点每日扫描分支手动执行，确认它被判为due_soon并写入Alerts。

可直接复制的材料

你是零售店的收款复盘助手。下面是本月分期赊购台账的统计事实（JSON）：
{stats_json}
请用中文给店长写一封不超过180字的纯文本复盘邮件正文，要求：
1. 第一句给出活跃计划数和欠款总额（用「Rp」作货币符号）；
2. 说明逾期笔数和逾期金额，并点名余额最大的前3位顾客及其欠款；
3. 提醒即将到期（3天内）的笔数；
4. 最后给一句本月催收建议。
只输出邮件正文，不要标题、不要解释、不要编造JSON里没有的数字。

{"customer_name":"Budi Santoso","customer_email":"budi@example.com","customer_phone":"+6281200001111","item":"Kulkas 2 pintu","price_total":5000000,"deposit_paid":2400000,"installment_amount":650000,"installments_total":4,"interval_days":30,"office_email":"office@toko-example.com"}

plan_id,customer_name,customer_email,customer_phone,item,price_total,deposit_paid,balance_due,installment_amount,installments_total,interval_days,next_due_date,payments_made,status,created_at
LAY-20261005-0001,Budi Santoso,budi@example.com,+6281200001111,Kulkas 2 pintu,5000000,2400000,2600000,650000,4,30,2026-11-05,0,ACTIVE,2026-10-06

输入与输出示例

本站虚构演示，未实际调用原模板；金额单位按印尼盾示例，plan_id后四位由你的生成逻辑决定。

输入

向webhook发送上面的测试报文（Budi Santoso买冰箱，总价5000000、首付2400000、分4期、间隔30天），随后把Plans页里该行的next_due_date手动改成明天再触发每日扫描。

对应输出

规范化结果：plan_id=LAY-20261005-0001、balance_due=2600000、installment_amount=650000、next_due_date=2026-11-05、status=ACTIVE，Plans页追加一行，顾客收到确认信。把到期日改成明天后每日扫描判定days_until_due=1、标签due_soon，Alerts页新增一行alert_type=due_soon，顾客收到温和提醒；若改成昨天则标overdue，且店办会收到一封汇总升级邮件。

做完检查这些

• POST测试报文后Plans页恰好新增一行，balance_due等于price_total减deposit_paid，next_due_date按interval_days正确推算
• customer_name为空的报文不会写入Plans，而是触发拒收通知发到店办邮箱
• 把某行next_due_date改为昨天后手动跑每日扫描，该行被判overdue、写入Alerts且店办收到一封（而非多封）升级邮件
• status改为COMPLETE的行在每日扫描中被跳过、不再产生任何提醒

容易卡住的地方

• 模板原文把模型写作gpt-6-luna，这更像是作者自定义的凭据显示名，配置时必须在模型节点选择你账号里真实可用的模型，否则会报模型不存在
• n8n实例时区与店铺时区不一致时，08:00扫描和days_until_due计算都会偏移，需统一设置
• webhook测试URL与生产URL不同，POS正式对接前要在激活状态下用生产URL再测一次
• interval_days缺省值30在规范化节点里，POS不传该字段时余额期数不会报错但到期日全部按30天算，需在Code节点里显式兜底
• Sheets节点选错文档ID会静默写到旧表，五个读写节点要逐一确认指向同一文件