explanation of diagram

This diagram traces how elements of the Creditors Invoice Database, which contains many field of data, are selected by two parsing scripts (CR625, CR626) which assemble the data into a comma separated value spreadsheet.

The Council database is questioned via the NATURAL computer languages, which uses a query language similar to SQL to access stored data.

Similar to how a postcode can be sundered to disclose different geographical information, the Invoice Expend_Code (which will feature in every entry into the Creditors standing invoice database) can be split into more atomic units of concise data, such as P_DIR, P_COST, P_DETAIL, and P_BUDGET. When these elements are concatenated together, as they are for the Desc_1, Desc_2, and Desc_3 fields, they can be searched against the Creditors Invoice Payment Database to return detailed contextual information on where the expenditure money was spent.

Two scripts are responsible for extracting data from the NATURAL database and recombining it for the Open Data datasheet, CR625 and CR626 respectively.

The Creditors Invoice database, which was given prime position in Fig 1. Granular Open Spending, can in fact only declare the supplier and amount spent. When placed with reference to the Costing and Financial Management Database greater contextual information is possible

As is explained in the latter paragraphs of Decoding Open Data, the code structure is dependant upon the Capital & Revenue Code.

From this diagram one can see that an additional database beyond the Creditors Invoice Payment Database (Shared Transactional Services: Account Services as responsible department) is required to produce the datasheet available on Bristol B-Open. This additional database is the Costing and Financial Management Database (Shared Transactional Services: Finance as responsible department)