Версия 2.5.7.226 типовой конфигурации "Комплексная автоматизация" содержит очень много изменений. Если вы ещё не переходили на неё и у вас большая база - имеет смысл подождать.

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

При предварительном тестировании выявлена следующая ошибка - один из постобработчиков вызывал исключение с описанием:

> Ошибка выполнения обработчика обновления Документы.СверкаВзаиморасчетов.ОбработатьДанныеДляПереходаНаНовуюВерсию:
> Открытая внутри обработчика обновления транзакция осталась активной (не была закрыта или отменена).

Для правки лучше сразу создать расширение и в него добавлять исправления. Указанная ошибка исправляется добавлением в модуль менеджера документа "Сверка взаиморасчётов" в процедуру "ОбработатьДанныеДляПереходаНаНовуюВерсию" между строкой 6865 и 6866 текста: "ЗафиксироватьТранзакцию();"

``` 1c
// . . .
Если Не ГотовКЗаполнению Тогда
    ЗафиксироватьТранзакцию(); // <-- добавить это
    Продолжить;
КонецЕсли;
// . . .
```

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

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

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

2.
С мест сообщают: Прошу решить этот вопрос, т. к. управленческий учет не виден. Все данные пропали по конец 3 кв. 2021 (расчеты видны только с 01.10.2021).
Мой комментарий: Возможно постобработка коснулась только документов открытого периода. Пока неясно как исправлять.

3.
С мест сообщают: Тормозит 1С. Вал обращений про взаимоблокировки.
Мой комментарий: На самом деле происходит зависание процедуры расчёта графика платежей при проведении документа. Процедура держит транзакцию, отсюда блокировки. Находится это в общем модуле "ОперативныеВзаиморасчетыСервер", процедура "ЗаполнитьОперативныеВзаиморасчеты". Зависает она в цикле (стр. 281):

Пока Индексы.ИндексОплаты + Индексы.ИндексОтгрузкиПоставки < ЗаписейОбработать Цикл

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

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

(9) Нет. Тест был, я об этом написал. Имитации работы системы со всеми пользователями ни у кого нет. Поэтому то, что можно было вскрыть на тестировании - вскрылось на тестировании, я об этом написал.

(11) Я тестировал сколько смог - я же написал выше, что даже выявил одну ошибку. Вы видите, что характер проблем такой, что при тестировании на местах его не выявить? У меня нет автотестов по новым, и даже по старым сценариям использования типовой конфигурации. Я рассчитываю на то, что они есть у производителя.

(14) "в первой строке начального поста:"содержит очень много изменений.". Смелый ТС"

А какая альтернатива? Ждать, пока не понадобится что-то срочно для подсистемы ЗУП? И потом всё равно ставить новое обновление, но уже в режиме ещё большей нехватки времени? Или когда лучше это делать? Может быть перед сдачей года посоветуете?

(20) У меня был повод залезть в конфигураторе не по всем подсистемам вообще, но по конкретным отдельным вопросам.

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

(21) Относительно подсистемы ЗУП я думаю об этом и готовлю плацдармы :-) Начиная с возможностей установки ЗУП в чистом виде. Но имхается, что если сейчас 2.4 соответствует 3.1.18, обновления на 2.4 будут продолжаться в части ЗУП как минимум год (пока 3.1.18 актуальная в виде стабильной версии)

(6) Ставка НДС - это теперь другая сущность. Например, если раньше, чтобы получить ставку 20%, нужно было обратиться к соответствующему перечислению, то теперь нужно получать так:
```
СтавкаНДС20 = УчетНДСЛокализация.СтавкаНДСПоПеречислению(ПредопределенноеЗначение("Перечисление.СтавкиНДС.НДС20"));
```

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

(23) И что получается в СтавкаНДС20 ? Какой тип?

(20)[А какая альтернатива?] закрыть год на 2.4 и переходить на 2.5 с II квартала 2022 года

(24) Это теперь справочник

В оплатах (ПКО, РКО, Оплата картой) сумма НДС теперь равна ноль, независимо от ставки. Если переввести сумму документа, то значение суммы НДС возвращается.

(25) Возможно автора ветки под дулом пистолета заставили обновиться сейчас.

с утра обновили рабочую базу и компания перешла в аварийный режим работы
и зачем так жЫть ?

