Прайс-лист цены и скидки

[Sharky]

Доброго времени суток!

Столкнулся я тут с такой проблемой:
Компания продает ПО, причем ПО состоит из 5 модулей, а каждуй модуль состоит еще из 4-10 подмодулей.
Стоимость за одно сетевое рабочее место подмодуля = Х, доплата за каждое дополнительное рабочее место состовляет 0,6 от стоимости одного рабочего места. Причем количество рабочих мест задается для модуля, а подмодули либо включаются либо нет.

Вопрос:
Как можно реализовать такой расчет цены в аттейне?

[Grizzly]

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

1. Завел бы в справочнике товаров все подмодули с их ценами продажи.

2. Завел бы в справочнике товаров для каждого подмодуля лицензии за первого и дополнительного пользователя (кстати, стоимость первого пользователя можно включить в стоимость самого подмодуля).

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

Естественно, в данном случае цена на первого пользователя и дополнительного в системе будут вестись отдельно.

Для удобства расчета цены лицензии дополнительного пользователя из цены лицензии первого (X*0,6), можно будет установить связь между их карточками товаров и написать небольшой скрипт.

3. Для удобства все лицензии на модуль (лицензии на подмодули и пользовательские лицензии) можно объединить в комплект. Далее в заказе продажи пользователь будет выбирать модуль, раскрывать его с помощью "Функции/Раскрыть комплект" и проставлять вручную требуемое количество каждой из лицензий.

[Sharky]

