| GENERAL DESCRIPTION |
Vendor Update API
The vendor update operates asynchronously using a callback model. The first
step in running the vendor update is to build a (typically global) array
containing the vendor ID, site ID and modification date for each vendor to be
updated. In addition to the asynchronous (background) entry point, there is a
synchronous (foreground) call that may be used to interactively retrieve the
full set of attributes that would be returned for a vendor using the
background update. The foregound call involves no modification date, and
returns the vendor attributes unconditionally.
The format of the array is
...
ARRAY(index) = vendor_id^site_id^timestamp
...
(where timestamp is in Fileman format).
Note: The timestamp will be the value previously received from CoreFLS, not
the time the local file was updated or any other timestamp generated within
VistA.
Example:
^TMP(4375,1)="ACME_DRUGS_AND_SUPPLIES^SAN_FRANCISCO_2^3021008.191213"
^TMP(4375,2)="PEERLESS_AMBULANCE_CO^ATLANTA_7^3020721.1542"
The name of this array (not a reference) will be one parameter to the vendor
update.
Example:
In this case, the array name is $NA(^TMP(4375)), or simply "^TMP(4375)".
The second parameter will be an entry point to user supplied routine in the
format "ENTRY^ROUTINE" (i.e., no parameters will be listed). The actual call
is
D UPDATE^CSLVQ(ARRAY,"ENTRY^ROUTINE")
The array passed as the first parameter may safely be KILLed by the caller at
any point after this call returns.
If an error occurs, CSLERR will be set a value in the format
"errno^description".
The callback has one parameter, the name of an array containing one or more
vendor records. The format of the array is
ARRAY(index, field_subscript) = value
Exception: Index value 0 is reserved for system use, so ARRAY(0, ...) must not
be treated as data. Typically, data will be stored under numeric subscripts
starting with 1.
The possible values of field_subscript are
VENDOR_ID
VENDOR_NAME
TAX_ID
INACTIVE_DATE [1]
AREA_CODE
PHONE_NO
FAX_AREA_CODE
FAX_NO
ADDRESS_LINE_1
ADDRESS_LINE_2
ADDRESS_LINE_3
CITY
STATE
COUNTY
POSTAL_CODE
COUNTRY
VENDOR_SITE
CHAIN_NO
COMMENTS [2]
LAST_UPDATED [1]
PARTICIPATION_CODE
VENDOR_TYPE
TYPE_OF_VENDOR
MEDICARE_ID
SPECIALTY_CODE
NO_OF_BEDS
INSPECTED/ACCREDITED
LAST_ASSESSMENT [1]
CERTIFIED_MEDICARE/MEDICAID
ON_HOLD
FEE_VENDOR
Notes:
[1] Dates are Fileman format
[2] A word-processing field will be stored in the format
SUBARRAY(1,0)=line 1 SUBARRAY(2,0)=line 2
...
For example, the comments field might be stored as
^TMP(1,34567830,"COMMENTS",1,0)="Line 1 of comments
^TMP(1,34567830,"COMMENTS",2,0)="Line 2 of comments
In addition, there are a number of optional vendor attributes. If an attribute
is present, the appropriate top level subscript will be set. For example, for
an EDI vendor, we will have
ARRAY(index,"EDI_VENDOR")=1
The complete list of attribute subscripts is
ON_HOLD PRIMARY_PAY_TO RFQ PURCHASING PAY_TO PROCUREMENT_CARD PRICER_EXEMPT
FEE_VENDOR EDI_VENDOR PO_HOLD NEW_PAY_HOLD ALL_PAY_HOLD
WARNING
It is the responsibility of the user supplied routine to file the data,
performing any necessary locking. It is important to be aware that this
routine can be called at any time, and it is possible for it to be called any
number of background tasks running concurrently.
A second entry point ("interactive update") exists as a convenience to the
user/programmer. This entry point is an extrinsic function ($$IUPDT^CSLVQ)
taking the vendor ID and vendor site name as parameters and returning he name
of an array containing the vendor attributes (in the same format). In this
case, no date of last update is supplied, and the vendor data is returned
unconditionally.
|
| COMPONENT/ENTRY POINT |
| COMPONENT/ENTRY POINT |
COMPONENT DESCRIPTION |
VARIABLES |
UPDATE |
This entry point is used to initiate an update. There
are two parameters, a list of records to be updated (with timestamps) and a
callback to be invoked by CSL to perform the update. Each subscribing package
must provide an IA allowing CSL to invoke the callback.
|
| VARIABLES |
TYPE |
VARIABLES DESCRIPTION |
data |
Input |
Name of a (typically global) array containing ID,
Site ID and Date of Last Update for each vendor to be updated, the format is
^TMP(4375,1)="248^SAN_FRANCISCO_2^3021008.191213"
^TMP(4375,2)="57^ATLANTA_7^3020721.1542"
...
(This variable should be namespaced.)
|
cback |
Input |
This is the callback invoked by CSL to hand the new
record values back to the invoking application. It should be in the format
"TAG^ROUTINE" with no parentheses or argument. It will, of course, be invoked
with a single argument, but only the tag and routine name should be used.
(This variable should be namespaced.)
|
|
UPDATE |
|
|
$$IUPDT(vendor_id,site_id) |
This extrinsic function returns the name of a global
array containing attributes for a vendor returned unconditionally (without
regard to the date of last update).
Example:
After
S X=$$IUPDT^CSLVQ(vendor_id,site_id)
X will be equal to the name of a global array containing attributes for the
given vendor, e.g.
^XTMP("CSLUPDATE5163074","DATA")
The format of this array is identical to the format of the global array passed
to the callback in the background update (D UPDATE^CSLVQ).
|
| VARIABLES |
TYPE |
VARIABLES DESCRIPTION |
vendor_id |
Input |
This is the (numeric) CoreFLS Vendor ID. (This
variable should be namespaced.)
|
site_id |
Input |
This is the (alphanumeric) CoreFLS Vendor Site ID.
(This variable should be namespaced.)
|
|
|
