Продвинутый курс. МГ от 14.03.2011
14.03.2011
комментария 33
Свежие ответы на новые вопросы.
1. Тестирование и исправление.
Обезателно ли проводить бекап бази (выгружать dt или sql средствами) перед проведениям процедуры “Тестирование и исправления”?
И второй вопрос безопасний ли етот механизм для самой информационной базы, то есть если поставить радиобаттоны што только тестировать, то может ли ета процедура привести к проблемам з самой ИБ или позже окажится що база розрушена или што то в етом родё.
2. Определение ключа защиты.
При подключении через RDP ми подключаемся к терминальному серверу і уже на терминальном сервере у нас есть подключения к серверу приложений 1С, ключей защыти и прочие.
Как будет определятся ключ защыты 1с при использовании тонкого клиента, если ключи не в локальной сети і VPN тоже нет.
3. УУ на регистрах бухгалтерии.
Посмотрев 3й блок, у меня закралась такая мысль, что можно некоторые процессы управленческого учета автоматизировать использую регистры бухгалтерии.
К примеру те же взаиморасчеты, куда прозрачнее и нагляднее они видны на регистре бухгалтерии с субконто: Контрагент, договор, документ… Наличие подчиненных счетов только облегчают картину: счет авансов, счет долгов.
Или при отслеживание заказов.
К примеру. Счет заказ (заказ.1) и заказ-резерв (заказ.2).
Д заказ.1 К 62 – формирование заказа
Д заказ.2 К 62 – резервирование заказа
Д 41.1 К заказ.1 – приход товара
Д 41.2 К заказ.2 – резерв
Делая тоже самое на регистрах накопления, получается не так прозрачно. Ваше мнение, скажется ли это на производительности?
4. Обновление типовых решений.
Есть конфигурация с небольшими доработками по сравнению с конфигурацией поставщика, требуется обновить ее через несколько релизов. cfu файлов нет.
Будет ли корректным обновление , если возьму cf файл из последнего релиза, добавлю в него изменения,
потом выгружу полученный файл для последующей загрузки в рабочую конфигурацию через пункт меню: загрузка измененной конфигурации.
5. Изменение иерархии счетов.
Если изначально был счет БЕЗсубсчетов – его ведь можно сделать субсчетом и добавить родителя, тогда старые данные окажутся на субсчете.
6. Признаки учета субконто.
Я так понимаю субконто нужно располагать в такой последовательности, чтоб субконто с отключенными признаки были последними?!
— залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись —
напишите нам на e-mail поддержки.
Продолжаем исследовать ключи.
1. Запуск РАЗНЫХ версий платформ 8.1 и 8.2 и/или различных версий 8.2 все так же “отъедает” лишь 1 лицензию в ключе или …?
2. Как происходит поиск ключа (сервера лицензирования) с учетом настроек в файле nethasp.ini? Сервер ищется только по указанным в параметре <NH_SERVER_ADDR> адресам или если по указанным адресам ничего не найдено – все равно будет выполнен широковещательный запрос?
3. В реальном сетевом окружении на практике указание заведомо ложного адреса сервера лицензирования не приводит к ошибке – ключ получается от одного из доступным по сети серверов лицензирования… Это “фишка”, “глюк” или влияние кэширования полученного в первом запущенном сеансе ключа?
Комментарии (замечено из практики).
– физическое удаление файла nethasp.ini приводит к невозможности получения лицензии. Даже если в нем все параметры были закомментированы – он должен быть.
– изменение файла nethasp.ini в случае, когда уже запущено несколько сеансов платформы и все они пользуются одной лицензией, приводит к “отъеданию” еще одной лицензии в ключе. Остальные запуски платформы пользуются уже новой лицензией – до очередного изменения nethasp.ini
>1. Запуск РАЗНЫХ версий платформ 8.1 и 8.2 и/или различных версий 8.2 все так же «отъедает» лишь 1 лицензию в ключе или …?
Если не используется выдача лицензий сервером предприятия, то должна заниматься только одна лицензия.
>Сервер ищется только по указанным в параметре адресам
Да, правильное поведение системы именно такое.
Если наблюдаем обратное, то видимо это ошибка (скорее всего платформы).
Вообще, как показывает, практика система лицензирования в 8.2 работает не очень стабильно, полагаю это временное явление.
По п.2 (еще вопрос)
Окружение: терминальный сервер с толстым клиентом + сервер предприятия + сервер СУБД (3 РАЗНЫХ машины). Все сервера находятся в одной локальной сети. Ключ защиты стоит (физически) на сервере предприятия.
В реальной многопользовательской работе возникает ситуация, когда в ключе использовано намного больше лицензий, чем запущено сеансов на терминальном сервере. Вариант, что пользователи запускают клиенты со своих собственных машин – исключен.
Если я правильно понял видеоуроки по лицензированию и ответ в этой МГ, то для толстого клиента ВСЕГДА происходит лицензирование на рабочее место. Т.е. сколько бы запусков платформы в своей терминальной сессии пользователь не запустил – все равно из ключа будет забрана ТОЛЬКО 1 лицензия, так?
Еще в текущем уроке говорится, что 1 лицензия будет лишь тогда, когда запуск происходит от имени одного и того же пользователя ОС. Как это понимать? Сервер лицензирования смотрит на уникальность имени машины (домена) + имя пользователя?
Как можно посмотреть, кто же именно (какие пользователи) занимают лицензии в ключе? Стандартными средствами видно только имя машины, но оно для всех пользователей одинаковое – ведь это терминальный сервер…
>сколько бы запусков платформы в своей терминальной сессии пользователь не запустил – все равно из ключа будет забрана ТОЛЬКО 1 лицензия
Да, это так.
>1 лицензия будет лишь тогда, когда запуск происходит от имени одного и того же пользователя ОС. Как это понимать?
Имелось ввиду следующее.
Есть пользователь Ivanov, он осуществляет 2 коннекта к терминальному серверу по пользователями sa, admin.
В этом случае и sa и admin будут занимать по одной лицензии при запуске толстого клиента.
>Как можно посмотреть, кто же именно (какие пользователи) занимают лицензии в ключе?
К сожалению, таких средств на текущий момент нет. Надеюсь добавят утилиту.
По п.2 (получение лицензий)
В тексте урока (1:45) звучит “…посылается запрос веб-серверу на поиск свободной лицензии…”.
А разве лицензию в случае работы через веб-клиент лицензию получает не сервер предприятия, а веб-сервер? Зачем тогда вообще нужна настройка сервера предприятия “Не выдавать лицензии”?
Уточню по ответу:
Конечно же лицензии выдает только сервер приложений. Веб-сервер переадресует запрос на лицензию серверу приложений.
Хорошо, а как же в случае файловой базы? Ведь в файловом режиме с базой тоже можно работать через веб-клиент…
Это единственный случай, когда лицензию получается специальное расширение встроенное в веб-сервер.
Вовремя не скачал, а теперь не дает :(
Пишет: У вас нет доступа к этому файлу (ссылке). Возможно закончился доступ к мастер-группе(ам)
Вы не можете скачать этот файл сейчас
You have an expired period of membership for this master-group
Надо потерпеть до выходных, в выходные будем обновлять модуль управления ссылками
Спасибо за третий вопрос, буду пробовать что нить реализовать)
Я поддерживаю конфигурацию оперативного учета, которая полностью сделана на базе типовой БП. В конфе реализован механизм двух-уровнего резервирования, парарелльных три партионных учета, все управленческие отчеты, механизм гарантийного ремонта и еще много чего. Все это сделано на одной плане счетов, расширенного своей синтетикой и аналитикой.
Из плюсов всего этого, я бы отметил, как метко подметил Евгений – мгновенный сбор баланса по опер.учету. А это очень много значит.+ его очень легко проверить, т.к. проверять баланс по бухгалтерским ОСВ, анализе и карточке счета гораздо удобнее, нежели пытаться выудить нужную инфу из миллионов РН.
Минусы так же, исходя из опыта, также нарисую: чем больше изменений вносится в план-счетов, тем сложнее потом понимать суть проводок, делаемых документом. Нужно обязательно все документировать, иначе можно прийти к ситуации когда Дт и КТ “бьется”, конечные сальдо – ноль, а результат не поддается осмыслению. Все это из-за описания бизнес-процессов в пространстве двойного учета. Если все подробно документировать, то этого не произойдет конечно.
1. Радиобаттоны – порадовали !.. ;))
4. По моему проще и надежнее – поэтапное обновление..
5. Вопрос задавался к материалам 3 блока. Там говорилось, что при создании СубСчета данные могут оставаться на СчетеГруппе.
Поэтому – какой смысл их оставлять на СчетеГруппе?!..
А это все будет зависит от решаемой задачи. Возможно когда-нибудь остатки и обороты по счете-группе имеют смысл.
Они ведь включают в себя – остатки и обороты СубСчетов..
А это смотря как запрос построить.
Если использовать “В Иерархии”, то будут включать, если “=”, то не будут.
Я к тому, что на СчетГруппу – можно было б наложить запрет в проводках..
Все верно, так и нужно делать в большинстве случаев..
Евгений, возникли дополнительные вопросы про выдачу лицензий. Возможно ответы были в базовом курсе, уже не помню, хочется прояснить.
1. У одного пользователя несколько подключений к одной и той же базе данных. На это тратится одна клиентская лицензия или столько, сколько есть подключений на текущий момент?
2. А если у одного пользователя одно подключение к базе данных и одно подключение в режиме внешнего соединения? Одна лицензия тратится или две?
3. У одного пользователя три подключения к трем разным базам данных. Три лицензии занимает?
Спасибо.
Если идет подключение толстым клиентом, то тратиться одна лицензия во всех случаях.
Если тонкий клиент, то все будет зависит от способа получения лицензии:
– самостоятельно тонкий клиент находит ключ, тогда тратиться одна лицензия.
– через веб-сервер, на каждое подключение тратиться лицензия.
А если для 8.1 запускаем две базы на сервере и одну файловую, сколько надо будет лицензий?
Если это делает один пользователь ОС, то лицензия займется одна.
Я заметил, что когда запускаешь под одним пользователем ОС 8.1 несколько сессий и сразу под тем же пользователем ОС 8.2 несколько сессий, то все жезанимаются две лицензии – одна на 8.1, другая на 8.2. Возможна такая ситуация?
Вопрос интересный.
Вообще такого быть не должно (кроме случая, когда лицензии раздаются сервером приложений).
Тем не менее, практика использования многопользовательских ключей иногда говорит об обратном.
Иногда наблюдается нерациональное использование лицензий.
Рекомендации стандартные:
-садить пользователей на конкретные ключи;
-запретить серверу приложения выдавать лицензии.
Орфография в текстах вопросов сохранена авторская? :)
Да, национальная орфография сохранена :)
Думаю, якщо писати українською Ви взагалі нічого не зрозумієте, тому пишу трохи з помилками, вибачайте :)
Да..уж лучше с помилками :))
Google translate в помощь для перевода с украинского на русский =)
але це дивлячись хто, дехто зрозумiв:)
Коллеги, прекращаем отходить от темы текущей МГ.
Под столом.. ;))