Всем привет.
не нашел подходящей ветки, поэтому еще одну по маркировке завожу..
В первую очередь для оптовиков (у которых немалые объемы проходят).

Пусть сейчас заводят только отдельные группы товаров, но если делаем ИС, то уж на все.. через 3 года (по планам), ну пусть 5-6 по факту должна быть маркировка всего! (гибель оптового звена как бизнес-класса пока не рассматриваем).

Типовые 1С предполагают хранения всех марок в соответствующем справочнике... (и ссылки на него в табличных частях соответствующих документов).
все бы ничего, но например у нас за год проходит 1.4 млн штук по молочке, и 2.4 млн. штук по воде..
а если посмотреть на всю перспективу то ~50млн штук. (ну пусть среди них есть чупа-чупсы, которые наверное маркироваться будут по 100 штук но это редкий кейс).

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

Но писать во внешнюю базу (нормальную) это еще быстрее чем в РС в 1С ))

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

(126) ты удивишься но в рс тоже бывает уид

Для брезгающих справочниками. Прогнал тест.

РС - 1 измерение (строка 27)
Справочник - наименование длиной 27. Без кода.

Запись в РС 10 000 элементов - 61 сек.
Запись в Справочник 10 000 элементов - 66 сек.

Обалдеть разница.

(130) А теперь тоже самое но параллельно в 50 фоновых заданиях на сервере

(131) "А вот если залезть на шкаф..." (с) анекдот
Оно зачем? И что случится?

Вот эта картинка - показательна:
https://yadi.sk/i/dzf9UTQu6Mf3bg

Да, сам такой справочник занимает места больше, чем аналогичный РС.
Но если в РС и справочник будем добавлять одинаковые реквизиты - разница нивелируется.
И, самое главное, чем больше документов, тем больше будет проигрывать строка: в табличной части она занимает почти в 2 раза больше места.

РС позволяет работать с НаборамиЗаписей.

(133) Но, к сожалению, нельзя набором записать блок записей с разными изменениями. Те же 100500 КИЗов, у которых ничего общего. Да и нужно такое разве что самому ЦРПТ, который эти коды миллионами выдаёт.

(134) Слава яйцам, марки лучше хранить рядом с партией.

(135) но бывает и не партионный товар.
или даже для партионного (меркурий) - пришло в накладной 1000 штук (марок) по 5 партиям, и нигде инфы нет какие марки по каким партиям 9а сами мы сканировать не будем)

та что для ГИС МТ видимо вообще не буду учитывать партии (в т.ч. пустую), так что пока не придумал что учитывать и как (организацию и товар видимо, чтобы не полагается на содержимое ШК в плане привязки к товару, т.к. это геморой и проблемы).

(136) Зачем партии когда уже поштучный учет?

Это к тому что новая штука (с уникальной маркой/sgtin) - новая номенклатура или характеристика уникальная (тут с шк удобно и стандартно) а во всех доках кол-во =1 :)

(137) для меркурия как минимум

Партия при поштучном тем более нужна.

(138) дык там просто кол-во дробное ))
пришла тонна или цистерна молока а продаем литрами - хотя можно долями от тонны или цистерны с дробным кол-вом ))

(139) если все марки/sgtin хранятся в базе 1С то партии (как некая сущность) уже не нужны
они автоматом вытекают из дока поступления по некоему общему признаку штук

(140) в любом случае учет по сериям.. (а марки - это параллеьный и не связанный с ним поштучный учет получается)

(141) в доке может быть 5 партий одного и того того жетовара

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

(141) Это все прекрасно во вселенной с единорогами, пока не начнется проблема с расследованием, почему марка не прошла через ГИС.

(123) Разное количество полей - вестимо

(134) Можно;)

(147) как?

(148)

(148) +     НЗ = РегистрыСведений.РегистрСведений1.СоздатьНаборЗаписей();
    
    Для I = 1 По 1000 Цикл
        
        Измерение1Объект = Справочники.Справочник1.СоздатьЭлемент();
        Измерение1Объект.Записать();
        
        Измерение2Объект = Справочники.Справочник2.СоздатьЭлемент();
        Измерение2Объект.Записать();

        
        НС = НЗ.Добавить();
        НС.Измерение1 = Измерение1Объект.Ссылка;
        НС.Измерение2 = Измерение2Объект.Ссылка;
        НС.Измерение3 = Перечисления.Перечисление1.ЗначениеПеречисления1;
        НС.Ресурс1 = I;
    КонецЦикла;
    
    НЗ.Записать(Ложь);

(150) Офигенные технологии.

(151) Ага, сногшибательные.)

(150) Интересно, как такой код (дописывание новых) работает на миллионах записей? Какие запросы в SQL прилетают?

(153) Нормально работает

(153) если это независимый, не подчиненный + обменданными.загрузка = истина, то там простой инсерт, без проверок

поентому..не так и медленно

(30) если не хранить, то как обрабатывать сканирование групповой тары? на каждый пик ТСД запрашивать ЧЗ про агрегат?

(157) Речь о пропикивании каждой штучки внутри групповой или просто операции с групповой?
Что подразумевается под "обрабатывать сканирование групповой тары" ?

Гарри счаст в походе,
Вернется едва-ли..

(159) Лечиться не пробовал?

(160) Не пытаться давать советы там, где нет компетенций не пробовали*

(161) вот тут Как получить HWND окна 1С (обычные формы)
было эпичное утверждение в посте 16

это так в тему о компетенциях и советах

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

Учись, Гарри.

(158) вообще фраза "сканирование групповой тары" - какая-то тотальная безграмотная бредятина

(165) Коробки, паллеты не сканируете?

(166) сканируем. но это никак не "групповая тара"
даже если сканируется пустая тара (именно ТАРА, именно пустая) для последующего подбора в нее товаров - она никак не может быть "групповой тарой".

Ну да "сканирование групповых/агрегатных кодов" чуть логичнее.

Один хрен вопрос зачем и какие данные полученные из ЧЗ в этот момент надо хранить?
И для чего?

Все равно чтобы отразить в ЧЗ операцию с групповой - делать туды запрос.
Ну так сделать два запроса один перед операцией а второй после.
Если ЧЗ не пашет один фуй операция не пройдет.

(164) Мне у алкоголиков учиться пока нечему, они до сих пор на помарочный не шмогла.
"В целях недопущения распространения новой коронавирусной инфекции (COVID-19), в дополнении к информационному сообщению, Росалкогольрегулирование сообщает об изменении срока полного перехода на поштучный учет алкогольной продукции в ЕГАИС на 01.11.2020."

А МДЛП уже с 01.07.2020 пашет как бы ))

(168) для, того чтобы понимать, что это уже выгружено.
Но у них на самом деле, тоже, не супер крутые разрабы сидят...
Вот новая версия 21-ая версия API вышла,генерим по ней вывод из оборота, а вам блять ошибка ; дескать не соотвествует xsd схеме, перелопатили все схемы, все примеры все как надо, но нет....
И как обычно проблема будет на их стороне..
Потому что, все что делается на гос. деньги, делается на отъебись..

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

(27) Подобная схема вами где-то применялась? Опишите, пожалуйста, кратко - какая область, какие проблемы, какие преимущества, почему решили сделать так?

(172) Кратко:
фармацевтика (МДЛП)
проблем особых нет
преимущества почти не надо трогать конфы 1С
потому что 1С77 где все плохо с прямой работой по api а раз сделали промежуточное внешнее решение почему бы его не расширить для хранения sgtin в привязке к кодам/ссылкам

(169) Да, тебе действительно учиться противопоказано.
Полный переход - означает перевод на помарочный заявки на эмиссию марок в производстве и импорте.
Все остальное, включая регистрацию выпуска и импорта, все оптовое и розничное звено - уже как год на помарочном.

(158), (165) да, имелось в виду сканирование групповых.агрегатных кодов. (т.к. сами не агрегируем, то под групповой тарой устоялся, возможно не вполне корректный внутренний термин, означающий групповой код).

(170) сборщик собрал товар, надо подготовить ТТН (и желательно загрузить, распечатать доки, отправить в ЧЗ и т.п.). Кроме того после передачи отсканированного групповой кода WMS должна понять, сколько товара сборщик забрал со склада, надо ли еще забирать (или может он лишку схватил). И это надо делать !сейчас", лишняя секунда в задержка - уже негатив со стороны сборщиков (кладовщиков), которым надо косить/зарабатывать и тормоза склада.

Коллеги привет )
в порядке ап’а
Я тут наконец должен скоро вернуться к допилке под марки нашей нетленки..
подскажите несколько практических вопросов.
1. Правильно я понимаю, что ШК аггрегата ничнем не отличается от ШК марки? Т.е. при сканировании понять нельзя агрегат это илим арка-  надо тупо проверять по базе?
2. Чем чревато отгрузить марку, которая не значится на балансе (ну вот по факту пикнулась, по по ЭДО ее нам не передавали) – (молочка-вода)?
3. Если по п.2 считаете это недопустимым, то как разруливаете? Сборщику – отложить товар до разбирательств, а потом? Есть процедуры постановки выявленных марок на баланс свое организации? (и вообще как с пересортами бороться)
4. Претензионная работа с покупателями – есть уже практика/предположения.. что-то я сомневаюсь, что многие клиенты смогут корректно недопоставки отражать – выставлять акты, с указанием неполученных марок (а это вообще предусмотрено в АПИ/схемах документов)? По ЕГАИС зачастую клиенту тупо отклоняют накладную целиком и просят выставить чистую с «правильными» марками (чтобы их вычислить приходится жать возврата брака или фотки марок с места клиента юзать.

апнуть наверное лучше утром ))

Можно ли как то через Честный знак узнать, в каком статусе и у кого пачка табака?
Есть ли аналог check1.fsrar.ru?

(179) я так понимаю что можно запрашивать только по своим кодам:
из доки по API:


2.1.1. Метод получения списка КМ по заданному фильтру с подробной информацией о КМ
Метод возвращает список КМ с подробной информацией, которые доступны в данный момент времени участнику оборота товаров (ИНН определится по токену), согласно заданному фильтру.
URL: /api/v3/facade/identifytools/listV2 - устаревший вариант, далее использовать: /api/v4/facade/identifytools/listV2
Метод: GET
Пример запроса:
curl -X GET '<url стенда v4>/facade/identifytools/listV2?\ limit=10&order=DESC&orderColumn=emd&\ uit=010469022978096621qSF7qjA3aRIqM2406402&\ orderedColumnValue=2019-01-23T08:42:17.593Z&pageDir=NEXT' \ -H 'Authorization: Bearer <ТОКЕН>'

а есть у кого образцы ШК для молочки? (прямо картинки)

и не вполне понял чем отличаются:
API ГИС МТ (напр. Версия 24) - методы обмена инфой о марках, но и отгрузка тоже
и
True API (напр. Версия 6.4) -

это частично перекрывающиеся описания одного и того же API ?

ппро групповой ШК
как я понимаю это в обязательном порядке SSCC код (18 символьный). Надо понимать, ФЛК систем не пропустит коды, не подходящие под этот формат?
Не члены UC1 не могут агрегировать?
т.е. мы сами как оптовики у себя не сможем делать агрегацию, или если забить на
"
префикс компании ГС1 - глобальный уникальный номер, присваиваемый члену ГС1 (9 цифровых символов);
"
а тулить свои 9 цифр какие-нибудь, то тоже пройдет?

в типовых я так понимаю и КИГУ и КИТУ - все сидят в справочнике ШтрихкодыУпаковокТоваров
только КИТУ можно переагрегировать и создавать самим а КИГУ? они незыблемы? Если из ящика продана одна пачка, то КИГУ "расформировывается"? КИГУ тоже стоит 60 копеек как и обычная марка?

(184) Я не понимаю ваших терминов. КИГУ- это что такое? Поискал бегло в интернетах - не нашел.

(182) Это разные АПИ. Изначально был "обычный АПИ", его и точили, но он больше нацелен на обувь и табак. Потом, при подходе к прочим товарным группам этот АПИ перестал подходить (под каждого надо было много чего перепиливать) вот и родилась идея сделать новый АПИ, который бы подходил всем. Его и обозвали ТруАПИ. Вот только попробовал я инфу по списку марок через этот ТруАПИ получить и словил много косяков. Через 3 дня мучений переключился на обычный АПИ и за 2 часа все у меня заработало.

(180) На сколько я понял, по своим маркам в ответ придет больше информации.

(185) КИГУ это я пытаюсь в никнуть в глоссарии ЧЗ - код идентификации групповой упаковки - я так понимаю это тоже платный 2D ШК, т.к. ГУ может отгружаться покупателю - например блок/ящик сыров (в отличие от транспортной упаковки ТУ, которая видимо ТОЛЬКО для логистической обработки и ее код формирует участник (отправитель) по правилам SSCC).

(186) КИГУ тоже формирует участник по правилам SSCC , в целом он им и является

(185) про разные АПИ.. т.е. сейчас труАПИ на ваш взгляд не вполне работоспособен?

(187) привееет.. а чо в глоссарии к молочке написано, что КИГУ - последовательность бла-бла, формируемая оператором?

вы там допилили готовое решение?

(188) Много изменений, но в будущем все будет на тру апи

(189) Узнаю по поводу оператора, в нашем решении формируется внутри.

И его допилить невозможно, постоянно что то надо делать)

продолжаем вопросы от нуба:
ладно. вопрос про КИТУ / КИГУ пока оставим в стороне, с хоопарком АПИ прояснили, но все равно схема у меня что-то не вытанцовывается..


Как выстраиваете схему обмена данными

– первично ЭДО? не вполне стандартизировано т.к. готовых интеграций с разными провайдерами нет, т.е. если например хотим с «контуром» – покупать их модуль с 1С и допиливать либо ваять своё с нуля (опять же купив подписку на их API). (либо вариант роуминга через 1С-ЭДО но когда своя нетиповая, то не факт что это проще)
Получив из ЭДО документ – ищем его в ЧЗ и подкачиваем нехватающие данные? (иерархию транспортных упаковок и марок?). Как узнать поданным ЭДО guid документа в ЧЗ? Или сопоставлением пономеру-дате-поставщику?

– или наоборот – первичен ЧЗ, запрашиваем там перечень документов, загружаем новые (ну по молочке мы загружаем из меркурия, тут будем подцеплять к существующим). Тогда требовать от поставщика выгрузки своего документа в ЧЗ (помимо отправки ЭДО).

(34) самый прикол это когда завод отправил в палете чужую первичную, оптовик это дело принял (но нифига не отметил в ЧС), отправил на регионального оптовика (это тоже не фига не зарегал приемку в ЧС) и отправил это все на аптеку. Торопыги да. И вот аптека которая тоже забила на все болт пытается продать не разагрегированный товар ...

(192) Получив из ЭДО документ – ищем его в ЧЗ и подкачиваем нехватающие данные?
Насколько я знаю, в ЧЗ ЭДО сторонних операторов (не ЭДО-лайт) появляется только после подписания со стороны покупателя. У нас основная масса поставщиков выгружает напрямую в ЦРПТ, оттуда по API получаем и сравниваем массивы КМ. Если по ЭДО отправили, то парсим XML и так же сравниваем. В основном обувь не агрегируют, но если агрегируют, то по непонятному алгоритму то удается получить содержимое, то нет. Например пару недель назад перестал работать метод api/v3/true-api/cises/list, получал содержимое коробов еще не подписанного ЭДО, пришлось запрашивать у поставщика содержимое.

(194) сравниваете - имеется ввиду проверка при приемке?
у вас розница?

(195) Да, сравнение КМ в документах/по факту. У нас и опт и розница.

(188) "про разные АПИ.. т.е. сейчас труАПИ на ваш взгляд не вполне работоспособен?"

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

Начал с ТруАПИ и, на каких-то марках, у меня выборка опять начинается с самой первой. Я не понял, еще раз - опять так же, поменял размер блока с 500 на 498 - слетело в другом месте. В итоге, методом проб и ошибок, пришел к выводу, что если в марке есть какой-то "кривой" символ (типа "=", "/", "(" и т.д.), то выборка ТруАПИ "слетает". Никакое экранирование не помогало. Решил, что справлюсь и начинаю с последней марки проверять на эти "кривые" символы, если есть, то беру предыдущую. В итоге выборка работала, но тоже до определенного момента. Второй момент был более неожиданным. Оказалось, что нельзя было получать более 1542 марки. По обычному АПИ такое уже встречалось и решалось параметром "cashe"=false, но нигде в ТруАПИ это не применялось. Это ограничение уже никак было с моей стороны не обойти, поэтому попробовал "Обычный АПИ"

