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

[uriy]

Как сделать в NAV возможность учета товара по цвету и размеру? Т.е остатки товара по складам нужно видеть не для одного варианта, а для 2х, при этом код товара один, но 2 варианта. Может уже где-то реализовано?

[Dzemon]

Одежду учитываете?
Может проще какое готовое решение взять?

[Alterant]

В решениях для розницы, например LS Retail.

[RobiBaggio]

или Peoplestone fashion

[Dzemon]

Zitat:

Zitat von RobiBaggio

или Peoplestone fashion

Точнее Pebblestone fashion, кстати, очень хорошее решение, заточенное именно на торговлю.

[Галина]

не пойму-а почему варианты не подходят?

[balashov]

Zitat:

Zitat von vako

Как сделать в NAV возможность учета товара по цвету и размеру? Т.е остатки товара по складам нужно видеть не для одного варианта, а для 2х, при этом код товара один, но 2 варианта. Может уже где-то реализовано?

Использовать товарные Варианты. Если я не ошибаюсь этот функционал можно как AddOn купить.

[balashov]

Zitat:

Zitat von vako

Как сделать в NAV возможность учета товара по цвету и размеру? Т.е остатки товара по складам нужно видеть не для одного варианта, а для 2х, при этом код товара один, но 2 варианта. Может уже где-то реализовано?

Если не нужен специфический функционал вариантов то можно поступить еще следующим образом:
1. Создаете и заполняете справочник вариантов необходимыми вариантами
2. Настраиваете TableRelation поля Code таблицы Item Variant на этот справочник
3. Создаете отчет который заполнит Item Variant необходимыми товарами по вариантам.
4. Существующие остатки через журнал инвентаризации переводите в необходимые варианты.

В базавом NV уже все настроено под них.

[uriy]

Zitat:

Zitat von balashov

Zitat:

Zitat von vako

Как сделать в NAV возможность учета товара по цвету и размеру? Т.е остатки товара по складам нужно видеть не для одного варианта, а для 2х, при этом код товара один, но 2 варианта. Может уже где-то реализовано?

Если не нужен специфический функционал вариантов то можно поступить еще следующим образом:
1. Создаете и заполняете справочник вариантов необходимыми вариантами
2. Настраиваете TableRelation поля Code таблицы Item Variant на этот справочник
3. Создаете отчет который заполнит Item Variant необходимыми товарами по вариантам.
4. Существующие остатки через журнал инвентаризации переводите в необходимые варианты.

В базавом NV уже все настроено под них.

Но нужно не один а два варианта - размер и цвет.
Вот интересно в Addon'ах для одежды, обуви как это реализовано?

[RobiBaggio]

Zitat:

Zitat von vako

Zitat:

Zitat von balashov

Zitat:

Zitat von vako

Как сделать в NAV возможность учета товара по цвету и размеру? Т.е остатки товара по складам нужно видеть не для одного варианта, а для 2х, при этом код товара один, но 2 варианта. Может уже где-то реализовано?

Если не нужен специфический функционал вариантов то можно поступить еще следующим образом:
1. Создаете и заполняете справочник вариантов необходимыми вариантами
2. Настраиваете TableRelation поля Code таблицы Item Variant на этот справочник
3. Создаете отчет который заполнит Item Variant необходимыми товарами по вариантам.
4. Существующие остатки через журнал инвентаризации переводите в необходимые варианты.

В базавом NV уже все настроено под них.

Но нужно не один а два варианта - размер и цвет.
Вот интересно в Addon'ах для одежды, обуви как это реализовано?

Спасибо Dzemon, что поправил.
В Pebblestone fashion это реализовано как матрица цветов и размеров, и при вызове соответствующей функции формируються товарные варианты. Так же реализован и механизм в LS Retail.

[randrews]

То есть фишка только в том, что на основе двух параметров создается все тот же стандартный вариант ? Тогда, мне кажется, нет смысла покупть addonы. Проще самим реализовать данное поведение системы.

[uriy]

Но нужно не один а два варианта - размер и цвет.
Вот интересно в Addon'ах для одежды, обуви как это реализовано?
[/quote]
Спасибо Dzemon, что поправил.
В Pebblestone fashion это реализовано как матрица цветов и размеров, и при вызове соответствующей функции формируються товарные варианты. Так же реализован и механизм в LS Retail.
[/quote]

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

[balashov]

Zitat:

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

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

[Alterant]

Zitat:

Zitat von vako

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

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

[uriy]

Zitat:

Zitat von balashov

Zitat:

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

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

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

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

Zitat:

Zitat von Alterant

Zitat:

Zitat von vako

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

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

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

[Alterant]

Zitat:

Zitat von vako

Zitat:

Zitat von Alterant

Zitat:

Zitat von vako

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

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

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

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

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

[uriy]

Zitat:

Zitat von Alterant

Zitat:

Zitat von vako

Zitat:

Zitat von Alterant

Zitat:

Zitat von vako

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

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

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

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

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

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

[rmv]

Zitat:

Zitat von vako

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

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

[Alterant]

Zitat:

Zitat von vako

Zitat:

Zitat von Alterant

Zitat:

Zitat von vako

Zitat:

Zitat von Alterant

Zitat:

Zitat von vako

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

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

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

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

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

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

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

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

[uriy]

Zitat:

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

Zitat:

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

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