Доброго
ТСД организация максимального быстрого обмена с базой.
Есть пачка ТСД. Анроид.
Есть БД, пока файловая.
Но будет серверная, на отдельной машине, с быстрыми дисками.
Все самописаное. Так ограничений по версиям, технологиям и прочему нет.
Любой каприз, за разумные деньги конечно.
Задача обеспечить верификацию при сканировании шрихкодов.
То бишь, некий оператор(их пока десяток, но будет больше) берет в руки ТСД и идет сканировать паллеты, ящики  и прочее.
Ему необходимо максимально быстро проверить есть ли такой штрих код в общей базе, и зарезервировать его если он есть.
На текущий момент там их около шести миллионов записей. Прогнозируемое увеличение миллион в месяц.
В общем рад любой идее.
Заранее спасибо.

А кто пробовал по rdp с тсд работать?

(8) ТСД. Чтение DataMatrix  - я пробовал, купили ПО потом после моих проб)

(0) Миллионы марок, подсистема марочного учета самописная, а не эта вот ваша от 1С на ТабЧастях и диких справочниках с десятком реквизитов. 50 операторов ТСД в одной базе, через Тонкого.
Сидят все через десктопы, которые стоят на складе, но в решении есть поддержка RDP (так как есть клиенты на УТ-УТАП10.3) и есть поддержка МобильногоКлиента (есть клиенты на УТ11-УТАП11, ERP).

Все онлайн.


Покупайте.

Сейчас даже точный срез по количеству марок по месяцам покажу.

(8) Работать по РДП можно, если оффлайн работа совсем не нужна.

http://prntscr.com/pcto7y

(10)видел я ваше решение. Нам такое не надо.

(14) Ну у нас есть отдельно ТСД под типовой 1С-КТ2000 помарочный.

(12)Нужна скорость. У меля ТСД превращается в сканер с экраном. Оффлайн работа не нужна.

(11) Спаиваете народ, Волшебника на тебя нет

(15) Есть у нас типовая от КТ-2000. После того как Ежов смылся, там вообще все печально стало.

(17) Ну я лично не пью. Производством алкоголя не занимаюсь. В бутылки не разливаю. Чисто бизнес - ничего личного.

(18) Так вот он, я, вернее, мы. У нас - все - весело и играет музыка.

На данный момент, в подсистеме ТСД зарегано 63 кода ошибки. Тоесть, это 63 ситуации, когда при сканировании марки-упаковки, что то может пойти не так. Вы уверены, что пройдете наш путь в 2 года?

(18) Да, их решение учитывать марки на РС, подчиненном регистратору, вызывает попоболь уже сейчас, через 2 года. Доки, регающие даже одну марку, проводятся по 2-4 секунды у достаточно объемных клиентов. Толи еще будет...

(16) Значит, РДП вполне вам подойдёт.

(20) Приветствую.
А я уже его прошел. У меня декстопе все пучком. И с ТДС, до недавнего времени, тоже. Но количество резко возросло, ТСД в оффлайн работа стало печальна, захлебываются.
Во ведем везде вайфай и переходим в онлайн.

(21) Это да. Это они как-то не подумали.

(23) ТСД оффлайн случайно не от КТ2000 ?

(25) Боже упаси. Он у них даже на вебвинарах нормально не разу не отработал.
Своя разработка.

(22) Пробовали? Какой клиент порекомендуете?

(26) Понятно. Я последнее время не сильно следил, сталкивался с только помарочным учетом, так как нашей ТСД с ним работать и работать.
(27) Microsoft RDP Client

(27) А чего не МобильныйКлиент? УТАП 10.3 ?

Мобильный клиент еще не пробовал. Только вот сегодня сел пощупать.
Не своя разработка. Потом в типовые только итоговые данные грузим.
Типовые больно неповоротливые.

(30) На Андроиде- свое Андроидское, или МобильноеПриложение от 1С?

(30) Случайно, импорта марок нет? А то может мы вам хоть поточное сканирование продали бы.

(27) У нас ТСД на Винде, так что про РДП под Андроид не подскажу.

(31) МобильноеПриложение от 1С
(32) В смысле? У система технического зрения на конвейере стоит. 200 бутылок в минуту сканирует.

(33) И как они?

(35) Да нормально, с быстродействием проблем нет при качественном покрытии вайфаем. Единственно на терминальные лицензии виндовые потратиться надо...

(36) Ну на лицензии в любом случае надо потратится. Этого добра, к счастью, у нас валом.

(13) это данные только по новой марке, или вы там и новую и старую храните ?
И.. инн организации какой. если не секрет?

(38) И новую и старую. Просто, когда начиналось писаться, новой марки еще не было.

(39) ясно, у нас только новой марки примерно в 1.5 раза меньше при таком же запросе.

старую, храним только, если с завода такая пришла изначально

в чем проблема работы со штрихкодами?
нормальный скуль по таблице ищет достаточно шустро.

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