Никаких проблем с марками со спецсимволами! Никаких проблем с ограничением выборки (с тем самым параметром "cashe"=false)! Все марки спокойно получил, в базу к себе сложил и пошел дальше работать.

З.Ы. Разбирался со всем этим в середине июля, х.з. как там сейчас ТруАПИ поживает. Проверять, пока, желания нету.

(196) у вас нетиповая? марки храните пообразцу типовой (с справочник ШКУпаковк с ТЧ для вложенных?)

(198) УПП + Хамелеон. Да, из типовой используется только ШКУпаковок с табличными частями. Хамелеон-для общения по API с ЦРПТ, блок сканирования/сбора марок,учета остатков + генерация документов хамелеоновских и мобильное приложение самописные (внедрялось в январе, для УПП еще ничего не было, частично дергал с УТ11).

(199) о, можно в личку )) ?
в телеграм например (@ EuVodoley)
я пока погуглю что такое Хамелеон

я как раз хотел спросить немного расспросить про логику типовых с их ТЧ, когда и куда они пишут статусы, и насколько удобна/неудобна именно такая организация (в ЕГАИС мы не так сделали).

Нам очевидно придется все КИТУ/ГИТУ разворачивать до штучек,т.к. сборка штучная и в момент сканирования уже некогда с ЧЗ выяснять, все марки будем вытягивать заранее. (тут мне говорят, что ГИТУ это тоже что КИТУ но я как-то тогда не понимаю логику)

ну и другие вопросы. (если честно я немного в растерянности, никак не спроектирую как нам надо, чтобы и попроще и легло на нашу специфику).

кстати - а бывает у вас, что фактически один и тот же товар по каким-то причинам учитывается на разных "карточках"? и например одна и та же марка может относится к одному товару и к другому. Может быть разная вложенность в короба например - правда тогда у них разные коды ITF, Или по внутренним соображениям разделять (промо/не промо, еще что-то там).
Получается, что связь ШКУпаковки (КМ) <-> номенклатура, ограничивает гибкость, напрашивается связь ШК<-> GTIN

(201) Вы это что сейчас написали? Одна марка - это один товар. Все. Сама суть маркировки именно в этом.

(202) если один и тот же товар фасуется в разные упаковки (например 8 или 12 банок в ящике) то у нас это разные товарные позиции. (при это ШК штучки один и тот же)

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

Мультипак и поштучная банка - у нас это разные карточки товара (и в мультипаке "квант" товара это та же банка, с тем же ШК, хотя кратность отрузки - мультипак).

(203) А... у себя можете городить что угодно, я же про обязательную маркировку и там таких вольностей нет.

