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

Например, Клиент покупает товар 1, товар 2, товар 3 и услугу упаковки товара 2. При этом просит, чтобы упаковка не была выставлена в счете отдельной строкой. В этом случае, менеджер включает стоимость услуги упаковки либо в стоимость товара 2 (именно его упаковывали), либо разносить ее по всем позициям счета (заказа).

Компании необходимо учитывать выручку от всех (включенных и не включенных в стоимости позиций) оказанных клиентам услуг.

Кто-нибудь сталкивался с подобной проблемой и как ее решали?

Рассматривал вариант с отдельными видами условий в схеме калькуляции (например HB00), но он не очень хорошо подходит
1. номенклатура услуг может меняться и не очень хорошо выполнять постоянные настройки и доработки отчетов
2. Для анализа придется собирать информацию по оказанным услугам как с позиций документов, так и «залазить» в калькуляцию. Что само по себе не очень удобно.

Не знаю есть ли какие-то более удобные стандартные решения, но IMHO нужно услуги добавлять как sub-item товара, т.е. чтобы VBAP-UEPOS показывал позицию самого товара. А потом при распечатке документов для клиента эти позиции скрывать, добавляя стоимость к основному товару. Если только несколько таких "special" клиентов, то можно для них вообще отдельный output type сделать.

У нас один нестандартный процесс (одна и та же позиция должна проходить по нескольким profit centers) реализован с помощью pricing conditions. Это такой немеряный геморрой!!! Теперь невозможно настроить инфоструктуры и даже свои отчеты писать на ABAP'e повеситься можно. Плюс всё утыкано юзер-экзитами и левыми программками по самое не могу. Так что мой совет - не делать этого ни в коем случае.

т.е. Вы говорите про подчиненные позиции?
Подскажите, а как они будут отражаться в стандартных отчетах? Ну например, после ОМ и фактурирования, как будет отображаться в транзакции vl06f подобная подпозиция?

Хм, мне все время казалось, что VL06 используется до ОМ и фактурирования... К сожалению, у меня сейчас нет под рукой системы с поставками, но полагаю, что такие позиции будут иметь какой-то особый тип позиции, ну и номера у них будут между "нормальными".

Ну, например, сейчас у нас в контрактах реализована такая байда. Когда клиент покупает какой-то продукт, то иногда к нему нужно сразу покупать как бы подписку на поддержку (maintenance). Так вот, оператор вводит основной продукт, потом шлеп на Enter, выcкакивает окошко с предложением добавить maintenance и количество открыто. Если надо, то пишет - 1 штука и на кнопочку жмет. Окошко явно стандартное, но конфигурировала не я, так что подробностей не знаю, хотя можно покопаться. Естественно, у maintenance есть свой номер материала (MATNR) и т.п.

А в другой конторе была реализована дополнительная скидка за прошлые покупки. Только там не юзеры выбирали количество, а в user exit добавлялась позиция. Само собой, при таком раскладе нумерация позиций должна быть не 1,2,3, а 10,20,30 и т.д.

Рассматриваю вариант решения через подпозиции. Начал разбираться и возник вопрос:
«В настройках типа позиции для этого есть «статистические величины», которая позволяет определить, увеличение стоимости на уровне заголовка, но не основной позиции. Но мне необходимо, чтобы стоимость подпозиции складывалась со стоимостью основной позиции. Как это можно реализовать, только через формулу в схеме калькуляции?»

Основная позиция – TAN
Подпозиция – TANN, не определена как натуральный рабат

Версия SAP 5.0

А почему так принципиально, чтобы стоимость складывалась? Есть стоимость товара, скажем, 10$. Есть стоимость сопутствующей услуги (упаковки или whatever), например 2$. В заказе / фактуре будет две позиции:

10 - товар - 10$
12 - упаковка - 2$

Если заказчики очень хотят видеть в фактуре только "Товар - 12$", то это элементарно решается в Smart Form.

В SD отчетах можно будет видеть отдельно продажи по товарам и по упаковке. Если надо вместе или даже по связкам "товар-упаковка", то элементарно отчет в ABAP'е сделать. Главное, чтобы не надо было лезть ни в какие там дополнительные pricing conditions и т.п.

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

Хотя, не исключено, что если не сумею побороть проблемы (включенная в позицию стоимость, непроводка по подпозициям в финансы), то остановлючь на вашем варианте с суммированием в выходных документах (к сожалению, мы не используем смартформы)

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

В SAPscript можно тоже изобразить что надо IMHO.