MANUAL DE USUARIO DEL FORMATO DE TRANSMISIÓN

ESTÁNDAR DE LA OCDE

El Formato de Transmisión Estándar de la OCDE

para el Intercambio Internacional de Información en Materia

Tributaria (STF)

Una introducción

ORGANIZACIÓN PARA LA COOPERACIÓN

Y EL DESARROLLO ECONÓMICOS

Las Administraciones Tributarias de los Estados han establecido modelos de declaración anual de las rentas obtenidas por las personas físicas residentes en otros Estados miembros de la Unión Europea y en aquellos otros países y territorios con los que se han establecido acuerdos para el intercambio de información. Estos modelos, que deben presentarse a las Administraciones Tributarias respectivas, contienen la información relativa al año natural inmediato anterior, y esta información puede tramitarse por vía telemática a través de internet o teleproceso. Para realizar el intercambio de información se aprobó un modelo de intercambio de datos basado en el Formato Estándar de Intercambio Automático de Información de la OCDE (STF-Standard Transmission Format), en el que se respetan las características técnicas de este formato. El STF se define como sucesor del SMF, el Formato Magnético Estándar de la OCDE para el intercambio internacional de información en materia de impuestos directos, adoptado en 1992 y reformulado en 1997. El SMF se construyó para soportar el intercambio automático de información, en el sentido del Artículo 26 del Modelo de Convenio de la OCDE. No obstante, en el diseño del STF se contempla también el objetivo de dotarle de flexibilidad y posibilidad de extensión. Obra publicada originalmente por la OCDE en inglés con el título: USER GUIDE FOR THE OECD STANDARD TRASMISSION FORMAT

The OECD Standard Transmission Format for international information exchange in taxation

An introduction

©2008 Organisation for Economic Co-operation and Development (OECD)

www.oecd.org

OECD Publications Service

2, rue André-Pascal, 75775 Paris

Cedex 16, France

©2010, Instituto de Estudios Fiscales (IEF) para la edición española.

Obra publicada por acuerdo con la OCDE, París. El Instituto de Estudios Fiscales (IEF) es

responsable de la calidad de la edición española y de su coherencia con el texto original. En caso

de discrepancias prevalecerá la edición en lengua inglesa.

ISBN 978-84-8008-327-0; www.ief.es; NIPO: 602-10-014-X

Traducción al español patrocinada por la Secretaría de Estado de Hacienda y Presupuestos en el marco del convenio de colaboración con la OCDE. Maquetación: Secretaría de Estado de Hacienda y Presupuestos. Ministerio de Economía y Hacienda. Madrid. España.

Todos los derechos reservados. No está permitida la reproducción total o parcial de este libro, ni su tratamiento informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito del editor.

2

Contenidos 1. ¿Dónde encaja el STF? 2. ¿Qué contenidos soporta el STF? 3. ¿Cuál es la estructura básica de un mensaje STF? 4. ¿Cuál es la estructura modular de los esquemas para la definición del STF? 5. ¿Cuál es la estructura de un documento STF_DIRECT? 6. ¿Dónde puede encontrarse una referencia detallada sobre todos los elementos y su contenido? 7. ¿Cómo se garantiza la coexistencia entre el SMF y el STF? 8. Ejemplos de Elementos y Mensajes 9. ¿Con qué dispositivos cuenta el STF?

2

1. ¿Dónde encaja el STF? 1.1 Se define al STF como sucesor del SMF, el Formato Magnético Estándar de la OCDE para el intercambio internacional de información en materia de impuestos directos, adoptado en 1992 y reformulado en 1997. A fecha de hoy no se ha previsto un límite para la coexistencia entre el SMF y el STF. 1.2 El STF forma parte del grupo de recomendaciones SEIT de la OCDE (Estándares para el Intercambio internacional de Información en materia Tributaria). Dentro de este conjunto de recomendaciones, el ámbito del STF es la definición del formato del contenido de los mensajes, que se obtiene por medio de un esquema del Extensible Markup Language - XML (lenguaje de marcas extensible). El STF no aborda cuestiones tales como la transmisión y el encriptado, entre otras, de los mensajes. 1.3 Si bien la máxima proximidad del STF al SMF constituyó un importante objetivo en su diseño (lo que posibilita los programas-puente), también se consideró como objetivo a medio plazo la compatibilidad del STF con los estándares internacionales XML que puedan crearse en materia de imposición, a lo que aspira el Comité Técnico del OASIS Tax XML*. La intención tanto del Comité Técnico del OASIS Tax XML como del grupo TIES de la OCDE (Grupo de trabajo sobre tecnologías de la información) es la de trabajar en pro de esa convergencia. 2

¿Qué contenidos soporta el STF?

2.1 El SMF se construyó para soportar el intercambio automático de información (en el sentido del Artículo 26 del Modelo de Convenio de la OCDE) en materia de imposición directa. Tratándose básicamente –si no exclusivamente- de una versión moderna del SMF, el STF soporta también este tipo de intercambio. Por tanto, el primer formato de mensaje construido en el STF ha sido STF_DIRECT destinado precisamente a este tipo de información. 2.2 No obstante, en el diseño del STF se contempló también el objetivo de dotarle de flexibilidad y posibilidad de extensión. Por tanto, el STF puede extenderse fácilmente a otro tipo de mensajes con información tributaria. En esta posibilidad se incluye tanto su uso para intercambios distintos de los automáticos como para contenidos que difieran de la información convencional sobre rentas del tipo SMF. 3

¿Cuál es la estructura básica de un mensaje STF?

3.1 Como es habitual en los mensajes, los mensajes STF responden a una estructura jerarquizada cuyo vértice (MessageSpec) especifica la información técnica del mensaje en su conjunto y un número arbitrario de documentos detallados (en este contexto se utiliza el término “documento” en sentido amplio y no con el significado estricto que se le otorga en XML, en el que un documento es siempre la unidad más amplia que contiene un único elemento raíz. Los documentos en sentido estricto del XML son lo que aquí denominamos “mensajes”). En el nivel actual de desarrollo del STF únicamente se ha definido un tipo de tales documentos (STF_DIRECT), pero desde el momento en que se desarrollen otros formatos, podrán incluirse igualmente en los mensajes.

*

(N. de la T.) OASIS: acrónimo procedente del inglés “Organization for the Advancement of Structured Information Standards” (Organización para el desarrollo de estándares para la estructuración de información). El OASIS Tax XML, designa, por tanto, a la división encargada, dentro de dicha Organización, de la utilización del leguaje XML en el ámbito tributario.

3

La imagen 1 representa esta estructura general.

Imagen 1: Estructura general de los mensajes STF En términos de esquema XML, esta estructura se expresaría como sigue:

Fragmento de esquema 1 El atributo de nombre “versión” y valor “1.0” designa el grado actual de desarrollo. 3.2 La estructura del elemento de especificación del mensaje (header) queda reflejada en la imagen 2.

Imagen 2: Estructura de la especificación del mensaje (Header) [Donde “SendingCountry” es el país remitente; “ReceivingCountry” el receptor; “Warning” el campo de avisos; “Contac” contacto; “MessageRefld” es el campo destinado a la referencia del mensaje; “TaxYearList” ejercicios fiscales a los que se refiere, como se explica más adelante].

El elemento contiene datos que identifican y describen el conjunto del mensaje. “SendingCountry” y “ReceivingCountry” identifican la correlación de la transmisión por lo que aparecen bien visibles al principio del mensaje e independientes del contenido de la transmisión que se despliega después. Son elementos opcionales pues - no son imprescindibles para el éxito de la transmisión, - no se corresponden exactamente con campos del registro SMF - el STF se asemeja mucho al SMF.

4

No obstante, se recomienda encarecidamente utilizar estos campos de identificación con la finalidad para la que se crearon. El campo “warning” se utiliza para las limitaciones jurídicas. Es un campo de texto libre para dejar constancia de las restricciones de uso de la información que contiene el mensaje y el marco jurídico en el que se intercambia. El campo “Contact” debe incluir toda la información que sea necesaria para el contacto con las personas que efectúan el procesamiento de los datos transmitidos y que sean responsables del mismo, tanto desde el punto de vista legal (autoridad competente) como técnico. Se trata de un texto libre pues no está destinado al procesamiento automático. “MessageRefld” es un identificador único que el emisor tiene que otorgar al mensaje y que se utilizará en toda la correspondencia. “TaxYearList” es un listado de los años respecto de los que se transmite información en los documentos del mensaje en curso. Para indicar el ejercicio fiscal se proporciona el dato de su último día. El formato para las fechas es aaaa-mm-dd. Cada entrada debe separarse mediante blanco espacial. 4. ¿Cuál es la estructura modular de los esquemas para la definición del STF? 4.1 Los documentos STF son documentos XML. El Grupo de trabajo sobre tecnologías de la información (TIES) ha definido: (1) Un documento esquema XML (stftypes-1.0.xsd) que contiene una serie de tipos de datos simples y complejos para su uso en cualquier esquema STF que conforman un tipo de documento concreto. (2) Un documento esquema XML (stfdirect-1.0.xsd) para la definición de los documentos XML que reemplazarán los registros SMF, junto con la definición del contenedor del mensaje STF_OECD para esos documentos. (3) Dos documentos esquema XML adicionales para los códigos OCDE e ISO utilizados en los documentos STF. Estos esquemas enumeran los valores admisibles de los códigos. 4.2 El núcleo del STF es la definición de los tipos de datos que van a utilizarse en los documentos STF. Se espera que este conjunto de tipos se amplíe tan pronto como se definan nuevos documentos. Con la llegada de nuevas definiciones de documentos aumentarán, con toda seguridad, las necesidades adicionales que aún no se hayan abordado desde una perspectiva puramente stfdirect. Cabe esperar que estos nuevos tipos se ajusten a una de las siguientes tres categorías: (1) Tipos que, aún cuando no sean necesarios para stfdirect, tengan un cierto grado de inespecificidad y se añadan por tanto a la recopilación stftypes. (2) Tipos que sean específicamente necesarios para la definición de un cierto tipo de documento sin más utilidad general; se añadirán como esquema XML independiente para su uso exclusivo en la definición de ese documento. (3) Tipos que, aunque estén estrechamente relacionados con otros tipos ya definidos en stftypes difieran en algún punto en la configuración del algún aspecto del nuevo documento; se

5

derivarán como extensión o restricción respecto de los stftypes generales con los que están relacionados. 4.3 En tanto que el stfdirect sea el único tipo de documento en la familia STF, lo pertinente es no complicar la estructura del esquema más de lo estrictamente preciso para este supuesto. Por tanto: (1) La estructura del mensaje general y la del documento stfdirect se definen dentro del mismo esquema; (2) Todos los esquemas antes mencionados se ubican en el mismo espacio de nombres (urn:oecd:ties:stf:v1); Esto genera la estructura que muestra la imagen 3: stftypes-1.0.xsd Tipos generales para la familia STF

stftypes-1.0.xsd STF_OECD STF-DIRECT

isotypes.xsd código incluye

oecdtypes.xsd

código incluye

incluye

specifictvpes.xsd código incluye

Imagen 3: Estructura inclusiva de los esquemas STF a fecha de hoy 4.4 Cuando en el futuro se añadan nuevos tipos de documentos, con toda probabilidad la estructura de la imagen 3 resultará impropia. Cada tipo de documento se definirá entonces en un espacio de nombre junto con sus tipos de datos específicos y se importarán los tipos generales STF (núcleo), incluyendo el correspondiente al mensaje. 5. ¿Cuál es la estructura de un documento STF_DIRECT? 5.1 La imagen 4 muestra la estructura de mayor nivel en un documento STF_DIRECT.

