Вышла версия 8.3.11 «1С:Предприятия»

(1) о модульных решениях начали говорить со времени появления БСП и подсистем на УФ

(1)На мой взгляд идея правильная - но реализация тупиковая - вот как раз для того, о чём Вы говорите нужно совсем иной подход к реализации это идеи - "расширения" конфигурации.

(1) Оно будет Оркестратором, а расширения превратятся в микросервисы :))). И тогда мы доживём до архитектуры решений, которая сейчас является уже практически стандартом дефакто в большинстве крупных проектов :). Я думаю что к тому времени я уже всё-таки умру от старости :)

(2) Мы еще на 8.3.6 УТ 11.1 переделали так. Че там. Доп регистры и документы и так не затрутся, проведение, если в типовых доках участвовало, то в подписки (правда год на это ушел). Нет такого костыля, который бы нельзя было прикрутить "сбоку" изначально, чтобы обновляться ровно.

(2)
Я бы не стал переоценивать расширения - оно ведь может и отвалиться. Куда в таком случае денутся данные добавленные реквизитами расширения?
Так что, всё что касается данных и бизнес логики - это объекты конфигурации, подписки на события и т.п. механизмы. А вот всякие бантики, такие как изменения форм интерфейса, печатные формы, отчёты и обработки - расширения. Даже если отвалится, то ни на сохранность данных, ни на бизнес логику не повлияет.

(2) в типовой БП3 при захвате в расширение формы дока пропадает структура подчиненности - 1с зафиксировала как ошибку... еще есть желание ?

как говорится, идея хорошая, реализация хромает)

(5)
очень жаль, на проектах erp думаю без них нет смысла использовать расширения, да и нет поддержки работы хранилища с расширениями

(8) Мне кажется, что у фирмы 1с нет цели исправить ошибки платформы. Они стремятся только добавлять новый функционал, который увеличивает список ошибок.

(12)Как говорится продаем, не то, что хотят купить пользователи , а то, что хотим втюхать пользователям сами))

(14)
зачем вам восстанавливать тестовые базы хирургическим путем? подняли из .bak - и тестируйте дальше

(17) третий абзац

(17)
статья по истории данных
https://infostart.ru/public/699109/
;-)))

(22) А можно ссылку? Это трэш, мне кажется ты ошибся - до такого маразма не могли дойти.

(32)в 8.3.10 еще

(34) БСП старая. Хотя и новая не умеет этого ещё. Там в зазеркалье писали нюансы по ролям. Мы пока без ролей действуем, очень пока проблемная штука.
Чтоб на это не ругалось - пришлось вручную идентификаторы добавить, но вот если в пользователях в ролях добавить эти роли - то при записи идёт ошибка.

(44)Можно. Только есть один момент - из внешних обработок не получится. Из консоли запросов можно, только сначала запрос надо в ней написать, а потом в обработку вставлять. Если в конфигурации вызвать конструктор запроса - все будет норм.

(49) этого не будет ИМХО как заявила сама фирма 1с - это "фирменный стиль" ...

(51) Расширения это тренд. Ждём "1С-Маркет" на инфостарте...

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

Согласен с тем, что контроллируемое обновление изменённых даже управляемых форм пока ещё на зачаточном уровне - по-прежнему приветствуется программное добавление (и тем более изменение) элементов форм, а так же текстовые пометки в модуле формы - к изменениям, сделанным в самой форме. Так что тут есть над чем ещё поработать (как раз для УФ это вполне реально было бы сделать).
Да и очень бы хотелось поддержки идеологии интегрируемых в формы фреймов - чтобы функционал можно было бы размещать на одной вспомогательной форме - и затем вставлять его в интерфейсные группы других форм - как фрейм (естественно с переносом обработчиков из исходной формы, с возможностью их переопределять в приёмнике - по необходимости). Упростило бы и доработки типовых форм - и размещение одинаковых наборов интерфейсных объектов в разных формах.

По поводу процедурного объединения - так ведь давно уже есть! При сравнении/объединении нажимаете у модуля (в т.ч. модуля формы) на шестирёнку - справа в строке - и настраиваете процедуры по отдельности - что и как объединять - даже в окне (внизу) результата объединения можно тут же внести свои правки - в тех случаях, где есть в одной процедуре пересечения "интересов" (изменений) - это достаточно удобно - жаль нельзя каждое изменение так настраивать (что оставить, что перенести и заменить) - но ручное редактирвоание результаат "не отходя от кассы" всё же это упрощает.

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

Лишний паралельный конфиг при работе с расширениями - это не так плохо - тут дело привычки - можно считать, что это примитивный глобальный ООП (на всю конфигурацию) - с наследованием и полиморфмизмом, и теперь ещё с инкапсуляцией. Грубое, конечно, сравнение, но всё же. Другое дело, что расширения не поддерживают хранилище - вот это беда - действительно усложняющая групповую разработку. Зато теперь, одно-несколько расширений можно ставить сразу на ряд конфигураций - разрабатывая их лишь в одном месте - можно выстраивать целый зоопарк из этих расширений, чтобы, к примеру, обеспечить разные наборы функционала в разных информационных базах - хотя я не сторонник такого подхода внутри одной корпорации - лучше делать одну единую доработку - а для разных организаций регулировать функционал настройками.