Automatically populating other fields based on lookup

[joe.mag]

My apologies if this question is answered elsewhere--I searched the forum numerous times and either got way too many results or none at all! Also searches of the example projects didn't seem to turn up anything useful either.

Here's my situation: I'm creating an order via the API. I already know the lookup codes for several of the key entities (e.g. Attorney) so I can easily query via the Lookups interface to find the attorney in question. Here comes my issue--while i can obviously assign every property, one by one, on the IAttorney object that I get via CreateNew() from the corresponding attribute in the lookup table results that's a) time consuming coding and b) doesn't appear to support substitution.

In the example of our Proposed Insured Lookup Code lookup table the corresponding Proposed Insured edit box gets populated when a user selects a lookup code manually in the UI. The contents of the textbox often involves resolution of a field reference (e.g. {{Order.Lender.Name}}). Since I don't know how to "tell" the API "hey, build the instance of the object based on this lookup table result" I'm not sure how I'd invoke the substitution mechanism.

Thanks for reading and any help you can provide.

[Melissa McBerkowitz]

In the current version, you'd walk through the lookup columns and assign those values to the order.

In the next major release (Cameron, v3.0), we are integrating lookups into the order itself, so you will be able to set a key field value like Attorney Lookup Code and have that one change trigger the lookup to occur to populate all the corresponding values.

[Melissa McBerkowitz]

Also, in the field substitution case: if you leave the field code as is and don't try to imitate any replacement logic, our document rendering process will replace the field's value at the point the user renders a document containing the field.

[joe.mag]

Thanks for the quick and detailed reply--sounds like a great enhancement.

As far as the document performing the substitution that's great as far as final output. The only thing that's less than ideal is the SPS user doesn't see the substitution on the screen so they will need to be trained that "that's not an error, it'll be ok in the long run." I guess my other concern would be that queries to the database for reporting, etc. (not that fields that undergo substitution are likely to be heavily referenced on reports) will return the {{field.name}} text rather than the substituted text.

We can consider this matter closed. My primary interest was to make sure I wasn't missing some undocumented/overlooked way to invoke this population.