При добавлении нового контрагента ругается: "В данной транзакции уже происходили ошибки".
Ошибка появилась после обновления до релиза 49.10.
Она возникает при заполнении ЛЮБОГО ПОЛЯ на закладке "Адреса и телефоны".
В релизе 48.9 ошибки не было. Откатываюсь до этой версии - всё ОК.
Обновляю снова до последнего релиза - та же самая ошибка...
И еще одна сопутствующая "радость" появилась.
При попытке отредактировать запись уже созданного контрагента выскакивает сообщение:
"Ошибка при вызове метода контекста (Записать): Не удалось записать: "Контактная информация"!"
В базе данных ошибок нет, кэш почищен, что еще сделать?
Ума не приложу. Экзотика какая-то...
(2) PhoenixAOD, я бы не стал говорить так категорично.
Во-первых, я не уверен, что этот глюк появился в самом последнем релизе.
Возможно он был и раньше. Просто я эту базу обновил сразу до последнего релиза.
Во-вторых, в других базах этой ошибки у меня не было.
Возможно, что еще кто-то пожалуется. Но МАССОВОГО недовольства не будет - это экзотическая ошибка.
Ну и, в-третьих, обновляться-то все равно раньше или позже надо.
Вот я и ищу сейчас таблетку от этой головной боли для конкретного пациента :)
SVGS, ну попробуй платформу поновее поставить, я проверяю на 8.2.18.96.
(6) Платформу? Сейчас попробую. Обновлял с 48.9 на 49.10.
Если она это обновление видит, так чего с промежуточными заморачиваться?
На других базах у меня тоже всё нормально. Проверял - всё ОК.
Голова болит у дятла. И больше ни у кого. :)))
(6) AllexSoft, 8.2.18.96 будет проблема при обновлении. были темы здесь что народ не мог на 18 версии платформы обновить БП и откатывались на 17 версию.
У меня то же самое было с УТ11, но когда я поставила платформу последний релиз 8.2.18.104 от 27 июня - у меня обновление произошло без проблем
Сделал так:
1. Откатился на 48.9
2. Обновил платформу на 18
3. Обновил релиз до 49.10
Результат - та же самая ошибка.
Похоже, что дело не в платформе, не в релизе, а в конкретной БД.
Причем, тестирование и исправление говорит, что никаких ошибок нет;
а контактная информация (в т.ч. и адреса) не записывается...
Подробная диагностика такая:
{Справочник.Контрагенты.Форма.ФормаЭлемента.Форма(524)}: Ошибка при вызове метода контекста (ЗаписатьВФорме)
ЗаписатьВФорме();
по причине:
В данной транзакции уже происходили ошибки!
Что делать? Пока ни одной сколь-нибудь стоящей мысли нет ))
(14) SVGS, Кстати, сейчас посмотрел- в модуле формы Элемента Контрагенты нет такой функции или процедуры ЗаписатьВФорме()...Ее точно никто не допиливал?
(14) SVGS, слушай, а ты попробуй базу свою 48.9 скопируй на флешку и обнови на ДРУГОМ компьютере ) и релиз заного перекачай, если возможно...
у меня было что то похожее, долго искал, дело оказалось в оперативке сервера, одни из планок памяти оказалась битая и при обновлении какие то страницы оперативы попросту херились (
SVGS, В справочнике виды контактной информации все корректно?
Еще бы понять, как это "все корректно". Во всяком случае, когда кладу этот справочник рядом со справочником из работающей базы, то никаких отличий не вижу.
в модуле формы Элемента Контрагенты нет такой функции или процедуры ЗаписатьВФорме()... Ее точно никто не допиливал?
Точно не допиливал. Конфигурация типовая.
(17) AllexSoft, я об этом тоже подумал. Поэтому все операции, описанные в предыдущем посте, я сделал на другом компе. Результат от компа, к сожалению, не зависит...
(21) SVGS, вот координальное решение: выгрузить весь регистр КИ через универсальную выгрузку в XML, очистить регистр, обновить, попробывать записать любую КИ, если ошибок нет то записать назад КИ из XML сохраненного ранее)
(18) SVGS, Я не нахожу такой процедуры или функции в форме элемента контрагенты: ЗаписатьВФорме()...Щелкните по ошибке, вы перескочите на нее, скажите, где она у вас? В каком месте распологается?
(23) SVGS, Что то мне кажется все же, что что то не то с регистром сведений Контактная информация, так как при записи контрагента пишется туда, там нет записей кривых? Заполненных не полностью или не корректно?
Что то мне кажется все же, что что то не то с регистром сведений Контактная информация, так как при записи контрагента пишется туда, там нет записей кривых? Заполненных не полностью или не корректно?
Ну дела обстоят так: есть ли там записи, нет ли там записей - без разницы.
Ошибка проявляется даже в том случае, когда в поле "Другое(любая другая контактная информация)" добавляешь 1 символ. Т.е, было там написано "0" - на версии 48.9 можно было спокойно написать "01". Обновляешься на версию 49.10, пытаешься написать "012" - возникает ошибка. Можно, конечно, героическими усилиями найти эту ошибку в ТИПОВОЙ конфигурации, но кто эти усилия оценит?
Бум действовать так:
1) откатываемся до последней рабочей конфигурации (48.9), работаем на ней;
2) пишем письмо в 1С, т.к. никаких изменений в конфигурацию не вносилось, то пусть свои ошибки устраняют за свой счет ));
3) когда появится конфигурация с работающей связкой "Контрагенты-Контактная информация", то надо ее сначала проверить и только после этого обновить рабочую базу.
P.S. Похоже есть в этой базе какие-то нетиповые данные,
которые приводят типовую конфигурацию к неадекватной реакции на кнопку "хочу контакт" :)))
(28) SVGS, Сегодня обновлюсь и проверю в 1 базе, сейчас там пользователи работают, нужно сохраниться, пока не дают...Отпишусь, если будет такая же ошибка и как с ней бороться
SVGS, Обновился, проверил- ошибки нет...Все таки у вас некорректные записи где то
Я это и сам уже понял. Но, если автоматическая проверка ничего не находит, то есть ли смысл как-то искать эти некорректные записи вручную? Тем более, что контактная информация не редактируется ни у одного из контрагентов в обновленной базе...
Думаю, что это косяк 1С. Безусловно, что в этой БД есть какие-то некорректные данные. Но почему обычное обновление типовой конфигурации делает вполне корректные с точки зрения 1С данные некорректными?
Ну вот всё и решилось :)
Расскажу вкратце. Ответ от 1С пришел на следующий день. Суть проста: можете присылать базу, мы поставим в очередь, на скорое решение не надейтесь, но может быть починим...
Понятно, что меня такой ответ не очень-то устроил. Полазал по другим форумам. Наткнулся на похожий случай: там ломался справочник "Номенклатура" при наличии неактуального обмена с УНФ. В этой БД больше года назад тоже был настроен обмен с УНФ. Потом это направление было признано бесперспективным, работы свернуты, но сами правила обмена остались...
Стоило их удалить и чуть-чуть почистить базу от лишних объектов, как всё заработало!
Кто бы мог подумать, что наличие НЕАКТУАЛЬНЫХ правил обмена с УНФ делает неработоспособной ТИПОВУЮ конфигурацию и в частности два основных справочника в ней?
P.S. Описание этой ошибки отправил в 1С. Но попросить у них зарплату за три дня работы с нетипичными ошибками типовой конфигурации постеснялся :)))
(34) SVGS, не поверишь, сегодня сам столкнулся с проблемой обновления типовой БП на 49.10... при попытке запуска в пользовательском режиме не проходило обновление, ругалось тоже на план обмена, правда с торговлей... решилось включением возможности изменения, правкой глобального модуля обновления, обновлением без глючной процедуры, ну и загрузкой сверху cf этого же релиза )
(35) AllexSoft, спасибо за предупреждение. У меня тоже есть обмены с УТ.
Сейчас работают на 49.8. Десять раз подумаю перед тем, как поставить новый релиз БП.
Оно мне надо? Устранять за ту же з/п ошибки 1С, которые из-за косяков в обменах лезут в типовые конфигурации БП?
У разработчиков 1С свои доходы, у нас - свои. Так пусть каждый отвечает за результаты СВОЕЙ работы! :))
А почему никто не описал изначальную причину ошибки? В данной транзакции уже возникала ошибка происходит если происходит вызов функции ОтменитьТранзакцию() при условии что нет ни одной активной транзакции. Т.е. транзакция была закрыта. В этом направлении и надо капать
Я не знаю как в других конфигурациях, но в УПП дело обстоит так:
На примере справочника Контрагенты (при записи).
1. Возникает ошибка (при записи), генерируется исключение.
2. Вызов функции ОбщегоНазначения.СообщитьОбОшибке(...)
3. Далее снова вызовы ... и обращение к константе.
В этот момент возникает повторно исключение ;)
Т.е. исключение в обработки исключения.
Для того, что бы узнать истинную причину ошибки, нужно посмотреть стек вызовов ;)
Я поставил точку останова на ОбщегоНазначения.СообщитьОбОшибке и узнал истинную ошибку.
Столкнулся с такой же проблемой в БП 3.0 при использовании внешней обработки пользователем без полных прав. Проблему я решил, дав пользователю права на РС ВерсииОбъектов (не используем!) и ПланОбмена.ОбменРозница1Бухгалтерия3 (который мы не используем!). Но для меня осталось загадкой, почему, когда пользователь проводил документ "Списание с расчетного счета" интерактивно, то такой ошибки не было, а если он проводил документ с помощью обработки, то была. Может кто знает?
в УТ 11 столкнулся с данным сообщением при печати УПД.
Вырезал попытку в общем модуле и получил настоящую ошибку. Ругалось на отсутствие заполненного поля "Организация" при чтении регистра сведений "Задания к распределению расчетов с клиентами". Удалил записи по данной накладной и ошибка ушла.
Также столкнулся с такой ошибкой, вроде решил снятием галочки в Параметрах рабочего сервера (консоль Администрирование серверов 1С Предприятия) - Менеджер под каждый сервис и перезапуском сервера.
Я не на 100% уверен была ли в нем проблема, но было ощущение, что в 1с создается целая гора лишних сеансов (увидел при попытке выгрузить базу, перед тем как ковыряться), снял эту галочку тк до этого её ставил, а затем перезапустил сервер.
После этого все заработало.
Столкнулся с аналогичною бедою. Создавал узел обмена по магазину методом копирования файловой базы по рецепту из скрижалей мудрости. Розница, типовая, на поддержке, в общем, всё кошерно и халяльно. При попытке программно изменить код узла, который ЭтотУзел, ругался точно так же. Оказалось - не любит всеми горячо любимая программа буквы в коде узла. Поменял код узла на полностью цифровой - и всё завертелось.
(47)
Прошу пардону за назойливость - опять столкнулся с тою же бедою. Делал свёртку базы, и, чтобы никому не мешать, - делал её в отдельной базе, в которую из боевой по обмену подгружал актуальные данные. Когда дело дошло до переноса свёрнутой базы из тестовой в боевую, при попытке поменять код узла (который ЭтотУзел), опять стала ругаться розница, что уже были ошибки в этой транзакции. Помогла пометка на удаление документов ВводНачальныхОстатковУзла с датой после даты свёртки. Они один фиг в базе непроведённые болтались (формировались для периферийных узлов РИБ). Так что, по идее, трагедии в том, что они помечены теперь на удаление, нет. Да и снять пометку удаления у этих документов после изменения кода узла никакой шариат, вроде, не запрещает.