В продолжении кнопок без фигуры отдельно хочу рассмотреть выбор стандартного периода в Бухгалтерии предприятия.

В этой форме у всех кнопок отображение фигуры При активности, хотя сценарий выбора периода - это основное предназначение формы. А значит формально нет смысла скрывать кнопки от пользователя.

Но если все кнопки отобразить, то это выглядет перегруженно. Все таки нужно выбирать из 20 кнопок тяжеловато.

Поэтому скрытие фигуры в этом случае немного облегчает форму. Плюс и цветовая градация периода скрывается и не цепляет взгляд.

Что еще интересного в этой форме:
1. Выбор стандартного периода осуществляется в два клика. Буквально: 1й клик - Открыли форму выбора периода, 2й клик - Нажали на нужный период.

2. У кнопки «День…» не логичное расположение. Так как кнопки идут по такой логике: Месяцы, Кварталы, Нарастающий период. На месте кнопке «День...» должна быть кнопка «1 квартал». Кстати, раньше так и было.

3. Кнопка «День…» имеет многоточие, чтобы показать. что кнопка открывает новую форму, а не выполняет действие. Кстати, в этой форме выбор дня тоже осуществляется по 1 клику.

#Design

⬆️⬆️⬆️

Вот так бы выглядела форма выбора стандартного периода, если бы мы отображали фигуры у кнопок.

#Design

Мудрость и безумие толп

Ранее делился игрой-иллюстрацией Эволюция доверия. В ней рассказывается и доказывается математически, что доверять людям в принципе выгодно. Даже есть смысл прощать, если человек случайно ошибся, но вот если он это делает несколько раз, то это уже может быть большей проблемой. И все это на понятных примерах. Если кто пропустил, то очень рекомендую.

Сегодня хочу поделиться еще одним шедевром от этих ребят - Про мудрость и безумие толп. Эта штука немного сложнее - тут нужно будет думать, выстраивать связи и рисовать - https://ncase.me/crowds/ru.html

Займет минут 20 и заставит задуматься о уже выстроенных связях (полезных и не очень). В свое время меня эта игра побудила сильнее налаживать связи между отделами - так ты больше и лучше узнаешь все вокруг. Ну и в целом нетворкинг с разными группами людей - это очень крутой инструмент.

Рекомендую к неспешному изучению в пятницу!
https://ncase.me/crowds/ru.html

Непреложные законы управления проектами

ЗАКОН 1
Ни один крупный проект никогда не завершается
- вовремя,
- в рамках запланированного бюджета
- и силами той же команды, что его начинала

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

Следствия:
1. Выгода от реализации будет значительно меньше той, на которую рассчитывали сначала, если кто-то вообще на что-то рассчитывал
2. Система будет в конце концов внедрена с опозданием и без тех функций, для выполнения которых она предназначалась
3. Затраты окажутся выше плановых, но с технической точки зрения все будет в порядке

ЗАКОН 2
Преимуществом размытых формулировок при постановке целей является то, что они позволяют избежать в последствии проблем при внешнем контроле освоения бюджета проекта

ЗАКОН 3
Количество усилий, которые необходимо приложить к исправлению ошибок на проекте, идущем не по плану, с течением времени увеличивается в геометрической прогрессии

Следствия:
1. Чем дольше ждешь, тем труднее становится
2. Если ждать до окончания проекта, будет уже слишком поздно
3. Возьмитесь за дело прямо сейчас, как бы вас это ни смущало

ЗАКОН 4
Сформулированную вами миссию проекта все трактуют иначе, чем вы

Следствия:
1. Если вы объяснили цель проекта настолько четко, что вряд ли могут быть какие-либо разночтения, все равно найдется тот, кто поймет ее неправильно
2. Если вы делаете то, что, по вашему мнению, должно быть принято всеми с одобрением, все равно найдется тот, кому это не понравится

ЗАКОН 5
Реальной является лишь та выгода, которую можно измерить. Нематериальную выгоду измерить нельзя. Таким образом, нематериальная выгода не является реальной

Следствия:
1. Нематериальная выгода может быть реальной, если вы сумеете это доказать