если через открытое tcp соединение и напрямую обработчику,который в скуль лезет,то будет очень быстро,но это надо tcp стек поднимать,и обруливать ситуации,когда связь теряется.
в принципе,марка в 150 байт прекрасно в юдп пакет залазит,и еще место под заголовок остается.

основной вопрос-а вам надо очень быстро?

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

Simple wms

(44) там не все гладко с отображением более сложных форм. есть тонкости. но это визуальщина, по факту - вроде все норм.

А взять беспроводной сканер с функцией работы в режиме ТСД?
Пошёл нашёлкал штрихкодов подошёл к компу и выгрузил.
Нужно понять только как новые обрабатывать.

Либо с ноутом пришёл сканер по блютузу нашёлкал и сразу ввел новые.
дешёво и без всяких обменов.

(46) Смущает отсутствие обратной связи. Ведь кто даст 100% гарантию что код будет корректно считан и распознан. Всегда существует процент брака (код 2 раза считался, не считался, считался только наполовину)

(0) Если версия Android на ТСД >=5 то МП на 1С или даже МК на 1С.
Если <=4.4 то писать нативное на java/kotlin + http сервис поднять на 1С как (1)

(43) С скулю претензий нет
онлайн нужен так объем проверочного блока шрихкодов уже начинает занимать нереальное время при выгрузке на ТСД.

Очень, очень. Их планируется 50 штук.
И 20 миллионов шрихкодов оборота в месяц.

(48) МК плохо что-то на обрывы связи реагирует. Или я его пока не освоил как готовить.

(50) Это известная "особенность". Связь нужна качественная.

При качественной связи можно подумать про рдп

ПО рдп и при обрыве должно нормально быть, пользователь туда и попадет где оборвало.

Веб-сервисы.
Самописный веб-сервис в расширении КА2 возвращает по штрихкоду паллеты все данные о товаре, включая остатки, менее чем за 200 мс.

+(54) И это ещё в режиме прокси через ШД, т.е. основное время уходит на трансляцию запроса и ответа.
Конечно же, это решение прокатит при наличии стабильной связи на всей территории склада.

веб приложение и бэкэнд на 1с, получается симпатично: https://i.imgur.com/sHGhRyH.png

(56) Это откуда?

(57) от меня

(58) Жажду подробности.

(59) ну а чо подробности-то? можно сделать как угодно, хочешь - полный онлайн, хочешь - гибрид, хочешь - полный оффлайн. вопрос в том, в какой момент дергать хттп сервисы 1ски.

(60) хочешь - полный онлайн.

(56) Слушайте, а оно с Zebra работать умеет?

(62) работает со сканерами ШК, которые в разрыв клавиатуры

блютуз и встроенные

проверял на циферлабовском сканере + андроиде и на урово 6300

(0) ТСД на андроид? Тю!
Ставишь мобильный КЛИЕНТ 1с, пилишь нужный интерфейс оптимизированный под малый размер экрана и все.
Любая обратная связь, любые проверки - главное чтобы вай-фай ловил.

(62) с зеброй все умеют.

печать этикеток не пробовал, но если принтер в андроиде определяется, то без проблем

потестить работу СШК можно тут: http://fragster.ru/barcode_hid_reader/

(50) Да вроде нормально на обрывы связи реагирует... Хуже реагирует на плохую связь - время реакции заметно падает.

Ессно если обрыв надолго - тогда да, ничего хорошего. А кратковременную потерю нормально переживает.

Под андроид у этого товарища бомбовые компоненты есть: http://catalog.mista.ru/profile/454063/
Там и управление зебровскими ТСД из 1С и ловля события сканирования практически на любых ТСД

(69) Это на чем реализовано?

(72) + У меня с помощью этих компонтент так реализовано: ловится штрихкод (стандартный звук отключен), блокируется дальнейшая сканировка, на сервере выполняются все мыслимые проверки (коих куча), если все ОК - тогда подается сигнал успешного сканирования и разблокируется дальнейшая сканировка. Если что-то не так - подается сигнал неудачи и выдается соответствующее сообщение.

(73) обработка ШК относительно простой javascript: https://github.com/FragsterAt/barcode_hid_reader можете юзать в своих проектах (там один js файл)

интерфейс нарисован с использованием https://quasar.dev/

(67) Ой ли? У них свои библиотеки классов, которые нельзя включать согласно лицензионному соглашению в программы, где функциональность не-ТСДшная есть. Ну, насколько я помню. К тому же, оно не работает как разрыв клавиатуры.

(76) У зебры есть развесистый API по управлению сканерами ТСД через андроидовские интенты. Т.е. даже библиотеки никакие не нужны.

(76) И у практически всех андроидовских ТСД (включая зебру) настраивается через те же интенты передача события сканирования.

А, речь про веб-приложение... Тут я не копенгаген.

(72) Во, спасибо.
(77) А как же это:
"Управление сканером терминала выполняется через приложение DataWedge. Попытки интегрировать во внешнюю компоненту Zebra API для Андроид окончились неудачно, видимо их модель многопоточности несовместима с архитектурой мобильной платформы 1С."

Т.е. работа только через ВК, работающую через интенты? Или я чот недовкуриваю?

(79) Меня именно мобильный клиент интересует, МП слишком монструозное и тормозное.

(77)(78) через интенты да. только с ними надо лепить нативное приложение (что тоже, конечно, можно), но вот деплой его мне совсем не нравится. когда веб - просто обновляешь исходники и на всех ТСД все само обновилось. ну и работает на планшетах с виндой, на иосе с блютузными сшк и на андроиде сразу. с нативным приложением намного больше гемора именно по деплою (и сборке, пока не настроишь и потом не обновишь чего нибудь)

(82) Вот мы нативное и слепили, две ветки, одна под псевдо-ТСД с блютусными сканерами в разрыве клавы, а вторая под зёбру с её заморочками. И вот эту под зёбру из-за лицензионных ограничений нельзя выкатывать в плей маркет, т.к. в приложении есть функциональность сверх необходимой для ТСД. Такие дела.

(80) Так он и пишет, что через библиотеки не получилось а через интенты получилось. "Управление сканером терминала выполняется через приложение DataWedge" - это оно и есть.
(82) Чувак уже накатал нативные ВК для этого. Никаких проблем с диплоем - стандартно через общий макет.

Не, если задача кроссплатформенность - тогда да. Через "клавиатуру" можно везде универсально сделать.
А когда задача - максимальный контроль сканировки и обратная связь, тогда "клавиатура" и кроссплатформенность до свидания.

У нас пользуются планшеты на Андроид по RDP и блютуз сканеры штрих кодов в разрыв клавиатуры с соответствующим драйвером. Проблем никаких с быстродействием. Единственно надо найти нормального RDP клиента для андроид

(86) И как, нашли?

(80) "Т.е. работа только через ВК, работающую через интенты? Или я чот недовкуриваю?"
Да. Нужные интенты штатно из 1С не пошлешь, поэтому чувак специальную компоненту для зебровской DataWedge написал, которая это делает.
А перехват сканировки во внешнее событие 1С - ВК по "ловле" широковещательных интентов.

(86) Да-да, тоже интересно про нормальный РДП клиент.

Лично я использовал ВК которая через DataWedge управляет только для того, чтобы из 1С блокировать/разблокировать сканировку. Если просто ловить штрихкод то она не нужна.

(86) какой клиент рдп для андроид используете?

(88) Ну, вообще то пошлешь, вернее, можно было посылать до версии 8.3.12.1685, но проще - написать ВК.

(92) Ыыыыы! А у меня как раз 8.3.12.1685 и я несколько дней продолбался, пытаясь через ЗапускПриложенияМобильногоУстройства добиться нужного результата. Самое печальное, что по обратной связи вообще было невозможно ничего понять. Все улетало в пустоту. Чтобы разобраться, это проблема с 1С или DataWedge на моем ТСД, пришлось ставить студию и собирать из гитхабовских исходников демку по работе через эти интенты.

вот из-за этих геморов я и забил на клиент от 1са. ну и из-за проблем со сборкой. за пол дня накидал прототип на js по перехвату клавиатурного ШК и стал лепить веб приложения

(94) Читер :) А у нас так нельзя :(

(95) почему? веб приложение же может хоститься внутри локалки

(96) Склады, большие объемы, криворукие пользователи... Требуется любой ценой минимизировать вероятность ошибок. Как в (74) через вебку не сделать.

(93) Ну так 1С перешла на FCM c GCM тихо, не привлекая внимания. Прямо, посреди 12 редакции

FCM, кстати, вполне работает, но только - через сервер Google, в локалке его не развернешь, как GCM, поэтому пинг - от полсекунды, до бесконечности, марками тут и не пахнет.

(98) В смысле, наоборот? С GSM на FCM? И какое отношение это имеет к интентам? Это же только пуши вроде? Ежели чо, я в андроидах не настоящий сварщик :)

(100) Пишешь приложение на Adroid в котором есть Сервис, который в фоне перехватывает Интент, который потом отправляет в Приложение, которое потом отправляет пуш в 1С, из которого вызвано/запущено. Пуши в GCM можно было отправлять в рамках Android, эмулируя сервер Google. в FCM эмулировать нельзя.

(101) бабка за дедку, дедка за репку

вот как сделал генерацию ШК через зинт десять лет назад, так все работает, а компоненты от 1с отваливаются регулярно

то же с клиентом на ТСД, сборка отваливается регулярно, то 64 бита введут, то еще какая-то фигня. при этом веб приложение , блин, работает стабильно.

(103) Бывает, хренли. Надо просто немного почистить нужную папку.

(105) ну, началось все с отсутствия 64битной версии, а потом с работой через ком. или наоборот. еще и падало регулярно. и количество ШК подбирться к актуальному только в прошлом году стало и то маловато типов

(105)Часто да. Но бывают моменты.