(28) судя по уровню истерики - решение ТС принял сам и горд этим

(28) (29) Слушайте, откуда я мог знать, что релиз нерабочий? Я в тот день обновлял все типовые конфигурации (да, она не одна). Сначала на тесте, потом на бою. База увидела новый релиз - установила. Я что смог на тесте проверил и поставил в рабочую. Я не считаю, что должен был действовать по-другому (если думаете иначе - пожалуйста объясните свою точку зрения). Как только пользователи вошли, откатиться назад стало большой проблемой. Вот и всё.

"База увидела новый релиз - установила"
А такое надо пресекать в корне. Сразу отключать автоматические обновления.

(31) Релиз КА 2.5.7 испекли только "вчера", и ты сразу выкатываешь его на бой
А зачем полез в нехорошее ? В чем причина торопливости ?

(33) Почему нехорошее? Это правило какое-то? Оно только к КА относится или к любой конфигурации? Почему я, как конечный потребитель продукта, должен вообще об этом думать?

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

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

И опыт - сын ошибок трудных
И гений - парадоксов друг
(с) А.С. Пушкин

(35)+ или мыши которые захотели стать ежиками
https://lurkmore.to/Мыши_плакали,_кололись%E2%80%A6

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

Одно дело чистая бухня - ее приходится держать актуальную последним/предпоследним релизом, сдача отчетности, особенно электронной, все дела
Если выпустили кривой релиз 1с'ники то достаточно безболезненно переносится восстановление базы из бекапа и простой отдела в полдня

Другое дело остальные базы типа КА или УТ или ЕРП какое-нить - стоит производство, склад, доставка и т.п.
Фирмешка в коматозе

А всего то "потребитель" обновился

Бекап то хоть сделал перед обновлением ?
Сделал ?
Пиздуй к руководству, останавливайте учетную систему, поднимайте бекап
Смиритесь с потерей времени, забьют потом данные юзера

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

(38) в ка и ерп тоже есть рег учет

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

(40) В том то и дело

(34) Если откинуть правила и рекомендации 1С и сообщества, то можно ответить достаточно просто: "Здравый смысл". Так вот...Здравый смысл подсказывает, что не всегда на заборе написано то, что за ним. Не хочешь думать и принимать рекомендации-запасайся вазелином.

(42) а вы с 2.4 переходили или с 2.5.6?

(44) (17) - см. 17

(40) Кусками обновляться, или тянуть до последнего
Учетная система "все в одном" требует команды поддержки; а не одинокого самурая-потребителя;
да и хороша ровно до того момента пока ничего не меняется в пределах отчетного периода

проще с синхронизаией жахаться в зоопарке конф

(45) если с 2.4 то ваша вина.

(45) нужно понимать, что переход между релизами это не простое обновление

(46) Нет. В зоопарке там тоже команда нужна свой на каждую конфу и еще на каждый обмен еще один.
Если это не уровень ларька где подождет и объемов нету.

(49) Не соглашусь.
Бухню выносом в БП - она наиболее часто обновляемая, и наименее болезненно реагирует к косякам релиза
Склад и продажников пихаем в УГ - работает годами не обновляясь; пока "маркировку" не введут какую-нибудь
Производство в КА - его вообще один раз настроил и забыл

Остается рулить обменами, при изменении какого - то из блоков

(50) Интенсивность обновлений ЗУПа сопоставима

(47) Надеюсь только, что это не мнение сотрудника 1С

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

(50) >Склад и продажников пихаем в УГ

УГ = Унылое Г ?

(50) >Остается рулить обменами, при изменении какого - то из блоков

Вы в курсе что это называется микросервисная архитектура?
Только обмен извратный вместо http-сервисов между ними или шины/брокера

(54) Ога
(55) В курсе.
Почему извратный ? XML типовой не используем. Строим обмен на сервисах, двухкомпонентный - расширение конфиы отдающее данные и обработки считывающей их и загружающей.
Например, обработка из БП дергает сервис в УГ, сервис отдает данные
Реализовано с индикациями, интерактивностью для бухгалтера, видами документов и и прочими свистоперделками ...

https://ibb.co/sJH7KYd
На картинке не видно но в окне щелкают счетчики загрузки документов

(56) Понимаем что на поддержку этого нужна да команда?
А вот с единой ERP/КА можно в пару справиться

