Ошибка арифметического переполнения при преобразовании numeric 1с

   фпк1сл

31.01.16 — 21:52

Добрый день!

Конфигурация УТ 11.1.10.145, платформа 8.3.6.2237, SQL Server 2008.

При проведении документа «Расчет себестоимости товаров» за апрель, выскакивает ошибка

Ошибка при выполнении обработчика — ‘ОбработкаПроведения’

по причине:

{Документ.РасчетСебестоимостиТоваров.МодульОбъекта(2181)}: Ошибка при вызове метода контекста (ВыполнитьПакет)

        Выборка = Запрос.ВыполнитьПакет()[1].Выбрать();

по причине:

Ошибка выполнения запроса

по причине:

Ошибка при выполнении операции над данными:

Microsoft SQL Server Native Client 10.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.

HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Все  другие документы проводятся нормально. Подскажите пожалуйста, все чем может быть проблема, куда смотреть?

   фпк1сл

1 — 31.01.16 — 21:53

Я понимаю, что где-то в результате запроса получается большое число, вот только как найти, откуда это число возникает?

   cw014

2 — 01.02.16 — 07:37

Пройтись отладчиком + ТИИ

   фпк1сл

3 — 01.02.16 — 11:57

Отладчик мне ничего не покажет, программа завершается в момент Выборка = Запрос.ВыполнитьПакет()[1].Выбрать(); , значит я не узнаю, что её выбивает. В файловом варианте база тоже не запускается, размер слишком большой.

   Timon1405

4 — 01.02.16 — 12:04

обновитесь, говорят, на 11.1.10.150 проблема уходит.

   Михаил Козлов

5 — 01.02.16 — 12:14

(3) Можно попробовать в консоли удалять из пакета по 1. Или выполнять по 1.

   Карупян

6 — 01.02.16 — 12:16

профайлером (или тж) засечь запрос и посмотреть

   фпк1сл

7 — 01.02.16 — 15:21

Обновляться буду в крайнем случае, попробую в технологическом журнале посмотреть на криминал. Профайлером не имею представления как пользоваться.

   фпк1сл

8 — 02.02.16 — 16:16

Обновление не дало результатов. В ТЖ и профайлер смотрел — ничего не понял. Подскажите, может по какому нибудь регистру посмотреть какие нибудь значения подозрительные?

   mikecool

9 — 02.02.16 — 16:19

(8) первый запрос из пакета генерит не перевариваемое число — посмотри, какие там числовые поля и попытайся понять, откуда мб такое большое

   Timon1405

10 — 02.02.16 — 17:16

(8) поищите большой ресурс «ПостояннаяРазница» в регистре ВыручкаИСебестоимостьПродаж в консоли запросов

   Tateossian

11 — 02.02.16 — 18:37

(0) Скорее всего, это происходит где-то при делении, попробуй все такие места явно обработать через ВЫРАЗИТЬ( КАК ЧИСЛО(xx,yy))

   Cyberhawk

12 — 02.02.16 — 18:53

ИР тебе в помощь — там и разбивка запроса на подзапросы, и отбор ТЖ по конкретному запросу

   фпк1сл

13 — 03.02.16 — 09:26

   фпк1сл

14 — 03.02.16 — 12:58

Запрос выполняется с использованием Менеджера временных таблиц

   фпк1сл

15 — 03.02.16 — 13:02

Еще глупый вопрос, в запросе выполняется первый пакет. Как мне его найти?

   фпк1сл

16 — 05.02.16 — 09:26

я вычислил, что всему виной вот эта строчка в запросе

|    ВЫРАЗИТЬ(СУММА(ЕСТЬNULL(ВтТаблицаРешений.ПостояннаяРазница, 0) * ЕСТЬNULL(ПеремещенияСписания.Количество, 0)) КАК ЧИСЛО(23,10))

Здесь и происходит переполнение.

   Ёпрст

17 — 05.02.16 — 09:35

(16) выкини выразить оттуда

   Ёпрст

18 — 05.02.16 — 09:35

и спи спокойно дальше

   фпк1сл

19 — 05.02.16 — 09:42

(17) Не помогло, все та же ошибка преобразования numeric.

Что интересно, только за апрель документ выжучивается, следующий месяц проводится без проблем.

   Ёпрст

20 — 05.02.16 — 09:43

ну поставь  КАК ЧИСЛО(15,0)

   фпк1сл

21 — 05.02.16 — 09:53

(20) Все так же упрямо выскакивает эта ошибка.

   НЕА123

22 — 05.02.16 — 10:00

   НЕА123

23 — 05.02.16 — 10:03

вообще, ИМХО, ВЫРАЗИТЬ в Сумма засунуть.

   Tateossian

24 — 05.02.16 — 10:09

(16) Выведи в отладке содержимое ВтТаблицаРешений в ТЗ и посмотри, что там за числа.

   фпк1сл

25 — 05.02.16 — 10:53

(23) выразил, снова ошибка. (24)  Глазами пробежался по 12к строк, на первый взгляд никакого криминала. Попробую покромсать запрос и выполнять по частям.

   фпк1сл

26 — 05.02.16 — 13:11

Получается, что «ВтТаблицаРешений.ПостояннаяРазница» и «ПеремещенияСписания.Количество» имеют значение Null.

И если подставить, то получается, что выражение

ВЫРАЗИТЬ(СУММА(0 * 0) КАК ЧИСЛО(23,10)) — вызывает арифметическое переполнение.

   фпк1сл

27 — 05.02.16 — 13:50

Был неправ, зайдя дальше обнаружил, что умножение «ВтТаблицаРешений.ПостояннаяРазница» и «ПеремещенияСписания.Количество» на какой то итерации дает переполнение, буду двигаться дальше.

   фпк1сл

28 — 09.02.16 — 15:52

При проведении документа «Расчет себестоимости» формируются записи регистра накопления «Себестоимость товаров». Так вот за 2014 год все формировалось нормально, а с 2015 в колонке «Стоимость (ПР)» — постоянная разница, только по 2-3 номенклатурам начали появляться и расти огромные числа. Подскажите, из-за чего растет постоянная разница строго по 2 позициям номенклатуры?

Пример. Одна организация, два склада.

Документ перемещения формирует две записи в регистре накопления — Количество(10) по двум складам.

Документ Расчет себестоимости товаров формирует одну запись — Стоимость(ПР) : 134 046 229,30.   Откуда такая цифра? Причем некоторые записи идут корректно, в чем разница, так и не понял.

Опубликовано: 21.02.2018 /

В рамках проекта перехода с Управление торговлей 11.1 на Комплексная автоматизация 2.2 возникли с одной проблемой. Суть в следующем. Сам переход подразумевает обновление УТ на КА (как базовую бухгалтерию на проф) — никаких трудностей. Но перед переходом необходимо в УТ рассчитать себестоимость и закрыть месяца. У нас было обновление на 10 релизов примерно, после чего я и попытался сделать закрытие месяц. Вот тут и появилась ошибка:

1. При выполнении расчета возникла ошибка:
{ОбщийМодуль.УниверсальныеМеханизмыПартийИСебестоимости.Модуль(2043)}:
Ошибка при вызове метода контекста (Выполнить)
Выборка = Запрос.Выполнить().Выбрать();
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
Microsoft SQL Server Native Client 10.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

С этого момента начался поиск решения проблемы. Что было проверено:

• последняя платформа 1С
• последний релиз конфигурации 1С
• полное ТиИ (и отдельно пересчет итогов)
• checkdb в ms sql server

Также был найден запрос, на котором была ошибка, и запросе, было исправлено выражение ВЫРАЗИТЬ(15,3) на ВЫРАЗИТЬ(25,3) — или что-то подобное. Такой способ рекомендуют во многих местах в сети (в том числе и на infostart). Но он тоже мне не помог. 

После я решил, что нужно все понять причину, ведь не может появиться ошибка просто так.

И проанализировал регистр «ВыручкаИСебестоимостьПродаж«. И ужаснулся — в полях себестоимости были миллиарды.

Тут я понял, что проблему нужно решать с другой стороны! После чего и начал искать с чего все началось — с каких документов. Где-то исправлял ошибки, где-то просто перепроводил документы и потом закрывал месяц. И все получилось. И самый правильный залог успеха — отсутствие отрицательных остатков!

Позже выложу обработку, которая упрощает механизм поиска и исправления данных ошибок.

<?php // Полная загрузка сервисных книжек, создан 2023-01-05 12:44:55
global $wpdb2;

global $failure;

global $file_hist;



/////  echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;

//подключаемся к базе

$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL

// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке

if (!empty($wpdb2->error))

{

/////   echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';

$failure=TRUE;

wp_die( $wpdb2->error );

}
$m_size_file=0;

$m_mtime_file=0;

$m_comment='';

/////проверка существования файлов выгрузки из 1С

////файл выгрузки сервисных книжек

$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';

if (!file_exists($file_hist))

{

/////   echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';

$m_comment='Файл обмена с сервисными книжками не существует';

$failure=TRUE;

}



  


                       
  




/////инициируем таблицу лога

/////если не существует файла то возврат и ничего не делаем

if ($failure){

///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']

/////   echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));

wp_die();

/////    echo '<H2><b>Возврат в начало.</b></H2><br>';

return $failure;

}

/////проверка лога загрузки, что бы не загружать тоже самое

$masiv_data_file=stat($file_hist);   ////передаем в массив свойство файла

$m_size_file=$masiv_data_file[7];    ////получаем размер файла

$m_mtime_file=$masiv_data_file[9];   ////получаем дату модификации файла

////создаем запрос на получение последней удачной загрузки

////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
/////   echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';

/////   echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';

/////   echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';

////препарируем запрос

$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);

$results=$wpdb2->get_results($text_zaprosa);
if ($results)

{   foreach ( $results as $r)

{

////если штамп времени и размер файла совпадают, возврат

if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))

{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));

wp_die();

return $failure;

}

}

}

////если данные новые, пишем в лог запись о начале загрузки

/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));



////очищаем таблицу

$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');

$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);

$results=$wpdb2->query($clear_tbl_zap_repl);

/////   echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';

if (empty($results))

{

/////   echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';

//// если очистка не удалась, возврат

$failure=TRUE;

wp_die();

return $failure;

}
////загружаем данные

$table='vin_history';         // Имя таблицы для импорта

//$file_hist Имя CSV файла, откуда берется информация     // (путь от корня web-сервера)

$delim=';';          // Разделитель полей в CSV файле

$enclosed='"';      // Кавычки для содержимого полей

$escaped='


      
Related Posts
  
      
      
        

	       
Получение логина и пароля техподдержки 1С из базы
	       
Класс для вывода отчета в Excel
	       
Счет-фактура для УПП
	       
Библиотека классов для создания внешней компоненты 1С на C#
	       
Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
	       
Прайс-лист с артикулом в отдельной колонке
        
      







	    
22 Comments

		

				

		

				
Плюсану, поскольку сталкивался и лечил такие проблемы в самопальных складских программах.
			 
Reply ↓			
			   			
	
	

		

				
В данном случае помогло, но это не факт, что всегда поможет.

Проблема может быть не только с длиной целой части, но и длиной дробной части.
Суть ошибки в том, что во время вычисления — SQL не может преобразовать тип внутри вычисления как правило умножения или деления. Решается не обязательно увеличением разрядности, достаточно ВЫРАЗИТЬ( Значение , ХХ,ХХ) использовать для всех вычисляемых аргументов в том числе внутри скобок. Тогда SQL не занимается самодеятельностью по выбору типа внутри самого вычисления и ошибка не происходит.



  


                       
  






 ВЫРАЗИТЬ(СУММА(ЕСТЬNULL(ВтТаблицаРешений.ПостояннаяРазница, 0) * ЕСТЬNULL(ПеремещенияСписания.Количество, 0)) КАК ЧИСЛО(23, 10)))


Будет


ВЫРАЗИТЬ
СУММА(ВЫРАЗИТЬ ЕСТЬNULL(ПеремещенияСписания.Количество, 0) КАК ЧИСЛО(23, 10) *
ВЫРАЗИТЬ ЕСТЬNULL(ПеремещенияСписания.Количество, 0) КАК ЧИСЛО(23, 10) )
КАК ЧИСЛО(23, 10)

Reply ↓			




При таких расчетах могут накапливаться и ошибки округления дробной части, здесь это нивелируется десятью знаками после запятой ЧИСЛО(…, 10). Попутно может всплыть проблема сравнения итогов с нулём или константой, так как из-за накопления ошибок округления дробной части выглядеть она будет как -0.0001 < x <0,0001
Reply ↓			





Коллеги прошу помощи.

Увеличение разрядности не помогло.

Ошибка осталась. Кто может помочь?


Ошибка при выполнении обработчика — ‘ОбработкаПроведения’

по причине:

{ОбщийМодуль.КорректировкаСтоимостиУчетЗатрат.Модуль(403)}: Ошибка при вызове метода контекста (Выполнить)



  


                       
  





 Док.Записать(РежимЗаписиДокумента.Проведение);

по причине:

Ошибка выполнения запроса

по причине:

Ошибка при выполнении операции над данными:

Microsoft SQL Server Native Client 11.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.

HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Код такой:


СУММА(ВЫРАЗИТЬ(
|  ВЫБОР КОГДА УчетЗатрат.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход) ТОГДА
|   УчетЗатрат.Стоимость
|  ИНАЧЕ
|   0
|  КОНЕЦ
| КАК ЧИСЛО(38,10))) КАК Стоимость

Reply ↓			




(5) Какая конфигурация?



  


                       
  




Reply ↓			




Какая конфигурация?
Reply ↓			




Управление производственным предприятием, редакция 1.3 (1.3.89.2)
Если есть возможность помочь для более оперативного общения контакты на почту прислать?  У меня каждый день на счету.
Reply ↓			




А если попробовать поменять


| КАК ЧИСЛО(38,10))) КАК Стоимость

на


| КАК ЧИСЛО(32,10))) КАК Стоимость

Reply ↓			





(9) читаем статью, «не хватает знаков ДО запятой», метод решения:



  


                       
  





Если есть строчки ВЫРАЗИТЬ(<ВыбранноеПоле> КАК ЧИСЛО (23,10))  изменяем их на ВЫРАЗИТЬ(<ВыбранноеПоле> КАК ЧИСЛО (25,10)) и радуемся результату.

Читаем (9) и понимаем, что уменьшение знаков до запятой не поможет…
Reply ↓			




У меня такая же ситуация, только последняя УТ 11.3.3.231 я уже 2 месяца пытаюсь найти в данных проблему. пробовал увеличить разрядность, помогло на два месяца потом опять стала ошибка.
Reply ↓			




(9) Начинали с 25,10  дошли до 38,10 не помогает. ТЬочнее попробовал 40,10 ругнулась что перебор…
Reply ↓			




Проблема не решена.  Помогите кто может.
Reply ↓			




Вот и я попал. (37,10) стояло больше двух лет, сейчас не спасло. Решения нет?



  


                       
  




Reply ↓			





Теперь и я)  как перевел базу на с 11.1 на 11.3.4… даже не пойму что он там  по кругу выполняет,с каждым выполнением отклонение растет. Что это такое вообще? Кто сможет объяснить:

Дополнительная информация об этапе:

    — Отклонение на текущей итерации: 42 631,8

    — Отклонение на текущей итерации: 24 780

    — Отклонение на текущей итерации: 21 311,8

    — Отклонение на текущей итерации: 17 797,43

    — Отклонение на текущей итерации: 7 800

    — Отклонение на текущей итерации: 20 588,5568513129

    — Отклонение на текущей итерации: 20 588,556851313



  


                       
  





    — Отклонение на текущей итерации: 73 530,5601832607

    — Отклонение на текущей итерации: 73 530,5601832608

    — Отклонение на текущей итерации: 262 609,1435116457

    — Отклонение на текущей итерации: 262 609,1435116456

    — Отклонение на текущей итерации: 937 889,7982558771

    — Отклонение на текущей итерации: 937 889,798255877

    — Отклонение на текущей итерации: 3 349 606,4223424179

    — Отклонение на текущей итерации: 3 349 606,422342418

    — Отклонение на текущей итерации: 11 962 880,07979435

    — Отклонение на текущей итерации: 11 962 880,07979435



  


                       
  





    — Отклонение на текущей итерации: 42 724 571,71355125

    — Отклонение на текущей итерации: 42 724 571,71355125

    — Отклонение на текущей итерации: 152 587 756,1198258929

    — Отклонение на текущей итерации: 152 587 756,119825893

    — Отклонение на текущей итерации: 544 956 271,8565210464

    — Отклонение на текущей итерации: 544 956 271,8565210464

    — Отклонение на текущей итерации: 1 946 272 399,4875751657

    — Отклонение на текущей итерации: 1 946 272 399,4875751656

    — Отклонение на текущей итерации: 6 950 972 855,3127684486

    — Отклонение на текущей итерации: 6 950 972 855,3127684486



  


                       
  





    — Отклонение на текущей итерации: 24 824 903 054,688458745

    — Отклонение на текущей итерации: 24 824 903 054,688458745

    — Отклонение на текущей итерации: 88 660 368 052,4587812321

    — Отклонение на текущей итерации: 88 660 368 052,458781232

    — Отклонение на текущей итерации: 316 644 171 615,9242186857

