Export CDT To Excel Smart Service

Please see the details for the "Excel Tools" shared component in forum records. It has details about the smart service you have mentioned.

Regards,
Varsha

Configuring Export Cdt to Excel
In the Input Tab

CDT : Your CDT
CDT_fields_to_Export : Field in your cdt, open that cdt get the field names you are going to use
to export to excel they should be in the format {"fieldName1",
"fieldName2"}
Cell_keys: The keys you want to use to display data in the format of {"A1", "B1"} or if
you want to starting cell is "A1" if your starting cell is "A2", you will have the f
format of {"A2", "B2", "C2"} etc...
Cell_Values: values for your cells that will come from the CDT
Document_name_to_create: Name of the doc you want to create
Document_save_directory: the directory you want to save that generate document
Document_to_overwirte: Leave blank if you are not overwriting any documents
Excel_base_template: An excel template you can create to format the way you want that document
Put the cdt field names as cell headers.
Fail_on_error: Boolean to configure for failure, not required
include_header_row: not required, if you want to include a header row
Sheet_number: Determine sheet number, you can give it a value of 0
Starting_cell: Where you want to start displaying your cdt data in excel, could be "A1" or
"A2" or whatever cell you want to start

I hope that helps a little bit on how to configure it.

Thank you.

Thanks very much, it helped to understand what the node inputs are. After making changes to match the documentation I still get my error, so I guess I'll have to keep making stabs in the dark.

What is the specific error that you are getting? Also take a screen shot on how you are configuring each node, maybe we can see what you are passing exactly.

Regards,
Jerry

Sorry I meant to say a picture of each Input.

I am getting an error, "The following error was raised by the Export to Excel function: Cell index must be >= 0"

 

 

Cdt_fields_to_export uses cons!RM_EXPORT_REFERRAL_FIELD_NAMES which has the following values

id
priority
status
reason
primaryDiagnosis
primaryConcern
referringParty
intendedParty
referringProgram
intendedProgram
isVerbalConsentReceived
servicingProviderFirstName
servicingProviderPhoneNumber
referralOriginContact
referralDate
assignUser
createDateTime
referralClosureReason
lastName
firstName
dob
gender
account
clientCd
subscriberRelationship
groupId
sectionNum
zipCode
subscriberId

 

Cell_keys uses cons!RM_EXPORT_REFERRAL_EXCEL_COLUMNS which contains the values:

A2
B2
C2
D2
E2
F2
G2
H2
I2
J2
K2
L2
M2
N2
O2
P2
Q2
R2
S2
T2
U2
V2
W2
X2
Y2
Z2
AA2
BB2
CC2

 

Cell_values uses cons!RM_EXPORT_REFERRAL_FIELD_NAMES which contains the values listed above for Cdt_fields_to_export

Excel_base_template uses the template with the following format

 

 

Sorry for all the info, but thanks for helping out.

 

Try saving the cell values in a pv variable that can store multiple in the format below since you CDT input is called pv!cdt
{
pv!cdt.id
pv!cdt.priority
pv!cdt.status

}

One more question are the cell keys in the constant saved as an array of text also? The same question goes for the CDT_fields_to_export. Let me know if that works

the cell keys and cdt_fields_to_export are both arrays of text.

do you mean the cell values should have an array of literal field values as opposed to an array of symbolic field values?

if it's symbolic values, then it will be a static array and making it a pv vs. a constant is something i don't understand. or would it not be static because you need an array for every cdt passed in? so it would be an array of fields in an array of cdts?

if it's literal field values, then what is the purpose of "cdt", since "cdt" contains the literal values.

So what I am saying is that the cell values should be the actual values or data from the CDT you have. So pretty much the cell values are literal field values to answer your questions. This is the way we have gotten it to work on our end. I agree with you 100% if "cdt" already contains the literal values there is no reason to have to re use the literal values. As I have mentioned this is the way we got it to work for us. I haven't seen much thorough documentation about that smart service though.