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赋值。
Paypal提供了API供用户调取付款的订单信息，编写SuiteScript调取这个接口可以实现一个功能简单的Paypal付款与NetSuite集成，从而为系统已有的发票（Invoice）创建付款（Payment），对没有发票的订单创建客户存款（customer deposit）。本文仅提供思路和技术要点，并不是可以运行的代码；而实际应用场景中，由已有的逻辑可以灵活扩展到更多的功能。 前提 系统已有其他的方案集前台电商网站（BigCommerce、Shopify、Magento等等），电商网站的订单会被同步到NetSuite中。 设计要点 本章节对方案的一些技术要点着重介绍一下。 Paypal API的验证类型 Paypal采用的是OAuth2.0验证，因此每次请求之前需要先获取token，然后请求数据。对于Paypal的token获取请求和请求数据的请求，都需要在请求的头部声明'Accept': 'application/json'，否则会提示错误MEDIA_TYPE_NOT_ACCEPTED。 Paypal API的选择 我选用的是https://api-m.paypal.com/v1/reporting/transactions，这个请求的结果包含了所有的客户付款、手续费等等信息，对于客户付款的记录则包含了币种、发票号码的信息。这个API我使用了3个参数：时间范围、状态、类型。 你可能也可以选取其他report类型的API，或者在transactions的API上找到更多功能。具体参考https://developer.paypal.com/docs/api/transaction-search/v1/#search_get Paypal API请求数据的时间问题 Paypal使用的是UTC时间戳，没有时区背景。所以为了避免混乱（此方案将在中国使用，而客户主要是北美）推荐使用前一天日期。 功能流程 方案开发完成将是一个MapReduce的脚本，每天在运行一次，获取前一天的结果。 在getIntputData阶段，请求数据，并生成一个多行的自定义记录，每一行包括了如下信息： 在Map阶段，对于状态不是已核销的自定义记录，查找Invoice的编号和状态，尝试创建payment或customer deposit，对必填字段赋值。 在Summarize阶段，对成功与失败的记录生成log，给管理员和财务人员发送提示邮件。
对于只有正式账号，没有沙盒账号的环境而言，不太需要在设计的时候考虑接口与沙盒环境的兼容性。而对于一部分有多个沙盒账号的环境而言，沙盒的兼容性尤为重要，否则刷沙盒可能造成外部系统的混乱。 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:
跳板机装好Nginx之后在/etc/nginx/nginx.conf中，在http模块下定义好include，以便使配置模块化 这样在conf.d中的所有conf文件都可以被读到。 在conf.d中创建一个文件proxy.conf，并且写入以下内容 这样就初步配置好了一台跳板机