В динамических списках есть возможность выполнять поиск по полям, на которые не наложено ограничение отбора.
Его можно вызвать через сочетание клавиш CTRL+F или ALT+F.

В данной форме поиска помимо поля "Что искать" также очень важно поле "Как искать".
У этого параметра есть три режима:

• По началу строки
• По части строки
• По точному совпадению

При выборе пользователем режима "По части строки", на СУБД в запросе отбор будет сформирован по шаблону "Подобно %ПодстрокаПоиска%", т.е. будет скан таблицы целиком, даже если по данному полю есть индекс.
Большинство пользователей никогда не меняют значение в поле "Как искать", поэтому они очень долго ожидают окончания поиска и нагружают базу.

И это при том, что на строковых полях такая настройка включена по умолчанию.

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

Добавить во встроенный язык 1С метод ДобавитьКДате()

По аналогии с одноименным методом в языке запросов и СКД:

ДОБАВИТЬКДАТЕ(<НачальнаяДата>, <ЕдиницаВремени>, <Сдвиг>)

На данный момент есть только метод ДобавитьМесяц()
Во всех остальных операциях нужно использовать волшебное число 86400

Или, как вариант, можно сделать тогда уже методы на подобии ДобавитьМесяц(), но для других единиц времени:
ДобавитьСекунду(), ДобавитьМинуту(), ДобавитьДень(), ДобавитьНеделю() и так далее

Но метод ДобавитьКДате() выглядит более универсально и при этом соответствует языку запросов и СКД.

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

Это можно отнести к объектам (общие модули, документы, справочники), реквизитам объектов, формам, а так же реквизитам форм.

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

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

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

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

Возможность сохранить объект функции и потом где-то в другом месте её вызвать.

Функция А()

КонецФункции

Процедура Б()
     // в этот момент функция не вызывается, а сохраняется в переменную как объект
     СохраненнаяФункция = А;
      
     СохраненнаяФункция();
КонецФункции

Предопределенная процедура формы "Инициализация".
Все размещенные элементы на управляемой форме (поля ввода, группы, таблицы и тд) генерят програмный код создания этих элементов в предопределенную процедуру формы Инициализация(..)
Профит:
Всё есть код, в том числе элементы формы. Модифицировать логику формы проще, работать с элементами формы через расширение проще, сравнивать например при обновлении проще. При выгрузке в файлы в формате конфигуратора или едт код более читабельный чем богомерзкие xml. Мержить конфликты проще чем xml.

Добавить описание общих шаблонов РЛС в отдельном объекте метаданных.
Сейчас в типовых конфигурациях один и тот же типовой шаблон ограничения описывается для каждой роли. В итоге, если надо поправить шаблон, его приходится править для всех 100500 ролей в дереве метаданных.
Например, две роли имеют один и тот же шаблон. Тексты шаблонов одинаковые, абсолютно. Если мы меняем типовой шаблон (а это все БСПшные типовые шаблоны - "ПоЗначениям", "ПоЗначениямРасширенный", "ДляРегистра"...), тогда придется поменять его во ВСЕХ ролях, которые используют шаблон.

В управляемой форме нельзя, находясь на клиенте, однозначно определить значение, которое указано в элементе.
Сами данные у нас на форме есть. В элементе есть свойство ПутьКДанным. И, вроде бы, мы можем по нему получить значение, но:

1. Свойство доступно только на сервере
2. Свойство содержит строку формата "Реквизит1.Реквизит2.РеквизитN", которую приходится обрабатывать кодом самостоятельно.

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

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

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

Когда пользователь пролистывает форму списка со сложным отбором\запросом, то весь клиентский сеанс висит. И блокирует работу пользователя. Хотя от его сеанса не требуется ничего, кроме как просто ждать.

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

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

Сейчас при вводе строки в поле полнотекстового поиска 1С по такому же принципу генерирует фоновое задание и получает через него результат:

Добавить возможность вывода в результат запросов "страниц" для реализации списков сторонних сервисов. Т.е. вывода результата от определённой ссылки некоторое количество элементов.

OFFSET 3 ROWS 
FETCH NEXT 2 ROWS ONLY // пропустить первые 3 строки и вывести 2 следующие за ними строки

Это будет полезно для реализации списков (товаров, заказов, документов) сторонних сервисов (сайтов)
как это сейчас работает, например на странице выводится 10 записей:
1 страница - Выбираем первые 20 записей
2 страница - Выбираем первые 40 записей
10 страница - выбираем первые 200 записей

после выбора этих данных, определяем те которые попадают в нужный нам диапазон, например 180-200 запись
делаем второй запрос в котором считаем дополнительные данные связанные по нужным нам документам.

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

T-SQL код MSSQL И Postgres:
выберем только три строки, начиная с третьей

SELECT * FROM Products
ORDER BY Id 
    OFFSET 2 ROWS
    FETCH NEXT 3 ROWS ONLY

1С при реструктуризации сама делает основные миграции, но что если добавить возможность посмотреть, какие миграции будут выполнены и позволить вносить изменения и добавлять новые свои

Как сейчас:

Управляемая форма при закрытии может возвращать результат. Для этого необходимо закрывать форму при помощи метода Закрыть(РезультатЗакрытия). Возвращаемый результат можно "поймать" с помощью обработчика, который объявлен в ОписаниеОповещенияОЗакрытии.
Если закрыть форму стандартными командами формы, например ОК, Да, Отмена, то в обработчик, который указан в ОписаниеОповещенияОЗакрытии будет передан РезультатЗакрытия со значением Неопределено.

Предложение:

В коллекцию свойств формы добавить свойство РезультатЗакрытия
Передавать свойство РезультатЗакрытия в обработчик, который объявлен в ОписаниеОповещенияОЗакрытии при любом сценарии закрытия формы.

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

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

Предлагаем сделать возможность пакетно изменять данные объектов специальным классом платформы. Этому поможет объектная оболочка для методов UPDATE\DELETE\INSERT, используя которую, разработчик будет реализовывать алгоритм с учетом нюансов непосредственного изменения данных.

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

Когда пишешь универсальную обработку, то сталкиваешься с проблемой, что база, в которой её запустят, может не содержать какого-нибудь платформенного метода. Например, СтрРазделить().

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

Предлагаю сделать возможность в директивах компиляции указывать версию платформы и\или режим совместимости.

Например, здесь мы добавляем в обработку функцию СтрРазделить() на тот случай, если не будет платформенной

#Если &ВерсияПлатформы < 8.3.6 Тогда
       
Функция СтрРазделить(Строка, Разделитель, ВключатьПустые) Экспорт
       
       <...>
       
КонецФункции
       
#КонецЕсли

А здесь мы внутри процедуры используем новый платформенный метод взамен устаревшего.

Процедура ОбработатьФоновыеЗадания(ОбрабатываемыеЗадания) Экспорт
       
       <...>
       
       #Если &ВерсияПлатформы >= 8.3.13 Тогда
           ФоновыеЗадания.ОжидатьЗавершенияВыполнения(ОбрабатываемыеЗадания);
       #Иначе
           Попытка
               ФоновыеЗадания.ОжидатьЗавершения(ОбрабатываемыеЗадания);
           Исключение
           КонецПопытки;
       #КонецЕсли
       
       <...>
               
КонецПроцедуры

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

Пример

Функция ВернутьЧтоТо(ПараметрыВыполнения)

   ЧтоТо = Неопределено;
    //<...>
   Возврат ЧтоТо

КонецФункции


МояФункция = Новый Функция("ВернутьЧтоТо");
Параметры = Новый Структура();
Результат = МояФункция(Параметры);

Таким образом мы сможем хранить в переменной функции и выполнять их по мере необходимости.

Ещё как усложненный вариант (альтернативная реализация) давать возможность указывать "контекст" выполнения метода. В качестве простой реализации можно сделать так, чтобы контекст передавался автоматически первым параметром.

Пример:

Функция СложитьЗначения(КонтекстВыполнения, ДополнительныеПараметры = Неопределено) экспорт
    
    Результат = КонтекстВыполнения.Число1 + КонтекстВыполнения.Число2;
    Если ТипЗнч(ДополнительныеПараметры) = Тип("Число") Тогда
         Результат = Результат + ДополнительныеПараметры;
    КонецЕсли;

   Возврат Результат;

КонецФункции

МойОбъект = Новый Структура();
МойОбъект.Вставить("Число1", 5);
МойОбъект.Вставить("Число2", 5);

//Здесь мы создаем объект функции и передаем в качестве контекста структуру
МояФункция = Новый Функция("СложитьЗначения", МойОбъект);

//Мы можем выполнить функцию так:
Результат = МояФункция() //Неявно передается первый параметр, указанный в момент создания функции

//А можем добавить этот метод внутрь самой структуры. 
МойОбъект.Вставить("Сложить", МояФункция);

//Таким образом мы имеем возможность наделить структуру своим методом, который имеет контекст этой структуры
Результат = МойОбъект.Сложить(); 

//А так дополнительно передать параметр, который будет помещен в ДополнительныеПараметры
Результат = МойОбъект.Сложить(5); //Число 5 будет передано во второй параметр

Это позволит создавать на основе структур произвольные объекты, обладающие собственными методами.

В БСП в модуле ОбщегоНазначения есть самые популярные во всех типовых конфигурациях методы ЗначениеРеквизитаОбъекта и ЗначенияРеквизитовОбъекта, что подтверждено недавней статистикой.

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

Предлагаю перенести эти функции в платформу как методы ссылки. Сравните вызов:
ОбщегоНазначения.ЗначениеРеквизитаОбъекта(МояСсылка, «МойРеквизит»)
И возможный:
МояСсылка.ЗначениеРеквизита(«МойРеквизит»)

Какие плюсы:

1. Запись намного короче
2. Работает контекстная подсказка
3. Работает подсказка возможных реквизитов
4. Не требуется БСП
5. Реализация на уровне платформы может работать быстрее
6. Возможно сделать доступным на клиенте

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

В идеале еще сделать подсказку по реквизитам в параметре-строке. Подобные подсказки в строках уже есть, например, для методов ОткрытьФорму или ПредопределенноеЗначение.

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

Проблематика:
Допустим, в продуктиве обнаружена ошибка в обработке, передана разработчику.
Разработчик анализирует ошибку, находит проблему, исправляет ее. Тестирует обработку - все ок.
Обновить продуктив прямо сейчас нельзя, но можно установить расширение.
Разработчик идет и создает расширение руками, добавляя туда свои изменения. В зависимости от сложности изменений это может занимать довольно много времени. И потребовать дополнительного полноценного тестирования.

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

Добавить возможность переопределять форму для подсистемы.
На данный момент доступна только скудная настройка пунктов меню.

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

Предлагаем добавить возможность создавать свои виртуальные таблицы, доступные в языке запросов 1С.
Выделить для этого можно новую ветвь в дереве конфигурации. "Виртуальные таблицы".

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

В 1С нет встроенного метода Пауза().
С одной стороны, утверждают, что метод никому не нужен.
С другой же... Про него постоянно спрашивают. Есть несколько несовершенных костыльных попыток решения. В том числе и в типовых конфигурациях.

Не баян, а классика: https://ru.wikipedia.org/wiki/Инкремент

Добавить возможность писать такой код:

МояДлиннаяПеременная++
МояДлиннаяПеременная--

А так же возможность писать вместо этого:

МояДлиннаяПеременная = МояДлиннаяПеременная + ЧужаяДлиннаяПеременная

это:

МояДлиннаяПеременная += ЧужаяДлиннаяПеременная

Аналогично:

МояДлиннаяПеременная -= ЧужаяДлиннаяПеременная
МояДлиннаяПеременная *= ЧужаяДлиннаяПеременная
МояДлиннаяПеременная /= ЧужаяДлиннаяПеременная

Добавить возможность указывать в запросе "ВЫБРАТЬ ПЕРВЫЕ" параметром.

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

Пример текущей обработки текста запроса СКД

Добавить в запросы платформы подчиненную таблицу в иерархических справочниках.

Проблематика: когда встает вопрос в запросе определять вхождения одних элементов в другие, проверять уровни вложенности и находить все элементы иерархии, то приходится либо разбивать запрос на куски (отдельно получая всю иерархию, а потом уже передавать собранную таблицу в основной запрос), либо использовать конструкции типа Родитель.Родитель.<...>.Родитель. При этом, иерархия справочника может быть не ограниченной по уровню вложенности.

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

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

Найти что-нибудь даже в простых динамических списках (основная таблица документа и регистр сведений со статусами документа в пару млн строк) может быть слишком долго + по словам поддержки полнотекстовый поиск искать по вхождению строки не умеет. А при отсутствии результата полнотекстового поиска выполняется поиск по СУБД с очень большими запросами.

Если почитать статьи связанные с тормозами динамических списков - можно увидеть советы:
Использовать другой софт для индексации данных
Делать регистры сведений с сотнями миллионов комбинаций искомых слов
Отключение строки поиска (или ищи по Alt+F)

Как это происходит в других языках:

C#
int[] myArray = {1, 2, 3, 4};

Java
Int[] myArray = {1, 2, 3, 4};

JavaScript
var myArray = [1, 2, 3, 4];

Python
myArray = [1, 2, 3, 4]

Как это происходит в 1С:

МойМассив = Новый Массив;
МойМассив.Добавить(1);
МойМассив.Добавить(2);
МойМассив.Добавить(3);
МойМассив.Добавить(4);

Но можно реализовать и в 1С подобными синтаксисами:
МойМассив = Новый Массив(1, 2, 3, 4);
МойМассив = Новый Массив{1, 2, 3, 4};
МойМассив = Новый Массив[1, 2, 3, 4];
МойМассив = Новый Массив( {1, 2, 3, 4} );

Или даже:
МойМассив = ["раз", "два", "три"];

Подобно можно и для Соответствий и для Структур:

МояПеременная = Новый Соответствие(
   {Ключ1, Значение1},
   {Ключ2, Значение2}
);

или даже:

МояСтруктура = {Имя: "Иван",
                Фамилия: "Иванов",
                Отчество,
                Адрес: {Город: "Москва",
                        Улица: "Большая улица",
                        Дом: "100",
                        Квартира: "200"},
                Телефоны: ["111-11-11", "222-22-22"],
                ДатаРождения: '20000101'};

Или хотя бы уж так
МояПеременная = Новый Соответствие(Ключ, Значение, Ключ, Значение);

На текущий момент возможно лишь создание строковых массивов при помощи СтрРазделить()

И заполненных структур при помощи синтаксиса
МояПеременная = Новый Структура("Ключ1,Ключ2,Ключ3", Значение1, Значение2, Значение3);

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

Синтаксис может придумать разный, но суть ясна.

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

Например, ПередТранзакциейЗаписи() и ПослеТранзакцииЗаписи()

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

Сейчас есть такие обработчики только в события форм объектов. Что не позволяет их использовать полноценно.

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

В качестве примера можно рассмотреть документы ПКО и РКО, которые могут на 50% пересекаться. Было бы логично сделать абстрактный документ КО, от которого унаследовать эти два документа, что уменьшило бы повторение кода, двойную работу.

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

Написанный разработчиком запрос может содержать ошибки. Например:

Содержимое объекта данных может быть выбрано только во временную таблицу...
Не задано значение параметра...
Получение данных из нескольких источников данных недопустимо
Таблица не найдена

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

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

Например:

{(245, 21)}: Не задано значение параметра &НачалоПериода
{(255, 21)}: Не задано значение параметра &КонецПериода
{(300, 55)}: Таблица не найдена МояВТ

Это позволит более комфортно разрабатывать сложные запросы и видеть сразу все существующие проблемы

Весьма распространенный случай - требуется добавить в несколько существующих экранных форм блок имеющих одно и тоже поведение. Яркий пример - отображение контактной информации.

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

Или же внутри каждой формы рисовать одинаковый блок элементов.

Предлагаем добавить возможность размещать другую форму как элемент в текущей.

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

Предлагаем добавить специальный тип элемента "КонтейнерФормы". Его размещать идентично обычных элементов. Контейнер может содержать в себе любую форму (как окно). В свойствах контейнера можно выбирать нужную форму, указывать передаваемые параметры. Если добавить специальные события формы, то получится гибко настроить "общение" между контейнером и отображаемой в ней формой.

Например, создаём на нашей форме контрагента специальную группу с типом "Контейнер формы". И указываем в группе саму форму, которую нужно открыть в этом контейнере, а так же параметры, которые нужно передать. Например, специальную общую форму "КонтактнаяИнформация".

Таким образом можно создать одну универсальную форму и "встраивать" её внутри других форм.

Пожелание которое в принципе не требует доработок платформы.
Открыть форматы cf/cfe/cfu/mxl/epf/erf (cd в части описания работы с хранилищем) или внятно озвучить свою позицию по v8unpack -

1. можно разрабатывать такие инструменты?
2. можно ли официально использовать подобные инструменты в сборочных линиях ?

В платформе 1С нет возможности обновить данные в существующей временной таблице (хотя сама СУБД это позволяет).

Когда же это необходимо, приходится перекладывать данные из одной ВТ в новую. Это влечет за собой дополнительные накладные расходы и усложняет текст запроса, создавая множество "одноразовых" ВТ и в ряде случаев заставляет производить дополнительные манипуляции с пересозданием таблицы.

Возьмем пример из типового ЗУПа 3.х, там очень часто имеет место следующий кейс:

1. Формируем ВТ ВТСведенияОДоходах (именно эта ВТ взята чисто для примера).
2. Данную ВТ нам нужно дополнить данными, и поэтому мы берем из нее все данные, плюс соединяемся с другими таблицами и получаем ВТ ВТВременнаяТаблица.
3. Полученные данные нам нужно вернуть в ВТ ВТСведенияОДоходах, т.к. дальнейшие обработчики ждут ВТ именно с таким именем.
4. Удаляем ВТ ВТСведенияОДоходах.
5. Создаем ВТ ВТСведенияОДоходах, в которую ПРОСТО КОПИРУЕМ данные из ВТВременнаяТаблица.
6. Удаляем ВТ ВременнаяТаблица.

Пример листинга:

ТекстЗапроса =
"ВЫБРАТЬ
| СведенияОДоходах.Период КАК Период,
| СведенияОДоходах.ПериодРегистрации КАК ПериодРегистрации,
| СведенияОДоходах.ВключатьВПервичнуюОтчетностьПФР КАК ВключатьВПервичнуюОтчетностьПФР,
--------------КУЧА ВЫБИРАЕМЫХ ПОЛЕЙ--------------
| ВЫБОР
| КОГДА ПревышениеДохода.ДобавленнаяСтрока
| ТОГДА 0
| ИНАЧЕ СведенияОДоходах.БазаФСС_НС
| КОНЕЦ КАК БазаФСС_НС,
| ВЫБОР
| КОГДА ПревышениеДохода.ДобавленнаяСтрока
| ТОГДА 0
| ИНАЧЕ СведенияОДоходах.БазаФОМС
| КОНЕЦ КАК БазаФОМС,
| СведенияОДоходах.СуммаПревысившаяПределПФР КАК СуммаПревысившаяПределПФР,
| СведенияОДоходах.ДобавленнаяСтрока КАК ДобавленнаяСтрока,
| СведенияОДоходах.СуммаПревысившаяПределФСС КАК СуммаПревысившаяПределФСС,
| ЕСТЬNULL(ПревышениеДохода.СуммаПревысившаяПредел, 0) КАК СуммаПревысившаяПределФОМС
|ПОМЕСТИТЬ ВТВременнаяТаблица
|ИЗ
| ВТСведенияОДоходах КАК СведенияОДоходах
| ЛЕВОЕ СОЕДИНЕНИЕ ВТПревышениеПредельнойВеличиныДоходаФОМС КАК ПревышениеДохода
| ПО СведенияОДоходах.Регистратор = ПревышениеДохода.Регистратор
| И СведенияОДоходах.НомерСтроки = ПревышениеДохода.НомерСтроки
| И СведенияОДоходах.ДобавленнаяСтрока = ПревышениеДохода.ДобавленнаяСтрока
| И (СведенияОДоходах.ДобавленнаяСтрока
| И СведенияОДоходах.ПериодРегистрации = ПревышениеДохода.ПериодРегистрации
| И СведенияОДоходах.Период = ПревышениеДохода.Период
| ИЛИ НЕ СведенияОДоходах.ДобавленнаяСтрока)
|;
|
|////////////////////////////////////////////////////////////////////////////////
|УНИЧТОЖИТЬ ВТСведенияОДоходах
|;
|
|////////////////////////////////////////////////////////////////////////////////
|УНИЧТОЖИТЬ ВТПревышениеПредельнойВеличиныДоходаФОМС
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ВременнаяТаблица.Период КАК Период,
| ВременнаяТаблица.ПериодРегистрации КАК ПериодРегистрации,
| ВременнаяТаблица.ВключатьВПервичнуюОтчетностьПФР КАК ВключатьВПервичнуюОтчетностьПФР,
--------------КУЧА ВЫБИРАЕМЫХ ПОЛЕЙ--------------
| ВременнаяТаблица.БазаФСС_НС КАК БазаФСС_НС,
| ВременнаяТаблица.БазаФОМС КАК БазаФОМС,
| ВременнаяТаблица.СуммаПревысившаяПределПФР КАК СуммаПревысившаяПределПФР,
| ВременнаяТаблица.СуммаПревысившаяПределФСС КАК СуммаПревысившаяПределФСС,
| ВременнаяТаблица.СуммаПревысившаяПределФОМС КАК СуммаПревысившаяПределФОМС,
| ВременнаяТаблица.ДобавленнаяСтрока КАК ДобавленнаяСтрока
|ПОМЕСТИТЬ ВТСведенияОДоходах
|ИЗ
| ВТВременнаяТаблица КАК ВременнаяТаблица
|;
|
|////////////////////////////////////////////////////////////////////////////////
|УНИЧТОЖИТЬ ВТВременнаяТаблица";

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

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

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

Расширить возможности рефлексии в 1С.

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

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

Пример реализации:

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

Если СуществуетМетод(МойОбъект, "Сформировать") Тогда
  МойОбъект.Сформировать();
КонецЕсли;

//Ещё лучше так:
ОписаниеМетода = ОписаниеМетода(МойОбъект, "Сформировать");
Если ОписаниеМетода <> Непределено Тогда
   ОписаниеМетода.Выполнить();
КонецЕсли;

//А так можно проверить наличие свойства объекта. 
//ВладелецСвойства - переменная, теоретически содержащая внешний отчет. 
ЗначениеСвойства = Неопределено;
Если СвойствоОбъекта(ВладелецСвойства, "ИспользуемоеИмяФайла", ЗначениеСвойства) Тогда
  Сообщить(ЗначениеСвойства);
КонецЕсли;

МояПеременная= "Текст";
//Так можно реализовать поведение методов, чтобы они были универсальными
Сообщить(СвойствоОбъекта(МояПеременная, "ИмяСвойства")) //Ложь
Сообщить(СуществуетМетод(МояПеременная, "ИмяМетода")) //Ложь
Сообщить(ОписаниеМетода(МояПеременная, "ИмяМетода")) //Неопределено

Проблематика

1. Нет возможности создавать некластерные индексы, содержащие несколько реквизитов/измерений/ресурсов в заданном порядке. Использование индексирования с доп.упорядочиванием не позволяет явно указывать порядок колонок в индексе и не позволяет создавать несколько индексов с разным порядком полей. В ряде случаев этого достаточно, иногда ситуацию улучшают пересечения индексов. Но иногда для запроса нет подходящего индекса. Особенно часто так происходит с аналитическими или проверочными отчётами, которые используют не типичные для таблицы отборы.

2. Для многих объектов нет возможности влиять на состав кластерного индекса.

3. Нет возможности использовать included columns. Из-за чего усложняется реализация покрывающих индексов для запросов, выбирающих большие объёмы данных.

4. Нет возможности создавать фильтрованные индексы.

5. Некоторые служебные поля вообще не могут быть включены ни в один индекс. Например, «Активность» регистра накопления или «НомерСтроки» табличной части. В результате, при использовании этих полей в запросе, покрывающим может быть только кластерный индекс. При работе с большими выборками, это приводит к сканированию кластерного индекса или ресурсоёмким key lookup.

6. Нет возможности использовать некластерные колоночные индексы или создавать индексируемые представления с кластерными колоночными индексами.

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

При этом эти ограничения воспринимаются как искусственные, т.к. фактически эти манипуляции с индексами можно проделать при работе напрямую с СУБД. Более того:

1. Администрирование базы данных и расследование проблем производительности всё равно требует работать с БД напрямую.

2. Иногда, изменение структуры таблиц БД рассматривается как приемлемое решение на тренинге 1С:Эксперт.

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

Предлагаемое решение

Расширить возможность настройки индексов таблиц.
Вместо существующего подхода, при котором для полей устанавливается режим индексирования, предлагается добавить новую закладку в редактор свойств объекта метаданных.
Свойство «Индексировать» реквизитов/измерений/ресурсов удаляется с панели свойств.

При переходе на новую версию платформы, настройки индексирования объекта не теряются – на их основании создаются новые объекты конфигурации. На скриншоте ниже, индексы «ПоСсылке», «ПоДате», «ПоНомеру» и «ПоПрефиксу» были созданы автоматически при переходе на новую версию платформы. Таким образом, никаких дополнительных действий разработчика конфигурации при переходе не потребуется.

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

Иконки индексов и полей в индексах позволяют быстрее ориентироваться. Например, на скриншоте жёлтым кругом отмечены индексы, соответствующие типовому поведению платформы, а голубым – созданные или измененные разработчиком конфигурации. Стрелка на иконке индекса говорит о том, что он кластерный. У полей – серой чертой отмечены стандартные реквизиты, синей – пользовательские. Такие обозначения приведены для примера, полный перечень подлежит проработке.

Для индекса допустима установка следующих параметров:

• Наименование (Строка (80))
• Тип: Кластерный/Некластерный. + Проверка на то, что кластерный только один.
• Включая колонки. Список. Выбор из всех полей, доступных для использования в полях индекса.

Добавление полей возможно из фиксированного списка, который определяется как:

• Стандартные реквизиты
• Пользовательские реквизиты/измерения/ресурсы
• Общие реквизиты

При изменении объекта метаданных в конфигураторе, который может влиять на индексы таблиц (например, общий реквизит, критерий отбора, свойство «Ведущее» и т.д.), выполнять проверку:

1. Если необходимо изменить существующий индекс, который был изменен пользователем (на скриншоте отмечен голубым кружком), то выводить предупреждение о необходимости скорректировать индекс.
2. В остальных случаях, т.е. если индекса нет или он не был изменен вручную, выводить вопрос с предложением изменить/создать индекс автоматически.

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

В 1С отсутствует возможность получения УИД ссылки в запроса, а так же соединения с ней.
Хотя физически на SQL эта колонка есть и используется при обращении к Ссылке. Осталось только предоставить к ней доступ с языка запросов 1С.

Это облегчит код, в том числе, в интеграционных задачах с http-сервисами и внешними источниками данных.

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

Так же была бы удобна возможность приведения УИД к строке (и наоборот)

ВЫБРАТЬ ВЫРАЗИТЬ(Т.Ссылка.УникальныйИдентификатор КАК СТРОКА)
...
ГДЕ Т.Ссылка.УникальныйИдентификатор В (ВЫБРАТЬ ВТ.УИД ИЗ ВТ)

• Разрешить указывать экспортные процедуры общих модулей из событий элементов и обработчиков команд на форме.

Сейчас принятая практика модификации форм, без использования расширений, выглядит так :
программно описывается и размещается элемент формы, в качестве процедуры обработчика события элемента формы используется процедура из БСП ВыполнитьПереопределяемуюКоманду, она вызывает общий модуль и из него вызывается свой модуль с десятками проверок
Если Форма.Имя = "Имя формы" Тогда
Если Команда.Имя = " имя команды" тогда
и это делает модули плохо читаемыми. Плюс не всегда есть такой универсальный вызов

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

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

В свойствах конфигурации есть свойства "Время засыпания сеанса" и "Время завершения спящего сеанса". Если компьютер пользователя не выключился случайно или находится не в спящем режиме и при этом нет активности пользователя то сеансы не засыпают не завершаются (в консоли кластера время последней активности отличается от текущего максимум на 30 секунд). Я думаю это связано с серверными вызовами обработчиков ожидания, автообновлениями динамических списков.

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

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

Добавить возможность в управляемой форме описывать реквизиты формы типа Структура или ДанныеФормыСтруктура.

Сейчас можно добавить реквизит формы с типом "Произвольный". Сделать его программно структурой и наполнить нужными свойствами. Но нельзя их редактировать в самом редакторе формы. И привязать элементы формы к значениям структуры.

Как сейчас:
Сложные формы содержат разные реквизиты на все случаи жизни.

Минусы:

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

Как будет:

• Можно добавлять реквизиты формы с типом Структура (или ДанныеФормыСтруктура)
• Описывать их свойства в редакторе формы
• Привязывать к свойствам элементы формы
• Использовать в условном оформлении
• "Группировать" реквизиты формы по функционалу в структуры

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

В событиях записи управляемой формы невозможно определить какая именно кнопка была нажата пользователем. "Записать" или "Записать и закрыть".
Что приводит к необходимости отключать стандартные кнопки и реализовывать их самостоятельно.

Что об этом говорит ИТС:

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

Решается эта проблема добавлением соответствующего свойства в ПараметрыЗаписи обработчиков события.

При разработки конфигураций иногда возникает необходимость защитить код конфигурации от изменения. Например, защитить модули лицензирования.

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

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

Предлагается добавить свойство общих модулей "Контекст формы".

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

Добавить возможность разработчику выносить на форму платформенную команду "Открыть значение" (Ctrl+Shift+F4)
А так же сделать её горячую клавишу доступной в полях таблицы формы не только при редактировании.
Ведь открытие значения никак не связано с его изменением. И другие поля (не таблицы) позволяют использовать эту горячую клавишу.

Как сейчас: В таблицах формы пользователь может открыть значение двумя способами:

1. Начать редактировать строку и в поле выбрать пункт меню "Открыть" (вызвать обсуждаемую команду)
   

2. Начать поиск и открыть значение из поля "Что искать" (при помощи той же команды)
   

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

Было бы удобнее (и логичнее) добавить возможность "вынести" стандартную команду в виде кнопки на командной панели таблицы формы. Чтобы платформа открывала значение текущей выделенной ячейки без какого-то вмешательства программиста.

Добавить возможность указывать комментарии в конструкторе запросов.
Язык запросов и так поддерживает комментарии, однако сам конструктор ни в конфигураторе, ни в предприятии не умеет с ними работать и просто затирает.

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

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

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

Добавить возможность выборочно сравнивать НЕ только с хранилищем.
Например, с конфигурацией поставщика. Или с файлом.

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

Пункт меню можно сделать "сравнить выборочно". А далее уже с какой конфигурацией (хранилище, поставщика, файла).

Хотелось бы иметь возможность видеть некоторые экспортные методы только в определенных модулях.

Добавить новый метод объекта Запрос, позволяющий получить текст запроса SQL без отправки на СУБД. Удобно для контроля неявных действий платформы. Например, для контроля левых соединений при обращении через точку, РЛС, условий отбора и соединений по полям составных типов.

1. Позволит при отладке запроса находить конструкции, которые добавляет к тексту запроса платформа, и которые могут приводить к падению производительности.
2. Упростит сопоставление запроса на языке 1С и запроса на языке СУБД.
3. Нет необходимости "отлавливать" запросы, если тебе нужно быстро посмотреть запрос СУБД

На данный момент в платформе нет возможности перехватить момент ПЕРЕД обновлением данных динамического списка, чтобы подкорректировать выполняемые настройки.
Нельзя также отловить все возможные события, которым пользователь изменит настройки компоновки.

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

И это при том, что отключить или переопределить стандартную форму поиска (Ctr+F) невозможно.

Предлагаю добавить в платформу событие ПередПолучениемДанных() у Динамического списка.
С передачей выполняемых СКД и настроек компоновки.
С возможностью их изменения или полного переопределения стандартного обработчика (как ПриКомпоновкиРезультата() в отчете)

Сейчас пакеты запросов передаются последовательно и 1с ожидает исполнения части пакета и потом передает следующий.
При повсеместных рекомендациях разбивать запросы на части это незначительно увеличивает время исполнения при расположении СУБД на одном сервере и более значительно когда СУБД и сервер приложений находятся на разных серверах.
Это должно упросить отладку.

Условное оформление - прекрасный функционал платформы, но, к сожалению, он не завершен.
Работает, но не везде можно регулировать доступностью, видимостью и только просмотром.

Вот описание с ИТС: https://its.1c.eu/db/v836doc#bookmark:dev:TI000000397

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

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

А так же расширить применяемые свойства. Добавить в платформу возможность указывать произвольные значения свойств элементов. Например, регулировать заголовком. Или размером. Или подсказкой. Это позволит настраивать "стиль" формы, используя стандартные свойства элементов форм.