(31) У 1С все свежевыкаченные релизы - нерабочие. Примите это, не торопитесь с обновлениями, иначе постоянно будете попадать в состояние в (0). Отключайте автообновления и проверяйте, когда ветка стала стабильной, или просто обновляйтесь через полгода после первого релиза (если лень мониторить). Иначе всегда будете бетатестером.

(57) Клиент - группа фирмешек, 6 юрлиц, 4 базы БП последнего релиза, 3 буха; один в офисе двое по домам сидят
Обмен функционирует с июля 20, переделывался один раз - в БП сменили перечисление в договоре
УГ версии 11.4.5
Вся поддержка - дать пинка одмину, когда vpn отваливается у домоседов

О какой команде поддержке идет речь ?

(59) Ну например когда в УГ задним числом навертят уже после того как в БП ушло кто с этим разбирается и как?

(60)+ А ЭДО есть? в УГ или в БП?

(60) Механизм то же что и в единой базе - запреты редактирования, изменения данных задним числом по согласованию
Бух просто перевыгружает один документ, тыкая галочку и перезакрывает периоды если на границе периода изменения
В УТ маркировка, в БП ЭДО работает.

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

(62) А если контрагент получив по ЭДО документ его не подписывает? Или с разногласиями?
Каким образом обратно из БП в УТ? И как данные обратно из БП в УТ, ну например клиент-банка где?

И где можно полные отчеты получить например какой менагер сколько реально по оплатам?

(63) ЭДО, разногласия, наличие/отсутствие документов первичных - работа бухгалтерии
на склад производство и продажи это не влияет - товар/материал пришел - таскаем внутри склада, производим и продаем
банк, наличность - оператор в УГ разносит с данных БП
отчеты по товару/манагерам/продажам в УГ

(62) те до сих пор нет никакой автоматизации сверки?

(65) Ога. Предлагал - не хотят платить, думают что "экономят" )))
клюнюла нужда одного - сделаю, остальным впихну за половину стоимости )))

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

выгрузилось - не выгрузилось, да пох. мы нажали кнопку, остальное не важно

(67) Это в типовом XML не понятно что выгрузилось, что нет - период, организация и все.
Действительно - батон продавили и пох что там происходит
У меня бух видит даты, суммы, тут же сравнить может не залезая в другую систему

(19) >> Тест был.

Не было никакого толкового теста.
То что вы называете тестом - полная фигня. И практика это показала.
Как уже отметили, нельзя обновлять мажорные релизы без всестороннего тестирования.

>> Имитации работы системы со всеми пользователями ни у кого нет.

Всё никто и не тестирует. Но критический функционал должен тестироваться. В том числе с привлечением пользователей. Как правило, достаточно протестировать ~20% функционала, который на среднестатистическом предприятии покрывает до 80% потребностей всего учёта.

Накатывать на продуктив конфигурации типа ERP, КА или УТ без какого-либо внятного тестирования - попахивает маразмом и идиотизмом. Даже если эти конфигурации абсолютно девственно типовые.
иногда даже минорные обновления типовых конфигураций нельзя ставить без проверок.
Все остальные твои высказывания - чистой воды детский сад.
Если тебя не уволят после случившегося, то через несколько лет ты сам будешь рассказывать сегодняшнюю историю, как какой-то анекдот.

Поэтому то, что можно было вскрыть на тестировании - вскрылось на тестировании, я об этом написал.
   1div0
20 - 09.11.21 - 13:41
(11) Я тестировал сколько смог - я же написал выше, что даже выявил одну ошибку. Вы видите, что характер проблем такой, что при тестировании на местах его не выявить? У меня нет автотестов по новым, и даже по старым сценариям использования типовой конфигурации. Я рассчитываю на то, что они есть у производителя.

(70) Это только ваше мнение, потому что вы привыкли к такому порядку вещей. Расскажите, уважаемый, раз вы всё знаете, как проводить толковый тест и почему я должен проверять это всё за производителем?

(71) Когда долго ешь кактус, то входишь во вкус. 1С нас все поломала.

(71) Не к тому, чтобы кого-то защищать, но к тому, что ситуация получилась кривая несколько для Поставщика 1С.

Вот смотрим, что там написано на странице релизов. Вот тут https://releases.1c.ru/project/ARAutomation20
Текст копировать не буду, но вроде бы из него очевидно, что операция перехода с 2.4 на 2.5 достаточно ответственная и это именно _переход_, а не очередное _обновление_.

