Реклама на этом месте
Форум 1С
Форум 1С
Программистам. Бухгалтерам. Администраторам. Пользователям
Задай вопрос - получи решение проблемы. Без троллинга и флуда.
21 Сен 2017, 02:48
МультиВход
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Не получили письмо с кодом активации?
 
collapse

Автор Тема: О штрихкодировании документов  (Прочитано 3186 раз)

0 Пользователей и 1 Гость просматривают эту тему.



На написание данной статьи меня побудили 2 факта:
  • В очередной раз в новой организации столкнулся с проблемами при штрихкодировании документов. Подробнее суть проблем опишу ниже.
  • Тема форума http://forum-1c.ru/index.php?topic=62345.0
   
Оба эти факта лишний раз убедили меня в том, что задача штрихкодирования документов является в некотором смысле типовой и довольно таки распространенной. Поэтому я решил поделиться своим ноу-хау. Возможно, для кого-то это не станет открытием и где-то что-то подобное уже работает, и кто-то скажет, что я пытаюсь заново изобрести велосипед, но во всяком случае мне эта идея пришла без подсказок извне и на практике я пока этого подхода больше нигде не видел. Так что у меня возникло желание поделиться своими мыслями с 1С-собществом, возможно, кому-то это пригодится. Ну и здоровую критику никто не отменял, интересен будет любой отклик.

Начну я с наверно самого распространенного способа штрихкодирования – составление штрихкода «на лету» на основе параметров документа. Этот метод я называю «классическим». Основной принцип этого подхода заключается в том, что штрихкод (далее по тексту может использоваться сокращение ШК) формируется из некоторого набора ключевых полей, под каждое из которых отводится сколько-то символов. «Классический» вариант структуры штрихкода:
  • Код вида документа (заказ, реализация, доверенность и т.п.) – обычно от 1 до 3-х символов.
  • Код организации (по сути, замена кириллического префикса в номере документа) – обычно от 1 до 3-х символов.
  • Номер документа без префикса – от 6 до 9 символов.
  • Дата документа – от 6 до 8 символов в зависимости от варианта представления (год кодируется 2-мя или 4-мя цифрами).
   
В целом на первый взгляд все здорово: учли все многообразие видов документов, различные организации, нумерацию, дату - на выходе получим уникальный ШК, который однозначно идентифицирует документ. Но сразу же очевидны и минусы: при обработке штрихкода требуется его обратное преобразование, расшифровка, получение тех самых ключевых полей, который изначально в него зашифровали. И обычно никто не заморачивается на тему реализации универсального алгоритма, настраиваемого параметрически в пользовательском режиме. Хотя вообще то никто не мешает создать некую структуру данных с указанием соответствия цифрового кода объекту метаданных, в организациях можно добавить поле с названием например «код организации для штрихкода» и т.п. Обычно все делается на скорую руку и эти вещи полностью или частично описываются хардкодом. Ну то есть прямо в коде написано что-то типа:
ДокументТип = "000";
Если ТипЗнч(Документ)=Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
ДокументТип = "001";
ИначеЕсли ТипЗнч(Документ)=Тип("ДокументСсылка.ЗаказПокупателя") Тогда
ДокументТип = "002";
КонецЕсли;
К чему все это приводит? Очевидно: к тому, что при любом изменении набора ключевых параметров (как то необходимость вывести штрихкод на новый тип документа, появление новой организации и т.п.) нужно править код. А если есть еще и обмен с другими базами и там тоже нужен поиск документа по штрихкоду, то количество мест, где надо изменить код растет, а вместе с ним растет и вероятность ошибки – забыли адаптировать код, адаптировали но с ошибкой и т.д. и т.п.
Мало того. Бывает еще и такое, что например менеджер ошибся при заведении заказа в базу, указал не ту организацию, после чего зашел бухгалтер (ну или любой другой пользователь с соответствующими правами) и организацию изменил. Очевидно, что теперь при печати документа штрихкод будет уже совершенно другим и по ранее распечатанной бумаге документ в базе найти не удастся. В течение нескольких дней после изменения организации это может и не вызвать проблем, а через полгода кто вспомнит об этом случае?

Основная идея метода, который я предлагаю и который успешно используется в нескольких организациях заключается в следующем: штрихкод должен быть отдельным полем и он должен храниться в базе. Не нужно привязывать его ни к номеру ни к дате ни к другим полям, так как значения этих полей в принципе могут измениться. Понятно, что нужно гарантировать уникальность штрихкодов, поэтому добавление реквизита «штрихкод»  в документ – плохая идея. Да и к тому же выше я уже писал, что штрихкодировать надо разные виды документов – добавлять реквизит во все просто глупо. Очевидное решение: регистр сведений с единственным измерением типа строка – Штрихкод и ресурсом Документ составного типа. Можно указать фиксированный набор документов, либо же тип ДокументСсылка, либо вообще ЛюбаяСсылка. Явным преимуществом такой архитектуры является гарантия уникальности штрихкода на уровне платформы – ни при каких обстоятельствах не получится записать в базу 2 строки с одинаковым ШК и разными документами. Другой вопрос конечно, что можно изменить существующую запись (то есть фактически переприсвоить штрихкод другому документу и таким образом можно получить бумажные варианты 2-ух различных документов с одинаковым ШК ) – но тут уже вопрос ограничения прав доступа + грамотно написанный код, который не допустит такого развития событий.
 
