jueves, 25 de septiembre de 2014

Guía de Configuración en SAP FI-AA: Parámetros Clave y Transacciones de Parametrización

En el módulo de Contabilidad de Activos Fijos (FI-AA), la correcta definición de los parámetros globales es el cimiento para asegurar una depreciación exacta, reportes financieros fiables y un cumplimiento estricto de las normas contables locales e internacionales (como las NIIF/IFRS).

La mayoría de los parámetros estructurales y de control de este módulo pueden ser creados y modificados haciendo uso de las siguientes transacciones clave del Customizing:



 

1. Transacción ORFA: El Menú de Configuración General de Activos Fijos

La transacción ORFA es, en realidad, el acceso directo al árbol de la guía de implementación (IMG) exclusivo para Activos Fijos. En lugar de navegar por toda la transacción SPRO, ORFA te sitúa directamente en el corazón de FI-AA.

Desde este menú estructurado, un consultor o administrador del sistema puede parametrizar:

  • Estructuras Organizativas: Definición y asignación de los planes de valoración (Chart of Depreciation), que agrupan las reglas de depreciación de una o varias sociedades.

  • Clases de Activos Fijos (Transacción OAOA): El enlace principal entre el maestro de activos fijos y la contabilidad de mayor (FI-GL). Aquí se define el rango de números y la asignación de cuentas.

  • Áreas de Valoración (Transacción OADB): Configuración de las diferentes "capas" de cálculo de amortización (por ejemplo, Área 01 para Libros Locales, Área 30 para IFRS/NIIF, Áreas Fiscales, etc.).

2. Transacciones Clave Complementarias para la Operación de FI-AA

Para complementar el uso de la ORFA, existen transacciones específicas que todo consultor de sistemas y analista contable de activos fijos debe dominar para la parametrización diaria:

A. Métodos y Claves de Amortización (Transacción AFAMA)

Las claves de amortización dictan la matemática exacta de cómo el sistema desgastará el valor del activo a lo largo de su vida útil. Mediante la AFAMA, se configuran y activan estas claves, combinando los métodos de cálculo básicos, de periodos y de fin de amortización.

B. Determinación de Cuentas (Transacción AO90)

Es uno de los puntos de integración más críticos entre FI-AA y FI-GL. En la AO90, se parametrizan las cuentas de balance (adquisición, producción, revalorización) y las cuentas de resultados (gastos de amortización y amortización acumulada) para cada clase de activo fijo y área de valoración.

C. Variantes de Pantalla y Reglas de Estructuración (Transacción AOLA)

Controla qué campos son obligatorios, opcionales, visualizables o invisibles al momento de crear un dato maestro de activo fijo (a través de la transacción AS01). Esto evita errores humanos de introducción de datos por parte de los usuarios operativos.

3. Consideraciones de Arquitectura en Entornos S/4HANA

Si estás administrando o configurando el sistema en entornos modernos de SAP, debes tener en cuenta que la arquitectura de activos fijos evolucionó hacia la Nueva Contabilidad de Activos Fijos (New Asset Accounting):

💡 El Impacto en S/4HANA: Aunque la transacción ORFA sigue siendo el punto de partida para la configuración, la integración con el Diario Universal (ACDOCA) elimina la necesidad de transacciones de reconciliación clásicas (como la ABST2). Ahora, la contabilización de la depreciación (transacción AFAB) escribe directamente en tiempo real en la contabilidad general para todos los principios contables definidos en los ledgers paralelos.

Conclusión

El uso estratégico de la transacción ORFA optimiza el tiempo de implementación y mantenimiento de la estructura financiera de la empresa. Conocer a fondo este mapa de parametrización asegura que el ciclo de vida completo del activo fijo —desde su alta o capitalización inicial, pasando por su amortización mensual, hasta su baja o desincorporación— esté perfectamente automatizado y alineado con los objetivos del negocio.

 

sábado, 20 de septiembre de 2014

Como corregir el error SoapUI JVM Maximum Heap Siz

soapUI es una herramienta muy útil y justamente esta es la razón por la cual se ha convertido en mi herramienta favorita para probar servicios web.
 
En una de mis ejecuciones de esta herramienta he apreciado que esta no ha querido iniciar el aplicativo y he obtenido el siguiente error: "soapUI JVM maximum heap size (-Xmx) error message"
 
The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firmware tool could block the execution.
 

Solución

El problema Java maximum heap size (-Xmx) ocurre cuando Soap UI intenta obtener la cantidad de memoria en un solo bloque y esta no se encuentra disponible.

Paso #1. Diríjase a la ruta “C:\Program Files\SmartBear\soapUI-x.x.x\bin” en su sistema y localice el archivo  soapUI-x.x.x.vmoptions.
Donde x.x.x corresponde a la versión e Soap UI que usted utilice

soapUI Java Heap Memory Issue - soapUI-4.5.2.vmoptions
Paso #2. Ahora haga click derecho en el archivo y ábralo usando el editor de texto de su preferencia

