Sapforum.Biz
Логистика => Управление материальными потоками (MM) => Тема начата: fil от Сентябрь 27, 2010, 11:36:44 am
-
Стоит задача: В случае , если валюта документа отличается от валюты БЕ, нужно расчитать курс на дату, указанную в поле MKPF-BLDAT, а не BUDAT как по умолчанию. Может кто-нибудь сталкивался с подобной проблемой?
-
Стоит задача: В случае , если валюта документа отличается от валюты БЕ, нужно расчитать курс на дату, указанную в поле MKPF-BLDAT, а не BUDAT как по умолчанию. Может кто-нибудь сталкивался с подобной проблемой?
Если не ошибаюсь, на это можно влиять значением поля EKPO-MEPRF в подробных данных договора рис. 1, 2 или EINE-MEPRF в инфо-записи рис. 3.
Это поле как я думаю можно вынести и в заказ. http://[table][tr][td][/table]
-
Если не ошибаюсь, на это можно влиять значением поля EKPO-MEPRF в подробных данных договора рис. 1, 2 или EINE-MEPRF в инфо-записи рис. 3.
Это поле как я думаю можно вынести и в заказ. http://[table][tr][td][/table]
не совсем понятно, это где-то настраивается или нужно при создании ДМ подменять это значение?
-
не совсем понятно, это где-то настраивается или нужно при создании ДМ подменять это значение?
Это поле есть в договоре и инфо-записи, когда Вы создаете заказ со ссылкой на договор - значение этого поля тянется в заказ и далее влияет на выбор курса при ПМ, если вы создаете заказ без ссылки на договор - система находит инфо-запись и (если условия инфо-записи действительны - точно не помню, влияет ли это) - значение этого поля тянется в заказ.
-
Это поле есть в договоре и инфо-записи, когда Вы создаете заказ со ссылкой на договор - значение этого поля тянется в заказ и далее влияет на выбор курса при ПМ, если вы создаете заказ без ссылки на договор - система находит инфо-запись и (если условия инфо-записи действительны - точно не помню, влияет ли это) - значение этого поля тянется в заказ.
извините за тупость, но какой тип нужно поставить, чтоб считалось по дате документа, а не по дате проводке. в списке (рис.2) я не нашла ничего подходящего
-
извините за тупость, но какой тип нужно поставить, чтоб считалось по дате документа, а не по дате проводке. в списке (рис.2) я не нашла ничего подходящего
Да мне тоже кажется что это не то. Вы кстати, в MIGO поступление к заказу делаете? Вечером гляну, но боюсь, что без шаманства тут не обойтись.
-
Да мне тоже кажется что это не то. Вы кстати, в MIGO поступление к заказу делаете? Вечером гляну, но боюсь, что без шаманства тут не обойтись.
да, к заказу
-
извините за тупость, но какой тип нужно поставить, чтоб считалось по дате документа, а не по дате проводке. в списке (рис.2) я не нашла ничего подходящего
Странно, все время думал, что данное поле как раз влияет на цену и курс,
видимо ошибся, ссори
Текущие условия из инфо-записи предлагаются в любом случае. Для поиска
различных условий, например, условий, зависящих от даты поставки, можно
использовать тип даты цены. В случае использования типа даты цены Дата
поступления материала необходимо также выбрать контроль счетов на
основе поступлений материала.
scm521, стр. 45
-
да, к заказу
Ok! Посмотрю, но уже кажется завтра, а то сегодня систему удаленную положили...
-
Ну как и обещался немного абапа и можно сделать выбор курса валюты по дате документа а не по дате проводки. Для этого идем в тему Enhancement Spot (http://sapforum.biz/index.php/topic,546.0.html) и читаем как создавать расширения, а именно там берем файлик Enhancement Spot 2.pdf . Далее будем использовать не явное расширение функции function fi_currency_check, почему она, ну в общем таки она, в ней есть подпрограмма
*---------------------------------------------------------------------*
* FORM READ_EXCHANGE_RATE *
*---------------------------------------------------------------------*
* ........ *
*---------------------------------------------------------------------*
form read_exchange_rate using i_kurs
i_hwae
i_basw
i_umrd
i_kuty
changing e_kurs e_fixk.
data: waers like t001-waers,
datum like sy-datum.
*
e_kurs = i_kurs.
if i_kurs is initial.
if not i_hwae is initial.
if i_basw eq char_1.
waers = i_waers.
else.
waers = t001-waers.
endif.
if i_hwae ne waers.
case i_umrd.
when char_1.
datum = i_bldat.
when char_2.
datum = i_budat.
when char_3.
datum = e_wwert.
endcase.
call function 'READ_EXCHANGE_RATE'
exporting
foreign_currency = waers
local_currency = i_hwae
type_of_rate = i_kuty
date = datum
importing
exchange_rate = e_kurs
fixed_rate = e_fixk.
endif.
endif.
endif.
endform. "read_exchange_rate
В эту подпрограмму передается параметр i_umrd, значение этого параметра определяет какую дату брать, исходя из конструкции:
case i_umrd.
when char_1.
datum = i_bldat.
when char_2.
datum = i_budat.
when char_3.
datum = e_wwert.
endcase.
Короче если 1, то дата документа, если 2, дата проводки, если три, то дата вычисляется на более высоком уровне и передается в переменной e_wwert. Так вот при проводке поступления и вообще движения материала, значение идет 3. Ну значит можно вставить неявное расширение и заменить значение i_umrd на цифру 1, дата будет браться из даты документа. К сожалению поменять эту переменную никак нельзя, она как параметр USING, а поэтому придется частично скопировать весь код расчета себе, что не очень хорошо, но если по другому никак, а клиент хочет, то почему бы и нет. В общем виде код будет где-то такой
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(1 ) FORM READ_EXCHANGE_RATE, Начало S
*$*$-Start: (1 )--------------------------------------------------------------------------------$*$*
ENHANCEMENT 1 Y_KURS_BLDAT. "active version
DATA: ls_mkpf LIKE mkpf,
l_waers like t001-waers,
l_datum like sy-datum.
FIELD-SYMBOLS: <fs_mkpf> TYPE ANY.
ASSIGN ('(SAPMM07M)MKPF') TO <fs_mkpf>.
CHECK sy-subrc = 0.
ls_mkpf = <fs_mkpf>.
IF ( ls_mkpf-vgart = 'WE' AND ls_mkpf-blart = 'WE' AND
ls_mkpf-blaum = 'PR' AND
ls_mkpf-bldat <> ls_mkpf-budat AND
ls_mkpf-tcode2 = 'MIGO_GR').
e_kurs = i_kurs.
if i_kurs is initial.
if not i_hwae is initial.
if i_basw eq char_1.
l_waers = i_waers.
else.
l_waers = t001-waers.
endif.
if i_hwae ne l_waers.
l_datum = i_bldat. "Всегда дата документа
* case i_umrd.
* when char_1.
* l_datum = i_bldat.
* when char_2.
* l_datum = i_budat.
* when char_3.
* l_datum = e_wwert.
* endcase.
call function 'READ_EXCHANGE_RATE'
exporting
foreign_currency = l_waers
local_currency = i_hwae
type_of_rate = i_kuty
date = l_datum
importing
exchange_rate = e_kurs
fixed_rate = e_fixk.
endif.
endif.
endif.
UNASSIGN <fs_mkpf>.
exit.
ENDIF.
UNASSIGN <fs_mkpf>.
ENDENHANCEMENT.
*$*$-End: (1 )--------------------------------------------------------------------------------$*$*
Ну где-то так, по быстрому проверил работает... но я бы подумал на вашем месте, все таки это вмешательство в работу системы и существенное. Тут клиент сильно не прав, настаивая на таком функционировании системы.
-
спасибо, может и подойдет :)
правда я думала может есть возможность менять дату с помощью badi или exit'ов ???
-
правда я думала может есть возможность менять дату с помощью badi или exit'ов ???
Ну теоретически я бы еще на проводку счета посмотрел бы... так как возможно что он курс возьмет по дате проводки и переоценит вам еще запас, в общем это надо хорошо все потестировать. Екзитов точно нет.
-
попробовала в отладке менять дату datum, не подходит, курс действительно верный подтягивается (причем в расширении можно просто поменять e_wwert), а вот суммы расчитаны по старому курсу, возникает ощущение, что все суммы уже были расчитаны раньше
-
попробовала в отладке менять дату datum, не подходит, курс действительно верный подтягивается (причем в расширении можно просто поменять e_wwert), а вот суммы расчитаны по старому курсу, возникает ощущение, что все суммы уже были расчитаны раньше
Ну значит надо где-то раньше посмотреть по коду где суммы считаются... в принципе при проводке до этого места расчета, стек вызова где-то такой:
=============
SUBST_AMOUNTS SAPLFACI LFACIF2Q
CHECK_ACCIT SAPLFACI LFACIF20
FI_DOCUMENT_CHECK SAPLFACI LFACIU01
DOCUMENT_CREATE SAPLRWCL LRWCLF01
AC_DOCUMENT_CREATE SAPLRWCL LRWCLU01
CKMV_AC_DOCUMENT_CREATE SAPLCKMV LCKMVU01
F-BELEG_ERGAENZEN SAPMM07M MM07MFF9_F_BELEG_ERGAENZEN
BUCHEN_AUFBEREITEN SAPMM07M MM07MFB9_BUCHEN_AUFBEREITEN
MB_CREATE_MATERIAL_DOCUMENT SAPLMBWL LMBWLU05
MB_CREATE_GOODS_MOVEMENT SAPLMBWL LMBWLU14
MB_CREATE_GOODS_MOVEMENT SAPLMBWL LMIGOKD1
DOCUMENT_OPERATION SAPLMIGO LMIGOKD1
DOCUMENT_POST SAPLMIGO LMIGOKD1
LIF_MIGO_FRAME~OKCODE_HANDLER SAPLMIGO LMIGOST2
OKCODE_DISPATCH SAPLMIGO LMIGOFR2
PAI_OKCODE_DISPATCH SAPLMIGO LMIGOPAI
==============
Так что где-то с функции BUCHEN_AUFBEREITEN SAPMM07M MM07MFB9_BUCHEN_AUFBEREITEN в отладке посмотреть, думаю можно быстро найти.
-
не так то это просто
Как я поняла, для проводки документа материала дата курса = дата проводки зашито в код
В отладке мне пришлось менять дату в нескольких местах, чтоб получить нужный результат
1. при вызове FUNCTION CONVERT_TO_LOCAL_CURRENCY, где data = budat
FORM WE_AUS_POT
FORM XEBEFU_AUFBAUEN
FUNCTION ME_READ_ITEM_GOODS_RECEIPT
FORM BESTELLUNG_PRUEFEN
FUNCTION MB_CREATE_GOODS_ISSUE_ITEM
FUNCTION MB_CREATE_GOODS_MOVEMENT
METHOD DOCUMENT_OPERATION
METHOD DOCUMENT_POST
Причем budat, по которой ведется расчет, равна mkpf-budat, подается на вход FUNCTION 'ME_READ_ITEM_GOODS_RECEIPT'.
2. при вызове FUNCTION CONVERT_TO_LOCAL_CURRENCY, где дата = mkpf-budat
FORM WA04_CURRENCY
FORM WE01_RECHNEN
FORM WE01
FORM WERTE_RECHNEN
FUNCTION MB_CALCULATE_VALUES
FORM F-SEGMENTE_GENERIEREN
FORM BUCHEN_AUFBEREITEN
FUNCTION MB_CREATE_MATERIAL_DOCUMENT
FUNCTION MB_CREATE_GOODS_MOVEMENT
METHOD DOCUMENT_OPERATION
METHOD DOCUMENT_POST
Здесь дата расчета зависит от ycurtp-curdt, где формируется данная табличка, я пока не выяснила
3. в function FI_CURRENCY_CHECK в FORM READ_EXCHANGE_RATE изменяем e_wwert, чтоб в заголовок подтянулся верный курс
причем это частный случай на простейшем примере и, даже если учесть все условия и сделать enhancement в CONVERT_TO_LOCAL_CURRENCY, то кто даст гарантии, что все будет верно работать
вообще советуют использовать ноту 619330, но там тоже правка стандарта
может я где-то ошиблась?
-
может я где-то ошиблась?
Вряд ли ошиблись. Просто это действительно сложная модификация и тестировать нужно будет все процессы, не забывая кстати и про чистый FI, так как действительно оно в коде все сильно зашито на дату проводки. Короче я бы посоветовал вашему клиенту отказаться от такой реализации процесса и вот именно в этом случае пересмотреть свои бизнес процессы.
-
Для истории, так сказать.
619330 - Document date instead of posting date for goods receipt
-
Для истории, так сказать.
619330 - Document date instead of posting date for goods receipt
Для истории наверное правильнее было бы сделать так 8)