35CRM 订单管理

要解决什么问题

销售侧数据往往分散在 CRM 的合同、订单、收款与开票模块里。人工在 Web 界面来回切换查列表、补跟进、录收款计划，既慢又容易漏字段。若要在对话里直接完成「查某张订单的跟进记录并补一条跟进」，需要一套稳定的 Token 认证、统一的列表查询与 viewId → insert 新建流程，还要处理 35CRM 对中文与 multipart 请求的特殊要求。

技能如何工作

技能把 35CRM 开放接口按业务拆成参考文档（authentication.md、agree_ment.md、contract_order.md 等），并在对话开始时 一次性 收集凭据，用 scripts/crm_login.py 校验后在本会话内复用 token 与 base_url。

常见路径包括：

• 列表查询：POST 到 /agreeMent/list、/ContractOrder/list、/PayPlan/list、/Invoice/list 等，可配合 scripts/crm_query.py。
• 新建记录：先走对应 viewId（如 ContractOrderAdd）取表单，再 POST 到 .../insert，由 scripts/crm_form_submit.py 走通用表单提交流程。
• 跟进类：合同跟进（agreeMentFollow）与订单跟进（ContractOrderFollow）与主单据分开建模，列表与新增各有独立文档。

解析响应时，行数据通常在 resp.get('rows') 或 resp.get('data')；提交日期需为 Y-m-d H:i:s（含时间部分）。

适用边界与注意点

• 含中文的请求 必须通过 Python 脚本 发出，不要用 Bash 直接 curl（见 base.md）。
• multipart 上传需按技能说明用 curl --data-binary @- 经 subprocess 发送。
• 技能覆盖的是文档索引中的查询与新增；复杂审批流、权限模型或 UI 专有逻辑以 35CRM 实际配置为准，调用前应对照对应 .md 里的字段与 enums.md 中的通用结构。