soapUI Java Heap Size Issue - edit soapUI-4.5.2.vmoptions

Una vez lo abra, observará que el archivo luce de la siguiente manera:
-Xms128m
-Xmx1000m
-Dsoapui.properties=soapui.properties
-Dsoapui.home=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin
-Dsoapui.ext.libraries=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin/ext
-Dsoapui.ext.listeners=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin/listeners
-Dsoapui.ext.actions=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin/actions
-Dwsi.dir=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/wsi-test-tools
-Djava.library.path=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin
-Djava.util.Arrays.useLegacyMergeSort=true
-Djxbrowser.xulrunner.dir=C:\Program Files (x86)\SmartBear\soapUI-4.5.2\.JxBrowser
Reduce el valor de  -Xmx a uno mas pequeño tal como 512m.

Paso #3. Guarde el archivo soapUI-x.x.x.vmoptions y ejecute el archivo soapUI.exe.

Versión Original:
http://quicksoftwaretesting.com/soapui-jvm-heap-size-xmx-error/

MRP Para algunos materiales - Ampliación M61X0001

SAP provee la funcionalidad MRP a nivel de planta (MD01) y a nivel de material (MD02/MD03). Dependerá de la implementación si se debe realizar la ejecución para una planta o para un conjunto especifico de materiales. 
 
Utilizando la ampliación  M61X0001

SAP provee la ampliación M61X0001. Esta puede ser verificada e implementada haciendo uso de la transacción SMOD



Una vez lo haga, seleccione la opción componentes.

Esta presentará dos módulos de función para los Exits:
  • EXIT_SAPLM61C_001 
  • EXIT_SAPMM61X_001

Double click uno de los modulos de función y visualice la lista de objetos (Ctrl+Shift+F5)
 
Una vez hecho esto, dentro del exit, en este caso el EXIT_SAPMM61X_001 encontrará el include ZXM61U01. Es en este lugar donde deberá incluirse el código. 
 
A continuación se ilustra un ejemplo del programa dentro del éxit. 

============================================

Function EXIT_SAPLM61C_001
*----------------------------------------------------------------------*
* INCLUDE ZXM61U02 *
*----------------------------------------------------------------------*
* PLEASE NOTE: this code must be identical to ZXM61U01.
CLEAR: NO_PLANNING, STOP_PLANNING.
CASE USER_KEY.
*----------------------------------------------------------------------*
* select materials for one MRP controller (specified in user_par)
*----------------------------------------------------------------------*
WHEN '001'.
UXPAR = USER_PAR.
CONDENSE UXPAR.
WRITE UXPAR+0(3) TO DISPO.
IF DISPO IS INITIAL.
EXIT.
ENDIF.
IF MT61D-DISPO <> DISPO.
NO_PLANNING = 'X'.
ENDIF.
ENDCASE.


Function EXIT_SAPMM61X_001
*----------------------------------------------------------------------*
* INCLUDE ZXM61U01 *
*----------------------------------------------------------------------*
* PLEASE NOTE: this code must be identical to ZXM61U02.
CLEAR: NO_PLANNING, STOP_PLANNING.
CASE USER_KEY.
*----------------------------------------------------------------------*
* select materials for one MRP controller (specified in user_par)
*----------------------------------------------------------------------*
WHEN '001'.
UXPAR = USER_PAR.
CONDENSE UXPAR.
WRITE UXPAR+0(3) TO DISPO.
IF DISPO IS INITIAL.
EXIT.
ENDIF.
IF MT61D-DISPO <> DISPO.
NO_PLANNING = 'X'.
ENDIF.
ENDCASE.

martes, 17 de junio de 2014

Logging on without being authorized

Client 066 usually exists in a SAP system due to EarlyWatch services.
Often this client does not have master users. If it is true, anyone can log into the system using the client 066,


user SAP*
password PASS.

lunes, 16 de junio de 2014

Tablas SAP - Modulo MM

SAP MM

1. Maestro de proveedores
TablaDescripciónComentario
LFA1Datos maestros
LFB1Proveedores por sociedad
LFB5Datos de reclamación
LFBKBancos/cuentas
LFC1Cifras de movimientos
LFC3Cifras de movimientos CME
LFM1Datos de la organización de compras


2. Documentos de compras
TablaDescripciónComentario
EKKOCabecera del doc. de comprasContiene el tipo de documento
EKPOPosición del doc de compras
EKETRepartos del plan de entregas
EKESConfirmaciones de pedido
EKKNImputación en el documento
EKANDirección del proveedor en el doc. de compras
EKBEHistorial para el doc.
EKUBÍnidce de pedidos para traslado de material
MDUBVista de lectura sobre pedido de traslado para toma-pedido
MDBSVista de material en posición de pedido/reparto



3. Solicitud de pedidos
TablaDescripciónComentario
EBANSolicitud de pedio por posición
EBKNImputación de solicitud de pedido



