пятница, 15 ноября 2019 г.

SAP GUI 7.50 Patch Level 13

SAP GUI 7.50 Patch Level 13

Download from Mega
Download from Mail.ru

пятница, 8 ноября 2019 г.

Запись VBKD-TRATY при использовании BAPI_SALESORDER_CREATEFROMDAT2

BAPI  BAPI_SALESORDER_CREATEFROMDAT2  не содержит входящих параметров чтобы сохранять в создаваемом заказе VBKD-TRATY. В иторнетах встречается предложение вместо этого использовать ФМ SD_SALESDOCUMENT_CREATE (который внутри BAPI и вызывается), передавая TRATY в BUSINESS_EX. Это бред, поскольку BUSINESS_EX это исходящий параметр. Еще есть вариант обновлять VBKD-TRATY прямым update после вызова BAPI и сохранения по полученному номеру заказа. Это в принципе вариант, но все можно сделать прямо через BAPI описанным ниже способом.

VBKD может хранить данные как на уровне позиции, так и на уровне заголовка - в последнем случае в VBKD-POSNR  будут 0. От того куда нужно записать TRATY зависит, что нужно расширять и что передавать в параметрах. В примерах будет про позиции, но для заголовка тоже указано что и как.


вторник, 10 сентября 2019 г.

Связь средств поиска между собой внутри другого средства поиска (F4 on F4)


В средстве поиска (СП) могут быть входящие параметры, которыми можно ограничивать результат, выдаваемый пользователю для выбора.
Возьмем для примера СП для склада H_T001L. Склады LGORT лежат в таблице T001L, склады принадлежат какому либо заводу WERKS. В СП по складу WERKS помечен как импортируемый параметр (IMP):




Также WERKS присутствует в диалоге ограничений:
 

Обратите внимание, когда завод не задан, выводятся склады всех заводов. Но если завод указать, будут выведены только его склады - например укажем завод 0002:

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


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

четверг, 20 июня 2019 г.

Ловля CX_SY_CONVERSION_OVERFLOW

Поймал странное (на мой взгляд) поведение кода при ловле CX_SY_CONVERSION_OVERFLOW.
Допустим есть метод, который принимает строку и возвращает из нее число. Тип возвращаемого числа DECFLOAT34, чтобы влезло как можно больше. Результат метода присваивается переменной имеющей меньшую разрядность. В случае, когда итоговый результат превышает максимально возможный для этого типа переменной, должно выбрасываться CX_SY_CONVERSION_OVERFLOW. Это вроде как все учтено.
При присвоении результата вызова метода напрямую в переменную CX_SY_CONVERSION_OVERFLOW не ловится и лезет дамп.
Но, если переписать присвоение через промежуточную переменную, CX_SY_CONVERSION_OVERFLOW ловится, дампа нет.
В чем прикол?

REPORT ztest_overflow.
DATA gv_value TYPE string VALUE '123456789123456'.
DATA gv_wrbtr TYPE wrbtr_d.

CLASS lcl_test DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS convert
      IMPORTING iv_value        TYPE clike
      RETURNING VALUE(rv_value) TYPE decfloat34
      RAISING   cx_static_check.
ENDCLASS.

CLASS lcl_test IMPLEMENTATION.
  METHOD convert.
    DATA(lv_value) = iv_value.
    DO 2 TIMES.
      TRY .
          rv_value = lv_value.
          EXIT.

        CATCH cx_root INTO DATA(lx_error).
          IF sy-index = 1.
            TRANSLATE lv_value USING ',..,'.
          ELSE.
            RAISE EXCEPTION TYPE cx_sral.
          ENDIF.
      ENDTRY.
    ENDDO.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

  BREAK-POINT.
  TRY .
      DATA(lv_value) = lcl_test=>convert( gv_value ).
      gv_wrbtr = lv_value.
    CATCH cx_root.
      WRITE 'Overflow'. NEW-LINE.
  ENDTRY.


  TRY .
      gv_wrbtr = lcl_test=>convert( gv_value ). "!!!!DUMP
    CATCH cx_root.
      WRITE 'Overflow'. NEW-LINE.
  ENDTRY.