1с пользователь не указан
Ошибка появляется при обновлении конфигурации - вываливается окно "Недостаточно памяти" -> платформа крешится -> на базе появляется ошибка.
(1)Столкнулся с такой проблемой. То, что предложил автор статьи так не работает. Как еще решить эту проблему?
+ Молодец, что написал эту статью. "Недостаточно памяти" и все остальное. Именно так это все и происходило. Спасибо, что открыл тему. Четыре базы навернулись по такому принципу. У нас в конце концов один человек лишился работы, после этой ошибки. Два раза навернул базу, архивы не делал, а потом узнали об ошибке 1С.
(1)
Треш! Почему же 1С не снимает релизы с этими ошибками с сайта ИТС ? Делает вид, что ничего не происходит.
Сегодня столкнулся с такой же проблемой на платформе 8.3.16.1814.
Возможно кому то поможет, решил ее так:
1. Создал вспомогательную базу на сервере 1С, загрузил туда созданную перед началом обновлений выгрузку основной базы
2. На сервере MS SQL штатными средствами сделал полный бекап вспомогательной базы базы
3. Штатными средствами MS SQL восстановил основную базу из резервной копии вспомогательной
(6) Да, сделал бекап, но развернул его в другую базу, а потом средствами MS SQL накатил на основную.
Столкнулся с проблемой, что не мог удалить базу в консоли сервера 1С, поэтому таким странным способом..
(8) Да - удалить не дает, т.к. авторизация больше не проходит. Поэтому я на другом кластере (8.3.12) прописал ее - она дошла до авторизации - и дальше вернулся на кластер 8.3.18 - и прошла авторизация - и удалять не пришлось ничего из консоли администрирования
(8) что заначит "сделал бэкап, а потом средствами SQL. "?
Бэкап всегда и делается средствами SQL.
А если это выгрузка в dt, то надо ее так и называть.
У меня баг был на платформе 8.3.17.1851 исправлял платформой 8.3.16.1359.
Спасибо за статью.
Спасибо 1с за наши спокойные выходные, сарказм конечно.
То что сервер 1с начал рубить процессы в которых происходит принятие изменений это вообще за гранью.
Было такое, на пару дней оставил базу в процессе обновления, на окне принятия изменяемых метаданных, а когда вернулся к окну конфигуратора, то сеанс почему-то был завершен сервером. Ну и словил такую ошибку. Очистка пользователей в SQL не помогла, просто восстановил базу из dt и все.
Обновиться на 8.3.18.1289 запустить конфигуратор вводя пароль, помогает, потом возвращаемся назад на 8.3.18.1208 чтобы нигде больше платформу не переустанавливать по крайней мере пока одно место горит))) Когда потухнет, тогда в плановом порядке везде обновлять платформу.
(23) если с кампа программиста войдете, то да потом с любого кампа тоже войдете, лишь бы там была такая же версия платформы, новая в смысле
(24) а в чем смысл "компа программиста"? Я имею ввиду если обновиться и уже на старую платформу не возвращаться - пустит?
(26) Смысл в возвращении на старую платформу, - это тогда когда у тебя сотни ПК с установленной старой платформой, а ещё армия внешних пользователей и всех их как бы обновить одним днём проблематично, поэтому спасаете базу на новой платформе и возвращаетесь на старую, потом планомерно везде накатываете новую платформу пока работаете на старой, а потом одним днём грубо говоря переходите на новую платформу уже на серверах.
Если у вас нет проблем с армией юзеров и их ПК, то естественно вы можете сразу на новой платформе и продолжить дальше работать без даунгрейдов на старую платформу, это для вас будет лишнее и вредное, так как все равно та же 8.3.18.1208 опасна выходит для использования и лучшее её обойти стороной или сбежать от неё на новую версию, хотя ещё мало кто чего может сказать что там с 8.3.18.1289 не так и что есть за сюрпризы.
(27) не, просто тут люди делают манипуляции со старой платформой, а потом запускают на новой, я думал, нужны определенные танцы. А если апгрейд на последнюю 18 спасает положение, то мы подождем :)
(27) когда у нас это произошло - 8.3.18.1289 еще не было - поэтому пришлось возвращаться туда где были)
(13)
тот же эффект на 8.3.17.1851
теперь пакетно запускать обновления, даже типовых, это лотерея.
восстановил рядом архив
Дополню - обычное обновление после этапа реструктуризации периодически "убивает" базу.
Платформа 8.3.17.1851
Восстановить можно, если иметь бэкапы таблиц Config и ConfigSave (последняя, если нет хранилища, там будут ваши изменения). База запустится, но ошибки останутся, нужно будет проверить все добавленные при падении объекты.
(21) В процессе прерванной реструктуризации думаю есть риск, что часть таблиц будет преобразовано к новому варианту конфы, а часть так и останется по старому, хоть спасай или не спасай таблицы Config и ConfigSave
ТИИ скорее всего нужно проводить на базах после воскрешения
Платформа 8.3.17.1851 - такая же проблема после обновления и перезапуска.
В своём случае просто восстановил базу из бэкапа сервера.
А подскажите пожалуйста что означает фраза:
"заходим в конфигуратор до окна логина (логин не вводим)"
(29) прикрепилось не туда
запускаю конфигуратор -> появляется окно ввода логина / пароля -> жму Отмена
(40) так заходить и не надо было в конфигуратор - этим маневром фиксилась ошибка и при повторном запуске уже под нужной платформой давала зайти в базу. Сейчас уже не актуально (это уже писал в ветках) - потому что есть новый релиз, где эта ошибка указана как исправленная.
Автору спасибо за решение.
В итоге оказалось все ещё проще.
Удалил 8.3.18.1208.
Установил 8.3.16.1063
Запустил службу 1С, убедился что в консоли серверов 1с база есть.
Запустил базу в конфигураторе, окно авторизации появилось.
Отменил авторизацию.
Удалил 8.3.16.1063.
Установил 8.3.18.1208.
.
PROFIT
ничего не переставляли
так как старая платформа оставалась, сделали так.
- остановили 1с-сервер в службах
- заменили в реестре путь запуска на старую платформу (скрин приложил)
- запустили 1с-сервер
- дальше запустил конфигуратор(открылся в старой платформе), спросило, что делать с проблемной конфой - я ответил "да",
- открылось окно авторизации, отменил
- остановили 1с-сервер в службах
- вернули в реестре 1208
- запустили 1с-сервер
- запустил конфигуратор, вошел без проблем.
(36) у меня удалить из консоли не давало - т.к. требует авторизацию на базе в консоли - > а в базу авторизация порушена
(37) мне кажется сначала надо удалить БД, средствами СУБД, а затем при удалении ИБ 1С, выбрать пункт - Оставить без изменений.
(37) она не порушена. в предприятие вы же можете войти. Нельзя войти только в конфигуратор. Я на дню по несколько раз восстанавливаю. Есть причины, по которым пока не могу обновить платформу.
Скриптом запускаю второй сервер 1с на другом порту как приложение (лицензия не требуется). В консоле администрирования данного сервера создаю базу с теми же свойствами , что и основной версии. Запускаю конфигуратор. Дохожу до отсутствия лицензии. Закрываю. Потом запускаю конфигуратор основной версии. Все работает. Если снова нужно, то во второй версии в консоле нужно удалить базу, оставив БД без изменения. И снова создать новую. Работает только при создании новой базы
Столкнулись с указанной ошибкой, при переходе на новую версию платформу, с 8.3.16.1502 на 8.3.16.1814.
Способ, указанный автором, нам помог.
Добрый. 1с-ка делает запрос к табличке "SEL ECT Status FR OM SchemaStorage WHERE SchemaID = 0", в поломонной этот статус "200" в нормальной "100". я его изменил и база запустилась.
allexx; RazorSky; teca; FireFauced; santech-1C; avu2002; Andy_sh; yghmd; C0oLZ3r0; yelisenkov; bondaleksey; altviser; Maxs_1919; Slypower; stvorl; andpal; natal_tihom; reoreh; dammit666; CAIN; JohnK; r-azt; saleksv; AlexKriulin; ikekoval; retr0; Georgik; user763700; info1i; dimao; sivalor; user1024932; JetBerry; xamass; AActor; soci0pat; dkonakov; anderson; Painted; Terabaytus; alexey.glotov; netesoff; JohnyDeath; user953800; max_vorzhev; daodezi; Hellhackee; duhh; jagon; Zedd4D; mrcamomile; AlexKo; -Kulebyaka-; + 53 – Ответить
allexx; user591578_1c; Serega-artem; RazorSky; teca; mamonth; FireFauced; SerVlasov; vorkir; santech-1C; angel4evil; Andy_sh; kras; bird21; user1534961; pilotfitz; yghmd; teyana; Гуррыч; John_Dow; gerandy; Alex17; bondaleksey; altviser; evn-zorin; Slypower; ra9000; romankoav; Светлый ум; natal_tihom; finservice; reoreh; wizard.ilmir02; dammit666; CAIN; JohnK; r-azt; koka; гаврюша; ReXt0n; 1cmax; N!ghtmare; BomjBandit; saleksv; Lolmes; user871141; ikekoval; kudlach; retr0; user763700; wolder; karagiosis; dimao; user1024932; milanse; JetBerry; moyo; higs; max_nch; pro100; soci0pat; dkonakov; Painted; maxx; kaysh; Man940N; Terabaytus; akiril; Ole4ik; alexey.glotov; user1547888; Borometr; fedorovyhnikolai; user953800; tank68; Hellhackee; duhh; jagon; AlexKo; + 79 – Ответить
ПользовательВ журнале активных пользователей у всех стало . Что в программе, что в конфигураторе.
При загрузке 1С все как обычно. Все логиняться под своими именами (которые пропали) и при создании документа ответственный то же проставляется. 1С:Предприятие 8.3 (8.3.18.1433)
Чистите КЭШ. Не поможет - тестирование и исправление в конфигураторе. Копию создать не забудьте. Непонятно что за конфа у вас? Дописанная? Типовая?
У меня конфигурация: Бухгалтерия предприятия, редакция 3.0 (3.0.92.51).
КЭШ чистил удалением информационной базы из окна запуска, делал тестирование и исправление в конфигураторе - ничего не помогло.
Решил проблему. Ошибка была из-за разных клиентов 1С.
У пользователей стояла 8.3.18.1433 , а на компьютере Администратора, с которого просматривался мониторинг, была более свежая 8.3.18.1483. После обновлений пользователей до той же версии проблема исчезла.
У меня после перехода с 8.2 на 8.3 тоже появилось, что пользователь , а раньше было . 1 пользователь, вход без пароля. Платформа 8.3.18.1363. Была 1С Бухгалтерия предприятия базовая редакция 2.0 (2.0.66.138), стала редакция 3.0 (3.0.95.15). Пусть уж лучше будет . Как убрать этого ?
У меня после перехода с 8.2 на 8.3 тоже появилось, что пользователь <не указан>, а раньше было <не авторизован>. 1 пользователь, вход без пароля. Платформа 8.3.18.1363. Была 1С Бухгалтерия предприятия базовая редакция 2.0 (2.0.66.138), стала редакция 3.0 (3.0.95.15). Пусть уж лучше будет <не авторизован>. Как убрать этого <не указан>?не>
В редакции 3.0 должен быть хоть один пользователь с правами администратора. Запустите в режиме Конфигуратора, Администрирование - Пользователи. Откройте вашего 1 пользователя и проверьте, что у него стоят права Администратор системы, Администрирование и Полные права
Не совсем так. . или ни одного пользователя.
Ни в коем случае! В "новых" конфигурациях (БП3, ЗУП3, УТ11 и т.д.) всё управление пользователями делается только в режиме "Предприятие".
Не совсем так. . или ни одного пользователя.
Никак. Без переписывания программы. Заведите хотя бы одного пользователя, и будете видеть его имя.
То есть, если нет ни одного пользователя, то будет <не указан>? Верно?
не>Если же хоть 1 пользователь будет, то его имя будет видно вместо , но тогда и вход в программу будет происходить под именем этого пользователя с вводом пароля?
Иными словами, если нужен вход без паролей, то не должно быть и пользователей Так что ли?
. тогда и вход в программу будет происходить под именем этого пользователя с вводом пароля?
Иными словами, если нужен вход без паролей, то не должно быть и пользователей Так что ли?
Пользователь может быть без пароля - это уже сами смотрите.
+ если нужно, то пользователя и пароль можно прописать в параметрах запуска информационной базы, а если база одна, то и её тоже можно прописать в параметрах запуска. Т.е. кликаете по ярлыку 1С на рабочем столе, а программа сразу запускается, при этом сама выбирает нужную информационную базу, подставляет пользователя и его пароль.
Слушатели по-разному используют Мастер-группы курсов: кто-то по ходу обучения сразу задает возникающие вопросы; кто-то копит вопросы и затем скопом их задает; некоторые не любят задавать вопросов, они просто читают обсуждения других слушателей и пытаются найти аналогичный вопрос; кто-то пытается использовать Мастер-группу в своих личных целях и получить консультацию по реальной проблеме из практики. Каждый выбирает по себе!
Вопрос
Здравствуйте. Давно хотел спросить вот что: если поле пустое РегламентноеЗадание.ИмяПользователя, то в контексте какого пользователя (прав доступа какого поля) исполняется регл.задание? В документации так: “Если имя пользователя не задано, регламентное задание будет выполняться пользователем по умолчанию, имеющим административные права.” По наличию какого права определяется данный пользователь? Я неоднократно фиксировал, что при пустом РегламентноеЗадание.ИмяПользователя возвращает ПользователиИнформационнойБазы.ТекущийПользователь() в контексте выполнения регл.задания пустое значение. Как это объяснить?
Ответ
Добрый день! Если Вы откроете утилиту администрирования, то можете увидеть в ней вот такие записи:
Если у регламентного задания не указан пользователь, под которым оно должно выполняться, то будет отображаться DefUser.
Или другая ситуация – если в базе нет ни одного пользователя ИБ, при входе в базу пользователя Вы не выбираете, то в списке сеансов тоже будет отображаться DefUser. Это такой служебный, “виртуальный” пользователь ИБ.
Теперь по поводу прав этого пользователя. DefUser имеет права, определяемые совокупностью основных ролей конфигурации, и полные права, если список основных ролей конфигурации пустой. Напомню, что ОсновныеРоли – это свойство корневого элемента в дереве объектов метаданных:
Таким образом, если свойство конфигурации ОсновныеРоли заполнено, пользователь DefUser получит объединение указанных ролей. Если свойство конфигурации ОсновныеРоли не заполнено, пользователь DefUser получит привилегированный режим, “неограниченные права”.
Столкнулся с такой ошибкой на релизе 8.3.18.1208 при обновлении серверной базы ЕРП. Ранее разработка велась на 8.3.12.1790.
Подсказали такой хак - может, кому пригодится:
- устанавливаем предыдущий релиз платформы (в моем случае 8.3.12.1790 была установлена на другом сервере)
- в консоли администрирования 8.3.12.1790 прописываем эту базу
- заходим в конфигуратор до окна логина (логин не вводим)
- возвращаемся на платформу 8.3.18.1208
- заходим в конфигуратор + вводим логин / пароль
- профит
Был еще хак где SQL скриптами переливали базу в другую - но там было очень много нюансов.
Ошибка есть на баг-трекере
UPD / 16.01.2021 ушли на 8.3.18.1289 - пока полет нормальный
Список платформ, на которой у пользователей произошла ошибка:
8.3.16.1814
8.3.17.1851
8.3.18.1208
Специальные предложения
Ошибка появляется при обновлении конфигурации - вываливается окно "Недостаточно памяти" -> платформа крешится -> на базе появляется ошибка.
(1)Столкнулся с такой проблемой. То, что предложил автор статьи так не работает. Как еще решить эту проблему?
+ Молодец, что написал эту статью. "Недостаточно памяти" и все остальное. Именно так это все и происходило. Спасибо, что открыл тему. Четыре базы навернулись по такому принципу. У нас в конце концов один человек лишился работы, после этой ошибки. Два раза навернул базу, архивы не делал, а потом узнали об ошибке 1С.
(1)
Треш! Почему же 1С не снимает релизы с этими ошибками с сайта ИТС ? Делает вид, что ничего не происходит.
Сегодня столкнулся с такой же проблемой на платформе 8.3.16.1814.
Возможно кому то поможет, решил ее так:
1. Создал вспомогательную базу на сервере 1С, загрузил туда созданную перед началом обновлений выгрузку основной базы
2. На сервере MS SQL штатными средствами сделал полный бекап вспомогательной базы базы
3. Штатными средствами MS SQL восстановил основную базу из резервной копии вспомогательной
(6) Да, сделал бекап, но развернул его в другую базу, а потом средствами MS SQL накатил на основную.
Столкнулся с проблемой, что не мог удалить базу в консоли сервера 1С, поэтому таким странным способом..
(8) Да - удалить не дает, т.к. авторизация больше не проходит. Поэтому я на другом кластере (8.3.12) прописал ее - она дошла до авторизации - и дальше вернулся на кластер 8.3.18 - и прошла авторизация - и удалять не пришлось ничего из консоли администрирования
(8) что заначит "сделал бэкап, а потом средствами SQL. "?
Бэкап всегда и делается средствами SQL.
А если это выгрузка в dt, то надо ее так и называть.
У меня баг был на платформе 8.3.17.1851 исправлял платформой 8.3.16.1359.
Спасибо за статью.
Спасибо 1с за наши спокойные выходные, сарказм конечно.
То что сервер 1с начал рубить процессы в которых происходит принятие изменений это вообще за гранью.
Было такое, на пару дней оставил базу в процессе обновления, на окне принятия изменяемых метаданных, а когда вернулся к окну конфигуратора, то сеанс почему-то был завершен сервером. Ну и словил такую ошибку. Очистка пользователей в SQL не помогла, просто восстановил базу из dt и все.
Обновиться на 8.3.18.1289 запустить конфигуратор вводя пароль, помогает, потом возвращаемся назад на 8.3.18.1208 чтобы нигде больше платформу не переустанавливать по крайней мере пока одно место горит))) Когда потухнет, тогда в плановом порядке везде обновлять платформу.
(23) если с кампа программиста войдете, то да потом с любого кампа тоже войдете, лишь бы там была такая же версия платформы, новая в смысле
(24) а в чем смысл "компа программиста"? Я имею ввиду если обновиться и уже на старую платформу не возвращаться - пустит?
(26) Смысл в возвращении на старую платформу, - это тогда когда у тебя сотни ПК с установленной старой платформой, а ещё армия внешних пользователей и всех их как бы обновить одним днём проблематично, поэтому спасаете базу на новой платформе и возвращаетесь на старую, потом планомерно везде накатываете новую платформу пока работаете на старой, а потом одним днём грубо говоря переходите на новую платформу уже на серверах.
Если у вас нет проблем с армией юзеров и их ПК, то естественно вы можете сразу на новой платформе и продолжить дальше работать без даунгрейдов на старую платформу, это для вас будет лишнее и вредное, так как все равно та же 8.3.18.1208 опасна выходит для использования и лучшее её обойти стороной или сбежать от неё на новую версию, хотя ещё мало кто чего может сказать что там с 8.3.18.1289 не так и что есть за сюрпризы.
(27) не, просто тут люди делают манипуляции со старой платформой, а потом запускают на новой, я думал, нужны определенные танцы. А если апгрейд на последнюю 18 спасает положение, то мы подождем :)
(27) когда у нас это произошло - 8.3.18.1289 еще не было - поэтому пришлось возвращаться туда где были)
(13)
тот же эффект на 8.3.17.1851
теперь пакетно запускать обновления, даже типовых, это лотерея.
восстановил рядом архив
Дополню - обычное обновление после этапа реструктуризации периодически "убивает" базу.
Платформа 8.3.17.1851
Восстановить можно, если иметь бэкапы таблиц Config и ConfigSave (последняя, если нет хранилища, там будут ваши изменения). База запустится, но ошибки останутся, нужно будет проверить все добавленные при падении объекты.
(21) В процессе прерванной реструктуризации думаю есть риск, что часть таблиц будет преобразовано к новому варианту конфы, а часть так и останется по старому, хоть спасай или не спасай таблицы Config и ConfigSave
ТИИ скорее всего нужно проводить на базах после воскрешения
Платформа 8.3.17.1851 - такая же проблема после обновления и перезапуска.
В своём случае просто восстановил базу из бэкапа сервера.
А подскажите пожалуйста что означает фраза:
"заходим в конфигуратор до окна логина (логин не вводим)"
(29) прикрепилось не туда
запускаю конфигуратор -> появляется окно ввода логина / пароля -> жму Отмена
(40) так заходить и не надо было в конфигуратор - этим маневром фиксилась ошибка и при повторном запуске уже под нужной платформой давала зайти в базу. Сейчас уже не актуально (это уже писал в ветках) - потому что есть новый релиз, где эта ошибка указана как исправленная.
Автору спасибо за решение.
В итоге оказалось все ещё проще.
Удалил 8.3.18.1208.
Установил 8.3.16.1063
Запустил службу 1С, убедился что в консоли серверов 1с база есть.
Запустил базу в конфигураторе, окно авторизации появилось.
Отменил авторизацию.
Удалил 8.3.16.1063.
Установил 8.3.18.1208.
.
PROFIT
ничего не переставляли
так как старая платформа оставалась, сделали так.
- остановили 1с-сервер в службах
- заменили в реестре путь запуска на старую платформу (скрин приложил)
- запустили 1с-сервер
- дальше запустил конфигуратор(открылся в старой платформе), спросило, что делать с проблемной конфой - я ответил "да",
- открылось окно авторизации, отменил
- остановили 1с-сервер в службах
- вернули в реестре 1208
- запустили 1с-сервер
- запустил конфигуратор, вошел без проблем.
(36) у меня удалить из консоли не давало - т.к. требует авторизацию на базе в консоли - > а в базу авторизация порушена
(37) мне кажется сначала надо удалить БД, средствами СУБД, а затем при удалении ИБ 1С, выбрать пункт - Оставить без изменений.
(37) она не порушена. в предприятие вы же можете войти. Нельзя войти только в конфигуратор. Я на дню по несколько раз восстанавливаю. Есть причины, по которым пока не могу обновить платформу.
Скриптом запускаю второй сервер 1с на другом порту как приложение (лицензия не требуется). В консоле администрирования данного сервера создаю базу с теми же свойствами , что и основной версии. Запускаю конфигуратор. Дохожу до отсутствия лицензии. Закрываю. Потом запускаю конфигуратор основной версии. Все работает. Если снова нужно, то во второй версии в консоле нужно удалить базу, оставив БД без изменения. И снова создать новую. Работает только при создании новой базы
Столкнулись с указанной ошибкой, при переходе на новую версию платформу, с 8.3.16.1502 на 8.3.16.1814.
Способ, указанный автором, нам помог.
Добрый. 1с-ка делает запрос к табличке "SEL ECT Status FR OM SchemaStorage WHERE SchemaID = 0", в поломонной этот статус "200" в нормальной "100". я его изменил и база запустилась.
allexx; RazorSky; teca; FireFauced; santech-1C; avu2002; Andy_sh; yghmd; C0oLZ3r0; yelisenkov; bondaleksey; altviser; Maxs_1919; Slypower; stvorl; andpal; natal_tihom; reoreh; dammit666; CAIN; JohnK; r-azt; saleksv; AlexKriulin; ikekoval; retr0; Georgik; user763700; info1i; dimao; sivalor; user1024932; JetBerry; xamass; AActor; soci0pat; dkonakov; anderson; Painted; Terabaytus; alexey.glotov; netesoff; JohnyDeath; user953800; max_vorzhev; daodezi; Hellhackee; duhh; jagon; Zedd4D; mrcamomile; AlexKo; -Kulebyaka-; + 53 – Ответить
allexx; user591578_1c; Serega-artem; RazorSky; teca; mamonth; FireFauced; SerVlasov; vorkir; santech-1C; angel4evil; Andy_sh; kras; bird21; user1534961; pilotfitz; yghmd; teyana; Гуррыч; John_Dow; gerandy; Alex17; bondaleksey; altviser; evn-zorin; Slypower; ra9000; romankoav; Светлый ум; natal_tihom; finservice; reoreh; wizard.ilmir02; dammit666; CAIN; JohnK; r-azt; koka; гаврюша; ReXt0n; 1cmax; N!ghtmare; BomjBandit; saleksv; Lolmes; user871141; ikekoval; kudlach; retr0; user763700; wolder; karagiosis; dimao; user1024932; milanse; JetBerry; moyo; higs; max_nch; pro100; soci0pat; dkonakov; Painted; maxx; kaysh; Man940N; Terabaytus; akiril; Ole4ik; alexey.glotov; user1547888; Borometr; fedorovyhnikolai; user953800; tank68; Hellhackee; duhh; jagon; AlexKo; + 79 – Ответить
Описанная ситуация требует проверки:
- наличия подключаемого пользователя в справочнике Пользователи ;
- даты регистрации сервиса Обсуждения;
- работы пользователя в 1С после регистрации сервиса Обсуждения .
В качестве участников обсуждения можно добавить только тех пользователей, которые работали с информационной базой после ее регистрации на сервере взаимодействия.
Наличие подключаемого пользователя в справочнике «Пользователи»
Проверьте наличие подключаемого к обсуждению пользователя в справочнике Пользователи : раздел Администрирование — Настройки программы — Настройки пользователей и прав — ссылка Пользователи .
Возможно, пользователя Рома в справочнике нет или он введен в программу иначе, например, Иванов Роман. Если это так, введите наименование пользователя в поисковой строке правильно.
Определение даты регистрации сервиса Обсуждения
Дату регистрации сервиса можно посмотреть в электронной почте того, кто регистрировал сервис Обсуждения. Письмо от имени 1С:Диалог ИТ о регистрации с кодом доступа для подключения сервиса.
Дата регистрации сервиса Обсуждения — 15 мая 2019 г.
Проверка работы в 1С подключаемого пользователя после регистрации сервиса
Для проверки работы в 1С подключаемого пользователя нужно открыть Журнал регистрации : раздел Администрирование — Настройки программы — Обслуживание — ссылка Журнал регистрации — кнопка Установить отбор :
После применения настроек по кнопке Применить и закрыть в окне просмотра будет отражены действия пользователя за данный период.
После выхода из отпуска, когда он начнет работать в базе, указанного пользователя можно будет включать в список участников обсуждения.
См. также:
Помогла статья?
Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно
Похожие публикации
-
.От пользователей поступают жалобы, что при автообновлении на ЗУП 3.1.8.В соответствии со ст. 272 НК РФ расходы признаются в..
(3 оценок, среднее: 5,00 из 5)
Публикацию можно обсудить в комментариях ниже.
Обратите внимание!
В комментариях наши эксперты не отвечают на вопросы по программам 1С и законодательству.
Задать вопрос нашим специалистам можно в Личном кабинете
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Вы можете задать еще вопросов
Доступ к форме "Задать вопрос" возможен только при оформлении полной подписки на БухЭксперт8
Нажимая кнопку "Задать вопрос", я соглашаюсь с
регламентом БухЭксперт8.ру >>
Изменения в 2022 году, о которых нужно знать бухгалтеру
6-НДФЛ за 1 квартал 2022 в 1С
Санкции и контрмеры: как работать организации и ее бухгалтеру в новой реальности. Часть 2
Учет малоценных ОС и запасов (ОСН)
Отчетность за 1 квартал 2022
С 1 мая — новые коды в платежках при переводе денег физлицам
Поддерживающий ЗУП за апрель 2022 + Премии в ЗУП 3.1
6-НДФЛ за 1 квартал 2022 в 1С
Исключение матвыгоды за 2021-2023 гг. из обложения НДФЛ (ЗУП 3.1.21.75 / 3.1.18.435)
Спасибо большое! Как всегда,бесподобный вебинар с исчерпывающими ответами для нас «бедных» бухгалтеров! Всем лекторам благодарность.
Читайте также: