1с 7.7 торговля/склад.

Вопрос про алкоголь, который поштучный и приходит в разрезе 1 и 3 регистров.

приходит нечто вроде: Водка Колосок 0,5л
справка: FB-000000000000304

к этой справке привязаны несколько акцизов:
<ce:amc>09001785400000118984310PX8051522100000476712617218613594213116182124151</
ce:amc>
<ce:amc>09001785400000118984310PX8051522100000476712617218613594213116182124152</
ce:amc>
<ce:amc>09001785400000118984310PX8051522100000476712617218613594213116182124153</
ce:amc>
<ce:amc>09001785400000118984310PX8051522100000476712617218613594213116182124154</
ce:amc>

поскольку каждый акциз уникален, то количество у каждого будет 1.

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

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

по всякому можно...
https://content.screencast.com/users/Che66/folders/Jing/media/7ea2eacd-3b55-45fc-996d-074503a66f90/2018-11-27_0628.png
.
регистр - а зачем? по сути накопления нет никакого, только да\нет.

регистров сведения в 7.7 нет
так что в справочнике.
там приходят справки,и список марок к каждой справке.
справки в подчинение к алкогольной продукции,марки в подчинен е к справкамв наименование hash,так как наименование более 100 быть не может,а по hash-у все найдется быстрее.

(0) в семерке - только справочник.

Сделать документ специальный и его привязывать к поступлениям

(2) мне нравиться
но два вопроса или один)
-неясно как обойти ограничение в 100 символов
-hash что это

наверное проще дополнительный реквизит создать, для хранения марки

(6) Мы твоих объемов не видим. Скуль или дбф нам не ведомо.
Создай тест, в тесте прикрути что тебе нужно, оцени изменение размеров базы и отдельных файло, посмотри как вспухнет база и наскольно хватит твоих доработок при текущих объемах.

Я у себя храню в справочнике "Марки", подчиненном справочнику "СпрF2", который в свою очередь, никому не подчинен. Вся связь с документами движения марок, идет через текстовые поля, поиском с помощью SqlLite(базы обычные, DBF). Да, не совсем красиво... Но, зато, я имею возможность удалять давно проданные марки, не затрагивая документы. Решение конечно спорное, но у меня работает, в нескольких организациях, и пока оправдывает себя. Организации - розничные магазины, обороты от маленьких до средних. Пока, в реальности, еще не приходилось пользоваться предусмотренной функцией удаления давно проданных марок - размеры справочника марок пока далеки до максимума. Поиск марок через SqlLite сделан с единственной целью - что-бы не создавать лишний индекс, устанавливая "галочку" сортировка. Без нее, штатный метод "НайтиПоРеквизиту" не работает, а SqlLite ищет нормально и очень быстро.
По сути, это решение - как-бы отдельная база данных, но в пределах одной базы. Она не связана ссылками с основной частью базы, как если бы она была совершенно отдельно, под чем-то типа какой-то внешней СУБД, или, как автор предлогал "текстовик"...

PS Делать жесткую связь ссылками, как обычно, я чего-то побоялся - думал объемы будут "зашкаливать", но пока, уже скоро год, ни у кого проблем не возникло, можно было и не городить огород. Но, что сделано - то сделано. Работает, нормально, и ладно.

(5)-неясно как обойти ограничение в 100 символов

А что за ограничение? Наименование? Вот по этому я и создал реквизит длиной 150 символов, потому как в наименование больше 100 не запихнешь. В наименовании я храню 68 символов для "старых" марок, если они приходят "поштучно", и 14 первых символов от новой марки. Весь ШтрихКод и для старых и для новых марок я храню в отдельном реквизите "КодНовМарк". Так-же есть реквизит "ШкКоробки", длиной 50 символов. Ну, и перечисление статус - "Принята, Продана, Возвращена, Списана". И еще один реквизит 0/1 - проверена. Туда единичку подставляю, когда сканируют марку при приемке.

С длиной наименования больше 50 символов был/есть хитрый глюк/фича. В чем он - не помню, разжевывали то ли здесь, то ли на инфостарте. Епрст может подскажет. И, кстати, в типовых - почти везде наименование штатно 50 символов

(10)Интересно... А в чем смысл глюка/фичи -?
Вот у меня в справочнике наименование 68 символов, совершенно штатно, без использования "недокументированных" возможностей:
https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-274.jpg
Вот больше 100 символов, да, не дает... Может тут можно что-то "схитрить"-?
PS Мне по большому счету не нужно, у меня реквизит "КодНовМарк" имеет длину 150 символов, но, вдруг пригодится в будущем...

(10) больше 100.
Собственно, можно обойти, ставя длину наименования в 0, и первый реквизит любой длины. Представление будет по первому реквизиту.
только тут как в картинке про булку хлеба и троллейбус...
Ну и, естественно, нужно понимать, что делаешь, как это будет реализовано внутри и к каким последствиям это приведет/может привести.

Ну, я решил, что для конкретной задачи заморачиваться с представлением не стоит. В наименовании храню все 68 символов для "старых" марок, и только 14 символов(это тип, серия, номер) для новых. Сами ШК хранятся в отдельном реквизите, полностью, и 68, и 150 символов. В этом даже есть некое преимущество - открыв список марок, сразу видно, где новая, а где старая. А все остальные символы новой марки, с 15 по 150, нам видеть и не обязательно - это "крипто-хвост", и прочая служебная информация, ничего ценного для нас в ней нет...

