这是一个非常有趣的观察，当使用如下代码试图生成一个PDF时，SuiteScript会报错： 这里如果format是OBJECT，会报错提示 如果把format设置为JSON，则报错提示为 我尝试过使用JSON.parse()或者是用regex把输入的jsonArr进行整理，但是没有任何效果。最后我发现问题出现在json存在一个键是纯数字的，整理之后问题消失 作为JSON，它的键可以是数字或者字符串，但是可能是NetSuite内部的原因，键为纯数字的时候会报错，建议开发的时候注意。
Scenario A Restlet script used for importing orders populates ROUNDING_ERROR during the saving process of one order. When importing, the following data is passed for each line: Solution Based on one of the answers found on the internet (Reddit), it seems that setting taxtotal for items with istaxable=false can cause this error. However, this is... » read more
情况描述 系统中有一个restlet类型的接口用于传入订单，有一个订单在保存的时候提示ROUNDING_ERROR。在传入的时候每一行货品传入以下数据： 问题解决 根据互联网可以找到的答案之一（reddit）疑似是对istaxable=false的货品设置了taxtotal会造成这样的错误。但是这个不符合我的系统的情况。 最后发现问题是外部系统错误地传入了一个item=0的货品行，但是又同时具有其他的值如location、taxcode，触发了ROUNDING_ERROR，类似于下面的数据： 非常奇怪，这个错误提示应该是“货品不存在”。总之ROUNDING_ERROR的出现可能往往并不是准确的。
Transaction Type Type Code Bill VendBill Bill Credit VendCred Bill Payment VendPymt Bin Putaway Worksheet BinWksht Bin Transfer BinTrnfr Blanket Purchase Order BlankOrd Cash Refund CashRfnd Cash Sale CashSale CCard Refund CardRfnd Check Check Commission Commissn Credit Card CardChrg Credit Memo CustCred Cross Charge Journal XChgJrnl Currency Revaluation FxReval Customer Deposit CustDep Customer Refund CustRfnd... » read more
今天尝试使用render使用非custom form默认的PDF模板来打印一个销售订单的PDF文件。此代码片段来自一段user event脚本。 注意PDF_TEMPLATE_ID必须是myFile.addRecord的记录类型一致。比如template的类型是sales order，则addRecord的类型必须是sales order。 此外，注意需要加载subsidiary，否则可能会造成引用subsidiary部分的模板不能正常加载，例如header中放置的对应subsidiary的logo。 最后，不要忘记设置文件名。
这个和N/search的不同之处在于实际上customer和customersubsidiaryrelationship是两张分开的表，需要用innerjoin联查。 实例代码如下
这个问题困扰了我一阵子，在此做一个总结。 设置付款科目为Undeposited Funds 建议按照customer, date, currency, undepfunds, account, payment的顺序写入值。重点是先给account赋值为null，再给undepfunds赋值'T'。 按照以下例子赋值（代码片段仅供参考，不可直接运行） 设置付款科目为具体科目 建议按照customer, date, currency, undepfunds, account, payment的顺序写入值。重点是先写入currency，给undepfunds赋值'F'，给account赋值。
对于只有正式账号，没有沙盒账号的环境而言，不太需要在设计的时候考虑接口与沙盒环境的兼容性。而对于一部分有多个沙盒账号的环境而言，沙盒的兼容性尤为重要，否则刷沙盒可能造成外部系统的混乱。 Suitelet做endpoint 用suitelet作为接口确实有一些hacky（因为suitelet原生是不带验证的，一旦url被滥用可能非常尴尬），但是确实有开发者会使用它。 在外部系统调用suitelet的时候需要考虑的东西不会太多，主要是账号的后缀-sb需要正确，它意味着正确的系统环境；而h参数一样决定了访问是否成功。 对于suitelet类型的脚本每次刷新之后系统会更新h这个参数，因此你的url每次刷新都需要改变。 Restlet类型的脚本 Restlet脚本在沙盒兼容性上考虑的最少。 外部系统调用restlet的时候需要考虑到账号的-sb参数以及realm（针对OAuth1.0） 对于restlet类型脚本，每次刷新之后需要考虑重新创建Integration以确保获得正确的token和secret 其他脚本 其他脚本包括了所有可能通过http、https请求向外部发送请求数据的脚本，包括但不限于MapReduce, Scheduled, UserEvent等服务器端的脚本，实现的目的包括推送、更改、获取数据等等。 在设计上，有两种思路： 以上都需要用到N/runtime 如果应用了以上的设计思路，那么正式环境和沙盒环境可以实现脚本互相通用，刷新了沙盒环境也无需顾虑。如果没有采取以上的设计思路，则需要在沙盒环境刷新之后尽快调整脚本的部署，尤其是定时类型的脚本，比如MapReduce和Scheduled。
Scenario Paypal Authentication returns this error, although Content-Type: application/x-www-form-urlencoded set to Headers. Solutions Paypal didn’t say so, but they like Accept:application/json in Headers. So the header should be something like:
Replace & in the data source with & (will write about this issue with details and examples later)