Proposal summary
This proposal covers the scope of implementing Donor Portal – NetSuite APIs for Pending Donation.
The portal will be able to create a new pending donation record, cancel a pending donation, and
fetch details of all the pending donation records from NetSuite using the APIs.
Requirement
The requirement is to implement NetSuite APIs that can be triggered from the donor portal for the
following functionalities:
• Create a ‘Pending Donation’ record in NetSuite when a donor initiates a donation through the
portal. The details of the donation will be sent to the NetSuite side via the API call to create
a custom ‘Pending Donation’ record.
• Update the status of a ‘Pending donation’ record in NetSuite to canceled when a donation is
canceled on the portal side by the donor.
• Fetch the details of all the ‘pending donation’ records on the NetSuite side for synching the data
with the portal records.
Whenever a ‘Pending donation’ record is created/updated on the NetSuite side, the data along with
the support fee value needs to be posted to a portal URL in the request structure provided by the
CFS portal team with additional security header parameters if any.
Deliverables
The first request is the ‘createPendingDonation’ API call, where the request should contain
all the pending donation record mandatory fields as parameters: ‘Fund name’(internal id to
refer to the fund), ‘Donor’(internal ID of the donor in NetSuite), ‘Date’(date of submission in
[‘YYYY’, ‘MM’, ‘DD’] format), ‘TD/NTD’ (specify the internal id for TD/NTD field), ‘Incoming
effect’( Incoming effect field value), ‘Payment type’(list option internal id), ‘Item’(related
item internal id in NetSuite), ‘Amount’(amount of the donation).
• If all the parameters in the ‘‘createPendingDonation’’ API call is valid then, a new ‘Pending
Donation’ custom record entry should be created and a success response should be returned
as a response. If the request is not valid or record creation fails, then an error response should
be returned to the Portal with the details.
• The second API request ‘cancelPendingDonation’ should have the internal ID of the ‘pending
donation’ that needs to be canceled and an optional ‘reason’ parameter. The script should
check if the internal ID is valid and ‘Pending donation’ is still in ‘pending’ status. If the record
is in ‘pending’ status, it should be changed to the ‘cancelled’ and a success response should
be returned to the portal side. If the internal ID is not valid or the record is not in ‘pending’
status, then an ‘Invalid request’ response should be returned with the reason for the error.
• The third API request ‘fetchPendingDonations’ will have the ‘Page index’ value as a
parameter. If the request is valid, then the NetSuite script should return the details of all the
pending donations in chunks. If the script fails to fetch the data, then an error response will
be returned with the reason of the error.
• Add a script to trigger on creating or updating the pending donation record and post the
data with the support fee value of that pending donation record to a CFS Donor portal. The
data will be structured similarly to the ‘‘fetchPendingDonations’’ API along with the
event(Create/Edit).
Assumptions
• The NetSuite list/record internal ids, donor ids etc. should be available at the portal side for
including in the API request.
• This proposal only covers the implementation of the following:
o API requests send to the NetSuite side from the portal for creating and cancelling
‘pending donations’
o API requests send to the NetSuite side from the portal fetching the details of all the
‘pending donations’ for synching the data.
o Script to post pending donation data to a Portal API from NetSuite on
creating/updating a pending donation in NetSuite.
• The expected request body structure for the ‘createPendingDonation’(POST) will be like the
following:
{“apiType”:” createPendingDonation”, “fund_name”:”123″, “donor”: “201”, “trandate:
[“2023″,”8″,”18”], “td_or_ntd”: “1”, “incoming_efffect”: ”123”, “payment_type”: “1”, “item”: “101”,
“amount”: “1000.00”}
• The response for the ‘‘createPendingDonation’’ (POST) will be like:
{ “summary”: {“status”: “SUCCESS”, “reason”: “RECORDS_CREATED”, “error”: []} }
• The URL and headers of the API for posting data to the portal after pending donation
creation/edit should be provided by the CFS portal team.
• The internal id returned to the portal after creating/updating a ‘Pending Donation’ record
should be stored in the portal donation record. This internal id should be provided in the
‘‘cancelPendingDonation’ request as a parameter.
• The expected request body structure for the ‘cancelPendingDonation’ (POST) will be like the
following:
{“apiType”:” cancelPendingDonation”, “internal_id”:”2034″, “reason”: “Testing””, “updatestatus”:
“3”}
The ‘updatestatus’ field value is the internal id of the ‘Cancelled’ status. Any other values will return
error.
• The response for the ‘cancelPendingDonation’ (POST) will be like:
{ “summary”: {“status”: “SUCCESS”, “reason”: “RECORDS_UPDATED”, “error”: []} }
• The expected request URL structure for the ‘fetchPendingDonations’ (GET) will be like the
following:
Base URL + “&apiType=fetchPendingDonations&pageIndex=NUMBER”
• The response for the ‘fetchPendingDonations’ (GET) will be like:
{ “summary”: {“status”: “SUCCESS”, “reason”: “RECORDS_LISTED”, “error”: []},
“data”: [ “pageInfo”:{“pageLength”:10,”pageIndex”:1,”isLastPage”:false},
“fields”: [{ “internalID”: {“value”: “1”, “text”: “1” }, “inactive”: {“value”: false,”text”: null},
“fundname”: {“value”: “123”, “text”: “TEST”}, “donor”: “1234”, “trandate: [“2023″,”8″,”18”],
“td_or_ntd”: “1”, “incoming_efffect”: ”123”, “payment_type”: “1”, “item”: “101”, “amount”:
“1000.00”}, ……… ] } }
• Note: The request structure provided above is based on the initial analysis and might change
during development.
• The list/record field values in the API requests should be sent as a string of the internal id of
the record entry or list option in the NetSuite account.
Risks
• NetSuite has a concurrency limit of 5 in processing API requests. If more than 5 API requests
are sent by the portal to NetSuite, only the first 5 requests will be processed.
• If an API request is failed, it should be handled by the portal by resending the failed requests
again.
• If the data is not correctly passed in the specified format, the API will return an error.
• The real-time sync request from NetSuite to the portal should return a sufficient response.
• If the real-time sync request from NetSuite to the portal fails due to NetSuite/Portal issues,
then the data in Portal needs to be synched via the ‘fetchPendingDonations’ API.
Estimate
Estimated Effort: 30 hours