SAPфорум.RU https://sapboard.ru/forum/ |
|
Копирование ручных условий в поставку. Кто-нибудь делал? https://sapboard.ru/forum/viewtopic.php?f=2&t=11909 |
Страница 1 из 2 |
Автор: | LKU [ Пн, янв 16 2006, 15:52 ] |
Заголовок сообщения: | Копирование ручных условий в поставку. Кто-нибудь делал? |
Привет! Создаю заказ, вручную ввожу скидку 10%. Создаю поставку, провожу разделение позиции. И в этот момент мне очень хочется, чтобы в позиции поставки в схему калькуляции подтянулась эта скидка. Кто-нибудь такую програмку писал? Поделитесь опытом, плиз... |
Автор: | moonrajah [ Вт, янв 17 2006, 08:14 ] |
Заголовок сообщения: | |
Привет, эта проблема когда-то обсуждалась на sapfans.com, так что если есть желание, то можешь прошерстить их форум. Но вообще, для начала неплохо бы определиться, зачем в документе поставке необходима торговая схема калькуляции. Обычно в поставке, если это надо, ведут собственный расчет неких расходов, связанных с отгрузкой/транспортировкой продукции, которую потом хотят выставить клиенту. Торговый расчет (цена, скидки/надбавки и налоги) все равно перекочуют из заказа в фактуру. Так что, может, в консерватории что-то подправить? |
Автор: | LKU [ Вт, янв 17 2006, 09:26 ] |
Заголовок сообщения: | |
Сабир, спасибо за совет - буду искать. А дело вот в чем. У меня происходит разделение позиций в поставке, причем в фактуре используются групповые условия, чтобы сумма фактуры была равна сумме заказа. В результате, если печатать накладную до создания фактуры, программа печати берет за основу заказ и производит расчет стоимости позиций по правилам, отличающимся от тех, что зашиты в схеме калькуляции фактуры. Ну а если фактура уже есть, то при печати накладной все нормально - цены берутся из фактуры. Так что я вижу два варианта: А) Просто поставить предпосылку, запрещающую печать накладной, пока нет фактуры. Минус - пользователям придется сначала создать поставку, потом фактуру, потом снова вернуться к поставке, чтобы ее напечатать. Б) Сделать в поставке рассчет цен идентичный тому, что есть в фактуре и печатать цены из поставки. А для этого надо: - включить схему калькуляции в поставке - научиться копировать ручные условия цен из заказа в поставку (отсюда мой вопрос) - изменить программу печати Торг-12. |
Автор: | moonrajah [ Вт, янв 17 2006, 09:40 ] |
Заголовок сообщения: | |
Знакомая проблема, но мы решили ее несколько иначе. Во-первых, мы полностью отказались от групповых условий - в т.ч. и для НДС (НДС теперь считается для каждой позиции в отдельности, а не для всего документа в целом). Во-вторых, накладная печатается по поставке, однако программа печати берет не суммы по умолчанию (NETWR, KZWI), а только цену за единицу продукции и ставку налога из позиции заказа, все остальное программа печати высчитывает на месте. Поэтому расхождений по суммам нетто и налогов между накладными и фактурами у нес не бывает. Не совсем понятно требование равнозначности суммы заказа и связанных фактур. Если вы заказ разбиваете на несколько поставок, в фактуре будет несколько позиций, и тогда по математике неизбежны т.н. ошибки округления. Мы долго анализировали эту проблему, пытались от нее уходить по-разному, но все-таки пришли к пониманию, что особенности округления будут всегда! Уйти от них можно только, если объем позиции в заказе будет равен позиции поставки. А это не всегда возможно. Поэтому, вместо того, чтобы изобретать велосипед и затем ставить заплатки на заплатки, мы решили проблему описанным выше способом. Организационно пришлось помучаться (читай, сталкивать лбами коммерсантов, финансистов и бухгалтеров), зато сейчас все предельно ясно, четко и, самое главное, в этой области мы не делали своих z-наработок. Чего и вам желаю! |
Автор: | LKU [ Вт, янв 17 2006, 09:57 ] |
Заголовок сообщения: | |
Да я понимаю, если по одному заказу есть несколько поставок или физически невозможно отгрузить ровно столько, сколько заказали (отгрузка идет на вес), то борьба с копейками бесмысленна. Но у нас все меряется в штуках, и зачастую по одному заказу одна поставка, просто в этой поставке товар отгружается из разных партий с разными ГТД => разделение партий в поставке и в фактуре их тоже соединять в одну нельзя. Да еще как правило применяется 100% предоплата. И вот в такой ситуации очень заманчиво избавляться автоматически от разниц в 1-2 копейкимежду счетом и фактурой, чтобы они потом не висели на счетах наших дебиторов. Но, конечно, городить огромный z-огород тоже не хочется... |
Автор: | Evgenii [ Вт, янв 17 2006, 10:04 ] |
Заголовок сообщения: | |
LKU написал: Сабир, спасибо за совет - буду искать.
А дело вот в чем. У меня происходит разделение позиций в поставке, причем в фактуре используются групповые условия, чтобы сумма фактуры была равна сумме заказа. В результате, если печатать накладную до создания фактуры, программа печати берет за основу заказ и производит расчет стоимости позиций по правилам, отличающимся от тех, что зашиты в схеме калькуляции фактуры. Ну а если фактура уже есть, то при печати накладной все нормально - цены берутся из фактуры. Так что я вижу два варианта: А) Просто поставить предпосылку, запрещающую печать накладной, пока нет фактуры. Минус - пользователям придется сначала создать поставку, потом фактуру, потом снова вернуться к поставке, чтобы ее напечатать. Б) Сделать в поставке рассчет цен идентичный тому, что есть в фактуре и печатать цены из поставки. А для этого надо: - включить схему калькуляции в поставке - научиться копировать ручные условия цен из заказа в поставку (отсюда мой вопрос) - изменить программу печати Торг-12. Для решения Ваших проблем есть выход, которым воспользовались мы: Программа печати накладной и ТТН моделирует счет фактуру ( грубо говоря просто создает ее в системе, после чего делается откат => счета в системе небудет),берет из нее все значения сумм, и по ним печатает накладную и ТТН, по моему одно из самых правильных решений, по крайней мере суммы в накладной и фактуре всегда сходятся!!! Попробуйте!!! |
Автор: | moonrajah [ Вт, янв 17 2006, 10:09 ] |
Заголовок сообщения: | |
И все-таки я не вижу принципиальной проблемы. Во-первых, единицы измерения тут ни при чем. Тонны, штуки или гигакалория - все это абстракция измерения количества. Главное, математика. Во-вторых, у нас тоже авансы. Да, пришлось некоторое время объяснять коммерсантам, что та, сумма, которая у них выходит по заказу на большой объем, и сумма по фактурам - разнятся. А окончательный расчет с покупателем ведется не по документу заказа, о котором покупатель может и не иметь понятия, а по фактурам, которые мы ему выставляем. В-третьих, что касается партий, не совсем понял проблему. Если в поставке несколько позиций с разными партиями, то накладную можно печатать (с учетом ранее указанных изменений в программе печати по алгоритму расчета сумм) с перечислением всех позиций. Расхождений между накладной и фактурой быть не должно. А что касается остающихся разниц в 1-2 копейки, то у нас есть возможность, после закрытия контракта, переносить оставшиеся суммы на другой контракт того же дебитора (ессно, по согласованию с ним). Так что повторюсь, ошибки округления - это не обязательно ошибка R/3. Возникают математические расхождения из-за самой сути бизнес-процесса. Поэтому и ответ надо искать не обязательно только в рамках системы. P.S. С каждым постом все длиннее и длиннее. |
Автор: | moonrajah [ Вт, янв 17 2006, 10:18 ] |
Заголовок сообщения: | |
Здравствуйте, Евгений. Evgenii написал(а): Для решения Ваших проблем есть выход, которым воспользовались мы: Программа печати накладной и ТТН моделирует счет фактуру ( грубо говоря просто создает ее в системе, после чего делается откат => счета в системе небудет),берет из нее все значения сумм, и по ним печатает накладную и ТТН, по моему одно из самых правильных решений, по крайней мере суммы в накладной и фактуре всегда сходятся!!! Попробуйте!!!
Не совсем понял, что значит создается СФ и затем откатывается - она виртуально моделируется, или все-таки создается запись в VBRK (и всех связанных таблицах), а затем сторнируется/архивируется? Отдельно хочу сказать, что этот метод теоретически может "выстрелить" при формированиий коммерческой отчетности по поставкам - получается для каждой позиции в отчете надо будет формировать СФ, а затем откатывать. Не тяжеловато будет? |
Автор: | LKU [ Вт, янв 17 2006, 10:28 ] |
Заголовок сообщения: | |
Я понимаю, что разница в копейках - не ошибка "тупого сапа", а математическая неизбежность. Вопрос только в том что с этим делать - подгонять цены и НДС в фактуре, чтобы ее сумма сошлась с заказом или потом решать в бугалтерии проблемы с ненулевым сальдо дебитора (например, перенести на другой контракт.) Но вот если покупатель разовый, то надо потом либо требовать от покупателя дополнительный платеж на 2 копейки (кому это понравится?), либо эти деньги куда-то списывать. Про единицы измерения я написал потому, что они определяют специфику бизнеса. Например, если вы продаете картофель в мешках, то есть плановая цифра (50кг), но покупатель от вас не ждет, что каждый мешок будет весить ровно столько. Значит, клиенты в таком бизнесе привыкли, что либо предоплата не 100%, либо после отгрузки им придется оплатить разницу, либо это разница останется на их счете до следующей отгрузки. А вот если вы отгружаете йогурты в коробках и выставляете требование авансового платежа на 100% стоимости (по заказу), то клиенты вовсе не готовы к тому что им потом скажут, что цена изменилась на 1-2 копейки. Что-то я тоже расписался |
Автор: | LKU [ Вт, янв 17 2006, 10:30 ] |
Заголовок сообщения: | |
Evgenii, мысль интересная! А можно огласить технические подробности? 1. Как именно моделируется фактура - с сохранением или без. 2. Если без сохранения, то как считываются значения цен? |
Автор: | Гость [ Вт, янв 17 2006, 10:32 ] |
Заголовок сообщения: | |
moonrajah написал(а): Здравствуйте, Евгений.
Не совсем понял, что значит создается СФ и затем откатывается - она виртуально моделируется, или все-таки создается запись в VBRK (и всех связанных таблицах), а затем сторнируется/архивируется? Отдельно хочу сказать, что этот метод теоретически может "выстрелить" при формированиий коммерческой отчетности по поставкам - получается для каждой позиции в отчете надо будет формировать СФ, а затем откатывать. Не тяжеловато будет? Счет - Виртуально моделируется, а вот про такую отчетность я ничего не знаю и на том проекте видимо она была не нужна, хотя отчетность по поставкам была написана. И мне так кажется, что любой метод теоретически может "выстрелить", просто это вариант решения проблемы. |
Автор: | moonrajah [ Вт, янв 17 2006, 10:43 ] |
Заголовок сообщения: | |
Вот мы и докопались до сути проблемы. Дело не в округлении - это всего лишь катализатор, а избыток/недостача средств на счетах отдельных дебиторов. Тут мы ступаем на более зыбкую почву, так что утверждать ничего не буду, сообщу лишь общие наблюдения. С постоянными клиентами вопрос расхождения суммы предоплаты не острый. Во-первых, отчетные документы (фактуры) они получают, и по ним видят суммы. Объяснить им, что таковы особенности системы учеты, как правило, проблемы не представляет (конечно, есть особо упертые, но такие есть везде, и подход к ним в каждом случае отдельный). Во-вторых, изменение подхода на подсчет не по общему объему заказа, а по факту, не есть игра в одни ворота - в одном случае с клиента требуется на 2 копейки больше, в другом - на 3 копейки меньше. Люди разумные это понимают, и переносить остатки свободных денег по контракту можно (у нас это делают сами коммерсанты) без особых проблем. В-третьих, проблема одноразовых покупателей не так уж уникальна. А что если клиент, с которым вы работали последний год, обанкротился или вообще исчез вместе со своей бухгалтерии в направлении горячих южных стран? Как тогда будете списывать недостачу? Да, списать можно, но геморрой еще то будет. В-четвертых, эту проблему частично можно решить на уровне системы так, чтобы система в real-time анализировала что и по какой сумме отгружается. Например, в юзер-экзитах кредитного менеджмента (или головной программы) прописать проверку свободных денег в рамках данного контракта/заказа в момент формирования отгрузки с тем, что уже было отгружено в пределах СД (к нас для этих целей используется собственная структура ИСЛ, куда пишутся агреггированные данные о движении денег в рамках одного контракта) и с тем, что уже реализовано (данные FI). Если сумма превышена, то отгрузку можно блокировать с выводом подробного мессаджа. У нас внедрена похожая вещь (правда на уровне сохранения заказа, а не поставки). А вообще, если полностью абстрагироваться, то проблема в корне своей лежит в области ваших отношений с клиентами - идут ли они вам навстречу в таких мелких (а копейки - это мелочь, в отличие от проблем которые они вызывают). Но это уже не тема САПа. |
Автор: | Evgenii [ Вт, янв 17 2006, 11:29 ] |
Заголовок сообщения: | |
LKU написал: Evgenii, мысль интересная! А можно огласить технические подробности?
1. Как именно моделируется фактура - с сохранением или без. 2. Если без сохранения, то как считываются значения цен? Увы, но технические подробности я не знаю, постараюсь выяснить у нашего ABAP консультанта, может быть он подскажет, как моделировать счет-фактуру в SD!!! Выясню, напишу! |
Автор: | LKU [ Вт, янв 17 2006, 12:05 ] |
Заголовок сообщения: | |
Спасибо, будем ждать! (ну и сами, конечно, покопаемся ) |
Автор: | LKU [ Вт, янв 17 2006, 13:13 ] |
Заголовок сообщения: | |
LKU написал: Так что я вижу два варианта:
А) Просто поставить предпосылку, запрещающую печать накладной, пока нет фактуры. Минус - пользователям придется сначала создать поставку, потом фактуру, потом снова вернуться к поставке, чтобы ее напечатать. Б) Сделать в поставке рассчет цен идентичный тому, что есть в фактуре и печатать цены из поставки. А для этого надо: - включить схему калькуляции в поставке - научиться копировать ручные условия цен из заказа в поставку (отсюда мой вопрос) - изменить программу печати Торг-12. На данный момент мозговой штурм привел к тому, что остановились на варианте А) - сначала делать фактуру, потом печатать накладную. А чтобы не приходилось возвращаться в транзакцию vl02n сделали Торг-12 выходным документом к фактуре. |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |