Есть замечательный курс со сквозным примером, в котором можно научиться, в том числе, настраивать РОЛИ. Приобрести доступ к курсу можно либо самостоятельно, либо через любого франчайзи 1С в Вашем городе.
Может с атолом путаете? Они цифровую подпись на свои драйвера для WIN10 чуть ли не в декабре 17 года получили и из-за это были некоторые накладки, но опять же не с 1с.
У Вас типовые конфы или самописные? Версии какие? Может могу посоветовать что? Опыт-то большой :).
ФР Штрихи — базовое оборудование, вообще проблем не было. С Феликсами не сталкивался, а значит постараюсь по-возможности избегать. Но исходя из того, что я его не нашел в списке по 54ФЗ, то можно предположить, что и не столкнусь.
Про штрих-сканеры тоже удивили, мы стараемся устанавливать простой USB-HID прибор, во всех конфах на тонких клиентах впахивает.
Спасибо за инфу.
Так я больше для своего будущего интересуюсь списком, вдруг попадется. Чтоб не танцевать лишние танцы вокруг него. И за ОС был бы признателен и за конфу и за комбинации испробованные…
Перечень оборудования возможно опубликовать? Ибо мы сопровождаем торговую сеть и никаких сложностей в достаточно широком перечне оборудования не встречали.
Что значит «локально»? Локальную базу? Нет, серверную, если Вы об этом. Превосходство тонких клиентов в клиент-серверной реализации, когда клиенты — достаточно старые машины, я увидел на внедрении. Но об этом я уже писал.
1. Про шустрость старого интерфейса — специально сейчас запустил БП 3 под толстым и тонким клиентами — разницы не увидел. В общем виде различие между толстым и тонким клиентом — в контексте исполнения. Очень упрощенно: толстый клиент хомячит ресурсы клиентской машины, тонкий — ресурсы сервера. Буквально перед НГ (где-то в октябре) мы внедрили серверную 1с.83 (переход с 7.7), оставив СТАРЫЕ компы, что оказалось экономически выгодным. Скорость работы тоже оценивалась. Это к вопросу о «старых, хорошо живущих»
Про «драйвера» и «через веб» — я предлагаю вам полнее освоить документацию (если хотите дальше дискутировать) и узнать, что такое работа через Веб-интерфейс, что такое работа тонким клиентом через HTTP-коннектор и чем это все отличается. Могу заверить — Вас ждут открытия.
2. Я не настаиваю на универсальности. Более того, именно об этом в первом посте я и говорил. Понимаете, каждое конкретное решение необходимо рассматривать через призму целесообразности.
Но данная статья, если предназначена «для старых и хорошо живущих» — опоздала, целевая аудитория уже наступила (надеюсь) к сегодняшнему дню на все возможные грабли. Для новых или прогрессивных данная статья имеет нулевую ценность в силу наличия новых архитектурных подходов в новых продуктах.
А я как сказал? Я собсно так и говорил: «Технически корректно, но морально устарела».
Понимаете в чем дело, на платформе 8.3 современные конфигурации (БП 3, Розница 2, УТ 11 и пр...) если «режим запуска» выбирать «автоматический» (а чаще всего так они и стоят), то клиенты стартуют в режиме «тонкого клиента». Т.е. именно это режим работы является ШТАТНЫМ для современных конфигураций.
Понимаю, что скрины Вас могут не убедить, а взывать к своему авторитету не могу, т.к. вряд ли мы знакомы. Потому могу предложить скайп в режиме демонстрации рабочего стола. У меня как раз уровень Разраба и все базы коннектятся к серверу по стандартной схеме (а не через прокси). Более того, есть просто локальные базы. Готов принять вызов или хотя бы увидеть аргументы у Вашей позиции.
Статья, будучи технически правильной, морально устарела. Она не освещает архитектурные решения по безопасности, заложенные в современных платформах и конфигурациях. А именно (параллельно отвечая на критику «Чет вы вообще в кучу все собрали...»):
Сегментация может быть достигнута как нарезкой по подсетям, так и нарезкой на VLANы. Тонкий клиент 1с.83 вполне себе замечательно работает через http-коннектор. Такая архитектура позволяет изолировать сервер 1с-SQL от остальной сети предприятия, тем самым решается возможное отсутствие квалификации в области системного администрирования у инженера 1с.
При этом проблема выполнения скриптов в контексте сервера 1с решается _настройкой на уровне конфигурации_. И если 1с-инженеру простительно незнание системы, то за отсутствие базовых навыков в администрировании 1с… лишать гордого звания «Инженер 1С» на общем собрании без права апелляции.
Так же замечу, что http-proxy в корпоративной сети при применении «OwnCloud»-сервера решит проблему ВаннаКрая и снизит до минимума проблему шифровальщиков.
Нет ничего плохого, когда специалисты изобретают велосипед в отсутствие нормальных инструментов, как например в случае с «Трицепсом» (голый SQL-сервер, который надо умудриться закрыть). Но если 1с.83 дает инструменты, то почему ими не пользоваться?
Но всего этого можно избежать, если ориентироваться на модель конфигураций для платформы 8.3. Например все типовые решения уже переведены (в базе требуют) на платформу 8.3 и представляют из себя «тонкие клиенты» на клиентской стороне. А это в свою очередь позволяет вытолкнуть коннект на http-прокси, а сами сервера вывести из домена/закрыть VLANами, оставив в «группе доверия» только разрабов с их конфигураторами. Понятно, что решение подходит не всем и не всегда, но вариант проходной в достаточно солидном количестве случаев.
А как же периоды? Разверну мысль: есть _отчетный период_, есть оперативная работа. И наверное корректней говорить не об абсолютной дистанции, а о периодах работы. Например: идет декабрь, менеджеры работают как хотят в декабрьском периоде, но ноябрьский — только с ведома и разрешения бухов. Тем более, если 700 млн. производственных запасов — то это скорее всего крупнейший налогоплательщик, сдающий отчеты _ежемесячно_.
Бухгалтерия должна быть абсолютно оторвана от реальных процессов и опаздывать недели на две-три за реальностью. Данные в бухгалтерскую программу должны заливаться с такой задержкой.
Если вы попытаетесь управлять процессами на основе бухгалтерских данных, то вы всегда будете управлять тем, чего нет.
Надеюсь, что цитата — просто ирония, которую я не понял. Ну или хотелось бы чуть более развернуто и аргументированно мысль прочитать, если не сложно.
Чуть позднее отправлю в лк ссылку на хорошую инструкцию.
Нет. IIS Windows server например.
В целом все понятно. Успехов в труде и удачи Вашим заказчикам.
У Вас типовые конфы или самописные? Версии какие? Может могу посоветовать что? Опыт-то большой :).
Про штрих-сканеры тоже удивили, мы стараемся устанавливать простой USB-HID прибор, во всех конфах на тонких клиентах впахивает.
Спасибо за инфу.
Повторюсь, что целесообразность рулит.
Что значит «локально»? Локальную базу? Нет, серверную, если Вы об этом. Превосходство тонких клиентов в клиент-серверной реализации, когда клиенты — достаточно старые машины, я увидел на внедрении. Но об этом я уже писал.
Про «драйвера» и «через веб» — я предлагаю вам полнее освоить документацию (если хотите дальше дискутировать) и узнать, что такое работа через Веб-интерфейс, что такое работа тонким клиентом через HTTP-коннектор и чем это все отличается. Могу заверить — Вас ждут открытия.
2. Я не настаиваю на универсальности. Более того, именно об этом в первом посте я и говорил. Понимаете, каждое конкретное решение необходимо рассматривать через призму целесообразности.
Но данная статья, если предназначена «для старых и хорошо живущих» — опоздала, целевая аудитория уже наступила (надеюсь) к сегодняшнему дню на все возможные грабли. Для новых или прогрессивных данная статья имеет нулевую ценность в силу наличия новых архитектурных подходов в новых продуктах.
А я как сказал? Я собсно так и говорил: «Технически корректно, но морально устарела».
Понимаю, что скрины Вас могут не убедить, а взывать к своему авторитету не могу, т.к. вряд ли мы знакомы. Потому могу предложить скайп в режиме демонстрации рабочего стола. У меня как раз уровень Разраба и все базы коннектятся к серверу по стандартной схеме (а не через прокси). Более того, есть просто локальные базы. Готов принять вызов или хотя бы увидеть аргументы у Вашей позиции.
Сегментация может быть достигнута как нарезкой по подсетям, так и нарезкой на VLANы. Тонкий клиент 1с.83 вполне себе замечательно работает через http-коннектор. Такая архитектура позволяет изолировать сервер 1с-SQL от остальной сети предприятия, тем самым решается возможное отсутствие квалификации в области системного администрирования у инженера 1с.
При этом проблема выполнения скриптов в контексте сервера 1с решается _настройкой на уровне конфигурации_. И если 1с-инженеру простительно незнание системы, то за отсутствие базовых навыков в администрировании 1с… лишать гордого звания «Инженер 1С» на общем собрании без права апелляции.
Так же замечу, что http-proxy в корпоративной сети при применении «OwnCloud»-сервера решит проблему ВаннаКрая и снизит до минимума проблему шифровальщиков.
Нет ничего плохого, когда специалисты изобретают велосипед в отсутствие нормальных инструментов, как например в случае с «Трицепсом» (голый SQL-сервер, который надо умудриться закрыть). Но если 1с.83 дает инструменты, то почему ими не пользоваться?
Спасибо