Порядок измерений в регистре накопления #453636

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

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

для РН используется кластерный индекс см.

э..., не совсем понял при чем здесь РН ?

посмотрев здесь , такую вещь как ТаблицаостатковИндекс                                 Условие Период + Измерение1 +...+ ИзмерениеN         Для регистров вида "Остатки".                        (Кластерный) Пришел к выводу что порядок следования не важен.

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

может ну его этот регистр, не трогать его вовсе...  а добавить свой, в котором хранить чейки ??!! P.S. ( использовать другую конфу для адресного хранения... )

чейки = ячейки

разберись как для кластерного индекса будет отрабатывать запрос с условиями на Измерение1 и Измерение3

Перебором :)

ну вот и ответ на значение порядка следования измерений

а если добавить условие по дате?

еще регистр не хочется лепить, пока по мере изучения вопроса может жутко захочется :-))

Захочется. Если уж и прилепливать ячейки, то к остаткам, но никак не к партионному регистру. Задумайтесь - на фига Вам оперативный количественный учет навешивать на регистры, которые отвечают за оценку себестоимости? А вообще отдельный регистр!

Партии далеко не всегда отвечают только за себестоимость.

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

Еще планируется одно извращение, склад сделать сомтавным типом, страшно конечно, но пока думаю.

А за что еще? Партии (в терминологии 1С) говорят сколько этот товар стоит

Готовься к тому, что, скорее всего, понадобится несколько регистров. Нам, например, тремя удалось отделаться.

абсолютно книжный подход :)

Расширь свой кругозор... И дата изготовления, и номер из ЕГАИС, и ГТД, и мало ли еще что...

Я речь вел про партионный регистр в типовой 1С, а не про назначение справочника Серии. Если отрубить галку Вести партионный учет по сериям, то серии исчезнут из регистра ПартииТоваров... и рухнут данные ЕГАИС, ГТД и т.д.

Речь идет о назначении партий в принципе. Без привязки к какой-либо туповой...

+ А в регистре остатков серии останутся, так что если и брать количественную инфу, то только оттуда. Поэтому и говорю, что партионный регистр исключительно для расчета стоимости товаров - да и неверно было бы использовать его для каких-либо иных целей (если только не малыми силами допиливать типовую под ЕГАИС - я кстати допиливал УПП для алкогольного производства по другому). А я про типовую в . А вообще про назначение партий не спорю :)

Ну согласись, что не я виноват, что типовые так криво спроектированы? :)

партионный учет на 3 регистрах - один для себестоимости, второй для ГТД а третий под что ?

Не партионный учет. А учет на адресном складе. 1 регистр - остатки в складских ячейках, 2 - остатки в мелких ячейках, 3 - документы, на данный момент находящиеся в обработке складом.

понятно

. Соглашусь. Насчет виноват / не виноват - не знаю, а вот кривизна есть и ее к сожалению не мало. С другой стороны что еще ждать от конфигураций, автоматизирующих выдуманное типовое предприятие. Хотя есть и интересные находки - такое ощущение, что 1С ежегодно меняет команды: один год для проектирования системы автоматизации, другой год - для продажи сего продукта. 2009 год был годом проектировщиков - довольно удачный КОРП получился. Но сейчсас нужно проталкивать 8.2, и эра хороших решений кончилась - наступает аналог 2007 года, когда все конфы дружно перепроектировались под 8.1 (глюки конф перемежались с глюками платформы) В таком количестве багов было только в 2004/2005, когда 8.0 выходила (раньше не знаю, с 1С работаю с 2003)

есть типовые решения со стеллажами ячейками ?

Есть

(имхо) Я бы партии не трогал. Не хочу всяким любопытствующим потом что-либо объяснять (или оправдываться) :( Лучше свои регистры "сверху" наложить.

статическая адресация есть в УТ и УПП

+ УПП :) :) :)

1С-Логистика:Управление складом

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

почему не жизнеспособный - для многих складов статической адресации вполне достаточно

Не спорю насчет статистиеской адресации, но считаю что функционал мест хранения недостаточно "раскручен" - нет "специлизированных" документов и отчетности.

если не трудно пару слов о статическом хранении в данных конфах

Я бы добавил  1с-Логистика Управление складом 3.0  эту логистику хоть как-то но можно связать с упп.(пренос документов, номенклатуры, контрагентов) Есть бесплатный варинт логистики - это EME ( но в последнем варианте нужно знать практически все буквы алфавита.

Ошибка 404 Запрашиваемая страница на сайте отсутствует Возможные причины, по которым возникла эта ошибка: Неправильно указан адрес страницы Проверьте правильность набора адреса страницы в адресной строке браузера Эта страница была удалена с сервера либо перемещена по другому адресу Попробуйте найти интересующий Вас документ, используя навигацию по разделам сайта

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

Скобку в конце адреса убери.

типа подчиненный справочник адреса для номенклатора ?

попадаю на некий форум

в УТ МестаХранения подчиненный Спр Склады

+51 еще есть РС МестаХранения - измерения Номенклатура,Склад,Приоритет(Число) Ресурс - МестоХранения ну и вот еще ссылка

google рулит, но вопрос не решает

ибо вопрос должен быть решен в рамках УТП для Украины

возьми типовую УТ на каком-нибудь nowa-сайте и посмотри механизм статической адресации. еще бывают динамическая адресация без остатков и динамическая адресация с остатками

в УТ МестаХранения подчиненный Спр Склады, посмотрел так и есть В УТП тоже самое, не пойму только как это можно использовать, это своего рода Стеллажи получаются(нафига я их заводил в конфигурации :-))),но как по ним получать остатки можно непонятно и все равно еще нужны ячейки

Почитал здесь многое стало понятно и стало понятно, что все прийдется делать самому, что касается именно ячеек.

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

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

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

Для подбора собственно наверное все равно, главное что он есть(товар на остатке), а вот потом для собирания и инвентаризации необходимо знать где и сколько, если ячейки не закреплены за товаром, или мест закрепления несколько и они в разных концах склада(что конечно в корне неправильно, но такое может быть)

постарайся просто принять оптимальность для твоего случая :) каркас нужного тебе решения можно найти здесь