nns d0fee10e96 fix(barcode): весовой разбор выкл по умолчанию; поиск по ШК — точное совпадение

Реальный сценарий владельца: весов с печатью этикеток нет, штрихкоды весовых —
обычные коды «27xxxxx» в карточке. Исправлены два бага:
- поиск по ШК матчил весовой PLU по АРТИКУЛУ (вода арт.12345 → 1,5 кг) — убрано,
  поиск по штрихкоду больше нигде не матчит по артикулу;
- разбор весовых этикеток был дефолт-ON (WeightedBarcodeSettings.Enabled,
  Organization.WeightBarcodeEnabled) и ловил обычные коды — теперь дефолт OFF.

- ByBarcode: сначала точное совпадение штрихкода (вкл. короткие «27xxxxx»),
  разбор этикетки — только если включён в орг И точного ШК нет.
- Phase40: WeightBarcodeEnabled DEFAULT false + выключение у существующих орг;
  WeightedCodeFormat('short'|'ean13')/WeightedCodePrefix(27)/WeightedCodeDigits(5).
- Генератор ШК нового весового товара: короткий «<prefix>+N цифр» (27xxxxx, next-free)
  или EAN-13 по настройке; уникальность.
- Настройки орг отдают/принимают формат кода весовых.
- Sync отдаёт unitShort («шт»/«кг»/«л») рядом с unitCode (ОКЕИ) — shared UnitShort.
- Тесты: MobileApi (exact-only по умолчанию; не матчит артикул; PLU как ШК при вкл) 9/9;
  unit WeightedBarcode/UnitShort 16/16.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-09 11:02:43 +05:00

3.7 KiB

Raw Blame History

Весовой товар и поиск по штрихкоду — прогресс

Реальный сценарий владельца (09.10.2026): весов с печатью этикеток НЕТ. Штрихкоды весовых товаров (631 шт, вид «27xxxxx», 7 цифр) — коды, которые владелец сам генерирует и задаёт в карточке товара. Кассир сканирует код товара, вес — с весов на кассе (или вручную). Задача ЗАМЕНЯЕТ прежнюю про весовые этикетки.

Легенда: [x] готово · [~] частично · [ ] не начато.

Найденные баги (корень)

(а) Весовая «этикетка» сопоставлялась с товаром по артикулу: ByBarcode имел || (parsed.IsWeighted && p.Article == lookup) → вода с артикулом 12345 находилась по PLU 12345 из «этикетки» 2112345015007 и возвращала 1,5 кг. Поиск по ШК НЕ должен матчить по артикулу нигде.
(б) Разбор весовых этикеток был включён по умолчанию (WeightedBarcodeSettings. Enabled=true, Organization.WeightBarcodeEnabled DEFAULT true, префикс 27 в ценовых) → внутренние/обычные коды принимались за весовые.

План / статус

Разбор весовых этикеток ВЫКЛ по умолчанию (server/POS/web/mobile). Поиск по ШК — только точное совпадение (включая короткие 7-значные «27xxxxx»); убрать матч по артикулу.
Настройка орг «Весы с печатью этикеток» (как префикс МойСклада): выкл по умолчанию; при вкл — префикс(ы) + формат ПП ККККК ВВВВВ К; сначала точный ШК, потом разбор.
Касса: весовой товар → вес с весов (COM/USB, Масса-К/CAS) или ручной ввод; сумма = цена/кг × вес; «1,235 кг × 690 ₸/кг».
Генератор ШК: штучный — EAN-13 (как сейчас); весовой — EAN-13 или короткий «27 + 5» (настройка «формат кода весовых», по умолчанию 27 + следующий свободный 5-значный); проверка уникальности.
/api/pos/v1/sync: unitCode «796» → отдавать unitCode (ОКЕИ) + unitShort («шт»/«кг»/«л»); обновить docs/mobile-api.md.
Тесты (unit/integration) + full-chain без регрессий + деплой.

Автопоиск весов (данные sysadmin: МойСклад-касса спамит «Порт не выбран»/«Таймаут»)

Касса сама находит весы: автоскан всех COM (вкл. USB-COM CH340/Prolific) с Масса-К/CAS, кнопка «Найти весы» в настройках; найденный порт запоминается.
Весы не отвечают → значок «Весы не подключены» + мгновенный ручной ввод, без спама, опрос только при весовом товаре и не чаще нужного.
В логе — одна запись о потере связи, не сотни.

Что НЕ трогаем

Прод, shared-postgres, global.json, gateway nginx, sklad.

3.7 KiB Raw Blame History Unescape Escape