Это то что под приложением выдал из состоянии расчета.


А в отладчике последнее значение было таково :

267 488 214 754 648 642 684 559 809,9800832

и это на 85 Итерации из 200 как он показывает.

Что тут вообще происходит?)



  


                       
  




Reply ↓			




Такая же проблема. Увеличение разряда не помогает УТ 11.3.4.124
Reply ↓			




Смысл ошибки можно сформулировать проще.
Запрос не может выразить полученное при исполнении числовое значение, так как в результате получено число больше, чем разрешено условиями запроса.
Если будет конструкция ВЫРАЗИТЬ(1,0) а запросу попадется число 11, то он не сможет выразить его числом от 0 до 9.
Так то у вас все написано правильно, но к сути проблемы докопаться сложно.
Reply ↓			




(3)

Странно, но ошибка эта может вываливаться просто на счетчике.



  


                       
  





Вот строка запроса в обработке базопузомера:

Подсчитывалось количество записей в регистре сведений

              | СУММА(1) КАК Счетчик
Вот этот счетчик и выдал ошибку.  Количество записей в самом большом регистре было  около  62 млн. записей
и нормально заработала по вашему совету  вот так:
              | СУММА(ВЫРАЗИТЬ (1 КАК Число(23,0))) КАК Счетчик
плюсую
Reply ↓			






Такая же проблема.  Запрос к регистру ВыручкаИСебестоимостьПродаж показал что каждый документ записан 2 раза один раз с правильным количеством товара и суммы.  а второй раз с правильной суммой а количество равное нулю.  После отмены проведения и повторно ручного проведения запись документа в этом регистре с нулевым количеством исчезает. Это стандартное поведение или ошибка в системе?
Reply ↓			



  


                       
  












(3)тоже самое. Пришлось всем полям ВЫРАЗИТЬ писать. Тогда ошибка ушла



  


                       
  





СУММА(ВЫРАЗИТЬ(
|  ВЫБОР КОГДА ВЫРАЗИТЬ(УзлыКорректировкиСтоимостиСписания.Количество КАК ЧИСЛО(23, 10)) <> 0 ТОГДА
|   ВЫРАЗИТЬ(ТаблицаРешений.Стоимость КАК ЧИСЛО(23, 10)) *
|   (ВЫБОР КОГДА ВЫРАЗИТЬ(ВложенныйЗапрос.Количество КАК ЧИСЛО(23, 10)) = 0 ТОГДА
|    ВЫРАЗИТЬ(ВложенныйЗапрос.Стоимость КАК ЧИСЛО(23, 10))
|   ИНАЧЕ
|    ВЫРАЗИТЬ(ВложенныйЗапрос.Количество КАК ЧИСЛО(23, 10))
|   КОНЕЦ) /
|   ВЫРАЗИТЬ(УзлыКорректировкиСтоимостиСписания.Количество КАК ЧИСЛО(23, 10))
|  ИНАЧЕ
|   0
|  КОНЕЦ
| КАК ЧИСЛО(23,10))) КАК Стоимость
 Показать

Reply ↓			




Leave a Comment 
Ваш адрес email не будет опубликован. Обязательные поля помечены *


    

Описание ошибки:
Случилось, что в один момент отчет, который несколько лет работал без ошибок, при очередном формировании выдал ошибку: {ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Форма(480)}: Ошибка при вызове метода контекста (Выполнить)
мРезЗапроса = ОбъектЗапрос.Выполнить();
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
Microsoft SQL Server Native Client 10.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
HRESULT=80004005, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Найденные решения:

Исчерпывающее описание ошибки дало понять, что проблема скрывается в теле запроса. А формулировка «ошибка арифметического переполнения при преобразовании numeric к типу данных numeric» подсказывала, что проблема с числовыми данными, собираемых запросом. Внимательно присмотревшись к тексту запроса а так же благодаря заметке на сайте helpf.pro было выдвинуто предположение, что числа, получаемые запросом в результате арифметической операции, и приводимые с помощью функции языка запросов к числу с пятью знаками до запятой, стали длинее, чем указанная длина. 

Увеличение длины знаков до запятой решило проблему.

Оцените, помогло ли Вам предоставленное описание решения ошибки?

---

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

17-10-2018

Журавлев А.С.
(azhur-c.ru)