Показывать только дважды измененные свойства 1с что это
В свойствах баз обновлятора появилась вот такая замечательная опция:
Сразу оговорюсь, что работать эта возможность будет только с платформой 1С равной или новее 8.3.8.1652. Именно начиная с этой версии 1С позволяет выполнять обновление доработанных конфигураций в пакетном режиме.
Когда она может быть полезна
Например, вы регулярно обновляете одну и ту же дописанную конфигурацию и хотите облегчить себе работу.
При этом все дописки вы знаете и они у вас задокументированы.
В таком случае может быть проще и быстрее:
- Сначала обновить конфигурацию обновлятором (установив соотв. галку в свойствах базы)
- Затем посмотреть отчёт обновления в обновляторе (там будут указаны свойства,измененные дважды)
- И только после этого проверить, что все доработки на месте и вернуть те, что были утеряны (об этом смотрите ниже, где я рассказываю как работает автоматическое обновление доработанных конфигураций)
При таком способе работы вам не нужно:
- Скачивать необходимые обновления
- Открывать конфигуратор и применять эти обновления
- Ожидать пока выполнится обновление конфигурации
- Ожидать пока выполнится обновление базы данных
Вы вообще можете запланировать такое обновление на ночь, а уже утром произвести контроль и доработку, если она потребуется.
И если доработки конфигурации небольшие, то в большинстве случаев вам после обновления вообще не придётся ничего делать.
Ваше вмешательство будет нужно тогда, когда в обновлении будет изменен тот же самый объект, что изменен у вас (это и называется "измененные дважды"). И вы можете легко находить такие объекты, просматривая отчёт обновлятора:
Как работает автоматическое обновление доработанных конфигураций
Обновление происходит при помощи того же пакетного ключика updatecfg, но при этом обновлятор дополняет эту команду специальным файлом настроек в формате xml.
Обновление происходит с приоритетом новой конфигурации, при этом:
- Если вы добавляли в конфигурацию новый объект - обновление его не затронет.
- Если вы добавляли в конфигурацию новый реквизит в уже существующий объект типовой (от поставщика) - обновление его также не затронет.
- Если вы меняли в конфигурации объект поставщика, но он не изменился в этом обновлении, то он останется как есть.
- Но, если вы меняли в конфигурации объект поставщика, и он изменился в этом обновлении, то возьмётся версия из обновления. При этом в отчёте обновлятора этот объект будет отмечен как "дважды измененный".
При этом, при настройке по умолчанию.
. обновлятор останавливается сразу после обновления конфигурации, если были обнаружены свойства, измененные дважды. Это делается для того, чтобы вы смогли сначала вернуть необходимые доработки, а уже затем запустить обновление базы данных.
Я очень надеюсь, что эта возможность позволит высвободить ещё немного часов от ручного, монотонного труда.
Как настроить режим объединения конкретных объектов (для опытных пользователей)
Общий случай (c1)
По умолчанию, как описано выше, дважды измененные свойства замещаются свойствами из обновления.
Если вы опытный пользователь (программист или администратор, имеющий навыки обновления доработанных конфигураций), то при необходимости сможете настроить режим объединения для объектов, которые дорабатывались, чтобы, например, происходило не замещение, а объединение с необходимым приоритетом. Это позволит вам уменьшить объём возможных доработок конфигурации после обновления.
Рассмотрим такую настройку на примере конфигурации БухгалтерияПредприятия, в которую я внёс следующие изменения:
- В общий модуль "РегламентированнаяОтчётность" добавил новую процедуру с именем "Тест".
- Доработал форму элемента справочника "Валюты".
Заходим в конфигуратор и из меню выбираем "Конфигурация"-"Поддержка"-"Настройка поддержки. ":
В открывшемся окне нажимаем кнопку "Сравнить, объединить" (внимание, наша задача только сравнить и сохранить настройки, реального объединения мы выполнять не будем):
В окне сравнения должны появится наши доработки (при условии, что конфигурация до этого обновлялась корректно и версия основной конфигурации соответствует версии конфигурации поставщика):
Теперь отмечаем галками нужные нам объекты и настраиваем справа режим их объединения:
Внимание. Если среди предложенных вариантов нет нужного режиме объединения - прочитайте про специальный случай ниже.
После этого на панели выбираем "Действия"-"Сохранить настройки в файл как. ":
Сохраняем настройки в любой файл и закрываем конфигуратор, не продолжая объединения.
Открываем получившийся файл с настройками, нас интересует секция, которая начинается с тега <Objects> и заканчивается </Objects>. Это и есть нужные нам настройки объединения для выбранных нами объектов.
Копируем эту секцию в буфер обмена:
Далее заходим в свойства базы в обновляторе, закладка "Обновление", раздел "Сам процесс".
Устанавливаем здесь опцию "необходимо выполнять обновление с приоритетом новой конфигурации. " и тут же нажимаем ссылку "Настройки объединения. ":
В открывшемся окне вставляем содержимое буфера обмена (секцию Objects из файла с настройками):
Сохраняем все настройки и выполняем обновление конфигурации на 1 релиз:
Видим, что в этом обновлении был изменен общий модуль РегламентированнаяОтчетность, в который у нас добавлена процедура Тест.
Но благодаря нашим настройкам произошло не замещение, а именно объединение модулей, поэтому процедура Тест будет на месте после обновления:
Специальный случай (c2)
Но что если мы изменили объекты конфигурации, для которых операция объединения не имеет смысла.
Например, мы увеличили длину номера документа:
В этом случае, как вы видите, есть только один вариант объединения: "Взять из конфигурации поставщика".
Очевидно, что это не то, что нам нужно. Мы хотим, чтобы этот реквизит остался без изменений. Как этого добиться?
В таких случаях нужно выбрать "Взять из конфигурации поставщика", а затем в настройках.
. изменить правило объединения GetFromSecondConfiguration на DoNotMerge вот так:
Тогда наш измененный реквизит вообще не будет никак меняться при объединении.
Как настроить финальное объединение с эталонной конфигурацией
Чтобы стало понятнее о чём речь, приведу рабочий пример у одного из пользователей обновлятора.
У него 40 бухгалтерских баз. Все они содержат одну и ту же доработанную конфигурацию.
Обновлять приходится зачастую на несколько релизов и он для максимальной корректности делает это всегда последовательно с выполнением обработчиков обновления после каждого релиза.
Алгоритм работы до автоматизации у него был такой:
"В ручном режиме обновляю до последнего релиза одну базу; в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях. Затем обновляю остальные базы до последнего релиза и в конце объединяю с подготовленным cf файлом из первой базы."
Он обратился ко мне за помощью в автоматизации всей цепочки действий кроме "в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях".
С пакетным обновлением доработанных баз до последнего релиза обновлятор (учитывая возможность, описанную выше) справляется на ура, но вот объединять конфигурацию с подготовленным cf в пакетном режиме обновлятор не умел.
И я доработал эту возможность.
Чтобы заставить обновлятор после применения обновления следом выполнить ещё и объединение с конфигурацией из файла - необходимо расположить файл с конфигурацией для объединения в папку обновления под именем MergeThisFileAfterUpdate.cf
В рассмотренном выше примере предположим, что требуется обновить все 40 конфигураций на следующие релизы (и пусть они для упрощения задачи будут ключевыми, то есть их нельзя перескакивать): 2.0.60.1, 2.0.60.2 и 2.0.60.3.
Алгоритм наших действий с учётом автоматизации обновлятором будет следующим:
- Обновить при помощи обновлятора одну из конфигураций до версии 2.0.60.3
- Добавить все изменения, которые были потеряны. проверить работоспособность обновлённой конфигурации.
- Выгрузить эту конфигурацию в папку с обновлением 2.0.60.3 под именем MergeThisFileAfterUpdate.cf
- Запустить обновление (с включенной возможностью обновления доработанных конфигураций) оставшихся 39 баз.
- Обновлятор в этом случае для каждой из 39 баз:
- выполнит пакетное обновление на 2.0.60.1
- выполнит обработчики обновления
- выполнит пакетное обновление на 2.0.60.2
- выполнит обработчики обновления
- выполнит пакетное обновление на 2.0.60.3
- обнаружит, что в папке с обновлением 2.0.60.3 лежит файл MergeThisFileAfterUpdate.cf
- выполнит пакетное объединение нашей конфигурации с конфигурацией из файла MergeThisFileAfterUpdate.cf (о настройках такого объединения смотрите ниже)
- выполнит обработчики обновления
При этом пакетное объединение выполняется через пакетный ключик конфигуратора mergecfg и следующий файл настроек (передаётся через ключ settings):
Такие настройки объединения позволяют нам привести нашу конфигурацию (которая всё ещё на поддержке) к конфигурации в файле MergeThisFileAfterUpdate.cf, в которую мы внесли и исправили все наши доработки.
Объединение с эталонной конфигурацией как отдельная операция
Предположим, что нам требуется выполнить массовое объединение конфигураций наших баз, чтобы внести в них доработанный функционал.
Эта возможность доступна на закладке "Скрипты" в главном окне программы.
Тип скрипта "Пакетный". Из меню следует выбрать пункт "Обновлятор"->"Методы"->"Объединить с конфигурацией из файла":
В скрипт вставится вот такой текст:
Путь к файлу, с которым нужно выполнить автоматическое объединение, у вас, конечно, будет свой.
А чтобы сразу после изменения конфигураций выполнить обновление конфигураций баз данных, допишем этот скрипт следующим образом:
Получается, что в начале мы выполняем объединение конфигураций при помощи команды обновлятора merge_cfg, а затем выполняем обновление конфигураций баз данных при помощи пакетного ключика конфигуратора UpdateDBCfg.
Вторую команду можно вставить в скрипт из меню шаблонов:
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Многие слушатели с удивлением обнаруживают, что в рамках курса Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки в том числе рассматриваются и вопросы обновления типовых и нетиповых конфигураций. В Мастер-группе всегда можно задать любой вопрос по этой теме. Тренер оперативно ответит и, если нужно, поделится своими практическими наработками и идеями!
Вопрос:
В конфигурации включена возможность вносить изменения. Но замок снят не со всех объектов метаданных, а только с тех, которые нужно было доработать. При обновлении в режиме «Показывать только дважды измененные свойства» отображаются объекты, на которых стоит замок и в которые изменения не вносились. Например, обновление БП, общая форма НалогиИОтчеты. Скрин прикладываю. Почему это происходит?![НалогиИОтчеты]()
(нажмите, чтобы увеличить картинку)
Ответ:
Добрый день! Точной причины я, к сожалению, не назову. Предположение – особенность механизмов внутри самой платформы. На практике периодически сталкиваюсь с таким поведением в клиентских базах – в дважды измененные попадают объекты, которые точно не изменялись. Часто такие отличия появляются в справочной информации объектов. Справочная информация и форматированные строки базируются на HTML. Похоже, что разные версии платформы по-разному работают с этими данными. Если открыть справку проблемных объектов и посмотреть ее текст, то различия могут быть в html-теге META.
На партнерском форуме есть ветки, посвященные такому поведению системы. Сообщаются следующие ответы службы поддержки:
Ошибка механизма сравнения-объединения в части справочной информации – по мнению отдела разработки, различие в справочной информации ошибкой не является – следствие использования Internet Explorer, установленного в системе.
Сейчас эта ошибка опубликована со статусом Отклонена.
Также ранее платформа работала с HTML через Internet Explorer, сейчас в платформе перешли на библиотеку WebKit. Возможно, из-за этого появились еще какие-то нюансы. Потому что даже на актуальных версиях платформы встречается такое же поведение.
Также подобные отличия наблюдаются в форматированных строках. Предполагаю, тоже потому что форматированные строки базируются на HTML, как написано выше. Возможно, в Вашем случае как раз форматированные строки на форме стали отличаться.
Могу порекомендовать посмотреть, что показывает отчет о сравнении для этой общей формы. Если, конечно, он покажет, что именно “изменилось”.
Еще могу предложить выгрузить основную конфигурацию и новую конфигурацию в XML-файлы, найти файлы для этой общей формы и сравнить их. Возможно, при таком сравнении выясните, что же конкретно изменилось.
Инструкция расскажет, как по шагам обновить нетиповую конфигурацию 1С.
Для обновления нетиповой (измененной) конфигурации необходимо подготовить следующие файлы:
- исходная измененная конфигурация (рабочая);
- типовая конфигурация версии до обновления (старая);
- типовая конфигурация новой версии (новая) или файл(ы) .cfu для перехода на нее.
Технология обновление на примере нетиповой конфигурации УПП с 1.3.95.1 до 1.3.97.3
1. Создать пустую базу и загрузить туда рабочую конфигурацию: «Конфигурация>Загрузить конфигурацию из файла»:
![]()
На вопрос об обновлении нажать «Да»:
![]()
В окне реорганизации нажать «Принять»:
![]()
2. Проверить, стоит ли конфигурация на поддержке: «Конфигурация>Поддержка>Настройка поддержки»:
![]()
В появившемся окне отобразится информация о том, на какой поддержке (или поддержках) стоит конфигурация.
![]()
Если поддержек несколько, можно переключаться между ними, используя список выбора.
Необходимо проверить, что среди поддержек есть та конфигурация, которую необходимо будет обновить (в данном случае «УправлениеПроизводственнымПредприятием») и у нее правильная версия (в данном случае «1.3.95.1»). Нужную версию можно узнать, нажав кнопку «О программе».
Если в списке поддержек нет нужной конфигурации, то нужно поставить конфигурацию на поддержку старой типовой и затем перейти к п.3.
Если найдена поддержка нужной конфигурации, но неправильной версии, нужно нажать «Снять с поддержки», затем «Да», поставить конфигурацию на поддержкустарой типовой и перейти к п.3.
Если найдена поддержка нужной конфигурации и нужной версии, то нужно дважды кликнуть на правую колонку корня конфигурации, в появившемся окне выбрать «Объект редактируется с сохранением поддержки», поставить галочку «Установить для подчиненных объектов» и нажать «ОК». После этого можно закрыть окно настройки поддержки.
![]()
![]()
3. Когда конфигурация стоит на поддержке правильной версии, можно приступать к обновлению. Для этого нужно выбрать «Конфигурация>Поддержка>Обновить конфигурацию»:
![]()
В появившемся окне нужно переключиться на «Выбор файла обновления» и нажать «Далее».
![]()
![]()
Далее появится окно с информацией о версиях, в нем просто нажать «ОК». Если вместо этого появилось окно с текстом «Файл не содержит доступных обновлений», значит, была допущена ошибка либо при постановке на поддержку (см. п.2), либо при выборе файла обновления.
После этих действий начнется процесс сравнения конфигураций, который может занять длительное время.
4. По окончании процесса сравнения отобразится окно с деревом объектов. В нем необходимо переключиться на режим отображения только дважды измененных объектов. На платформе ниже 8.3.8 для этого необходимо нажать кнопку «Фильтр», в нижней части окна поставить галочку «Показывать только дважды измененные свойства» и затем нажать «ОК».
![]()
![]()
На платформе 8.3.8 и выше нужно в нижней части окна переключить фильтр на «Показывать только дважды измененные свойства»:
![]()
После применения фильтра в дереве останутся только те объекты, которые изменены и в рабочей конфигурации, и в новой типовой, по сравнению со старой типовой.
Если таких объектов нет, то обновление значительно упрощается. В этом случае можно перейти к следующему пункту.
Если объекты есть, то нужно сохранить их список куда-нибудь, т.к. в будущем он пригодится. Для сохранения можно использовать текстовый файл или любой другой способ.
Пример. Дерево после применения фильтра выглядит следующим образом:
![]()
В этом случае список объектов, который нужно сохранить, будет такой:
- Подсистема РегламентированнаяОтчетность – состав
- Общий модуль УправлениеЗапасамиПартионныйУчет
- Общий модуль УчетНДС
- Обработка КлиентБанк – модуль объекта
Формат списка может быть произвольным, главное, чтобы он оставался понятным.
5. Нажать кнопку «Выполнить».
Если отобразится окно «Неразрешимые ссылки», то в нем нужно нажать «Продолжить».
Если были дважды измененные объекты, то появится предупреждение об их замещении. На него нужно ответить «Да».
![]()
Далее появится окно настройки поддержки. В нем нужно установить такие настройки:
![]()
6. Данный пункт имеет смысл, только если были дважды измененные объекты. Если их не было, следует перейти к следующему пункту.
В отдельном конфигураторе (можно, например, создать пустую базу) необходимо построить сравнение старой типовой и рабочей конфигураций. Для этого нужно выбрать «Конфигурация>Сравнить конфигурации»:
![]()
В появившемся окне выбрать тип конфигурации «Файл» и указать пути к старой типовой (сверху) и рабочей конфигурации (снизу), затем нажать «ОК».
![]()
После построения сравнения выполнить перенос изменений в объекты, список которых был составлен в предыдущем пункте.
7. Обновление почти завершено!
Осталось только применить изменения (F7), при необходимости нажав «Принять» в окне реорганизации, и выгрузить обновленную конфигурацию: «Конфигурация>Сохранить конфигурацию в файл»:
![]()
12 статей про обновление 1С
Типовую программу 1С легко обновить самостоятельно через конфигуратор или интернет. Ещё один способ — использовать cfu-файл. Если пропущено много релизов, вам сэкономят время промежуточные конфигурации.
После обновления не забывайте запустить особые процедуры.
Бывает выгоднее отдать обновление нетиповой 1С на аутсорсинг.
Что нового для вашей 1С?
Оперативная информация о выходе и содержании свежих для 24 типов конфигураций.Рассылка осуществляется в день выхода обновления. Никакой рекламы, только полезная информация. Посмотрите пример →
В свойствах баз обновлятора (в версиях после 3 ноября 2017 года) появилась вот такая замечательная опция:
Сразу оговорюсь, что работать эта возможность будет только с платформой 1С равной или старше 8.3.8.1652. Именно начиная с этой версии 1С позволяет выполнять обновление доработанных конфигураций в пакетном режиме.
Когда она может быть полезна
Ну, например, вы регулярно обновляете одну и ту же дописанную конфигурацию и хотите облегчить себе работу.
При этом все дописки вы знаете и они у вас задокументированы.
В таком случае может быть проще и быстрее:
- Сначала обновить конфигурацию обновлятором (установив соотв. галку в свойствах базы)
- Затем посмотреть отчёт обновления в обновляторе (там будут указаны свойства,измененные дважды)
- И только после этого проверить, что все доработки на месте и вернуть те, что были утеряны (об этом смотрите ниже, где я рассказываю как работает автоматическое обновление доработанных конфигураций)
При таком способе работы вам не нужно:
- Скачивать необходимые обновления
- Открывать конфигуратор и применять эти обновления
- Ожидать пока выполнится обновление конфигурации
- Ожидать пока выполнится обновление базы данных
Вы вообще можете запланировать такое обновление на ночь, а уже утром произвести контроль и доработку, если она потребуется.
И если доработки конфигурации небольшие, то в большинстве случаев вам после обновления вообще не придётся ничего делать.
Ваше вмешательство будет нужно тогда, когда в обновлении будет изменен тот же самый объект, что изменен у вас (это и называется "измененные дважды"). И вы можете легко находить такие объекты, просматривая отчёт обновлятора:
![]()
Как работает автоматическое обновление доработанных конфигураций
Само обновление происходит при помощи того же пакетного ключика updatecfg, но при этом обновлятор дополняет эту команду специальным файлом настроек в формате xml.
Обновление происходит с приоритетом новой конфигурации, при этом:
- Если вы добавляли в конфигурацию новый объект - обновление его не затронет.
- Если вы добавляли в конфигурацию новый реквизит в уже существующий объект типовой (от поставщика) - обновление его также не затронет.
- Если вы меняли в конфигурации объект поставщика, но он не изменился в этом обновлении, то он останется как есть.
- Но, если вы меняли в конфигурации объект поставщика, и он изменился в этом обновлении, то возьмётся версия из обновления. При этом в отчёте обновлятора этот объект будет отмечен как "дважды измененный".
При этом, при настройке по умолчанию.
. обновлятор останавливается сразу после обновления конфигурации, если были обнаружены свойства, измененные дважды. Это делается для того, чтобы вы смогли сначала вернуть необходимые доработки, а уже затем запустить обновление базы данных.
Я очень надеюсь, что эта возможность позволит высвободить ещё немного часов от ручного, монотонного труда.
Как настроить финальное объединение с эталонной конфигурацией
Чтобы стало понятнее о чём речь, приведу рабочий пример у одного из пользователей обновлятора.
У него 40 бухгалтерских баз. Все они содержат одну и ту же доработанную конфигурацию.
Обновлять приходится зачастую на несколько релизов и он для максимальной корректности делает это всегда последовательно с выполнением обработчиков обновления после каждого релиза.
Алгоритм работы до автоматизации у него был такой:
"В ручном режиме обновляю до последнего релиза одну базу; в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях. Затем обновляю остальные базы до последнего релиза и в конце объединяю с подготовленным cf файлом из первой базы."
Он обратился ко мне за помощью в автоматизации всей цепочки действий кроме "в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях".
С пакетным обновлением доработанных баз до последнего релиза обновлятор (учитывая возможность, описанную выше) справляется на ура, но вот объединять конфигурацию с подготовленным cf в пакетном режиме обновлятор не умел.
И я доработал эту возможность.
Чтобы заставить обновлятор после применения обновления следом выполнить ещё и объединение с конфигурацией из файла - необходимо расположить файл с конфигурацией для объединения в папку обновления под именем MergeThisFileAfterUpdate.cf
В рассмотренном выше примере предположим, что требуется обновить все 40 конфигураций на следующие релизы (и пусть они для упрощения задачи будут ключевыми, то есть их нельзя перескакивать): 2.0.60.1, 2.0.60.2 и 2.0.60.3.
Алгоритм наших действий с учётом автоматизации обновлятором будет следующим:
- Обновить при помощи обновлятора одну из конфигураций до версии 2.0.60.3
- Добавить все изменения, которые были потеряны. проверить работоспособность обновлённой конфигурации.
- Выгрузить эту конфигурацию в папку с обновлением 2.0.60.3 под именем MergeThisFileAfterUpdate.cf
- Запустить обновление (с включенной возможностью обновления доработанных конфигураций) оставшихся 39 баз.
- Обновлятор в этом случае для каждой из 39 баз:
- выполнит пакетное обновление на 2.0.60.1
- выполнит обработчики обновления
- выполнит пакетное обновление на 2.0.60.2
- выполнит обработчики обновления
- выполнит пакетное обновление на 2.0.60.3
- обнаружит, что в папке с обновлением 2.0.60.3 лежит файл MergeThisFileAfterUpdate.cf
- выполнит пакетное объединение нашей конфигурации с конфигурацией из файла MergeThisFileAfterUpdate.cf (о настройках такого объединения смотрите ниже)
- выполнит обработчики обновления
При этом пакетное объединение выполняется через пакетный ключик конфигуратора mergecfg и следующий файл настроек (передаётся через ключ settings):
Такие настройки объединения позволяют нам привести нашу конфигурацию (которая всё ещё на поддержке) к конфигурации в файле MergeThisFileAfterUpdate.cf, в которую мы внесли и исправили все наши доработки.
Объединение с эталонной конфигурацией как отдельная операция
Предположим, что нам требуется выполнить массовое объединение конфигураций наших баз, чтобы внести в них доработанный функционал.
Эта возможность доступна на закладке "Скрипты" в главном окне программы.
Тип скрипта "Пакетный". Из меню следует выбрать пункт "Обновлятор"->"Методы"->"Объединить с конфигурацией из файла":
В скрипт вставится вот такой текст:
Путь к файлу, с которым нужно выполнить автоматическое объединение, у вас, конечно, будет свой.
А чтобы сразу после изменения конфигураций выполнить обновление конфигураций баз данных, допишем этот скрипт следующим образом:
Получается, что в начале мы выполняем объединение конфигураций при помощи команды обновлятора merge_cfg, а затем выполняем обновление конфигураций баз данных при помощи пакетного ключика конфигуратора UpdateDBCfg.
Вторую команду можно вставить в скрипт из меню шаблонов:
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Читайте также:
