powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / О периодических реквизитах. Вопрос.
11 сообщений из 11, страница 1 из 1
О периодических реквизитах. Вопрос.
    #35273715
Бизон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О периодических реквизитах.
Проводим переход с 1С на другую программную платформу. При обсуждении ТЗ с программистами возник следующий вопрос об механизме использования периодических реквизитов. Для иллюстрации вопроса приведу следующий пример. Справочник товаров, товар имеет какую то цену. В процессе работы цена изменяется в зависимости от даты. В 1С реализуется просто, ставится галочка, что реквизит периодический и в дальнейшем можно получить историю изменений и как это было выполнено документом или вручную. В предлагаемом продукте реализовано несколько по другому, все изменения производятся только на основании документа(ввод цен), в дальнейшем можно получить отчет, когда и кто изменял цены, прямого доступа к справочнику товаров нет. Вопрос заключается в следующем, равнозначно это по функционалу или необходимо затребовать реализации как в 1С. Заранее спасибо.
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276513
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бизон В 1С реализуется просто, ставится галочка, что реквизит периодический и в дальнейшем можно получить историю изменений и как это было выполнено документом или вручную.
Для начала нужно понять как это реализовано на уровне СУБД в 1С. Галочка галочкой, но всю историю в таблицу справочника даже 1С не кидает.
В 7.7 есть таблица констант, в которой хранятся (помимо констант) история абсолютно всех периодических реквизитов справочников и констант. Налицо ненормальзованность и большие тормоза.
В 8.х пошли навстречу народу. Там нет понятия периодического реквизита, зато есть регистры сведений. Примерно это выглядит следующим образом:
таблица-паттерн "периодический регистр сведений"
Поля:
1.1. ДатаНачалаИспользования
1.2. Документ-регистратор (внешний ключ), сделавший запись
2. Поле (поля) разрезов/измерений (может не быть)
3. Поле-значение
Значение действует от Даты или Документа до следующей даты (документа) в разрезе полей измерений, если они есть
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276529
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naf
В 8.х пошли навстречу народу.
народ ликовал.
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276552
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NafВ 8.х пошли навстречу народу. Там нет понятия периодического реквизита, зато есть регистры сведений
И за счет чего именно победили "ненормальзованность и большие тормоза"?
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276563
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ВаскецовИ за счет чего именно победили "ненормальзованность и большие тормоза"?
За счет того что каждую историю (периодический реквизит) храним в отдельной таблице
iscrafmнарод ликовал.
Это другой вопрос
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276649
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naf Сергей ВаскецовИ за счет чего именно победили "ненормальзованность и большие тормоза"?
За счет того что каждую историю (периодический реквизит) храним в отдельной таблице
Это не ответ на мой вопрос. Хотя бы насчет "ненормальзованности" можете внятно ответить, что было, что стало?
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276716
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ВаскецовЭто не ответ на мой вопрос. Хотя бы насчет "ненормальзованности" можете внятно ответить, что было, что стало?
Раньше было: все в одной таблице. Примерно так (привожу некоторые поля):
1. ДатаИзменения
2. ДокументРегистратор
3. СсылкаНаЭлементСправочника (причем для всех)
4. Код реквизита (в одном справочнике могут быть несколько периодических реквизитов)
5. Значение(тип строка: не важно какого типа реальное значение, все вносится сюда)
Стало: можно создавать сколько угодно регистров сведений (таблиц), в которые можно включать один или несколько периодических значений
1. ДатаИзменения
2. ДокументРегистратор
3. Измерения (теперь можно делать несколько измерений, например, цены в разрезе товаров и магазинов)
4. Значения - собственно значения, типаж у каждого свой
Отсюда бОльшая нормализуемость и меньшие тормоза
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276733
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NafОтсюда бОльшая нормализуемость
Доказательство у Вас, разумеется, есть?

