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

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

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

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

(0) Справочник Марок должен быть справочником, но без реквизитов.

Состояния марок хранятся в отдельном РС, который архивируется.

А вот и алкоголики подтянулись ;-)

(1) ну и прикинь справочник, в котором по 50 миллионов записей в год добавляется.
архивируй-не архивируй регистр (а вообще вышедшие из оборота и оплаченные можно и коцнуть статусы наверное), справочник начнет недетски тормозить мне кажется.
по АП у меня щаз так и сделано, (если эдти по этому же пути, то пока думаю - как в типовой один и тот же заюзать для акцизок и для марок ГИМТ или разные)

(1) Текущее состояние (статус и где хранится) - очень не помешает в справочнике.
(4) 50 млн в год это еще ничего. У нас - в месяц.

(0) Только удалять, у коллеги Меркурий и ЕГАИС уже по 1-1.5Тб каждая без свертки данных, руки пока так и не доходят на свертку.

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

(6) удалять вместе со всеми строками ссылающихся на них ТЧ? (т.е. полное забвение, как и не было) ?

вобщем вынос данных во внешнюю базу SQL полагаете нецелесообразным? (немного геморрно и  сам справочник и все ссылки на него хранить и всю бизнес логики организовывать).

(9) вынос данных во внешнюю базу SQL - это если свое производство и дистрибуция, тогда проще в одной базе статусы менять

(4) не начнет

(5) Не помешает, но лучше в регистре.

(5) где хранится - в смысле на какой организации числится?

(0) Вы собираетесь дублировать у себя базу ЦРПТ? Нахрена?

Советую хранить документы (файлики xml и т.д.) во внешней базе и все. С подписями.

(14)+ Поймите простую вещь - Честный знак в лице Маркировки это единая учетная система, куда принудительно загонят весь бизнес.
А 1С останется как прокладка между единой и юзерами/ТО работающая по API и кэширующая у себя данные которых еще нет в ЦРПТ.
Или нет в ЦРПТ совсем ибо внутренние хотелки фирмы.

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

Причем первое время будет и первичку давай и старые все отчеты давай.
И что "единая бухгалтерия" не выдает отчеты регламентированные или криво выдает ))

(14) чтобы контролировать чего вообще пикают. Чтобы ШК соответствовал товару и желательно был на нашем балансе. Как WMS может это контролировать не имея инфы о своем регистре марок. В ЕГАИС такого вопроса и не стоит, тут невольно начинаешь по примеру ЕГАИС мыслить, хотя типа ЕГАИС - разрешительная система, ЦРПТ - уведомительная.

(17) С фиг ли маркировка уведомительная то?
Если ты не имеешь права получить/отгружать марки, которые не прошли по системе и обязан их вернуть назад.

(18)+ Точнее получить то можешь - дальше по цепочке низзя.

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

Если марка вернется - на ней есть DataMatrix - или не имеешь права ее принять ))

(14) Как там с Тимвиевером?

(21) Оффтопик от админа.

(22) Оффтопик - это все твои сообщения на этом форуме.

(23) Правильно понимаю что админ в твоем лице, имея хреновое настроение решил до меня докопаться с переходом на личности?

Припоминая мне мою ветку с "Аналогом ТимВьювера" и тем более "Оффтопик - это все твои сообщения на этом форуме"

(24)+ сорри не админ а "хард-модератор"

(24) Нет. Я всегда негативно реагирую, когда в тематических ветках, с серьезным лицом, предлагают кривые решения.

В данном случае хранить в базе 1С это кривое решение.

Намного лучше хранить все марки во внешней базе относительно 1С, со ссылками (УИД) на объекты 1С.
При необходимости используя API дергать эту базу из 1С.

Проблема только на строки в ТЧ объектов (документов в 1С) ссылаться, благо это редко надо и обычно можно придумать некий ключ (ДокументСсылка+НоменклатураСсылка) чтобы привязаться маркам/SGTIN во внешней базе.

Плюс подобного решения что можно сменить внешнюю базу не трогая 1С.
Или "добавить еще одну маркировку" не перепиливая в очередной раз 1С.

(27)+ Кстати на хабре вроде была статья про крупный ритейл, они по такому пути и пошли отдельной базы (не на 1С) под маркировку.
На отдельных серверах а весь существующий учетный софт почти не трогали, только допилил интеграцию.

надо было мне голосовалку прикрутить:хранить в базе vs внешнее хранилище ))

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

(20) издержки на то, чтобы  принять на что не имеешь права ниже, чем пикать все подряд. Мы и водку не перепикиваем на входе всю.

(18) уведомительная поскольку не отлупает проведение дока (как я понимаю) по маркам, которых не числится на балансе.

(29) Там скорее разрешительно-уведомительная.
Пока еще полный ахтунг например в табачке где реально уведомительная.
А кое где уже все строго например в лекарствах и там у тебя не примут ошибочную схему.

А насчет где хранить - лично я предпочитаю заранее подумать что будет через N лет а не сразу бросаться говнокодить и потом десять раз переделывать или страдать что все тормозит.
Про квалификацию не понял, 1С нынче требует офигенной квалификации.

Для некоторых случаев например можно отказаться совершенно от хранения sgtin/марок у себя.
Ибо они есть в ЧестномЗнаке и есть на товаре. Любой товар сканируем при любой операции - зачем еще в базе хранить?

(30)+ В базе нужен только признак маркированный товар или нет.
Вот тут есть проблема если одна номенклатура с одним старым ШК и есть и старый не маркированный и новый маркированный.

И если маркированный то запрашивать сканирование DM, временно запоминать а потом после отправки в ЧестныйЗнак удалять.

(13) У нас лекарства, а в МДЛП учет по складам.
(30) По лекарствам сейчас веселуха только начинается. Опт грузит аптекам, а те просто забивают на маркировку с отмазами "не знаем как в маркировке работать". Некоторые при этом товар возвращают, а некоторые - нет.

(32) 1. В МДЛП учет не по складам а по МД - местам деятельности - это так мелочь ))
2. Веселуха фигня и то что возвращают тоже фигня.
Хуже когда аптеки не возвращают и продают (не прогнав по обратной схеме и даже не подтвердив по прямой) как не маркированный а остатки зависли или вернулись поставщику.
Как раз если вернули то все хорошо!

(33)+ Самый прикол это обратная схема - оптовик даже не знает какие sgtin отправил в аптеку и если она не пропикала то концы поставщик будет долго искать ))

(34) большинство так и работает. Все оптовики крайними сделали аптеки. Причем в отдельном доп.соглашении.

(34) Большинство крупных так и работает, насколько я вижу.
Они даже умудряются своими наклейками заклеить sscc. И все, нормально хрен примешь эти КИЗы. Только через всякие анальные схемы.
У меня есть даже подозрение, что они тупо подтверждают все прямое от производителей, а потом отправляют как получится.

(34) Вот только ответственность вся на аптеках. Ну и принять в течение 5 дней (обратная схема) лучше, чем в течение 1 (прямая схема). Так как один фиг надо все проверить, а то мало ли что туда оптовик реально насовал.

(28) А я пошел по пути "отдельной базы (только на 1С) под маркировку." и через web-сервисы с ней планирую работать.

(37) Нифига там не 5 дней и не 1 а намного более мягкие сроки.

(37) + хотя не, гоню. Вроде всегда будет теперь 1 день.

(39) http://www.garant.ru/hotlaw/federal/1402472/
смотри
т) в пункте 44:

(40) (41) Они ипанулись.

Надо будет полный текст поизучать но фактически аптека часто не может за один день все принять

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

(34) Именно так. Мы отгрузили неделю назад по обратному акцепту. Десятки накладных - без ответа. И очевидно, что его не будет :)
(42) Да, ипанулись, всё верно.

а обратная схема - только в лекарствах? или в воде-молоке тоже будет? Что то я там такого не видел. (или это общий механизм для всех)

(45) Вроде только в лекарствах.

(45) Пока только в лекарствах, причем имхо зря они ее сделали

получается, что ЭДО будет обязательно во всех ТГ (рано или поздно) - тогда откуда лучше брать марки , с ЭДО или через АПИ ЧЗ?

(0) АПИ ЧЗ как понимаю речь о ГИСМП. В твоем случае именно он нужен.
ЭДО и ГИСМП разные задачи решает, для отгрузки и продажи ЭДО, для агрегации и разагрегации то ГИСМП.

(20) +100500

