1с привязать ошибку к полю
Эта статья продолжает цикл статей «Первые шаги в разработке на 1С». В ней на практических примерах рассматривается механизм предопределенных данных, в т.ч. и в распределенной информационной базе.
Применимость
В статье рассматривается платформа 1С:Предприятие версии 8.3.4.465. Материал актуален и для текущих релизов платформы.
Предопределенные элементы в «1С:Предприятие 8.3»
При реализации алгоритмов разработчики часто опираются на определенные данные – элементы справочников, планов счетов, планов видов расчета и т.д.
Во встроенном языке существуют методы для поиска данных, например, НайтиПоКоду() или НайтиПоНаименованию().
Однако алгоритмы, опирающиеся на код или наименование, зачастую являются ненадежными.
Поскольку в пользовательском режиме код или наименование элемента справочника могут быть изменены, что может привести к неработоспособности алгоритмов.
Именно для решения этой проблемы и предназначены предопределенные данные – данные, созданные в конфигураторе, обратиться к которым возможно по имени, не прибегая к предварительному поиску элемента.
Таким образом, у предопределенных данных есть две “стороны”: во-первых, существует список предопределенных элементов, созданный в конфигураторе, а, во-вторых, для данных информационной базы указывается, является ли конкретный элемент предопределенным.
Предопределенные элементы могут быть созданы у:
- справочников;
- планов счетов;
- планов видов характеристик;
- планов видов расчета.
В статье рассмотрены новшества, касающиеся предопределенных данных на платформе 8.3, а также особенности работы с ними в распределенных базах (как центральных, так и периферийных) и в информационных базах в режиме разделения данных.
Для примера, создадим в справочнике Организации предопределенный элемент ОсновнаяОрганизация:
Для увеличения нажмите на изображение.
Обращение к этому элементу из программного кода будет следующим:
В платформе 8.3 реализована возможность связать предопределенные данные с элементами соответствующего типа.
Для этого у объектов, которые могут иметь предопределенные элементы (они указаны выше), добавлено новое свойство ИмяПредопределенныхДанных. Оно отображается в списке стандартных реквизитов:
Выберем при помощи запроса все поля из справочника Организации:
Для увеличения нажмите на изображение.
На рисунке видно, что в поле ИмяПредопределенныхДанных указан именно тот идентификатор, который мы ввели в режиме конфигуратора.
Предопределенный элемент в списке отображается специальной пиктограммой:
Чтобы “отсоединить” элемент данных от элемента предопределенных данных, нужно присвоить свойству ИмяПредопределенныхДанных пустую строку и записать элемент:
Пиктограмма в списке изменилась:
Теперь предопределенный элемент существует только в конфигурации и в данных нет элемента, привязанного к идентификатору ОсновнаяОрганизация:
Для увеличения нажмите на изображение.
Обращение из программного кода к предопределенному элементу вызовет исключение:
Чтобы связать предопределенный элемент с новой записью, нужно присвоить свойству ИмяПредопределенныхДанных имя предопределенного элемента:
1с доработали адреса в формате фиас и понеслось.
После обновления на УПП 166.2 возникло несколько проблем с заполнением адресов.
1. В контрагенте при сохранении адреса выдается ошибка, когда пытаешься установить номер квартиры, а слово Квартира не выбирается..
ОбщийМодуль.УправлениеКонтактнойИнформациейСлужебный.Модуль(225)>: Ошибка при вызове метода контекста (ЗаписатьJSON)
ЗаписатьJSON(ЗаписьJSON, Значение,, "АдаптацияПолейКонтактнойИнформации", УправлениеКонтактнойИнформациейСлужебный);
по причине:
Передано значение недопустимого типа
2. В документе больничного при попытке выбрать адрес мед. заведения выдается ошибка:
: Поле объекта не обнаружено (ПанельНастроекАдреса)
ФормаРедактированияАдреса.ЭлементыФормы.ПанельНастроекАдреса.Свертка = РежимСверткиЭлементаУправления.Верх;
3. При открытии Классификатора из адресной строки физ лица:
: Тип не определен (ФормаКлиентскогоПриложения)
ТипыСвойств.Вставить("ФормаВладелец", Тип("ФормаКлиентскогоПриложения"));
Даже как-то странно. такое количество ошибок, либо они вообще ничего не тестировали, просто накатили обнову и отправили людям.
У кого нибудь есть такие проблемы? Погуглил, таких ошибок не нашел.
Даже как-то странно, что человек после 8 лет общения с 1с обновляется не протестировав изменения.
где-то в 2010 на курсах в 1с Морозов утверждал, что ут почти вся покрыта тестами, а упп - вся.
но судя по кол-ву ошибок - тесты не поддерживаются и не применяются.
(1) Не поверите, но сколько не обновлялся за 20 лет косяков глобальных никогда не было, чтобы нельзя было работать. Вот чего чего, времени на глобальные тесты у меня нет, всех изменений не протестируешь. Если только у кого вагон свободного времени.
Дедушка старый, ему все равно. УПП, судя по всему, совсем не в приоритете у 1С, несмотря на то что они собирают по 8 штук за месячный пинкод обновлений и по 60 - за годовой.
(1) да в общем-то и я действую также. Чтобы тестировать - время надо и людей. Если в ит-отделе полтора человека, то заниматься этим некому. Если что-то вылезет в критичном функционале - подправляем прямо наживую. Что характерно, уже 10 годков существуем в таком режиме и ничего. Но у нас и готовность 24 часа в сутки не нужна, оттого что база будет недоступна, скажем, час - ничего не поменяется. Свет вырубают чаще и на-дольше, чем происходят сбои в ИТ.
Статья продолжает цикл статей «Первые шаги в разработке на 1С».
В ней мы рассмотрим способы информирования пользователя, которые присутствуют в платформе «1С:Предприятие» 8, а также акцентируем ваше внимание на некоторых особенностях работы этих механизмов, эти особенности связаны с режимом использования модальности.
Применимость
В статье рассматривается функциональность:
- Интерфейса в варианте «Версии 8.2» для конфигурации, разработанной на платформе «1С:Предприятие» 8.2.19.130
- Интерфейса «Такси» для конфигурации, разработанной на платформе «1С:Предприятие» 8.3.4.496 до 8.3.9+
- Интерфейса «Такси» для конфигурации, разработанной на платформе «1С:Предприятие» 8.3.10-8.3.11
- отражение хода выполнения текущего процесса (показ стадии выполнения процесса; показ расчетных значений, полученных в ходе работы алгоритма);
- выдача ошибок пользователю для возможного их исправления;
- выдача рекомендаций;
Т.е. первым параметром является сам текст.
В концепции управляемого интерфейса значок всегда в виде восклицательного знака, переопределить его нельзя.
Но форма моментально закрывается, и пользователь не увидит, что для него выводилась какая-то информация.
Тем не менее, функция Сообщить может использоваться для вывода информации о некоторых ошибках, например в момент проведения документа.
В этом случае системе можно сообщить, что форму закрывать не нужно, и показать пользователю, какие ошибки возникают при проведении документа.
Функция Сообщить полностью поддерживается в Платформе 8.3. Ее можно использовать, и она будет работать (и в файловом варианте, и в клиент-серверном).
Так, программный код в Платформе 8.3 может быть исполнен как на стороне Клиента, так и на стороне Сервера.
При этом клиентский программный код отвечает за взаимодействие с пользователем, т.е. на стороне клиента открываются формы, выводятся отчеты.
Различные диалоговые документы также отображаются только на клиенте. На сервере они не могут быть исполнены, поскольку сервер не имеет возможности взаимодействия с пользователями.
В этот момент система запросит данные из буфера и выведет их на экран.
Механизм оповещений
Механизм оповещений нужен, чтобы информировать пользователя о том, что в системе “что-то” произошло и это “что-то” требует внимания пользователя. Оповещения создаются двумя сценариями:
- Самой платформой при интерактивной записи или изменении объекта
- Разработчиком при вызове в коде метода ПоказатьОповещениеПользователя().
Само оповещение представляет собой небольшое окошко, которое появляется, как правило, в нижнем правом углу и сообщает о совершенном действии. В течение нескольких секунд оно постепенно гаснет и пропадает. При этом, если навести на оповещение курсор мышки, оно не гаснет и можно внимательно его прочитать.
Кроме того, к оповещениям можно обратиться в соответствующей области информационной панели (кнопка “История” слева внизу формы приложения в варианте интерфейса «Версии 8.2»).
Чтобы создавать свои собственные оповещения, необходимо использовать метод глобального контекста ПоказатьОповещениеПользователя(). Его синтаксис до редакции 8.3.10 представлен ниже:
В первом параметре передается текст, который будет выводиться в оповещении.
Также можно присвоить картинку, отображающую статус оповещения.
Следует отметить, что все эти параметры являются необязательными для заполнения. Ниже приведен пример использования данного метода (в конфигураторе и в пользовательском режиме в варианте интерфейса «Версии 8.2»).
В редакции платформы 8.3.10.216 для интерфейса в варианте «Такси» механизм оповещений был существенным образом доработан с целью повышения удобства работы как в тонком, так и в веб-клиенте. По этой причине изменились и передаваемые параметры в метод ПоказатьОповещениеПользователя(). Теперь синтаксис выглядят так:
Видно, что второй параметр, ранее называемый НавигационнаяСсылка, получил новое имя ДействиеПриНажатии. Это связано с тем, что теперь в него стало возможным передавать не только строку с навигационной ссылкой, но и описание оповещения. Это проиллюстрировано скриншотом ниже:
Как видно из примера, у нас появилась возможность программным образом обрабатывать нажатие на окно с оповещением, согласно той логике, которая необходима.
Следующий параметр СтатусОповещенияПользователя появился впервые. В нем указывается статус оповещения (Информация или Важное).
После выполнения команды получим приблизительно такой вид окна приложения:
В панели инструментов появилась кнопка с пиктограммой звонка, по которой вызывается упомянутый выше Центр оповещений. В нем накапливаются новые важные оповещения, на которые пользователь пока никак не отреагировал.
Если в Центре есть какие-то оповещения, то рядом с ним появляется маленькая оранжевая точка, чтобы привлечь внимание пользователя. Пользователь может открыть Центр оповещений, прочитать текст и, если необходимо, выполнить какие-то действия.
И наконец, последним добавленным параметром стал КлючУникальности. С его помощью можно найти отображенное на экране оповещение и изменить его. Если же оповещения с таким параметром нет, то будет показано новое оповещение.
Как видим, возможностей, предоставляемых соответствующим методом, стало еще больше! Но это не все изменения в механизме оповещений.
Как вы уже, наверное, успели заметить, изменился их внешний вид. Теперь оповещения выглядят более современно и эргономично, но их нельзя перемещать по экрану и изменять их размер. Обратите внимание, в нашем примере, текст оповещения попросту не поместился целиком в самом окне, и прочитать его полностью пользователь сможет, только открыв Центр Оповещений. Поэтому не стоит в текст оповещения писать большое количество текста.
Также к новым возможностям относится и одновременное отображение на экране до трех оповещений.
На этом завершим наше знакомство с программным формированием оповещений. Однако вспомним, что оповещения формируются не только разработчиком программно, но и самой платформой в момент интерактивной записи или изменения объекта. И часто этот факт вызывает непонимание в первую очередь у начинающих пользователей: зачем нужны эти служебные оповещения, которые, кстати, нельзя отключить?
Давайте представим такую простую ситуацию: пользователь установил фильтр в каком-то списке для удобства. Допустим, он сделал это в форме списка справочника Номенклатуры. Потом, через какое-то время, решил ввести новый элемент с наименованием “Стул”, который не соответствует установленному ранее фильтру. Вводит его, записывает и…? И не видит его в списке. Что будет делать среднестатистический пользователь? Конечно, введет его второй раз, но опять не увидит. Дальше может последовать третий, четвертый, пятый раз. Когда ему надоест вводить одно и тоже, он, наконец, спросит у вас: а куда все пропадает?
Вот именно поэтому платформа и отображает эти служебные оповещения, информируя пользователя о том, что его действие выполнено. В нашем примере в момент интерактивной записи пользователь увидит следующее оповещение:
Выведем какое-нибудь предупреждение с помощью строки (например, в модуле управляемого приложения):
Предупреждение(“Сейчас будет открыта база”);
Чтобы открыть модуль управляемого приложения, следует в дереве конфигурации выбрать объект Конфигурация, вызвать контекстное меню и выбрать пункт Открыть модуль управляемого приложения.
В данном случае, при запуске приложения, будет выводиться окно, которое является модальным. Модальное окно перекрывает собой все окна, которые существуют в приложении. Пока мы не обработаем это окно, дальнейшие действия невозможны.
Аналогичным образом работает и функция Вопрос.
Обязательными являются только первые два параметра. Для второго параметра тип данных составной (РежимДиалогаВопрос или СписокЗначений). Третий параметр ( ) характеризует интервал времени в секундах, в течение которого система будет ожидать ответа пользователя.
По истечении интервала окно вопроса будет закрыто. Аналогичный параметр( ) есть и у функции Предупреждение.
В качестве примера использования функции Вопрос можно использовать следующий код, записанный в модуле управляемого приложения:
Обращаю Ваше внимание, что данные методы (Предупреждение и Вопрос) не доступны на Сервере. И это логично, потому что интерфейсные методы не могут быть выполнены на Сервере, где нет пользователя.
Особенности использования модальных окон в Платформе 8.3
В платформе 8.3 существуют режимы работы с использованием и без использования модальности. По умолчанию стоит настройка Не использовать режим модальности.
Модальное окно выводится на самый верх и блокирует работу с другими окнами до завершения действий с модальным окном. Кроме того, останавливается выполнение программного кода на том месте, где происходит вызов этого окна. Выполнение кода продолжится только после закрытия модального окна.
Во-первых, проблемы по использованию модальных окон возникают для мобильного приложения. Во-вторых, в браузере модальность окон реализуется с помощью отдельных всплывающих окон.
В настройках браузера по умолчанию всплывающие окна зачастую запрещены. Пользователя приходится заставлять устанавливать разрешение на эти окна.
Браузеры для планшетных компьютеров и для телефонов в большинстве случаев вообще не поддерживают всплывающие окна.
Для замены функций Вопрос и Предупреждение разработаны новые методы: ПоказатьВопрос, ПоказатьПредупреждение.
Эти методы позволяют вызывать окно, но не останавливать выполнение программного кода. Технически это реализуется формированием псевдоокна внутри родительского окна. Псевдоокно не перекрывает родительское окно. После открытия такого окна код продолжает выполняться.
Получение и обработка введенных пользователем значений осуществляется в отдельной процедуре, которая вызывается при закрытии диалогового окна.
Синтаксис функции ПоказатьПредупреждение:
Тип данных: ОписаниеОповещения.
Содержит описание процедуры, которая будет вызвана после закрытия окна предупреждения.
Синтаксис функции ПоказатьВопрос:
Обязательными являются первые три параметра.
Ниже приведен пример использования функции.
Таким образом мы создаем экземпляр данного объекта.
Внимание! Для привязки к нужному полю формы обратите внимание на инициализацию свойств ПутьКДанным и КлючДанных. Применительно для документа при размещении кода в модуле объекта можно писать:
Чтобы открыть модуль документа, следует в окне редактирования объекта (документа) на закладке Прочее нажать на кнопку Модуль объекта.
Для эксперимента в модуле объекта какого-либо документа разместим код.
Ниже представлен полученный в пользовательском режиме результат для Платформы 8.3.
Соответственно, в момент обнаружения ошибок отменяется транзакция, т.е. запрещается запись элемента справочника, либо запрещается проведение документа.
Уведомление о состоянии процесса
Существует специальная функция, с помощью которой можно отображать примерный ход выполнения какого-либо процесса.
Синтаксис: Состояние(, , , )
Параметры: и – не обязательные, тип – Строка.
Текст выводится на специальную панель состояния.
параметр тоже необязательный, но наглядный.
Тип: Число. Значение индикатора прогресса (от 1 до 100).
тоже необязательный параметр.
При обработке какого-либо события могут использоваться периодические вызовы функции типа:
При этом могут меняться надписи, а могут изменяться значения параметра Прогресс.
Функция может вызываться как из одной процедуры (функции), так и из нескольких. Таким образом можно отслеживать состояние выполнения процесса.
Если вы хотите ознакомиться с механизмом уведомления более подробно, то прямо сейчас прервитесь и прочтите нашу новую статью Отображение прогресса длительных операций в 8.3.10. В ней уже не на уровне новичка объясняются все тонкости и подводные камни работы этого механизма.
Мы же завершаем знакомство со способами информирования пользователя. Надеемся, что у вас сложилось понимание, в каких ситуациях следует применять тот или иной способ.
Хочется еще раз акцентировать ваше внимание на том факте, что если ваша конфигурация (версии 8.3.3+) предполагает работу с помощью веб-клиента, то:
- на уровне конфигурации должна быть установлена настройка режима модальности «Не использовать»
- в коде должны использоваться методы асинхронной модели взаимодействия с пользователем. Такие методы начинаются со слов Показать или Начать.
Более подробно об отказе от использования модальных окон в платформе 1С:Предприятие 8.3 можно почитать в финальной статье цикла. А мы идем дальше и, наконец, приступаем к изучению долгожданного интерфейса «Такси», который уже не раз упоминался в наших материалах.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
Комментарии / обсуждение (16):
Доведем до логического завершения пример со справочником ФизическиеЛица. Для этого заполним справочник Районы и введем в информационную базу сведения о следующих физических лицах:
Обратите внимание на то, что справочник ФизическиеЛица – это пример справочника, с которым пользователям нашей информационной базы придется работать достаточно часто. В данный момент для того, чтобы создать новый элемент справочника, нам нужно выполнить несколько действий – перейти в раздел Расчет заработной платы, щелкнуть по ссылке, открывающей список справочника, после чего нажать на кнопку Создать новый элемент списка. Для того, чтобы сократить количество действий, необходимых для выполнения часто используемых операций, мы можем соответствующим образом настроить интерфейс нашего прикладного решения , в частности, поработать с панелью действий соответствующего раздела и с Рабочим столом.
Настройка командного интерфейса для ускорения доступа к справочнику
Добавим команду создания нового элемента справочника ФизическиеЛица в панель действий раздела Расчет заработной платы. Для этого откроем окно Все подсистемы командой контекстного меню ветви Подсистемы дерева конфигурации и установим флаг Видимость напротив команды Физические лица: Создать в области Панель действий.Создать, рис. 3.24.
Мы можем включить команду добавления нового физического лица в командный интерфейс Рабочего стола.
Для этого выполним команду контекстного меню корневого элемента конфигурации Открыть командный интерфейс рабочего стола
Выделим в поле Доступные команды команду Физические лица: создать, в поле состава командного интерфейса – команду Панель действий.Создать и нажмем на кнопку со значком ">" (Добавить команду на рабочий стол ), которая находится между полями, после чего установим флаг Видимость для добавленной команды, рис 3.25.
Теперь, рис. 3.26., команда для быстрого создания элементов справочника ФизическиеЛица добавлена в панель действий Рабочего стола, аналогичная команда появилась в разделе Расчет заработной платы.
Выводы
Механизм проверки заполнения позволяет автоматически проверить, заполнены ли указанные реквизиты объекта. Для этого нужно воспользоваться свойством ПроверкаЗаполнения , которое есть у реквизитов объектов конфигурации.
Разработчик может повлиять на стандартную проверку заполнения, выполняемую платформой. Для этого у него есть два события:
- Одно событие — ОбработкаПроверкиЗаполненияНаСервере — можно обработать в модуле формы.
- Другое событие — ОбработкаПроверкиЗаполнения — можно обработать в модуле прикладного объекта.
У формы, как правило, есть основной реквизит (редактируемый объект) и могут быть реквизиты, не относящиеся к редактируемому объекту, а являющиеся лишь частью формы:
Поэтому серверное событие формы ОбработкаПроверкиЗаполненияНаСервере предназначено для проверки заполнения тех реквизитов формы, которые не относятся к редактируемому объекту. Это данные только формы, у формы могут быть свои причины и алгоритмы для проверки этих данных.
Напротив, событие объекта ОбработкаПроверкиЗаполнения предназначено для для того, чтобы проверить реквизиты основного реквизита формы.
Обработчики обеих событий имеют параметр ПроверяемыеРеквизиты , в который платформа передает массив имен тех реквизитов, которые подлежат проверке. Если после выхода из обработчика в этом массиве все еще останутся какие-то имена реквизитов — платформа выполнит автоматическую проверку оставшися реквизитов.
Поэтому существует несколько сценариев того, как разработчик может встроить свой алгоритм в механизм проверки заполнения:
- самостоятельно проверить заполненность всех реквизитов и очистить массив ПроверяемыеРеквизиты , чтобы платформа не выполняла их проверку
- проверить часть реквизитов самостоятельно, удалить их из массива ПроверяемыеРеквизиты , а оставшиеся оставить на проверку платформе
- добавить в массив ПроверяемыеРеквизиты какие-то реквизиты, чтобы платформа проверила и их тоже
- вообще отказаться от проверки заполненности реквизитов, очистив массив
Все эти сценарии реализуются довольно просто. Например, чтобы самостоятельно проверить заполненность реквизитов, можно выполнить следующий код:
Чтобы проверить лишь часть реквизитов, можно выполнить такой код:
Добавить в массив проверяемых реквизитов еще один реквизит можно следующим образом:
А очистить массив проверяемых реквизитов, чтобы ничего не проверять ни самому, ни платформе, можно так:
Вторым параметром в обработчиках этих событий является параметр Отказ . Если ему присвоить значение Истина , то после выхода из обработчика дальнейшая запись объекта будет отменена. Таким образом этот параметр нужно устанавливать в значение Истина тогда, когда ваш алгоритм приходит к выводу, что реквизит не заполнен. В этом случае запись объекта выполнена не будет.
Справка
ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
- Отказ . Тип: Булево . Признак отказа от записи. Если в теле процедуры-обработчика установить данному параметру значение Истина , то запись выполнена не будет. Значение по умолчанию Ложь .
- ПроверяемыеРеквизиты . Тип: Массив . Массив путей к реквизитам, для которых будет выполнена проверка заполнения. Массив может быть модифицирован удалением или добавлением путей к необходимым реквизитам.
Вызывается расширением формы при необходимости проверки заполнения реквизитов при записи в форме, а также при выполнении метода ПроверитьЗаполнение() . Для вызова проверки заполнения системой необходимо, чтобы у формы (с которой происходит работа) было установлено свойство ПроверятьЗаполнениеАвтоматически . В этом случае вначале будет вызван данный обработчик, а затем обработчик ОбработкаПроверкиЗаполнения() модуля объекта.
Позволяет разработчику самостоятельно реализовать проверку заполнения в обработчике события. При этом в обработчике можно полностью отказаться от системной обработки (очистив список проверяемых реквизитов), отказаться от проверки системой части реквизитов (выполнив проверку отдельных реквизитов особенным образом и исключив эти реквизиты из списка), а также добавить для проверки другие реквизиты, проверка которых не была указана.
Для формы документа, если при конфигурировании для документа свойство Проведение установлено в Разрешить , событие вызывается только при проведении. Если документ не проводится (свойство Проведение установлено в Запретить ), то вызывается при записи.
ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
- Отказ . Тип: Булево . Если в теле процедуры-обработчика установить данному параметру значение Истина , то будет выполнен отказ от продолжения работы после выполнения проверки заполнения. Значение по умолчанию Ложь .
- ПроверяемыеРеквизиты . Тип: Массив . Массив путей к реквизитам, для которых будет выполнена проверка заполнения. Массив может быть модифицирован удалением или добавлением путей к необходимым реквизитам.
Вызывается расширением формы при необходимости проверки заполнения реквизитов при записи или при проведении документа в форме, а также при выполнении метода ПроверитьЗаполнение() . Если для документа при конфигурировании свойство Проведение установлено в Разрешить , то вызывается только при проведении. Если документ не проводится (установлено Запретить ), то вызывается при записи.
Позволяет разработчику конфигурации самостоятельно реализовать проверку заполнения в обработчике события. При этом в обработчике можно полностью отказаться от системной обработки (очистив список проверяемых реквизитов), отказаться от проверки системой части реквизитов (выполнив проверку отдельных реквизитов особенным образом и исключив эти реквизиты из списка), а также добавить для проверки другие реквизиты, проверка которых не была указана.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Читайте также: