Фирма «1С» опубликовала план развития технологической платформы «1С:Предприятие 8.3.22»

Давно пора!

Расширения развивать не планируют получается, считая, что этого достаточно?

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

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

Это просто надо еще знать подход 1С к сбережению ресурсов сервера (халатное).

ПолучениеФайловИзИнтернетаСлужебный (сервер, внешнее соединение)


И что если не удалят? А если вызывают через 40 вызовов?

генерацию паролей мы и сами давно сделали, а вот новые методы в запросах были бы очень кстати, например нумерация строк в выборке.
В 1С очень нехватает приличных графиков и гистограмм, отдельная боль это графики 1С для финансовых данных, посмотрите как они сделаны в tradingview, Metatrader5, с хорошими градиентами и масштабированием, лучше всех здесь смотрится tradingview.
Очень нехватает компоненты дашбордов типа QlikSense (QlikView), чтобы быстро сформировать и сохранить дашборд с графиками по наборам данных, чтобы это все красиво смотрелось и в мобильной и в десктопной версии.

А когда нам ООП завезут то?

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

А никто не знает, когда в платформу завезут функцию получения уникального идентификатора у объектов метаданных?
Поясню, сейчас имея доступ к Метаданные.Документы.АвансовыйОтчет вы можете грубо говоря узнать только его Имя, но не уникальный идентификатор. Так же дела обстоят и для реквизитов, табличных частей... да всего собственно.

Зачем это было бы нужно спросите вы.

Вы наверное заметили уже, что в КД 3.1 1С пытается прилепить аналог создания правил обмена как в КД 2.1, для типа создания правил обмена, чтобы можно было делать обновление базы данных 1С ERP и вероятно 1С УХ да и прочих просто ТОЛСТЫХ больших баз данных, которые не обновить в один день. И вот 1С придумали такую штуку как обновление через копию, а для этого нужны правила обмена. Вы справедливо заметите, ну так бери выгрузи структур конфигурации в файлы XML (как это делается для EDT) и загрузи в КД 3.1. Я скажу да, все круто, все работает, все почти получалось у меня, НО! Как быть с расширениями конфигурации? КД 3.1 не умеет скрещивать основную конфигурацию и расширения в одно целое. То есть нет монолитной структуры конфигурации. Монолитную структуру конфигурации с расширениями выдаёт старая добрая обработка MD83Exp. Вот только беда, эта обработка хоть и формирует файл структуры конфигурации, где есть некие уникальные идентификаторы, но это на самом деле сгенерированные на лету новые GUID-ы. Обработке неоткуда взять GUID-ы метаданных, платформа не даёт такой возможности.

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

1С же типа сделали в платформе возможность увидеть названия полей и таблиц в SQL, так добавление функции получения GUID-а метаданных микроскопичная вещь, 100% это делается в платформе простым заданием свойства, показывай этот метод всем или нет, и метод уже 100% есть, только недоступен.

Потом, когда он будет, естественно нужно слегка допилить MD83Exp чтобы он её использовал.
Я пытался переделать обработку MD83Exp так чтобы она генерила GUID-ы по хэш сумме полного имени реквизита, но миссия проваливается когда эти самые реквизиты меняют имена с например СтавкаНДС в УдалитьСтавкаНДС, а рядом появляется ещё новая СтавкаНДС. При генерации правил обмена сопостявятся старый реквизит СтавкаНДС и новый реквизит СтавкаНДС, а нужно СтавкаНДС -> УдалитьСтавкаНДС.

По сути можно и КД 2.1 чутка допилить добавив у метаданных поле GUID для создания правил обмена с сопоставление объектов по GUID, а не именам. Вот только незадача, придётся на самом деле много перепилить, так как тот же автоматический алгоритм создания правил обмена между Источником и Приемником тупо падает на ошибке переполнения стека (база ERP приёмник и источник), что как бы намекает, что нужно переписывать его чтобы он меньше рекурсивных вызовов использовал или вообще без них работал.
Сдаётся, что КД 2.1 уже похоронен фирмой 1С, а КД 3.1 будет развивать и дальше.

Даже, если 1С научит КД 3.1 отдельно загружать ещё и расширения конфигураций, а потом скрещивать их с основной конфигурацией, то это все равно потребует дофига ресурсов от самой 1С чтобы эти загрузчики и скрещивалки сделать, а потом ещё и нас заставит постоянно выгружать XML файлики по каждому расширению, вместо того чтобы как раньше запустить MD83Exp и подождав пару тройку минут получить один XML и скормить его КД 3.1.

Я считаю, что все перечисленное из сделанного и запланованного = мусор.
1Сники просто копают себе яму повышением порога входа.

(20) Не могу согласиться с прям ультимативным высказыванием, что всё равно мусор.
А вот с тем, что порог вхождения все круче становится это да.

Я бы хотел, чтобы в платформу 1С:Предприятие добавили большую языковую модель типа ChatGPT и аналог com-технологии, который бы позволял платформе 1С:Предприятие подключаться к другим информационным базам 1С (к которым нет доступа через конфигуратор) и считывать/записывать информацию у файлов электронных таблиц и текстовых процессоров. Этот аналог com-технологии актуален ввиду того, что в российских операционных системах com-технологии не используются, а государственные корпорации, государственные компании, публично-правовые компании, субъекты естественных монополий, организации, осуществляющие регулируемые виды деятельности в сфере электроснабжения, газоснабжения, теплоснабжения, водоснабжения, водоотведения, очистки сточных вод, обращения с твердыми коммунальными отходами, автономные учреждения, а также хозяйственные общества, в уставном капитале которых доля участия Российской Федерации, субъекта Российской Федерации, муниципального образования в совокупности превышает пятьдесят процентов должны будут с 1 января 2025 г. использовать программное обеспечение на принадлежащих им значимых объектах критической информационной инфраструктуры из единого реестра российских программ для ЭВМ и БД.