翻自己的脚本库，同一个模型反复出现。一个SFTP上传的Suitelet，一个把保存的搜索结果写成CSV丢进文件柜的导出器，一个处理多段文件上传的模块，一个在CSV导入时校验日记账行的验证器，还有一堆ACH付款文件模板。 说这是巧合，实在说不出口。它总以某种形式出现。 钱，仍然以文件的形式流动 ACH文件是定长ASCII文本。每条记录94个字符，十条记录一个块，第一个字符说明这行是什么。1是文件头，5开始一个批次，6是一条付款条目，8关闭批次，9关闭文件。 最后两个字符很关键。它们携带计数、一个条目哈希，以及借贷总额，让接收方能拿文件自己校验自己。你手里的CSV大概没有这些东西。 ACH和ISO 20022的付款文件模板，包括SEPA，都放在一个公开仓库里。格式不同，思路一样：付款指令以文件形式传递，而这个文件长得完全不像一次API调用。 NetSuite托管不了那个文件夹 约束塑造了设计。Oracle的文档写明，NetSuite不提供SFTP服务器功能。SuiteScript 2.0确实有SFTP库，但只能单向工作——NetSuite连出去，连到别人的服务器上。每一次进出NetSuite的SFTP传输，都必须由SuiteScript发起。 所以当合作方说“我把文件丢给你就行”，那个文件夹其实在别处的服务器上，NetSuite得自己去取。这意味着一个定时脚本：连上去，列出目录，下载找到的东西，处理完再移动文件。N/sftp连接对象提供了全部方法：list、download、move、removeFile。 这往往就是整个集成。一个别处的文件夹，加一个定时脚本。 文件夹为什么一直赢 不是偷懒。文件会等。如果接收方整夜宕机，什么都不会丢，早上文件还在那儿。 文件也容易看。你可以打开它、读它，然后交给一位从没听过webhook的财务同事。它不在乎对方系统是用什么搭的。 代价在于，文件投递会以很无聊的方式失败，而且失败时没人被叫醒。 一次NetSuite的CSV导入可能部分成功、部分失败。Oracle自己的任务状态示例写的是“205条记录中导入200条”。没进去的记录躺在一个results.csv里。任务照样算完成了。至于有没有人打开那个文件，是另一个问题。 还能更糟。Oracle也说明，当导入后afterSubmit用户事件脚本失败时，记录其实已经创建或更新了，你只需要重试用户事件脚本，而不是整个导入。用Add模式重跑整个文件，你可能把每条记录都创建两遍。 把文件夹当成API来对待 规则是一样的，只是文件夹不会替你强制执行任何一条。 给文件加个尾部。借用ACH的思路：在最后一行放上行数和总计，让脚本在加载任何东西之前先核对它们。然后在加载任何一行之前校验每一行。部分导入是真实会发生的结果，所以别开始一个你收不了尾的导入。 请发送方用临时文件名上传，传完再改名，这样你永远不会拿到半个文件。 记录每一个处理过的文件，这样同一个文件被发两次也不会入账两次。 把原始文件原封不动移到归档文件夹。N/sftp有move方法，一个归档文件夹加一个错误文件夹，成本几乎为零。 把失败放到人能看见的地方，并且发消息告知。然后，当文件压根没出现时也要告警。沉默也是一种失败。 没人会在架构图上画那个CSV文件夹。但遗留系统拒绝改变，某个随机需求在最后一分钟冒出来，或者用户对传输方式的理解还没到位。按它大概率会发生来构建。 特别