[Решено] Разные национальные стандарты в формулах

[Sirius34]

И все новые документы создаются с настройками, сохранёнными в этом шаблоне (например, локаль ячеек)

С действующими документами такое решение не поможет, увы.

я так и не знаю, что могут исправить пробелы в формате

Я уже написал, что локали для суммовых ячеек исправил. Будем считать, что решение найдено.

Дальше, по сути, обсуждение начинает переходит на мою нелогичность и непоследовательность в вопросах,
в чём я и так не очень сомневался

Всем спасибо за помощь, терпение и понимание.

Топик можно закрывать.

[mikekaganski]

Я уже написал, что локали для суммовых ячеек исправил. Будем считать, что решение найдено.

Дальше, по сути, обсуждение начинает переходит на мою нелогичность и непоследовательность в вопросах,
в чём я и так не очень сомневался

Вы не правы.
Форум - это не "я зашёл, спросил, готово". Здесь те, кто отвечают, тоже получают что-то - скажем, знания. Вот Вы написали в какой-то момент: "без пробела косяки". И я заинтересовался, потому что насколько я знаю, так не бывает, но всегда находятся вещи, которых мы не знали, а они есть. А Вы не собираетесь рассказывать, потому что Вам уже не надо. Вам бы понравилось, если бы на Ваш вопрос не отвечали, потому что отвечающим не надо?

Этот топик могут читать и потом, и узнавать что-то. Поэтому старайтесь вносить и свой ответный вклад.

Но хорошо, что проблема решена

[sokol92]

Этот недостаток легко исправляется фиксацией локализации отдельной ячейки.

Здесь у меня отличная точка зрения.  
Разработчики Excel ошиблись при проектировании функции TEXT, локализовав второй параметр, и последствия этой ошибки мы до сих пор ощущаем.
В LO сделана попытка эту ошибку "затушевать", но это нарушает принцип независимости результатов вычисления формул от форматов ячеек (кроме специальных функций типа CELL). Изменение формата ячеек само по себе не вызывает пересчет формул, пользователи могут поменять форматы ячеек, не считая это "опасной" операцией и т.д.

По хорошему, нужно забыть про функцию TEXT и создать какой-нибудь TEXT2 (или TEXTEN), который будет работать как TEXT со вторым параметром, задаваемым в соответствии с локализацией en_US (по типу Format в Basic).

И пара "монструозных" формул (хотя я не "формулист"), которые должны работать в любой локали.

Представление числа как текста с 2 дробными знаками, разделитель дробной доли запятая, разделитель тысяч отсутствует.

Код Выделить Развернуть

=SUBSTITUTE(FIXED(A2;2;1); MID(3/2;2;1);",")

Представление числа как текста с 2 дробными знаками, разделитель дробной доли запятая, разделитель тысяч пробел.

Код Выделить Развернуть

=SUBSTITUTE(SUBSTITUTE(FIXED(A2;2);MID(FIXED(1234);2;1);" ");MID(3/2;2;1);",")

В этих формулах есть простые способы определения разделителя дробной доли и разделителя тысяч.

[mikekaganski]

Этот недостаток легко исправляется фиксацией локализации отдельной ячейки.

Здесь у меня отличная точка зрения. 

Ваши слова не противоречат моим

Вы говорите про принципиальные архитектурные проблемы, заложенные даже не в Excel, а раньше. 1-2-3, наверное.

А я писал про возможность исправить конкретную проблему в конкретной книге, не описывая своего отношения к тому факту, что проблема сама по себе есть

[Sirius34]

"без пробела косяки". И я заинтересовался, потому что насколько я знаю, так не бывает, но всегда находятся вещи, которых мы не знали, а они есть

Хорошо, попробую пояснить, хотя мне уже очевидно, что здесь, скорее всего, виноват я сам в некорректной формулировке,
чем запутал и себя, и Вас.

Пока локаль ячейки не изменена принудительно на русскую, то использование, что TEXT(A2,"0,00"), что FIXED(A2,2) приведёт
либо к некорректному округлению, как 1,235, например, либо к использованию запятой в качестве разделителя разрядов,
а точки, как разделителя дробной части.
Согласитесь, что для русских пользователей, пусть даже и в англоязычном интерфейсе, это неправильно.
Да и смотрится кривовато, глаза режет даже тем, кто далек от бухгалтерских вопросов.
При этом, я прекрасно понимаю, что чисто математические операции с исходными данными ошибок не вызовут.
Но в моей ситуации речь идёт о формировании таблицы, которая будет выгружаться во внешний файл, потом отправляться по
электронной почте, ну и распечатываться для приобщения к официальному номенклатурному делу.
Поэтому, вопрос ВИЗУАЛЬНОЙ корректности данных довольно существенен.

А вот при использовании русской локали в конечной ячейке проблема с TEXT отсутствует, но FIXED опять же
работает по стандартам локали самого LO.
Наглядевшись на разделители разрядов "по умолчанию", я уже не хочу оставлять этот параметр без внимания,
поэтому явно прописываю пробел в формате преобразования.
Кстати говоря, с ячейкой в английской локали, в отличие от русской, использование пробела вызывает жуткие
преобразования чисел, именно поэтому я и хотел найти более-менее универсальное решение.

Немного сумбурно изложил, наверное

[mikekaganski]

Спасибо!

Да, запятая в числе в качестве разделителя разрядов вообще может быть серьёзной проблемой, если при этом нет десятичной точки (целое число) - скажем, 1234 отобразится в напечатанном документе как 1,234 - и потом доказывай, что не верблюд

[sokol92]

1234 отобразится в напечатанном документе как 1,234

Если это удержание из зарплаты, то прекрасно, а вот если начисление...