lunes, 29 de abril de 2013

SAP FI-AA: Cambio de datos de valoracion (Vida Util) en subnumero de Activo Fijo (inmovilizado)


Pónganlo todo a prueba, pero quédense nada más con lo bueno, y rechacen todo lo malo. 1 Tesalonicenses 5:21-22 (Lenguaje Actual)

La parametrización buscada!
Primero lo primero: ésto no lo hubiese solventado tan rápidamente sin la colaboración especial de la mejor consultora SAP SSS y Coach en Finanzas Personales que conozco:

http://joselynquintero.com/
Joselyn Quintero website
Facebook Josely Quintero Muchas graicas Yosy, siempre tan amable y diligente. Eres un sol.

En mi opinión, el módulo de activos fijos de SAP (FI-AA) es el mejor de todas las funcionalidades de la Gestion Financiera (FI): es el más completo, confiable y flexible.

El problema era el siguiente:
Un subnumero de activo fijo es un componente de un activo que requiere una supervisión especial, ya sea porque su metodo de amortización (Horas Maquina, Acelerado, etc) es diferente al principal o porque su vida util difiere, se requiere controlar un baja o alta parcial, o inclusive porque el inicio de de la amortización es distinto. Ahora, ¿como hacemos para permitir "personalizar" los datos de valoracion de un subnumero?
En FI-AA existen los niveles de actualizacion (algo así como status campos en otros modulos), veamos que dice el HELP de SAP al respecto:
Nivel de actualización
Se puede especificar un nivel de actualización para cada grupo de campos del registro maestro de activo fijo. El nivel de actualización determina en qué nivel de clasificación de activos fijos puede actualizarse un grupo de campos.
Los niveles de actualización del sistema son:

  • Clase de activos fijos

  • Número principal

  • Subnúmero de activo fijo
Debe asignarse uno de estos niveles de actualización a un grupo de campos con los siguientes resultados:

  • Sólo clase de activos fijos
Si se especifica la clase de activo fijo como el único nivel de actualización para un grupo de campos, no podrán actualizarse los campos en el nivel de número principal o de subnúmero de activo fijo. Además, estos campos sólo pueden visualizarse en dichos niveles. Los valores de estos campos se copian de la clase de activos fijos al número principal y al subnúmero de activo fijo. Las modificaciones realizadas posteriormente en estos valores del campo de la clase de activos fijos no quedan reflejadas en los registros maestros existentes (número principal y subnúmero de activo fijo), sino que sólo son aplicables a los activos fijos creados recientemente.
  • Sólo número principal
Si se especifica el número principal como nivel de actualización para un grupo de campos, sólo podrán actualizarse los campos al crear o modificar el número principal. Los valores de estos campos se copian automáticamente en subnúmeros de activo fijo creados posteriormente y, una vez allí, ya no pueden volver a modificarse.
  • Sólo subnúmero de activo fijo
Si se especifica el subnúmero de activo fijo como nivel de actualización, podrá actualizar el grupo de campos del nivel de número principal y del de subnúmero de activo fijo.
  • Número principal y subnúmero de activo fijo
Si se especifica el nivel de actualización como número principal y subnúmero de activo fijo, el grupo de campos del número principal se propone como valor por defecto durante la actualización de los subnúmeros de activo fijo, pero todavía puede modificarse.

Gráfico: Control de estructuración de pantallas
Copia mediante una referencia (al crear registros maestros) Se puede crear un activo fijo utilizando otro activo fijo como referencia. Se utiliza la estructuración de pantallas para controlar si ciertos grupos de campos del activo fijo de alta pueden completarse con los valores del activo fijo fuente de referencia. No deben completarse todos los campos copiando desde el activo fijo de referencia. Es más razonable actualizar por separado algunos de estos campos para cada activo fijo, ya que se aplican sólo a un activo fijo (por ejemplo, el valor base asegurable y otros campos de valores que contengan datos de seguro).





No puede definirse un nivel de actualización para los campos suprimidos mediante la estructuración de pantallas.
Disposición A causa del gran número de campos, el registro maestro de activo fijo se divide en diferentes pantallas y etiquetas utilizando funciones relacionadas con la disposición. En el Customizing (Datos maestros), puede especificar cuántas fichas quiere tener (hasta un máximo de 8) y qué grupos de campos desea visualizar en las etiquetas de las que dispone. Puede hacer estas especificaciones dependientes de la clase de activos fijos. En caso necesario, puede definir excepciones dentro de una clase de activos fijos que dependan del plan de amortización.

Control de Pantallas en FI-AA