(13) а зачем их все хранить в наименовании?
Если в марке есть "криптохвост", КЧ/КС и т.п., и формат известен и контрольные можно отделить от идентифицирующих - может идентифицироваться по идентифицирующим, а по реквизиту проверять полноту и правильность?
Кстати, (0) можно порекомендовать - если формат всегда такой: 23 цифры+2 буквы+47 цифр - просто поднять систему счисления для цифровой части?

(14)а зачем их все хранить в наименовании?
Да тут все просто... Старое наследство. Писалось это тогда, когда о марках длиной 150 символов еще и слухов не было. Была марка 68 символов, и все тут. Поэтому, и решил на тот момент хранить ее в наименовании, она туда прекрасно пролазила. Искал при сканировании методом "НайтиПоНаименованию"... А какая разница, по наименованию все равно индекс строится. Потом, когда в связи с "новыми веяниями" пошли марки по 150 символов, это не прокатило. Поэтому, добавил отдельный реквизит. Но, "НайтиПоРеквизиту", работает только для реквизитов с установленным признаком "Сортировка". А это дополнительный индекс, который не всегда корректно обрабатывается, особенно при добавлении реквизита в такой справочник. Поэтому, устанавливать признак "Сортировка" не стал, а сделал поиск через SqlLite

Естественно, старые марки тоже стал пихать в этот реквизит, кроме наименования, для унификации алгоритмов.

PS А вообще, сейчас понимаю, что по большому счету, все это лишнее - в новых марках первые 14 символов уникальны. По большому счету, вообще незачем хранить все 150 символов ШК. Зачем они в УС-? Просто при сканировании выделять из ШК первые 14 символов, и искать по ним. Тогда и реквизит не нужен, можно в наименовании хранить этот фрагмент кода. Но, уже сделано так, переделывать смысла особо не вижу, работает нормально.

(0) я в справочнике храню... больше негде...

(16) Искать можно и по первым 14 символам. а вот сравнивать отсканированный ШК нужно полному 150-значному коду в БД учетной системы.
Иначе как защититься от контрафактной марки, в которой первые 14 символов совпали, а в криптохвосте записана ерунда?

это как раз и есть аналог хэш.
только хэш это мд5 от строки,который 32 символа,и по нему отбор и уже сравниваем с полем в 150.символов,которое можно не индексировать.
вартант с 14 уникальными символами хорош,но кто даст гарантию,что они уникальны,а формат не поменяют-от этих чудиков всего можно ожидать-в 150 символов можно все,что угодно записать.
опять же,если там 36ричная система,то кто мешает ее сначала в двоичную перевести,а потом в другую,например 64ричную и т.п.,если взять все заглавные символы,допустимые в наименовании?

(18)Иначе как защититься от контрафактной марки, в которой первые 14 символов совпали, а в криптохвосте записана ерунда?

Ну, по большому счету - да. Можно было-бы хранить марки во входящей ТТН, и сравнивать при приемке, но, тоже не вариант - где хранить? Это не снеговик, с несколькими ТЧ... В подчиненном документе? Можно извратиться конечно, а смысл? Справочник с реквизитом КодМарки проще, и надежнее, да и не ресурсо-затратно, как оказалось.

(20) >>Это не снеговик, с несколькими ТЧ.
хосспадя, ну какая в опу разница, как организованы таблицы? смысл от этого не меняется....

(20) Лучшим вариантом будет хранение таблицы марок во внешнем источнике. Поэтому я за SQLite.

(22)если внешний источник выбрать sqlExpress или еще какой то нормальный sql,то потом возникнет вопрос,а зачем вообще 1с.

(23) интерфейс.

(15) поделитесь кодом функции? спасибо

(25)Какой именно функции? Поиска по реквизиту без "галочки" "сортировка" - ???
Если так, то вот:

Функция НайтиМаркуSqlLite(ШК) Экспорт
    Перем Запрос;
    Попытка
        БазаДанных = СоздатьОбъект("SQLiteBase");
    Исключение
        ЗагрузитьВнешнююКомпоненту("1sqlite.dll");
        БазаДанных = СоздатьОбъект("SQLiteBase");
    КонецПопытки;
    БазаДанных.Открыть(":memory:");
    Запрос = БазаДанных.НовыйЗапрос();
    Запрос.ВыполнитьЗапрос("create virtual table Марки using dbeng(Справочник.Марки)");
    Текст =     "SELECT
                |code Код,
                |id [Марка :Справочник.Марки]
                |FROM Марки
                |WHERE ismark <> '*'";
            
    Текст = Текст + "
                |AND КодНовМарк LIKE '%" + СокрЛП(ШК) + "%'";
                
    Попытка
        Тз = Запрос.ВыполнитьЗапрос(Текст);
    Исключение
        Сообщить(ОписаниеОшибки());
    КонецПопытки;
    Если Тз.КоличествоСтрок() > 0 Тогда
        ИскМарка    = Тз.ПолучитьЗначение(1, "Марка");
        Возврат ИскМарка;
    Иначе
        Возврат 0;    
    КонецЕсли;    
КонецФункции

(26) оно, спасибо