1с при обновлении не показывает изменения
Процесс ручного обновления нетиповой 1С довольно длительный и напряженный. Часто исполнитель теряет на каком-либо этапе концентрацию внимания и допускает иногда глупые, а иногда очень серьезные ошибки.
Рассмотрим самые распространенные технические и методологические ошибки при обновления нетиповых конфигураций.
Ошибки перед обновлением
Первое правило администратора — сделать архив. Второе — проверить сделали или нет архив.
И, не смотря на это, самая распространенная и типичная ошибка — отсутствие резервной копии.
Ошибки в процессе обновления нетиповой 1С
- Часто нетиповую конфигурацию обновляют как типовую и все изменения, ранее внесенные в рабочую конфигурацию, исчезают.
- Ошибка, которую совершают практически все — после подготовки новой конфигурации ее сразу устанавливают на рабочую базу. Всегда не хватает времени, надо сделать что-то более срочное и важное и т.д. А первое что необходимо сделать после создания обновленной конфигурации — обновить на нее копию рабочей базы и протестировать все изменения и функционал из новой типовой конфигурации, корректность обновления данных информационной базы.
- При обновлении конфигураций платформы «1С: Предприятие 7.7», конфигуратор не показывает изменения свойств элементов управления диалоговых форм. Очень часто эти доработки не переносятся из-за невнимательности, и в обновлённой конфигурации будут ошибки.
- Обновляют все модули и формы, а права пользователей и интерфейсы — не обновляют.
- Обновление конфигурацию не последовательно через все контрольные релизы, а сразу на последний релиз новой типовой конфигурации. Возможно, это закончится тем, что важные данные исчезнут из информационной базы. Так же очень важно после обновления на все контрольные релизы запускать встроенную обработку обновления конфигурации — она часто выполняет различные конвертации данных и необходимые заполнения информацией.
- Часто забывают обновить или теряются внешние печатные формы и обработки.
Ошибки после обновления нетиповой конфигурации
- После обновления конфигурации необходимо обязательно прочитать историю изменений. Конфигурация стала работать по другому и для ее корректной работы может потребоваться какая то дополнительная настройка.
- Часто после обновления конфигуратор не даёт обновить конфигурацию информационной базы на новую конфигурацию, потому что коды и номера документов становятся неуникальным. Так же распространена проблема при обновлении регистров сведений — наборы записей так же становятся не уникальными. Варианты решения — перебить коды в информационной базе, изменить длину номера или кода, отключение контроля уникальности в справочниках, изменить свойство контроля уникальности справочника — по группе или во всём справочнике.
- После обновления форм в «1С: Предприятие 8.х» обязательно надо проверять как работают привязки, очень часто они перестают работать правильно.
- Возможная ошибка — потеря данных, после обновления. Это может произойти, если внутренние идентификаторы объектов или реквизитов в рабочей и обновленной конфигурации не совпадают.
12 статей про обновление 1С
Типовую программу 1С легко обновить самостоятельно через конфигуратор или интернет. Ещё один способ — использовать cfu-файл. Если пропущено много релизов, вам сэкономят время промежуточные конфигурации.
После обновления не забывайте запустить особые процедуры.
Бывает выгоднее отдать обновление нетиповой 1С на аутсорсинг.
Что нового для вашей 1С?
Оперативная информация о выходе и содержании свежих для 24 типов конфигураций.Рассылка осуществляется в день выхода обновления. Никакой рекламы, только полезная информация. Посмотрите пример →
Рассмотрим обновление на примере нетиповой конфигурации УПП 1.3 находящейся на поддержке с возможностью изменения с релиза 1.3.61.2 на релиз 1.3.62.1. Так как конфигурация сама по себе довольно тяжелая, то это накладывает некоторые особенности, в частности, не всегда получается открыть в одном конфигураторе несколько окон сравнения конфигурации.
Для обновления я использую две одинаковые копии базы данных старого релиза. В одной из них выполняю подготовку *.cf для обновления, назовем ее, например, for_updating. Другая база остается не тронутой и служит только как вспомогательная, для сравнения конфигураций, назовем ее base. В принципе, в качестве вспомогательной может использоваться конфигурация рабочей базы.
В базе for_updating выполняем «Конфигурация» – «Поддержка» – «Обновить конфигурацию», в открывшемся окне выбираем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.
Нажать кнопку «Выполнить», на данном этапе нет пока необходимости что-либо смотреть, так как целью является лишь получение конфигурации поставщика нового релиза.
В процессе обновления может появиться окно «Неразрешимые ссылки», нажимаем «Продолжить». О причинах появления данного окна поговорим ниже.
Откроется окно «Настройка правил поддержки» - для новых объектов (верхний раздел) с обеих сторон ставим «Объект редактируется с сохранением поддержки», для существующих объектов поставщика (нижний раздел) во всех четырех местах ставим флаг «Сохранять текущий режим», нажимаем «ОК».
Произошло обновление основной конфигурации. Сама по себе основная конфигурация на данном этапе нам не нужна, цель – получение новой конфигурации поставщика. Поэтому основную конфигурацию не сохраняем, конфигурацию базы данных не обновляем.
Выполняем «Конфигурация» – «Поддержка» – «Настройка поддержки». В открывшемся окне выбираем «Сохранить в файл» и сохраняем в *.cf конфигурацию поставщика нового релиза.
Основная конфигурация в том виде, в котором она на данный момент имеется, нам не нужна. Закрываем конфигурацию. «Конфигурация» - «Закрыть конфигурацию». Отказываемся от сохранения изменений.
В конфигурации для сравнения base запускаем сравнение конфигурации поставщика (старый релиз) и конфигурации поставщика из файла (новый релиз).
Таким образом, мы увидим только те изменения, которые будут выполнены в конфигурации при обновлении на новый релиз.
В базе for_updating снова запускаем обновление конфигурации через поддержку «Конфигурация» – «Поддержка» – «Обновить конфигурацию», в открывшемся окне выбираем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.
При нажатии на кнопку «Фильтр» откроется окно «Настройка фильтров просмотра». В данном окне устанавливаем флаг «Показывать только дважды измененные свойства».
При обновлении без нашего вмешательства происходит следующее:
- - объект не изменен нами, изменен в новом релизе – обновляется из нового релиза;
- - объект изменен нами, не изменен в новом релизе – остается наш объект;
- - объект изменен нами, изменен в новом релизе – это и есть дважды измененный объект, если ничего не менять – он загрузится из нового релиза.
Таким образом, наиболее пристальное внимание следует уделить именно дважды измененным объектам, их и будем рассматривать.
В данном примере изменено несколько общих модулей, в том числе и общий модуль « УчетНДС ».
По умолчанию в окне обновления показаны отличия основной и новой конфигурации поставщика от старой конфигурации поставщика.
Если посмотреть различия конфигураций в общем модуле «УчетНДС», то мы увидим следующую картину:
Если же сравнить эти модули в базе для сравнения base , то картина будет другая:
Очевидно, что функции «СобратьДанныеДляПечатиИсправленияСчетаФактуры», «СобратьДанныеДляПечатиКорректировочногоСчетаФактуры» и прочие содержат наши доработки, но не меняются при обновлении, а значит, нет смысла тратить время на их просмотр и анализ.
Поэтому, выполняя по процедурное обновление с выделенных процедур и функций можно снять флаги:
Многие скажут, что увидеть отличия старой конфигурации поставщика от новой можно с помощью изменения настройки фильтров просмотра в текущем конфигураторе, не используя сравнение конфигураций в базе base .
Однако, как показывает практический опыт это не так, процедуры и функции все равно отображаются в окне сравнения модулей, даже при установленном фильтре «показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
Сделав не большое мысленное усилие, выявим дважды измененные процедуры и функции, только они будут нуждаться в доработках после процесса объединения. С данными процедурами и функциями нужно определиться, что легче:
- - либо взять процедуру или функцию из новой конфигурации поставщика и потом, после объединения, внести наши доработки;
- - либо снять флаг обновления, тем самым сохранив наши доработки, и уже потом добавить нужный код из конфигурации поставщика.
Объединение с приоритетом основной конфигурации и объединение с приоритетом новой конфигурации поставщика использую редко, в принципе и без использования данных режимов результат получится качественным.
После того как общие модули были проанализированы и у части процедур сняты флаги обновления, видим, что у модулей теперь установлен режим объединения – индивидуальная настройка:
Двигаемся далее. Среди дважды измененных объектов имеется форма элемента справочника «ОсновныеСредства». Прежде чем определиться обновлять ли данную форму из новой конфигурации поставщика, нужно выяснить, что по факту меняется при обновлении.
Для этого в базе base с помощью контекстного меню вызовем «Отчет о сравнении объектов…». В открывшемся окне должны стоять все флаги в группе «Объекты».
Мне нравится режим вывода отчета в табличный документ, когда различия показываются графически, но это дело вкуса.
В результате сравнения формы элемента справочника «ОсновныеСредства» видим, что изменения есть только в модуле формы , а изменений в диалоге формы в обновлении нет.
Но так как форма элемента попала в дважды измененные объекты, то наши доработки есть либо в диалоге формы, либо в модуле.
Выполнив аналогичное сравнение в базе for_updating можно увидеть, что доработки есть в диалоге формы.
Причина тому, добавление справочника «ОсновныеСредства» в план видов характеристик «СвойстваОбъектов». Если обновить форму элемента справочника «ОсновныеСредства» мы получим неразрешимые ссылки, о чем и будет свидетельствовать окно:
В данном случае самым лучшим вариантом будет не обновлять форму элемента справочника «Основные средства» и уже потом добавить необходимый код в модуль формы элемента. В этом случае окно «Неразрешимые ссылки» при обновлении появляться не будет.
Сделаем отступление и представим, что диалог формы элемента справочника «Основные средства» меняется при обновлении на новый релиз, тогда лучшим вариантом было бы обновление формы. Уже потом, после объединения, нужно было бы добавить в форму наши изменения, как в модуль , так и в диалог . Если в модуле много наших доработок и мало от поставщика, то после объединения можно полностью вернуть наш модуль и добавить изменения поставщика.
В этом случае в процессе объединения появилось бы окно «Неразрешимые салки». Вариантов выбора в данном окне два: 1) «Пометить все для объединения»; 2) «Продолжить».
На мой взгляд, правильнее выбирать «Пометить все для объединения».
В этом случае план видов характеристик «СвойстваОбъектов» будет добавлен как объект для объединения в дереве во вновь открывшемся окне «Обновление…»
Естественно, что после обновления в план видов характеристик «СвойстваОбъектов» нужно будет добавить наши изменения, сделать это лучше с помощью сравнения и объединения с текущей конфигурацией.
Рассмотрим, что произошло бы, если бы мы выбрали «Продолжить» в окне «Неразрешимые ссылки». В этом случае форма элемента справочника «ОсновныеСредства» стала бы новой, а план видов характеристик «СвойстваОбъектов» остался бы старым. В этом случае у нас затрутся изменения в диалоге формы элемента справочника, а именно на странице «СвойстваИЗначения», смотри рисунок ниже.
Данная проблема тоже не является не преодолимой, если конечно о ней не забывать.
Конечно, лучше всего стараться как можно меньше вносить изменений в диалоги форм , например, создавать реквизиты и кнопки на форме программно.
Многие вообще рекомендуют не менять типовые формы, а создавать их копии с нашими доработками и делать их основными. Мне данный вариант не нравится потому, что если поставщик добавил что-то в диалоге форме – на моей форме это не появится и мне придется делать добавления вручную, а изменений поставщика может быть гораздо больше, чем наших.
Отдельное внимание хотелось бы уделить по процедурному обновлению форм (часть процедур беру из конфигурации поставщика, а часть нет - индивидуальная настройка). Рассмотрим, как при данном режиме происходит обновление диалога формы в отличие от режима « взять из конфигурации поставщика ».
Пример не имеет отношения к данному обновлению конфигурации, но показателен, поэтому рассмотрим его.
В справочник «Контрагенты» добавлено несколько реквизитов, и они помещены на форму элемента.
При обновлении конфигурации на новый релиз через поддержку будет предложено окно сравнения и объединения конфигурации, в котором можно сделать различные настройки. Сравним несколько вариантов:
1. Флаг обновления формы выставлен, но обновление сделано по процедурно , т.е. по факту выполнена индивидуальная настройка
Многие думают, что диалог формы должен взяться из конфигурации поставщика, а процедуры в зависимости от сделанных настроек. Посмотрим, насколько это так после выполнения объединения. Сделаем сравнение конфигурации поставщика с основной конфигурацией.
Очевидно, что на формах нарушились привязки и прочее, т.е. диалог формы не был полностью взят из конфигурации поставщика. В данном случае в диалоге формы остались наши объекты, с одной стороны это хорошо, с другой стороны, местоположение наших элементов на форме не всегда оптимально, особенно в связи с добавлением новых элементов поставщика, наблюдается изменение позиций обхода и нарушение привязок. В некоторых случаях легче вручную добавить наши элементы в диалог формы, чем делать исправления.
2. Флаг обновления формы выставлен, обновление сделано в режиме «Взять из новой конфигурации поставщика»
В данном случае диалог формы элемента полностью приводится в соответствие с диалогом формы элемента поставщика.
Вернемся к обновлению. С модулями объекта и модулями менеджера документов поступаем также как с общими модулями, обновляем их по процедурно. С формами документов поступаем аналогично тому, как поступали с формами справочников.
Отдельно нужно выделить работу с ролями. Не смотря на то, что в примере не требуется обновлять роли поговорить об этом стоит. Рассмотрим самый простой случай, когда в конфигурации поставщика содержится новый объект. В этом случае потребуется обновление роли « Полные права », но данная роль может содержать какие-то созданные нами объекты, например, справочники, документы и прочее.
Кажется, что с ролью «Полные права» все просто, объединяем их полностью, права на нетиповые объекты сохранятся в них все равно. Так и есть, права на нетиповые объекты никогда не пропадут, но у всех этих объектов будет включен флаг «Интерактивное удаление», что не всегда хорошо. При сравнении конфигураций старого релиза и подготовленной нового релиза это хорошо видно:
С остальными ролями поступаем аналогично тому, как мы работаем с модулями - если наших изменений больше, то не объединяем роль, после обновления добавляем в нее то, что добавил поставщик в новом релизе.
После того как проработали все дважды измененные объекты в окне обновления нажимаем «Выполнить»
На вопрос о том, что измененные нами объекты будут загружены из новой конфигурации, отвечаем утвердительно.
В открывшемся окне «Настройка правил поддержки» проверяем, установленные флаги, хотя по умолчанию должны стоять правильно, нажимаем «ОК».
По окончании процесса объединения сохраняем основную конфигурацию, конфигурацию базы данных пока не обновляем.
Теперь в конфигурацию for_updating добавляем те минимальные доработки, которые не удалось правильно обновить штатными средствами.
Чтобы удобнее было проконтролировать выполнение данного процесса, в базе base запустим сравнение конфигурации поставщика и основной конфигурации старого релиза.
В базе for_updating сделаем тоже самое. Контролируем дважды измененные объекты, различий быть не должно.
После того как обновление в базе for_undating будет завершено обновляем конфигурацию базы данных и тестируем некоторые моменты, что именно хорошо бы протестировать станет понятно в процессе обновления, тут все индивидуально.
Обновление в рабочей базе желательно выполнять с помощью поддержки «Конфигурация» – «Поддержка» – «Обновить конфигурацию». При этом дважды измененные объекты будут загружены из нового релиза, т.е. наши изменения затрутся (конфигурацию не сохраняем!), но потом при объединении с подготовленной конфигурацией мы их восстанавливаем. После этого можно сохранить конфигурацию, обновить конфигурацию базы данных.
если вы его официально купили - можете получать и полный релиз.
а к разработчику задавали этот вопрос? про обновление.
(4) dark_kardinal, купили официально. Как получить полный релиз? Есть только онлайн доступ.
Вопрос разработчику еще не задавал, сначала решил поспрашивать на форуме.
(5) doom-black, Камин после описания проблемы выслал мне полную установку по почте. Обращаться нужно к разработчику. Вышлют cf, сделаете загрузку конфигурации из файла и будет все Ok. На некоторых релизах платформы был вылет при сравнении/объединении модулей без поставки кода. Тоже решалось загрузкой конфы. Естественно такой подход пройдет, если все типовое. Если не типовое, то снимаете конфу с поддержки и делаете сравнить/объединить с конфой из файла. купили официально-вопросы к франчам. должны и обязаны помочь На камине 3.0 часто была такая ошибка. Помогало удаление базы из списка баз. После добавления базы в список, 1с начинала видеть обновления. Еще помогала очистка кэша и временных файлов. Еще можно самому быстро сделать cf-файл. Выгрузить из вашей базы конфигурацию, создать новую пустую, загрузить туда созданный cf-файл, обновить эту чистую базу до нужного релиза, и выгрузить нонфигурацию на диск. Обновить вашу ИБ на полученный *.cf. (10) olbanez, если самому делать cf проблема с его обновлением абсолютно аналогичная. (0) Я бы всётаки (несмотря на отключенную возможность изменений) посмотрел версию конфигурации поставщика (всякие умельцы бывают) (11) AnryMc, конфигурации одного релиза, сравнение я сделал первым делом. Так как конфигурация, можно сказать не типовая, а немног изменена (Конфигурация "Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК.) То обращаться лучше туда, где вы её брали и задавать вопросы им, пусть разбираются. 13. Alex_Japanese_Student 443 19.03.12 10:30 Сейчас в теме надо cf все же иметь, по хорошему надо иметь чистую конфу и на нее каждый новый релиз накатывать и cf выгружать - нудно, но стоит того в конечном счете В общем суть в том, что если развернуть даже типовую демо базу, ее обновление по такой же причине оканчивается крахом. И что нет никакого решения по данному вопросу, уже 2 часа мучаюсь с Камином 49.1, в cfu файле пишет что доступно только для конфигурации 49.1, а у меня блин какая? :( и в справке и в поддержке стоит версия 3.0.49.1 такое поведение может быть симптомом того, что конфигурация поставщика отличается от рабочей конфигурации.т.е. рабочая конфа - 49.1, а конфигурация поставщика может 48.7. тоже не будет обновляться.
попробуй обновление на 49.1 подсунуть и посмотреть захочет ли он его хавать. если захочет.
обнови сняв все галочки - это обновит конфигурацию поставщика. В Управление строительной организации была такая проблема, свзывался с разработчиками, сказали это глюк платформы (если глюк тогда почему из релиза в релиз переходит. ) и посоветовали обновится из cf файла.
(0) В (19) правильно написали - у Вас не совпадает версия конфигурации поставщика, или база вовсе снята с поддержки. Тогда если конфигурация типовая - нужно создать новую базу на соответствующем релизе, выгрузить конфигурацию, загрузить в рабочую базу конфигурацию из файлы. Если не типовая, то тоже самое, но учесть изменения и внести их снова (н.п. через сравнить-объединить) до обновления базы.
Естественно перед этим сделать архив. :)
Сталкивался с такой проблемой.
Надо выгрузить базу (ту, которая до начала обновления была - оригинал) в DT, затем загрузить ее в SQL и обновить. Она без проблем обновится. Затем проделать все обратно - из SQL выгрузить и загрузить в файловую. Эта проблема в платформе - при обновлении в базу в определенную таблицу пишутся строки с проделанным обновлением, которые должны обнуляться, но не обнуляются почему-то. В SQL несколько по другому.
Рассмотрим основные ошибки, которые могут возникнуть при обновлении конфигурации 1С, а также методы их решения.
Файл не содержит доступных обновлений
Ошибка возникает при несовпадении конфигураций.
Порядок исправления следующий:
-
.
- Сделать сравнение/объединение конфигурации 1С с типовым cf-файлом того же релиза. При этом выключить все чекбоксы в дереве метаданных, нажать кнопку «Выполнить».
- Затем в диалоге «Настройка правил поддержки» для всех объектов дерева метаданных выставить «Редактируется с сохранением поддержки», нажать «Ок». В результате восстановится конфигурация поставщика и конфигурация встанет на поддержку. При этом останутся все изменения и возможность редактирования.
- Обновить конфигурацию базы данных.
Имя предопределенного элемента не является уникальным
Существует несколько причин, по которым возникает ситуация «задвоения» связи элементов информационной базы и предопределенных элементов. Если ошибка произошла при обновлении конфигурации, то, с большой степенью вероятности, можно сказать о проблеме совместимости конфигурации с платформой.
Для исправления ситуации снизьте версию платформы, например, до предыдущей версии и повторно запустите обновление конфигурации.
Предопределенный элемент отсутствует в данных
Ситуация, характерна, когда предопределенный элемент отсутствует в базе данных ИБ, но в конфигурации он описан. Существует два основных варианта событий, когда такое происходит.
Иногда ошибкой может быть само обращение в предопределенному элементу, а не само наличие такого элемента. В таком случае нужно понять, почему элемент не создан. Возможно, его случайно удалили либо он создается только при выполнении определенного режима программы.
Если это все же ошибка в информационной базе, то выполните привязку элемента базы к предопределенному элементу. Технически это просто указание имени в свойстве «ИмяПредопределенныхДанных».
Ошибка формата потока
Ещё одна ошибка, возникновение которой может быть вызвано разными причинами. Например, она характерна при нарушении регламента обновления, когда администратор обновляет систему минуя промежуточные конфигурации 1С — в таких случаях «бьется» конфигурация поставщика. Профилактика данной ошибки — последовательное обновление с помощью cfu-файлов.
Если же ошибка всё же возникла, попробуйте следующий порядок действий:
- Поставьте чистую конфигурацию, аналогичную вашей, а затем через конфигуратор, сохраните её в файл.
- Аналогично сохраните файл конфигурации проблемной базы и следующие шаги выполняйте в нём же.
- Откройте пункт меню «Конфигурация» > «Загрузить конфигурацию из файла». При запросе системы «Обновить конфигурацию БД» обязательно выбираем «Нет»
- Создайте новую конфигурацию поставщика через меню «Конфигурация» > «Настройка поддержки» > «Включить возможность изменения».
- Следующим шагом выбираем «Конфигурация» > «Сравнить Объединить с конфигурацией из файла» и указываете файл конфигурации, созданный на втором шаге.
- Соглашаемся с изменениями и применяем их к конфигурации информационной базы по кнопке F7 — «Обновить конфигурацию базы данных».
- Обновляете.
Ошибка при записи профиля
Данная ошибка вызвана, как правило, дублированием информации профилей. Зайдите в справочник пользовательских профилей: «Все функции» > Справочники > «Профили групп доступа» (не путайте со справочником «Пользователи)».
Раскройте все группы профилей и посмотрите, есть ли повторяющиеся записи. Удалите все ненужные дубли, и ошибка исчезнет.
12 статей про обновление 1С
Типовую программу 1С легко обновить самостоятельно через конфигуратор или интернет. Ещё один способ — использовать cfu-файл. Если пропущено много релизов, вам сэкономят время промежуточные конфигурации.
После обновления не забывайте запустить особые процедуры.
Бывает выгоднее отдать обновление нетиповой 1С на аутсорсинг.
Что нового для вашей 1С?
Оперативная информация о выходе и содержании свежих для 24 типов конфигураций.Рассылка осуществляется в день выхода обновления. Никакой рекламы, только полезная информация. Посмотрите пример →
Читайте также: