Имеем регистр ОстаткиТоваров, с измерениями Товар,Склад и ресурсы Остаток и Сумма.
Возникла необходимость вести учет в разрезе партий и по "ячейкам"(в нашем случае, это аналог палеты. Перемещается между складами, теоретически - на одной ячейке - только один вид Товара, но разные партии могут быть вполне. И один товар может размещаться в нескольких ячейках).
Самое простое решение - добавление измерений, в порядке Товар,Склад,Партия,Ячейка , НО возникает вопрос с размером таблиц регистра: имеем за 1,5 года таблицу движений в 203 МБ(2 млн.записей).- добавил измерения(получил 265МБ), перепровёл ТОЛЬКО приходные(партийобразующие) документы и получил 370МБ. (и это ещё нет расхода партий и не задействованы ячейки, коих будет 2-3к.).
((База ДБФ, необходимо, чтоб её хватило не менее чем на 5 лет. Переход на СКУЛЬ в данный момент не рассматривается))

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

тебе обязательно нужен КОЛИЧЕСТВЕННЫЙ учет в ячейках? или достаточно знать в какой ячейке лежит товар-партия? (общее колво товара-партия также известно доступно в проге)

(0) Сча придет Злобчинский и все порушит :)

А если по факту списание партий фифо\среднее или с прямым выбором...

следует учесть, что длительная история движения товара по ячейкам - практически никого не интересует. достаточно знать В ДАННЫЙ МОМЕНТ скольо товара где лежит. поэтому - если упрешься в размер файла 2Гб - просто "свернешь" регистр и все...

(2) опоздун, я уже здесь

1) - да важен
(2) - фифо, возможен выбор

(0) Разделить регистр, как в ТиС ?

(0) Подобного опыта нет, но я за - новый регистр (не трогая существующие): товар, склад, партия, кол-во.

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

Ввиду того, что товарищ описывает регистр как "товар,Склад" - то это скрее всего самописка. Поэтому вариант (7) неактуален

(0)
не нужно тебе этого
http://www.onlinepbx.ru/images/Yoda_TPM_RotS.png

ну и надо понимать, что перепроведение и заведение документов задним числом - является для складского учета противоестественным извращением - поэтому надо смотреть на суровую действительность. если порядка в конторе нет - то складской учет по партиям и ячейкам - однознаочно выносить в отдельный СКЛАДСКОЙ РЕГИСТР, а на текущем регистре - финасновый/управленческий учет

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

(6) Логика разделения в ТиС 9,2 - мне не понятна, в ТиС для Украины - разобрался-подходит, Но начитался отзывов что там регистр Партии "вылазит из штанов" быстро.
(11) "однознаочно выносить в отдельный СКЛАДСКОЙ РЕГИСТР, а на текущем регистре - финасновый/управленческий учет" - если сможешь - мысль развить бы ?

Да! забыл упомянуть важную весч - имеется производство(и доки по нему), т.е. по сути внутреннее двигание ТМЦ.
и вот для производства добавляются "перемещаемые" ячейки, и будут добавлятся новые виды документов.

(13) ну ты товар принимаешь сейчас, 24.08.15, а по базе его проводят 01.07.15 - потому что так надо менеджерам/управленцам.
.
основноая мысль: в складском учете нет такого понятия как исправление документов/проведение задним числом. все делается здесь и сейчас. всегда в текущий момент времени.
.
отсюда у тебя будут постоянно лезть траблы. Тупой пример (упрощенно): сделали "возврат от покупателя". через три дня выясняется что надо не "возврат от покупателя", а "поступление ТМЦ". Возврат от покупателя убивают. Заводят поступление - и все.. "поехал" твой складской учет... так как он опирается не на фактические события/факты, а на некие виртуальные сущности "документы"

(13) херня все.
для складской работы минимум документов нужен? для основных складских операций хватает три документа: заявка на приемку, заявка на отгрузку, перемещение. Отсюда и кури бамбук. также в сторноу ордерной схемы.

(13) в тис все просто.
ОстаткиТМЦ - учет остатков на складе
ПартииНаличие - себестоимости, от кого, кому, виды движений
Покупатели и Поставщики - взаиморасчеты по долгам

может вот это мое пригодится: http://catalog.mista.ru/public/266256/

(14) такие ситуации у нас - норма (к сожалению)... ежемесячное перепроведение всех доков (пока) спасает.
(15) сейчас основная задача не склад, а обеспечение учета перемещения ТМЦ по цеху (этапам технологического процесса). (16) надо ещё покурить ТиС на тему - как там отчеты по двум регистрам строятся...

интересная фишка: был в регистре ресурс Розн_Сумма, в кот. расходными накладными записывалась сумма реализации(использовалось некоторыми отчетами), ((согласен что глупо, но сделано было ещё до меня и я до сегодня не трогал)), так вот удалил я этот ресурс и размер стал 204 МБ... появилась мысль "может таки оставить один регистр!?"

Если таки делить на два регистра - то как?
Товар,Склад,Партия + Товар,Ячейка ???
или Товар,Партия + Товар,Склад,Ячейка ???

или может в одном вести "внешние" а в другом "внутренние" движения и сделать их идентичными (ЯТД здравая мысль)

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

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

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