ВКП!
Натолкнулся на абсолютно непонятное (для меня) поведение платформы.
Оно выражается в следующем:
Имеется справочник с текстовым реквизитом. В него грузятся числовые значения, преобразованные в строку. Преобразования делал через Строка(Значение) и неявно. При массовой загрузке число преобразовывается как с раделителем тысяч, так и без него - хаотично.
Никто не знает, ВТФ?
Платформа 1С:Предприятие 8.3 (8.3.10.2561), СУБД Postgresql 9.2.4. Сервер и СУБД на Генту.

те, что без разделителя, уже были строками

(1) Ничего подобного. Числа.

(2) Строки. Возьми да загрузи проблемное "число" 100500 раз

(3) Я же сказал - хаотично меняются. Каждую загрузку - разные.
Даже делал так: Строка(Число(Значение)) для верности.
И проверял до этого тип значение на соответствие типу "число".
Отловить вручную на 30-60 тыс. записей нереально.

Открой для себя точку останова с условием

(5) Не ловится. Я не совсем уж ламер.
И я заметил, что остановка с условием на текстовые значения работает как-то не очень...

(4) одно и то же значение случайным образом то с разделителем, то нет? Я ж говорю, грузи одну и ту же строку, пока не подтвердишь ошибку. И если хотел исправить поведение, стоило таки использовать Формат

(6) что ты писал в условии для "точка останова с условием"?

(6) "Пригласи специалиста" (с)

(7) Формат использовал с принудительным заданием разделителя Символы.НПП - пофигу
(8) СтрНайти(СтроковоеЗначение,Символы.НПП)=0
Он останавливался и там, где эти чертовы непереносимые пробелы были.

(9) известный мне специалист ответил:
"Если вы преобразуете число в строку, программа пытается сама догадаться - какой формат представления числа использовать.
И до чего она догадается по виду числа - загадка."
ЗЫ этот специалист имеет право преподавать программирование на платформе...

"останавливался и там, где эти чертовы непереносимые пробелы были" // Гонишь, или давай пруф (в табло при сработавшей точке останова результат условия)

(11) Нужен не теоретик

(12) в табло) "угости сигареткой - сигаретки в магазине - а если в табло и еще раз спросить?"
(11) приведи типы и источники чисел

(0) Предлагаешь поверить на слово?!

(15) Ох уж Фомы неверующие...
https://yadi.sk/i/OwuQkOLV3QAr9z
(14) Загрузка из Интернета через JSON. Разбор с помощью ЧтениеJSON. Уже писал, что:
- тип значения проверял - число.
- делал преобразование Строка(Число(Значение))

(16) осталось в временный файл записать джейсон до разбора

+ по артикулу вполне можно было отладку

xmlСтрока() же все пользуются. Функция Строка() - это только для теоретиков.

Всегда просто получается:

Формат(ЗначениеЧисло,"ЧДЦ=; ЧГ=0")

(0) "Имеется справочник с текстовым реквизитом. В него грузятся числовые значения, преобразованные в строку". Зачем число грузить в строку? Какой в этом смысл?

(0) откуда грузятся? скорее всего в этом "откуда" там тип строка или текст, а не число

(22) если ексель, то там даже тип число не всегда число, он же просто пытается перевести в число

то есть хочу сказать что в таблице откуда загружаются значения вот этот идентификатор записан как текст 58965, то есть при переводе в строку он будет как есть 58965, а также там имеются значения с типом число 58965, то есть при строка(значение) он ставит разделитель и переводит в 58 965

(10) XMLСтрока(<Значение>) или Формат и ЧГ=

0Формат()

Формат(ТвоеЧисло, "ЧГ=")

(21) Да потому что в этом реквизите и строки используются.
Народ, читайте внимательнее - то, что исходное значение "Число" проверял как на соответствие типов, так и явным приведением к типу "число".
(27) Пробовал - не прокатило.
(17) Это уже изврат, когда стандартный механизм разбора не ошибается...
(24) При чем здесь эксель?
(27) Пробовал. Не помогало.
Пока дописался до такого изврата:
Стр = Формат(Число(Стр.Id),"ЧЦ=15; ЧРГ= ");
СтрЗаменить(Стр, " ", Символы.НПП);
Сработало без сбоев.
И да, сбоило примерно в 0,5% случаев.

