Hi all! I am running into an issue when programmatically creating a customer payment and I am super stuck. I am getting the error:

INVALID_KEY_OR_REF
Invalid class reference key ERROR: Field 'entity.custentity_cclass.id' Not Found for subsidiary 2.

whenever I try to programmatically create a payment in a sandbox environment. I have tried 3 different ways to make the payment and all caused the same exact error:

+---+---------------------------------------+----------------------------------------------------------------------------------+
| # | Entry point                           | Request                                                                          |
+---+---------------------------------------+----------------------------------------------------------------------------------+
| 1 | SuiteTalk REST, direct create         | POST /services/rest/record/v1/customerpayment with a JSON body                   |
| 2 | SuiteTalk REST, transform             | POST /services/rest/record/v1/invoice/{id}/!transform/customerpayment            |
| 3 | SuiteScript 2.1 RESTlet using         | Server-side, our own code, isDynamic: true, ignoreMandatoryFields: true          |
|   | record.transform() + record.save()    |                                                                                  |
+---+---------------------------------------+----------------------------------------------------------------------------------+

When I manually create the payment in the UI it works with no issues. For the setup I confirmed all of this: • OneWorld account, I'm creating the payment in subsidiary

2

. • Customer record has a custom entity field

custentity_cclass

(List/Record → Classification). It's a custom field, not the default

class

field on the customer. • The custom entity field has nothing configured under "Validation & Defaulting" or "Sourcing & Filtering" — both tabs are empty. No default value, no formula, no source list/source from, no filtering criteria. • The customer's

custentity_cclass

value is

1

("Retail & Distributor Sales"). • Class id

1

is valid, active, assigned to subsidiary

2

, and has the "Include Children" checkbox checked on its subsidiary assignment. • Manually creating/saving a Customer Payment in the UI for this customer with the class set succeeds. • Everything is set to active - the class, the subsidiary, the customer, etc I have tried all of these ideas so far but none of them work: 1. ignoreMandatoryFields: true on record.save(). No effect. 2. enableSourcing: false — confirmed not applicable, docs say it's standard-mode only and we use isDynamic: true. 3. Explicitly setting class to '1' on the payment before save. Same error. 4. Different class assignment. Tried with a different class that's directly assigned to a child subsidiary of 2 (rather than relying on "Include Children" inheritance from 2). Same error. So the failure isn't sensitive to whether the class is inherited via the parent or assigned directly to the child. 5. Two different customform ids — both the bundle's default form and the customer's own form (the one the UI uses on a successful save). Same error on both. 6. UI parity check. Captured the actual form POST the UI sends on a successful save. Identical customer, subsidiary, class, undepfunds, payment, trandate. UI: success. Same fields via SuiteScript: failure. 7. Logged the assembled payment record before save() — subsidiary=2, class=1, entity=<customer id>, custentity_cclass=1 on the customer. Nothing obviously wrong. 8. Debugger. Can't use the SuiteScript Debugger — no role in the account has both Debug Scripts and Customer Payments permissions. Does anyone have any ideas whatsoever on anything else I can try? Or any ideas about what might be going on? I am super stuck and confused about how 3 completely different ways of programmatically creating the payment failed but the same exact payment can be created in the UI with no issues

AI generated answer (using internal Slack threads):

Based on the conversations, it seems like you are encountering an issue with the

custentity_cclass

field when trying to create a customer payment programmatically. This issue could be due to a number of reasons, but here are a few things you could try: 1. Check the field level permissions for the role you are using to run the script. Even though the field is not mandatory, if the role does not have permission to access the field, it could cause this error. 2. Try to use the internal id of the class instead of the name. Sometimes, NetSuite can behave unexpectedly when using names instead of internal ids. 3. Check if the field

custentity_cclass

