Añadir columna salida en al VA05N.

Después de añadir un par de columnas a a la VA05, mi consultor preferido para SD me ha pedido si se podía hacer para la VA05N, he visto que pasaba por la user donde les daba valor pero luego no mostraba las columnas ni tampoco estaban en los variantes de visualización.
He mirado foros, blogs con "add fields VA05N" y decían que no se podía, pero al final se me ha encendido la luz.
Habría que hacer primero como con la VA05 y luego ir a la SE11, visualizar estructura SERPSLS_GENDOC. Hacemos un clic en Estr.Append y le añadimos un Append con los mismos campos que hemos añadido en VBMTVZ.

Por ahora lo dejo en cuarentena para ver que no tiene otra afectaciones.

Añadir columna salida en al VA05.

Bueno simplemente seguir los pasos de SAPTRICKS de Roberto Espinosa, simplemente hacer notar que en:
2) Inclusión del campo en la estructura VBMTVZ. Al intentar añadir los campos me pide que registre el objeto, lo he resuelto con el botón Estr.Append y me ha permitido poner los campos fácilmente sin registrar.
3) Ajuste del include V05TZZMO donde se llenara el valor del campo. He intentado añadir el código como se hace como con la VA01, VA02 y VA03 en la MV45AFZZ. Pero no me deja insertar código dentro del CASE, sino antes o después. ¿Versiones? ¿Opciones? ¿Lo que hay entre la pantalla y la silla?.

BADI ME51N Informar elemento PEP (Imputación) automaticamente de una solicitud de compras

Implementamos por la SE18-SE19 la BADI ME_PROCESS_REQ_CUST (Transacción ME51N)

BADI: ME_PROCESS_REQ_CUST    -> se18 -->Nre.BADI

***************************
* IF_EX_ME_PROCESS_REQ_CUST~PROCESS_ACCOUNT
***************************
METHOD if_ex_me_process_req_cust~process_account.
*Al realizar una solicitud de pedido la cual el tipo de imputación se “A” (Activo) [EBAN-KNTTP] y en la cual se
*indique un código de activo, si este activo tiene asociado un elemento PEP se rellenerá automáticamente en el campo de la solicitud de pedido.
*En caso que el activo no tenga asociado un elemento PEP, el campo de la solicitud referente al
*elemento PEP quedara vacio. Permitiendo continuar con la solicitud
  DATA: re_data TYPE exkn.
  CHECK im_count <= 1.
* obtenemos los datos de imputacion
  CALL METHOD im_account_ref->get_data
    RECEIVING
      re_data = re_data.
* si viene el nº de activo y no ha informado el elemento PEP, nosotros le informamos
* el del maestro de activos
  IF re_data-ps_psp_pnr IS INITIAL AND
     re_data-anln1      IS NOT INITIAL.
    SELECT SINGLE posnr INTO re_data-ps_psp_pnr
     FROM  anla CLIENT SPECIFIED
           WHERE  mandt  = sy-mandt
           AND    anln1  = re_data-anln1.
    IF sy-subrc IS INITIAL AND
       re_data-ps_psp_pnr IS NOT INITIAL.
      CALL METHOD im_account->set_exkn( re_data ).
    ENDIF.
  ENDIF.
ENDMETHOD.

!No tengo interlocutores en la posición 20 de la factura de ventas SD!

Es la segunda vez que me pasa, pero esta vez vamos a escribirlo aquí. Hago un report Z que tiene que sacar los interlocutores  (VBPA) por posición de las facturas y vemos que sólo me salen para la primera. Investigamos y hemos visto que sólo guarda los interlocutores para la primera posición y a la hora de mostrar en las transacciones estándares estos interlocutores nos lo muestran para todos.
Así que para buscar los interlocutores de la posición 20, por ejemplo hay que ir a la VBPA por factura y que el campo posición no sea 0, las 0 serían para la cabecera. Me suena raro, pero SAP sabrá porque si van a ser iguales para todas las posiciones no las guarda como cabecera.

Factura de un pedido de compras.

Problema: Tengo un pedido de compras (transacciones ME21N, ME22N, ME23N) y me piden el importe de la factura. De hecho en el caso del cliente para el que me lo piden tenemos facturas por compras (MIR4) “normales” y facturas con compras de costes indirectos de adquisición (transportista).

Resolución:  Hablando con mi consultor de guardia para SD me ha explicado que esto se ve yendo a las ME23N, en posición, pestaña Historial de Pedido.

En nuestro caso tenemos 2 facturas, las de costes de adquisición lo tenemos en la EKBZ, por pedido posición podemos ver y comparando podemos saber por qué campos también cribar (vgabe y bewtp), ya que sigue todo el “flujo” de documentos. Tendremos la factura en BELNR y el importe en moneda local en DMBTR.

Análogamente para EKBE tendremos las facturas normales.

En nuestro caso como sólo necesitamos importe lo hemos sumado usando la siguiente subrutina. Quizás tenga que depurarla un poco más, pero todo se andará.

FORM f_imp_factura      USING    p_ebeln TYPE ebeln
                                 p_ebelp TYPE ebelp
                        CHANGING p_imp_factura TYPE DMBTR.

  DATA: w_dmbtr TYPE dmbtr,
        w_shkzg TYPE shkzg.
  CLEAR: p_imp_factura .

* 1.- Activ. Cost.ind.ad.log.fac.
  SELECT dmbtr FROM  ekbz CLIENT SPECIFIED
    INTO w_dmbtr
         WHERE  mandt  = sy-mandt
         AND    ebeln  = p_ebeln
         AND    ebelp  = p_ebelp
         AND    vgabe  = 2
         AND    ( bewtp  = 'M' OR bewtp  = 'P' ).
    IF w_shkzg = 'H'.
      SUBTRACT w_dmbtr FROM p_imp_factura.
    ELSE." 'S'
      ADD w_dmbtr TO p_imp_factura.
    ENDIF.
  ENDSELECT.
*
* 2.- Activ. Recepción facturas
  CLEAR: w_dmbtr.
  SELECT dmbtr shkzg FROM  ekbe CLIENT SPECIFIED
    INTO (w_dmbtr, w_shkzg)
         WHERE  mandt  = sy-mandt
         AND    ebeln  = p_ebeln
         AND    ebelp  = p_ebelp
         AND    vgabe  = 2
         AND    ( bewtp  = 'Q' OR bewtp  = 'N' ).
    IF w_shkzg = 'H'.
      SUBTRACT w_dmbtr FROM p_imp_factura.
    ELSE." 'S'
      ADD w_dmbtr TO p_imp_factura.
    ENDIF.
  ENDSELECT.

ENDFORM.  

Error al añadir nuevo tipo de pedido en BAPI.

Problema: Heredo un programa que para crear pedidos desde un fichero usa BAPI_SALESORDER_CREATEFROMDAT2. Hasta este momento son pedidos con tipo de documento de ventas TA (VBAK-AUART) y funciona bien. Al añadir dos tipos nuevos me da el mensaje de error V1 761, como estoy en un cliente en inglés es algo así como "Unpermitted combination of business object &1 and sales doc. category &2". Y en &2 me va diciendo K o L según el nuevo tipo.

Solución: Leyendo la mejor respuesta en SCN llego a la conclusión que lo mejor es usar SD_SALESORDER_CREATE usando los parametros tal como los tenía llenos en la BAPI. 

Porque el problema está ahí, la BAPI sólo vale para el BUS BUS2032 con el que llama a SD_SALESORDER_CREATE. De hecho no he probado a no poner el BUS con la nueva función porque no parece obligatorio. El BUS depende del VBTYP de la TVAK, es la K y la L que me daba en el error.

Para saber el BUS que hay que poner uso la siguiente subrutina.

FORM f_obtain_bus USING p_auart TYPE auart

                  CHANGING p_bus TYPE nast-objtype.

*

  DATA: w_vbtyp LIKE  vbak-vbtyp.

*

  SELECT SINGLE vbtyp FROM  tvak CLIENT SPECIFIED

    INTO w_vbtyp

         WHERE  mandt  = sy-mandt

         AND    auart  = p_auart.

*

  CALL FUNCTION 'SD_OBJECT_TYPE_DETERMINE'

    EXPORTING

      i_document_type   = w_vbtyp

    IMPORTING

      e_business_object = p_bus.

*

ENDFORM. 

Errores y mensajes en móviles.

Problema: Estoy con transacciones de SAP por móviles (pistolas) tipo LM01, LM05, etc. Tengo unos mensajes de error que no acabo de detectar de dónde me vienen.
Solución: Para saber cuales son hay que poner un break-point en la función CALL_MESSAGE_SCREEN (Call message screen) del grupo de funciones LMOB (Mobile Computing in Warehousing). Evidentemente con esta función podemos sacar mensajes por pantalla.