(30) тебе в (19) и (25) показали как надо, но ты продолжаешь жрать кактус.

Или тебе все таки нужен этот неразрывный пробел (правда я совершенно не могу понять зачем это может быть нужно)?

(31) К сожалению нужен...
Из-за внутренних механизмов самой 1С по преобразованиям типов. У нас есть еще дополнения к конфигурации и там тоже используются неявные (или явные хз) преобразования типов. Править хрен знает в скольки местах да еще при наличии закрытых от изменения частях кода - проще поправить в одном.
Еще раз повторюсь: проблема проявляется ТОЛЬКО при обработке 50+тыс. записей в JSONе. И из них 100-200 рандомно сбоят. По одной или небольшими порциями проблемы нет.
Сразу скажу, что разбивать загрузку невозможно - поставщик данных отдает только одним здоровым куском в 300+тыс. записей, из которых и так выдираю часть. Если грузить частями, то загрузка займет часов 8, а надо грузить как минимум 3 раза в день.

(34) тогда делай остановку когда ТипЗнч(<Твой_параметр>) = Тип("Строка").
ИМХО, дело в преобразовании из json-а. Как, кстати, его делаешь?

Может с клиентов Win грузится с разделителями, а с сервера Линукс без. Кто их там линуксов знает...

(35) См. (16)
Ч_JSON = Новый ЧтениеJSON;
Ч_JSON.ОткрытьФайл(ФайлРезультата);
СтруктураОтвета = ПрочитатьJSON(Ч_JSON, Ложь);
Нормально все обрабатывает, с правильными типами.
(36) Я бы не поднимал тему, если бы все записи обрабатывались одинаково...

(37) а какой тип у колонки "Идентификатор"?

(37) Подготовь минимальный тестовый набор, который каждый сможет проверить у себя.

(39) +, можно и полный, есть же скрин в (16)

Строка(Значение)  - не надо так больше делать
чего обсуждать то
XMLСтрока(Значение)

Число - XML представление соответствует представлению типа decimal схемы XML (см. http://www.w3.org/TR/xmlschema-2/#decimal);

(41) ему нужны разделители НПП

(40) (39) Подготовить минимальный - не знаю как, т.к. не знаю, какое количество записей нужно для воспроизводства ошибки. Полный ответ JSON занимает до 30 метров в двух строках. А скрин - это просто список справочника с уже полученной ошибкой...
(41) Пока 1С и партнеры вовсю используют неявные преобразования в конфигурациях подобные вещи возможны только в личных надстройках. Я бы вообще использовал типизированные поля для идентификаторов, но вынужден пользоваться тем, что уже есть.
Вопрос закрыт костылем и терять время на поиски плавающей первопричины в текущий момент не могу. Тем более, что все предложенные варианты, которые могут дать требуемый результат, испробованы.

(43) выкладывай, у нас норм инет и много дискет) а на скрине просто видно проблемную строку

Попробуйте поразвлекаться разными способами преобразования.
https://yadi.sk/d/0xLOVNxN3QBuHE
Это строка в JSON. Лишние поля удалил.

(45) И? Проблемная строка которая?

(46) Да сколько раз повторять - рандомно не добавляются НПП. За 1,5 недели работы (загрузка 2 раза в день) количество неправильных идентификаторов растет и достигло 1462 штуки на сегодняшнее утро.
Дальше развлекаться неохота - база рабочая и последующее удаление неправильных записей будет все тяжелее. Так что так как решение найдено, то все ошибочные записи уже удалены.
Если нужна конкретная запись из бывших ошибочных, то вот, например: {"Id": 117935, "Stock": 0, "Additional": 0, "Price": "3769.23"}
или эта, из скрина: {"Id": 58965, "Stock": 0, "Additional": 0, "Price": "431.58"}

(47) а зачем добавлять нпп? Они там вообще ни к чему.

(48) 1. разборка JSON возвращает тип данных для ID "число"
2. Есть сторонние доработки, которые так же используют это поле с преобразованиями число-текст и я не знаю, как они это делают - часть кода закрыта. Но точно преобразуется число в текст по правилам 1С, т.е с НПП.

(45) Ты б сделал конфу с одним справочником и обработкой загрузки из json, может кто и потестил бы у себя.

Сам бы проверил - может это только на какой-то конкрентной платформе или при прочих конкретных параметрах среды воспроизводится.