Imagen 4: STF_DIRECT, mayor nivel 6

[Donde “DocSpec” es el campo de especificación del documento; “RecipientBeneficialOwner” es el perceptor/beneficiario efectivo; “RecipentAgentOrIntermediary” es el Agente o Intermediario del perceptor; “ActualPayer” el pagador real; “PayerAgentOrIntermediary” el agente o intermediario del pagador; “PaymentData” la fecha de pago y “OtherInfo” el campo destinado a “otra información”]. Se observará que los componentes de esta estructura se enmarcan en cuatro categorías: - DocSpec, PaymentData y OtherInfo representan cada uno un tipo de información

concreta con entradas únicas en el documento.

- Todos los demás componentes tienen la misma categoría: se refieren a las partes

intervinientes en la operación comunicada.

La estructura puede resultar compleja a primera vista, pero tras un cierto análisis resulta más clara. Las líneas de puntos significan “opcional”; los datos referidos a las partes enmarcados en este tipo de líneas pueden aparecer o no. Los recuadros con línea continua denotan la obligatoriedad de la cumplimentación del campo. En los documentos tipo stfdirect deben constar los datos relativos al beneficiario efectivo, mientras que los datos del agente o intermediario que intervenga en nombre del beneficiario efectivo no son imprescindibles. La configuración de los datos correspondientes al pagador es algo más sofisticada. Es preciso confirmar la inclusión de al menos uno de los siguientes campos: “pagador real” y “agente o intermediario del pagador” aunque no haya una norma estricta sobre la obligatoriedad de uno de significa “uno de ellos”. Puede comprobar que la estructura ellos en concreto. El símbolo planteada en la Imagen 4 permite una de las siguientes situaciones: - constancia únicamente de los datos del pagador - constancia únicamente de los datos del agente o intermediario del pagador - datos tanto del pagador real como del agente o el intermediario del pagador, y que al mismo tiempo exige la cumplimentación de alguno de estos campos. 5.2 El elemento DocSpec sirve como descripción del documento stfdirect concreto al que pertenece, al igual que el elemento MessageSpec identifica la totalidad de los documentos integrados en el mensaje. DocSpec tiene la siguiente estructura:

Imagen 5: Elemento de especificación del documento El indicador del tipo de documento (DocTypeIndic) alberga los datos administrativos sobre la situación del documento (lo normal es que se trate de un dato “nuevo” enviado por primer vez en un porcentaje cercano quizá al 100 por cien de los documentos, o puede tratarse de la

7

corrección de un documento enviado previamente, o la repetición de un documento enviado pero que no se haya recibido correctamente). La identificación mediante referencia del documento (DocRefld) es su único identificador. Para posibilitar cualquier referencia ulterior tiene que ser único al menos dentro del mensaje en el que está contenido. Los siguientes dos elementos son opcionales y únicamente se necesitan en caso de corrección o de repetición de envío. Dado que en esos casos se trata de campos obligatorios y no opcionales, este esquema es un modelo algo inconsistente respecto de la generalidad de situaciones posibles. Los elementos se refieren a documentos enviados previamente aportando los campos DocRefld y MessageRefld del documento al que hacen referencia y al mensaje en el que estaban incluidos. 5.3 Los datos sobre el pago constituyen el motivo por el que se remite el documento. La administración remitente anota la información que conozca sobre la renta del beneficiario efectivo en el país de la fuente. La estructura de este elemento es como sigue:

Imagen 6: Datos sobre la renta [Donde “PaymentDate” es la fecha de pago; “MonAmmt” el importe; “AcctInfor” los datos bancarios y “TaxRate” el tipo de gravamen.] Cada documento sirve para transmitir información sobre un único elemento de renta del beneficiario efectivo. Por tanto, si es necesario informar sobre rentas procedentes de distintas fuentes, percibidas en momentos distintos, etc., es necesario transmitir varios documentos (preferiblemente en el mismo mensaje). El ejercicio fiscal al que corresponde el pago se anota en el elemento TaxYearEnd, que es un campo de fecha (formato aaaa-mm-dd siguiendo las normas generales de anotación en XML). No se trata de un campo para cuatro únicos dígitos a fin de poder reflejar los casos en los que el ejercicio fiscal no coincide con el año civil. El tipo de pago percibido por el beneficiario se anota en los elementos OCDEPaymentType y SpecificPaymentType. Su estructura se rige por las siguientes definiciones de esquema: 8

Código OCDE descriptor de la naturaleza de los pagos:

06 Rentas procedentes de bienes inmuebles

……

21 Otras rentas







……

Fragmento de esquema 2a Tipo para la explicación de un pago por código específico de cierta legislación, por ej., la del país remitente. El archivo OCDE para este esquema está parcialmente constituido por un código “dummy”. El elemento enumerador y la anotación-documentación en el archivo preparado por la OCDE sirven como ejemplo de código específico real en función de la legislación y su documentación.











Fragmento de esquema 2b Para que la descripción de la naturaleza de la renta goce de libertad suficiente puede incluirse el código de pago específico por país/legislación además del código de pago estándar de la OCDE. Un país remitente puede estar interesado en transmitir un código de renta especial que se utilice en su país a fin de describir más adecuadamente el tipo de renta percibida por el beneficiario. En caso de no transmitir tal código no debe utilizarse el elemento SpecificPaymentType. Si a pesar de ello se utilizara, tiene que ser idéntico a este a fin de no anular el documento: 00