En resumidas cuentas: se puede parametrizar cuales datos se pueden "heredar" o diferenciar para los subnumeros, según sea el caso o necesidad.
La ruta de configuracion para los datos de Valoración es la siguiente (la transaccion ORFA te despliega un SPRO resumido para FI-AA):


Ruta de parametrización
Escogemos la Estructura de pantalla 2000 Amo a nivel de Subnumero

Cambios a nivel de subnumero

Y listo, recordemos que allí solo se encuentra los datos de valoracion:
Control de datos de valoración para los subnumeros

Nota: ruta de parametrización del resto de las vista del activo fijo:
Configuración complementaria
https://www.dropbox.com/s/ngy7vuwlgi0e5y5/130429_%20SAP_modificar%20datos%20valoracion%20subnumero.pdf

Gracias Yosy ,*

Dios te bendiga!

jueves, 25 de abril de 2013

SAP: Habilitar campo en Sustitución / Validacion en SAP (OBBH, BSEG-REBZG)

Acuérdense de esto: «El que da poco, recibe poco; el que da mucho, recibe mucho.»  Cada uno debe dar según crea que deba hacerlo. No tenemos que dar con tristeza ni por obligación. ¡Dios ama al que da con alegría!  Dios puede darles muchas cosas, a fin de que tengan todo lo necesario, y aun les sobre. Así podrán hacer algo en favor de otros.  Como dice la  Biblia , refiriéndose al que es generoso: «Siempre que ayuda a los pobres, lo hace con generosidad; y en todo sale triunfante.»
2 Corintios 9:6-9 TLA
Recientemente tuve un "cangrejo" en un cliente, y el problema era el siguiente:

Se requiere que las notas de Débito o Credito en los estados de cuentas de los clientes (FI-AR) se venzan según su condición de pago y/o según la factura a la cual hace referencia.
Origen del problema: REF.A FACTUR


En éste punto hay que tener en cuenta algo: por estandard SAP, las notas de debito o credito vencen según la fecha base indicada, indiferentemente de la condición de pago asociada a la posición del documento; pero hay dos exepciones a la regla en base al contenido del campo "Ref.a Factur", veamos como lo explica SAP:

Ref. a Factura: Número documento de factura a la que pertenece la operación

Para posiciones de documento que están relacionadas con otra posición de documento, este campo contiene el número del documento de interlocutor.

Utilización

En la versión estándar de SAP, el campo se utiliza para
  • abonos que hacen referencia a una partida de factura determinada
  • facturas siguientes de una partida de factura
  • pagos parciales de una partida de factura
  • compensaciones parciales de anticipos
En los dos primeros casos, las condiciones de pago se copian de la partida de factura de referencia a la partida en tratamiento. Con ello se asegura que las partidas venzan en la misma fecha y se paguen a la vez mediante el pago automático.
Para los abonos, para los que en este campo aparece una "V", rige una regla especial. En ese caso, el vencimiento se determinará como si se tratase de una factura. Si el campo está en blanco (no contiene ningún número de documento ni ninguna "V"), el vencimiento será en la fecha base para plazo de pago.
En caso de dudas, podemos resumirlo así:
  1. En caso de que el campo "Ref.a Factur" esté en blanco, entonces la nota vence segun la fecha base sin importar la condición de pago,
  2. Si el campo "Ref.a Factur" contiene "V" entonces se aplica la condición de pago
  3. Si el campo "Ref.a Factur" contiene el numero de documento SAP de la factura, el sistema "hereda" los datos de pago de dicho documuento permitiendo que el vencimiento sea el mismo.

Clarisimo no?, El origen del inconveniente tambien ocurre porque al generar la nota de debito o crédito en SAP-SD el campo "Ref. a Fact" (no confundir con el campo REFERENCIA) no se llena al contabilizarse el documento financiero. Si alguien sabe como parametrizar ésto por favor envíame un e-mail.

En tal sentido, se decidió la no muy brillante idea de crear una regla de sustitución para que al generarse el documento financiero se sustituya el campo "Ref. a Fact" (BSEG-REBZG) por el contenido de campo "Referencia" (BKPF-XBLNR) el cual si viene lleno desde el modulo de SD con el numero de documento SAP. Hasta aquí todo bien, pero existe la limitante que por el estandar SAP el campo "Ref. a Fact" (BSEG-REBZG) no está permitido para Validaciones o Sustituciones, más adelante explico el porqué.

Básicamente me apoye en dos informaciones, en un 75% en la página SAP FANS FORUMS y en un 25% En el Market Place de SAP el peso corresponde a la utilidad de información.

Basicamente hay que seguir 3 sencillos pasos:

1. (Esto no es transportable) Debemos modificar la tabla GB01 y desbloquear el campo BSEG-REBZG, este paso está implicitamente explicado en el Post de Martillando una Tabla, y tambien puedes descargarlo haciendo clic aquí. pero básicamente se hace así:
    1. Ir a la SE16 con la tabla GB01 buscar el registro donde GB01-BOOLCLASS=009, GB01-CLASSTYPE=S, GB01-BCLTAB=BSEG, GB01-BCLFIELD=REBZG
    2. hacemos doble clic en el registro encontrado y entramos en el "modo debugging" ingresando "/H" en el cuandro de transaccion
    3. Ingresamos la variab "CODE", presionamos enter, doble clic en el lapiz y cambiamos valor de la variable de "SHOW" por "EDIT" y continuamos con la ejecucion del programa (F8)
    4. Finalmente nos mostrará el campo GB01-BEXCLUDE en modo edición, borramos "X" y dejamos en blanco
Imagenes para Ilustrar lo indicado anteriormente:
Ingresando a la SE16

Realizando la busqueda del campo que queremos habilitar para la sutitucion o validacion

Registro a modificar

Registro en modo "SHOW" o sólo visualización

entrando en modo Debuging con "/H"

Confirmacion del sistema

Ingresando la variable CODE

Cambiando SHOW por EDIT

Seguimos con la ejecución del programa

Modificando el campo BEXCLUDE a "vacío"

2.(Esto es transportable) Debemos modificar la vista de tabla V_GB01C para incluirla la la lista de campos permitidos: Vamos a la SM30 con la vista:
ingresando a la SM30 con la Vista V_GB01C
 Presionamos el botón ACTUALIZAR

Entramos a la vista de la tabla
 Presionamos el Boton ENTRADAS NUEVAS

Llenamos los campos con la siguiente información (sin comillas ""):
  • Clase Boole:"009"
  • Tipo Clase:"S"
  • Tabla:"BSEG"
  • Campo:"REBZG"
  • Excluir:dejar en blanco

Campos llenos


3. (Esto no es transportable): Finalmente debemos ejecutar un programa que nos habilitará el campo en los programas, reglas y rutinas de las Validaciones y Sustituciones (OB28 / GBB0 / OBBH):
Vamos a la SA30 y ejecutamos el programa RGUGBR00:

Ejecutando el programa RGUGBR00
 Indicamos el area de aplicacion e instante de aplicacion según sea el caso, para éste en particular es FI y todos los instantes (*), adicionalmente marcar las opciones deseadas:

Indicando parámetros de ejecución
Ejecutar (F8)

Y listo!

Consideraciones finales:
Por qué SAP no permite que el campo "Ref. a Fact" (BSEG-REBZG) se use para validaciones o sustituciones?Me pregunte esto al comenzar, y cuando comenzó a funcionar la sustitución me dí cuenta de el por qué.
Reconozco que esos alemanes detras de SAP son brillantes y no dejan nada al azar: resulta que si ese campo siempre esta lleno (inclusive cuando intentas modificar un documento, igual la regla de sustitución se aplica) no se puede modificar ningún dato relacionado con el pago, es decir, ni fecha base, ni condición de pago, ni días para pago o % de Descuento. Lo que genera limitantes en la funcionalidad para los usuarios finales.
Así que, al final de todo ésto, la idea de la sustitución no fué practica y tuvo que ser declinado. (aquí debería ir una carita triste?). Lo positivo es que este instructivo aplica a cualquier campo que querramos agregar a las reglas de validación o sustitución.

 Dios te Bendiga!

Descarga éste post haciendo Clic aqui
Descarga SAP NOTE OSS 20637 haciendo Clic aqui
Descarga Post de Referencia de SAP FANS CLUB FORUMS haciendo Clic aqui
  
 

lunes, 22 de abril de 2013

SAP: Como Martillar una tabla SAP (modificación forzada de una tabla SAP) (&SAP_EDIT)

 Hebreos:14 TLA

Traten de vivir en paz con todos, y de obedecer a Dios; porque si no lo hacen, jamás lo verán cara a cara.
Pégale con el martillo.
ACTUALIZACION 2013 Jul 11: Considerar que los BASIS pudieran haber bloqueado algunas variables de entorno que imposibiliten realizar alguno de éstos pasos, normalmente ésto se acostumbra a hacer en el ambiente de producción (PRD).
Éste post viene en combo, se ha dividido en dos post porque son herramientas que pueden ser usadas individualmente,

Vayamos al grano, quiero compartir dos métodos para "martillar" una tabla (registrar o modificar de modo forzado un tabla en SAP),
Considere por favor que ésto pudiera generar inconsistencias graves en SAP y anular cualquier solicitud de soporte o garantía directa con SAP AG por daños colaterales a tablas
Habiendo dicho eso, hay dos opciones: