How can I batch invoices into customer payments using the REST API?
Hi all,
Having trouble creating/transforming invoices into customer payments using the REST API. I have no issue transforming an invoice into a customer payment like so:
POST {{REST_SERVICES}}/record/v1/invoice/4960/!transform/customerpayment
However I’d like to add multiple invoices to a customer payment in one API call, and I’m not sure how to do that. When I structure my request like this;
I get the following error:
Hi Jonathan,
Do you have a way to determine which Invoices you’ll apply the payment to?
Thanks,
Chris
Hey Chris,
Yes, I want to specify the invoices which I will turn into a payment. As in, I know I know I want to add a customer payment using invoices 1 and 2, so I’d like to either transform a customer -> customer payment using those invoices, or create a new customer payment using those invoices.
I had issues doing this with 2020.1, but I”m upgrading our sandbox to 2020.2, so I’m going to try and take advantage of the new invoice grouping feature to accomplish this
Hi Jonathan,
Invoice grouping may well get you to the end result from what I’ve seen but I don’t think it’s included in any of the documentation at the moment.
In case you loop back to some of your original thinking, I believe this is the sort of area you’d need to look at in order to update the apply sublist:
https://netsuite.custhelp.com/app/answers/detail/a_id/87133
The keys in question should be the references to the invoices that you want to pay.
I hope this might help and, equally, I’ve done a little playing around with Invoice Groups so please feel free to give me a shout if you want to discuss anything in that area too.
Thanks,
Chris
Thanks a lot Chris!
One of the reasons I want to try 2020.2 is I had issues with updating the apply sublist. I may have gotten the calls incorrect, but i kept getting the error in my first post whether I created a new cust payment or transformed a cust to a cust payment.
They added a “doc” field to the apply sublist in 2020.2, so I might use that if invoice grouping doesn’t work.
FYI I successfully batched invoices into customer payments using 2020.2 and the following request:
{{REST_SERVICES}}/record/v1/customer/144/!transform/customerpayment
{"externalId": "PYMT-test","apply": {"items": [{"apply": true,"doc": {"id": "201"},"amount": 0.01},{"apply": true,"doc": {"id": "12"},"amount": 0.01}]}}
Thank you for posting! The doc property got me what I needed, I was frustrated trying to find the way to define the relationship between the apply prop and the actual invoices.
Chris, I would love to hear how you’ve navigated invoice grouping using the REST API. So far I’ve done the following:
- Enabled invoice grouping for the account
- Enabled invoice grouping for a specific customer
But I’m not sure how to go about actually grouping the invoices. Do I patch each invoice I want to group with an invoice group id, and then create a customer payment using that invoice group?
Hi Jonathan,
I’ve not tried through REST Web Services but here are some notes I made on using SuiteScript:
————————————————————————————————————————
[…] the sublist on an Invoice Group is not like that on a standard transaction. In fact, the relationship from Invoice to Invoice Group is stored on the Invoices themselves in these two fields:
- For Invoice Grouping (forinvoicegrouping)
- Grouped To (groupedto)
————————————————————————————————————————
Not sure whether those fields are available through REST. Also, contrary to what I believed to be the case, it looks like actions are supported and so it’s worth checking whether these actions are included:
https://netsuite.custhelp.com/app/answers/detail/a_id/87480
Thanks,
Chris
I posted back in March 2021 that the solution here was working well for me. 5 months later, changes in the REST API appear to have broken this. Some of our test cases now throw this error that were previously working on the same records with the same code. CustomerPayment is still a beta record, so I can’t complain.
Instead, we’ve been creating simple RESTlets one by one to replace REST API calls that have proven unreliable. Rock solid.