Curious if I ran into some kind of temporary bug: I have a Map/Reduce script that is used to send credit memos, but marks them as sent so they aren't processed again. It runs the following SuiteQL query. We filter out ten years worth of older credit memos that existed before the script was put into service using the transaction.id:

SELECT id, entity FROM transaction WHERE type = 'CustCred' AND custbody_sent != 'T' AND id > 16000000

However, yesterday morning, this query returned over 400 old credit memos, all of which had an id less than 16000000. It has been used daily for seven months and this is the first time it happened. Is it worth contacting support? I can't reproduce it again. Has anyone ever seen an issue like this either in a standalone query or in a script?

For things you can’t reproduce, in my experience NS Support will just throw their hands in the air and not care. How much is your time worth? I find this sort of thing isn’t usually worth pursuing via support because it just gets annoying trying to convince them that a product we pay hundreds of thousands of dollars for shouldn’t randomly break.

Yes, my thoughts exactly. The sad part is, I am having a hard time convincing the users, and especially the controller, that there is not and never was a bug in my code. I also can't assure them it can never happen again, since it obviously did once, even though the logic dictates otherwise. My proposed solution is to add a redundant safety filter, to also filter by createddate, just as an extra safety precaution. The new admin thinks the issue is that SuiteQL is unreliable and I should convert all scripts using it back to saved searches instead, but I have seen saved searches break before too, so I'm not convinced that would be a good idea. I do understand their frustration with things not working as expected, though.

ids (internal id field) on records are not guaranteed to be sequential and not guaranteed to not have gaps in numbering. i would recommend using a different field that is more deterministic for your query (something like

createdDate

)

In retrospect, yes, we can not assume that NetSuite will never go back and re-use numbers that haven't already been used in the past, or that internal ids will always be positive integers, so we did implement the created date filter, and will eventually have to take the id filter out.