Для начала надо было самому понять формат файлов журналов регистрации, формат понимался одновременно с написанием обработки, поэтому обработка и родилась раньше статьи про формат :)
К тому же еще не совсем понятно что означает седьмое и последнее поле в файле данных, а так же 11, 12 и 13 справочники из файла описаний.
(2) Доброго дня. За идею - я поставил бы и 100 плюсов. Месяц назад у поднимался вопрос про операции именно с файлами Журнала регистрации. Была плоная переписка с разработчиком (1С), которая закончилась ничем. Ваша обработка откроет для меня информацию для изучения. Поле "непаханное"... Буду следить с развитием поднятой вами темы. Спасибо!
(3) Ditrich,
Если не секрет опишите пожалуйста что именно вы хотели получить из файлов журнала регистрации. Возможно это даст толчок к расширению функционала.
Обработка в первую очередь писалась не для того для чего ее будут использовать большинство качающих - "заметания следов" в журнале регистрации. Идея разработки возникла из-за внутренней нужды объединить и отфильтровать старые журналы регистрации рабочей базы, а описание формата нигде найдено не было...
(4) моя задача и не сводилась к заметанию следов, а к лёгкой доступности к файлам Журнала регистрации на сервере и манипуляциями с ними, т.е. получение данных из файлов ЖР, перемещённых в архивную папку на сервере. Если подробнее, изначально ЖР для двух ИБ - ЗУП и БУ, которые были ещё и ко всему связаны РИБ (9 узлов), были НЕ настроены на период (т.е. писались непрерывно в течение 1,5 лет) и выросли в объёме до 20 ГБ на каждую базу, что помимо места на сервере значительно тормозило работу 1С для пользоватлей... Я пытался у разработчика (1С) получить информацию о возможности "обрезать" файлы ЖР для ЗУП и БУ до нужной даты средствами 1С... После долгой переписки, ответа они так и не дали, кроме как посоветовали настроить ЖР по периоду. А такая настройка (например, я настроил ЖР по периоду месяц с 01.02.2013 г.) обрезает ЖР до даты, указанной в новой настройке. А мне требовалось, скажем отрезать все записи ЖР в файле на сервере до начала 4-го квартала 2012 г. Теперь в общем у меня фалы ЖР каждый месяц перемещаются в архивную папку на сервере каждый месяц по написанному скрипту SQL. НО неудобство заключается в следующем - если требуется посмотреть записи ЖР прошлого или более раннего месяца, нужно вырубать всех из 1С, подгружать файлик ЖР из архивной папки в папку работующей базы... Что сами понимаете, занимает кучу времени и неудобство в работе пользователей. А ваша идея - значительно упростит решение моей проблемы.
(8) AlexO, очень удобно, с вашей точки зрения, открывать копии 9 баз? подтягивать в каждую нужный файл ЖР за период? и искать там когда и что с тем или иным объектом делали? Я уже молчу про затраченное время на разворачивание необходимой копии базы на сервере и не одной ещё ко всему (да фиг с ним, пусть даже если и на лок.машине). На сой взгляд, вы до конца не изучили проблему, либо поверхностно взглянули на неё не разобравшись, упоминая при этом версионирование и т.п., про которое в теме и не писалось даже!
(5) Ditrich,
Разбивать файлы на несколько / объединять несколько в один думаю доработать в будущих версиях, собственно для этого и было начато исследование. Причем моя задача объединить старый журнал регистрации формата 8.1 с текущим и старыми журналами 8.2 с фильтрованием совсем ненужных событий и урезанием текстовых комментариев / представлений данных.
Вообще не понятно зачем вы подсовываете архивный журнал регистрации рабочей базе, если он без проблем открывается через Файл - Открыть. Просто копируйте вместе с файлом данных файл описаний и открывайте его.
(21) AlexO,
Ну так в первую очередь и писалась для понимания формата и чтения напрямую файлов журнала регистрации. И запись в первую очередь была реализована для проверки чтения.
Неожиданно получился "мощный" инструмент для "заметания следов", но основное то предназначение другое. Чтобы почистить записи в журнале регистрации никакой специальной обработки то и не нужно - открываем файл любым текстовым редактором и явно видим там записи - начало записи дата со временем - что мешает вычистить ненужные записи вручную?
(24) AlexO,
Если уж уходить от сути и рассматривать только "заметание следов", то по датам вычищение вполне достаточно чтобы замести следы - ведь дата вместе со временем вплоть до секунды, так что резко снижается граница поиска.
Обработка конечно позволяет вычистить записи более прецизионно и быстро и даже подменить одни записи на другие, но кто очень хотел мог все это сделать и без нее, немного покопавшись в файлах.
Если не секрет опишите пожалуйста что именно вы хотели получить из файлов журнала регистрации.
На самом деле, чем не устраивает типовой просмотр? Что вы хотели такого-эдакого увидеть еще?!
Или списывались с 1С - подозревали, что не все попадает в журнал? :)
Ну, а если думали "заставить" 1С писать в журнал еще и версионность объектов (изменение реквизитов. модификацию и т.д.) - то это и ни туда, и ни сюда: есть отдельные попытки версионировать все и вся, но они крайне затратны.
Скажем так, если будет в результате в обработку добавлена возможность выкидывать из файлов журнала к черту все записи о регистрах накопления, изменяемых при проведении обычных документов - будет уже хорошо.
Я имею в виду, что платформа 8.2, конфигурация УПП 1.3.х при проведении, например, документа "Реализация товаров и услуг" пишет движения в каждый из 43 регистров (накопления, сведений и бухгалтерии), для которых этот документ может делать движения. Если реальные движения есть, скажем, по 5 регистрам, то в остальные 38 пишутся пустые наборы записей. И все это отражается в журнале регистрации, серьезно увеличивая его объем.
Я имею в виду, что платформа 8.2, конфигурация УПП 1.3.х при проведении, например, документа "Реализация товаров и услуг" пишет движения в каждый из 43 регистров (накопления, сведений и бухгалтерии), для которых этот документ может делать движения. Если реальные движения есть, скажем, по 5 регистрам, то в остальные 38 пишутся пустые наборы записей. И все это отражается в журнале регистрации, серьезно увеличивая его объем.
Так что вы предлагаете - очищать все записи в журнале регистрации по регистрам или проверять в какие регистры есть записи у документа и оставлять только их? Если очищать выборочно, то как быть со случаем когда документ при проведении записал какие-то данные в регистр, а при повторном проведении вычистил их?
(18) Я предлагаю удалять эти записи безусловно. Ни разу на моей памяти не потребовалось смотреть по журналу регистрации, в какой регистр какой документ что-то записал.
(31) kapustinag, (34) vis_tmp,
В будущих версиях планируется фильтр, который будет позволять отсеивать ненужные записи при чтении, либо при записи файла данных журнала регистрации.
Если удалять все записи по регистрам, то это будет не проблемой - снимем галки со всех регистров и все. Но пока этот механизм еще начал делать.
Сейчас в ближайшей версии планирую загрузку файлов данных не по одному, а по маске и выгрузка данных с разбивкой по периодам.
Кстати, на Инфостарте есть обработки, позволяющие загрузить журнал в отдельную SQL-базу, и просматривать его там. Если часто нужно возвращаться к журналам в прошлых периодах - может быть, они помогут?
Кстати, на Инфостарте есть обработки, позволяющие загрузить журнал в отдельную SQL-базу, и просматривать его там
Насколько мне известно на данный момент нет обработок, которые могли бы выгрузить данные обратно в типовой журнал регистрации 1С.
Разрабатываемая обработка как раз предназначена для работы напрямую с файлами типового журнала регистрации 1С.
Так как она разрабатывалась одновременно с пониманием самого формата журнала регистрации (который тоже кстати по имеющейся у меня информации на данный момент нигде не описан), то все допфункции решено было отложить "на потом", сначала реализация чтения / записи файлов.
Обработка обновлена до версии 1.1
1) Исправлены ошибки возникающие при выводе добавленной строки
2) Определена 7я колонка - это номер соединения
3) Реализован выбор значений из списка для всех справочников из файла описаний
4) Реализован просмотр дополнительных метаданных (ранее колонка ДопДанные)
Следующим этапом планирую чтение файлов данных не по одному а по маске содержащей "*"
А соответствие описаний и журнала кто будет тогда выставлять?
Будет что-то вроде того как в типовом через Файл - Открыть - т.е. выбираться будет файл описаний, а вместо файла данных будет указана маска, по которой к одному файлу описаний будут подгружено несколько файлов данных.
В принципе механизм уже кое-как работает. Пока не хватает времени чтоб оттестировать и выложить.
(28) AlexO,
Во второй строчке как файла данных, так и файла описаний содержится некий GUID - в принципе можно ориентироваться на него и сопоставлять данные и их описание по нему. Пока эти GUIDы в обработке не проверяются, но как показывает практика эти GUIDы совпадают и ориентироваться на них можно.
Тут еще один вид файлов всплывает - так называемые архивы журнала регистрации - в них в одном файле последовательно сначала файл описаний, а затем файл данных.
Если вы располагаете более полной информацией о журнале регистрации и желаете поделиться этой информацией, пишите в комментариях к статье о форматах - http://forum.infostart.ru/forum24/topic83883/, я обязательно дополню статью новой информацией.
(32) Балабас,
Очень странно. Только что попробовал скачать версию 1.1 по ссылке http://infostart.ru/public/download.php?file=181807. Файл IE10 скачался корректно - с русским именем "АнализФайловЖурналаРегистрации_1_1" и расширением "epf". Приложенный вами файл имеет латинское имя "analizfaylovzhurnalaregistratsii.1.1" и расширение "erf" и что еще более странно "_" заменено на ".".
Думаю нужно сообщить об этом администрации сайта. Уточните чем качался файл?
Обработка обновлена 15.04.2013 - Версия 1.2
1) Реализована возможность загружать файлы данных по маске содержащей "*"
2) Реализована возможность разделять при сохранении файл данных по периодам - Час, День, Неделя, Месяц, Год
3) Реализовано чтение архивов журнала регистрации в которых в одном файле последовательно идут сначала описания, затем данные
(37) что-то не смог увидеть как работает ваша обработка постоянно пишет мне
Не удалось прочитать файл: C:\base\1Cv8Log\20110322000000.lgp
Не удалось прочитать файл: C:\base\1Cv8Log\1Cv8.lgf
Подскажите как она должна работать, версия платформы 1с82 13.219
(38) amon_ra,
Скорее всего вы пытаетесь открыть файлы, которые в данный момент используются 1С.
Скопируйте журнал регистрации в отдельную папку и читайте его оттуда.
Так же возможно у вас не хватает прав на открытие этих файлов - попробуйте открываются ли файлы блокнотом.
Скорее всего вы пытаетесь открыть файлы, которые в данный момент используются 1С.
Отсюда сразу следует, что средствами 1С читать лог-файл -- лажа.
Читать надо внешней программой с режимом открытия файла: fmOpenRead or fmShareDenyNone
А можно выложить побольше скриншотов, а то - тот что есть - очень неинформативен.
Какой именно анализ делает Ваша обработка , что и как предоставляет из описания не оч.понятно.
На данный момент обработкой можно исправить или удалить нужные записи из журнале регистрации, а так же разделить один большой файл данных журнала регистрации на несколько (по месяцам, дням и т.д.). Если есть битый журнал регистрации, то обработкой можно пробовать проанализировать ошибку - конечно не в автоматическом режиме и без доработок, т.к. пока я не занимался поиском типичных ошибок журнала регистрации.
Обработкой уже давно не занимаюсь, так как особого интереса со стороны сообщества не было. В последней версии, которую пока так и не выложил добавил сохранение файла описаний. В текущей общедоступной версии поддерживается редактирование только файлов данных. В планах были автоматизация удаления ненужных записей для уменьшения размера файлов данных чтобы можно было хранить в журнале регистрации рабочей базы все основные события без урезания журнала регистрации по периодам.
Скриншотов постараюсь понаделать как доберусь до обновления статьи, но они особо не нужны, так как по сути тут все те же поля что и в обычном просмотре журнала регистрации.
Суть обработки в том, что она работает напрямую с текстовыми файлами журнала регистрации, чего ранее практиковалось.
43.
slava_vermishelkin
15.08.13 22:19 Сейчас в теме
Интересует вопрос: можно ли из журнала регистрации 1с 8.2 вытащить ссылки на объекты? Если точнее, то есть задачка: необходимо отредактировать реквизит объектов, список которых в журнале регистрации (для отбора хватает стандартных фильтров при построении журнала). Конечно можно было бы выгрузить наименование объектов и обработать, но оно не уникально.
Кто-нибудь сталкивался с такой проблемой? Может есть решения?
Интересует вопрос: можно ли из журнала регистрации 1с 8.2 вытащить ссылки на объекты?
Да. В обработке реализовано получение ссылки из записи журнала регистрации.
Ссылка получается через ЗначениеИзСтрокиВнутр(). Проблема в том, что в журнале регистрации не вся информация для формирования строки для передачи этой функции. Поэтому сначала происходит кэширование идентификаторов типов всех ссылок, которые получаются через ЗначениеВСтрокуВнутр(ПустаяСсылка).
для отбора хватает стандартных фильтров при построении журнала
Отборы в обработке планировались, но они пока не реализованы. Как найду время вернуться к продолжению разработки, доделаю.
Очень интересная программка для сбора доказательств по мошенничеству пользователей с бухгалтерскими проводками и операциями в базе. Мне как эксперту по кибер-преступности очень поможет. Спасибо.
(47)(59)(61)(62)(66)(72)(76)(79) По поводу нехватки памяти при чтении файла журнала...
Обработка автора сейчас читает сразу весь файл и затем построчно обрабатывает его.
Поэтому и вываливается с ошибкой на строке чтения большого файла.
Я попробовал переделать версию 1.4 на открытие файла и его построчное чтение.
В таком режиме у меня открылся журнал размером примерно 10 Гб.
Побочный эффект - неизвестное заранее число строк в файле и, соответственно, бессмысленность прогрессора.
Добавил опциональную возможность предварительного подсчета числа всех строк в файле (по флажку "Сч.строки"), тогда прогрессор работает, но тратится доп. время на этот подсчёт.
(83) vis_tmp, Попробовал проанализировать файл размером 6 гигабайт, 1с закылась с ошибкой на чтении строк 4789000
Памяти достаточно свободной (4 гиг), заняла памяти 1,5 гиг и вывалилась. Может потому что у меня 32 битная win 2003 server...
Спасибо автору за обработку, но с большими файлами не "дружит"
48.
bogdan_sukonnov
5704.12.13 18:11 Сейчас в теме
Спасибо большое за обработку, очень помогла. Путем доработки напильником удалось склеить 2 журнала регистрации (точнее перевести один в словарь другого). Если Вы добавите это в функционал - цены не будет обработке!
Автор как к человеку знающиму подскажи как правельней зделать в такой ситуации. Реквизит со значением неограничено преобразовываю при помощи функции ЗначениеВСтрокуВнутр() при обратном преобразовании при помощи функции ЗначениеИзСтрокиВнутр() приисходит ошибка формата потока. Подскажите как быть как можно решить етот вопрос. Зарание спасибо за ответ
Нужно посмотреть что там в этой строке, что вызывает ошибку. Вообще если в строке какие-либо спецсимволы, то можно попробовать заменить проблемные символы на другие / комбинацию других.
Не помогла :(
Суть проблемы: Не можем прочитать архив журнала!
Мы обрезали разросшийся журнал с сохранением в файл. Файл получился 5,8Гб 1с8 вылетает при попытке его открыть. Пробовал разрезать его "тотал коммандером" и приделать к нужным кускам заголовок из первого файла - 1с8 пишет "ошибка формата потока" - ваша обработка после 8 часов обработки 100мб куска выдала пустое окно с записями (обьекты только в прочипх вкладках есть)
(51) serg1974, Выкладывайте на любой обменник rghost.ru например. Если не хотите светить данные всем, то запарольте архив и ссылку с паролем в личку.
Файлы резать нужно по записям (Число "{" должно быть равно числу "}").
Если это архив журнала регистрации, то сначала идет файл описаний, который нужно отделить и использовать для всех кусков.
"ошибка формата потока" скорее всего из-за наличия кривой записи, возможно в поле "Комментарий" используются непарные {}
Новая Версия 1.3
1) Добавлена возможность записи Файла описаний
2) Доработано чтение архива журнала регистрации в неком новом формате, где нет заголовка перед началом данных и есть новая таблица DatesMap
3) Добавлена возможность переразбивки файлов данных без загрузки самих данных в табличную часть обработки (Кнопка Переразбить)
4) При разбивке данных на периоды теперь не разрывается транзакция
5) Добавлена возможность фильтрации по метаданным при загрузке Файлов данных
6) Исправлены статусы транзакций
Новая Версия 1.4
1) Исправлена ошибка из-за которой неоправданно долго читались большие Файлы описаний
2) Добавлена возможность перекодирования журнала регистрации на словарь другого журнала регистрации для 8.2
Теперь появилась возможность склеивать журналы регистрации - например у вас начался новый журнал при переезде на новый сервер 1С или при смене платформы 8.1 -> 8.2, а вы очень хотите видеть все в одном месте.
Для 8.1 перекодирование реализовано не полностью.
Так же каждый легко может немного доработать обработку для фильтрации только нужных записей. На текущий момент реализована фильтрации по метаданным, по аналогии можно добавить по другим признакам или разработать сложное условие.
Файл журнала за месяц - 412 Мб, обработка так и не смогла его загрузить - 1с вылетает с ошибкой - видимо заканичвается память которую 32 битный процесс может захватить. По диспетчеру задач 1с занимала больше 3,5 Гигов в оперативке.
Обработка супер, то что давно искал, огромное человеческое спасибо, у меня были старые журналы которые не мог прочитать вываливалась ошибка и наконец-то я их смог прочитать!
Но памяти конечно кушает очень много )) на 32 битном сервере 1С на платформе 8.2.16.368 у меня не прочиталось пришлось поднять 64 битный 8.3.4.482 и только там нормально прочиталось.
(66) (72) не пробовали лог разделять по периодам?
Это не обработка виновата - сама 1С не приспособлена к таким объемам обработки. Вот и вылетает по памяти.
(76) AlexO, 1С не может мне порезать журнал по периодам - вылетает с ошибкой памяти. Сейчас у нас журнал по периодам настроен, но очень нужно просмотреть старый, а он очень большой - нигде не открыть ;(
Здравствуйте! У нас есть база, Мы перенесли её на новый сервер, а файлы журнала сразу не перенесли, соответственно файлы описаний теперь разные и подсунуть старые журналы в каталог к новым не получается.. Не могли бы пояснить что делает ваша обработка по кнопке "Перекодировать файл данных"? Могу ли я с её помощью поправить новый файл описаний и перекодировать новые журналы. А старые докинуть в папку к новым? Заранее благодарю
И если можно опишите как склеивать журналы? очередность действий.
к примеру, так можно? 1) загружаем "файл описания1" 2) загружаем "файл данных1" 3) загружаем "файл описания2".4) жмем перекодировать "файл данных1".
Ато инструмент хороший, а как пользоваться непонятно - лезть в код чтобы разобраться ? Помогите пожалуйста
Никак. Уже "хорошо", что 1С позволила разрезать журнал (кое-как) и наискосок.
Обработка и призвана просматривать и осуществлять поиск по разным кускам лога, в противном случае, типовой механизм может подключить лишь какой-то один файл-кусок.
Никак. Уже "хорошо", что 1С позволила разрезать журнал (кое-как) и наискосок.
Обработка и призвана просматривать и осуществлять поиск по разным кускам лога, в противном случае, типовой механизм может подключить лишь какой-то один файл-кусок.
Выже не автор обработки - зачем вводите в заблуждение? Привожу цитату автора:
Теперь появилась возможность склеивать журналы регистрации - например у вас начался новый журнал при переезде на новый сервер 1С или при смене платформы 8.1 -> 8.2, а вы очень хотите видеть все в одном месте.
Поэтому я и копал в этом направлении..
После длительного анализа и тыков получилось склеить два журнала! Подобных обработок не встречал. Если ей сделать понятный механизм конвертации журнала с одного описания под другое описание то цены ей не будет. Я сначала пытался допилить - в итоге потом обошелся типовой. Делал так:
1) Выбираю ФайлыЖурнала1 по маске *.lgp и старый ФайлОписания1, загружаю их (прочитать). Потом жму переразбить и сохраняю все в один файл без разделения по периодам
2) Выбираю получившийся ФайлЖурнала1 и жму "прочитать файл данных"
3) !!! перехожу на вкладкуПользователи, выбираю ФайлОписания2 и жму "прочитать файл описания". Если чтение файла описания происходит не на вкладке Записи ЖР, то данные в таблице ЗаписиЖР не меняются - это нам и нужно.
4) !!! Выбираю ФайлОписания1 НЕ нажимая прочитать файл описания
5) Жму "перекодировать" и сохраняю в нужное место ФайлДанных, сконвертированный под ФайлОписания2. В том же каталоге создается файл описания 1CV8.lgf. Эти два файла переносим в каталог ЖурналаРегистраци2, заменив 1CV8.lgf. (Перед этим можно забэкапить их). Работать с базой в этот момент не должны.
Еще как я выяснил имена файлов, состоящие из цифр и представляющие собой даты нужно делать таим образом чтобы файлы имеющие данные за более ранние периоды располагались раньше при сортировке по имени файла.
Еще я думаю, что: Правильнее конвертировать новые журналы под старые, т.к. они меньше как правило и в новых файлах описания может не быть описания многих событий и объектов из старого журнала.
Приводите. А еще - посмотрите, как в обработке "склеиваются" фрагменты.
(79) СистемСервис,
1С не может мне порезать журнал по периодам - вылетает с ошибкой памяти.
У вас слишком большой журнал.
Попробуйте сначала отрезать старый кусок, а потом подразбить оставшееся.
(81) vis_tmp, я думаю, если поле одно - то этот перенос значения не имеет: сменится только отображение поля, было в две стоки, станет в одну.
(0) Заметил искажение текста события.
было так:
{20150127183916,N,
{0,0},1,1,1,1,6,I,"Объект изменен: Справочник.Склады
Регистрация конфигурации изменена",0,
{"U"},"",0,0,0,2,0,
стало так:
{20150127183916,N,
{0,0},1,1,1,1,6,I,"Объект изменен: Справочник.СкладыРегистрация конфигурации изменена",0,
{"U"},"",0,0,0,2,0,
Т.е. из строки "Объект изменен: Справочник.Склады
Регистрация конфигурации изменена" оказался вырезан перенос строки.
(87) olegpoz, была попытка открыть файл объемом около 4 или 5 Гб, попытка окончилась неудачей, т.к. было свободной памяти 2 или 3 Гб. Теоретически, если у Вас свободной оперативной памяти более 7 Гб, то файл должен открыться. Либо Вам необходимо будет поправить процедуру загрузки данных из файла. Посмотрите в (83) выложен вариант данной обработки. В итоге - Вам нужно наличие свободной оперативной памяти более 7Гб.
Надеялся найти тут возможность пересобрать LGF файл (файл описания), т.к. за долгие годы эксплуатации он сильно вырос (8Мб), что фактически блокирует открытие отборов по ЖР (на сколько я понимаю в этот момент платформа формирует списки событий, а они гиганские...). Сами файлы журнала мы периодически убираем, однако старые события записанные по ошибке когда-то с уникальным идентификатором события привели к тому, что весь файл описывает идентификаторы событий которые отсутствуют в LGP-файлах.
Попробовал этой обработкой вариант "Перекодировать", не подошло. Не хочется изобретать велосипед (и тем более изучать код...) - нет ли готовых решений для этого?
Добрый день, Антон. Было бы не плохо указать что не работает в 8.3. А то мне нужно было чем то срочно посмотреть журналы и на скорую руку нашел эту обработку. Но обработка, соответственно, не предназначена для 8.3. Потратил зря время и не только время
Если ЧитатьВБазу Тогда
СтрокаЖР = РегистрыСведений.ЖурналРегистрации.СоздатьМенеджерЗаписи();
Иначе
СтрокаЖР = ЗаписиЖР.Добавить();
КонецЕсли;
Нашел вот такие строчки. Сейчас занимаюсь вопросом загрузки журнала как раз-таки в регистр сведений на основе процедур из Вашей обработки. Видимо опыт такой у Вас тоже имеется. Вопрос, собственно в том - насколько быстро разрастается объем таблицы регистра?
PS: Просматривать журнал штатными средствами нереально, Ваша обработка - уже лучше, но парсинг файлов журнала тоже не быстрый, причем путей заметно ускорить его не вижу. Настроили разбивку журнала по дням, каждый день набегает около 500 000 записей или 100 Мб файла. Часть записей планирую выбрасывать, но и после этого останется немало.
Код 13 в lgf-файле - это аналог записи таблицы ComputerToUserCodes в журнале lgd. Где в нулевом элементе массива код вида элемента, в 1м - код компьютера, а во 2м - код пользователя.