Есть вдоволь переписанная комплексная на 7.7 у клиента.
Внезапно свалилась маркировка, не отвертеться, решили все таки дописать 7-ку по упрощенной схеме, маркированных товаров не много.
Есть несколько вопросов.
1. Для хранения маркировки завести справочник? Для уникальности в коде 1С ограничение на 24 символа, в марке 31.
Но есть <SERIAL>, в котором 13 символов. Он уникальный? Или уникальный в пределах <GTIN> ?
Или тупо завести строковый реквизит с отбором и по нему искать?
2. Надо ли хранить остатки в базе по кодам маркировки? Или тупо подбирать из справочника в отгрузке?
А в справочник прописать признак использования, например?

(0)>> Надо ли хранить остатки в базе по кодам маркировки?
Надо бы ,чтобы потом непоняток не случилось

"Но есть <SERIAL>, в котором 13 символов" - там еще спецсимволы могут быть. Учти. А ещё разный регистр = разные коды.

(2) Спецсимволы? Они вроде после 31 начинаются, не?

(0) Сначала ответь на вопрос "Зачем хранить в базе?"
Дальше все будет понятно

сделано уже.

(4) Ну в базе полюбому как то хранить, например что бы сформировать УПД в эл. виде....

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

(7) Я тоже склоняюсь к тому что учет останков не нужен. Но справочник просится.
Мы производители, значит будет ввод в оборот. Продажа своей фирме в этой же базе, от нее приход и опять реализация. Значит уже в 4 местах используем. Лучше буду хранить в справочнике.
Причем наши покупатели конкретно этих маркируемых изделий - конечные потребители. То есть сразу сами и выводим. В итоге работа ради работы....

Я думаю, лучше хранить хранить марки и вести учет по ним ВНЕ базы 1С 7.7.
Это если нужен универсальный вариант, независимый от типа базы DBF/SQL.
И учитывая что 1С 7.7 не резиновая, в отличие от той же 1С8.

(9) Городить огород ради экономии места? У меня SQL, там нет такой проблемы.

(3) В коде маркировки допустимы символы: !""%&'()*+-./

(0) >Внезапно свалилась маркировка, не отвертеться, решили все таки дописать 7-ку по упрощенной схеме, маркированных товаров не много.
>Есть несколько вопросов.

Бегите.
В смысле хочу сказать что нихрена не получится легко и просто без опыта.
Там граблей дофига и больше.

И вас вопрос ни о чем.

Ответь уже на (4)

Ибо в (6) где:
>сформировать УПД в эл. виде

нет ответа а каким местом в УПД ты будешь правильные уникальные для каждой штуки SGTIN подставлять?
У вас эта УПД до реальной сборки (отгрузки) товара на складе или после (в процессе)?

(11) Они могут не сохраняться в 1С? Вроде обычные символы. В чем проблема?

(12) "Бегите." - Ага, щас, собираюсь уже, пошел заявление писать....
В реализации видимо надо сделать механизм ввода SGTIN для маркированных товаров.
Бухгалтерия оформляет реализацию, кладовщик в нее сканирует коды. Дальше все это выгружается в ЭДО.
В принципе разобрался уже в структуре данных, осталось наваять ввод останков и прикрутить коды к реализации. Вот тут вопрос - либо сделать разбивку построчно в самой реализации, либо отдельную "табличку" со списком и привязать к строке реализации.

(14) >кладовщик в нее сканирует коды

И нахрена тебе хранить в базе в отдельном справочнике если "сканирует коды"?
Нужен просто для номенклатуры признак "Маркированный товар" и в Реализацию отдельными строками с кол-во = 1.
Ну и реквизит ТЧ (SGTIN) куда из DM вытаскивается и затем в УПД

(15) Справочник нужен для того, что не хранить одинаковые строки в 4-5 документах. Будет цепочка реализаций между своими юрлицами.

(16) Эээ вот тебе не пофиг ссылку на элемент справочника или сам sgtin 27 символов в строках документов?

(16) >"Будет цепочка реализаций между своими юрлицами"

Вот маркировка одна из целей прикрыть подобое

(18) Тут не для прикрытия :)
Есть юрлицо производитель, есть реализатор. Собственно все.

(19) Если владелец один и завязаны друг на друга то смысл нескольких ЮЛ (а сча уже и ИП) только уход от налогов

(17) Ну тут со справочником еще доп проверка на существование такого кода в базе. Что он оформлен и введен как надо.

Проще для маркировки применять что-нибудь типовое 8, а в 7.7 переносить данные без маркировки.

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

(15) "и в Реализацию отдельными строками с кол-во = 1. "

мне так не понравилось, большая ТЧ и переписывать много отчетов... плюс печатные формы надо сворачивать по товару.

в SQL пока сделал таблицу(марка, статус, документ, номенклатура)

(24) Две и более одинаковой номенклатуры в документе с разными ценами (внезапно цена в маркировку тоже уходит) как?

(25) МРЦ у нас нет, цена к марке не привязана. Цена на всю номенклатуру одинакова(даже если разные партии)

(14) Что решили делать? Построчный ввод товаров с марками в реализации или ДОП табличку(для хранения марок по документу)?

(27) отдельную доп табличку.

(28) если табличку к документу привязываешь то туда кроме номенклатуры засунь еще цену/сумму и кол-во к sgtin

(29)+ чтобы если кто уже после ввода марок изменит строки в документе можно было попытаться концы найти ))

(30)+ по умному это составной ключ

(11) Добавьте в свой список еще и _

(29) зачем в табличку добавлять количество по sgtin количество всегда 1

(28) Где храние отдельную ДопТаблицу? Какие в ней реквизиты?
(29) В реализации одна строка с товаром с количеством 23 шт, для чего надо хранить цену, количество и сумму

(34) Вариантов хранения доптаблицы несколько - отдельный "служебный" документ с привязкой, ТЗ в строку, просто строки с метками. Можно еще придумать что нибудь.

(33) общее кол-во скоко всего марок по позиции в каждую марку

(35) что значит строки с метками?

(35) У себя сделал в SQL табличку.

CREATE TABLE dbo.s_marki (
            ROW_ID        int NOT NULL IDENTITY(1, 1),
            ID_marki      nchar(35),
            ID_reference  nchar(13) NOT NULL,
            ID_document   nchar(13),
            status_km     numeric(1),
            DATE_mercury  smalldatetime,
            /* Keys */
            PRIMARY KEY (ROW_ID),
            UNIQUE (ID_marki)
            )

(35) Строка неогр длины, в ней многострочный текст. 1 строка - 1 марка.
Ну как вариант.

(38) Че по индексам?

(40) пока так
if not exists (select * from sysobjects    where name = 's_marki' and type = 'U')
    exec ('CREATE TABLE dbo.s_marki (
            ROW_ID        int NOT NULL IDENTITY(1, 1),
            ID_marki      nchar(35),
            ID_reference  nchar(13) NOT NULL,
            ID_document   nchar(13),
            status_km     numeric(1),
            DATE_mercury  smalldatetime,
            /* Keys */
            PRIMARY KEY (ROW_ID),
            UNIQUE (ID_marki)
            )
            
            CREATE INDEX IND_doc_s_marki
            ON dbo.s_marki
            (ID_document)
            
            CREATE INDEX IND_ref_s_marki
            ON dbo.s_marki
            (ID_reference)
        ')

Какая странная структура

Марка, Ссылка на Товар(внутреннего представления в виде: [Kind(4)][ID(6)][Sign(3)] ), ссылка на Документ, СтатусМарки(принята, погашена....), ДатаМеркурий(для себя)

(43) Че бы какой нибудь из них не сделать кластерным?

(44) посоветуйте, буду рад

(44)
http://prntscr.com/w9me5d