Зравствуйте!
ККМ тормозит через RDP. Проблема давно известная.
Около 120-130 торговых точек, все через мобильныю связь (модем-флешки), через RDP работают в общей базе 1С. Попытался подключть ККМ. В офисе все работало нормально, на торговой точке - жуткие тормоза. Смену открывает 70 секунд, чек с одной товарной позицией печатает столько же, если не дольше. ККМ АТОЛ FPrint-22. Пинги 50-60мс, но есть торговвые точки, где связь хуже.

1. Кто-нибудь слышал о решениях данной проблемы? Я полистал форумы навскидку - ничего дельного не нашел.
2. Может написать для торговых точек тонкий клиент, чтобы не работали на RDP?

Перевести ККМ на работу через сетевой интерфейс а не через РДП

LAN

(0) У вас больной админ, ногами его ногами.

Если конечно зп платите, причем хорошую.

VPN что ли организовать с каждой точкой?

(3) что не так? какие видите варианты? только если скажете про то, что на каждой точке должна быть своя база, которая должна регулярно синхронизироваться с основной, я скажу, что Вы тяжело больны

(3) и какое решение? Такая же проблема. Причем если в одной сети работают, то нормально. Если через инет (VPN), то тормозит

(5) Упал инет на сервере (основной и резервный) - и 120-130 точек "курят бамбук" ?

Один юзер зашел 100 раз в одну базу - сколько лицух осталось свободных?

(6) Ну так не переведите ККМ в режим сетевого устройства и путь он напрямую с 1С работает, а не через РДП с пробросом устройства.

(6) Только РИБ для ОФ или еще веб-клиенты для УФ (тонкие через веб)

(8) а можно, пожалуйста, чуть поподробнее. я не понял, извините. и мне кажется там в начале стоит лишняя "не" - опечатка?

(8) допустим, я строю VPN с удаленным компом (такой опыт уже есть), у удаленного компа есть свой локальный IP, и в настройках драйвера ККМ я устанавливаю его?

Проблему решает использование службы FDSVC

(12) Плюсик этому господину

Советующие FDSVC и прочие подобные методы, прочитайте еще раз кол-во "точек"!

120-130 соединений с сервера (по vpn ибо серые ip на точках) исходящих по FDSVC на точки. Нюню...

(12) а вытянет столько касс?

Идиотизм тягать туды-сюды порты для касс (кассы на точках, база на сервере).

Не проще или базу на точки или клиента тонкого/веб на точки???

(16) Базу на точки тот еще геморой. Не лучше чем 120 устройств. А по тонкому клиенту - может у него толстые формы.

(16) базу на точки - не проще, а клиента тонкого - думаю над этим.

Да и 120 соединений нормально. Там же не потоковая передача. Когда чек отбивается только. А одновременного отбития чеков на 120 устройств такое вряд ли.

(19) И что будет в одном часовом поясе,в час пик:))))

продавщицы - тупые базарные девки, раньше таких ПТУ-шницами называли, они вообще не знают с какого бока к компу подойти. Я работал как-то в организации, где было 28 торговых точек с самостоятельными базами - замучался заставлять их вовремя синхронизироваться, даже специального сотрудника завел для этого. А тут 120-130 точек (постоянно колеблется, нерентабельные закрываются, новые открываются)

(21) это я про РИБ говорю - не вариант

(20) Да ничего не будет. Там данных то передается мизер. Если у него 120 сейчас по рдп работают.

А канал лучше нельзя из за аренды на точках?

(22) и к тому же руководство избаловано тем, что привыкло видеть актуальную картину продаж, а не ждать, пока все синхронизируются

(24) умножьте цену любого приличного интернета на 120.

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

(26) если на инет жалко тогда ой,удачи

(24) Канал хороший нужен только на центральной базе.

(29) это без проблем

(29) тогда не понял претензий в (0)

(31) Претензия простая: "У нас работают криворукие ленивые дятлы, почему у нас так все плохо?"

(31) Проброс устройств через РДП не любит задержки. Из за этого так медленно. Через FDSVC уже будет пофиг на задержки.

(29) Подробнее можно,чем проброс или еще что там улучшит скорость канала?

(32) ой, тут умный выискался - предложил локальную базу. Сколько у тебя точек в организации?

(31) так на точках то канал слабый

(33) у меня обратный опыт,но может я чего не знаю

(34) Ну ты представляешь как проброс устройств выполняется через РДП? Тогда бесполезно объяснять.

(38) канал с задержками,как поможет eou

(39) tcp на себя возьмет все задержки. Еще доотправит пакеты, если не дошли, сожмет ну и прочие хитрости tcp\ip.

+ (40) ТСу нужно просто взять и попробовать.

(40) и потери пакетиков))я тебя понял,лучше rdp,но все же из г-на конфетку не сделаешь.Думал,что-то новое придумали

(42) Ну вот представь устройство постоянно посылает данные через рдп. Каждый кадр пересылается. Доходят не все, не в той последовательности доходят, по новой переотправляется.
Там потоковая передача данных.
С tcp такого не будет. Отправляются данные. Формируется пакет, пакуется, разбивается на фреймы в зависимости от размера. И отправляется. Там нет потоковой передачи.

(5) Не РИБ, а обмен через xml с локальными базами. Связка УТ+Розница чем не вариант?

+ (43) Это примерно как ютуб и миста.

(35) Сча всего 5, но работал на предыдущих работах с 160+ а до этого на 77 было 250+

(33) читаю про это (44)

(44) это еще хуже

(46) и как следили за своевременной синхронизацией? даже если автоматику настроить, все-равно она будет глючить, сбиваться. у меня руководство избаловано - всегда знает точные продажи

Мне в своё время пришлось самому написать прокладку для печати чека по принципу - файл из 1с на печать чека, из проги уже идет распечатка чека на ккм. Все команды по такому же принципу (открытие кассовой смены и проч).
На инфостате видел платную подобную разработку.

(12) + 100 500

(48) Хм, инет упал- база не доступна - торговля встала, тем более при ваших "свистках".

(52) Ну так сейчас, их, при свистах все устраивает.

(0) Выше не читал, возможно кто-то уже предлагал.

Сталкивался с подобной проблемой, вроде и пинги нормальные, канал широкий, и связь стабильная, но чеки долго печатает, работать не возможно.

В результате оказалось, что два провайдера, один на точке, второй в офисе, вот между ними есть какой-то параметр сети, который влияет на передачу данных. Не админ, попытался объяснить как мог, проблема была в этом. Перешли на один провайдер и на точке и в офисе, в результате все идеально. Хотя канал интернета стал "уже", пинги не изменились, но вот этот параметр задержки между провайдерами ушел

(53) это смотря какая ккм и ассортимент, если автономная , то ей пофиг на стороннее ПО, бей сколько хочешь- потом внесешь в базу, а с их машинками без базы уже ничего не пробьешь, только по "мягким" чекам, но это уже на свой страх и риск.

В общем, подняли VPN, через него смену открывает 15 секунд, чек печатает 9-10 секунд. Это уже терпимо, лучше не будет.
Кто работает через RDP, поднимайте VPN с локальной машиной и подключайтесь к локальному IP.

(56) Это долго. На чем впн развернули? Покажи пинг от точки к серверу и от сервера к точке.

Игрался раньше в "как можно подешевле интернет через 3G-свистки, на кой я буду платить этим барыгам".
В итоге: день простоя POS-терминалов приема безнала оказался дороже сомнительной выгоды от сомнительной экономии.
Я за вариант: "проводной интернет + VPN (L2TP/GRE) до центрального офиса + FDSVC".
Убедите свое руководство не жлобиться и заложить расходы на связь.

(56) А ты более 32 касс подключи через проброс портов.
Если подключишь 33 одновременно я сильно удивлюсь.

Люди правильно советовали FDSVC

(59) не помогает один черт тормозит. Хотя конечно поменьше.

Я на РИБ перешел, но 130 точек...

Нужно просто нааисать virtual channel dll,и через нее данные чека передавать,один пакет с гарантированной доставкой и никакого vpn не надо

(61) Отдельный РИБ сервер для центральной базы.

Центральный склад/офис работают в отдельной периферии с полной синхронизацией.

Или выкинуть уже ОФ и перейти на УФ с тонкими/веб клиентами.