Однако, в строке таблицы указано вот так : 2.5.7.226    29.10.21        2.5.5.104, 2.5.6.291, 2.5.7.211, 2.4.13.281
И это показывает реализованную возможность запуска именно обновлением, а не получением отдельной и сложной процедуры перехода.
Т.е. допустим есть похожая ситуация в конфигурации БП 2 и БП 3, что там переход осуществим через запуск обновления, но не совсем простого, а специально разработанного.
Зачем? Вероятно, чтоб не было ошибки или случайного запуска процесса.

Вот как записано тоже самой в БП3 : 3.0.105.14    01.11.21        3.0.101.19, 3.0.102.11, 3.0.103.12, 3.0.103.20, 3.0.103.21, 3.0.104.25, 2.0.67.12, 3.0.104.28
Видно, что релиз 2.0.67.12 есть в этом перечне, но это не _обновление_, а _переход_
Там внутри страницы релиза это есть - копирю строчки названий ссылок на дистрибутивы
Дистрибутив обновления
Дистрибутив обновления для перехода с базовой версии для 1
Дистрибутив обновления для перехода с базовой версии
Дистрибутив обновления для перехода с редакции 2.0

Почему же в случае с конфигурациями КА2.4 и КА2.5 не сделали такого способа? Не очень понятно.

Можно предположить, что это недоразумение исправят. Ну а кто успел заскочить не глядя...? Значит влетел.

(71) а Вы похоже не привыкли к такому порядку вещей и считаете, что не должны проверять за 1С качество свежих релизов, вот и получили (0).

(71) >> Это только ваше мнение.

Безусловно.

>> ..., потому что вы привыкли к такому порядку вещей.

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

Да, 1С тестирует конфигурацию в целом и отдельные подсистемы. На каких-то демонстрационных примерах. Протестировать абсолютно всё невозможно физически. Если бы это было возможно, то не было бы никогда ошибок.

>> ...раз вы всё знаете.

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

>> ... как проводить толковый тест и почему я должен проверять это всё за производителем?

Способов тестирования множество. И на каждом предприятии он свой. Конкретные советы тут дать сложно. Кто-то ограничивается перепроведением и перезакрытием какого-нибудь одного периода в тестовой базе с проверкой результатов при помощи каких-то контрольных отчетов. А кто-то прогоняет целый комплекс собственных тестов, подготовленных в каком-нибудь стенде типа 1С:Сценарное тестирование. Подготовка самих таких тестов - огромный труд и тесты эти индивидуальны и уникальны для каждой базы данных. В любом случае к тестированию привлекаются ключевые пользователи. Которые должны открыть тестовую обновленную базу, проверить свои данные, убедиться, что всё нормально (или есть ошибки) и дать обратную связь (желательно, подписав соответствующий протокол тестирования). Глубина тестирования определяется исходя из сложности обновления (в данном случае обновление с 2.4 на 2.5 - очень сложное), количества изменений в обновлении, затрагивают ли изменения задействованные на предприятии контуры и подсистемы учета и в какой степени, возможных рисков в случае если что-то пойдёт не так и придётся откатываться (одно предприятие может себе позволить встать на полдня-день, а для другого это будет равнозначно огромным финансовым потерям). Ну и разумеется с учетом наличия свободных ресурсов для тестирования.
Тестироваться должен в первую очередь оперативный контур и критические бизнес-процессы, сбой которых при продуктивной эксплуатации может вызвать серьёзные проблемы типа (0).
Тестирование, например, регламентированного бух и налогового учета может вообще не проводится или проводится по какой-то упрощенной схеме. Т.к. исправление ошибок в таких подсистемах может как правило подождать и их сбой не вызовет коллапса (при условии конечно, что обновление не ставится в день сдачи отчётности).

>> почему я должен проверять это всё за производителем?

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

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

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

PPPS И да. Совсем забыл. Ни в коем разе не пытаюсь оправдывать или защищать 1С. Если у кого-то вдруг сложилось такое впечатление.
Качество типовых конфигураций и обновлений, мягко говоря, оставляет желать лучшего. Как и качество предварительного и предрелизного тестирования.
Но справедливости ради нельзя не отметить, что всякие там SAP'ы с их бест практикс (прости, Господи) не многим лучше.