Nafи меньшие тормоза
За счет чего? Только за счет удаления приведения типов? Или за счет деления таблицы на более мелкие "срезы", так как цифробуква и приличные индексы - вещи несовместимые?
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35276747
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ВаскецовДоказательство у Вас, разумеется, есть?
Читаем про нормальные формы применительно к реляционным БД
Сергей ВаскецовЗа счет чего? Только за счет удаления приведения типов? Или за счет деления таблицы на более мелкие "срезы", так как цифробуква и приличные индексы - вещи несовместимые?
За счет этого тоже, а также за счет того( в первую очередь), что для записи одного реквизита не блокируется вся таблица всех реквизитов
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35282875
Бизон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Допустим цена продажи может изменятся тремя документами, и для того чтобы просмотреть историю изменения необходимо делать довольно большую выборку. И еще вариант, у нас очень часто меняется сумма кредита для контрагента, тогда тут тоже необходимо делать отдельный документ, чтобы в дальнейшем проследить динамику.

Модератор: отредактировано
...
Рейтинг: 0 / 0
О периодических реквизитах. Вопрос.
    #35285235
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БизонДопустим цена продажи может изменятся тремя документами
Вообще в системе или для каждого контрагента это реально? Обычно используется банальная политика уточнения (актуализация) цены по мере прохождения цепочки. Подробности ниже.

Бизончтобы просмотреть историю изменения необходимо делать довольно большую выборку
Сама по себе история изменения цены - это никому не нужная абстракция. Подробности ниже.

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

Теперь обещанные подробности.

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

Представим себе ситуацию, что возникла необходимость закупить некий товар. Что нам даст знание некой абстрактной величины "цена"? Практически ничего, так как первое, что необходимо знать - у кого его закупать (оценка экономического обоснования бизнеса сейчас не интересна), так как логично предположить, что цены могут отличаться у разных поставщиков. Равно как у разных поставщиков разные ограничения на поставку (это второе). Например, при потребности в 100 штук в месяц имея 2-х поставщиков, каждый из которых может поставить штук по 30 по 3 рубля и по 5 рублей, совершенно невозможно спрогнозировать "цену". Предположив изменение контрактных обязательств поставщиками (не всегда в сторону ухудшения, пример "нам надо еще 50 штук, сможете осилить?"), логично в эту систему вписываются и тендеры, и их контроль.

Необходимо различать цену от разных поставщиков, а также иметь некую абстрактную цену (не обязательно хранимую, она может быть и avg от цен поставщиков, или даже max, это зависит от "оптимистичности" планирования, как раз лучше, чтобы она не редактировалась напрямую, в эту цену фактически будут заложены и затраты по поиску новых поставщиков и риски работы с ними, например, это может быть 1.2max), в противном случае даже оценить потребность с точки зрения суммы вообще невозможно. Желание иметь историю изменения цены - слабость и ограниченность мышления в части планирования затрат на закупку (бюджета). А подчас и непонимание, что цену, чтобы вбить вручную, тоже надо откуда-то взять, а какая-либо ответственность такого "вбивателя" обычно просто отсутствует.

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

Если же говорить о продажах, то считаю совершенно недопустимым, если продажная цена вводится "вручную" или несколькими документами. Необходимо иметь функциональность прайс-листов, которые имеют при необходимости срок действия, которые утверждаются ответственными лицами, и только на основании их (прайс-листов) оформлять документы на продажу. сразу же замечу, что вопросы всяких скидок находятся в стороне от ценообразования по прайс-листам. Фактически, несмотря на наличие цен в "продажных" документах, единственным источником формирования их должны быть подобным образом организованные прайс-листы, формирование это должно быть в момент создания документа, а по "продажной" цепочке вниз они должны копироваться. Всякие форсмажоры и прочие редкости традиционно могут не вписываться в эту красоту, но по крайней мере здесь нет ограничений на реализацию их вручную.
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / О периодических реквизитах. Вопрос.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]