Выводы:
- Делайте измеримыми все показатели, за которые вы хотите, чтобы вас похвалили
- Если у вас есть ценности, сделайте так, чтобы работа измерялась по показателям, связанным с этими ценностями

ЗАКОН 6
Если человек сейчас может эффективно уделить свое время проекту, значит, в настоящее время ему нечем заняться

Следствия:
1. Если непосредственный начальник не загрузил сотрудника полностью, то и вам не следует его перегружать
2. Если у сотрудника несколько задач накладываются по времени одна на другую, расстановка приоритетов будет в пользу заданий, полученных от непосредственного руководителя

ЗАКОН 7
Чем сложнее техническая сторона проекта, тем меньше необходимость в руководителе-технаре

Следствия:
1. Найдите самого хорошего руководителя для проекта. А технических специалистов он подберет сам
2. Правило, обратное следствию 1, не срабатывает практически никогда

ЗАКОН 8
Проект займет втрое больше времени, чем ожидалось, если он спланирован плохо, и вдвое больше если спланирован хорошо

Следствия:
1. Если нет ничего, что могло бы пойти не по плану, все равно что-нибудь будет не так

ЗАКОН 9
Если реализация проекта проходит гладко, все равно случится что-нибудь непредвиденное

Следствия:
1. Если ситуация уже хуже некуда, она все равно еще ухудшится
2. Если кажется, что дела пошли в гору, значит, вы чего-то не замечаете

ЗАКОН 10
Проектные команды терпеть не могут еженедельные отчеты о ходе проекта, так как по ним сразу видно, что ничего не происходит

ЗАКОН 11
Реализация идет бодро, пока не достигает отметки 90%
Затем проект навсегда остается выполненным лишь на 90%

ЗАКОН 12
Если нет ограничений на изменение содержания проекта, скорость, с которой будут происходить изменения, превысит скорость, с которой идет само выполнение работ

ЗАКОН 13
Если пользователь не доверяет системе, на свет появится другая — ей параллельная.
И ни одна из них не будет работать как следует

ЗАКОН 14
Степень полученной от проекта выгоды является производной от тщательности проведения аудита результатов работ

Следствия:
1. Перспектива независимой проверки результатов проекта является мощным стимулом для проектной команды сделать продукт качественно, вовремя и в рамках запланированного бюджета

ЗАКОН 15
Непреложных законов не бывает

(с) Лич Лоуренс - Вовремя и в рамках бюджета

На GitHub

Я раньше боялся схемы запросов. Для меня это какая-то неведомая технология, где обычный текст запихивается в сложный объект и с ним там работаешь. Я старательно избегал его и для редактирования запросов использовал СтрЗаменить и конкантенацию строк.

Но редактирование текста ошибкоемко - легко можно развалить запрос, особенно когда используются сложные условия. Да и редактировать текст не всегда может быть удобно удобно.
Конечно, нужно использовать параметры в запросе, а не просто менять текст, например, так неправильно:

"ВЫБРАТЬ
| Номенклатура.Наименование  КАК Наименование ,
| Номенклатура. " + ИмяПоляКод + " КАК КодАртикул
|ИЗ
| Справочник.Номенклатура КАК Номенклатура";

а вот так правильно:

ТекстЗапроса =
"ВЫБРАТЬ
| Номенклатура.Наименование  КАК Наименование,
| &ИмяПоляКод  КАК КодАртикул
|ИЗ
| Справочник.Номенклатура КАК Номенклатура";

ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&ИмяПоляКод", "Номенклатура." + ИмяПоляКод);

Про это целый стандарт есть как правильно оформлять тексты запросов. Там разбираются типичные ошибки в оформлениях и предлагаются решения.

Я с легкой завистью смотрел на коллег, которые используют Схему запросов. Но самому было как-то страшновато это пробовать. Да и зачем - если через замену строк все так же будет работать, да и выглядит понятнее. Так я себя оправдывал.

И вот на текущем проекте настало время. Нужно редактировать запрос так, что через СтрЗаменить и параметры работает и выглядит плохо. И я начал использовать СхемаЗапросов. Было страшно…

