СПО приходит в российский бизнес

Изображение пользователя Школяр.

На прошлой неделе я проводил курсы по OpenOffice.org Calc для работников крупной российской компании-дистрибьютора (чего они дистрибутируют, и что за компания - сообщать не уполномочен).
Во-первых: компания заменила почти поголовно Windows на Linux, потому что это ЭКОНОМИЧЕСКИ ВЫГОДНО (кто бы и что ни говорил).
Во-вторых: кому интересен дистрибутив - они установили последнюю версию SUSE.
В-третьих: поскольку я привык проводить курсы с аудиторией "с нуля", то в этот раз я поимел очень интересный опыт - все слушатели уже наработались в OO Calc и пришли не столько учиться, сколько задать вопросы.
Если на часть вопросов ответы находились довольно легко (я даже отвечать не успевал, слушатели сами друг другу отвечали), то другая часть вопросов выявила возможные (и немалые) проблемы при переходе от MS Office к OpenOffice.org, причем проблемы связанные с медленной реакцией (или вообще отсутствием какой-либо реакции) со стороны разработчика на запросы пользователей. В частности, проблема разделителя в числах с плавающей точкой и представлениях валюты. При русском языке в OO Calc это запятая, а множеству пользователей нужна точка (при импорте из текстовых файлов, при копировании данных от зарубежных партнеров). Вопрос висит в воздухе почти год. Или, другие грабли: при импорте данных из веб-таблиц все поля Calc старается подогнать под формат, который сам считает правильным. И поле "артикул" со значением 6-127 ухитряется отобразить как дату. Обратное преобразование, естественно, уже ничего хорошего не дает. И таких вопросов мне накидали штук 5 или 6, на которые нет ответа. Кому интересно - пишите, обсудим.
Но в общем, несмотря на проблемы, переход на СПО и Linux в качестве пользовательских рабочих столов в российском бизнесе начался, без всяких приказов сверху, просто потому что это ВЫГОДНО. Ура!

Изображение пользователя den2007.

Да, все верно, но решаемо.

Наcчет,
поле "артикул" со значением 6-127 ухитряется отобразить как дату.

Да, все верно.
Так как автоматически определяется как дата, в отличии от MS, где оно определяется как текст.
Это задано форматом даты (хотя кто до этого формата додумался?)
Решение простое, надо сразу задать текстовый формат ячейкам, которые должны содержать такие артикулы и все.
Вообще, несколько раз сталкивался с базами данных, там практически везде надо указывать формат.
Теперь взял за правило, при создании больших(важных) таблиц сразу задаю форматы для ячеек и защищаю формулы, а такое же и с MS 2003 было, учителя несколько раз подходили, правда там фокусы с 8/52 были (актуально и для OpenOffice).

Что касается запятой, то по умолчанию используется значение из ОС(стоит галочка "Из настроек ОС" в Сервис -> Параметры -> Настройки языка -> Языки)
т.е.поменять можно в ОС, в KDE меняется быстро.
Хотя можно просто все задавать в формате ячеек (например, язык английский, категория числовой, формат 1234.56)

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

Про импорт из веб-таблиц не скажу, так как нужна более подробная информация.

Так что грабли старые.

Изображение пользователя Школяр.

Если бы было решаемо...

Насчет точки в качестве разделителя - решаемо, через "задний кирильцо". А вот насчет веб импорта артикулов как дат - нет, поскольку при импорте из веба предварительно установленные в "текст" ячейки сдвигаются, и CAlc на их место снова сует ячейки в том формате, в который он их при импорте преобразовал. Увы :(