Ancillary Data

For kashflow invoice and payment data to be modelled sensibly within eLink, it is necessary to incorporate a variety of ancillary data. This data currently comprises:

1. Kashflow Products,
2. Kashflow Nominalcodes,
3. Kashflow Nominalcode Classification Data
4. Kashflow Nominalcode Type Data
5. Sales Invoice and Purchase Invoice Payment Method Data
6. Bank Account Data

Items one and two are represented as eLink Products (note the terminology conflict between Kashflow products and eLink Products!). The remaining items are stored in custom lookup tables within eLink. The purpose of these remaining items is primarily to allow users to inspect and modify kashflow data using logical names rather than identifiers. For instance, the bank account data provides a translation between the bank account names and the identifiers used in payment data. So, by having this translation on hand, the kashflow integration module can present the data in human readable form. It also makes it possible to for users to create data for submission to kashflow in human readable form.

eLink Products

Synchronisation

Given the nature of this ancillary data, it was decided that a full synchronisation of this data is unnecessary, because:

1. The data does not change very often.
2. The data is generally of a fairly simple nature.
3. Kashflow does not provide full information about what has changed.

So, a single-directional synchronisation is all that is currently implemented. In this scheme, whenever data is synchronised, all the ancillary data held by Kashflow is copied to elink – overriding any changes made in elink.

Ancillary Data Modification

Due to the fact that the synchronisation process is one-directional – from kashflow to elink, it follows that the only way of modifying this data is to modify it in Kashflow and then allow the synchronisation to replicate the changes in elink. This is hardly a major restriction because it is likely that this data would not need to be changed very frequently.