Смысла хранить все марки нет, сами квитанции в базе и так хранятся. Их бы тоже чистить. В идеале нужен пул кодов актуальный + допустим пару месяцев.
Все остальное вырезать, тем более в ЦРПТ все эти коды дублируются. Если в ЦРПТ нет кода и движухи по нему, то твоя личная база ничего не докажет.

(51) + Тем более запрещено хранить полный код. Ограничения на срок хранения прописаны, где непомню

(17) "Как WMS может это контролировать не имея инфы о своем регистре марок."
для ВМС сам "регистр марок" размеров 50-100 млн записей - это вообще тьфу. это вообще нисколько не проблема (если говорить по крупному)

(53) привет ))
ну ты ж знаешь-  у меня все в одной базе.. и 50 миллионов марок в год (ну это если все-все маркировать, пока конечно нет таких цифр) + минимум по 2 раза ссылки на эти марки (пришло-отгрузилось) и не кисло так набегает

(54) Ну так, не храни))) зачем они тебе

(55) + Тем более у тебя была вроде самописка адская

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

(57) У нас это добро хранится в регистре Пул кодов маркировок, где сам код маркировки это строка, полный код тоже строка. Соответственно в документах тоже строка. Если коды уже не нужны, то чистим.
Посмотри типовые подсистемы, например МДЛП, похожим образом.

(57) нахрена ВСЮ историю видеть при таких объемах? устанавливаете срок, по которому в принципе возможны расследования ситуации. (типа если марка ушла, то храним ее 4 месяца как возможный возврат/отлуп покупателя/проблема у покупателя). все что глубже - чистим нафиг/архив сторонний. если всплывает раз в сто лет проблема с глубиной более 4 месяца - "разворачиваем" из архива историю.
не?

(58) Ага. У нас так же. Как раз МДЛП) А создавать элемент справочника для марки странная идея, ИМХО.
(59) +100500

(59) ну по алкашке нет таких объемов - еще не дошли руки до зачистки. Период же не так просто определить - он же явно не виден. можно отобрать все отгруженные ранее какой-то даты марки, и по которым больше не было движений. Когда тебе надо выборочно грохать например 100 тыс записей из 5 таблиц (справочник марок, ТТН входящие, ТТН исходящие, Акты списаний/разногласий) по неск.миллионов в каждой - это не быстро само по себе. а  нас база 23/6+12 примерно работает )))

(59) т.е. по алкашке просто не те объемы, проблема не стоит так остро, чтобы ее решение получило приоритет над другими текущими задачами. А так согласен- чистить не дожидаясь перитонита.

(58), (60) - гуид меньше места занимает, чем строка в 27 символов юникода. А если надо ссылку на один и тот же код использоваться в разных документах - это же кошмар будет. Ну и реквизиты можно к справочнику привязать, например тот же SSCC, текущее место деятельности. Без всего этого - каша будет.

(63) Ну хоть кто то дошел до этого :-)

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

подчищать марки в старых доках?

(66) в каких?

ну марки же не сами по себе
как минимум пара доков

(64) А что, в типовых не так, что-ли? Странные они тогда.

(69) В типовых так - но это слабое утешение.

(69) В типовой "Библиотека интеграции с МДЛП" - строки. Что меня удивило.

(63) sGTIN это 14 цифр + 13 строго определенных символов из ограниченного набора

Это меньше чем 16 байт уида

(64) А шаг дальше кто сумел сделать?

В ЕГАИСе народ сворачивал марки в строки длиной до 8-13 символов (с редкими возможными дублями, точно не помню, но что-то то ли 10, то ли 100 дублей на миллион)

(68) а эти доки/строки в доках - нужны если вычищаем марки сами? - да скорее всего - не нужны, ибо они уже гд-то задублированы

(74) Можно хранить полные марки снаружи 1С во внешней системе.
А в 1С если так хочется только короткий id уникальный выданный этой системой. Тут никаких дублей и самое короткое.

Это если не хочется наоборот идентификаторы объектов во внешней системе хранить по типу (27)

(74) в смысле с редкими дублями? с потерей информации что-ли сворачивали, в надежде что повезет?

(76) те 100м марок это много, а 100м *2 строк документов нет?

(78) Еще умножь на количество разных маркировок, под каждую отдельные реквизиты со своими справочниками и регистрами ))

(79)+ Обычный продуктовый магазин:
1. ЕГАИС
2. Табачка
3. Ветис/Меркурий
4. Непродовольственные маркировки если есть