Итак, архитектура понятна, теперь детали: как получить уникальный ШК? Можно конечно попробовать использовать просто сквозной нумератор, начать с 1 и каждый раз прибавлять на единичку – так тоже можно, но я решил использовать произвольный набор цифр. Точнее не совсем произвольный. ШК получается из уникального идентификатора документа, коим является GUID. Как известно, GUID состоит из 32 значимых символов (цифры и буквы латинского алфавита) + разделители (тире), общая длина 36 символов. По этой причине запихнуть в ШК весь GUID не представляется возможным – потому что на документе ШК заведомо ограниченного размера, могут возникнуть сложности при считывании столь длинного ШК. К тому же, если использовать кодировку GODE128, то количество штрихов на любые символы кроме цифр ровно в 2 раза больше, чем на кодирование цифры. Да и кроме того, ШК такой длины видится избыточным, обычно должно хватать 12-15 символов чтобы обеспечить запас для кодирования документов. Соответственно, решение такое: из GIUD убрать все кроме цифр. Полученный набор цифр довести до нужной длины. В зависимости от количества документов на единицу времени в организации обычно должно хватить 12-15 символов. Полученный таким образом ШК при помощи запроса предварительно проверяется на уникальность – ведь мы же обрезали GUID, уникальность которого гарантирована, стало быть, полученный обрезанный набор цифр уже может оказаться неуникальным и его надо предварительно проверить. Если проверка пройдена – отлично, мы получили искомый ШК, если нет – генерируем ШК на основе произвольного GUID до тех пор, пока не получим уникальный ШК. В конце статьи приведен код, который все это реализует. Сама запись штрихкода происходит по подписке на событие.

При обмене данными с другими системами передается так же и ШК в числе прочих полей. Кстати, учитывая, что ШК уникален, по нему можно вести синхронизацию. В базе-приемнике ШК может быть реквизитом документа. Естественно, уникальность ШК проверяется только в головной базе, база-приемник просто получает готовый ШК и сохраняет его.
 
О плюсах данного полхода. Главный плюс – это универсальность. Нет зависимости от количества организаций в базе, добавление штрихкодирования нового вида документов делается легко и просто. При желании, можно управлять этим параметрически в режиме пользователя – создать структуру данных, где будет храниться перечень документов, к которым нужно генерировать штрихкод. То же самое и при поиске документа по ШК – никакого разбора не требуется, ведется поиск на равенство, сам алгоритм поиска универсальный и не потребует доработок. При чем во всех базах, участвующих в обмене (опять таки, оговорюсь: при условии, что существует «головная» база, которая генерирует ШК и гарантирует их уникальность, в базах-приемниках ШК генерироваться не должны, только получаться вместе с обменом).

Исходный код:

Функция ПроверитьЗаписатьШтрихкодДокумента(СсылкаНаОбъект) Экспорт

Результат = Ложь;

// первое: получим штрихкод из GUID-а, чтобы сразу в запросе проверить его уникальность, дабы убрать лишний запрос к БД
GUID = СсылкаНаОбъект.УникальныйИдентификатор();
Штрихкод = ПодготовитьШтрихКодИзGIUDа(GUID);

// второе: проверяем наличие штрихкода, а так же уникальность кода в пакетном запросе
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ШтрихкодыДокументов.Штрихкод
|ИЗ
| РегистрСведений.ШтрихкодыДокументов КАК ШтрихкодыДокументов
|ГДЕ
| ШтрихкодыДокументов.Документ = &Документ
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ШтрихкодыДокументов.Штрихкод
|ИЗ
| РегистрСведений.ШтрихкодыДокументов КАК ШтрихкодыДокументов
|ГДЕ
| ШтрихкодыДокументов.Штрихкод = &Штрихкод";

Запрос.УстановитьПараметр("Документ", СсылкаНаОбъект);
Запрос.УстановитьПараметр("Штрихкод", Штрихкод);

Результат = Запрос.ВыполнитьПакет();

ВыборкаДетальныеЗаписи = Результат[0].Выбрать();

Если ВыборкаДетальныеЗаписи.Следующий() Тогда
// штрихкод есть - возвращаем Истину
Возврат Истина
КонецЕсли;       

// третье: штрихкода нет - запишем
// сначала проверим ШК на основе GUID на уникальность:
ВыборкаУникальность = Результат[1].Выбрать();
Если ВыборкаУникальность.Следующий() Тогда
// ШК не уникален. генерируем новый
КодУникален = Ложь;
Пока НЕ КодУникален Цикл
Штрихкод = ПодготовитьШтрихКодИзGIUDа(Новый УникальныйИдентификатор);

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ШтрихкодыДокументов.Штрихкод
|ИЗ
| РегистрСведений.ШтрихкодыДокументов КАК ШтрихкодыДокументов
|ГДЕ
| ШтрихкодыДокументов.Штрихкод = &Штрихкод";

Запрос.УстановитьПараметр("Штрихкод", Штрихкод);
Результат = Запрос.Выполнить();
КодУникален = Результат.Пустой();
КонецЦикла;
КонецЕсли;

ЗаписьРегистра = РегистрыСведений.ШтрихкодыДокументов.СоздатьМенеджерЗаписи();
ЗаписьРегистра.Документ = СсылкаНаОбъект;
ЗаписьРегистра.Штрихкод = Штрихкод;
ЗаписьРегистра.GUID = GUID;
ЗаписьРегистра.ДатаСоздания = ТекущаяДата();
ЗаписьРегистра.Пользователь = ПараметрыСеанса.ТекущийПользователь;
Попытка
ЗаписьРегистра.Записать();
Результат = Истина;
Исключение
Результат = Ложь;
КонецПопытки;

Возврат Результат;

КонецФункции

Функция ПодготовитьШтрихКодИзGIUDа(фGIUD, фДлина = 12)

фШтрихКод = фGIUD;

фШтрихКод = СтрЗаменить(фШтрихКод, "-", "");
фШтрихКод = СтрЗаменить(фШтрихКод, "a", "");
фШтрихКод = СтрЗаменить(фШтрихКод, "b", "");
фШтрихКод = СтрЗаменить(фШтрихКод, "c", "");
фШтрихКод = СтрЗаменить(фШтрихКод, "d", "");
фШтрихКод = СтрЗаменить(фШтрихКод, "e", "");
фШтрихКод = СтрЗаменить(фШтрихКод, "f", "");

фШтрихКод = Лев(фШтрихКод, фДлина);

// на случай, если штрихкод оказался меньше нужной длины, дополняем его ведущими нулями
Пока СтрДлина(фШтрихКод) < фДлина Цикл
фШтрихКод = "0" + фШтрихКод;
КонецЦикла;

Возврат фШтрихКод;

КонецФункции //ШтрихКодНовый()

Последний раз редактировалось: MuI_I_Ika; 03 Июл 2017, 15:07
166



Еламан Мухамбетжанов : 27 Май 2017, 12:49
у меня такая проблема штихкод выводит на 1 лист 1 штрих код а мне нужно чтобы на 1 лист этикетки поместит 2 и более штих код как этим справиться
Теги:
 

Как создать нескольких документов "расчет при увольнении" на основании кадрового документа "увольнение" как Отпуска

Автор cozuРаздел Пользователям "1С - Предприятие 8"

Ответов: 3
Просмотров: 2952
Последний ответ 21 Мар 2015, 20:24
от дфтын
Не работает структура подчиненности документов "Требование-накладная" и "Передач

Автор sv_stas_svРаздел Конфигурирование, программирование в "1С - Предприятие 8"

Ответов: 0
Просмотров: 3996
Последний ответ 10 Мар 2011, 07:36
от sv_stas_sv
Реквизит "Ссылка" у справочников и документов

Автор leklerkРаздел Конфигурирование, программирование в "1С - Предприятие 8"

Ответов: 3
Просмотров: 2833
Последний ответ 29 Май 2013, 16:24
от leklerk
"Дубляж" документов реализации в ВзаиморасчетыКомпанииОстаткиИОбороты

Автор mspuzРаздел Пользователям "1С - Предприятие 8"

Ответов: 0
Просмотров: 1696
Последний ответ 24 Янв 2014, 13:55
от mspuz
Неясна схема создания документов в "1С: ERP УП 2.1".

Автор РексарычРаздел Конфигурирование, программирование в "1С - Предприятие 8"

Ответов: 1
Просмотров: 1646
Последний ответ 29 Июн 2016, 12:04
от Sandi

* Реклама

* Штрихкодирование документов

* Поиск

* Последние задачи на разработку (фриланс)

* Реклама

* Последние вакансии

* Топ 10 авторов за месяц

oleg-x
164 Сообщений
Геннадий ОбьГЭС Геннадий ОбьГЭС
87 Сообщений
alex0402
81 Сообщений
Golickoff Golickoff
31 Сообщений
ilyay ilyay
30 Сообщений
Kironten
29 Сообщений
BuhRust
26 Сообщений
AsadRoman
26 Сообщений
AIFrame
25 Сообщений
Варвар
20 Сообщений

* Кто онлайн

  • Точка Гостей: 223
  • Точка Скрытых: 0
  • Точка Пользователей: 5
  • Точка Сейчас на форуме:

* Облако тэгов

* Форум 1С с мобильного

* Инструменты

* Дополнительно

Поиск

 
SimplePortal 2.3.5 © 2008-2012, SimplePortal