Веб-приложение для учета серийных номеров: как описать операции движения, обеспечить уникальность, добавить поиск, сканирование и историю по товару.
Когда серийники живут в Excel, в чатах и на бумаге, проблемы появляются тихо: один и тот же номер записывают по-разному, файл становится «единственной правдой» у одного сотрудника, а правки делаются без следа. В итоге вы тратите время не на склад и сервис, а на поиск виноватого и восстановление фактов.
Учет по серийному номеру - это учет каждой конкретной единицы товара, а не партии. Две одинаковые коробки одного артикула могут иметь разную судьбу: одну продали, вторую отправили в ремонт, третью переместили в другой город. Если вы ведете только «количество по складу», то гарантия, возвраты и разбор потерь превращаются в гадание.
Хорошее решение должно отвечать на простые, но критичные вопросы:
Роли в процессе обычно смешанные: склад фиксирует приемку и перемещения, продажи отмечают выдачу клиенту, сервис ведет диагностику и ремонт по той же единице, а администратор настраивает справочники, права и правила ввода.
Пример из практики: клиент приносит устройство по гарантии и называет серийный номер. Если учет ведется «в табличке», часто виден только факт продажи, но не видно, что эта же единица неделю назад уже была в ремонте, а до продажи лежала на другом складе. Учет по серийному номеру дает единую историю и снижает споры между складом, магазином и сервисом.
Серийный номер «живет» не в таблице, а в цепочке событий. Если с самого начала описать базовые движения, потом проще добавить поиск, сканирование и понятную историю по каждой единице. Важнее всего фиксировать три вещи: где сейчас находится единица, кто сделал действие и по какому основанию.
Минимальный набор операций лучше оформить как типы событий, а не как набор разрозненных полей. Тогда любая единица товара всегда имеет читаемую хронологию.
Чаще всего с первого дня нужны:
Чтобы данные не спорили друг с другом, у каждого события держите короткий, но обязательный набор полей: дата и время, пользователь, локации, документ-основание, комментарий. Для возврата и ремонта добавьте причину и результат.
Пример: смартфон приняли на центральный склад, переместили в магазин, продали клиенту по чеку. Через месяц клиент пришел по гарантии. Если продажа и гарантийное обращение оформлены как события по одному серийнику, сервис сразу видит дату покупки, путь товара и того, кто выдавал. Это экономит время и убирает споры.
Чтобы учет серийников не превратился в хаос, разделите данные на четыре сущности. Тогда любые операции (приемка, перемещение, выдача в сервис, возврат) складываются в одну понятную историю.
Карточка товара (номенклатура) описывает модель: название, бренд, артикул, гарантийный срок, штрихкод модели. Здесь нет конкретного серийного номера.
Карточка единицы товара - конкретный экземпляр с серийником. У нее должна быть связь с номенклатурой, собственный серийный номер, текущая локация и состояние (например, на складе, продано, в сервисе). Такой подход убирает дублирование.
Локации лучше хранить отдельным справочником. Это не только склады: добавьте магазин, зону приемки, сервисный участок, карантин для брака. Тогда перемещение - это просто смена «откуда» и «куда».
События движения - ключ к прозрачности. Документы удобны, если у вас пачки товаров и печатные формы. Для MVP проще события: каждое действие над единицей - отдельная запись, из них легко собрать историю.
Минимальный набор полей для события движения:
Пример: на приемке вы создаете единицу с серийником и событие «приемка» в локацию «Склад 1». При отправке в сервис добавляется событие «перемещение» из «Склад 1» в «Сервис», а текущая локация единицы обновляется вместе с записью события.
Серийный номер ценен только тогда, когда он однозначно указывает на одну конкретную единицу товара. Сразу решите, где вы гарантируете уникальность: глобально по всей базе или в рамках бренда, модели, партии, поставщика. Для сервиса и гарантии чаще выигрывает глобальная уникальность. Если у производителей пересекаются форматы, иногда разумнее уникальность по паре (бренд + серийник) или (модель + серийник).
Проверки нужны в двух местах. На уровне базы данных ставьте ограничение unique, чтобы система не приняла дубль даже при одновременной работе нескольких сотрудников. В интерфейсе делайте быструю проверку до сохранения, чтобы человек сразу видел ошибку.
Большая часть дублей возникает из-за мелочей. Перед проверкой приводите серийник к единому виду:
Отдельный случай - товар без маркировки. Тогда выдавайте временный номер (например, TMP-2026-000123) с пометкой, что это не заводской серийник. Когда настоящий серийник появится, делайте замену отдельной операцией, чтобы история сохранилась.
Если дубль все же найден (например, поставщик наклеил одинаковые стикеры), не удаляйте записи молча. Помечайте экземпляр статусом «спорный», запускайте проверку и фиксируйте правки в журнале: кто, когда и на что заменил. Так склад и сервис видят факты, а не «подчищенную» базу.
Чтобы учет работал без споров, у каждой единицы с серийным номером должна быть понятная «жизнь» от приемки до списания. Проще всего задавать это через события движения и текущий статус, который видно в карточке единицы.
Базовые статусы лучше согласовать заранее и не плодить десятки вариантов. Часто хватает таких:
Важно определить источник правды. Самый надежный вариант - журнал событий (последнее событие определяет текущее состояние). Поля «текущий статус» и «текущая локация» можно хранить для скорости, но обновляйте их строго вместе с событием, иначе появятся расхождения.
Отмены и исправления делайте через обратное событие, а не через удаление. Удалили перемещение - потеряли причину, время и автора. Правильнее: если ошибочно отправили единицу «в пути», создайте событие «возврат на склад» или «отмена отправки» со ссылкой на исходную операцию и комментарием.
Ответственность держится на правах доступа и аудите. Разделите роли так, чтобы ошибки не превращались в хаос:
В каждой операции фиксируйте: кто сделал, когда, откуда и куда, по какому документу или причине. Тогда в спорной ситуации видна цепочка действий, а не «последняя правка».
MVP стоит собирать так, чтобы он закрывал ежедневные операции, а не был «заготовкой на будущее». Для старта достаточно, чтобы система уверенно проводила приемку и показывала, где сейчас находится каждая единица товара.
Начните с процесса, а не с таблиц: что люди делают каждый день и где чаще всего ошибаются.
Дальше переходите к данным и проверкам. На этом этапе важнее понятные поля и защита от ошибок, чем «красивые отчеты».
Пример: вы приняли 30 смартфонов, у 2 серийники введены с ошибкой. MVP должен остановить дубль, показать последнюю локацию и дать понятный путь исправления по роли.
Если в системе есть серийники, поиск должен быть быстрым и терпимым к ошибкам. Начните с поля поиска, которое понимает частичный ввод и ведет в карточку единицы.
Сделайте подсказки: пользователь вводит первые 3-6 символов, видит 5-10 совпадений и выбирает нужное. В подсказке показывайте не только серийник, но и модель, текущую локацию и статус, чтобы не открывать лишние карточки.
Чтобы оператор не застревал из-за опечаток, добавьте простые правила: игнор пробелов и дефисов, единый регистр, предупреждение при слишком коротком запросе. Если серийник не найден, покажите похожие варианты и подсказку, где обычно путают 0 и O, 1 и I.
Фильтры держите рядом и делайте их короткими:
Из результатов поиска добавьте быстрые действия, но только безопасные: переместить, выдать клиенту, принять в ремонт. Перед подтверждением показывайте краткое резюме: что за единица, откуда и куда, кто выполняет операцию.
Для скорости храните серийник в отдельном поле и делайте индекс по нему. Для выборок по «свежести» помогает индекс по времени последнего события.
Сканирование убирает главный источник ошибок - ручной ввод. Оператор сканирует код, а система находит единицу, проверяет правила и сразу показывает, что делать дальше.
На складе чаще всего удобен USB-сканер: он работает как клавиатура (текст + Enter). Второй вариант - камера телефона: полезна в магазине, сервисе и в пути, когда нет рабочего места.
Сканирование обычно встраивают в операции, где важна скорость:
После каждого скана нужны простые проверки: найдено ли устройство, нет ли дубля, подходит ли статус. Например, если серийник уже «выдан клиенту», его нельзя принять как «на складе» без операции возврата.
Для приемки и инвентаризации полезен пакетный режим: оператор сканирует 10-100 серийников в список, видит подсветку ошибок, а затем подтверждает одним действием. Это снижает количество отмен и спорных ситуаций.
Тексты в интерфейсе делайте короткими и однозначными:
Когда у каждой единицы есть серийный номер, главный вопрос звучит просто: где она сейчас и что с ней происходило. Хорошая история по серийнику снимает споры между складом, магазином и сервисом и экономит часы на поиске.
Карточка единицы должна открываться быстро по вводу или скану серийника. В ней держите самое важное: модель/артикул, серийный номер, текущую локацию, текущий статус и дату приемки. Этого достаточно, чтобы сотрудник сразу понял ситуацию.
Дальше решает лента событий: последовательность фактов - что сделали, когда, кто сделал и куда переместили. Обычно это таблица с датой, типом события и короткой заметкой.
Чтобы история была полезной уже в MVP, держите фиксированный набор событий:
Документы можно привязывать без сложной интеграции: на первом этапе хватит текстовых полей «накладная №», «заказ №», «акт №». Важно, чтобы это было именно в событии - тогда поиск по номеру документа сразу покажет нужные серийники.
Отдельный блок - гарантия. Храните дату начала, срок, обращения и итог: ремонт, замена, отказ. Пример: клиент приносит устройство в сервис, менеджер вводит серийник и быстро видит, что товар уже ремонтировали месяц назад.
Главная беда - когда система позволяет «поправить» прошлое так, что след исчезает. Если кладовщик удалил приемку или перемещение, вы теряете ответ на простой вопрос: где была единица товара вчера и почему она оказалась в сервисе сегодня. Делайте обратные операции (отмена/возврат), чтобы история оставалась цельной.
Вторая проблема - дубли из-за грязного ввода. Серийник вводят с пробелами, разным регистром, с дефисом или без, путают похожие символы. Без нормализации и проверки уникальности вы быстро получите «две одинаковые» единицы.
Еще одна ловушка - слишком сложные формы на старте. Когда приемка просит 20 полей, люди начинают писать серийники «в комментарии» или вообще пропускать. Так партия и единица смешиваются, и серийник перестает быть ключом учета.
Что чаще всего ломает доверие к системе:
Пример: в первый день выясняется, что часть серийников короче, чем вы ожидали, а часть содержит буквы. Если валидация слишком жесткая, приемка встанет. Если слишком мягкая, появятся дубли.
Перед тем как отдавать учет серийных номеров в реальную смену, проверьте это на тестовых данных. Лучше потратить час сейчас, чем разбираться с «пропавшими» единицами и спорными гарантиями потом.
Уникальность серийника должна ловиться в двух местах: в форме ввода (чтобы оператор сразу видел ошибку) и в базе (чтобы не появилось дублей при одновременной работе). Отдельно проверьте, что формат серийника не «ломается» пробелами, разным регистром и похожими символами.
Сканирование должно покрывать ключевые операции. Если приемка и перемещение все равно требуют ручного ввода, в полях быстро появятся опечатки. В идеале оператор сканирует код, выбирает действие и подтверждает, а система подставляет данные и проверяет правила.
Карточка единицы товара должна быть короткой и полезной: текущая локация, последняя операция, кто сделал и когда. Это то, что менеджер и сервис должны видеть за секунды.
История по серийнику должна быть «непереписываемой». Ошибки допускаются, но исправляются новой операцией (отменой или корректировкой), а не правкой старого события без следа.
Проверьте роли и права:
И продумайте откат. Если случилась ошибочная массовая операция, нужен понятный план: снимок данных перед изменением, возможность откатиться и журнал, где видно, что именно было отменено и кем.
Представьте поставку на склад: 30 одинаковых устройств, но у каждого свой серийный номер. Из них 20 планируются в магазин, 10 сразу уедут в сервисный центр на предпродажную проверку. Здесь хорошо видно, зачем нужен учет по серийникам: одна и та же единица должна быть узнаваема в любой точке цепочки.
Приемка выглядит так: кладовщик сканирует штрихкод или QR на коробке, система создает запись единицы (серийник + модель), привязывает ее к поставке и фиксирует первое событие. Если часть серийников пришла списком, их можно добавить вручную, но скан почти всегда быстрее и без ошибок.
Дальше оформляется перемещение в сервис. Удобно делать это пакетно: сотрудник сканирует подряд 10 единиц, проверяет список и подтверждает. В истории каждой единицы появляется событие «перемещение», а ответственность становится понятной: кто отдал, кто принял, когда и куда.
Через неделю покупатель приносит устройство по гарантии. Сервисник вводит или сканирует серийный номер, быстро видит всю цепочку (поставка - склад - сервис - магазин - продажа) и открывает обращение прямо из карточки единицы.
Типичная ошибка: один серийник отсканировали дважды на приемке. Система должна остановить это сразу:
Так учет не «разъезжается», а каждая единица остается уникальной и проверяемой.
Если хочется быстрее перейти от идеи к рабочему инструменту, начните с набора экранов, который нужен людям на смене. Для учета серийных номеров обычно хватает 5-7 основных страниц, а остальное добавляется по мере реального использования.
Соберите короткий список ежедневных действий и превратите его в экраны и поля:
Дальше делайте MVP: пусть сначала проходят приемка и поиск, и только потом добавляйте сложные сценарии (частичные возвраты, разукомплектацию, спорные операции). Так быстро станет видно, какие поля реально заполняют, а какие только мешают.
В TakProsto удобно ставить задачи через чат: описываете экран и правила простыми словами, а дальше итеративно добавляете формы, поиск, историю событий и роли доступа. Если в процессе выяснится, что нужна новая проверка (например, запрет дублей серийников в рамках бренда или партии), правило можно уточнить и сразу встроить в логику.
Дальше все упирается в дисциплину ввода: договоритесь о едином формате серийников (регистр, пробелы, дефисы) и обучите операторов за 1-2 смены. Когда базовые процессы закрепятся, развитие идет проще: добавляете отчеты, печать, расширенные сценарии сервиса.
Если вы собираете такое приложение на платформе TakProsto (takprosto.ai), можно начать с MVP, а затем по мере роста проекта продолжать развивать его в том же контуре, выгрузить исходники или развернуть с вашим доменом и хостингом - в зависимости от того, как удобнее вашей команде работать дальше.
Учет по серийным номерам нужен, когда важно знать судьбу каждой единицы товара, а не только общий остаток по артикулу. Он помогает быстро отвечать на вопросы про гарантию, возвраты, ремонт и перемещения без «поиска виноватого» в таблицах.
Начните с пяти событий: приемка, перемещение, выдача/продажа, возврат, ремонт/гарантия. Этого хватает, чтобы видеть текущую локацию и полную цепочку действий по каждому серийнику.
Разделите данные на номенклатуру (модель), единицу товара (конкретный серийник), локации (склад, магазин, сервис) и события (журнал движений). Тогда вы не смешиваете «модель» и «экземпляр», а история собирается автоматически из событий.
По умолчанию выбирайте глобальную уникальность серийного номера по всей базе. Если форматы пересекаются у разных брендов, используйте правило уникальности по паре вроде «бренд + серийник», но фиксируйте это сразу и одинаково во всех операциях.
Ставьте ограничение unique в базе данных, чтобы дубль не прошел даже при одновременной работе нескольких людей. Параллельно делайте быструю проверку в форме до сохранения, чтобы оператор видел понятную ошибку сразу.
Нормализуйте ввод: убирайте пробелы и скрытые символы, приводите к верхнему регистру, одинаково обрабатывайте дефисы, и аккуратно работайте с похожими символами вроде O/0 и I/1. Это резко снижает количество «ложных дублей» и ошибок на приемке.
Не удаляйте старые записи и не переписывайте прошлое. Делайте исправления через обратное событие (например, «отмена перемещения» или «возврат на склад») с комментарием и автором, чтобы история оставалась целой и проверяемой.
Стартовый набор статусов можно держать коротким: на складе, в пути, у клиента, в ремонте, списано. Источником правды лучше считать журнал событий, а текущий статус и текущую локацию хранить как «кэш» для скорости, обновляя их строго вместе с новым событием.
Самый быстрый путь — поиск по серийнику с частичным вводом и подсказками, где видно модель, текущую локацию и статус. Добавьте терпимость к пробелам/дефисам и единый регистр, а также фильтры по локации, статусу и дате последнего события.
USB-сканер удобен на складе, потому что работает как клавиатура, а камера телефона полезна в магазине и сервисе. Встраивайте сканирование в приемку, перемещения и сервис, добавляйте проверки статуса и пакетный режим, чтобы можно было сканировать десятки серийников и подтверждать одним действием.
