I am creating a vendor bill with a scheduled scrip...
# suitescript
m
I am creating a vendor bill with a scheduled script 2.0. The transaction date could be in a prior period, for example 1/28/2020. I am using setText() to set the posting period to Mar 2020. However, this period will not stick. It always flips back to the prior period, in this case Jan 2020. Anyone know why this is happening?
b
make sure that your bill is approved
and that the accounting preferences allows transactions dated outside the posting period
m
Both are true. I am using the same function to build the text string 'Mar 2020' as a 1.0 script we use. The 1.0 then uses setFieldText() and it seems to work. Both create the VB in dynamic mode. When I hardcode the internal Id for the posting period and setValue(), it works also.
b
what does the code look like
m
Copy code
newVB.setText({
		fieldId : 'postingperiod',
		value : stolenGetPostingPeriod()
	});



function stolenGetPostingPeriod (){
	  var d = new Date();
	  var months = ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"];
	  return months[d.getMonth()] + ' ' + d.getFullYear();
	}
		  
};
b
Record.setText(options) does not use value as a parameter.
m
Oh my gosh. Thank you! I swear I looked at that like 10 times. Still a newbie....
s
I highly recommend using
setValue
and also TypeScript, because that call to setText would error out at compile time 🙂
for the record, not remembering details about an API is not 'newbie' shame. There is nothing to be proud of in memorizing NetSuite APIs in full detail.
m
Thank you both. I have a conceptual question: I just wrote a scheduled script to pull a saved search of custom transactions. I then need to create a sales order and vendor bill for each. I also need to load and write back information on the custom transaction from each new sales order and vendor bill. I just tried running 66 in a batch and got the USAGE error. Would this be a Map/Reduce use case or should I use multiple deployments and limit the results from the saved search?
s
it sounds like map/reduce could be a good fit here, but you could also keep it simple and just have the scheduled script run until it's out of governance, then reschedule itself. Assuming you can arrange your search to have previously processed transaction drop out of the search results so they don't appear in the next execution. You don't (necessarily) need multiple deployments, you could just have the scheduled script reschedule itself using N/task
m
oh cool. So would you use the getRemainingUsage() at the end of every each() and right before you run out, create a task to schedule it again?