Причем я использовал только замену условий сортировки и параметров, а сам текст запроса заполнил изначально как обычно. И вот тут мне прям понравилось - это гораздо проще для редактирования и программной обработки запроса. Сначала, кажется, сложно и непонятно, но уже относишься к этому проще.

Может быть неправильный термин - боюсь технологию, но я за собой такое замечал, что не хочу что-то использовать, чтобы не тратить силы на изучение или не бороться с последствиями, если что-то пойдет не так. Думаешь, что вот сейчас разбираться в этом, а потом если что-то пойдет не так, но ошибку очень долго искать. Гораздо проще использовать свой Золотой молоток.

И вот такие моменты, где я выбирал инструмент попроще вместо сложного - у меня остаются в памяти. Я к ним иногда примеряюсь - смогу ли я сейчас его применить?

Потихоньку такой список становится все меньше и меньше. Еще есть сложные задачи в виде удаления субконто с плана счетов, но и к этому придем.

Стандарт: Оформление текстов запросов
Статья: Объектная модель запроса Схема запросов
Антипаттерн: Золотой молоток

#Разработка

Про релизы Бухгалтерии

Релизы бывают Плановые, Внеплановые (Исправительный) и Актуальный, Финальные, Тестовые и Ознакомительные.

📅 Плановый релиз - релиз, в котором добавляют новые задачи и библиотеки, у него самое большое описание Новое в версии.
Это обычно первый релиз с изменением 3 цифры, например, сейчас актуальный релиз 3.0.155.23, а значит следующий плановый будет 3.0.156.х.
Такие релизы обычно выходят раз или два в месяц.

🚀 Внеплановый или исправительный релиз - релиз, который содержит либо исправление ошибок планового релиза, либо срочные изменения законодательства. Так как изменения законодательства не могут ждать, то их стараемся выпускать как можно быстрее.
Это релиз с изменением 4 цифры, например, плановый релиз 3.0.155.21, а внеплановый 3.0.155.23.

🎯 Актуальный релиз - последний опубликованный финальный релиз. Тут не важно - плановый или внеплановый - просто текущий релиз опубликованный на releases.1c.ru

🛠️ Тестовый релиз - релиз-кандидат, который отправляется на публикацию на Фреш. Тестовый релиз полностью прошел все наши проверки и готов к публикации. В качестве тестового он находится все то время пока команда Фреша проводит свои проверки и публикует его. В некоторых случаях релиз отзывается, если найдена какая-то ошибка. Например, релиз 3.0.155.23 был опубликован как тестовый 27.06, а финальным он стал 02.07, так как по заветам предков - на выходных не обновляются.

🏁 Финальный релиз - релиз, который прошел все проверки на Фреше и развернут на части баз. После этого релиз-кандидат переводится из Тестового в Финальный.

⚠️ Ознакомительный релиз - релиз, с экспериментальной функциональностью. Этот релиз не предназначен для ведения реальной работы и нужен для ознакомления с новыми функциями. Такой релиз обычно имеет завышенную версию, например, 3.0.300.х и с него нельзя будет обновиться на обычный релиз. Например, такой релиз мы делали с переходом на Такси.


✅ Все релизы проходят наши проверки: синтаксические проверки, статический анализ кода, сверка движения, автотесты и финальное тестирование.

❤️ Такой подход к релизам действует для всех конфигураций, выпускаемых в нашем отделе:
Бухгалтерия предприятия, БизнесСтарт, Бухгалтерия некоммерческой организации, Садовод и Гаражи.

#Разработка

А вы знали, что Система компоновки данных - это запатентованная технология фирмы 1С?

Вот ссылка на патент.
Авторы:
- Сергей Георгиевич Нуралиев
- Максим Михайлович Лейбович

Дата публикации патента: 2015.06.18.
В посте главная картинка из патента с принципиальной схемой.

Перевод реферата патента:

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

Причем это международный патент.

