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

[balashov]

Цитата:

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

По товарным вариантам не надо ни че править там и так эта аналитика почти во всех учетных таблицах олапах есть. А если нужны два измерения то в качестве второго можете использовать стандартные лоты или серии, или товар класс группу. Правда не все flowfield поля содержат эту аналитику. Предеться переписывать.
Лучше купити LS Retail

[uriy]

Цитата:

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

Цитата:

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

По товарным вариантам не надо ни че править там и так эта аналитика почти во всех учетных таблицах олапах есть. А если нужны два измерения то в качестве второго можете использовать стандартные лоты или серии, или товар класс группу. Правда не все flowfield поля содержат эту аналитику. Предеться переписывать.
Лучше купити LS Retail

мне интересно как это грамотно реализовать.
Если нужны 2 измер. - использовать товар класс? а если 3, 4, .. произвольное кол-во измерений, тогда как?
Вот интересно как это в аддонах реализовано?
Мне видится такое решение - к существующему варианту в станд. функционале привязать сколько нужно измерений. для этого (в нашем случае) добавить поля - код размера, код цвета. наименование варианта будет 42 красный, другой 42 синий, 43 красный и т.п.. Т.е. в варианте уже заключено все кол-во измерений.
При этом если потом нужно будет сортировать табл. Item Ledg Entry по размеру, то нужно в нее занести поле размер и поправить кодеюнит учета - копировать в него размер.

Будет так работать? Или есть какието подводные камни, которые я не вижу?

Цитата:

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

Цитата:

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

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

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

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

[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 символов каждый. Произвести вычисления и сложить остатки по каждому фильтру.

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