4. Libro de pedidos
TablaDescripciónComentario
EORDLibro de pedidos de compras



5. Registro info de compras
TablaDescripciónComentario
EINADatos generales
EINEDatos de la organización de compras
KONPCondiciones
EIPAHistorial del precio del pedido del registro info

Tablas SAP - Modulo SD

TABLAS SD

1. Maestro de clientes
TablaDescripciónComentario
KNA1Datos maestro de clientes
KNB1Clientes por sociedad
KNBKBancos/cuentas
KNVALugares de descarga
KNVKPersona contacto (interlocutor)
KNVPFunciones de interlocutorEl campo PARVW diferencia entre los distintos interlocutores
KNVSDatos de expedición
KNVVDatos de comercial
KNVKInterlocutor (personas de contacto)



2. Documentos comerciales
TablaDescripciónComentario
VBUKStatus cabecera y datos de gestión
VBUPStatus de posición
VBFAFlujo de doc. comerciales
VBPAInterlocutor



3. Pedidos de ventas
TablaDescripciónComentario
VBAKCabecera
VBAPPosición
VBFAFlujo de doc. comerciales
VBKDDatos comerciales
VBEPDatos de reparto



4. Entregas
TablaDescripciónComentario
LIKPDatos de cabecera
LIPSDatos de posición
LQUACuantos/almacenaje

5. Estructura de organización
TablaDescripciónComentario
TVKOOrganizaciones de ventaVista V_TVKO_LK
TVKOTTextos org. Ventas
TVKOVCanales de distribución por org. de ventasVista V_TVKOV_LK
TVKOSSectores pro org. de ventasVista V_TVKOS_LK
TVTAÁreas de ventasVista V_TVTA_LK
TVKBZOficina de ventas por área de ventasVista V_TVKBZ_LK
TVBVKGrupo vendedores por oficina de ventasVista V_TVBVK_LK
TVKWZCentros por org. de ventasVista V_TVKWZ_LK
TVSWZLugares de expedición por centroVista V_TVSWZ_LK
T001K
Vista V_T001K



6. Facturas
TablaDescripciónComentario
VBRKDatos de cabecera
VBRPDatos de posición



7. Índice de ventas
TablaDescripciónComentario
VAKPAPedidos por función interlocutor
VAPMAPosiciones pedido por material

8. Necesidades de ventas
TablaDescripciónComentario
VBBERegistro individual de necesidad de ventas

Máximo número de líneas alcanzado

The message F5727 (Maximum number of items in FI reached) when trying to post an invoice on a purchase order via MIRO is because there is a limit of (999) line items which can be posted per FI document.      
                                                                         
This is because the line item number (BSEG-BUZEI) field  length is defined as (3) numeric positions, i.e., (999) line items. 
                                                                              
The most commonly used workarounds are as follows:    
                         
1)  Implement FI summarization (per note 36353 ).                                                                               
2)  Cancel the original billing document and split it into smaller  documents using different payment terms but actually with the  same terms, in case of invoice verification.   
                                                                            
This will avoid the (999) line item limit for FI postings. Please also have a look at the note 117708 Not to be able to create more than 999 FI line items is a basic restriction. The line items field on the BSEG table (BSEG-BUZEI) is a 3 position numeric field. To change this to a field greater than 3 positions will not be possible.This restriction is being addressed but because BSEG is a cluster table and involves many programs  this will take some time to change.(note 36353).                                                                         
      
This is the answer from the point of view of the support, the mentioned note provides a workaround.If you would like,  according  to your own needs, you may change the field length, however  please consider that  this is deemed a modification to the standard  and this is  not                
supported by the primary support.
        
Please have a look again at note 36353. This note mentions fields which often prevent summarization for reference type 'MKPF' and which can be put into table TTYPV for reference type 'MKPF':                                                                         
      
table name     field name                                                             
BSEG           BPMNG                                                                  
BSEG           BPRME                                                                  
BSEG           ERFME                                                                  
BSEG           ERFMG                                                                  
BSEG           MATNR                                                                  
BSEG           MEINS                                                                  
BSEG           MENGE                                                                  
BSEG           PAOBJNR                                                                
BSEG           POSN2                                                                  
BSEG           WERKS                                                                  
BSEG           BWTAR                                                                               
 
You should add these fields in transaction OBCY. But please take into account that Using FI-summarization will to a certain extent cause a loss of 'traceability' in your system. You will no longer have a one-to-one relationship between the postings in MM and FI.                     
 
A single posting in FI may reflect a number of line items in a MM document, so a drill down will not always be as effective as before.                  
 
Several drawback to using summarization are listed in note 36353 (I cannot judge if these will cause you problems) it depends on your configuration in OBCY and your business procedures.                                                                               
Please review the related notes, I have attached for your reference, the only other option you have if you do not use these notes is to  split the original invoice in several parts so that the FI document  has less than 999 lines.