This topic contains 3 replies, has 0 voices, and was last updated by pcutler 7 years, 4 months ago.

  • Author
    Posts
  • #18419

    Jarod Tavares

    I’m trying to build a custom record that describes how to pull multiple record types together for generating documents. That is, I’m using TemplateRenderer.addRecord() to accumulate what I need passed to a template. Fairly simple, or so I thought.

    I tried using a Record Type field to determine the type of the record and, in some cases, get the scriptid for use as the type with record.load(), but that appears limited to custom records, as other types I’ve tried just give an empty string. I mostly care about transactions, though, so for now I thought I would try using a Transaction Type field, but trying to pull a scriptid causes an error, and I can’t seem to pull any joined data whatsoever. As it stands, the best I can do is apparently creating a Free-Form Text field to store the record type for loading, but this is sub-optimal. I’m left wondering about the usefulness of Record Type & Transaction Type fields.

    What’s the best approach for specifying a record type for loading miscellaneous records in this situation?
    This is a cached copy. Click here to see the original post.

  • #18420

    erictgrubaugh

    Not sure I understand fully what you’re trying to do; or what exactly you need.

    How are you retrieving the necessary data for the records you want to pull into the template in the first place?

    Can you share some code?

  • #18421

    Jarod Tavares

    There’s not much code to share at this point, more like proof of concept to see if I can get at the data I need.

    Code:
    require([‘N/record’, ‘N/search’, ‘N/file’, ‘N/render’],
    function(record, search, file, render) {

    function onRequest(context) {
    var req = context.request;
    var res = context.response;

    var recordId = req.parameters.record_id;
    var renderDefId = req.parameters.render_def_id;

    var rdFields = search.lookupFields({
    type: ‘customrecord_render_definition’,
    id: renderDefId,
    columns: [
    ‘custrecord_rd_document_tpl’,
    ‘custrecord_rd_record_type’,
    ‘custrecord_rd_transaction_type’
    ]
    });

    var recordType = rdFields.custrecord_rd_record_type[0].value;
    var transactionType = rdFields.custrecord_rd_transaction_type && rdFields.custrecord_rd_transaction_type.length
    ? rdFields.custrecord_rd_transaction_type[0].value
    : recordType;
    var type = rdFields.custrecord_rd_record_type[0].text === ‘Transaction’ ? transactionType : recordType;

    var targetRecord = record.load({type: type, id: recordId});

    var tplFile = file.load(rdFields.custrecord_rd_document_tpl);

    var myRender = render.create();
    myRender.templateContent = tplFile.getContents();
    myRender.addRecord({
    templateName: ‘foo’,
    record: targetRecord
    });

    res.write(myRender.renderAsString());
    }

    return {
    onRequest: onRequest
    };
    });
    So given the id of a “render definition” custom record and the id of a record to print, you get a rendered document. The custom record would contain metadata about additional records and searches to pull in that might not be directly available from the initial record specified. All that’s moot if I can’t load the first target record, so using Record Type & Transaction Type fields on the “render” appeared sensible.

  • #18422

    pcutler

    It sounds like we might be running into the same issue. Your problem is that the value of the “record type” drop-down field is the numeric internal ID and not the script ID, correct?

    I wasn’t able to find a great answer to this either, but the work-around I used:

    1. You can get the display name of the custom record type with nlapiGetFieldText/nlobjRecord.getFieldText of their SuiteScript 2.0 equivalents.

    2. You can use nlobjField.getSelectOptions on the script deployment record of a user event script to get a cross-reference table between the display name and script ID of the record type.

    Alternatively, you can create your own cross-reference table as a custom record, but you would have to keep it updated each release.

You must be logged in to reply to this topic.