Есть одна тян, торгует одеждой
В каждом городе по магазину
Штрихкоды создаются и печатаются параллельно с признаком магазина в шк
Товар при перемещении (txt-обмен) не перемаркируется
В результате на центральном складе накапливается масса "чужих" шк
Часть одинаковых шк соответствуют разному товару вследствие ошибок при создании и кочуют из базы в базу

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

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

файл обмена.txt:

[Дата|Номер|Откуда|Куда|Коммент|Сумма]
07.09.2016 9:26:38
НЧ000001350
Центральный склад
АЦКК

=49284=


Штрихкоды|ПодГруппа|Артикул|Код|Наименование|ХарактеристикаНоменклатурыНаименование|Цена|ЦенаВРознице|Количество|НоменклатурнаяГруппа
4404000052254,4404000052322;Обувь в асс-те;831;00000019543;ж балетки 36-40;603, 4;603;603;8;
4404000052261;Обувь в асс-те;A30;00000019546;ж балетки 36-40;603, 4;603;603;8;

Рад буду обоснованному кг/ам от уважаемых сетеводов вроде Лефмихалыч Злопчинский ибо на мисте не был и не кодил почти год

Если в каждом магазине правильно настроены штрих-коды, то они пересекаться не должны - это раз. То есть настройку нужно проверить и исправить.
Если уж очень хочется избежать проблем, то нужно, чтобы информация о товарах была общей, то есть и кодирование и ввод в базу делался на центральном складе - тогда - во-первых, не будет нескольких штрих-кодов на один и тот же товар, как и не будет нескольких номенклатурных позиций, во-вторых, все перемещения и заказы товаров можно будет оформлять в электронном виде - ничего не будет путаться.
Опять же, если одежда-обувь, то можно придумать другую систему формирования штрих-кодов и использовать внутренние штрих-коды не EAN с первой двойкой, а CODE39 или CODE128, чтобы в штрих-коде была информация о размерах и прочих характеристиках - но это процесс непростой.

(1)Настроены шк грамотно. Обмен шел нормально на первых 2 магазинах сети, ВНЕЗАПНО пошел молчаливый неконтролируемый ручной ввод в 1с перемещений из "дружественных" магазинов, обмен кодами с ними изначально не был запланирован. Сейчас проблемных шк порядка 5% и я на этапе проектирования барьера по их распространению. Поскольку обменник общий и есть инфа о происхождении "плохого" шк, думаю их "банить" на этапе формирования расходной накладной, таким образом в базу-приемник шк попасть не сможет и оператор распечатает стикер со следующим подходящим кодом либо сгенерирует новый.

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

нужна 100% доступность(инет есть не везде и не всегда),
=> будет папка каталогизированных текстовиков в дропбоксе, генерируемых роботом на основе выгрузок ключевых баз сети, в базах подписку на генерацию шк и их выгрузку

Тут ещё нужно производителей исключить - некоторые производители на свой товар клеят штрих-коды из той же 2Х группы, считая, что по-другому нельзя.

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

(3)Благадарю. Подумаем

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

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

Сильно не думая
1. В том, что на один товар несколько разных шк (разных магазинов) - никакого криминала здесь не вижу, главное наладить обмен всеми шк между всеми магазинами, ибо получается что товар из одного магазина может или прийти на центральный склад или в другой магазин) . А чем именно идентифицировать объект - отпечатком пальца или формой ушной раковины - абсолютно пофиг, главное чтобы было однозначное соответствие/уникальность. итого: на один товар может быть куча однотипных но разных штрихкодов.
2. Хуже, когда получилось что на разные товары одинаковый шк (в рамках одного магазина или всей тян непринципиально). Сливаешь все шк в одно место, выявляешь одинаковые шк для разных товаров (это-то я думаю достаточно просто), вместо этих шк генеришь новые уникальные, обеспечиваешь чтобы новые шк могли быть распечатаны на точках и центральном складе и было чтобы понятно к какому товару они относятся - персонал должен тупо вручную перемаркировать. В одном месте куда все слил - такие проблемные шк полностью "затираешь" - про них вообще не должно быть упоминания нигде, единственное место где они могут остаться - это физическое присутствие на жтикетках (персонал забил болт и не перемаркировал). Клонируешь такую исправленную инфу на точки. Итого при попытке отсканировать хреновый шк в любом месте - он тупо не будет найден в базе и не пройдет процесс продажи/инвентаризации - сделают выбор товара вручную или перемаркируют штатно.

Наличие какойто базы с проблемными шк - зачем оно надо? Еще больше сумятицы внести? Убей нафиг все проблемные шк во всех базах, перед этим отр
Правив на точки или готовые рулончики с этикетками для перемаркировки или файлик/инфу, которую должны принтануть на точках для перемаркировки.

Ну и ясен пень ликвидировать в принципе возможность введения/получения/создания одинаковых шк для разных товаров. Скорее всего такая хрень получалась или при копировании номенклатур или когда вместо старой номенклатуры поверх писали новую.

вариант ликвидации кривых шк должен быть сделан быстро, типа в ночь, собрал инфу/базы со всех точек, обработал, ликвидировал все кривое и разослал обратно

Как-то так я себе представляю
Никаких особых компе енций мне кажется иут не надо, простая нормальная логика и все

Написать обработку выгрузку
Коля наименование - штрихкода

Создать базу один справочник товары и регистр сведений штрихкода

По очереди загрузить туда файлы с анализом.

Выявить Дубликаты решить что с ними и где делать.
Вернуть обратно. Деловой на пару часов.

Коля = код и

(7)  угу именно

(2) >будет папка каталогизированных текстовиков в дропбоксе

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

А решение только одно, своя общая единая база ШК по правилам, для исключения дублей внутри.

И не пропускание чужих ШК в эту базу внутрь, они должны всегда заменяться своими внутренними.

Для этого достаточно отделить мух от котлет, в смысле свои ШК от чужих ШК. К примеру добавить в свои 2-ю контрольную цифру (это если от EAN не хотим отказываться, но уменьшение значащих).
Или использовать не EAN ШК а нечто побольше и признак свое туда.

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

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

(10)Вебсервисы сам хочу прикрутить, дык доступность айпи надо поддерживать, денег выбивать, раньше обходился ежедневными выгрузками в дбф из каждой базы, можно добавить интерфейс из 90ых на текстовых "файлах обмена" с командами и ответами, база кодов с роботом, должно хватить для сельской местности, имхо
Вся автоматизация тян это урезание функционала УТ10 до уровня понимания вчерашними продавцами с рынка, в регионах рабсила и стикеры дешевле сервака на данном этапе

(12) Если на точках есть хоть какой-то интернет, то писать обмен через почту, чтобы можно было оперативно что-то в базу послать.

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

(0) Code128, где префикс филиала + ШК производителя

(14) Это называется "человеческий фактор" (чтоб им пусто было).