Товар - вариант

[Alterant]

Цитата:

Сообщение от vako

Цитата:

Сообщение от Alterant

Цитата:

Сообщение от vako

Т.е. создается несколько таблиц вариантов? И в Item Ledger Entry и в Value Entry заносится несколько полей кодов вариантов, и соответствено правится кодеюнит проведения?
Или в существующий один вариант заносится информация по матрице? Т.е. к варианту привязывается доп. информация - например в варианте содержится и цвет и размер.

Нет, таблица вариантов по прежнему одна, стандартная. А вот заполняется она на основании таблиц атрибутов: цвет, размер, рост, ... (до 6 штук вроде). Т.е. в Вашем случае в ней будет для каждого товара [Кол-во цветов]*[Кол-во размеров] записей.
Также в системе уже существуют стандартные отчеты, позволяющие отображать информацию в разрезах этих самых атрибутов (хотя фильтрация таблиц, конечно же осуществляется по коду варианта).

Это в какой системе?

LS Retail, но, думаю, и в Pebblestone сделано так примерно так же, тут тяжело что-то другое выдумать.

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

[uriy]

Цитата:

Сообщение от Alterant

Цитата:

Сообщение от vako

Цитата:

Сообщение от Alterant

Цитата:

Сообщение от vako

Т.е. создается несколько таблиц вариантов? И в Item Ledger Entry и в Value Entry заносится несколько полей кодов вариантов, и соответствено правится кодеюнит проведения?
Или в существующий один вариант заносится информация по матрице? Т.е. к варианту привязывается доп. информация - например в варианте содержится и цвет и размер.

Нет, таблица вариантов по прежнему одна, стандартная. А вот заполняется она на основании таблиц атрибутов: цвет, размер, рост, ... (до 6 штук вроде). Т.е. в Вашем случае в ней будет для каждого товара [Кол-во цветов]*[Кол-во размеров] записей.
Также в системе уже существуют стандартные отчеты, позволяющие отображать информацию в разрезах этих самых атрибутов (хотя фильтрация таблиц, конечно же осуществляется по коду варианта).

Это в какой системе?

LS Retail, но, думаю, и в Pebblestone сделано так примерно так же, тут тяжело что-то другое выдумать.

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

Интересно, а как тогда получить остаток всей обуви 42 размера не складе? Если не добавлять поле размер в ILE.

[rmv]

Цитата:

Сообщение от vako

Интересно, а как тогда получить остаток всей обуви 42 размера не складе? Если не добавлять поле размер в ILE.

Добавляете необходимые атрибуты и вычисляемое поле Наличие в таблицу Item Variant, фильтруете таблицу по атрибуту Размер со значением 42 - получаете остаток .
Ну и все формы подбора наверно нужно переделать на Item Variant.

[Alterant]

Цитата:

Сообщение от vako

Цитата:

Сообщение от Alterant

Цитата:

Сообщение от vako

Цитата:

Сообщение от Alterant

Цитата:

Сообщение от vako

Т.е. создается несколько таблиц вариантов? И в Item Ledger Entry и в Value Entry заносится несколько полей кодов вариантов, и соответствено правится кодеюнит проведения?
Или в существующий один вариант заносится информация по матрице? Т.е. к варианту привязывается доп. информация - например в варианте содержится и цвет и размер.

Нет, таблица вариантов по прежнему одна, стандартная. А вот заполняется она на основании таблиц атрибутов: цвет, размер, рост, ... (до 6 штук вроде). Т.е. в Вашем случае в ней будет для каждого товара [Кол-во цветов]*[Кол-во размеров] записей.
Также в системе уже существуют стандартные отчеты, позволяющие отображать информацию в разрезах этих самых атрибутов (хотя фильтрация таблиц, конечно же осуществляется по коду варианта).

Это в какой системе?

LS Retail, но, думаю, и в Pebblestone сделано так примерно так же, тут тяжело что-то другое выдумать.

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

Интересно, а как тогда получить остаток всей обуви 42 размера не складе? Если не добавлять поле размер в ILE.

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

Проблема первого варианта в органичении длинны Flowfilter. Можно сделать комбинированный вариант:
из сформированного списка вариантов сформировать несколько Flowfilter, максимальной длинной, например, по 500 символов каждый. Произвести вычисления и сложить остатки по каждому фильтру.

[uriy]

Цитата:

Интересно, а как тогда получить остаток всей обуви 42 размера не складе? Если не добавлять поле размер в ILE.

Цитата:

Например отфильтровать список вариантов по атрибуту размер, а дальше в зависиомсти от их количества:
- сформировать Flowfilter по коду варианта в карточке товара;
- вычислить остаток по каждому варианту и сложить эти остатки (будет работать не слишком быстро, но если частота получения подобного отчета не велика, то этот вариант может подойти).
Проблема первого варианта в органичении длинны Flowfilter. Можно сделать комбинированный вариант:
из сформированного списка вариантов сформировать несколько Flowfilter, максимальной длинной, например, по 500 символов каждый. Произвести вычисления и сложить остатки по каждому фильтру.

Это так в где-то в аддоне сделано?