Я бы определенно не списывал это как случайный случай, вы не хотите, чтобы это появлялось снова при соблюдении определенных условий. Вот несколько вещей, которые я бы попытался сузить
1) Вы используете LEFT JOINs, он может оставить значения NULL в полях, которые, как вы ожидаете, будут целыми числами (например, QTY), попробуйте заключить их в операторы COALESCE в предложении SELECT
SELECT COALESCE(OpQty, 0) as OpQty, ...
2) SSRS может угадывать тип данных неправильно, оно может считать поле символа целым числом, если первые несколько значений являются числами. Выясните, какое поле генерирует ошибку, и, возможно, приведите ее явно к NVARCHAR, чтобы SSRS не пытался использовать ее как целое число
SELECT CONVERT(nvarchar(50), OpPrSKU) as SKU, ...
3) SSRS, возможно, добавил поле «ВСЕГО» в конце группы DETAIL, поэтому он пытается выполнить математику для поля, которое не является числом. Это менее вероятно, но возможно, поэтому, по крайней мере, стоит искать.
Но важно выяснить, КАКОЕ поле генерирует ошибку, чтобы вы могли сосредоточить на ней свое внимание.
РЕДАКТИРОВАТЬ: Если вы используете SQL Server 2012 или более поздней версии, вы также можете явно установить типы данных, возвращаемых с помощью предложения EXECUTE WITH RESULT SETS в вашем наборе данных в отчете. Хороший пример: http://www.sqlservercentral.com/blogs/sqlstudies/2016/01/14/what-is-result-sets/
Обратите внимание, что это имеет тот недостаток, что если вы обновите определение хранимой процедуры, добавив в него больше столбцов, вы должны будете не забывать отслеживать и обновлять все отчеты, которые ее используют. Если ваши настройки не меняют определения SP, это не проблема, и это самый надежный способ сообщить SSRS, какие типы являются правильными, но для меня приведение типа в SP более гибко в долгосрочной перспективе и достаточно для SSRS. в каждом случае, с которым я столкнулся.