Todo país remitente que desee utilizar códigos de pago específicos tiene que proceder a la edición del campo specifictypes_v1.xsd. Este campo contiene los códigos (por país) específicos (en este momento únicamente para tipos de pagos) que difieren de los tipos generales de la OCDE. El atributo specificPaymentTypeQlf que debe fijarse para todos los documentos remitidos por ese país y que depende de este conjunto concreto de códigos de pago, tiene que fijarse en un valor que identifique el código (por ej. código país + año). Después debe procederse al ajuste de la enumeración de los códigos en specifictypes_v1.xsd según las necesidades, debiendo acompañarse de una explicación suficiente del significado de los códigos. En relación con el pago en sí mismo, los elementos son múltiples. Debe tenerse en cuenta que todos ellos responden a un único elemento de renta y que representan diferentes aspectos de este

9

elemento tales como pago bruto, pago neto, impuesto y devolución. El elemento tiene que ser el siguiente en términos de sintaxis XML:

Fragmento de Esquema 3 El calificador del pago (paymentQlf) es el atributo que distingue el bruto, neto, etc., y tiene que responder a una de las categorías: renta bruta pagada “gip” (del inglés “gross income paid); renta neta pagada “nip” (del inglés “net income paid”); impuesto retenido “txh” (del inglés “tax withheld”) o devolución del impuesto “trf” (del inglés “tax refunded”). El tipo impositivo (TaxRate) puede facilitarse de forma opcional en relación con cualquier pago. Los tipos deben consignarse como números decimales, con un total de cuatro dígitos, dos delante y dos detrás del punto que marca los decimales. La fecha de pago puede añadirse a cualquiera de los elementos y designará el día concreto de un pago específico, por ej. el de la devolución. Los importes monetarios en STF se califican siempre mediante un atributo currCode que consiste en el código de moneda ISO 4217 correspondiente a la cifra consignada en el elemento MonAmnt. En aquellos casos en los que sea importante identificar la cuenta en la que se realizó el pago (y se conozca) puede utilizarse el campo al efecto AccInfo que tiene la siguiente estructura:

Fragmento de Esquema 4 Los elementos IBAN, ISIN y SWIFT contienen los identificadores de la cuenta como sus propios nombres indican y su notación responderá al formato estándar del identificador correspondiente. OBAN y OSIN significan “otro número de cuenta bancaria” y “otro número identificador de títulos” respectivamente, y se utilizan en los casos no normalizados; los atributos “acctNoQlf” y “secNoQlf” respectivamente deben utilizarse para indicar el tipo al que responden los números consignados. 5.4 La restante información pertinente para la descripción del caso en cuestión no forma parte del elemento PaymentData sino que se incluye en el elemento OtherInfo. El formato de este elemento no está restringido, pudiendo tener de hecho elementos-hijo o derivados. El remitente tiene que estar seguro de que el receptor será capaz de captar su intención, tanto utilizando identificadores genéricos (tag name) adecuados, como añadiendo explicaciones. Dado que es probable que el documento se procese automáticamente no hay garantía de que el receptor reconozca el contenido, o del momento en que esto ocurre.

10

5.5 La identificación de las partes que intervienen en el pago es vital para que el documento tenga valor. Por tanto, la mayor parte del contenido del documento se dedica a la descripción de las partes. Este proceso es uniforme para todas ellas, en XML: todos los elementos del tipo RecipientBeneficialOwner (perceptor/beneficiario efectivo), ActualPayer (pagador real) etc., son del mismo tipo, Party_Type. Por tanto, es importante familiarizarse con Party_Type. Este es el esquema general:

Imagen 7: Estructura común de todos los elementos que definen a la Parte En todo elemento descriptor de la parte debe aparecer al menos un elemento de nombre y otro de domicilio. Para facilitar un amplio espectro de información descriptiva, el número de tales elementos no está limitado, esto significa que pueden añadirse el nombre de pila, nombre inscrito al nacimiento, etc., así como el domicilio empresarial y otros. La naturaleza de los nombres y direcciones puede indicarse mediante atributos opcionales, los valores admisibles son para los nombres:





[alias u otros]

[persona física]

[alias]

[n. de pila o familiar]

[legal]

[inscrito al nacimiento]

para las direcciones: [residencia o dom. de la actividad]

[residencia]

[domicilio de la actividad]

[razón social]

La mayoría de estos campos se explican por sí mismos, permítasenos aclarar únicamente que aka significa “también conocido como” (del inglés “also known as”); dba significa “que realiza la actividad económica como” (del inglés “doing business as”). SMF AliasOrOther es un valor de atributo que debe utilizarse únicamente si el documento se genera por un programa puente desde un registro SMF. Si hubiera una entrada en el campo “alias u otro” en el registro SMF (un intragrupo al grupo del beneficiario efectivo que figura como “aka”, “dba”, etc.) el

11

programa puente no podrá decidir de qué tipo de nombre se trata y, por tanto, lo interpretará como “SMF AliasOrOther”. Más adelante analizaremos la estructura de nombres y domicilios con detalle. El país de residencia (durante el plazo pertinente), representado en el elemento ResCountryCode por su ISO 3166 código alpha dos-byte, se considera una propiedad de la parte, no un domicilio, aunque lo más probable es que coincida con al menos uno de los códigos de país de residencia de esa parte. Para que sea lo suficientemente general, el elemento debe ser opcional, aún cuando la información recibida sobre alguien con domicilio desconocido difícilmente pueda resultar de ayuda. Otro aspecto importante en la descripción de la parte la constituyen los identificadores formales (que se incluyen en el elemento PartyId), para el que se prevén tres entradas opcionales. La idea que subyace es la de facilitar todo “número” de identificación oficial que el país remitente conozca. Los elementos contenidos en PartyId se anotan como se muestran en el Fragmento de Esquema 5:

Fragmento Esquema 5 El atributo partyIdType sirve para distinguir entre los tipos de identificadores utilizados, por ejemplo el número de identificación fiscal (TIN [del inglés “Tax Identification Number”]), el número de referencia del expediente (TFN [del inglés “Tax File Number”]) y otros. Actualmente TIN, TFN y IdNo están definidos como entradas válidas. Es necesario añadir otro atributo (issuedBy) en el que se anota el organismo que ha emitido el identificador otorgado a la parte. En el caso del TIN será suficiente con el código país del país emisor, en otros casos será preciso recurrir a una entrada no formalizada. Para describir con más precisión a la parte y facilitar su identificación, puede anotarse más información en el elemento PersDat, dependiendo del tipo de parte de la que se trate (persona física o jurídica). Su contenido se refleja claramente en la imagen 8:

12

Imagen 8: Datos adicionales para la identificación de una parte [Para personas físicas, campos: “Género”; “Nacionalidad”; “Fecha de nacimiento”; “Lugar de nacimiento”, “Municipio” y “Código del país de nacimiento” respectivamente y “Fecha de constitución” para personas jurídicas.] En los párrafos siguientes analizaremos cuántos nombres y domicilios pueden manejarse en la estructura del STF destinada a la parte. 5.6 Nombres

Este es un esquema general:

Imagen 9: Estructura del nombre Observe que un nombre puede ser un elemento NameFree, un elemento NameFix o una secuencia de ambos. NameFree se utiliza en las situaciones comunes en las que no resulta totalmente obvio para el país remitente cuáles son las funciones de las distintas partes de la secuencia de palabras que constituyen el nombre de una parte. En tales casos puede resultar mejor dejar al país receptor que las seleccione ya que puede estar más familiarizado con la sintaxis del nombre de la parte. Lo ideal sería, naturalmente, que el nombre de la parte estuviera bien estructurado en partes identificables por el país remitente. Para atender aquellos casos en los que se anota un nombre estructurado (NameFix) pero con algunas dudas sobre la validez de su desglose, el país remitente puede cumplimentar también el campo NameFree.

13

En este momento se están desarrollando los estándares internacionalmente aceptados para la estructura de los nombres. En el caso de las personas físicas STF ha optado por la adhesión –no estricta- al estándar CIQ en el caso de los nombres (CIQ [Calidad de Información sobre el cliente] del inglés “Customer Information Quality”, un estándar de la familia OASIS), que tiene la siguiente estructura:

Imagen 9: Nombre estructurado en STF Todos los elementos de esta estructura son opcionales, dado que no hay garantías de que uno de ellos esté presente en todos los casos. Naturalmente siempre habrá al menos una entrada que resulte útil para la notación del nombre. Siguiendo CIQ, FirstName (nombre de pila o primer nombre) MiddleName (segundo nombre o nombre intermedio), NamePrefix (prefijo del nombre [N. de la T. elemento común a muchos nombres]) y LastName (último nombre), significan exactamente lo que su denominación indica, es decir: la secuencia en el uso “normal”. El significado de, por ejemplo, la primera parte del nombre puede sin embargo variar de un entorno cultural a otro. Por tanto, todos los elementos mencionados deben calificarse mediante un atributo, que se denomina xnlNameType (xnl es el estándar para los nombres en la familia de estándares CIQ). Hasta este momento no se han predefinido valores fijos para xnlNameType, ya que CIQ lo deja al albedrío del usuario, pudiendo utilizarse valores del tipo “Nombre de pila”, “apellido” etc. En el caso de las personas jurídicas siempre se utiliza la forma libre para el nombre; no parece existir una fórmula estándar para el desglose de estos nombres en partes bien definidas.

14

5.7 Domicilios

El nivel más alto de visualización por lo que a los domicilios respecta es:

Imagen 10: Estructura de domicilios Al igual que en el caso de los nombres, los domicilios pueden contar también con un elemento AddressFree o un elemento AddressFix, o la secuencia de ambos. El código del país queda fuera de estas estructuras por tratarse de un campo bien identificable que nunca debe incrustarse (y ocultarse) en una secuencia de caracteres sin formato como en AddressFree. En el caso de los domicilios son válidas las mismas indicaciones: AddressFree se utilizará en aquellas circunstancias habituales en las que el país remitente no conoce exactamente los papeles que desempeñan las distintas partes integrantes de la secuencia de palabras que constituyen el domicilio. Igualmente, en tales casos puede resultar mejor dejar al país receptor que las seleccione ya que puede estar más familiarizado con la sintaxis del domicilio de la parte. Lo ideal sería, naturalmente, que el domicilio de la parte estuviera bien estructurado en partes identificables por el país remitente. Para atender aquellos casos en los que se anota un domicilio estructurado (AddressFix) pero con algunas dudas sobre la validez de su desglose, el país remitente puede cumplimentar también el campo AddressFree. En este momento se están desarrollando los estándares internacionalmente aceptados para la estructura de los domicilios. Para STF se ha optado por imitar el estándar CIQ en relación con los domicilios, como se hizo con los nombres. Sin embargo, se observó que xAL, el estándar de domicilios dentro de CIQ, obtiene su extrema flexibilidad y amplio espectro de aplicación mediante un cierto grado de complejidad que no resulta adecuado para el STF. Esta decisión de diseño se marcó como “para control”, en función de que la difusión de la utilización de xAL en los países miembros de la OCDE indujera a reconsiderar su diseño. Por el momento, los domicilios en formato fijo se estructuran como sigue en STF:

15

Imagen 11: Estructura del domicilio en STF [Calle, Identificación del edificio, Identificación del piso/apartamento/despacho, Identificación de la planta, Nombre del distrito, Apartado de correos, Código postal, Ciudad, Municipio, respectivamente] El único elemento imprescindible en esta estructura es el nombre de la ciudad. Los restantes componentes se facilitarán en la medida en que se disponga de ellos. 6. ¿Dónde puede encontrarse una referencia detallada sobre todos los elementos y su contenido? La fuente principal de soporte en relación con el STF es el conjunto de esquemas STF XML. En ellos puede encontrarse una referencia para la práctica totalidad de los elementos importantes y sobre los tipos de datos. En muchos casos consisten simplemente en una réplica de los comentarios a los campos SMF del manual SMF. Dado que los esquemas XML no son legibles prima facie para no expertos en informática, e incluso para ellos puede resultar tedioso encontrar un dato preciso en un esquema muy largo, se han extraído los comentarios de los esquemas mediante un procedimiento automatizado, y se ha generado un “Manual electrónico” en formato HTML. De este modo, los usuarios pueden obtener información dirigiendo su navegador a la URL precisa (o su espejo en el cibersitio del país). El Manual electrónico contiene dos columnas de información. La columna izquierda está constituida por un listado de los elementos y atributos que constituyen el documento más amplio STF_OCDE de acuerdo con el esquema. La columna derecha contiene las anotaciones de todos los tipos de datos definidos. Hay dos tipos de interactividad disponibles: al pasar el cursor del ratón por encima de un elemento de la columna izquierda aparecen comentarios con categorización jerárquica referidos a ese elemento. Al pinchar sobre los elementos de la columna izquierda, a mano derecha aparecen comentarios relativos al tipo de datos del elemento (no en todos los elementos aparecen comentarios al pasar el cursor, ni tampoco todos los tipos de datos posibles contienen comentarios que aparezcan al pinchar sobre ellos.

16

La imagen estructural (columna izquierda) de un documento STF en el Manual electrónico no puede reproducir íntegramente toda la estructura de información de los esquemas. Por ejemplo, no contiene indicaciones sobre si los elementos son opcionales u obligatorios. En caso de necesitar la imagen completa, debe acudirse al esquema en sí mismo (anexo 1) o al diagrama global del anexo 2. Para los usuarios que tengan conocimientos de TI y quieran tener documentación exhaustiva pueden acceder también a una documentación generada en HTML que comprende todo lo contenido en los esquemas, pero cuya lectura resulta más fácil que los códigos de esquema en sí mismos. En el anexo 3 se adjunta una versión en Word. Para evitar la acumulación de páginas, los listados de códigos de país y de moneda se han reducido en las versiones impresas de forma que contengan únicamente unos pocos ejemplos. 7. ¿Cómo se garantiza la coexistencia entre el SMF y el STF? Aún cuando el XML es el estándar aceptado en todo el mundo para la transmisión de datos entre sistemas, y muchos países miembros de la OCDE cuentan con políticas de administración electrónica que utilizan el XML como estándar preferente, los países con un entorno SMF en funcionamiento pueden ser reacios a invertir recursos en la migración al STF. Por otro lado, los países que quieran introducir medios automáticos para el intercambio internacional de información en materia tributaria en este momento, probablemente no desearán utilizar metodologías que reflejan la situación de las TI en la década de los 90. Para solventar esta situación transitoria se han confeccionado programas puente que transforman los registros SMF en documentos STF_DIRECT y viceversa. Estos programas son transformaciones XSL y tienen los nombres explicativos smf2stf stf2smf Obviamente se entenderá que ni la OCDE ni los autores de los programas puente pueden considerarse responsables de los errores que contengan, o de las consecuencias que de ellos puedan derivarse. La oferta de estos programas responde al deseo de facilitar la migración, y la responsabilidad de su uso y de los datos intercambiados recae en el usuario. Por tanto, el código de transformación incluye una cláusula de exoneración de responsabilidad. THIS TRANSFORMATION HAS BEEN WRITTEN AND TESTED WITH CARE. THERE WILL BE, HOWEVER, NO GUARANTEE WHATSOEVER REGARDING ITS CORRECTNESS. ANYONE USING THIS TRANSFORMATION WILL DO THIS UNDER HIS OR HER OWN RESPONSIBILITY AND BEFORE USING IT WILL HAVE TO TEST IT AS CONSIDERED NECESSARY. NO LIABILITY WILL BE ACCEPTED BY OECD, THE OECD TIES GROUP, OR THE AUTHORS OF THIS TRANSFORMATION FOR ANY DIRECT OR INDIRECT DAMAGE THAT MAY RESULT FROM USING THIS TRANSFORMATION. THIS TRANSFORMATION MAY BE USED AND CHANGED FREELY IF AND ONLY IF THESE CONDITIONS ARE ACCEPTED.

[Esta transformación se ha escrito y probado meticulosamente. No obstante, no hay plena garantía de que esté libre de errores o defectos. Todo usuario asume la responsabilidad de su uso y, antes de proceder a ello deberá probarlo tanto como considere necesario. La OCDE, el Grupo TIES de la OCDE (Grupo de trabajo sobre tecnologías de la información) o los autores de esta transformación no aceptan responsabilidad alguna en relación con los daños directos o indirectos que pudieran derivarse de su uso. La utilización e intercambio de este mecanismo de transformación es libre únicamente con la aceptación de estas condiciones.]

17

Debe señalarse que, en gran parte debido a la escasa implantación del STF en comparación con el SMF, el puente resulta posible en casi el 100 por cien de los casos, aunque no llega a ese porcentaje exactamente. En los párrafos siguientes se explican los hechos observados. I. Puente de SMF a STF 7.0 El puente puede hacerse tanto desde el lado del envío como del de la recepción del archivo SMF. Ambas posibilidades tienen sus ventajas y desventajas. El puente desde la fuente permite al país remitente validar el archivo STF resultante con los esquemas y filtrar así cualquier irregularidad que se produzca en el proceso. El remitente podrá manejar con más facilidad el archivo que ha escrito, por lo que podrán evitarse algunos problemas relativos a su posibilidad de lectura cuando se transmita un archivo STF con cifrado UTF-8. Sin embargo, también implica que el país remitente tiene que tener en cuenta los países que utilizan el STF. Mientras que el STF no sea el formato principal lo más adecuado parece ser dejar a las partes que intervienen en el intercambio que decidan cuál de ellas realiza el puente. 7.1 El puente se hace vía Transformación XSL. Dado que estas transformaciones operan en archivos XML, la labor preliminar consiste en convertir el archivo SMF en XML. El programa de transformación espera el conjunto de datos introducido (input) envuelto en etiquetas de elemento raíz tipo “SMFFile”, “/SMF” y registros en los elementos “Record” (registro), es decir, cada registro tiene que estar inmerso en una etiqueta “Record”, “/Record”. Asimismo, dependiendo de la transformación, puede ser necesario insertar al principio una instrucción de procedimiento

donde pppp deba reemplazarse por la ruta al archivo de transformación. Puede ocurrir también que el código de transformación desde el cifrado principal, preferiblemente a UTF-8, tenga que hacerse antes del XSL. Este paso puede ser bastante directo pero debe hacerse dependiendo de la situación concreta del cibersitio del Estado miembro y el archivo SMF, por lo que no lo soporta el sistema puente de la OCDE. 7.2 Los archivos SMF no precisan de un equivalente en el encabezado del mensaje STF “MessageSpec”, por lo que estos archivos no contienen una fuente desde la que generar automáticamente el elemento “MessageSpec”. Por tanto, la persona que prepare la aplicación del programa puente tiene que introducir los datos pertinentes en el código XSL antes de proceder a la transformación. A continuación se muestra parte del XSL que tiene que adaptarse: Country Code Country Code Legal Information Who to contact for this message list of tax year ends in form: 2002-12-31

7.3 En SMF, los registros de referencia de remisión previa (para corrección o en caso de repetición) se cumplimentan únicamente en el nivel del registro, por lo que no hay archivo de identificación del mensaje en SMF. Por tanto, en los archivos STF generados a partir de SMF, la adaptación entre registros no puede basarse en la combinación de identificadores de mensaje e identificadores de documento. Se recomienda, por tanto, no atribuir identificadores de

18

mensaje a los mensajes STF generados a partir de archivos SMF (el elemento MessadeRefld tiene que permanecer en la secuencia, vacío, a fin de mantener la validez del documento). Esta circunstancia no debe afectar a la combinación, aún cuando no sea posible referirse al mensaje por un identificador ambiguo. 7.4 Si en relación con el beneficiario efectivo se introdujera un dato en el registro SMF en el grupo de campos “AliasOrOther”, se generaría un elemento derivado “Nombre” en el elemento “RecipientBeneficalOwner” del STF con el valor “SMFAliasOrOther” para el atributo “nameType”. 7.5 Se perderán las entradas en el grupo de campos “In Care Of Person” del SMF (parece que nunca nadie ha utilizado este rasgo del SMF). 7.6 Si en el registro SMF hubiera, por error, entradas para el nombre o domicilio distintas de “0” para formato fijo y “1” para formato libre, el programa puente asumirá que el contenido de los siguientes campos está en formato libre y los transformará en consecuencia. 7.7 Si en SMF se consigna el género ”M” (para varón) o ”F” (para mujer) del beneficiario efectivo, en STF se generará un elemento derivado “PersData” del elemento beneficiario efectivo con esa información y con la información referida a la ciudad de nacimiento si esta estuviera presente en SMF. La entrada “N” (no persona física) no generará un elemento “PersData”, dado que tiene que tener un contenido obligatorio que, sin embargo, no está disponible en SMF. II.

Puente de STF a SMF

7.8. Un documento STF puede generar identificadores múltiples de las partes para todas las partes consignadas, puede tratarse de números de identificación fiscal, pero también pueden ser otros tipos de identificadores. Supuestamente, SMF únicamente cuenta con los números de identificación fiscal como identificadores, por lo que los demás identificadores que contenga el documento STF se perderán en la transformación. Para todas las partes el SMF cuenta con dos campos TIN (número de identificación fiscal) junto con los campos correspondientes para los códigos de país que identifican al Estado emisor del TIN. En el caso del beneficiario efectivo se da una situación especial, dado que el SMF requiere expresamente que el primer TIN (y el primer código de país) pertenezcan al país de residencia y el segundo al país de fuente. El programa puente hace lo siguiente: - Si el elemento RecipientBeneficialOwner contiene un elemento ResCountryCode, el primer campo para TIN tras la transformación contendrá una única entrada si existe un único elemento TIN PartyId para el beneficiario efectivo con ese código de país como el atributo issuedBy (emitido por). El segundo campo para TIN del registro creado con la transferencia contendrá los datos de otro elemento TIN PartyId para el beneficiario efectivo (si lo hubiera), pero no se ejecutará el test respecto a su pertenencia al país de la fuente; - Si por el contrario el elemento RecipientBeneficialOwner no contiene un elemento ResCountryCode (opcional en STF) los campos destinados al TIN del resultado tras la conversión contendrán los datos relativos a uno de los dos elementos TIN PartyId (en la medida en que existan en el documento STF).

19

7.9 Un documento STF puede contener múltiples nombres para todas las partes. Los SMF pueden tener dos nombres (incluido “alias or other”) para el propietario / beneficiario efectivo y un único nombre para las demás partes. Al hacer la transformación, el campo de nombre principal para el beneficiario efectivo se rellena con el primer nombre STF que aparezca sin atributo nameType o cuando este sea “legal” (persona jurídica) o “individual” (persona física). Quedará en blanco si no existe ese elemento (es decir, cuando todos los elementos de nombre sean tipo “aka”, “dba”, etc.). Los elementos de nombre que excedan de dos (para el beneficiario efectivo) o de uno (para todas las demás partes) se pierden en la conversión con la única excepción del elemento de Nombre con el atributo de nameType “at birth” (inscrito al nacimiento). Estos nombres se agregan al nombre que contiene el campo principal de nombre con el añadido “at birth”. También se perderá uno de los nombres en caso de que se consigne una forma libre y otra fija (concretamente la fija). 7.10 Un documento STF puede contener elementos de PaymentDate (fecha de pago) para cada elemento de pago. El SMF contiene un único campo para fecha de pago. Este campo queda cumplimentado con el elemento de pago en el que el valor del atributo paymentQlf sea “gip” (renta bruta pagada [del inglés “gross income paid”]), siempre que exista ese elemento y contenga una fecha de pago (que es opcional para todos los pagos). Si con esto no quedara cumplimentado el campo, la siguiente fuente de datos sería el elemento de pago “nip” (renta neta pagada [del inglés “net income paid”]). En caso de que los elementos gip y nip no contuvieran fechas, este campo quedará en blanco en el registro SMF. 8. Ejemplos de Elementos y Mensajes 8.1 Ejemplos del elemento MessageSpec: del más simple al más complejo Only to be used in conformance with our Agreement [Advertencia: se utilizará únicamente de conformidad con nuestro convenio]

Rosalie Sender mailto: [email protected]

123123

2004-12-31

GB US Please do not use this [Advertencia: por favor no utilice este campo] Mark Anthony phone 007 135 791 1234567 1999-04-05 2002-04-05

8.2 Dos ejemplos del elemento DocSpec: uno encabezando un documento “nuevo” y otro modificando un documento enviado anteriormente (documento 1000001) en el mensaje correspondiente al primer MessageSpec anterior) 1 987654 2 5656565 123123 1000001

