CopiaFacts provides a range of data extraction and logging facilities to provide transaction data for monitoring, analysis and accounting. In principle, we concentrate on providing useful data which can be imported to your own accounting software, because we have found that the majority of our users already have systems either for internal departmental billing or external customer billing.
The principal extraction and logging methods are as follows:
| Daily DBF Log File | The original log file, one file per day, with the most detail about transactions and many options ($log_options). The DBF format is directly readable by many database applications, and Copia also provide an application (CATDBFX) which will concatenate DBF files for a period (e.g. a month or a week) and convert them to an XLSX file, with headings and matching field types, for further reporting or analysis. Because in most cases a transaction can cause multiple records to be written to the log, some filtering is necessary to produce a simple record of each transaction. For details of the standard file format (to which extra fields can be added) see Appendix E. |
| MSMQ Messages | Having the COPIAFACTS engine write an MSMQ message at the end of every transaction is the most efficient means of data extraction, but it requires a customer-provided application which can read the queued records. Typically multiple COPIAFACTS nodes will write messages to a common queue. You have complete control over the content of the messages, and for each transaction type you can specify a vector of variable names, either system variables or user variables, which will be written to each message. You can also choose whether to log every outbound transmission attempt or only a summary at the time of success or failure. Details of this option are summarized in the $notify_qname topic and the variables used in Appendix D. |
| Data Extraction to TSV | From version 8.3, the COPIAFACTS engine can also write daily tab-separated-value files, one line per transaction. Again the content of each record is fully configurable, by specifying a vector of variable names to be included; and again you can choose whether to log every outbound transmission attempt or only a summary at the time of success or failure. The TSV files for each transaction type (which may contain different field sets) can be concatenated and loaded into Excel for further analysis. Because there is one record per transaction and the fields included are under your control, these files are usually more straightforward to process than the Daily DBF log file. Details of this option are summarized in the Data Extraction to TSV topic and the variables in Appendix D. |
| Broadcast Job Data | Users of the Job Administration feature have a range of data extraction methods which are job-oriented. Normally the extraction(s) would be specified as an automatic end-job-task. All the available data for an individual job (including user variables) can be extracted to a variety of formats: |
•Tab-separated-value files. The data is extracted for a job using the JOBXDATA program, and the content can be customized by using the JXFIELDS.LST file to select which pre-defined or additional fields you need. This file can be processed by many programs, including Excel.
•DBF files. The data is extracted for a job using the JOBDDATA program, and the content can be customized by using the JDFIELDS.LST file to select which pre-defined or additional fields you need. JOBDDATA can also update a summary DBF file containing an entry for each completed job. These files can be processed by many programs, including Excel.
•Excel (XLSX) files. The data is extracted for a job using the JOBXLDATA program, and the content can be customized by using the JXLFIELDS.LST file to select which pre-defined or additional fields you need. The output consists of an XLSX file with two worksheets, the first showing a summary of the job and the second a listing of the job items. Both are fully customizable and presented with headings in a form which should be suitable for sending direct to a bureau customer.
