Добрый день.

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

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

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

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

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

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

400 отгрузок - это ни о чем. может там в отгрузке по 3-4-5 строк.

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

..твоя задача - чтобы на ТСД был быстрый отклик. Поэтому просто тупо РЕГИСТРИРУЕШЬ данные сканирования, поступающие на "сервер в виде обработки" - то есть в обработке внешнего события - нихрена тяжелого не делаешь, просто регистрируешь сканы и ставишь в "очеред"ь. А в другом сеансе, да хоть на этом же сервере - эту очередь обраббатываешь так как тебе надо. взлетит однозначно.
.
опять же - надо смотреть внимательнее на тем и загрузку твоей работы - наскольо грамотно написаны эти вские "создания документов" в теперешнем твоем состоянии. если один скан обрабатывается _полностью_ с созданием всего тебе необходимого за 0.02 секунды - то вообщем ничего проблемного нет...
.
но первый предложенный вариант выше - мну нравится больше

То бишь, доработать то что есть. Резонно, такие мысли тоже были. Спасибо!

(4)ОБработкаВыбораЗначения считывает данный со сканера, готовит таблицу значений для передачи в обработку (должна быть создана отдельно).
Обработка генерит документы по тем параметрам которые прилетели ей.
В результате упрешься в физическое быстродействие системы, но читаться данные будут быстро.

(5) ОБработкаВыбораЗначения

имелась в виду ОбработкаВнешнегоСобытия?

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

+ (6) и обработки, естественно, работают в разных сессиях, это понятно

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

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

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

(9) робот представлял собой что? Обработку 1С?

(11) Все что угодно, вплоть до другой базы. Заодно нагрузка распределяется.

меня интересует вопрос: как в семерке сделать качествено работающее задание, которое бы раз в несколько секунд что-то делало бы в базе? Запускать планировщиком 1С под пользователем, у которого при начале работы системы прописана обработка? Или есть менее тяжелые варианты?

(1) отвечу: в среднем от 10 до 30 строк в отгрузке.

(13) На виртуальном рабочем столе запущена 1С и в ней открыта форма.
Далее, другой процесс с этого рабочего стола шлёт в форму WM_CLOSE или WM_KEYDOWN в зависимости от того, что проще реализовать. Обработка начинает выполнять процедуру (или нажатие кнопки с клавишей или закрытие формы).
Соответственно, получается очень просто и быстро и не надо стартовать-завершать 1С.

Как вариант COM+ с "живущим" соединением к базе 1С по OLE.

(8) Вот у тебя 5 тел носятся с циферлабами; отсканировали все. Построились в очередь к кредлу (если он один) на считывание данных; либо каждый бросил сканер в свой кредл.

ОБработкаВыбораЗначения (или ОбработкаВнешнегоСобытия, не суть важно) ловит чтение данных и готовит ТЗ.
ТЗ через ОткрытьФорму передается в обработку, обработка занимается тем что генерит документы на основе входящих параметров.

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

(8) нету кредлов. Все автоматом. Термы вайфай.

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

(18) нет. Это вайфай терминалы. Они онлайн. Нету кредлов, нету файлов

(17) По WiFi мы сразу гоним код в компьютер ?
А если потеря связи - что происходит ?

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

происходит сбой, терминал отображает табличку "нет связи". Как восстановилась - можно повторить

(13) У меня было тупо, но очень надежно. Просто все время был запущен этот робот и все. Он просто периодически мониторил содержимое таблицы.

(21) у меня получилось, проблемы со связью бывают не столько на вайфае, сколько на VPN канале, но они не так часто и не критичны

(22) То есть гарантировано, что или будет передан весь код или не будет связи, а ситуации, когда три символа штрих-кода улетели на комп, а остальные - нет - такого не бывает ?
Просто, если бывает, то лучше систему не внедрять - всё равно х.ня получится.

(25) не бывает

(24) Если мы обрабатываем штрих-код на сервере, то интервал времени между "соседними" символами иногда оказывается бошьше десяти секунд (Vpn-сеть поверх WiFi и терминал-клиент).

(26) Если не бывает, то у вас, скорей всего http-запрос на "сервер" с очередным штрих-кодом - и всё очень просто - "сервер" должен его передать в 1С.

(18) Не важно. Точка входа в первую процедуру одна, так что ктото будет первым кто то получил отлуп (а скорее всего не получит). Самое главное обработку генерации доков выхывай уникальную;
Переменная = _GetPerformanceCounter();
Переменная = СтрЗаменить(Переменная, " ", "_");
ОтркрытьФорму("Обработка.<Имя обработки создания документов>#" + Переменная, СписокПараметров);

Приложение на ТСД + компонента устроены таким образом, что передается все содержимое формы терминала (в простейшем случае это ШК, в более сложном несколько полей ввода, м.б. несколько ШК + вручную введенные пользователем с клавиатуры данные). И форма либо прошла вся и тогда в ОбработкуВнешнегоСобытия поступят поля данных, либо ОбработкаВнешнегоСобытия не вызовется, а терминал покажет "Нет связи". Как-то так.

(29) к (19)

(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 это уже стало нормой в любом уважающем себя предприятии..

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