Дана простая с виду ситуация. За каждым товаром закреплена одна определенная ячейка склада. В одной ячейке не может быть более одного товара, один товар не может лежать более, чем в одной ячейке. В любой СУБД это решается элементарно (типа, раз галочка, два галочка). Но 1С нам не дает полноценно управлять индексами. Поэтому возникает вопрос. Если полноценное решение недоступно, то какое 1С-овское решение можно считать меньшим из зол? Что бы вы выбрали?

"Когда вы говорите, Иван Васильевич, впечатление такое, что вы бредите."©

РС, измерения: товар, ячейка.

ну можно еще 100500 таблиц запилить и продавать эту туфту за 100500 р.

(1) +1

и ветка под закрытие как бы...

(0) "один товар не может лежать более, чем в одной ячейке"

чушь

Если товар и ячейка это справочники
То размещение логично сделать РН измерения товар, ячейка, ресурс количество
И добавить проверку при размещении что если уже есть не нулевое кол-во в ячейке то другой товар нельзя в нее положить

(1) Э... нет. Вот в (2) это действительно бред. А у меня вопрос по делу

(0) Например, регистр сведений с измерениями Товар, Ячейка.

Еще поясни, какое решение ты считаешь "полноценным"? На низком уровне СУБД, когда при попытке оприходовать товар пользователю вылезает простыня на тарабарском?

(4) Это решение позволяет положить в одну ячейку несколько товаров. И наоборот один и тот же товар положить в несколько ячеек

(7) у тебя плохие знания "любой СУБД"
и тем более плохие знания 1С

иначе не писал бы подобный бред: "В любой СУБД это решается элементарно (типа, раз галочка, два галочка). Но 1С нам не дает полноценно управлять индексами."

(8) Это не годится

(7) без кода проверки  не обойтись

(10) В любой СУБД есть уникальные индексы

(13) Ты индексы с ключами не попутал?

(11) А ты пробовал?

(15) А что там пробовать? Вы предложили абсолютно бессмысленную конструкцию

Может быть, ТС имел ввиду систему адресного хранения типа https://42clouds.com/ru-ru/manuals/adresnoe-khranenie-na-sklade-pri-pomoshchi-1s.html

(16) Значит, ты плохо описал задачу. Попробуй еще раз.

Автор имел ввиду возможность введения ограничений "для одной ячейки не более одного товара" и "для одного товара не более одной ячейки" на уровне платформы (индексов и т.д.).
Платформа на таком уровне действительно не предоставляет средств таких ограничений. Либо нужен код с блокировкой записей, либо:

ДВА регистра сведений: в одном измерение ячейка, а ресурс товар, в другом - наоборот. Ну и контроль непротиворечивости данных (чтобы записи были в обоих регистрах).

(19) Ну раз ты такой телепат, то поясни еще, почему (2) не годится.

(20) потому что в (2) гарантируется только пара (Товар, Ячейка). Соответственно один и тот же товар (с разными ячейками) и одна и таже ячейка (с разным товаром) могут повторяться.

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

(22) хорошо/плохо это относительные понятия, но мы же говорим про условия задачи

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

(14) Нет, не попутал. Речь об индексах

(20) Ответь себе на простой вопрос. Чем (2) отличается от простого добавления реквизита "ячейка" в справочник товаров?

(20) Да и еще один вопрос. Скажи что есть в (19) и нету в (0)? Это к вопросу о "телепатии"

(19) Два регистра в данном случае лучшее решение?

(28) не лучшее, это опять все относительно

(29) Добавить в справочник товаров индексированное поле и контролировать его уникальность. Это решение можно сравнить с решением на основе двух регистров?

(26) а как вы собираетесь вести историю перемещений товара из ячейки в ячейку, если это будет реквизит номенклатуры?

(26) а если потом товар будет в 2х ячейках?

(31) А зачем она мне? Долгими зимними вечерами вспоминать: а вот было времечко, когда товар 1 лежал в ячейке 4?

(32) А если не будет?

(34) ага, наклепают такую архитектуры, а потом мучайся.
Хотя понятно что у тебя чисто теоретические задачи.
Нужно 2 уникальных индекса. Но в 1с на 1таблицу 1 уникальный индекс. Значит в твоем теоретическом решении нужно 2 таблицч

(33) у вас есть опыт работы с адресным хранением? На складе есть МОЛ, которые подписывают накладные с номером и датой, где перечень товара перемещается из одних ячеек в другие. Все это дело документируется. Завтра появится вопрос, при ревизии ячеек на складе, а где товар из ячейки 4? А вы будете потом долгими зимними вечерами искать кто последний перемещал туда товар))

(35) Задача практическая. Как раз сейчас автоматическим складом занимаюсь

(38) ну так нужно делать расширяемую архитектуру

(33) как вы думаете, почему склад хранится не в номенклатуре реквизитом, а в отдельных регистрах? Почему остаток и цена товара хранится не в реквизитах номенклатуры?

Я за рн: ячейка - товар - количество

(36) Нет особой необходимости перемещать из ячейки в ячейку. А в тех редких, гипотетических случаях, когда такое потребуется МОЛы подпишут два документа вместо одного, да и все

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

(40) Итого три решения: рс, рн и реквизит

(41) а подпиька например?

(44) когда с верхних полок достают вниз

(43) РС - это справочно, для истории. РН - если нужны остатки в разрезе ячеек, реквизит - это значение постоянные для конкретной номенклатуры

(42) Для консультанта вы рассуждаете чересчур непрактично. Никому эта история не нужна. Если ячейка хранения меняется, то просто меняется реквизит. Разумеется, с проверкой на нулевой остаток.

(37) >Задача практическая. Как раз сейчас автоматическим складом занимаюсь

Мне искренне жаль бесполезно потраченные ресурсы клиента

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

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

(47) а если остаток ненулевой, то ячейку у товара никак не сменить... пИчаль.

(40) А, нет, рн не решение. РН он и так будет.

(52) с ячейками?

(51) Так вынь и всунь, какая печаль?

(53) С ячейками, конечно

(55) те нужно хранить ячейку по умолчанию?

Это уже совсем другой вопрос

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

(50) можно вероятностный подход применить: примерно такой товар лежит примерно там-то... а-ля гейзненберг

(58) Всунул и вынул. Вот и все "бизнес-процессы". Что вы огород городите на пустом месте? Склад автоматический, ячейки жестко закреплены за товаром.

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

(61) РН нужен. Речь вообще не об этом.

(60) вы так и не ответили, что такое храните на складе, чтобы "Всунул и вынул. Вот и все" работало. Ревизии есть на складе? Перемещения? Буферные ячейки возврата/приема?

(0) уникальный индекс заменить на обычный индекс + контроль уникальности в ПередЗаписью объекта

(63) Вы уходите в сторону. Какое все это имеет отношение к вопросу?

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

+ к тому, что делать надо сразу нормально, и не вестись на фразы: "зуб даю, всегда будет один товар в одной ячейке!"

(66) Есть ли жизнь на Марсе?

(68) я так понимаю ветку можно закрывать?

(69) рано. Еще не раскрыта тема двух китайцев Вынь и Всунь.

(69) Я просто обращаю ваше внимание на то, что вы отвечаете не на тот вопрос, который вам поставили. Я напоминаю, что вопрос о том, чем заменить отсутствие уникальных индексов в 1С

(71) Читайте внимательно https://its.1c.ru/db/metod8dev/content/1590/hdoc и выберите, что вам ближе