SAP & ABAP

Nuevo IVA 2010

2010-06-11T14:12:00.001+02:00

Como sabéis en unos días entran en vigor los nuevos porcentajes impositivos para el IVA reducido y genérico, pasando estos del 7% al 8% y del 16% al 18% respectivamente. En este post vamos a enumerar someramente algunas de las tareas a realizar en el Sistema.

Como punto de partida debemos considerar que NO se deben modificar los porcentajes de los indicadores de IVA antiguos, sino crear unos indicadores nuevos como copia de los indicadores de IVA soportado y repercutido antiguos, pero con el porcentaje legal a partir del 1 de julio.

Las tareas a realizar en FI se pueden enumerar de la siguiente manera:

1. Creación de los indicadores de impuestos nuevos al 7% y al 18% en la FTXP

2. Parametrizar la determinación de cuentas de los nuevos indicadores en la OB40 para las operaciones VST (iva soportado) y MWS (repercutido)

3. Comprobar las cuentas que tengan informado el campo Categoría Fiscal para, en el caso de que apunten al código de iva antiguo, actualizarlo al nuevo correspondiente en la FS00. Se comprueba en la tabla SKB1.

4. Crear una validación financiera para evitar contabilizaciones erróneas en los respectivos indicadores de IVA.

Esta validación en finanzas, a crear en la OB28 será nuestro punto de control para las fechas de validez, de forma que controle que no se contabilice nada con indicadores antiguos después del 30 de junio, y nada con los indicadores nuevos antes del 30.

Además de estas tareas, se tendrían que revisar en el Sistema cualquier formulario y desarrollo en general que mostrase los indicadores antiguos para proceder a su modificación. Del mismo modo, sería importante revisar las interfaces de contabilización en finanzas, y cualquier documento modelo, periódico, etc que estén en uso en el Sistema.

Versiones plan: tipos de cambio y copia de versiones

2010-05-06T12:37:00.003+02:00

En este post voy a comentar una incidencia real resuelta con la funcionalidad estándar de copia de versiones plan-plan para centros de coste.

El caso se inicia cuando el key user de controlling se da cuenta que los informes de datos plan de centros de coste están devolviendo unos importes en EUR que corresponden a un tipo de cambio incorrecto con respecto al USD; el tipo de cambio p (Conversión estándar para planificación de costes) que usa la versión plan 1 para la conversión entre la moneda de la Sociedad CO y la moneda de la transacción no se actualizó a su debido tiempo.

En la versión 1 se sube a SAP el presupuesto en dólares para ciertos centros de coste (moneda de la transacción y del objeto dólar), y al no haberse actualizado el tipo de cambio a tiempo, toda la conversión de monedas USD-EUR se ha hecho con los últimos datos válidos, los de 2009.

El tipo de cambio se actualizó en la transacción S_BCE_68000174 después de subir los datos plan, cuando debería de haberse hecho antes,

con lo que al sacar los informes de centros de coste en EUR y en USD, el tipo de cambio que se aplica es de 1,20705 dolares por euro.

Guardando en la transacción RPC0 los parámetros de usuario para monedas de informes, bien en moneda de la Sociedad CO (EUR), bien en moneda de la transacción (USD)

El informe S_ALR_87013611 (Centros de coste: Real/Plan/Desviación) mostrará que para datos plan en versión 1 en euro y en usd:

Es decir, 30.798,92 USD / 25.515,85 EUR = 1,20705

¿Cómo solucionar esto? Con la transacción KP97, copia de datos plan en plan. En el menú en Finanzas -> Controlling -> Contabilidad de centros de coste -> Planificación -> Ayudas planificación -> Copiar.

Tendremos que seguir los siguientes pasos:

1. Parametrizaremos otra versión, llamémosla Z como copia de la versión 1 (o cualquier otra versión plan objeto de incidencia), asegurándonos que usa el mismo tipo de cambio.

2. Si no está actualizado el tipo de cambio, actualizarlo en la S_BCE_68000174 (se trata de una operación financiera, por lo que se tendría que tratar con el usuario responsable correspondiente.

3. Hacer una copia de los datos plan de la versión 1 a la versión Z con la opción Monedas Plan igual Moneda de la transacción:

Esto es importante, ya que si los datos a copiar se han registrado con moneda de la transacción igual a USD, nuestro objetivo es que en la nueva versión se copien con el mismo importe en USD, sólo debe cambiar el importe en EUR.

Siguiendo este procedimiento, si originalmente teníamos 1.000 dólares y 0,82847 euros en la versión 1,, deberemos de tener 1.000 dólares y 0,68292 euros en la versión Z.

Y realmente ocurre así tras la copia. Si vamos a la tabla COSS y comparamos los registros para el centro de coste en la versión 1 y la versión Z, veremos que en los campos de moneda de la transacción y de moneda del objeto (la moneda del objeto también es dólar) los importes no cambian, pero en los de moneda de la Sociedad CO sí.

Pero nuestro objetivo final no es tener los datos plan en una nueva versión. Nuestro objetivo es corregir los datos de la versión 1, la versión en la que se suben los datos operativos del presupuesto, por lo que nos falta un último paso: Hacer la copia inversa.

Después de comprobar que todos los datos se han copiado correctamente y que los informes para datos plan de centros de coste devuelven el importe en dólares sin variación y que en euros aplica el tipo de cambio que queremos:

es decir, 30.798,92 USD / 21.033,18 EUR = 1,46430, podemos proceder, con la KP97 de nuevo, a hacer la copia de la versión Z a la versión 1. Tendremos ya solucionado el problema.

Este mismo procedimiento aplica también para los datos plan de proyectos/elementos pep mediante el uso de la transacción correspondiente del menú de Sistemas de Proyectos, CJ9B o CJ9BS, o para los datos plan de órdenes con la KO14.

Añadir campo a informes CO de partidas individuales

2010-04-19T13:13:00.013+02:00

Veremos en este post el método a seguir para añadir nuevas columnas a la estructura de línea del informe CJI3 de partidas individuales reales de proyectos y elementos pep.

Este método se basa en la nota explicativa: 325546 - CO line item reports: Creating a user-defined field, y con él podremos añadir nuevos campos, ya sean campos a medida, o simplemente campos estándar no disponibles, a los informes de partidas individuales de controlling, ya sean reales, plan o comprometido, y ya sean de cecos, órdenes, o proyectos.

Supongamos que queremos añadir a la CJI3 el campo Número de pedido para el caso de partidas con origen en factura de ventas. Lo primero que debemos hacer es crear un proyecto en la transacción CMOD para asignarle la ampliación COOMEP01, pues esta ampliación contiene, entre otras, la exit EXIT_SAPLKAEP_001, que permite añadir campos a los informes de PI´s reales (otros de los componentes hacen lo mismo para los informes para el Plan y para el Comprometido).

Una vez asignada la ampliación:

Crearemos la estructura CI_RKPOS que deberá tener como campo el que deseamos añadir a la estructura de línea del informe, es decir, el campo Número de pedido, llamémoslo ZVBELN.
Programaremos la exit mencionada para rellenar el nuevo campo.

En la exit tenemos la estructura cs_record que contiene cada una de las partidas que posteriormente se visualizan en el informe. Añadido el campo a la estructura ci_rkpos, también lo tendremos disponible en la estructura cs_record, por lo que lo podremos informar accediendo a tablas.

Tenemos el número de documento de referencia, que para partidas con origen en facturas de SD, será el número de la factura, en el campo cs_record-refbn por lo que podremos ir a las tablas VBRK y VBRP (de facturas de sd) y de estas obtener el número de pedido del campo VBELN e informarlo en el campo correspondiente de la estructura, cs_record-zvbeln.

Adicionalmente:

Deberíamos limitar la exit a los informes de proyectos con la sentencia check i_rep_object eq 'PD' al inicio de la exit. Así, no se ejecutará el resto del código para los informes de cecos, órdenes, etc.

Como el campo que queremos rellenar lo tenemos sólo para las partidas con origen en facturas de SD, también deberíamos limitar el código principal de la exit a la operación de referencia VBRK, esto es, tendremos que añadir al inicio, la sentencia check cs_record-awtyp eq 'VBRK'.

Llegados a este punto ya tendríamos todo el desarrollo abap listo, lo único que nos faltaría sería realizar la parametrización necesaria para que el campo se muestre en el ALV de la CJI3. Esto lo hacemos parametrizando el cluster de vistas V_TKALV en la transacción SM34, donde indicamos una serie de especificaciones técnicas para la correcta visualización del nuevo campo. Estas son:

Datos del catálogo de campos. Aquí añadimos el nuevo campo a la estructura KAEP_COAC además de algunas características de este.
En dependencias de selección deberemos añadir los campos del informe que son necesarios leer para poder rellenar el nuevo campo. En nuestro caso el número de factura (número de doc. de referencia)

Con todo esto, ya tendríamos en el informe CJI3 una nueva columna con el dato del número de pedido.

Manuales FICO

2010-04-18T13:53:00.002+02:00

Aquí dejo algunos manuales de FI y CO que comparto vía google docs:

Resumen TFIN Controlling (Excepto CO por objetos de coste y ML)

Report Painter

TFIN50_1 en castellano (Parametrizaciones básicas, GL,...)

TFIN50_2 en castellano (Cuentas a pagar y a cobrar,...)

Realineación de partidas en CO-PA (transacción KEND)

2010-04-15T20:09:00.004+02:00

Una funcionalidad un tanto desconocida pero interesante cuyas implicaciones deberíamos conocer, es la llamada realineación de datos en CO-PA mediante la transacción KEND, una vía con la que modificar los valores de características de Objetos PA.

¿Qué tiene de sigular la KEND? Pues que, como sabemos, una vez que en SAP se ha imputado a un objeto de imputación de CO, este no se puede modificar, con lo que esta transacción supone tener un mecanismo con el que saltarnos esta norma, al menos en PA.

Pero, ¿por qué querríamos modificar los valores de características de algunos Obj. PA? Pues porque quizás se han producido cambios en la lógica de derivación de características y quisieramos mantener los datos históticos en consistencia con los actuales, es decir, REALINEAR los datos existentes con las reglas de derivación actuales.

Otro motivo para usar la realineación podría ser la inclusión de una nueva característica al catálogo de campos de la Sociedad PA. En este caso, evidentemente, los datos históricos no la tendrían informada y con la KEND podríamos derivar este nuevo dato.

Una cosa que tenemos que tener en cuenta con esta funcionalidad es que, para mantener la integridad de los datos, la partida individual original no se modifica, lo que se modifica es el objeto PA. Para entender esto tengamos en cuenta:

En la tabla CE4XXXX (donde XXXX es la Soc.PA) tenemos el Obj. PA. Es la tabla de segmento.
En la tabla CE1XXXX tenemos las partidas individuales reales de PA.
Por cada objeto PA, es decir por cada entrada en la CE4XXXX tendremos n entradas en la CE1XXXX, n partidas individuales.

así, al ejecutar la KEND para los datos seleccionados, en la tabla CE4XXXX modificaremos el valor de característica de la característica deseada, pero en la CE1XXXX las partidas asociadas no modificaran el valor de esa característica. Además, por cada Obj.PA modificado se creará una entrada en la tabla CE4XXXX_KENC, entrada que conservará los valores de características primitivos.

¿Qué implica esto último? Pues que si ejecutamos un informe de Report Painter, al tratarse de un informe que totaliza por características que están definidas a nivel de Obj. PA, es decir, las características cuyo conjunto de valores definen cada Obj.PA (transacción KEQ3), los datos que mostrará serán los actuales. Pero si lo que ejecutamos es un informe de partidas individuales como la KE24, dependiendo de cómo se ejecute, mostrará las partidas tal como se contabilizaron o según la información actual del segmento:

Para ejecutar la KEND llevaremos a cabo los siguientes pasos: Crear la Ejecución, la cabecera, indicando su texto descriptivo y crear las órdenes de modificación deseadas:

En cada orden definiremos las condiciones de selección:

y las reglas de conversión: si queremos derivar de nuevo las características seleccionadas, o sobreescribirsus valores:

Para terminar, mencionar que debemos tener en cuenta que en las condiciones de selección deberemos de usar características de nivel de objeto. Si tenemos las características A, B y C definidas a nivel de segmento y como condición de selección usamos los valores de característica A = 1, B = 2 y D = 4, donde D es una característica que no está definida a nivel de segmento, el sistema no encontrará en la CE4XXXX el valor 4 para la característica D, esta característica no se informa en la tabla de segmento. O usamos como condición de selección A y B o A, B y C.

Para más información:

Documentación de la HELP

Nota explicativa 94458 (precisa ususario de OSS)

Adaptación y generación del Modelo 347 en SAP

2010-03-18T21:14:00.017+01:00

En marzo de 2008 se emitió la Orden Ministerial EHA/3012/2008, con vigencia a partir del 1 de enero de 2009, por la que se aprobaba la nueva normativa del Modelo 347 de Declaración anual de operaciones con terceras personas, así como los formatos físicos y lógicos, etc, para su presentación.

Este modelo se presenta anualmente y declara las operaciones con terceros superiores a 3.005,06 euros, su carácter es obligatorio y se presenta en el mes de marzo del ejercicio siguiente a aquel a que se refiere la declaración.

El modelo 347 en SAP

El report que ofrece SAP para presentar el modelo 347 es el S_ALR_87012401 y lo tenemos dentro de la carpeta de Reporting de Declaraciones, en Finanzas, Libro Mayor.

Este informe nos da la opción de mostrar en pantalla las operaciones a declarar y generar en el servidor de aplicación de SAP el fichero físico mediante las opciones de Salida en Lista y Salida como fich. Unix disponibles en la pantalla de selección.

Este fichero Unix lo deberemos de descargar al PC mediante el otro report estándar S_PL0_09000158, por lo que es importante mantener el mismo nombre del fichero de salida para su posterior descarga.

El funcionamiento del report S_PL0_09000158 para generar el fichero en el PC es sencillo, sin embargo, dependiendo de nuestro codepage tendremos que usar una opción u otra de descarga:

Para mantener actualizado este desarrollo estándar, deberemos aplicar la nota SAP 989338 para obtener la útima version del report RFASLDPC asociado a la transacción S_PL0_09000158.

Cambios legales a los que adaptarse

Algunos de los cambios al modelo 347 que se aprueban en dicha Orden afectan, no sólo a la lógica de funcionamiento del report ABAP RFUSVS14 que genera la declaración, sino también a la estructura del fichero que se genera en SAP.

Algunos de estos cambios son:

1. Se declararán los cobros en efectivo superiores a 6 mil euros.
2. La longitud del fichero pasa de 250 a 500 caracteres
3. El código de país pasa de 3 a 2 posiciones, etc.

En las notas SAP 1286880 y 1315415 podemos tener acceso a documentación interesante sobre cómo adaptar el report RFUSVS14 a la nueva normativa aplicando una serie de notas.

La nota principal que debemos aplicar es la 1308645 (Legal change for RFUSVS14), sin embargo, del nivel de support package instalado tendremos que aplicar previamente otras notas que son prerequisito, como las notas:

0001153811 RFUSVS14 : multiple tax code selction & numeric field issues
0001231043 Error in program RFUSVS14
0001271698 RFUSVS14:All Vendors & Customers not getting displayed
0001318657 Correction note for 1308645

pero no es difícil averiguarlo con la SNOTE, ya que haciendo el download de la nota 1308645, automáticamente se solicitará el download de las notas previas necesarias.