home.cd3wd.ar.cn.de.en.es.fr.id.it.ph.po.ru.sw Misd170.htm

SECONDARY DATA RECORDING

This covers the following data fields:

- price in Tanzanian Shillings for each animal weighed

- the ID of the buyer

I classify these 2 fields as secondary since, for conventional logistics, the Market Organiser personnel are weighing, grading, sexing and TRN'ing on the day before the market or at the start of the market, and then the price and buyer information is logged the next day or later in the day.

The ID of the buyer is only used at Dar, and as far as I know, no analysis is done on a buyer basis. Therefore I strongly recommend that we discontinue this field.

PRICING

Pricing as an area with the potential for problems and errors in several ways:

- firstly, using the conventional techniques of Market Organiser weighing (rather than self-weighing), there is a shrinkage in the data between weighing and pricing. Current conversion ratios for 1994 are 66% for Dar, 63% for Arusha, and 59% for Moshi. These percentages are net sample size to gross sample size (i.e. number weighed and priced over number weighed). These losses represent a lot of weighing and a lot of other work down the drain. Some of these losses in information are due to the use of 'MOB' prices (a bunch of cattle from one seller are sold as a bunch, on an average price basis; the buyer and seller both know or feel that they are getting prices about the same as they would have got if they bid on an individual basis); other losses are possibly due to lack of organisation in that the seller leaves the market with his cattle without being asked the price of those of his cattle with TRN's. IF self-weighing is not to be used, or if a mix of self-weighing and Market Organiser weighing is to be used, then TLMP staff should investigate in more detail this data shrinkage problem and how to improve it (possibly the allocation of more labour to capture prices will save a lot of labour at the weighing operation, by requiring a smaller gross sample size).

- MOB pricing was mentioned above. Sometimes MOB prices get on to the data sheets, instead of the price being entered as blank or zero. And then the mob prices sometimes get into the computer data. The reason could be slackness by the data recorders and pressure to get the quota of data points. I recommend that this should be investigated.

- private people, and especially private business people, are naturally suspicious of anything that smacks of government. For example, with the MDB Crop Prices Program, the staff found that market traders would always underdeclare unit prices to their data recorders; they got round this by stationing an observer permanently at the market, ostensibly to check on volumes, but actually to overhear real prices. This approach is used very largely at Arusha cattle market, where one of the staff hovers on the edge of negotiating groups with one or more TRN'd cattle, in order to overhear the actual (OBSERVED) price instead of the STATED or DECLARED price. The Arusha staff feel that this produces improvements in data quality.

- of course an auction system would be nicer for the MIS - especially also if every animal were weighed and the grade and sex declared publicly (except of course there would be pressure on the officials to ramp up the grade allocation) - since the prices would be a matter of public record.

- in case that a combination of observed prices and declared prices is used, then the computer system should be written so as to record which of the 2 types of prices is valid for each data record line item. This can then be bulk analysed at a later time, and maybe some apparent rules can be established for the difference, if any (e.g. declared prices are usually 5% lower than observed prices for the same type of animal).

On pricing , the errors are difficult to estimate. They could be up to 5%, and probably on understating the price rather than overstating.