Name | Value | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
NUMBER | 3834 | ||||||||||||
IA # | 3834 | ||||||||||||
DATE CREATED | 2002/11/05 | ||||||||||||
CUSTODIAL PACKAGE | COMMUNICATIONS SERVICE LIBRARY | ||||||||||||
USAGE | Controlled Subscription | ||||||||||||
TYPE | Routine | ||||||||||||
DBIC APPROVAL STATUS | APPROVED | ||||||||||||
ROUTINE | CSLEC | ||||||||||||
NAME | CSL Cost Center table update | ||||||||||||
GENERAL DESCRIPTION | With the replacement of IFCAP by the CoreFLS system, the lookup of a Cost Center value will be done through a local Cost Center file. This file will be updated by Event Capture once a year or as needed through a query to retrieve active cost centers from the CoreFLS system. According to VA handbook 4671.1, cost center codes from 8000** through 8999** will cover all possible VHA activities. The cost center file update query will issue a request to the CoreFLS system to transmit all cost center codes which start with an 8 (8*****) to VistA. The CC table update query function call provided to the subscriber will return a value of 1 indicating the query sent to CoreFLS system was successful, or a 0 to indicate the query failed. Example: S X=$$CCTBL^CSLEC() to send CC table update query to CoreFLS system After CC table update query is received by the CoreFLS system, an HL7 message containing all the cost center codes that start with an 8 (8*****) will be generated and transmitted to VistA for processing. The HL7 package in VistA will invoke routine CSLEC1 to parse the HL7 message and store the most recent active cost center codes into table 536.3. Before the table is updated, the active flag for all cost center codes in the table will be changed to 0 (inactive). If an existing cost center is included in the HL7 message received, the active flag will be updated to 1 (active). To prevent table 536.3 from being partially updated while processing the HL7 messages, the data will be parsed to a temparary file ^XTMP first then to the file 536.3. In order to decide whether the CC table update is successful or not, the subscriber need to check the 5 parameters provided by the CC table update query. The following 5 parameters will be defined in file 8989.51 through the pre-install routine, CSLEC2, when the CSL package is installed at site for the first time. The value of these parameters are stored in file 8989.5 and will be updated each time the CC table update query is invoked. 1. CSL CC UPDATE REQUEST (store the query request date) 2. CSL CC UPDATE START (store the table update start date) 3. CSL CC UPDATE END (store the table update end date) 4. CSL CC UPDATE STATUS (1: processing, 0: completed) 5. CSL CC UPDATE NOTE (store status note) The following logic decide whether the update is successful or not: If Request date > Start date Start date > End date table partially updated and data is not usable Start date <= End date table not updated but data is usable. If Request date <= Start date Start date > End date table partially updated and data is not usable. Start date <= End date table updated successfully |
||||||||||||
STATUS | Active | ||||||||||||
KEYWORDS |
|
||||||||||||
ID | CSLEC | ||||||||||||
COMPONENT/ENTRY POINT |
|
||||||||||||
SUBSCRIBING PACKAGE |
|