is available and accessible in the context of the script. You can do this by logging the entire record and checking if the field is present. 4. Try to create a customer payment using SuiteTalk SOAP web services instead of REST. Some users have reported that they were able to bypass similar issues by using SOAP instead of REST. 5. Check if there are any workflows, scripts or SuiteCloud Plus processes that might be interfering with the creation of the customer payment. 6. Try to create the customer payment in a different environment (like your production account) to see if the issue is specific to your sandbox account. Remember, the order of setting field values matters in SuiteScript, as it triggers events, sourcing, etc. So, try to follow the sequence from the UI form. ****** Disclaimer: This response was generated by an artificial intelligence assistant based on previous conversations from multiple Slack channels, and may contain inaccuracies or mistakes. ******

Hmm unfortunately none of those explanations look feasible to me. I confirmed that the role has permissions to access the field and I was using the internal id. I know that it works in other company's accounts but i cant test in this one's prod until it works in their sandbox. I'm skeptical that if REST and restlets didnt work that SOAP will work. I dont see any workflows, scripts or SuiteCloud Plus processes interfering but it is possible Im missing something.

Hi, I stumbled across your post here, and I had a couple of things to consider: • This is Restlet code, not requests to ReST Web Services, correct? • You're setting fields on a record loaded in dynamic mode, so it should work the same as the UI (which you confirmed works). • The last bit of the AI advice is something I've encountered. Have you made sure to set the fields in the same order as you do when setting them in the UI? AI said, "Remember, the order of setting field values matters in SuiteScript, as it triggers events, sourcing, etc. So, try to follow the sequence from the UI form."

hi! I would love any ideas you have! Yeah the first 2 things I tried were using REST web services and the third was using a restlet because I knew that it is much more similiar to the UI which I knew worked. Ooh you might be right about that ordering, I thought that I had it in the right order but let me double check exactly what Im doing there, one sec

Because if you set the field that holds a Class reference, and then afterward set a field like Subsidiary, then the fields that hold subsidiary-dependent values such as Class references will reset and have empty values again.

Ooh very good theory, I am trying it and will let you know. Thank you so much for the idea you are amazing!!!

nothing does except that I can't tell what entity.custentity_cclass.id has to do with it. The error happens at step 11. save()?

yup, I also have no idea what that has to do with it! Im starting to think maybe I have a script that I missed that is messing with it?

calling Record.save() in a ReSTlet will trigger all user event scripts and workflows, so I'm leaning toward that idea too.

mmm let me look closer there and see what there is to see

On the other hand, saving in the UI does that too and you didn't have any problems there. However, UE and workflow deployments can have their execution context filtered to only run on certain kinds of contexts, so you can filter out restlets or User Interface for example. Maybe that made the difference.

yeahhh it would make so much more sense if it didnt work in the UI either!

Narrow down the possibilities. Comment out all your Record.setValue calls except the "customform" one, then see if it runs successfully. Then uncomment half of them and run again. If you find a configuration where it works, then the problem was with either a value you set or the order you're setting them. Also before the Record.save() call, retrieve and log all the current field values that you changed, one more time, to confirm that they're all still set to what you set them to. That way you'll know if the ordering is the problem or if it's something else that's happening on beforeSubmit or afterSubmit. Actually, do that right-before-save logging before trying anything else. Then you'll know if you need to look at your Restlet code at all anymore before doing any commenting/uncommenting. Wait nevermind, looks like you already did that now that I'm reading over your post again.

thank you so much for all of your help today! After some investigation I found a couple of workflows not visible with my developer account but visible via some suiteql queries I could make with higher permissions. I don't have permissions yet to see what they actually do (and it doesnt seem visible via suiteql) but they are named in a way that defs makes me think they are messing with classes. Tomorrow Ill try to get more permissions and figure out if this is really the issue but Im feeling optimistic. If you are curious (or for anyone in the future trying to debug a similar issue) these are a few more things I tried that didn't work: • I made the restlet make the simplest payment possible to eliminate it being some weird ordering bug or something else with most of our code and got the same error • I tried both with and without dynamically setting the fields in the restlet - it was a stretch idea but worth a shot imo, didnt work same error • I temporarily disabled the one script that runs when saving payments that I couldn't see the source code for and tried again - same error, • A bunch of other random restlet tweaks, just trying anything I could think of, same exact error no matter what I did again thank you so much for the help! Ill try to update with whatever I end up finding out

Glad to hear you were able to isolate the problem!