Добрый день.

Хочу посоветоваться с сообществом.

Работает оптовый склад, в котором готовят отгрузки по заявкам. Выглядит это сейчас у меня следующим образом: грузчику дают заявку и ТСД и он идет сканировать короба с изделиями. Этикетка и код на коробах делаются заранее на производстве, в коде специфическая информация - дата изготовления (идет учет по датам изготовления), экспортное направление, артикул и вес продукта. Отсканировал, выбрал пункт меню "закончить" - документы реализации создались и провелись. И таких грузчиков с терминалами несколько, сейчас 5 человек и 5 терминалов работают одновременно.

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

Реализована данная система у меня на терминалах Cipher 8370 (Wi-Fi) и файловой Торговле 7.7, которая крутится на удаленном терминальном сервере. Этот же 2003 сервер является и сервером для пяти 8370, которые подключаются к нему также удаленно, через тот же VPN канал, что и операторы по RDP.

Построено это все на ВК CipherLabTCP.dll для Cipher от Сканкод, которая все запросы от всех ТСД пихает в одну-единственную ОбработкуВнешнегоСобытия. Сервер терминалов сбора данных представляет собой обработку, которая круглосуточно пашет под одним из пользователей 1Ски и в ОбработкуВнешнегоСобытия которой приходят все данные со всех терминалов, эта обработка, собственно, и создает все доки. Такая архитектура приводит к тому, что при увеличении числа ТСД отклик на данные с каждого ТСД будет увеличиваться, и я боюсь, что при подъеме числа ТСД с 5 до 10-15 отклик при сборе данных станет неприемлемым. Все нормально работало с 2009 года, но сейчас встал вопрос о масштабировании - будут добавляться склады, в том числе и очень удаленные, 500 км от основного офиса.

Соответственно, вопрос: как сейчас принято строить такие системы, на каком оборудовании и ПО они работают. Прошу поделиться умными мыслями.
Объемы отгрузок - до 400 ежесуточно на каждом складе.

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

(28) там не HTTP, там TCP на сокетах, более низкий уровень

на специальном отдельном порту все работает, просто бинарные данные передаются, пакетик маленький

(33) Разницы нет - главное, что у вас транспортный уровень уже есть.
Вопрос в другом - если система не успевает ответить пользователю, что она полностью обработала текущий скан, то она может ответить только, что она его получила.
Далее - если не хватает скорости для генерации документа и т.п., то просто сливаем коды в файл.
Когда сканирование заканчивается - приходит пакет, что всё отсканировано - файл отправляется роботу "кушать подано" - там уже или документ будет создан или кто-то будет разгребать журнал ошибок - если что-то не взлетело.

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

(36) Самый простой робот - это запущенный сеанс 1С с открытой при запуске обработкой.
Ему только не хватает процедуры выполнения Sleep, которую можно где-то найти.
От робота можно обращаться по http-запросу к "посреднику", который как раз Sleep умеет, и он же (посредник) вернёт управление 1С или раз в несколько секунд или тогда, когда появилось задание.
ServerXmlHttpRequest как раз для этого подходит.

(37) еще лучше. Запущенный сеанс 1С с открытой при запуске обработкой - это как раз-таки мой сервер ТСД сейчас так реализован

а для создания и проведения доков еще сеанс и еще обработка...

(36) форма.обработкаожидания(имяпроцедуры)

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

(39) Так если скорости самого сеанса не хватает на проведение, то придётся делать другой.
Особенно, если терминалов будет несколько - пока один проводит - все "курят в сторонке".
Просто у создателей Cleverence ( http://www.cleverence.ru ), например, вообще промежуточная база данных для терминалов создана.

(40) это ничем не лучше чем то как реализовано сейчас у меня - доки проводятся из обработки внешнего события.

(43) Отдельный процесс, чтобы избежать эксцесс.

(42) дело не в том что не хватит. Дело в том что нет многопоточности в пределах одного сеанса, как ни крути, а скрипт семерочный выполняется только в одном месте в текущее время.

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

(45) Будто бы в восьмёрке вам кто-то многопоточность обещает - там в несерверной версии фоновые задания в сеансах отдельно командной строкой запускаются - и здесь так надо.

Если терминала два, то уже есть вероятность, что одного сеанса на них будет мало - всё равно нужно будет по потоку на терминал - поэтому, или плодить сеансы 1С или сделать вообще не на 1С, а на "взрослой" системе, которая уже 1С будет пинать по мере необходимости хотя бы по тому же OLE.

Плодить сеансы 1С не получится, потому что компонента может быть только одна на IP-адресе сервера. Если только виртуальные машины с собственными IP, но тут мы сталкиваемся с сетевыми проблемами файловой 1С 7.7

(49) Просто, внешнее событие в 1С "клинит" если нечаянно нажать Alt и открыть меню в программе.
После этого "чуда" я вообще стараюсь не использовать внешнее событие.
Есть, правда, метод DDE-запросов, но они выполняются с прерыванием строки кода в произвольном месте - поэтому нужно остерегаться "наложения" когда один DDE-запрос прерывает другой.

в плане развития текущей системы единственное что я вижу - два сеанса. В одном, как и раньше, обрабатываются события терминалов по возможности быстро и пишутся в некие промежуточные документы без проведения или даже файлы. В другом это дело раз в энцать секунд проводится.
Либо - основательная переделка, и тогда опять вопрос в конце (0) - в какую сторону "бечь", какое ПО и ТСД смотреть.
(50) да, я знаю, но там никто не трогает эти сеансы.

(51) На терминале http-клиенты, которые шлют http-запрос на сервер (например apache) там он сливается в промежуточную Sql-базу - в эту же базу периодически "заглядывает" 1С, чтобы получить задание на создание и проведение очередного документа.

> Серверная обработка записывает (без проведений и т.д.) некий документ со специальными пометками, что, мол, его бы провести.
.
не рекомендую - в 7.7 - общий журнал - узкое место и источник
затыков.
.
не зная всех тонкостей что и ка кнадо рискну предложить самый простой штатный и быстрый вариант.
.
сервер ТСД в отдельном сеансе 1С принимает через ОбработкуВнешнегоСобытия данные от терминалов. и складирует их в очередь. Складирование в очередь должно выполняться быстро, поэтому тупо делаем плоский справочник без наименования и кода, индексов никаких нет. запись "очереди" в этот справочник будет практчески мгновенной.
.
делаем отдельный "сервер обслуживания очереди" - обработку-робот, которая стартует и выполянется сама по себе в отдельном сеансе 1С, без всяких рабочих столов и прочего (у меня так работает и шуршит без всяких проблем). Робот с интервалом в N секунд прямым запросом тупо выгребает данные из справочника-очереди - даже без индексов это будет практически мгновенно, потому что вочереди вряд ли будет больше сотнии-двухсотен строк. Обрабатывает эти строки и что вам там надо - генерит доки и т.д. даже если цикл генерения документов будет дольше цикла повтора робота - в этом нет ничего страшного.
.
все.
.
нефиг сильно морочиться - надо пробовать и тестировать.
взлетит, стопудово взлетит. если конечно железо под сервер нормальное, ане какая-нить столетняя хрень.
.
после того как взлетит - можно уже думать об оптимизации - отдельных табличкахс тронней скуля и прочего.
.
работы - с учетом того. что код генерения документов уже готов - ну максимум на один рабочий день с запасом.

(53) Можно и не прямым запросом и не в отдельном сеансе и не отдельным роботом. Все делается штатно; вот изза этого "в 7.7 - общий журнал - узкое место и источник затыков".
Какая нафейхоа разница как обрабатывается запрос если все равно генерить до и если все равно упираться в узкое место движка ?

(21) > Просто у меня проект с WiFi-терминалами не взлетел, так как покрытие на складе сделать не удалось - диапазон WiFi не резиновый, а кто-то в него ещё и видеонаблюдение засунул.

Как так? Оборудование было 2,4 Ггц only?

(55) Проблема была в том, что сначала поставили FullHD-камеры по WiFi, а потом ожидали, что WiFi хватит.
"Пятёрку" не смотрели, так как были уже куплены терминалы 2.4 only.
Собственно, в режиме Offline оно как-то сейчас работает.
Но, проблема ещё и в том, что криво наклеенный штрих-код терминалом считывается неверно - получаются другие цифры.

(55) Как как ... Достаточно трех камер типа DLink 932L в сети чтоб сожрать весь трафик

(56) понятно.
> Но, проблема ещё и в том, что криво наклеенный штрих-код терминалом считывается неверно - получаются другие цифры.
Странно, если обычно декодером выступает что-то типа scanwedge то проблема только со всякими сочетаниями Ctrl+.. возникает.

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

(57) три наверно мало. Три камеры можно зафиксировать на 11 канале а терминалы на 1-й сдвинуть. И если стены склада железные то "соседи" фонить не будут и в приципе хватит. Хотя конечно тоже не фонтан.

(56) Прикольно... ни разу не сталкивался с таким считыванием
Контрольный же символ и все такое... может у вас терминалы неправильные?

(60) Проблема в том, что у камер выносные антенны и точки доступа на нескольких каналах.

(61) Если штрих-код наклеить на круглую бутылку, то можно узнать много нового и интересного.
P.S. обычные сканеры Metrologic с включённой проверкой считывания на три-четыре раза ошибок не давали, а многие другие - считывали немного не то, что должно быть.

Потом, если для покрытия склада нужна не одна точка, а несколько, а для видеонаблюдения поставили несколько мощных, то весь диапазон прекрасно перекрывается двумя каналами по 40 мегагерц (или четыремя по 20, как там и было).

(63) хе хе. Это когда с точки зрения сканера расстояние между штрихами к краю штрих-кода уменьшается и полоса 4х плавно превращается в 3х, 2х и 1х :) Удивительно что они вообще считывали.

(65) Metrologic-и просто не считывали - если немного повертеть, то иногда удавалось считать то, что написано.

(60) пох до канала. Вафля - 54Мб. Канал делится на количество подключений. Камера умеющая только мпег жрет 2.2-2.4Мб/сек.
Я вообщето говорю не про внутреннюю сетку - а про внешний канал.
Стандартая хотелка - поднятие системы камер в офисе и желание собственника смотреть их через тырет. Вот тут то и ловим вилы.

(63) Так если этикетка большая - вдоль надо клеить, а не поперек :)

(68) я так понимаю там поставщик расположением ШК рулит

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

и вообще  можно сделать вывод что бутыла должна быть квадратной :)

Jack Дэниельс - все для тебя

(71) Ну, ещё бывает простая поваренная соль, на которой штрих-код нанесён красным по белому.
P.S. имиджевые сканеры, кстати, съели такое на ура.

(67) ну как бы если камер не то покупать с рассчетом выноса на 5ггц диапазон и всё.

(73) да но дальнобойность у них никакая.

(74) Есть много моментов, которые могут "повалить" проект на взлёте.
В одной конторе выяснилось, что операторы немного слеповаты и не могут пользоваться экраном терминала 3.5 дюйма и что-то писать там стилусом - а менять людей из-за техники никто не захотел.

(76) интересно. У нас из за этого Моторолловские MC3000 никто не любил. У них по сравнению с МС9090 ppi меньше и текст мельче получается.

а сейчас 91хх уже идут 640х480 и там без перерисовки форм вообще никуда.

(76) Надо тупенько использовать клавиатуру и выводить большие буквы. Применять пошаговость вместо 100500 кнопок и т.п.

(79) ага, большие буквы, по одной на экран, как в букваре :)

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

Большие буквы - это, конечно, хорошо, но чем вводить - если клавиатура - экранная ?

(82) а че им вводить кроме цифр? По идее тому кто вводить текст должен ТСД не положен. Планшет или еще что.

(80) КЦ правильно говорит...

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

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

(82) А что вводить то?
Если даже наименование - надо какой-то шаблон использовать, выбирать...
Тем более экраны в которые тыркают вряд ли долго протянут (когда казенное так сказать)

(87) Я уже написал в (85), что при правильном решение проблемы годится самый дешёвый ТСД, чтобы просканировать всё, что получили, и сравнить с полученным документом.

на 3дюймовом экране и 240-320 и 480-640 смотрятся и читаются вполне.
.
http://content.screencast.com/users/Che66/folders/Jing/media/10b82996-61e7-4d79-9860-1ee74387e20f/2014-09-14_0018.png
.
если конечно не использовать унифицированные формы "стандартных решений" где на один экран выводят все - и нужное и ненужное в данный кокнретный момент.

сейчас идиотская мысль пришла - доску с штрих-кодами букв :) А, Б .. и т.д. :)

во умора была бы :)

(90) все зависит от частностей..

(90) Wav-файл с названием товара выглядит не менее смешно.
P.S. в общем "мыши созданы, чтобы грызть кактусы".

(89) красота, такое все гладенькое. HTML?

в принципе аналог "Т9" вполне справится на ТСД в режиме рдп на нормальном сервере

(95) Хрен вам, а не Т9.
Если в накладной написано "колбас.отеч.сыр.вес.царицыно", то что должен думать Т9 ?

(94) ни в коем случае. все штатно (дарю http://infostart.ru/public/266256/) не хватало еще спеца по ажтээмэлю держать там где один 1Сник справится.. кстати одним из причин отказа от ExpertLogistik с моей стороны было уж слишком разношерстная сборка используемых технологий для создания рабочего решения...

Слушайте байку. Возникла на складе складе идея - используя ТСД автоматизировать систему штрафования кладовщиков. На одежде/бейдже ШК. Старший смены если хочет штрафонуть как арбитр подходит и сканирует ШК на скл. сотруднике.
В голове сразу картина как старший смены бежит за виновным выцеливая его из "пистолета".

(96) ну.. при наборе "кол" - предложит все что начинается "колбас"

(98) вот ты тупой.. проще распечатать шк сотрудников и держать под рукой.. ;-) - потому что самые умные тут же на бейджи нацепят чужие шк.. ;-)

(100) я тебе рассказываю как было а ты сразу "тупойЙ. До дела не дошло а так бы конечно было бы прозаичнее.

(100) Так и на товары "умники" наклеивают другие ШК, особенно, когда что-то на складе пропало, а хочется, чтобы не попало.

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

(101) не кипиши, я ж в шутку...

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

(105) Коробка со штрих-кодом - это "кот в мешке" и чем больше уповают на штрих-код - тем более непрозрачный мешок.

(103) тогда клиент не получит одной из услуг - возможность высказать что мол вы все ко3лы и склад ваш г0вно. Так и уедет с чувсвом недосказанности.

(106) кроме ШК на коробке в каждую коробку вложен упаковочный лист того, что должно находиться в этой коробке. Изначально регламент упаковки построен так, что одномоментно на столе упаковки находится только одна открытая незапечатанаая коробка. То бишь в другую какую-то коробку положить проблематично. Но как ты написал в (103) - люди - они такие - начинают упрощать себе жизнь... по моим наблюдениям ситуации с рекламациями ухудшаются тогда когда я визуально наблюдаю падение диспислины и "толкотню" вокруг упаковочных столов...

(107) вот! а так - клиент приехал, полаялся, накапал всем на мозги и с апгрейдом ЧСВ - уехал... ;-)

(105) А если упаковывать под камеру? Подняли запись и посмотрели клали товар или нет

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

(110) да вот думали давно над этим уже... смысла мало.. но видимо придется делать...

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

(111) это запросто, рекламацию могут прислать и через полтора месяца... ;-)

Во-первых, сборка должна идти конвеером и на каждом этапе желательно отслеживать, что и куда кладут.
во-вторых, после запечатывания коробки на неё ставится штамп упаковщика, который её упаковал, чтобы все вопросы были к конкретному человеку.
В-третьих, все рекламации собираются с базе и накладываются на рабочих кладовщиков, чтобы вычислить число косяков на каждого кладовщика.
В итоге вычисляются те, кто больше косячит - с ними и проводится дальнейшая работа по видеонаблюдению и т.п.
Соответственно, если кто-то что-то забыл положить, то приветствуется "докладывание", когда человек вспоминает и сообщает начальнику склада, что он что-то забыл. Если же кто-то намеренно косячит, то таких "умников" переводят на другие должности или отправляют на рынок труда.

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

(114) Хорошо применять штрафы. Всегда известно кто что и когда собирал. Штрафовать можно и до момента отправки если заметили... таким образом повышается внематочность.
(115) Если коробка вскрыта - тогда вопросы к водителю. Принимал он ее закрытой.

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

(105) Ненадежных клиентов можно всегда контролировать... ну как бы тщательнее что ли... бывают те у которых "всегда что-то не так"
(117) Даже если этикетку наклеить на шов - она же все равно нужна... ШК там, маршрут и проч. А заказчику она как бы уже не нужна в целом виде.

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

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

(112) Отсылаешь видео клиенту со словами вот смотри положили в коробку, скотчем закрыли, вы же приняли упаковка небыла вскрыта или повреждена. Так что извините.

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

Ну и опять, если претензия на 10 рублей то проще и дешевле согласиться. Если же претензия на крупную сумму .. ну тут обычно вместе с продажником решается, толи он просто скидку клиенту даст, толи объяснит что клиент сам дурак, толи еще как разрулит

(113) Тоже решается административно, вплоть до прописывания этого пункта в договоре, типа "претензия при приеме принимается в течении N дней".
Если мы говорим о именно недостачи/пересорте при приеме, а не о браке

Ладно, это все хорошо. 8370 довольно хтоничная штуковина, кстати. А кто-нибудь может рассказать про современные решения, на RDP терминалах к примеру? Как у кого работает?

(123) у меня работает - зашибись! и в самописке складской работало зашиьись. и сейчас перешли на WMS - тоже работает зашибись. Причем у меня в самописке работало/работает зашибистее.
.
подробнее можно посмотреть в моей ветке на кубани.

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

(123) решение для опробывания/шаблона ТСД по терминалу можешь вон себе взять и юзать пробовать: http://infostart.ru/public/266256/

..напрягает то, что блин в большинсве рекламацими идут по тем поставкам, которые трудно проконтролировать - то что идет через транспортные компании. То что развозим по МСК, то что берут клиенты самовывозом (даже из регионов) - нормально...

(127) Таки сторонние транспортные компании, наверняка, уже руку набили на вскрытии коробок без следов вскрытия.
В принципе, если почти каждый раз при доставке косяк, то можно сделать "контрольные доставки", чтобы показать, что виновата транспортная компания, но реально только можно будет подтвердить, что с такой-то компанией лучше не работать.
P.S. например, почта России в прошлом очень это умела ^_^

(128) а сейчас разучилась?

(129)+1 это уже стало нормой в любом уважающем себя предприятии..

при работе с транспортными компаниями с палетными отгрузками (куча коробов на палете) существенно помог простой переход на палетирование черным непрозрачным стрейчем. практически сразу же колов рекламаций существенно упало. Пи..ят в транспортных.