Поэтому можно смело в резюме менять текст «умею в СКД» на
«Использую технологию, созданную умами величайших инженеров планеты, защищенную строгими патентами, что делает ее эксклюзивной и недоступной для широкой публики. Это нечто, что выделяет меня из толпы, подчеркивает мою индивидуальность и демонстрирует приверженность к инновациям.
Технология использует передовые достижения науки и техники, чтобы предложить пользователю непревзойденный опыт. Это - квинтэссенция инноваций, слияние искусства и технологий, которое позволяет мне быть на шаг впереди времени.»

Также фирмой 1С запатентованы технологии регистры расчетов и создание форм в управляемом интерфейсе.

Игра «Выигрывает тот, кто ближе к половине»

Сейчас с большим удовольствием читаю Теорию игр. Очень интересно размышлять и погружаться в эти равновесия Нэша (тот самый математик из фильма Игры разума), находить фокальные точки и продумывать шаги наперед.

В книге приводится интересная игра - Выйграет тот, кто ближе к половине.

Условия:
«Каждый игрок должен выбрать число от 0 до 100 включительно.
Выигрывает тот, у кого число ближе к половине числа другого игрока»


Давайте и мы с вами в нее сыграем.
Я выбрал число и оно под спойлером ниже.
Теперь ваша очередь.


Мое число: 12,5
Кто победил?

🔥 - Выиграл автор
👍 - Выиграл читатель

⬇️⬇️⬇️

⬆️⬆️⬆️

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

Мое второе число: 0.00
Кто победил?


Размышления:

Выбирать число больше 50 нет смысла, так как, например 55 - это половина от 110, а по условиям верхняя граница ограничена 100, значит выбирая это число я точно не попаду в половину вашего числа.

Значит есть смысл выбирать от 0 до 50. У Вас скорее всего будет такая же логика про мои ходы.
А значит вы можете выбрать число около 25, чтобы обыграть меня.

А значит мне нужно целиться в от 0 до 25, чтобы победить.
Поэтому в первом раунде выбираю число 12,5.

Если у Вас число больше, чем 12,5, то я выигрываю.

Почему это может сработать? Обычно люди продумывают игру на 2-3 хода. Исходя из этого 12.5 вполне адекватное число для первого раунда.

Но во втором раунде уже начинают продумывать сильнее, поэтому если прогнозировать шаги дальше, то будет 6,25, 3,125, 1,5652 и так далее. То есть число будет стремиться к нулю. И кто будет ближе к 0, тот и победит.

Причем на самом деле выбор 0 - это единственная выигрышная стратегия.

Ведь чтобы победить нам нужно оказаться слева от выбранного соперником числа, только в этом случае половина этого числа будет меньше выбранного числа.
Поэтому 0 будет всегда ближе к половине любого другого числа, которое вы выбираете.

🔥 - Выиграл автор
👍 - Выиграл читатель

#books #fun

Давайте знакомиться!

Всем привет! На канале много новых людей, поэтому давайте знакомиться!

Меня зовут Никита Арипов, мне 36 лет.
В телеграм-канале рассказываю о технологиях, дизайне и различных проектах, связанных и не связанных с 1С. Сейчас готовлю серию постов о фейлах в работе и проектах, скорее всего будет на следующей неделе.

Программированием увлекаюсь с детства, помню как делал игру на FoxBASE. А с 1С познакомился работая продавцом на складе, там нужно было подправить печатную форму в УТ 7.7. После университета пошел работать в свой региональный франч, ну и потом закрутилось-завертелось :)

Коротко о себе:
- Работаю в фирме "1С" 11 лет
- Отвечаю за выпуск и разработку 1С:Бухгалтерия некоммерческой организации
- Разрабатываю 1С:Бухгалтерия предприятия
- Занимаюсь автоматизацией процессов и внедрением современных технологий
- Лауреат и победитель премии Infostart Awards 2017
- Профиль на Инфостарт и мои лучшие публикации
- Профиль на GitHub

Полезные материалы:
- Статья Стек технологий для 1С
- Статья Шаблон новых объектов для 1С:Бухгалтерии
- Видео Инструменты и процессы разработки 1С:Бухгалтерии
- Видео Полезные обработки и инструменты

Диалоговое окно

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

Вот несколько правил, которые помогут сделать хорошее диалоговое окно:
1️⃣ Сообщение диалога должно быть понятным (спасибо, Кэп!).
Важно рассказать, что планируется сделать и что требуется от пользователя.
Сам вопрос лучше начинать с новой строки, чтобы явно выделить действие.

2️⃣ Описания действий на кнопках должны быть четкие.
В утвердительной кнопке лучше повторить действие из вопроса, которое запрашивается у пользователя. Стоит обратить внимание на действия со словом Отмена, чтобы избежать ситуаций, когда будет две кнопки «Да, отменить» и «Отменить».

3️⃣ У пользователя должна быть возможность закрыть диалог без выбора действия.
Обычно пользователь для этого закрывает диалог по крестику в правом верхнем углу. Но если нет кнопки с КодВозвратаДиалога.Отмена, то иконка будет доступна. Стоит такую кнопку добавлять самостоятельно, например, вместо негативного действия.

Пример на оповещениях:

ТекстВопроса = 
    "Для отключения уведомлений и комфортной работы рекомендуем использовать режим тишины.   
     |В этом режиме будут приходить только важные уведомления 
     | 
     |Установить режим тишины?";

Кнопки = Новый СписокЗначений;
Кнопки.Добавить(КодВозвратаДиалога.Да, "Установить режим тишины");
Кнопки.Добавить(КодВозвратаДиалога.Отмена, "Нет, оставить как есть);

ОписаниеОповещения = Новый ОписаниеОповещения("УстановитьРежимТишиныЗавершение", ЭтотОбъект);
ПоказатьВопрос(ОписаниеОповещения, ТекстВопроса, Кнопки);

Пример на Асинх:

&НаКлиенте 
Асинх Процедура ЗадатьВопрос() 
  
 ТекстВопроса =  
  "Для отключения уведомлений и комфортной работы рекомендуем использовать режим тишины.   
  |В этом режиме будут приходить только важные уведомления 
  | 
  |Установить режим тишины?"; 
  
 Кнопки = Новый СписокЗначений; 
 Кнопки.Добавить(КодВозвратаДиалога.Да, "Установить режим тишины"); 
 Кнопки.Добавить(КодВозвратаДиалога.Отмена, "Нет, оставить как есть"); 
  
 Результат = Ждать ВопросАсинх(ТекстВопроса, Кнопки); 
  
 Если Результат = КодВозвратаДиалога.Да Тогда 
  Сообщить("Режим тишины установлен"); 
 КонецЕсли; 
  
КонецПроцедуры

#Design

Как правильно сообщить пользователю об ошибке

Для сообщения об ошибке есть 5 основных правил:

1️⃣ Расскажите пользователю, что он сделал или что произошло
2️⃣ Объясните проблему
3️⃣ Объясните как исправить ошибку
4️⃣ Используйте активный, а не пассивный залог
5️⃣ Приведите пример

Об этом рассказывает Сьюзан Уэйншенк в своей книге «100 главных принципов дизайна»

🎯 В 1С:Бухгалтерии одной из ключевых операций является Закрытие месяца. В этом месте пользователь чаще всего сталкивается с ошибками. Причем порой они могут и не знать, почему это неправильно.
Важно именно в этом месте рассказать не только об ошибке, но и о том что нужно знать и как это исправить.

💡 На скриншоте часть кода формирующего описание и объяснение ошибки, и он чуть ли не больше, чем код выполняющий эту операцию. Полное описание кода можно посмотреть в

КонтрольЗатрат.ОписатьРасходыНеУдалосьРаспределить()

❗ Понятно, что такое описание ошибок не везде. Порой возникает малоинформативное «К сожалению, возникла непредвиденная ошибка». С этим, к сожалению, ничего не поделаешь - так сейчас выводит ошибка платформа. И есть вот инструкции от партнеров как быть в этом случае пользователю. Но если есть возможность обработать ошибки, то лучше придерживаться правил.

📖 Еще полезное видео и его расширфровка про то как сообщать пользовать, если что-то пошло не так

А вы знали, что конфигурация 1С:Гаражи самая большая в линейке бухгалтерских программ?

Мы выпускаем 5 бухгалтерских программ для хозрасчетного плана счетов. 1С:БизнесСтарт, 1С:Бухгалтерия предприятия, 1С:Бухгалтерия некоммерческой организации, 1С:Садовод и 1С:Гаражи.

Всему голова - 1С:Бухгалтерия предприятия - это прям основа основ, конфигурация конфигураций. 1С:БизнесСтарт - это базовая версия конфигурации со своими особенностями в настройках, но код весь одинаковый.

На базе БП выпускается 1С:Бухгалтерия некоммерческой организации. Причем 1С:Бухгалтерия предприятия входит в конфигурацию поставщиков, как другие библиотеки. А в самой конфигурации мы уже добавляем всю необходимую специфику некоммерческих организаций.

Тоже самое и с Садоводом. На базе 1С:Бухгалтерии некоммерческой организации мы выпускаем 1С:Садовод. То есть там есть все, что есть в Бухгалтерии предприятия и в Бухгалтерии НКО, плюс специфика садовых товариществ. Конечно в интерфейсе мы убрали все лишнее, чтобы не отвлекать пользователя от работы, но в коде это все остается.

На базе 1С:Садовод уже выпускается 1С:Гаражи. В принципе эти конфигурации одинаковые, просто заменены Участки на Гаражи, но тем не менее конфигурация содержит в себе 1С:Садовод, 1С:Бухгалтерия некоммерческой организации и 1С:Бухгалтерия предприятия.

Таким образом, 1С:Гаражи - это самая большая конфигурация в матрешке наших типовых бухгалтерских программ.
Причем, если вы разбираетесь в Бухгалтерии предприятия, то считайте, что и в остальных наших программах разбираетесь.


P.S. Cейчас поднимают петицию про размеры конфигураций. Суть проблемы в том, что во всех конфигурациях храняться драйверы подключаемого оборудования. И они занимают ощутимый размер.

Ну и еще пятничное, я вот собираю различные эффекты и феномены. Пока список небольшой:

Эффект Зейгарник - психологический эффект, заключающийся в том, что человек лучше запоминает прерванные действия, чем завершённые

Феномен Баадера - Майнхоф - это когда недавно узнанная информация, появляющаяся вновь спустя непродолжительный период времени, воспринимается как необычайно часто повторяющаяся

Эффект Даннинга - Крюгера - это когда человек плохо разбирается в чем-то, но мнит себя гением. Из-за этого часто приходят к ошибочным выводам и делают неудачный выбор

Эффект амнезии Гелла-Манна - учёный читает СМИ, видит полный бред по СВОЕЙ теме и возмущается, затем перелистывает то же самое СМИ и полностью доверяет тому, что написано по теме, ему незнакомой

Алгоритм Бойера — Мура - алгоритм общего назначения, предназначенный для поиска подстроки в строке

Пользовательская история

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

Например, для упрощения номенклатуры такая история могла бы звучать так:
Я как, бухгалтер,
хочу быстро завести номенклатуру,
чтобы продолжить оформлять свой документ.

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

Вчера мы рассмотрели один из вариантов решения - упрощение формы, убрав реквизиты в сворачиваемые группы. Но у пользовательской истории могут быть разные варианты решения.

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

И мы такой сценарий тоже поддержали, но уже позже. Во вложении как раз реализация такого быстрого создания номенклатуры на лету из документа.

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

Упрощение справочника Номенклатура. Проблема

Итак, мы выпустили упрощенную форму номенклатуры и получили просто шквал обращений на хотлайн и на партнерскую конференцию.

Проблема была в том, что я ошибочно предположил, что Наименование и Полное наименование заполняется одинаковыми значениями, а те кому важен этот реквизит смогут достать его через пользовательскую видимость (Еще - Изменить форму).

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

Мы рассказывали на форуме и в хотлайне как включить это поле через Еще - Изменить форму, но с проблемой столкнулось слишком много людей. Негатив нарастал.

Поэтому было решено вернуть видимость реквизита Полное наименование по умолчанию и выпустить исправительный релиз. Тогда патчей не было и изменения можно было доносить только релизами.

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

После этой проблемы мы добавили в шаблон проекта обязательный вопрос - А кому станет хуже от проекта?

#fail