Медленно печатает принтер через rdp

Обновлено: 24.04.2024

Добрый день! Проблема - тормозит печать чека на фискальном регистраторе при печати из 1С через RDP (удаленная точка, подключена через интернет по выделенке). Печать занимает 8 секунд. Прилагаю скриншот с замером времени, из которого видно, что именно операции с драйвером занимают все время.

Сервер - 16 Гб памяти, нормальный
Связь по выделенке, нормальная
1С - Комплексная автоматизация 1.1
ФР - атоловский FPrint
драйвера - атоловские, стоят на сервере, на клиент RDP пробрасывается порт

Отпишитесь, плиз, кто сталкивался с подобной проблемой

Для начала. (возможно эти рекомендации уже решат твои проблемы) Сделай следующие вещи.

1) Если на сервере есть физические СОМ порты, то задай им такие номера, что бы случайный появившийся маппинговый порт их не перекрывал.
ПРИМЕР:
Физический СОМ1 => СОМ61
Физический СОМ2 => СОМ62

ВАЖНО!
Это касается и возможных виртуальных портов на сервере (при временном подключении какого нибудь USB устройства с эмуляцией RS232.

2) Раз у тебя есть вариации работы по ADSL.(Да чего греха таить многие провайдеры и по Ethernet подключают методом PPPoE)
То нам необходимо защитить пакеты для предотвращения дропа и(или) фрагментации пакетов промежуточным устройством при прохождении через программно-аппаратный туннель провайдеров.
Для этого достаточно изменить размер MTU сетевой карты. Как правило у Windows размер MTU = 1500 байт . Количество байт для инкапсуляции может быть различным. Но больше 50 байт инкапсуляцию уж точно никто не делает.
Поэтому достаточно изменить размер MTU = 1450 байт .
При чем меняй размер и у сервера и у клиентов. Т.к. неизвестно где какой провайдер.

ВАЖНО!
После изменения размера MTU компьютер необходимо перезагрузить! Для вступления настроек в силу.

Как менять размер MTU описывать не буду. в интернете полно примеров. Вот один из них Изменение MTU в Windows

После этого проверь скорость печати чеков.

П.С. И не используй для ФР через маппинг большие скорости UART. Не больше 57600. Зачастую 9600 и 19200 достаточно.

П.П.С А вообще MTU лучше подбирать опытным путем , до тех пор пока пакет передачи данных перестанет фрагментироватся.

Для это выполняй такую команду
ping адрес_назначения - f - l xxxx где (хххх - это размер пакета в байтах)

Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт.
Фрагментируемый пакет будет отображаться так

а вот как только он станет отображаться следующим образом

Значит пакет прошел сразу! Целиком без разбиения на части и потери драгоценного времени. (Т.к. любое разбиение пакета заставляет генерировать новую контрольную сумму, добавь к этому еще и генерацию контрольной суммы на шинах RS232)

После это побробуй немного увеличить размер, по 2-3 байта, что бы найти оптимальную точку когда пакет не дробиться.

Слишком маленький MTU тоже не сулит ничего хорошего.

П.П.П.С
Кстати если работа с 1С в режиме тонкого клиента тормозит. а интернет вроде как работает. "Поиграться" с MTU то же имеет смысл.

Прилагаю скриншот с замером времени, из которого видно, что именно операции с драйвером занимают все время.
Это не удивительно, честно сказать ни разу не видел, чтобы печать чека через RDP при удаленном сервере работала быстро.
При локальном серваке обычно проблем нет 1. RDP - в локалке или через инет?
2. Скорость на портах какая? (на компах и на ФР)
3. Локально если подключить ФР скорость печати такая же, или шустро печатает? (Исключить кривость драйвера. Т.к. например у Штриха есть драйвер 1С-ных и тест-драйвер это разные длл с разным набором функций.)

(5) Kutuzov, Если хотите получить дельный ответ сообщите:

1. Пинг с клиента на сервер.
2. Попробуйте распечтать (чек, Х-отчет) на ФР который локально подключен к клиенту. (Тупо дровина может быть не хорошая)
3. Скорость портов какая? (Пример штрих АСПД максимум 57600 поддерживает и наблюдалось улучшение работы при снижении скорости портов)

Вы же когда к врачу приходите отвечаете на его вопросы, показываете результаты анализов. Одним замером производительности не обойтись))))

Оказывается, это известная проблема. На момент этой темы штатного решения не было.
Может, у кого-то есть опыт решения такой проблемы, используя локальный сервер печати и т.д.?

Конечно известная проблема :) Все думают о пингах и ширине канала. А зрить нужно в корень.
Механизмы передачи пакетов данных TCP, RS232. То о чем выше писал.

Надо запомнить главное! Быстрый - не значит качественный!

10000 гастробайтеров быстрее перенесут тонну кирпичей, чем один погрузчик, но это не значит, что это лучший вариант :)

Я рекомендую не использовать маппинг СОМ-порта через RDP.
Используйте механизм RS232-Ethernet-RS232 т.е. проброс портов по сети.
Для этого прекрасно зарекомендовала себя программа(бесплатная) Tibbo Device Server Toolkit

Устанавливается на торговых точках(серверный режим) и на сервере(клиентский).
На торговых точках необходимо настроить проброс TCP порта для программы.

Пример:
Настройки точек для ком порта на самом компе указывает только порт прослушки (и этот порт прослушки пробрасываем "наружу" в интернет)
(Точка-1) com1 = внеш.адрес: 123.123.123.123 порт: 7000
(Точка-2) com1 = внеш.адрес: 223.223.223.223 порт: 7000

Настройка сервера для созданных виртуальных комп портов указываем адрес и порт.
адрес: 123.123.123.123 порт: 7000 = com1
адрес: 223.223.223.223 порт: 7000 = com2

Получаем на сервере СОМ-порты на каждую торговую точку. В настройках Торг.оборудования настраиваем ФР каждой кассы на соответствующий порт.
Скорость ком. портов лучше делать небольшую.
от 19200 до 57600.И тайм аут выставлять в 300 мс. (Лучше немного поиграть с этими настройками)

На текущий момент в таком режиме работает порядка 40 магазинов заказчиков.

(9) bzmax, круто)
а сколько по времени печатается чек с такой архитектурой?

(10) Kutuzov,
Тут главный момент, что на конкретный сом-порт, конкретный туннель-устройство.

А при RDP если на нескольких точках касса на COM1, то и для каждого сеанса устройство будет на COM1.
Т.е. технологически на сервере получается несколько COM1 (но в разрезе разных сеансов).
А как такой механизм работает неизвестно потому как документации нет.

Мой же механизм реализует идентификацию COM портов, независимо от сеансов!

Главное правильно настроить соответствие "настройки кассы"-"COM порт"
А то может получиться такое:
Покупку пробили в Череповце, а чек вылез в Самаре :)

Для начала. (возможно эти рекомендации уже решат твои проблемы) Сделай следующие вещи.

ВАЖНО!
После изменения размера MTU компьютер необходимо перезагрузить! Для вступления настроек в силу.

Как менять размер MTU описывать не буду. в интернете полно примеров. Вот один из них Изменение MTU в Windows

После этого проверь скорость печати чеков.

П.С. И не используй для ФР через маппинг большие скорости UART. Не больше 57600. Зачастую 9600 и 19200 достаточно.

Для это выполняй такую команду
ping адрес_назначения - f - l xxxx где (хххх - это размер пакета в байтах)

Слишком маленький MTU тоже не сулит ничего хорошего.

Начинаешь с 1500 и потихоньку снижаешь размер по 10-12 байт
Для ОС семейства Windows в команде ping после ключа -l указывается не MTU (Maximum Transmission Unit), а MSS (Maximum Segment Size)
И начинать надо не с 1500, а с 1472. От 1500 (размер кадра Ethernet) отнимаем 28 (размер заголовков протоколов IP и ICMP, которые добавляются к пакету), получаем 1472 (максимальный размер пакета, проходящего через интерфейс Ethernet). А есть инструкция, как настраивать на локальной машине, где стоит касса, и как настраивать на сервере терминалов? Не понятно, как Tibbo Device Server Toolkit должен со своего виртуального порта пробросить уже на физический порт. Как правило моментально.
Т.к. создаються отдельные каналы-туннели по которым передается просто текстовая строка (команды драйвера в фр и обратно)
А т.к. на каждый девайс свой канал, то приоритет у него единственный-высший :)
а по RDP валит сборная солянка всяких перенаправлений и какой пакет имеет высший приоритет одному богу и команде Билла известно :)

Кстати совсем забыл.

Но это только для тех у кого Штрих-М
Ребята с Ростова сделали Драйвер-Сервер под "штрихи".
Механизм простой.
На торг.точке ставиться эта программулина у неё есть TCP порт (возможна работа по SSL- шифровани данных)

Через этот порт можно и управлять фискальником и печатать. Когда серверу нужно напечатать чек, он формирует xml-ку и пуляет её по нужному порту в нужный адрес. И все!
Офигенно надежно и быстро, своими глазами видел целую сеть АЗС на данном механизме.
Никаких сом-портов и потерянных сессий.
И главное(!) кроссплатформенность!

Подниму тему
С одним лишь отличием: регистраторы печатали быстро,а теперь всё медленее и медленее. Т.е. проблема не врожденная,а приобретенная
Скоро чек 20 сек займёт. Причём сначала думает долго, потом печатает понемногу, отдохнет 3-5 сек и дальше печатает, отдохнет 3-5 сек и дальше печатает.

Портов нет с одинаковыми номерами.
Это происходит на всех регистраторах и на всех компах. Даже есть функция ОТКРЫТЬ ЯЩИК ( т.е. без печати текста) и то она жутко тормозить стала
феликс-02к

Подскажите где можно копнуть

(16) camel, перезагрузить таки сервер. Добавить ему память. Сделать тестирование базы. Перевести базу на SQL. Проверить сеть. Ну и т.д. Кол-во вариантов - бесконечно.

(17) spacecraft,
Перезагружал. Загрузка памяти совсем небольшая.
И конечно подкупает тот факт, что еще месяц назад всё работало исправно и быстро.

Естественно, должна стоять галочка "использовать локальные принтеры" на клиенте и снята галочка "запретить перенаправление принтеров" на сервере. Имя принтера должно в точности (вплоть до регистра) совпадать с именем его драйвера на сервере.

А ещё лучше использовать пакет ScrewDrivers и подобные, но это довольно дорого.
Насчет ScrewDrivers вот что мне ответили на одном известном форуме: "Дорого, потому что нет лучшего решения. Всё что ты выше написал - мура, проверенная многолетней еблей с печатью. " Так что решайтесь =)

UPD:
Большинство принтеров будут корректно работать в терминальной сессии, если разрядность операционных систем сервера и клиента совпадает. То есть если на серве Windows 2008R2 (а она выпускается только в 64-разрядной редакции), а на клиенте - Win XP 32, то 90%, что принтер в терминале печатать не будет. А если на клиенте Windows 7 x64 - 90%, что проблем не будет.
Возможно, ещё играет роль семейство ОС (т.е. Win7 не будет печатать на WinServ2003 и наоборот). Хотя это лишь догадки - не проверял. Если кто знает - добро пожаловать в комменты!
Если клиент не в локальной сети, а в интернете - поднимайте VPN.
Ещё можно почитать здесь.

19 комментариев:

У меня, например, почти не возникает проблем при печати по RDP server 2003, разве что с экзотическими принтерами. Но, правда и сеть у меня без доменов.
Вот только недавно мудохался, чтобы печать на принтер, который находится в другой локальной сети от клиента.

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

1) Установите дрова принтера на клиент к которому физически подключен принтер, протестируйте печать на прямую с компа (без RDP)
2) Разшарьте принтер на клиенте чтобы он был доступен всем, установите полные права для всех пользователей на этот принтер
2) Установите на сервер драйвер принтера (такой же как и на клинете, только для соответсвующей ос) на который будете печатать
3) При подключение к серверу терминалов, проверьте, чтобы стояла галочка возле "принтеры" на вкладке локальные ресурсы

4) проверьте печать с компа по RDP к которому подключен принтер, для начала пробуйте под учётной записью админа. по идее принтер должен подхватиться и с клиента сразу печатать без проблем. Если не печатает, смотрите вкладку порты в настройках нужного принтера на сервере, бывает, что не правильно подхватывает порт из-за этого не печатает вообще или печатает не туда куда надо.
4.1) драйвер на клиенте и на серевер должен совпадать (у меня было на клиенте драйвер на HP PCl 5 а на сервере PCL 6.0 из-за этого не работало)

5) Если клиенты нах-ся в одной локальной сети подключитесь к розшареному принтеру (для этого у Вас должно работать сетевое обнаружение и доступ к файлам и ресурсам по локальной сети) тут могут быть заморочки с антивирусами, брэндмаурами (но это другая тема)

Вот такие бубны ))

Статья написано криворуким админом. Работает все и всегда. надо только правильно руки приложить. Даже через EasyPrint работают все принтеры с ПРАВИЛЬНО и ПОЛНОСТЬЮ установленными родными дровами, установленным Net.Framework 3.51 и клиентом 6.1 (лучше 7). Как пример - Canon LBP800. При правильных дровах работает с машины XP x32 в терминалах 2008R2 и 2012R2

. написал человек из 2016 года к статье 2011

Здравствйте, помогите пожалуйста с решением проблемы. В свойствах перенаправляемого принтера нельзя выбрать оригинальный драйвер принтера, а там стоит Remote Desktop Easy Print.
Как поменять на оригинальный драйвер?

Какое то собрание домыслов и суеверий. Феерия мракобесия.

"Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Перенаправление принтеров"
Параметр "Использовать в первую очередь драйвер принтера Easy Print удаленного рабочего стола" перевести в состояние "Отключено"

А лучше всего освоить ScrewDrivers и наслаждаться .

Вот говорите работает все и всегда. Но вот вопрос: WIn2008r2 домен принтеры подключены локально без сервера печати. То есть при заходе по RDP пользователь заходит под своим доменным именем и печатает всякую штуку. Но то и дело бывает отваливается печать и помогает только удаление папки пользователя с терминального сервера. При повторном входе пользователя на сервер автоматически создается новая папка пользователя на этом сервере и все прекрасно начинает работать, до поры до времени. Так вот, как бы избавиться от удалений папок пользователей и все таки решить проблему?

У большинства компаний работа с 1С организована через удаленный рабочий стол. Если рабочее место кассира и сервер с 1С находятся в разных локальных сетях возникает проблема со скоростью печати чеков. Скорость печати чеков по RDP может занимать от 15 до 60 секунд и даже больше. В статье я опишу самый простой бесплатный вариант решения проблемы скорости печати чеков по RDP на ККМ АТОЛ, подключенной через USB.

Подробная инструкция для подключения кассы АТОЛ по RDP я описывал в статье Подключение ККМ АТОЛ 55Ф к 1С на удаленном рабочем столе. Для 10-й версии драйвера ККМ подключение производится аналогично.

Скорость печати чеков резко упала после удаления «Службы FDSVC» из драйвера ККМ, начиная с 9-й версии. Сделано это было с целью обезопасить своих клиентов, т.к. часто администраторы оставляли возможность подключаться к ККМ с любых устройств и сетей.

Увеличиваем скорость печати чеков по RDP

Чтобы увеличить скорость печати чеков по RDP нам необходимо подключаться к кассовому аппарату напрямую, не через RDP. Но как это сделать, если возможности подключить ККМ к локальной сети нет?

На помощь нам приходит небольшая программа под названием Com2tcp. Данная программа позволяет подключаться к COM-порту по IP адресу через открытый порт.

Скачиваете программу Com2tcp на компьютер, где установлена касса АТОЛ. Скаченные файлы переместите, например, в папку «C:\services». Можете использовать любую другую папку на свое усмотрение.

Для создания связи «TCP/IP порт — Com-порт» необходимо запустить com2tcp.exe со следующими параметрами:

com2tcp \\.\COM3 9999

Где \\.\COM3 — Com-порт кассы АТОЛ, 9999 — TCP/IP порт, к которому мы будем обращаться.

Для быстроты запуска можно создать ярлык для com2tcp.exe с заданными параметрами.

Дальше необходимо открыть порт 9999 для внешних подключений. Для этого у вас должен быть выделенный IP адрес, либо воспользуйтесь сервисами DDNS.

Для открытия TCP/IP порта необходимо в настройках роутера прописать данные виртуального сервера (или перенаправление портов, все зависит от модели роутера).

внешний порт (может быть любой свободный порт, к нему подключаемся из вне);
Локальный адрес компьютера, к которому подключена касса и на котором запущена программа com2tcp;
Локальный порт, который прописывали в параметрах com2tcp.

В окошке com2tcp мы можем увидеть, что к COM3 порту было обращение.

Настройка подключения по TCP/IP к АТОЛ в 1С

Теперь необходимо прописать новые настройки для ККМ в 1С. Для этого переходим в настройки оборудования и прописываем подключение к ККМ по TCP/IP, указывая внешний IP адрес и порт.