(76) наиболее экстремальный вариант - не хранить марки в своих УС вовсе. ЕГАИС/Ветис/ЧЗ уже являются внешней системой, хранят полные марки, имеют историю приходов\выбытий\остатков.

(81) Это вариант к которому придем потихоньку

Все, автор, спецы решили твою проблему - не храни марки в УС :-)

В типовых вообще адок с марками, в егаисе, например - хранят как строка 150 везде.
"Приятно" смотреть, как рег сведений такой открывается.. а уж что-то найти в нём.. пестня.

А так, ну у нас примерно 3млн марок на остатке, и..как показала практика, это не много, база не так пухнет.
Марки да, в справочнике у нас.
Правда, на рег сведений, пришлось свои индексы в скуле воткнуть (которые 1с-ина не в состоянии создать сама). И хрен с ним, реструктуризировать это никто не будет, а индексы свои можно и пересоздать, при желании

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

(79) вот не совсем понял, какие нужны реквизиты для разных маркировок.
подход типовых - сама номенклатура "не знает" к какой группе МТ она относится (реквизита с типом перечисление ВидыОперацийЭД в номенклатуре нет). Он где-то в ходе анализа ШК инициализируется и передается в процедуру разбора GS1 как я понял.

(84) а зачем новый индекс? Мы тоже храним ЕГАИС марки в справочнике (в наименовании), статус в РС (без исории, история косвенно по вхождению м арки в доке восстанавливается, если надо). Но индексов не делал я новых.

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

(84) В типовых - адок, когда открывается какая-нибудь поставка на 10Кмарок и формируется это уепское дерево упаковок. Можно сходить и покурить что угодно. КТшные еще ничего.

(85) делать на основе анализа ШК какие-то выводы о смысле товара, закодированном этим ШК - трэш полный.
совершенно спокойно ШК похожий допустим на тот же самый sGTIN (ГТИН+серия) - вообще может не иметь никакого отношения к маркировке.

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

(88) это можно делать только в том случае когда в обслуживаемой системе только конкретный вид товаров, и гарантируется что нет других "таких же" же, относящихся к немаркируемому товару.

(89) Да, периодический, подчиненный регистратору - https://youtu.be/9mvm0TlHO4s

(89) Страшное там то, что это уепское дерево постоянно меняется, процедуры тасуются и связь тоже гуляет - когда и по идентификатору, когда по справке Б

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

(86) Можно и к РС - если хочется создать себе трудностей из ничего и придумать эмулятор справочника. Через точку в реквизиту РС не обратишься. И не надо клевать, что это ужас-ужас - это очень удобно. Банальная кнопка "Перейти к движениям по этому коду", "Перейти к подчиненным кодам" - в справочнике делается очень удобно.
А в групповом коде отлично смотрится табличная часть - в случае нескольких разных серий одного SSCC. Как это сделать в РС - лепить еще один РС "Таб.часть"? Оно надо?

А еще..в старых версиях, при смене детализации в форме проверки, оно целиком херилось.
Да и вообще, там много всего доброго и светлого.
Если такая же реализация там с сигаретами..то ой
:)

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

(94) в справочнике хранятся и коды товаров и коду агрегированных упаковок?
что такое "подчиненные коды" - вложенные в тару (код которой записан в самом элементе справоника "коды")?

(97) да. "агрегаты".

(96) "запрос останков_мини" -вообще не понимаю, к чему он нужен.

(99)
:)

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

(100) Никогда не было проблемы получить остатки по многотысячам позиций с детализацией по товарам.

Если конфа, кт, например, то получение обычного запроса останков приводит к перезаписи всей егаисной номенклатуры и всех связанных справочников - справки, производятелы и т.д.
В далионе, например, оне сымотрят, если есть справочник, то его не перезаписывают.
Но, в далионе тоже нет останков _мини

(101) ну, у нас 3 мульта на остатках, по другой фирме 6.. как то не очень переписывать все справочники

(102) Там смотрят на модифицированность АП

+ я могу запросить 2 раза останки в час, а не один

(104) в новых версиях так ? Не смотрел, в старых всегда перезапись

всех реквизитов

(106) Ну вроде нет. Вот есть проверка:

    |    ВЫБОР
    |        КОГДА алкКлассификаторАлкогольнойПродукцииЕГАИС.Ссылка ЕСТЬ NULL
    |                ИЛИ ТаблицаАлкогольнойПродукции.Наименование <> алкКлассификаторАлкогольнойПродукцииЕГАИС.Наименование
    |                ИЛИ ТаблицаАлкогольнойПродукции.НаименованиеПолное <> (ВЫРАЗИТЬ(алкКлассификаторАлкогольнойПродукцииЕГАИС.НаименованиеПолное КАК СТРОКА(1000)))
    |                ИЛИ ТаблицаАлкогольнойПродукции.Объем <> алкКлассификаторАлкогольнойПродукцииЕГАИС.Объем
    |                ИЛИ ТаблицаАлкогольнойПродукции.Крепость <> алкКлассификаторАлкогольнойПродукцииЕГАИС.Крепость
    |                ИЛИ ТаблицаАлкогольнойПродукции.Производитель <> алкКлассификаторАлкогольнойПродукцииЕГАИС.Производитель
    |                ИЛИ ТаблицаАлкогольнойПродукции.Импортер <> алкКлассификаторАлкогольнойПродукцииЕГАИС.Импортер
    |                ИЛИ ТаблицаАлкогольнойПродукции.ВидПродукции <> алкКлассификаторАлкогольнойПродукцииЕГАИС.ВидПродукции
    |                ИЛИ ТаблицаАлкогольнойПродукции.ТипПродукции <> алкКлассификаторАлкогольнойПродукцииЕГАИС.ТипПродукции
    |            ТОГДА ИСТИНА
    |        ИНАЧЕ ЛОЖЬ
    |    КОНЕЦ КАК ЕстьИзменения

Там только не учтена обрезка пробелов в наименованиях и тут может быть косяк.

(108) ну всё равно.. много чего не хватает :)
Да и..в мини нафик проверки не нужны, всё быстрее прилетит и запишется.

(109) Свежая, новая АП, которую за тебя подтвердил поставщик...

(63) Проходили уже это, адски тормозит. Один запрос кодов может быть в 150к, а это один из многих в день. Соответственно запись такого добра не быстра. А если учесть, что хранить в документах не обязательно, то и преимущества ссылок исчезают

(71) Опять же в угоду скорости.

(72) Даже короче, так как полный код хранить не надо, он есть только в пуле. Нужен только серийный номер, который до 13 или 17 символов. Остальное хранится в Пуле, или можно динамически собрать.

(81) И это в целом правильно, код это (пишу по памяти): 01 + Gtin + (еще пара символов) + Серийный номер + GS + срок годности (только для молочки) + криптохвост. Из этого всего достаточно хранить серийный номер, остальное можно собрать или запросить в ИСМП

(85) Эта процедура разбора вообще адовый. На более не менее больших объемах ложиться ножками к верху.

(114) gtin внутри DM может не совпадать с линейным ШК

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

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

(111) "запись такого добра не быстра" - какого именно добра?

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

(120) у нас РС "состояние марок" с измерениями Серия-Марка (ну в серии косвенно и организация и справка Б, но понятно это не индексируется).
а вообще насколько часто нужно получать такие данные? я понимаю типовой сценарий - пикаем паллету - перед тем, как запихнуть все ее марки в накладную, можно убедиться в том, что они все еще на балансе.. (но это конкретное множество марок, всех в одной серии).

Возвращаясь к топику (маркировка ГИСМТ) - вообще не уверен, что буду проверять статусы про при подборе товара. И получается марки нужно хранить, только ради того, чтоб наполнить ими отгрузку (и потом при необходимости учитывать разногласия для частичного их возврата)


в общем либо у нас объем не тот либо такие вопросы не задаем своей УС. (моет для розницы более актуально - атак Р1-р3 совпадают, серия кончилась- марки до свидания и слава богу).

(111) Парсинг КИ, запись в справочник.

(122) Как скорость записи в справочник отличается от скорости записи одной записи в РС? И там, и там - запись в таблицу.

(123) если справочник имеет ТЧ, то появляется паразитный траффик на вторичную таблицу.

(123) нифига подобного скорость записи в РС на порядки бывает выше записи в справочник

(125)+ Любой справочник (или документ) имеет уникальную ссылку (уид) и проверка уникальности же.
В РС нет "ссылок на записи"

Но писать во внешнюю базу (нормальную) это еще быстрее чем в РС в 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)+ато курю курю доку, что-то плохо понимаю как эффективно использовать их АПИ..