Хранение рег.номеров - регистр сведений или регистр накопления #146321

Хочу посоветоваться по поводу эффективности реализации (скорость, объем места для хранения). Мне надо учитывать рег.номера товаров, проданных клиентам. Т.е. чтобы по каждому клиенту можно было посмотреть рег.номера товаров, купленных им у нас. Рассматриваю два варианта: 1) регистр накопления - но он не будет сводиться в ноль (расхода рег.номеров от клиента не будет). Пока больше склоняюсь ко второму варианту (вроде так меньше данных хранить - только одну таблицу, а в варианте 1 - и движение, и остаток). Но, может, у него есть какие-то минусы?

регистр сведений

регистр накопления (обороты)

регистр сведений

неа

можно и по другому, но это поперек идиалогии 1с, да и потом легче статистику делать

регистр сведений, накопления - ф топку

нас больше, значит регистр накопления (обороты)

Я за сведения :))

, какая структура, опишите пожалуйста, поподробнее

А если захочу к нему прицепить еще какую информацию по товару и ее надо бутет складывать То надо будет переделывать!!!!

Клиент,Номенклатура,Номер

+ конечно

Мы же не продажи смотреть будем.. скорее всего надо просто узнать - продали клиенту этот товар или нет

поподробнее это значит описать измерения и ресурсы, периодичность и подчиненность регистратору.

Как вариант - просто справочник :)  Прокатит. Легче в QA лазить, а потом в екслю. :)

Как вариант - просто справочник :)  Прокатит. Легче в QA лазить, а потом в екслю. :)

Измерения клиент, номенклатура... ресур номер... Непериодический, подчинение - больше склоняюсь к клиенту

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

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

что то загнал :)) Независимый

Скорее всего имеется ввиду серийный номер товара

фирма торгует "Железом"?

фирма торует "Железом"?

я так понимаю, что это серийтые номера товара, но если надо будет добавлять комплектацию, или оформлять возврат или ремонт, то регистр накопления

А при отмене проведения (или пометке удаления) документа нужно ли удалять запись из регистра сведений?

+ точнее, вопрос не "нужно ли", а "как ты собираешься это делать".

можно и прибить движения.. А теперь ты мне скажи... когда делать будут свертки базы - нужно ли восстанавливать движуху по регистру?

я отвечу на все вопросы, только позже. Вопрос 2: если ты собираешься прибить движения, то как быть к другим документом (проведенным), по которому тот же клиент получал тот же товар? По дамнным регистра получится, что после распроведения первого документа этот клиент не получал этот товар вообще.

С тем же самым рег номером?

Номер у тебя в ресурсы вынесен, значит в расчет не принимается. А хоть бы и с тем же номером, почему бы нет?

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

Попровка принята, но это не делает твою схему менее дырявой, а просто приводит структуру твоего регистра в соответствии твоему посту . И мы тут не вероятность считаем, кстати говоря. Откуда ты знаешь, какова вероятность? Что, клиент на двух машинах за одной партией товара приехать не может, а каждая отдельной накладной оформляется.

По всей вероятности, следующим шагом ты сделаешь этот регистр периодическим с периодом секунда. Но и это не избавляет тебя от проблем полностью. При вводе документов задним числом вполне возможна ситуация, когда 2 документа, продающее одно и то же одному и тому же клиенту вбиваются в одну секунду (23:59:59).

Вот поэтому регистр сведений не годится. Теперь задавай свои вопросы.

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

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

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

+1

я не упорствую ... приведи мне веские аргументы

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

это желание ускорить работу приведет к реальным потерям надо делать сразу, что-бы потом не переделывать, и Дяпти прав на все 100% скажу из личного опыта (в 7.7) делали подобное в истории значения, потом пока не переделали на регистры былю проблеммы!!!!

А это и не ускорение. При желании узнать ответ на вопрос, что продавалось клиенту ЗА ОПРЕДЕЛЕННЫЙ ПЕРИОД времени придется перебирать все записи регистра сведений. А при регистре накопления при этом используются итоги, где хранятся месячные обороты - будет гораздо быстрее.

+ читать "перебирать все записи регистра сведений за этот период"

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

Нам не нужно знать за какой период продали товар - нужно знать продали или нет... Дыра в моей схеме - отмена проведения документа... Оки.. но во многих фирмах после проведения документ блокируется ... мало того - она к примеру еще утверждается кладовщиком (это к примеру). Перебирается вест регистр сведений - согласен перебирается- но все равно запросом время получения результата будет меньше секунды...  Как у тебя к примеру будет при свертки базы...К тому же наблюдается избыточность, думаю прирос объема базы тоже будет побольше

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

В моей схеме в случае свертки базы естественно информация будет утеряна.

на то она и свертка базы, чтобы выносить информацию об оборотах (любых) и оставлять только информацию об остатках.

Поддержу Дяпти - оптимальнее Оборотный регистр накоплений (если нет необходимости хранения истории). Но согласно методологии 1С Регистр сведений ...

Ого, какой тут жаркий спор :) Пардон, что не отвечал раньше - как раз тогда не был в инете. Да, разные единицы одного и того же товара могут продаваться под разными рег.номерами. Рег.номер однозначно задает конкретную единицу (коробку) товара. Поясню ситуацию. Пишется база для учета продаж коробок 1С. Фирма продает коробки, а также оказывает консультации и записывает обновления. Соответственно, надо знать, что есть у клиента (просто номенклатуру знать почему-то недостаточно, требуется знание рег.номеров). Определять, когда именно была продана конкретная позиция - пока не требуется. Но у каждого клиента будет небольшое число покупок (ну не десятками же они покупают - по крайней мере конченые пользователи). Так что в случае чего несложно будет перебрать все его покупки и по регистратору определить период продажи. Пока остановился на уже предложенном здесь варианте: регистр сведений (измерения: контрагент, номенклатура, рег.номер, ресурсов нет), двигается регистратором, непериодический.

Без сомнений. Абсолютно верно. Поддерживаю.

Может быть, просто сделать таблице из 3 колонок в MS SQL? И туда писать последовательно все действия. Получится что-то, типа ленты чековой на кассе. Думаю это скорость максимальная будет и объем минимальным. Я подобное, даже посложнее, на ORACLE реализовывал потому, как другие приложения у них на Delpfi написаны на базе ERACLE. Отстреливало, как из пушки.

Может быть, просто сделать таблице из 3 колонок в MS SQL? И туда писать последовательно все действия. Получится что-то, типа ленты чековой на кассе. Думаю это скорость максимальная будет и объем минимальным. Я подобное, даже посложнее, на ORACLE реализовывал потому, как другие приложения у них на Delpfi написаны на базе ORACLE. Отстреливало, как из пушки.

Никуя себе, это что коробок стока продается что в регистры запихивать нада ?