(75) >Разработчик не может протестировать подобного уровня сложности конфигурацию при всех возможных комбинациях исходных данных.

А как он пилить конфу то умудряется тогда?
Тестирование это на порядки проще чем пилить. Есть куча автоматизаций для этого. И тестеры стоят сильно дешевле прогов.

(75)[Но справедливости ради нельзя не отметить, что всякие там SAP'ы с их бест практикс (прости, Господи) не многим лучше]
+100500

(75) >всякие там SAP'ы с их бест практикс (прости, Господи) не многим лучше.

Это не так.
Точнее в сапах и других подобных там "эталонное" (синоним типовое) решение обычно все супер.
Проблема что любое внедрение там кастомизация и тут начинаются траблы.

(78)+ Точнее если решения уровня 1С а не нечто мелкое тяп ляп

(78) не а
релизы точно так же не тестируются на 100%
аварийные патчи выходят не сразу
и реакция поддержки исчисляется неделями

(78) Про эталонное решение от SAP не берусь судить. Не сталкивался.
С теми допиленными решениями, которые приходилось видеть, любые обновления и патчи ставились исключительно только через предварительное тестирование.

(78) >> "эталонное" (синоним типовое) решение обычно все супер.

Ну так и демка от 1С тоже будет супер.
Как правило, до 90% проблем и ошибок на демонстрационной базе не воспроизводится. Чтобы их (ошибки) смоделировать приходится множество настроек выполнить, учетную политику подкрутить, исходные данные в нужном виде завести и сам бизнес-процесс смоделировать от начала до конца.

(76) >> Тестирование это на порядки проще чем пилить. Есть куча автоматизаций для этого. И тестеры стоят сильно дешевле прогов.

Это всё так.
Проблема, как мне кажется, в том, чтобы протестировать на всех возможных вариантах исходных данных со всеми возможными вариантами настроек параметров, опций и НСИ.
По сути 1С отдаёт это на откуп центрам внедрения. Перекладывая на их плечи ответственность и принятие решений об обновлениях.
Практика, наверное, не самая лучшая. Но и SAP никто не внедряет своими силами.

(83) Да не в этом проблема.
Проблема что у 1С слишком много разных конф!
Слишком много в них разных проблем!
И они погрязли в багах.

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

(84)+ Например УНФ бесполезная конфа выкинуть и заменить КА лайт
Например БП2 выкинуть и тем более выкинуть версии КОРП, весь функционал в ПРОФ
И еще куча как можно сократить затраты на разработку и поддержку!

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

(85) А вот с этим в корне не согласен.
Чем наличие двух конфигураций КА и КА Лайт будет лучше разделения БП на ПРОФ и КОРП (от которого ты предлагаешь отказаться)? В чем принципиальная разница?
КА - это уже лайт версия ERP.
Выкинуть БП2 - наверное соглашусь. Почему 1С этого не сделала до сих пор не совсем понятно. Предварительно анонсировалась поддержка БП2 только до конца 2014 или 2015 года.

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

(86) КА лайт это замена УНФ
Выкинуть КОРП это значит не надо отдельно от ПРОФ извращаться
Типа есть БП Базовая, ПРОФ и КОРП
Есть Документооборот ПРОФ и КОРП и т.д. убрать нахрен

И Базовые тоже убрать и файловые нахрен убрать сделать так что даже базовая это КОРП на сервере 1С на PostgreSQL с добавленными ограничениями на одно юрлицо
Не вижу смысла поддерживать отдельную кодовую базу

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

(87) так базовые и так есть проф + ограничения в коде. а именно выключенные фо на уровне кода

(87) что нужно вырезать в КА, чтобы она стала лайт?

(89) Ограничить функционал до возможностей УНФ, тут конечно вопрос в бухучетом УНФ его не умеет и требует отдельной БП

(87) В БП КОРП Над КОРП отдельно от ПРОФ не извращаются. Делается просто КОРП. Затем отключается функциональность,
но не только через ФО, а по коду модулей тоже в некоторых местах и получается ПРОФ.
Затем еще раз обрезается функциональ и ПРОФ скатывается в Базовую.

т.е. отдельной кодовой базы для БП базовой нет.

и в ЗУП тоже так

(87) >> Выкинуть КОРП это значит не надо отдельно от ПРОФ извращаться.

Так никто и не извращается отдельно.
Пилится только одна конфигурация - БП КОРП. Уже на уровне кода заложена возможность отсутствия части объектов или подсистем. Из неё только удаляют часть функционала (объектов и подсистем), получая таким образом версии ПРОФ и базовую. Аналогично с ЗУП - КОРП, ПРОФ и базовая.
Тот же подход при разработке ERP. Из которой делаются ERP, КА и УТ.

И это лучше, чем отдельная разработка каждой из конфигураций.

ИМХО (субъективное впечатление), ошибок, причинами которых был бы используемый сейчас подход, не так уж и много. И не в нём основная причина низкого качества выпускаемых релизов.

(91) (94) Вы и правы и нет.
Фактически чтобы обрезанное работало приходится местами держать отдельную кодовую базу.
Да не много но есть и это затраты.

(95) До сих пор нет версии УТ11.5!
ERP 2.5 первой вышла, КА 2.5 недавно, УТ11.5 на базе ERP 2.5 до сих пор нетути
Сложно обрезать? Да!

(94) // Тот же подход при разработке ERP. Из которой делаются ERP, КА и УТ.

Про ERP были признания разработчиков, что этот подход планировался, но практике его не смогли осуществить. Т.е. все-таки УТ БП и ЗУП пилятся вне того, что там происходить в ERP

(97) ЗУП потом стабильную впиливают в ERP/КА

Теоретически надо разбивать "на микросервисы"
С интерфейсами стандартизированными между ними
И пусть будет одна конфа но состоящая из разных модулей и пусть будет дублирование данных
С онлайн изменениями на лету внутри по некой внутренней шине

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

Но проблемы будет решать легче!
Потому что не единый монструозный монолит а небольшие модули и стандартизированные интерфейсы

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

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

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

Это как обмен между УТ и БП например

(96) Возможно УТ11.5 не вышла не потому что её долго вырезать из ERP2.5, а потому что сначала исправят найденные ошибки, а потом уже и выпустят более распространённую конфигурацию.

Как можно из ERP вырезать УТ 11.5, если ее там просто нет?!

А не. Прикольно
УправлениеТорговлей                      11.5.7.226

БиблиотекаИнтеграцииВЕТИС                10.1.13.4
БиблиотекаИнтеграцииГосИС                1.1.13.4
БиблиотекаИнтеграцииЕГАИС                10.1.13.4
БиблиотекаИнтеграцииИСМП                 10.1.13.4
БиблиотекаИнтеграцииС1СДокументооборотом 1.1.18.5
БиблиотекаПодключаемогоОборудования      2.1.6.15
БиблиотекаСистемыМаркировки              10.1.13.4
БиблиотекаТехнологииСервиса              2.0.4.61
БиблиотекаЭлектронныхДокументов          1.9.2.39
ЗарплатаКадрыБазовая                     3.1.18.217
ЗарплатаКадрыРасширенная                 3.1.18.217
ИнтернетПоддержкаПользователей           2.5.2.13
КомплекснаяАвтоматизация                 2.5.7.226
Локализация                              2.5.7.202
РегламентированнаяОтчетность             1.2.1.100
РегламентированныйУчет                   1.1.1.6
СтандартныеПодсистемы                    3.1.5.208
УправлениеПредприятием                   2.5.7.226
УправлениеТорговлей                      11.5.7.226

А на релизах отдельная самая последняя опубликованная тестовая - УправлениеТорговлей                      11.5.7.203

С такой проблемой Зарелизили Комплексная автоматизация 2.5 сюда кто-то обращался?

Вы посмотрели остросюжетный триллер со счастливым концом - я откатил релиз. Новые данные не пострадали.

Вышедший патч видел - там мало ещё исправлений, нужных нет.
Всем спасибо за участие, переживания и наставления )

А по 1С.. есть такая вещь, как покрытие кода тестами. Да, можно не на 100% покрывать, хотя бы на часть. Вот создал ты новую сущность - напиши сценарии её использования. Если с тестами всё ок, то с ростом продукта растёт количество тестовых сценариев. Выше писали, что писать тесты легко - на мой взгляд это не так. Писать тесты должен тот же разработчик, что и писал новую сущность или функционал. Это занимает столько же времени, что и написание нового функционала. Если пишешь тиражное решение - экономить на этом нельзя. По платформе претензий нет. А вот по конфигурациям - ощущение, что тестов или совсем нет, или нет в достаточном количестве.

P.S.:
1. Кому интересно, новых и изменённых документов в новом релизе образовалось более 60 тыс. за эти дни. За вычетом изменённых в результате перехода на новый релиз. Ситуация по откату облегчалась вовремя закрытым 3м кварталом.

2. (46) Про самурая идея понравилась - нашёл и теперь слушаю Free Flow Flava (Dope Ninjaz, Smoke, ...).

Если под словами "написание нового функционала" понимается процесс _Перехода_ - значит сейчас можно точно сказать, что тестирования _Перехода_ оказалось недостаточно.

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

(108) Как это нет претензий по платформе? А протухающий кэш? Демоническое обновление? Забивание на обычные формы (конфигурации на них есть, за УПП отдельные деньги берут, но переход на последние платформы требует особых проверок)? А внедрение каких-то доработок в 19 платформу ломало конфигуратор - TormozIT не даст соврать? Ну и до кучи регулярное падение производительности от версии к версии?

(109) 60к документов это слабенько) 2млн знаю у ребят)

(108) >> писать тесты легко - на мой взгляд это не так.

Не знаю кто сказал, что писать тесты легко.
Написание тестов - целое искусство.

>> Писать тесты должен тот же разработчик, что и писал новую сущность или функционал.

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

>> Это занимает столько же времени, что и написание нового функционала.

Иногда и больше. Если ради теста требуется смоделировать всю цепочку бизнес-процесса со всеми необходимыми данными.

>> ощущение, что тестов или совсем нет, или нет в достаточном количестве.

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

(112) >> 60к документов это слабенько) 2млн знаю у ребят).

Я так понимаю, что автор говорит только о тех документах, которые успели внести или изменить за несколько дней с момента обновления на 2.5 до момента отката к 2.4.
60 тыс. документов за пару дней - это, ИМХО, довольно много.

(108) иди в комики, в 1С от тебя пользы нет и не будет

(115) Вы похоже таблетки забыли принять

Обнаружилась проблемка по Налогообложение НДС, проявилась она раньше, где-то с апреля 2019, но заметил только сейчас с переходом на 2.5.
У нас автосервис, патент на выполнение авторабот (услуги без НДС, кроме стоянки авто). А заменяемые запчасти с НДС. Работаем в Альфа-Авто, но все документы перекидываем в КА1/УПП для получения отчетности (и ЗП считаем). Еще из КА1/УПП документы транзитом перекидываю в КА2.4/ERP (пока в ней не работаем, отладка). В правилах обмена в документах где есть Налогообложение НДС прописал: Объект.НалогообложениеНДС = Справочники.Организации.НалогообложениеНДС(Объект.Организация, Неопределено, ТекущаяДата()); Но эта функция устарела (в 2.5 ее вообще нет), и с апреля 2019 везде ставила "Продажа не облагается НДС", хотя итоговая сумма НДС в документах проставлена! Сейчас заменил ее на: Объект.НалогообложениеНДС = ?(Объект.Товары.Итог("СуммаНДС") = 0, Перечисления.ТипыНалогообложенияНДС.ПродажаНеОблагаетсяНДС, Перечисления.ТипыНалогообложенияНДС.ПродажаОблагаетсяНДС); Чтобы не перезагружать документы, написал обработку ИсправитьНалогообложениеНДС Зарелизили Комплексная автоматизация 2.5 В ходе ее выполнения выскакивало сообщение:
Обратите внимание, что тип налогообложения "Продажа облагается НДС" не поддерживается учетной политикой организации. В этом случае могут быть списаны только комиссионные товары.
Справочник Учетные политики организаций в 2.5 не используется. Как теперь учетную политику настроить правильно, чтобы эти сообщения не выскакивали? И для моего случая это возможно?

В КА2.4:
// Устарела. Следует использовать методы программного интерфейса УчетНДСУП.
//
// Функция определяет тип налогообложения продажи товара налогом на добавленную стоимость.
//
Функция НалогообложениеНДС(Организация = Неопределено, Склад = Неопределено, Дата = Неопределено, Подразделение = Неопределено) Экспорт

В КА2.5 этой функции нет. Что использовать вместо ее?