(203) В маркировке каждая банка в ящике имеет свой уникальный SGTIN.
И все групповые упаковки (ящики из  8 или 12 банок аналогично имеют свои уникальные SSCC, для каждого ящика.

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

та же тривиальная ситуация когда в одной накладной 2 позиции (ну у нас это 2 позиции) с одинаковыми GTIN но разными ITF (разная вложенность в ящики) - скорее всего в УПД придет одной строкой со всеми марками га этот GTIN.

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

интересно что может значить фраза в письмо о рабочих группах по маркировке:

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

хотят чтобы маркированная продукция отличалась от немаркированной на уровне GTIN?

коллеги - еще вопрос -
в каких бизнес-процессах нужен криптохвост?
в кассу при пробитии - он нужен?

например если у нас склад собирает допустим под оптовую и под розничную продажу, без допикивания на кассе, то получается, что если собирается заказ для отдачи в розницу, то ящику нужно пропикивать поштучно?
хотя вроде код проверки не нужен для формирования тега 1162 в чеке. А где он (код проверки) вообще нужен?

т.е. никто не знает? или я тупой вопрос задаю?

мне подсказывают, что в новом формате ОФД в новых ФН нужно будет хранить весь ШК..
получается в розницу нельзя будет продать КИТУ не перепикав все марки,  например ящик сырков Hoсhland.. 6 штук в ящике - это около 200р.. а надо будет каждый пикать 😱

(200) Из типовых механизмов пользуемся только справочником ШтрихкодыУпаковокТоваров и ТЧ ШтрихкодыУпаковок. У нас обувь, кодов немного (около 120 тыс. пока, 40 тыс. было остатков и 80 тыс. пришло), по сравнению с вашими объемами - слезы, так что проблема хранения особо не стоит, статусы пишутся в 3 регистра накопления хамелеоновкие (остатки КМ, резервы КМ (отгруженные, но еще не обработанные в ЦРПТ и эмитированные КМ (еще не введенные в оборот, он пустой).

(208) Криптохвост не используется вообще нигде, везде передается только GTIN+серийный номер.

(211) про хвост порадовали! уррра )
но... что-то начинаю подозревать, что в следующем году нужно будет при пробитии на кассе передавать КМ, включая криптохвост:
https://its.1c.ru/db/newscomm/content/471190/hdoc

(212) Это и сейчас надо, т.к. сканируя марку вы передаете ее всю на кассу. Смысл какой при этом отрезать от нее криптохвост?

(213) Сейчас? С чего бы?
4. Резерв
Байты [22:32] (11 байт) – зарезервированы, и не используются. Резерв в ККТ не передается
Пока допустимо так: https://cloud.mail.ru/public/8VpH/2VfJTcsHx
Отрезать ничего не надо, просто передаем то, что требуется.

Хотя, я смотрел в новых релизах восьмерки, уже передают код полностью, в тег 1162. Думаю, пока это "задел на будущее". ОФД вроде переваривает коды и так, и так. Но, в ФН, как я понял это пока не хранится. В новых, обещают, что будет.

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

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

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

(217) в сигаретах блок это КИГУ - у него код DM со своим криптохвостом. Во всех остальных категориях товаров КИГУ не бывает - только КИТУ это обычный SSCC код и я сомневаюсь, что его можно пробивать на кассе.

(218) емнип, сейчас ккм ожидает от УС\Пользака gtin+serial.
этого в КИТУ нет, там GLN+(твой любой серийник).
ну вот когда ффд 1.2 дойдет до касс и станет обязательным, тогда и почешетесь. а сейчас, вроде, не к спеху?
ящик маленьких хохландов, скорее всего обзаведется КИГУ.

(215)
4.6. Справочник "Типы упаковки"
BUNDLE Комплект
Используется только ТГ
"Предметы одежды, бельё постельное, столовое, туалетное и кухонное"
"Духи и туалетная вода"
"Фотокамеры (кроме кинокамер), фотовспышки и лампы-вспышки"

(219) у нас есть сторонняя подсистема.. и если нужно будет менять структура передаваемых от сканера в БД данных там довольно геморройно вносить изменения

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

(218) Вы же понимаете, что сигареты - это уже принятые Постановления Правительства и озвученные правила игры, а молочка ваша - это только проект? Или у вас уже нормативка утверждена и там явно прописано, что по молочке КИГУ не будет?
P.S. Не моя тема, поэтому в детали законодательства в этой области я не вникал.

(222) согласен...только как себе наше родное, сверхтехнологичное, цифровизированное правительство предполагает работу участников рынка? если с 20.10.21 уже все должно работать??
впрочем чему я удивляюсь...

(223) Оно себе предполагает просто. Вот законы - выполняйте.
Захочешь остаться на рынке - выполнишь. Некоторые обувщики решили, что нафиг им этот цирк не нужен и ушли с рынка. Тоже вариант.

(224) здоровский подход.. впрочем в политику и качество администрирование пожалуй не стоит уклонятся.. пустое это все ((

Народ!! - лучше киньте мне пример - результат запроса к ЧЗ о содержимом документа (или какими вы запросами пользуетесь для получения данных из ЧЗ для создания/заполнения в своей УС данных о марках, когда вы покуптель-оптовик) - в JSON или XML?, ну чем пользуетесь

(225)+ато курю курю доку, что-то плохо понимаю как эффективно использовать их АПИ..