>> SOURCEID INTEGER,
>> SOURCETYPE VARCHAR(15),

>You told us, that SOURCETYPE is not a [VAR]CHAR but a numeric type. Ts, ts, ts ...

Ahhhhhhhhhhh, thank you, thank you, thank you!!!!
I must be going cross-eyed and looked at the one above by mistake - reading what I expected should be there, oy, vey.
You saved me from adding yet MORE indexes in, because I just split that index into 3 new ones, and the REFNO index kicked in, making the query fast - those are now getting deleted again!! Whew!

> CREATE INDEX STK_STOCKTRANSACTION_IDX1 ON STK_STOCKTRANSACTION
> (FINANCIALYEAR, PERIOD); CREATE DESCENDING INDEX
> STK_STOCKTRANSACTION_IDX10 ON STK_STOCKTRANSACTION (STOCKCODE,
> TRANSACTIONTYPE, TRANDTETME, ID); CREATE DESCENDING INDEX
> STK_STOCKTRANSACTION_IDX11 ON STK_STOCKTRANSACTION (TRANDTETME,
> STOCKCODE, WAREHOUSECODE, TRANSACTIONTYPE); CREATE DESCENDING INDEX
> STK_STOCKTRANSACTION_IDX12 ON STK_STOCKTRANSACTION (ID); CREATE INDEX
> STK_STOCKTRANSACTION_IDX13 ON STK_STOCKTRANSACTION (TRANDTETME, ID);
> CREATE DESCENDING INDEX STK_STOCKTRANSACTION_IDX14 ON
> STK_STOCKTRANSACTION (STOCKCODE, WAREHOUSECODE, TRANDTETME, ID);
> CREATE DESCENDING INDEX STK_STOCKTRANSACTION_IDX15 ON
> STK_STOCKTRANSACTION (STOCKCODE, TRACKINGNO1, TRACKINGNO2,
> TRACKINGNO3, TRACKINGNO4, TRANDTETME, ID); CREATE INDEX
> STK_STOCKTRANSACTION_IDX16 ON STK_STOCKTRANSACTION (SOURCELEDGER,
> TRANSACTIONTYPE, REFNO, SOURCEDETAILID); CREATE DESCENDING INDEX
> STK_STOCKTRANSACTION_IDX2 ON STK_STOCKTRANSACTION (STOCKCODE,
> TRANSACTIONTYPE, WAREHOUSECODE, TRANDTETME, ID); CREATE INDEX
> STK_STOCKTRANSACTION_IDX3 ON STK_STOCKTRANSACTION (FINANCIALYEAR,
> PERIOD, STOCKCODE, WAREHOUSECODE, TRANSACTIONTYPE); CREATE INDEX
> STK_STOCKTRANSACTION_IDX4 ON STK_STOCKTRANSACTION (STOCKCODE,
> WAREHOUSECODE, TRANSACTIONTYPE); CREATE INDEX
> STK_STOCKTRANSACTION_IDX5 ON STK_STOCKTRANSACTION (STOCKCODE,
> WAREHOUSECODE, FINANCIALYEAR, PERIOD, TRANSACTIONTYPE); CREATE INDEX
> STK_STOCKTRANSACTION_IDX6 ON STK_STOCKTRANSACTION (FINANCIALYEAR);
> CREATE DESCENDING INDEX STK_STOCKTRANSACTION_IDX7 ON
> STK_STOCKTRANSACTION (STOCKCODE, TRANDTETME, ID); CREATE INDEX
> STK_STOCKTRANSACTION_IDX8 ON STK_STOCKTRANSACTION (WAREHOUSECODE,
> STOCKCODE); CREATE INDEX STK_STOCKTRANSACTION_IDX9 ON
> STK_STOCKTRANSACTION (SOURCETYPE, TRANSACTIONTYPE, REFNO);

>Hmm, could be a bit over-indexed?

I try not to add more in, unless they definitely make one of my queries faster... I've started making notes now, to try keep track of which part of the program they actually speed up, so I can retest if I want to remove them, but it's quite a job to retest the whole lot, on a variety of databases.

>I don't know your access patterns, but you know that each index makes delete/insert/update performance worse, especially when an index need to be updated by non-sequential values in e.g. batch processes, changing a bunch of records.

These ones only ever get inserted...

>I have run through some tests on indexes delete/insert/update wise.

Although I'm not ready to publish the results, I can only say, each additional (useless) index can decrease DML performance dramatically.
The page cache plays an important role here as well.