20

8.3 Ejemplos de elementos de Nombre Elemento de nombre en formato libre perteneciente a una persona física que constituye una parte Arndt Liesen

Elemento de nombre en formato libre correspondiente a una persona jurídica Arndt Liesen IT consultancy and training Incorporated

Elemento de nombre en formato fijo correspondiente a una persona física AU 47 Kingston Avenue North

21

Block 2, Rippon Building

Suite 1A

Level 12

North Ryde

NSW



8.5 Ejemplos de elementos de tipo de Parte Elemento de Parte correspondiente a un beneficiario efectivo constituido por una persona física DE 777666555 Arndt Liesen





DE

Mystreet 77

77777

Mycity









M

DE

1939-04-16

Duisburg - Germany



Un elemento de Parte pagadora (ejemplo de domicilio adaptado de un ejemplo del estándar OASIS CIQ) JP 1234567 The very big Payer of Income from Interest Inc.





JP Japan 530-0001 Osaka Prefecture Oasaka City North Ku Plum Rice Field 1-2-2 the 2nd Building before the Oasaka Station

8.6 Ejemplos de elementos de PaymentData En 2003 se efectuó un pago de intereses brutos (tipo de pago OCDE nº 11) por valor de 2.000€ 2003-12-31 11 2000

22

En el ejercicio concluido el 5 de abril de 2001 se efectuaron los siguientes pagos en concepto de “Participaciones de consejeros” (tipo de pago OCDE nº 16), calificados con más precisión como tipo de pago específico de país “P47a” de acuerdo con un esquema de clasificación denominado “UK2001”: - pago bruto de 4.000 libras - reducido a un pago neto de 2.000 libras - seguido por una devolución de 1.000 libras 2001-04-05 16 P47a 2000-06-31 4000 2000-06-31 2000 2000-09-10 1000

En este caso el archivo de esquema para códigos de pago específicos por países, countryspecifictypes_v1.xsd, debería haberse editado como sigue: … Tipo para explicación de un pago por código que es específico para el RU (versión

de 2001)

-

Los códigos especiales utilizados son S20 intereses de depósitos extremadamente grandes ... P47a retribuciones para consejeros de salas de fiesta

- ...

….



….



8.7. Mensaje completo que contiene dos documentos para diferentes ejercicios fiscales, partiendo del supuesto de que uno de ellos es una corrección de un documento previamente enviado

23

US DE Only to be used in conformance with our Agreement Rosalie Sender mailto: [email protected] US20023-4 2003-12-31 2002-12-31





1

987654

DE 32/001/47133 123456433 Her Excellency Ms Mary R de Smith II PhD Retired





Mary the Belle





Marie Dupont





DE Friedhofstrasse 1 53225 Bonn





F FR 1937-08-13 Paris Montmartre FR





DE



The Mary the Belle Trust DE 53221 Bonn





US

99999999



Grey Dancers Great Performances

24



US



100 Broadway

NewYork

NY







2003-12-31

17



2003-07-06

7100





Please report back on matching with a real person



2

564534

US10001-7

561212



DE



The Big Earners Partnership





DE

Somewhere in Frankkfurt, Germany







US

124534



First Banking for Nothing





US 77 Gold Avenue, Las Vegas, Nevada

2002-01-01









2002-12-31

11

11-11



2002-01-02

900000001

30.5



2003-03-15

100000000

US-special income type 11-11 is interest from doubtful source

25

9. ¿Con qué dispositivos cuenta el STF? Los siguientes dispositivos están disponibles en formato electrónico en (Insertar URL). 9.1 Este Manual introductorio y sus apéndices STFexplained.doc

STFexpl-app1-schemas.doc

STFexpl-app2-diagram.png

STFexpl-app3-tecdocu.doc

9.2 El archivo de esquema STF stfdirect-1.0.xsd

stftypes-1.0.xsd

isotypes_v1.xsd

oecdtypes_v1.xsd

specifictypes_v1.xsd

9.3 Los programas de conversión (hojas de estilo XSL) stf2smf-1.0.xsl smf2stf-1.0.xsl 9.4. El manual electrónico en html (estructura jerárquica con vínculos a notas) STFmanual.html (el documento principal contiene tres marcos)

STFhead.html

STFstru.html

STFdoc.html

9.5. La documentación íntegra generada para el esquema-sistema en html stf-1.0-generatedDocu.html

stf-1.0-generatedDocu_pxx.png (93 png-archivos para su uso por stf-1.0­ generatedDocu.html)

26