https://netsuiteprofessionals.com logo
Join Slack
Powered by
How does everybody handle Transaction ID (tranid) ...
# suitescript
b
How does everybody handle Transaction ID (tranid) duplicates when running concurrent creates? What's the best approach you have seen?
e
I've never seen this happen before. Are you getting an error when it does?
m
Turn off the ability to override the auto created transaction number
a
The out of the box way and probably the most straight forward way to prevent duplicates is to use external ID because it is designed precisely to prevent that.
☝️ 2
🎉 1
b
b
I don't think external Ids are the solution, the external ids can be different on those transactions, but the tranids are still generated the same. The tranids are Autogenerated by netsuite on save already. The setting to override is off as well
a
Is a normal best practice to use pre-fixes for records, so IF-1234 should never collide with SO-1234 in which case you can use external id to effectively prevent duplicates
✅ 1
b
That wouldn't help, the issue would still happen in records of the same type being created concurrently. Also, externalid would only prevent the record from being saved if there's already another record with the same externalid, not with the same tranid
I've thought of a couple of ways to achieve this. This is one of them: 1- Turning on override 2 - Setting the tranid to a Unique identifier on beforeSubmit This would ensure no duplicates
a
I've never ran into this issue... so you're saying there's a delay in the NS counter between when its asked for and provides the next tranid for a create, and when it will increment to the next one for the next request? and you're able to create another transaction in that window? so you end up with duped tranids?
I want to say that shouldn't be possible, but I've seen NS do weirder things i guess... still it feels like this is just basic DB stuff, the process/logic for it should just be the same as internal ids, you shouldn't be able to get dupes, but somehow they made that possible?
b
the usual case here is that the document number allows overrides
which will generate duplicates when two transactions are created at the same time, which is primarily caused by the document number being set before the transaction is saved
b
Recently I ran into this specifically with Checks record, getting tranids (Check#) duplicated
But yeah, Document Override is OFF, Netsuite is handling the generation of those TranIDs. Anyways, I may be an edge case
And note: The rest of the IDs are not duplicated, the internal ids, etc... are unique, it's just the tranid that has this issue
Also, I am running a Map Reduce with 15 queues creating checks simultaneously
b
are you sure you are describing the problem correctly?
checks numbers doesnt allow override
b
Correct, that's not even an option, and for the record: none of my other transaction records have allow override set to true either
For the checks issue I had to turn concurrency off for my M/R but something inside of me died
Give it a try, create a M/R, set it to create checks with dummy data array being passed to the the reduce stage so each instance creates one check, set concurrency to MAX and observe the tranids getting duplicated
I have the record.create set to dynamicmode: false btw
b
the usual for netsuite check transactions isnt usually to have auto numbering for checks
you probably want to check with support to see if you can disable that feature
so that you can use Generate TranID on Save
b
Well I am not setting that number, the field help says that Netsuite Automatically fills that value, and something about grabbing the largest value. I'll contact support, interesting that the article lists Check as a record that can be configured, I don't have that listed in my account
b
usually checks automatically generate the tranid when its loaded, before its saved
it does the numbering differently its that its based on the bank account and not the usual auto numbering preferences
you are describing something unusual in that you have an allow override option in relation to checks which is non standard
b
I don't have an allow override option on Checks
b
you shouldnt, which is why describing the problem as document override is off is unusual
it shouldnt be an option in the first place
b
I've seen this happen in other records that do have that option
b
if your account is normal, then when you create a check, by default, it will generate the next check number as the tranid (before the transaction is saved)
b
I mentioned the Check because that's what I am seeing right now
b
finish following the instruction in the link i gave to configure checks so that the tranid is generated on save, not before
without doing so, the standard behavior for checks is to generate the id before save, which guarantees duplicates on concurrent transactions
🙌 2
a
yeah check numbers is different beast, you buried the lede not mentioning that upfront 🙂
b
Is this setting form-dependent?
I only see instructions on how to set it via form
b
correct, you want to show it on the form to actually be able to set it
if you are desperate, you can try not showing it on the form, but i wouldnt trust hidden fields to behave how you would want them to
b
Interesting. This is so odd. Now it works, the numbers jump all over the place, they aren't sequential anymore but there's no duplicate. Thank you!
I set the setting on the preferred form, the checkbox is hidden, but defaulted to Checked. I am not setting the form in the script, it automatically picks that one. I am guessing if someone were to change the preferred form to another one this would break. I should explicitly tell the script which form to use
Update: seems like this thing can be set using Suitescript, avoiding the form checkbox, it's undocumented though but doing this works: checkRecord.setValue({ fieldId: 'generatetranidonsave', value: true });
s
yes,I always set the form to check the generate tranid on save. then you can override as needed.
40 Views
Open in Slack
PreviousNext
Powered by