Именно так и делал!
Но у меня не получилось с расчетом цены :-((

Можно ли поподробнее что ты писал на счет лицензий......

А на счет докупки рабочих мест и/или функционала - это правильно, есть такой факт...просто не хотел все сразу спрашивать....

Есть там и еще одна проблемка: требование на склад, в котором записано:

Компакт диск с прогой
книжка такая то
ключ электронный
.....
То есть совсем другое нежели чем в реальной документации..

[Grizzly]

Рассчитать цену для лицензии дополнительного пользователя стандартными средствами Attain нельзя, насколько мне известно.

Для того чтобы это сделать тебе нужно:

1. Установить между карточками лицензий за первого пользователя и за дополнительного связь. Это можно сделать по-разному. На выбор конкретного способа могут влиять множество причин, в том числе и субъективных. Самый простой способ - при помощи некоторой системы кодирования товаров, при которой код карточки лицензии дополнительного пользователя включает в себя код карточки лицензии первого пользователя. Например, если карточка товара для лицензия первого пользователя имеет номер 1000. Тогда для карточки товара дополнительной лицензии можно назначить код 1000/01. Т.е. по такому коду всегда можно сказать что это лицензия для дополнительного пользователя и что код карточки товара для лицензии первого пользователя 1000.

2. Написать скрипт, который по ценам из карточек товаров лицензий первого пользователя будет устанавливать цены для карточек товаров лицензий дополнительных пользователей.

При его запуске можно запросить некоторые параметры, например, коэффициент пересчета.
Далее искать все товары, которые содержат знак "/" в номере и для каждого из них определять номер карточки товара для лицензии первого пользователя (брать часть номера до "/"), брать из нее цену продажи, умножать ее на коэффициент и записывать в карточку.

Прим. Если цены нужно менять не в карточках товара, а в таблице цен товаров, то процедура несколько усложнится.

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

[Sharky]

Прошу прощения за не полностью раскрытую тему, похоже мы друг друга не очень понимаем, попробую написать на примерах:

Первое:
Продажа.
Цена товара
Количественная скидка рассчитывается по формуле:
С(n) = C(1)+(n-1)*C(1)*0.7
Фактически это означает
цена первого часа в сауне = 120 рублей
Цена всех последующих часов - с 30% скидкой = 84
рубля.
Соответственно цена за пять часов = 120+84*4=456 рублев.
Как эту бяку сделать? Можно ли где-нибудь прописать формулу расчета цены, если да, то в каком месте это красивше сделать?

Второе:

Теперь представь.
Есть у нас есть костюм. Состоит он из пиджака и брюк. Брюки в свою очередь состоят из ремня и самих штанов.
Я могу при покупке костюма сказать что хочу 5 костюмов. При этом прога мне посчитает, что надо пять пиджаков и пять брюк. У покупателя есть возможность выбрать хочет ли он брюки с ремнем или без, но заказать 2 штанов с ремнем, а остальные без он не имеет права.
Теперь сам вопрос. Понятно, что я все это делаю в заказе, использую функцию "Раскрыть комплект". Но мне надо на последнем уровне иметь возможность поставить галку"С ремнем или без", т.е. я не хочу менеджеру дать право изменять непосредственно количество ремней на ноль, т.к. он может ошибиться и поправить кол-во самих штанов. Либо введет вместо нуля один или 2.
Могу ли я в Navision запретить на последнем уровне корректировку количества, А вставить возможность отметить те предметы, которые должны входить в комплект.

И последнее.

Если данные брюки были приобретены вместе с ремнём, то скидка на брюки+ремень - есть, иначе - нет.
Во-о-оот....такая задачка


Буду очень признателен за ответ

[komar]

По примеру 1.
Насколько я понимаю, скидка пойдет на все количестко, а не только на "после первого". Аттейном то бишь не получится. Или пусть меня поправят...
Аксаптой можно попробовать смоделировать ситуацтю через т.н. систему "товарных скидок". Первое, что пришло в голову.....

По примеру 2.
Еще подумаю....

[Grizzly]

> Прошу прощения за не полностью раскрытую тему, похоже мы друг друга не
> очень понимаем, попробую написать на примерах:

Sharky, я тебя понимаю. Вот только ты меня не очень :-)

> Первое:
> Продажа.
> Цена товара
> Количественная скидка рассчитывается по формуле:
> С(n) = C(1)+(n-1)*C(1)*0.7

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

"сумма по строке" х "процент скидки".

И никак иначе.

> Фактически это означает
> цена первого часа в сауне = 120 рублей
> Цена всех последующих часов - с 30% скидкой = 84
> рубля.

Цена дается одна на все количество товара в строке. Т.е. если в строке у тебя указано количество 10, то все десять единиц стоят одинаково. Для того, чтобы продать товар по разным ценам нужно ввести две строки.
Но чтобы не вводить цены товара вручную, ведь по умолчанию система будет проставлять одно и тоже значение, я тебе и предлагал завести отдельные карточки товара для лицензии за первого пользователя и последующих.
Кроме того, ты посмотри как выглядят счета твоей организации. Там, я почти уверен, при продаже более одной пользовательских лицензий указываются две строки.

> Соответственно цена за пять часов = 120+84*4=456 рублев.
> Как эту бяку сделать? Можно ли где-нибудь прописать формулу расчета цены, если
> да, то в каком месте это красивше сделать?

Теоритически запрограммировать можно все что угодно, но поверь ты усложнишь жизнь не только себе, но и тем людям, для которых ты это делаешь.

> Второе:
>
> Теперь представь.
> Есть у нас есть костюм. Состоит он из пиджака и брюк. Брюки в свою
> очередь состоят из ремня и самих штанов.
> Я могу при покупке костюма сказать что хочу 5 костюмов. При этом прога
> мне посчитает, что надо пять пиджаков и пять брюк. У покупателя есть
> возможность выбрать хочет ли он брюки с ремнем или без, но заказать 2
> штанов с ремнем, а остальные без он не имеет права.
> Теперь сам вопрос. Понятно, что я все это делаю в заказе, использую
> функцию "Раскрыть комплект". Но мне надо на последнем уровне иметь
> возможность поставить галку"С ремнем или без", т.е. я не хочу менеджеру дать
> право изменять непосредственно количество ремней на ноль, т.к. он может
> ошибиться и поправить кол-во самих штанов. Либо введет вместо нуля один или
> 2.

В Attain стандартными средствами ты этого не сделаешь по следующим причинам:
1. При продаже модуля существуют такие лицензии (например, на сам модуль и на первого пользователя) которые не зависят от общего числа продаваемых рабочих мест. Они всегда продаются в единичном экземпляре. Для этого комплект должен позволять постоянный тип потребления компонентов (число единиц компонента не зависит от числа единиц комлекта), а в Attain есть только переменный тип потребления.
2. Состав комплекта (спецификации) в Attain не может определяться (включать или не включать некоторые компоненты) его свойствами.

Кстати, обе эти возможности есть в Axapta.

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

> Могу ли я в Navision запретить на последнем уровне корректировку количества, А
> вставить возможность отметить те предметы, которые должны входить в комплект.

Запрещать смысла нет. Пользователь всегда сможет ввести еще одну строку в которой сможет "отрегулировать" заказ. Кроме того, мы уже говорили, что покупатель может докупать лицензии. А предусмотреть все варианты сочетания лицензий достаточно трудно. Если к твоим менеджерам придет клиент, а они не смогут выписать ему счет, будет не очень красиво и виноват будешь ты :-)
Запрещать нужно тогда, когда действия пользователя могут привести к нарушению целостности данных или когда выполняемая им операция 100% ошибочна.

[Sharky]

Спсибо большое!!
Буду искать варианты и пытаться решить эти ситуации. При возникновении дополнительных вопросов буду писать и спрашивать!
Еще раз БОЛЬШОЕ СПАСИБО!