Screening (Background Checks)

For discussion of issues related to integration of screening orders and reports.

Screening 3.0 / UserArea, Extensions, Effective Dates on AccessPointDetails

Here's a quick run-down on your questions.

> 1) I got to know from one of the members in our team that
> HR-XML 3.0 final release is due October 16th 2008; however I
> could not get the final release on the site as yet. Could you
> please let us know as to when we can expect that?

We're aiming for the near-final, Candidate Release next week. It will go through a 60-day public review period, followed by reconciliation of any feedback - So the final, official version should be available the first of the year.

> 2) Where can I get information regarding extending the
> existing schema for customizing to suit our needs. I did find
> it for 2.5 but not for 3.0

The same principles apply, but it is easier in 3.0.

***** 1 **** UserAreas are more abundant. Also, note that the HRUserAreaType uses processContents="lax". This is a change from 2.*, which specified "strict"

processContents attribute. Possible values for this are "skip" (meaning that an XML processor will ignore what is in the UserArea); "lax" (asking the processor to validate the contents when possible); and "strict" (meaning validation will be attempted.

It is still good practice to validate UserArea content with your own schema and to specify such extensions under your own namespace -- So everything you did in 2.* should work with 3.0. However, using "lax" most processors will look for a schema against which to validate the content, but won't throw a validation error if it doesn't find one. The UserArea extensions will of course still need to be well-formed. You also ought to declare a namespace prefix for the extensions even if you don't specify the schema against which to valid the XML. For an example (recruiting), see:
http://www.hrinterop.org/schemas/OAGi-BPI-Platform/org_hr-xml/3_0/Instan...
Notice the declaration of the namespace prefix and its use:

ScreeningOrderServiceCode / synchronous and asynchronous use cases

Contact First/Given Name: margaret

Question: I'd like to confirm these enumerated values:
Immediate - does this mean that requester is going to wait online until the results are ready (i.e. I'll wait until you process the credit check and have results to send back immediately)
Delayed - does this mean that I'm submitting my request for a credit check and the supplier just needs to respond with an acknowledgement that the order was recieved. Then the results will be sent back in a separate request/response transaction.

Margaret,

I assume you are talking about ScreeningOrderServiceCode. You probably found this definition: Refers to type of order processing pattern or level of service requested. This is an open HR-XML list. Enumerated values are Delayed and Immediate. Delayed = Acknowledgement of order receipt requested, but no immediate business-level processing expected. Immediate = Immediate business-level processing expected. This is an HR-XML Open List.

"Immediate" does imply a near-real-time response, which might support the return of a result to a user waiting for a result. I guess there are only a few types of screenings where this might be a reasonable expectation. **just an update to emphasize that this primarily is something that has meaning with a particular trading partner arrangement. I probably should just leave it there. I think the definition is actually pretty good -- immediate business-level processing. I think a synchronous, real time response with a result is a likely outcome, but the message exchange is really a separate matter.***

I'd agree that delayed is generally has the meaning you describe.

Syndicate content