很多团队从“需要哪些页面和功能”开始商城立项，随后才发现价格不是一个字段、订单不是一张表、库存不是一个数字。真正影响范围和风险的是业务关系。下面七个问题，应在进入详细设计与开发前形成可评审结论。
一、谁在卖，谁在买
品牌自营、平台招商和供应链协同看似都有商品、购物车和订单，但参与角色完全不同。平台商城需要商户入驻与治理，供应链商城需要供应商和渠道商，角色变化会直接影响数据权限、订单责任和后台工作台。
二、价格由谁决定
要区分基础价、渠道价、会员价、协议价和促销价，并明确它们的优先级、互斥关系、生效范围和修改权限。若价格规则没有被建模，越到联调阶段越容易出现“页面显示对、结算金额错”的问题。
三、库存承诺如何兑现
用户看到的可售数量，可能来自总部仓、区域仓、门店或供应商。系统必须知道库存何时占用、何时释放、缺货如何改派、拆单如何处理，以及售后完成后库存回到哪里。
四、订单由谁履约
自营发货、商户发货、供应商代发、门店自提和同城配送可以同时存在。每种方式需要清晰的任务触发、时效、异常处理和售后责任，不能只在订单上增加一个“履约类型”字段。
五、资金怎样流转
确认收款主体、支付渠道、退款责任、分账规则、账期、结算单和对账方式。涉及平台与多商户时，资金路径必须同时经过业务、财务与技术评审。
六、哪些系统是主系统
ERP、WMS、CRM、POS 与商城之间不能都维护同一份主数据。需要为商品、价格、库存、会员、订单和财务分别确定主系统、同步方向、频率、失败补偿和人工处理入口。
七、上线如何判断有效
“商城上线”只是技术结果。立项时应定义用户路径、运营效率、履约质量、资金准确和系统稳定等验证指标，并为每个指标明确数据来源与统计口径。
把答案变成可交付的蓝图
七个问题的结论应进入角色关系、业务流程、规则清单、系统边界和验收用例。只有当业务、运营、IT 与财务对这些内容形成共同理解，功能清单和开发排期才有可靠基础。
继续阅读：商城项目如何避免延期