После сохранения настроек нажмите на «Тест подключения». В случае отсутствия ошибок настройки в течение пары секунд вы получите информацию о вашей ККМ.

Таким образом можно совершенно бесплатно, без покупки сервера печати, ускорить скорость печати чеков по RDP.

Для безопасности рекомендую разрешить подключения к открытому порту только с IP адреса сервера с 1С настройками файрвола или роутера.

Последние статьи:

Поблагодарить

Если вам помогла информация на нашем сайте, то вы можете перевести нам любую сумму в качестве благодарности.

Часть переведенных средств пойдет на оплату обслуживания сайта, оставшаяся часть денег будет переведена в благотворительный фонд.

Реквизит "кассир" (тег 1021) и "ИНН кассира" (тег 1203) могут не включаться в состав ФД в случае применения ККТ для расчетов, осуществляемых с использованием автоматических устройств для расчетов. Реквизит "кассир" (тег 1021) содержит фамилию, имя, отчество (при наличии), должность, а реквизит "ИНН кассира" (тег 1203) содержит ИНН (при наличии) лица, уполномоченного пользователем для формирования ФД.

(37) т.е если расчеты не онлайн, и у физлица есть ИНН, то должен присутствовать, как это будет контролироваться, хз

(39) только физическим визитом.

Можно подытожить? На 9 версии драйвера нет штатных решений по нормальной печати (FDSVC нет например в нем)? 8 драйвер не подходит, т.к. не дружит с ФФД 1.05 и новыми прошивками, а 10 драйвер - потому что нет на толстом клиенте и обычных формах. что делать то. покупать сервер печати за 5 к на раб.место не охото. Советуют шить на 70** прошивку, там якобы скорость нормальная

Почему 8 драйвер не дружит с ФФД 1.05 и новыми прошивками-то? Мне прошили вот только что АТОЛ 11ф, поставил 8.16 последнюю - вроде все фурычит.
(41) фурычит, но передается все по умолчанию, как задано в драйверах, если захотите поменять какую информацию из 1С, например передать информацию, что платеж является авансом, то не получится
у 8.16 есть один косяк - на него антивирь от win10 брешет при установке. Но это решается - добавляешь установочную папку и папку куда устанавливать в исключения, и вроде встает и даже работает.
(41) у меня ручные скидки в рознице2 и ут11.4 не работали с 8х версией
(41) также не будет доступна продажа сертификатов и их зачет, либо одновременная продажа номенклатуры и услуг
(43),(50) соответствующие свойства в драйвере я вижу - ItemType, PaymentMode. Получается, что их модификация не дает ничего?
(52) так проблема с конфами 1С или с драйверами? Первое меня вообще не волнует, у меня все самописное
(52) дает, я говорил .что если работать черз компоненту, которая идет в официальных обработках
(55) А, ну и хорошо. Значит, просто разрабы 1С не хотят нормально восьмые дрова поддерживать. ну что ж, бывает
(56) да атол тоже красавцы. вы попробуйте с ними пообщаться на форуме. на все вопросы один ответ - напрямую из драйвера работает, тогда это вам к 1С. а то что они не могут договориться с 1С насчет своих библиотек годами - пофиг. и видимо свои ресурсы ценят больше чем пользователей
(58) Ну, то что нет в жизни щастья, мы знаем. Тем не менее, есть покой и воля, т.е. иными словами, заставить работать можно.
На первой же странице найдете кучу решений. Выбирайте что вам нравится.
(62) Мы разработали драйверы виртуального ККМ (API для ККТ и для ФР), который ретранслирует типовые запросы на драйвер производителя кассы, используя промежуточную программу-сервер.
Результат - печать со всех типовых 1С (и новых и старых) на онлайн кассы.
Скорость отклика из RDP - меньше полсекунды - и чек печатается из RDP сеанса.
небольшой допил 1С - и печатаем с нескольких рабочих мест.
Могу помочь с тестированием, если интересно.
На видео похожая ситуация - симптомы и излечение за 15 минут :)
Коллеги, на видео можно увидеть применение сторонней обработки печати. Дело в тормозах печати не в ней, а в том, что используется стандартная схема печати с сервера через проброшенный в сеанс комовский порт.
нами замечено, что при пинге больше 50мс часто возникает проблема долгой печати кассовых чеков.
Мы раскопали и причину такого поведения. Она кроется в особенностях протокола управления ккм. Во многих местах при реализации печати драйвер ждет ответа от ККМ , причем время ожидания весьма мало (часто 5мс). Получается канал связи просто не успевает передавать с нужной скоростью сигналы от драйвера к ККМ и обратно.
Если такое случается, то фиксируется режим обрыва связи и отправляется повторная команда.
Меня удивляет, что чек все таки в таких условиях вообще печатается, после тысяч попыток повторов на разных стадиях печати!
Решал проблему путем статического айпишника и проброской порта в роутере .
(70) Может и поменялось уже что-то. Был в командировке.
Для (0) нужна обработка ТО (т.к. у него КА 1.1.) Две недели назад - были только обработки с поддержкой драйвера Атол 9.
Есть уже новая версия типовой обработки ТО?
Для текущих типовых на управляемой форме понятно - драйвер если совместим с API 1С - он сядет автоматом.
(71) а если в обработке ТО загрузить драйвера 10, не взлетит КА 1.1 с этой обработкой?

(0) (2) (23) Сожалею вашей проблеме. Но решение, а точнее костыли, есть. Ниже читаем

2) Новые релизы 1С уже криво поддерживают ДТО8. Даже новые версии. Однако в 8ой есть и сервер, и подключение по IP. Но всё это уже через дописание руками.
3) Я задавал этот вопрос ТП Атол. Вот его ответ:
[1C]
Здравствуйте!
Имеется компьютер с подключенным ККТ АТОЛ 30Ф, и Управление Торговлей 10.3 через RDP. Операционная система Windows 7 x64. Работаем посредством проброса портов. На удаленной машине используется дто за версией 9.11. Операционная система Windows Server 2012 x64. Собственно проблема заключается в том, что пробитый чек приходится ждать без малого +/-3 минуты. Тест связи с ккт из 1с проходит за 30секунд, Закрытие смены +/-1,5 минуты.
Есть белый IP, но насколько известно в 9дто не реализована работа по ip через 6220 порт.Есть ли возможность уменьшить время ожидания чека, или всё упирается в скорость сети интернет?
Логи с сервера и локального компьютера прилагаю. В логе последние операции.

Общение по инциденту:
вх.(15.03.2018 11:33:29)
Материалы:

Работа по сети упирается в ограничение Платформы 2.5 , когда в ответ на команду должно прийти подтверждение, и в ограничение пакета данных.
Эта проблема решена в Платформе 5.0 и ДТО 10, на которые планируется перейти до конца года.

Если рекомендации помогли, просьба закрыть обращение.
Спасибо.
вх.(19.03.2018 17:09:52)
Уточненная информация - будет реализован в ДТО 10 веб-сервер, который позволит работать по сети без текущих ограничений.
Сроки выхода пока неизвестны, это не ближайшая перспектива. Если вам нужно реализовать рабоу сейчас, то пользуйтесь текущим ПО.

Если рекомендации помогли, просьба закрыть обращение.
Спасибо.[\1C]

Я не знаю, что за платформа 2.5. Может знающие люди тут ответят.

А теперь варианты решений:
1) Установка тонкого\толстого клиента локально на компьютере где подключена касса. (не всегда помогает)
2) Дописание 1С до работы с ДТО 8\10 и использовать его возможности (Снятие с поддержки, решение для программистов)
3) Сменить провайдера. (Честно, у меня клиент перешел на другого провайдера и у него чеки полетели!)
4) Получаем белый IP адрес на точку, где подключен ККТ. Ставим программу Virtual Serial Ports Emulator. Она позволяет обращаться напрямую к порту через IP. Делаете проброс в роутере и в 1С в настройках делайте подключение через IP адрес. Проверенно, работает (Минусы: 1) Наличие белого IP 2) Программа условно бесплатная. Пока не купишь, она настройки не будет сохранять. Поэтому после перезагрузки компа, необходимо снова её открывать и настраивать. Это дело 1 минуты, если сделать мануал)
5) Ждать, когда всё перейдет на дККТ 10

Читайте также:

Медленно печатает принтер через rdp

19 комментариев:

Увеличиваем скорость печати чеков по RDP

Настройка подключения по TCP/IP к АТОЛ в 1С

Рубрики

Свежие комментарии

Поблагодарить