1с удалить конфигурацию поставщика
Обновлено: 06.07.2024
Удалить конфигурацию коммутатора CISCO
Нужно удалить конфигурацию, чтобы сделать заново. Как это сделать? Пробовал команду erase.
Построить в алфавите машину Тьюринга, переводящую конфигурацию К1 в конфигурацию К0
Есть само уравнение Есть код,, но его надо отредактировать, но я не понимаю в чем ошибки, если не.
Как выгрузить конфигурацию в 7.7?
Подскажите плз. как выгрузить конфигурацию без бд в 7.7 ?
Как изучить типовую конфигурацию
Привет всем. Изучаю устройство 1С практически с нуля, ибо хочу сменить профессию с экономиста на.
Добавлено через 2 минуты
Долго думал о сути написанного. Ничего не придумал. Попробуйте ещё раз, более подробно. Что было до, что сделано, в какой момент система отругалась.
вариант 2: восстановить бэкап, если таковой имеется
вариант 3: сравнить/объединить через cf от предыдущего релиза (не самый лучший вариант, ибо чревато на типовых конфах)
Называйте файл 1Cv8.1CD хоть базой, хоть конфигурацией, суть от этого не изменяется, все в одном флаконе и база и программа(по сленгу 1С конфиг.). Для прояснения опять установил шаблон(интересно, это что база, конфигурация. опять же все в одном флаконе) и создал из шаблона ещё одну конфиг+базу. , т.к. платформы выше нет, но есть шаблон для версии пониже, поэтому надо перед установкой удалить все, что насоздавала 1С, заняв место гигабайты. поэтому что надо удалить и где(в каких каталогах) это находится
надо перед установкой удалить все, что насоздавала 1С база - это когда там есть информация. Если пофиг на данные - удаляйте как хотите, вместе с каталогом.На всякий случай прикопайте архив - ну, это святое .
Информации нет, поэтому я и хочу узнать, когда нажимаешь setup, начинается установка, вроде как устанавливается шаблон, к которому прописывается путь и запоминается в каталоге установленной платформы, затем идет создание базы и опять создается каталог(с этим каталогом понятно, где он находится). мне надо знать, при устаноке(Setup) и при создании базы, какие каталоги и где создались, где эти пути прописались(в реестре, в платформе и т.д.), чтоб можно было почистить
PS: в пустых таблицах нет информации, но все же они образуют базу. да и сами структуры представляют собой уже информацию, но это все философия.
Vofka --> Vofka
В данной статье я хочу показать сервисные возможности платформы 1С:Предприятие 8, в части использования конфигурации поставщика, которые очень часто бывают востребованы, но как показала практика, знакомы отнюдь не всем начинающим и даже опытным специалистам.
Рассмотрим типичную ситуацию, в которой часто оказываются новички. Допустим имеется типовая конфигурация 1С:Комплексная автоматизация 8. Первоначально конфигурация была установлена из дистрибутива (допустим релиза 1.1.20.1). Затем в связи с необходимостью адаптации под специфику предприятия была включена возможность изменения (новички очень часто ошибочно называют это действие снятием с поддержки, хотя на самом деле это не так).
И вот спустя некоторое время мы имеем сильно доработанную, но все же типовую (в целях регламентированного учета мы регулярно выполняли обновление) конфигурацию. А дальше рассмотрим несколько гипотетических ситуаций:
Теперь рассмотрим различные варианты решения:
а) Первый вариант: Меню -> Конфигурация -> Сравнение конфигураций, затем выбираем конфигурацию поставщика и сравниваем ее с основной конфигурацией.
Удивительно, но есть такие, кто про это не знает. Или при любых обстоятельствах используют пункт Сравнить, объединить с конфигурацией из файла (предварительно раздобыв/получив типовой .cf).
б) Второй способ подходит если нам нужно не только увидеть изменения, но и сразу выполнить объединение.
Меню -> Конфигурация -> Поддержка -> Настройка поддержки и внизу нажимаем кнопку Сравнить, объединить.
2) Другая ситуация: допустим мы изменили или удалили какой-то кусок типового кода, а через некоторое время оказалось, что мы допустили ошибку и нужно все вернуть обратно. И как часто происходит, бэкапа сохраненной конфигурации до внесенных изменений не оказывается. Но мы то точно знаем, что этот кусок кода содержится в типовой, поэтому конфигурация поставщика решила бы проблему.
Естественно можно поступить как и в первом случае. Дождаться окончания процесса сравнения, и из окна сравнения конфигураций открыть типовой модуль и скопировать оттуда код.
Некоторые делают именно так, но если мы имеем дело с монстром типа УПП, к тому же сильно измененной, то окончания процесса сравнения можно ждать ооочень долго. Имей мы файл .cf его можно было бы просто открыть в окне конфигурации (кстати про эту возможность знают тоже не все новички) и скопировать оттуда нужный код.
И возникает резонный вопрос, как же все таки сохранить конфигурацию поставщика в файл? Почему нет пункта меню аналогично Сохранить конфигурацию в файл для основной конфигурации или Сохранить конфигурацию БД в файл, для конфигурации базы данных. А где такой же для конфигурации поставщика? На самом деле он тоже есть, только зарыт чуть глубже. А именно все в той же форме настройки поддержки.
Просто многие единственный раз открывают данную форму только лишь для включения возможности изменения и больше никогда к ней не возвращаются.
А в нашем случае можно было поступить еще проще, даже не сохраняя конфигурацию в файл, нажать кнопку Открыть. Эффект тот же, но гораздо быстрее.
А для чего еще может понадобиться сохранение конфигурации поставщика в файл?
3) Рассмотрим следующую ситуацию. Допустим на начальном этапе существования конфигурации в типовой не было нужного нам функционала и было принято решение о доработке. Доработка была минимальной, но в дальнейшем это все же создавало неудобства при обновлении. Но затем, спустя какое-то время, мы обнаруживаем, что данный функционал (как в свое время было с версионированием объектов) появился в типовой (и как часто бывает, реализован на порядок лучше, чем «кустарная» доработка).
Приведу еще несколько примеров реальных ситуаций, когда может потребоваться откат к типовой конфигурации:
1. Пару раз сталкивался с конфигурациями, в которых доработке подвергались только макеты печатных форм. Ввиду отсутствия опыта либо по незнанию, программист сопровождавший конфигурацию, вместо создания внешней печатной формы снимал конфигурацию с поддержки и дорабатывал встроенные макеты (зачастую банально чтобы добавить логотип компании), после чего пользователи лишались возможности автоматического режима обновления.
2. Опять же по незнанию типового функционала (очень часто этим страдают бывшие «семерочники») вместо использования свойств и категорий были добавлены реквизиты справочников/документов, когда это не имело веских на то оснований (данные например использовались только для вывода в печатные формы).
Конечно же это не проблема, имей мы дело с УТ или другой конфигурацией управленческого плана, где в общем не критичны обновления, но в данном примере речь шла про доработанные УПП либо комплексную автоматизацию. И получается из-за незначительных доработок, которые можно было реализовать без снятия с полной поддержки, мы имеем никому не нужный геморрой с типовыми обновлениями.
Возникает резонное желание отказаться от внесенных доработок и снова поставить конфигурацию на полную поддержку. Как это сделать?
Вот такие как оказалось нехитрые возможности имеются в арсенале разработчика, но незнание этих приемов на практике может вылиться во многочасовую ненужную возню, описанную выше. Так что кто знал — молодец, а кто не знал — берите на вооружение и экономьте свое время.
Введение в поставку и поддержку конфигураций
Рассмотрим типичную ситуацию. Фирма-поставщик выпускает тиражную конфигурацию. Клиент приобретает ее и адаптирует под свои требования. Через некоторое время поставщик выпускает новую версию, и перед клиентом встает вопрос обновления, то есть интеграции своих изменений с изменениями поставщика. Ручное объединение в подобных случаях очень трудоемко. Требуется составить список всех отличий своей конфигурации от старой конфигурации поставщика и заново внести их в новую версию. Можно делать и наоборот, то есть подготовить список изменений поставщика и внести их в свою конфигурацию, но это ничего не меняет. Многое также зависит от механизма сравнения конфигураций и подготовки отчета различий. В платформе "1С:Предприятие" версии 8 этот механизм был существенно улучшен по сравнению с "1С:Предприятием" версии 7.7, но даже самый лучший и подробный отчет от дальнейшей утомительной ручной работы не освобождает. Механизм поставки и поддержки конфигураций в значительной степени автоматизирует этот процесс.
Общая схема обновления
Подробно рассмотрим ситуацию на примере любого свойства объекта метаданных. Возможны следующие варианты:
| Пользователь | Поставщик | Правило обновления | |
| 1 | Менял | Не менял | Взять из конфигурации пользователя |
| 2 | Менял | Менял | ? |
| 3 | Не менял | Не менял | Взять из конфигурации пользователя |
| 4 | Не менял | Менял | Взять из конфигурации поставщика |
Таблица 1. Правила обновления по умолчанию
Нетрудно заметить, что варианты 1, 3, 4 в большинстве случаев не требуют модифицировать предложенное правило. Самый сложный случай – второй. Здесь нельзя сделать никаких предположений, но можно по крайней мере автоматически определить все такие свойства и предоставить пользователю отфильтрованный список для указания правила в каждом конкретном случае.
Реализация в платформе "1С:Предприятие 8"
Общие понятия
В "1С:Предприятии 8" любая конфигурация может стоять на поддержке одной или нескольких других конфигураций, называемых конфигурациями поставщика. В качестве конфигурации поставщика может выступать конфигурация, созданная командой Конфигурация - Поставка конфигурации - Создать файлы поставки и обновления конфигурации . В результате выполнения этой команды создается файл конфигурации ( cf) . Файл, подготовленный командой Конфигурация - Сохранить конфигурацию в файл , в качестве конфигурации поставщика использовать нельзя. Для того чтобы получить конфигурацию поставщика в виде файла информационной базы (1cd) или файла выгрузки информационной базы (dt), требуется подготовленный вышеописанным способом файл cf загрузить в требуемую информационную базу (возможно, в пустую), выполнив команду Конфигурация - Загрузить конфигурацию из файла . Затем, при необходимости, можно штатными средствами создать файл dt.
Существуют два способа встать на поддержку конфигурации поставщика. Первый - использовать конфигурацию, подготовленную вышеописанным способом (при необходимости внося в нее изменения). Фактически подготовленная конфигурация поставщика находится на поддержке той конфигурации, в которой она была создана. Аналогичный результат достигается через команды Конфигурация - Загрузить конфигурацию из файла и Администрирование - Загрузить информационную базу . Второй способ позволяет поставить на поддержку уже созданную конфигурацию пользователя. Для этого необходимо выполнить команду Конфигурация - Сравнить, объединить с конфигурацией из файла . Если в качестве выбранного файла указывается файл конфигурации поставщика, и конфигурация пользователя уже не находится на ее поддержке, предлагается после объединения встать на поддержку.
Существуют два режима поддержки. Первый - в конфигурацию поставщика не вносятся изменения, она используется как есть. Такой режим возможен только при первом способе постановки на поддержку, и именно в нем конфигурация поставщика находится после ее создания. Все объекты конфигурации в этом случае заблокированы для изменений (в том числе и для добавления новых объектов). Второй режим - конфигурация находится на поддержке с возможностью изменений. Для того чтобы перейти в этот режим, необходимо открыть диалог настройки поддержки командой Конфигурация - Поддержка - Настройка поддержки и нажать кнопку Включить возможность изменения .
Способы обновления конфигурации. Обновление конфигурации может выполняться как с помощью файлов конфигурации поставщика новой версии, так и с помощью специальных файлов обновления конфигурации ( cfu) . Обновление конфигурации с помощью файлов (cf) может выполняться с любой версии (в том числе и более новой, при необходимости отказаться от внесенных изменений). При создании файла обновления поставщик указывает, для каких версий конфигурации он предназначен. Таких версий может быть несколько, но обновление может быть выполнено только с них. Это связано с тем, что файлы обновления включают в себя не всю конфигурацию, а только те изменения, которые существуют между конечной версией и указанными при создании файла обновлениями. Важно отметить, что файлы cfu не поддерживают обновления не только для более ранних версий конфигурации, чем они предназначены, но и для более поздних.
Приведем пример. Если конечная версия "4", а обновление создается только для версии "2", то невозможно будет выполнить обновление не только для версии "1", но и для версии "3". Такое ограничение связано с возможностью "обратных" изменений. То есть представим себе, что при переходе к версии "3" поставщик увеличил длину строки в типе реквизита, а в версии "4" изменил ее обратно. При подготовке обновления "2" - "4" это свойство в файл не попадет (поскольку в этих версиях значения совпадают). Если позволить использовать такой файл для обновления версии "3", то у пользователя окажется неправильная, увеличенная длина строки. Файлы обновления конфигурации имеют минимальный размер не только за счет включения в них только необходимых объектов, но и за счет применяемого в них сжатия данных. Они оптимальны для доставки обновления пользователю по низкоскоростным каналам связи. Обратной стороной является описанная выше меньшая гибкость их применения. С точки зрения дальнейшего процесса обновления применение файлов cf и cfu ничем не отличается.
Рисунок 1. Общая схема взаимодействия поставщика и пользователя
Выполнение обновления
Если конфигурация пользователя находится на поддержке без возможности внесения изменений, обновление представляет собой тривиальный, полностью автоматизированный процесс. Пользователь выполняет команду Конфигурация - Поддержка - Обновить конфигурацию , и после получения подтверждения выполняется обновление. Рассмотрим второй, наиболее интересный случай. Пользователь включил возможность изменения. Обновление конфигурации производится с использованием стандартного механизма сравнения и объединения, но пользователю предоставляется существенный дополнительный сервис. В процессе сравнения участвуют не две а три конфигурации - конфигурация пользователя, старая конфигурация поставщика (она хранится в конфигурации пользователя) и новая конфигурация поставщика, до которой и производится обновление. При этом система автоматически производит анализ сделанных изменений и, в соответствии с таблицей 1, расставляет правила объединения. Главную сложность представляет собой вариант 2, когда и пользователь, и поставщик меняли одно и то же свойство. Как отмечалось, разумных предположений автоматически сделать невозможно, но можно выделить эти случаи для пользователя. Все подобные свойства в дереве объединения показываются жирным шрифтом. Кроме того, в настройке фильтра просмотра можно указать флажок Показывать только дважды измененные свойства , и в дереве объединения будут показываться только те свойства, которые требуют ручной установки правил объединения. После выполнения объединения хранимая внутри пользовательской конфигурации конфигурация поставщика будет обновлена до новой версии.
Модификация алгоритма обновления с помощью правил поддержки
Пользователь может модифицировать приведенный алгоритм обновления с помощью правил поддержки, которые можно установить для каждого объекта метаданных. Необходимость в этом может возникнуть, если пользователь собирается самостоятельно выполнять дальнейшую модификацию объекта на себя и ему неинтересны изменения, вносимые поставщиком. Частный случай - пользователю вообще не требуется данный объект, и он хочет его удалить. Существуют три правила поддержки объекта метаданных:
- "Объект поставщика не редактируется" - пользователь не может изменять объект поставщика. Основное предназначение этого правила будет описано ниже, но пользователь может установить его с целью страховки от случайных изменений. При обновлении такие объекты будут полностью заменяться на объекты поставщика новой версии.
- "Объект поставщика редактируется с сохранением поддержки" - основное правило. В этом случае алгоритм объединения в точности совпадает с описанным.
- "Объект поставщика снят с поддержки" - пользователь не хочет выполнять дальнейшие обновления данного объекта. Для того чтобы удалить объект поставщика, предварительно ему необходимо установить данное правило.
Приведем расширенный вариант таблицы 1, с учетом правил поддержки.
| Пользователь | Поставщик | Правила поддержки и обновления | |||||||
| 1 | Менял | Не менял |
| ||||||
| 2 | Менял | Менял |
| ||||||
| 3 | Не менял | Не менял |
| ||||||
| 4 | Не менял | Менял |
|
Таблица 2. Правила обновления по умолчанию с учетом правил поддержки
Ограничения действий пользователя со стороны поставщика с помощью правил поставки
Поставщик может ограничить возможные изменения пользователя с помощью правил поставки, которые можно устанавливать для каждого объекта метаданных. Данная возможность призвана ограничить возможные изменения конфигурации поставщика, нарушающие логику ее работы, после которых дальнейшая поддержка конфигурации теряет смысл. Существуют три правила поставки:
- "Изменения разрешены";
- "Изменения не рекомендуются";
- "Изменения запрещены".
Далее приводятся правила поддержки (по умолчанию и доступные для выбора пользователем), соответствующие различным правилам поставки.
Во всех конфигурациях 1С:Предприятие 8 существуют два режима поддержки конфигурации:
Полная поддержка конфигурации - пользователь всегда работает с точной копией конфигурации поставщика последней версии и имеет возможность обновления конфигурации.
Поддержка с возможностью редактирования конфигурации, внесение в нее необходимых изменений. Без крайней необходимости не рекомендуем снимать конфигурацию с поддержки.
В данной инструкции рассмотрим как снять конфигурацию с поддержки и как поставить на поддержку на примере конфигурации 1С:Бухгалтерия предприятия 8, ред. 3.0
Как снять конфигурацию с поддержки
Шаг 1. Обязательно необходимо создать резервную копию базы. Для этого в базе необходимо завершить работу всех пользователей и выполнить резервное копирование базы по инструкции: Создание резервной копии базы 1С
После создания резервной копии необходимо запустить информационную базу в режиме Конфигуратор.
Шаг 2. После того, как Конфигуратор запустится, необходимо открыть вкладку Конфигурация - Открыть конфигурацию, слева откроется окно Конфигурация. Пиктограмма напротив названия конфигурации означает, что в конфигурацию ранее не были внесены изменения и она полностью соответствует конфигурации разработчика (рядом с желтым кубиком находится замок).
После открытия окна конфигурации необходимо перейти во вкладку Конфигурация - Поддержка - Настройка поддержки...
В окне Настройка поддержки нажимаем на кнопку Включить возможность изменения, в следующем окне нажимаем Да.
После этого необходимо выполнить Настройку правил поддержки, устанавливаем переключатель на пункт Объект поставщика редактируется с сохранением поддержки - это значит, что объекты можно изменять, но при обновлении все изменения затрутся, если не убрать галочки в сравнении конфигураций. Пункт Объект поставщика снят с поддержки означает, что все объекты открыты для изменений.
Нажимаем кнопку ОК, запускается процесс изменения режима поддержки.
После принятия изменений в окне Настройка поддержки - Конфигурация находится на поддержке с возможностью изменения, пиктограмма напротив названия конфигурации поменяет свой вид (замок, который находился рядом с желтым кубиком, исчезнет).
Сохранение внесенных изменений в конфигурацию происходит по кнопке (F7 или Конфигурация - Обновить конфигурацию базы данных).
Конфигурация снята с поддержки.
Поставить конфигурацию на поддержку
Обязательно убедитесь, что изменений, которые затрагивают структуру данных, в конфигурации базы не было, иначе данный способ не может быть использован. Для полной уверенности рекомендуем обратиться к квалифицированным специалистам.
Единственным способом корректной постановки на поддержку является загрузка типовой конфигурации в информационную базу вместо измененной конфигурации.
Шаг 1. Обязательно необходимо создать резервную копию базы. Для этого в базе необходимо завершить работу всех пользователей и выполнить резервное копирование базы по инструкции: Создание резервной копии базы 1С
После создания резервной копии необходимо запустить информационную базу в режиме Конфигуратор.
Шаг 2. Далее необходимо убедиться, что версии соответствуют (они должны быть идентичные):
версия конфигурации в разделе Справка - О программе.
версия конфигурации поставщика в разделе Конфигурация - Поддержка - Настройка поддержки:
Если версии различны, необходимо выполнить обновление конфигурации.
Шаг 3. Если версии совпали, то нажимаем кнопку Сохранить в файл и выгружаем конфигурацию поставщика в файл с расширением *.cf. На компьютере необходимо выбрать папку для сохранения файла.
Шаг 4. Загружаем сохраненный файл вместо основной конфигурации: Конфигурация - Загрузить конфигурацию из файла. , указываем путь к файлу, который сохранили ранее.
Нажав на кнопку Да соглашаемся с вносимыми изменениями.
Шаг 6. По окончанию процесса загрузки конфигурация будет полностью обновлена и встанет на поддержку.
Для проверки выполнить: Конфигурация - Поддержка - Настройка поддержки. В окне Настройка поддержки появится надпись Конфигурация находится на поддержке, пиктограмма напротив названия конфигурации изменит вид (рядом с желтым кубиком появится замок).
Читайте также: