Artículos

La FCA busca comentarios sobre las mejoras al mecanismo de almacenamiento nacional


Publicado el 6 de septiembre de 2024 por Editor

La Autoridad de Conducta Financiera (FCA) del Reino Unido ha abierto una consulta para recabar opiniones sobre las mejoras propuestas al Mecanismo Nacional de Almacenamiento (NSM). El NSM, similar al sistema EDGAR de EE. UU. o al EDINET de Japón, es el repositorio central de toda la información de las empresas reguladas en el Reino Unido.

La FCA tiene como objetivo mejorar la calidad de los datos del NSM y la experiencia del usuario, convirtiéndolo en una fuente más confiable de información corporativa.

La consulta se centra en abordar los desafíos actuales con el NSM, en particular los metadatos incompletos o inexactos asociados con los documentos presentados, como los identificadores de entidad jurídica (LEI) del emisor y la categorización. Estos problemas pueden dificultar que los usuarios localicen información relevante. Para abordar esto, la FCA propone estandarizar la recopilación de metadatos, implementar controles de calidad de datos más estrictos y simplificar la recuperación de información. Los cambios clave incluyen la introducción de un esquema estandarizado y un mecanismo de transmisión para los proveedores de información primaria (PIP), la actualización de los códigos de encabezado y la eliminación de la necesidad de clasificar los documentos.

Estas mejoras propuestas forman parte de una iniciativa más amplia de la FCA para modernizar los mercados primarios del Reino Unido mediante la actualización de las normas de cotización y las regulaciones comerciales. Los cambios tienen como objetivo mejorar la transparencia y fortalecer los mercados mayoristas del país al garantizar que el NSM pueda servir como un repositorio más eficiente y preciso para las divulgaciones corporativas.

El período de consulta está abierto hasta el viernes 27 de septiembre de 2024. Se anima a las partes interesadas a que aporten sus comentarios sobre cómo estos cambios propuestos podrían afectar la funcionalidad y la accesibilidad del NSM. La FCA planea considerar todos los comentarios antes de publicar las reglas finales en la segunda mitad de 2024, y se espera que los nuevos requisitos entren en vigor en la segunda mitad de 2025.

Para obtener más detalles o participar en la consulta, visite el sitio web de la FCA o contáctelos directamente en mdip@fca.org.uk.

Divulgación FCA NSM UK


CP24/17: Fortalecimiento del mecanismo nacional de almacenamiento

08/09/2024

27/09/2024

Documentos de consulta: Primera publicación: 08/09/2024 – Última actualización: 27/08/2024 

Estamos consultando sobre propuestas para cambiar los requisitos para presentar información regulada al Mecanismo Nacional de Almacenamiento (NSM).

Leer CP24/17 (PDF)

¿Por qué estamos consultando?

Queremos introducir requisitos de datos más exhaustivos para mejorar la funcionalidad del NSM. Esto facilitará a los usuarios del NSM la búsqueda de información presentada por emisores de mercados regulados.

También proponemos un requisito para que los proveedores de información primaria (PIP) utilicen un método estándar para enviar información al NSM.

Para quién es esto

  • Emisores con valores admitidos a negociación en mercados regulados del Reino Unido y PIP que difunden y presentan información regulada para ellos.
  • Inversores, analistas y otros participantes del mercado que utilizan el NSM.
  • Personas que hayan solicitado la admisión a negociación en un mercado regulado de valores mobiliarios de un emisor, sin el consentimiento del emisor.

Próximos pasos:

Formulario de respuesta en línea

Por favor, responda a esta consulta antes del viernes 27 de septiembre de 2024.

Responda utilizando nuestro formulario en línea o alternativamente envíe un correo electrónico a: cp24-17@fca.org.uk.

Tomaremos en cuenta sus comentarios y planeamos publicar nuestras reglas finales a fines de 2024. Proponemos que los requisitos de transmisión de datos para los PIP y los requisitos de metadatos para los emisores entren en vigencia en la segunda mitad de 2025.

Antecedentes:

El NSM es nuestro archivo en línea de información de empresas, de uso gratuito, y es utilizado por inversores, analistas y otros participantes del mercado.

A nivel internacional, la mayoría de las jurisdicciones cuentan con un servicio como el NSM. Sin embargo, las limitaciones actuales en el control de calidad y la estructura de los datos implican que los metadatos enviados al NSM pueden ser inconsistentes e incompletos. Esto puede dificultar que los usuarios encuentren la información que necesitan.

Esta consulta es parte de nuestra iniciativa más amplia para mejorar la funcionalidad del NSM, que respaldará otras iniciativas del mercado primario.


Capítulo 1

Resumen

¿Por qué estamos consultando?

1.1          El Mecanismo Nacional de Almacenamiento (NSM) es nuestro archivo en línea de uso gratuito de información de la empresa. Permite a los usuarios acceder y descargar información sobre los emisores. El NSM desempeña un papel importante en la regulación de los mercados primarios. Su desarrollo ulterior podría mejorar significativamente el NSM en beneficio de los participantes en el mercado del Reino Unido. Este documento incluye una visión general de nuestros planes para mejorar el NSM, que es un contexto importante para nuestras propuestas de consulta.

1.2          Estamos consultando sobre propuestas para cambiar los requisitos de datos del NSM para la «información regulada», que es la información divulgada por los emisores del mercado regulado de acuerdo con las Reglas de Transparencia y Guía de Divulgación (DTR), las Reglas de Cotización y partes del Reglamento de Abuso de Mercado (MAR). También proponemos estandarizar la forma en que los Proveedores de Información Primaria (PIP), empresas aprobadas por nosotros para difundir información regulada en nombre de los emisores, envían información al NSM.

1.3          Los PIP publican divulgaciones regulatorias y nos las envían para que las almacenemos de forma permanente en el NSM. Cuando la información regulada se publica y luego se presenta ante el NSM, debe incluir ciertos atributos de datos (metadatos), como el nombre del emisor, una categorización y una clasificación. Los usuarios de NSM pueden buscar información utilizando campos que correspondan a estos metadatos. Sin embargo, los metadatos suelen estar incompletos y/o ser inexactos. Esto se debe a las limitaciones heredadas en el control de calidad de los datos y la estructura de los datos. Esto puede dificultar que los usuarios de NSM encuentren información.

1.4          Los cambios propuestos nos permitirán implementar controles de calidad de datos mejorados y facilitar a los usuarios de NSM la búsqueda de información regulada.

1.5          Esta consulta forma parte de una iniciativa más amplia para mejorar la funcionalidad del NSM, que se sumará a otros cambios en el mercado primario, incluida nuestra reciente revisión de las Reglas de Cotización y la introducción del régimen de Regulaciones de Ofertas Públicas y Admisiones a Negociación, sobre el que actualmente estamos consultando (véanse CP24/12 y CP24/13). En conjunto, estas reformas nos ayudarán a cumplir nuestro compromiso de fortalecer los mercados mayoristas al garantizar que los inversores tengan acceso a la información correcta.

¿A quién se aplica esta consulta?

1.6          Los cambios propuestos afectarán a los emisores con valores admitidos a negociación en los mercados regulados del Reino Unido y a los PIP que difunden y presentan información regulada en su nombre.

1.7          Los inversores, analistas y otros participantes del mercado que utilizan el NSM para encontrar información regulada estarán interesados en esta consulta porque nuestras propuestas están destinadas a mejorar la experiencia del usuario del NSM.

1.8          Por último, las personas que hayan solicitado, sin el consentimiento del emisor, la admisión a negociación de los valores mobiliarios del emisor en un mercado regulado se verá afectadas de la misma forma que los emisores.

Lo que queremos cambiar

1.9          Queremos introducir requisitos de metadatos más completos para mejorar la funcionalidad del NSM facilitando a los usuarios del NSM la búsqueda de información regulada. En concreto, proponemos ampliar los requisitos para la presentación de identificadores de personas jurídicas (IPJ) y actualizar parte de la información principal que se utiliza para categorizar la información regulada.

1.10       Estos requisitos propuestos se basan en los cambios de norma que consultamos en la CP16/39, que dieron lugar al requisito del DTR 6.2.2A R (1) de proporcionarnos el IPJ del emisor en cuestión cuando se nos presente información regulada.

1.11       También proponemos el requisito de que todos los PIP utilicen el mismo esquema estándar y la misma interfaz de programación de aplicaciones (API) para enviar información al NSM. Esto producirá un intercambio y procesamiento de datos más rápido y estandarizado, lo que nos permitirá implementar mejores controles de calidad de los datos.

Resultados que buscamos

1.12       Queremos implementar un marco de gobernanza de datos para mejorar la precisión y la relevancia de los metadatos que se envían al NSM. Esto garantizará que los usuarios de NSM puedan localizar más fácilmente los envíos futuros al NSM.

1.13       Exigir que todos los PIP utilicen el mismo esquema estándar y API producirá un intercambio y procesamiento de datos más rápidos y estandarizados y nos permitirá introducir controles de calidad de datos mejorados.

1.14       La normalización también reducirá el riesgo de incompatibilidades del sistema que podrían provocar retrasos en el cumplimiento de las obligaciones de presentación por parte de los emisores y en la capacidad de los usuarios del MEN de acceder a la información.

1.15       Esperamos que nuestras propuestas tengan algunos costos para los emisores y los PIP, con costos únicos más altos para los PIP. Sin embargo, la mejora de la capacidad de búsqueda y la accesibilidad de la información en el NSM debería dar lugar a un beneficio continuo de reducción de los costos de búsqueda para los usuarios. En el Anexo 2 se ofrece un análisis más detallado de los costos y beneficios.

Medir el éxito

1.16       Mediremos el éxito de nuestros cambios a través de:

• Análisis de la calidad e integridad de los metadatos que se incluyen con las presentaciones regulatorias.

• Cambios en el número de usuarios de NSM y el número de visitas al sitio web de NSM como medida indirecta de la percepción y la utilidad del NSM.

• Encuestas de seguimiento para evaluar la experiencia del usuario de NSM.

Pasos siguientes

1.17       Esta consulta cierra el viernes 27 de septiembre de 2024. Las respuestas pueden enviarse a través del formulario de nuestro sitio web o por correo electrónico a cp24-17@fca.org.uk. Si responde por correo electrónico, indique si desea que su respuesta se trate como confidencial y, por separado, si está de acuerdo con ser nombrado como demandado.

1.18       Tendremos en cuenta todos los comentarios y tenemos previsto publicar nuestras reglas finales a finales de 2024.

1.19       Proponemos que los requisitos de transmisión de datos para los PIP y los requisitos de metadatos entren en vigor en el segundo semestre de 2025.

Capítulo 2

El contexto más amplio

Promoción de la transparencia del mercado

2.1          El acceso a información precisa y completa sobre los emisores promueve la transparencia del mercado y permite a los inversores tomar decisiones de inversión informadas. Esto mejora la eficiencia del mercado y la protección de los inversores, lo que respalda nuestro objetivo estratégico de garantizar el buen funcionamiento de los mercados relevantes.

2.2          La promoción de la transparencia del mercado es también un resultado estratégico fundamental de nuestro compromiso público de reforzar la posición del Reino Unido en los mercados mayoristas mundiales.

2.3          Una forma en que fomentamos la transparencia del mercado es exigir a los emisores y a otros participantes del mercado que publiquen información regulada y la archiven con nosotros para su almacenamiento permanente en el NSM.

El propósito del NSM

2.4          El NSM es nuestro archivo en línea de uso gratuito de información de la empresa, que incluye información regulada divulgada por o en relación con emisores de mercados regulados de acuerdo con los DTR, las Reglas de cotización y los artículos 17 a 19 del MAR.

2.5          En la actualidad, el NSM cuenta con más de 4,2 millones de entradas, con aproximadamente medio millón de nuevas propuestas cada año. El NSM es utilizado por inversores, analistas y otros participantes del mercado. Recibe aproximadamente 11.000 visitas cada mes.

2.6          El NSM se estableció en 2009 de conformidad con la Directiva de Transparencia, que exige a los Estados miembros de la UE que establezcan un Mecanismo Designado Oficialmente (OAM) para almacenar información regulada. Inicialmente, subcontratamos este requisito a un proveedor externo y lo incorporamos internamente en 2020.

2.7          Casi toda la información del NSM se recibe de los PIP, que actúan en nombre de los emisores del mercado regulado y otras personas que están sujetas a nuestros requisitos de presentación. Los PIP están aprobados y regulados por la FCA con el fin de difundir anuncios regulatorios a los operadores de medios de comunicación y presentar esos anuncios ante nosotros para su almacenamiento permanente en el NSM.

2.8          Los PIP también difunden y presentan información al MEN en nombre de los emisores cuyos valores están admitidos a negociación en otros tipos de mercados, como los sistemas multilaterales de negociación (SMN). Aunque los emisores de SMN están obligados a divulgar información de conformidad con el MAR, sus presentaciones al NSM no son información regulada a los efectos del DTR 6. Como se señala en los párrafos 21 a 23 del Anexo 2 de este documento, tenemos previsto añadir requisitos de metadatos a los términos de uso del NSM para todos los tipos de información que se presenten al NSM. Estos requisitos serán coherentes con nuestras normas para la información regulada.

2.9          El NSM también contiene documentos clave de la empresa que son cargados directamente por el emisor o la persona sujeta a nuestros requisitos de presentación. Por ejemplo, el anuncio de los resultados financieros de un emisor se difunde a través de un PIP y se presenta ante nosotros, pero el informe financiero subyacente es cargado directamente en el NSM por el emisor. Esto garantiza que los usuarios de NSM tengan acceso tanto al anuncio como al documento subyacente.

2.10       Del mismo modo, cargamos ciertos tipos de documentos (por ejemplo, folletos) en el NSM después de haberlos aprobado.

2.11       Como se ilustra en la figura siguiente, el NSM es un repositorio de información de la empresa que está a disposición de la industria de la información, así como de los usuarios finales de dicha información.

2.12       El NSM establece:

• Un registro permanente: la información del NSM se conserva para el registro de forma permanente. La información que publican las empresas es importante y los participantes del mercado y el público tienen muchas razones para necesitar acceder a los registros históricos sobre los emisores. Aunque las empresas mantienen información y documentos clave en sus sitios web, existe el riesgo de que esa información eventualmente no esté disponible si las empresas son absorbidas o dejan de operar.

• Una pista de auditoría digital: la regulación del mercado primario se centra en gran medida en la divulgación y la transparencia. Cuando los reguladores imponen obligaciones de divulgación a las empresas, es necesario poder verificar que la información se ha publicado realmente y que existe un acceso público razonable a ella. También será necesario saber con precisión cuándo se produjo la publicación. El NSM proporciona evidencia clara, objetiva y con marca de tiempo de que un artículo ha sido publicado. También otorga a los participantes en el mercado el mismo acceso a la información en su forma original sin editar.

• Un centro digital: en los últimos años se han adoptado informes corporativos legibles por máquina a través del requisito de que los emisores relevantes informen de las cuentas financieras anuales en formato iXBRL y con los elementos clave de divulgación en el informe marcados con etiquetas. Esperamos que el alcance de este informe aumente. Depositar estos informes en un solo lugar mejora la adopción y el uso de la tecnología. Esto beneficia a los usuarios directos de esta información y a la industria de la información, que probablemente sean los principales usuarios de esta aplicación. A su vez, los beneficios para la industria de la información se trasladan a sus clientes e inversores.

2.13       Vinculado a la finalidad del MEN está su alcance, es decir, la gama de información que contiene. Como se señaló anteriormente, el NSM contiene más que solo información regulada. Actualmente no tenemos planes de modificar este alcance. Sin embargo, esperamos que un NSM mejorado desempeñe un papel más importante en los mercados de capitales primarios del Reino Unido, momento en el que podríamos considerar ampliar los tipos de información que contiene.

Cómo se relaciona con nuestros objetivos

Integridad del mercado

2.14       Las propuestas que figuran en el presente documento de consulta tienen como objetivo principal avanzar en nuestro objetivo operativo de proteger y mejorar la integridad del sistema financiero del Reino Unido, lo que incluye la transparencia del proceso de formación de precios en los mercados financieros del Reino Unido. Los cambios propuestos mejorarán la funcionalidad del NSM, facilitando la búsqueda de información sobre los emisores con valores admitidos a negociación en los mercados regulados del Reino Unido.

Objetivo secundario de competitividad y crecimiento internacional

2.15       Consideramos que nuestras propuestas cumplen con nuestro objetivo secundario de competitividad y crecimiento internacional porque están concebidas para promover la transparencia del mercado. Esto debería aumentar la confianza y la reputación de los mercados regulados del Reino Unido, ya que los inversores tendrán más confianza en poder acceder fácilmente a la información regulada para fundamentar sus decisiones de inversión. Hemos tenido en cuenta la alineación con los estándares internacionales al diseñar las mejoras para el NSM. Esperamos que esto contribuya a la competitividad de los mercados financieros del Reino Unido.

Efectos más amplios de esta consulta

2.16       Instalaciones como el NSM son una característica de la regulación de los mercados primarios a nivel internacional. Cada estado miembro de la UE tiene un OAM, y el sistema de recopilación, análisis y recuperación electrónica de datos (EDGAR) de la SEC es el más notable a nivel mundial y desempeña un papel importante en los mercados de capitales de EE. UU.

2.17       Tenemos previsto mejorar significativamente el NSM convirtiéndolo en una instalación más parecida a EDGAR en importancia e impacto. Un mecanismo ampliado y mejorado podría apoyar la modernización y el desarrollo de los mercados de capitales del Reino Unido. Observamos que en el informe de septiembre de 2023 de la City of London Corporation «Visión para el crecimiento económico: una hoja de ruta hacia la prosperidad» se pedía la creación de una versión británica de EDGAR.

2.18       Si se llevan a cabo en su totalidad, nuestras mejoras en el NSM establecerán las instalaciones del Reino Unido como una fuente de información empresarial reconocida a nivel mundial. Apoyará firmemente nuestra labor política en el marco de los regímenes de cotización y folletos y contribuirá a la competitividad de los mercados de capitales del Reino Unido. Por ello, la mejora de la instalación forma parte de nuestra apuesta por el fortalecimiento de los mercados mayoristas.

2.19       Nuestros planes cubren el desarrollo en 3 fases, como se muestra en la Figura 2.

Fase 1

2.20       Corregir la calidad y la accesibilidad de los datos 2 Mejorar la experiencia del usuario y cambiar la marca de la instalación 3 Funcionalidad añadida, por ejemplo, análisis Los usuarios de NSM pueden buscar información utilizando campos que corresponden a los metadatos proporcionados con las divulgaciones que se presentan ante el NSM. Sin embargo, hemos observado que la instalación exhibe una mala calidad de datos, por ejemplo, cientos de miles de artículos sin suficientes metadatos que identifiquen a la parte a la que se refiere el artículo. Esto puede dificultar que los usuarios encuentren divulgaciones.

2.21       La primera fase de nuestro plan incluye la corrección de las entradas existentes en el NSM que tienen metadatos incompletos o inexactos. Este trabajo, que estamos llevando a cabo actualmente, se centra principalmente en añadir IPJ, que son un identificador global único para las personas jurídicas y las personas físicas que actúan a título empresarial

2.22       Las propuestas que figuran en este documento también pretenden formar parte de la primera fase de nuestro plan. Para los emisores y otras personas que están obligadas a presentar información regulada de conformidad con los DTR 6.2 y 6.3, proponemos requisitos de información de IPJ más exhaustivos, categorías de titulares adicionales en el DTR 8 y la eliminación de las clasificaciones en el Anexo 1 al DTR 6 (véanse los capítulos posteriores a continuación para obtener más detalles).

2.23       Los requisitos de metadatos propuestos mejorarán la calidad de las presentaciones y, en combinación con la corrección de datos, mejorarán la usabilidad del MEN y conducirán a una mayor transparencia del mercado.

2.24       En la actualidad, cada PIP utiliza un esquema de datos y un método de intercambio de datos diferentes para enviarnos información. Proponemos que los PIP transmitan datos al NSM a través de una API que utilice un esquema estándar. Esto nos permitirá implementar controles de calidad de datos mejorados para garantizar que los envíos al NSM cumplan con nuestras reglas.

Fase 2

2.25       En la segunda fase, tenemos la intención de seguir teniendo en cuenta los comentarios de nuestra reciente encuesta a los usuarios de NSM. Por ejemplo, planeamos habilitar la descarga masiva de información desde el NSM. Para mejorar la experiencia del usuario, planeamos observar cómo se distribuyen las pantallas de destino clave, reconociendo que muchos usuarios quieren buscar emisores específicos y ver la información que tenemos para esa empresa. Este tipo de mejoras dependen de completar la primera fase de nuestro plan. También tenemos la intención de cambiar la marca de las instalaciones.

Fase 3

2.26       Para abordar aún más los comentarios de los usuarios, tenemos la intención de realizar mejoras adicionales en la interfaz de usuario del NSM, que pueden incluir la introducción de herramientas analíticas.

Lo que no estamos haciendo

2.27       Es igualmente importante señalar que nuestros planes para el NSM no pretenden:

• Compita con los PIP: el NSM no está diseñado para la divulgación en tiempo real. Aunque la información publicada por los PIP se archiva en el NSM y aparece en él con relativa rapidez, se trata de una divulgación casi en tiempo real, no en tiempo real. Los PIP desempeñan un papel valioso en la autenticación de quienes realizan divulgaciones y aumentan la seguridad y la resiliencia de la arquitectura de información general. También existe competencia entre los PIP: los que divulgan información pueden elegir qué PIP utilizar en función del precio y la calidad del servicio.

• Competir con la industria de la información: como se muestra en la Figura 1, el NSM es una fuente y un recurso potencial para la industria de la información, como los proveedores de datos de mercado, no un competidor. Una vez que nuestro sistema se mejore para permitir descargas a gran escala, la capacidad de la industria de la información para absorber la información de NSM le ayudará a llevar datos y productos de información de valor agregado al público.

• Duplicados de Companies House u otros registros corporativos: el alcance y el propósito de nuestra regulación de mercados primarios difiere significativamente de los de Companies House y de los registros corporativos en el extranjero. Un número significativo de empresas no británicas acceden a los mercados del Reino Unido y, por lo tanto, están sujetas a nuestra regulación de mercados primarios.

Pregunta 1:

¿Está de acuerdo con el propósito del NSM y nuestros planes para mejorarlo? ¿Tiene algún comentario sobre la oportunidad de mejorar los mercados de capitales del Reino Unido a través del desarrollo del NSM por parte de la FCA, incluida la gama de información que contiene?

Consideraciones ambientales, sociales y de gobernanza

2.28       Al elaborar este documento de consulta, hemos tenido en cuenta las implicaciones medioambientales, sociales y de gobernanza (ESG) de nuestras propuestas y nuestro deber en virtud de los artículos 1B (5) y 3B(c) de la FSMA de contribuir a que el Secretario de Estado logre el cumplimiento del objetivo de cero emisiones netas en virtud del artículo 1 de la Ley de Cambio Climático de 2008 y los objetivos medioambientales en virtud del artículo 5 de la Ley de Medio Ambiente de 2021. En general, no consideramos que nuestras propuestas sean pertinentes para contribuir al logro de esos objetivos. Mantendremos este tema bajo revisión durante el transcurso del período de consulta y cuando consideremos si hacer las reglas finales.

2.29       Mientras tanto, acogemos con beneplácito sus aportaciones a esta consulta al respecto.

Consideraciones sobre la igualdad y la diversidad

2.30       Hemos examinado las cuestiones de igualdad y diversidad que pueden plantearse en las propuestas de este documento de consulta.

2.31       En general, no consideramos que las propuestas afecten significativamente a ninguno de los grupos con características protegidas en virtud de la Ley de Igualdad de 2010 (en Irlanda del Norte no se promulga la Ley de Igualdad, pero se aplican otras leyes contra la discriminación). Sin embargo, continuaremos considerando las implicaciones de igualdad y diversidad de las propuestas durante el período de consulta y las revisaremos al hacer las reglas finales.

2.32       Mientras tanto, acogemos con beneplácito sus aportaciones a esta consulta al respecto.

Capítulo 3

Requisitos de metadatos

3.1          En este capítulo se exponen los cambios propuestos en los requisitos de metadatos para los emisores y las personas que están sujetas a los requisitos de DTR 6.2 y 6.3.

Identificador de personas jurídicas (IPJ) y nombre de la organización

Antecedentes

3.2          Un IPJ es un código alfanumérico de 20 caracteres que es un identificador global único. La Global Legal Entity Identifier Foundation (GLEIF) es responsable de supervisar la calidad de los datos del IPJ y la integridad del sistema del IPJ.

3.3          Un IPJ puede utilizarse para buscar información a través de una base de datos de libre acceso que se actualiza a diario. Los IPJ pueden emitirse a personas jurídicas y a personas físicas que actúen a título empresarial, pero no pueden ser utilizados por personas físicas que actúen a título privado o como empleados, incluso si están autorizados por un regulador financiero.

3.4          El uso de IPJ fue respaldado por el foro intergubernamental del Grupo de los 20 (G20) en 2012 para apoyar a las autoridades y a los participantes del mercado en la identificación y gestión de riesgos financieros. Desde entonces, los IPJ se han convertido en una característica de varios regímenes regulatorios dentro del sector de los servicios financieros. Por ejemplo, los IPJ son necesarios para la notificación de operaciones de derivados a los Registros de Operaciones de conformidad con el Reglamento de Infraestructura de Mercados Europeos del Reino Unido. Del mismo modo, los DTR ya exigen a los emisores de mercados regulados que nos faciliten su IPJ al presentar información regulada.

Requisito existente

3.5          DTR 6.2.2A R(1) actualmente requiere que un emisor o persona sujeta a DTR 6.2.2 R nos notifique el IPJ del emisor en cuestión. Consultamos e introdujimos el DTR 6.2.2A R en el entendimiento de que el requisito de presentación de IPJ en el DTR 6.2.2A R(1) obligaría a los emisores a obtener un IPJ.

Requisitos propuestos

3.6          Proponemos modificar y ampliar el requisito del DTR 6.2.2A R (1) exigiendo a los emisores y a las personas sujetas al DTR 6.2.2 R que nos notifiquen el nombre y el IPJ del emisor en cuestión, el nombre y el IPJ de la persona que presenta la información regulada (si es diferente) y el nombre y el IPJ (si están disponibles) de cualquier emisor relacionado que sea objeto de la divulgación.  si los emisores relacionados están involucrados o no en la presentación de la información regulada.

3.7          Los cambios propuestos permitirán a los usuarios de NSM utilizar búsquedas basadas en metadatos para encontrar información regulada sobre un emisor, incluso si la información fue enviada por otra parte. Los usuarios de NSM también podrán buscar a personas, distintas de los emisores, que estén sujetas a DTR 6.2.2 R, para encontrar las presentaciones que hayan realizado.

3.8          Además de los IPJ, nuestras propuestas incluyen el requisito de que nos faciliten los nombres de las partes pertinentes. Esta aclaración es necesaria porque los metadatos presentados al MEN no siempre incluyen el nombre del emisor en cuestión.

3.9          En la siguiente tabla se compara el requisito de presentación de IPJ existente en DTR 6.2.2A R(1) con los requisitos de presentación de IPJ que proponemos. En los diferentes escenarios: el emisor A es el «emisor afectado» en DTR 6.2.2A R(1); La persona A es una persona que ha solicitado, sin el consentimiento del emisor A, la admisión a negociación de valores mobiliarios del emisor A en un mercado regulado; y el emisor B es un emisor relacionado que es uno de los sujetos de la presentación pero que no participa en la presentación de la información regulada.

3.10       Para respaldar los nuevos requisitos de presentación, también proponemos ampliar el requisito de obtener un IPJ a las personas que hayan solicitado, sin el consentimiento del emisor, la admisión de los valores mobiliarios del emisor a cotización en un mercado regulado. Este cambio de norma también hace explícito el requisito actual de que los emisores tengan un IPJ.

3.11       También proponemos que el requisito de obtener un IPJ significa tener un IPJ con un estado de registro de «emitido» según la GLEIF. El estado de registro de «emitido» significa que el IPJ está actualizado y es válido. Este requisito ayudará a los usuarios de NSM a encontrar información regulada sobre una entidad específica y garantizará que los metadatos enviados estén actualizados.

3.12       Somos conscientes de que, en determinadas circunstancias, puede que no sea proporcionado o posible que quienes divulgan información faciliten IPJ. Hemos considerado los siguientes escenarios:

• No hay IPJ disponible. Reconocemos que los declarantes de información regulada no deben ser considerados responsables de garantizar que los emisores relacionados tengan un IPJ «emitido». Por lo tanto, aquellos que presenten la información regulada ante nosotros solo necesitan proporcionar IPJ para emisores relacionados en los que la información de IPJ esté disponible en la GLEIF.

•Fondos. Más de 2,4 millones de entradas de NSM provienen de fondos que informan valores de activos netos. Reconocemos que muchas de estas divulgaciones se realizan a diario e incluyen referencias a varios fondos o subfondos diferentes que informan en una sola divulgación. Dada la carga potencial de proporcionar un IPJ para cada fondo o subfondo relacionado individual, proponemos que los requisitos de presentación de IPJ para los emisores relacionados sean opcionales para los fondos que informan valores de activos netos.

Pregunta 2:

¿Está de acuerdo con nuestra propuesta de modificar y ampliar el requisito del DTR 6.2.2A para que exija al declarante de la información regulada en virtud del DTR 6.2.2 R que nos proporcione su nombre y LEI y el nombre y el LEI de cualquier emisor relacionado?

Pregunta 3:

¿Está de acuerdo con nuestra propuesta de exigir que los emisores y las personas sujetas al DTR 6.2.2 R mantengan un IPJ con un estado de registro de «emitido» según la GLEIF?

Pregunta 4:

¿Está de acuerdo en que el requisito de presentación de IPJ propuesto en relación con los emisores relacionados debería ser opcional a la hora de informar sobre los valores de los activos netos?

Clasificaciones DTR

3.13       DTR 6.2.2A R (2) actualmente requiere que aquellos que presentan información regulada nos notifiquen las clasificaciones relevantes para la información regulada utilizando las clases y subclases en DTR 6 Anexo 1 R. Estas clasificaciones indican el tipo de información regulada que se divulga.

3.14       Los comentarios de las partes interesadas externas nos dicen que las clasificaciones no son útiles y, por lo tanto, la carga creada por DTR 6.2.2A R (2) es desproporcionada. De acuerdo con este punto de vista, nuestro análisis identificó que las clasificaciones no se incluyeron en los metadatos de casi el 75% de las entradas de NSM que examinamos.

3.15       Proponemos que se elimine el requisito del DTR 6.2.2A R (2) y que se eliminen el DTR 6.2.2B R y el DTR 6 Anexo 1 R.

Pregunta 5:

¿Está de acuerdo con nuestra propuesta de eliminar el requisito en DTR 6.2.2A R (2) de notificar a la FCA las clasificaciones relevantes para la información regulada utilizando las clases y subclases en DTR 6 Anexo 1 R, y eliminar DTR 6.2.2B R y DTR 6 Anexo 1 R?

Códigos de titulares y categorías

3.16       DTR 8.4.23 R y 8.4.24 R actualmente requieren que los PIP incluyan los códigos principales y las categorías relevantes del DTR 8 Anexo 2 R en la información regulada que difunde el PIP.

3.17       Cuando la información difundida se envía al NSM, las categorías, que son otro conjunto de metadatos, están destinadas a ayudar a los usuarios a localizar la información dentro del NSM.

3.18       Algunas de las descripciones de las categorías están desactualizadas o no son claras. Esto conduce a un etiquetado inconsistente de la información regulada e incertidumbre entre los usuarios de NSM sobre qué categorías usar al buscar información regulada. Como parte de nuestro compromiso con las partes interesadas, también hemos identificado la necesidad de nuevos códigos y categorías de titulares.

3.19       Por lo tanto, proponemos una serie de modificaciones de los códigos y categorías principales del Anexo 2 R del DTR 8.

3.20       También proponemos una nueva enmienda al DTR 6.2.2A R para exigir que la información regulada presentada por un emisor o persona sujeta al DTR 6.2.2 R también incluya los códigos de titulares y las categorías pertinentes del DTR 8 Anexo 2 R. Esto garantizará que toda la información regulada presentada al NSM incluya los metadatos relevantes.

Pregunta 6:

¿Está de acuerdo con las enmiendas propuestas a los códigos de titulares y las categorías de titulares en el Anexo 2 R del DTR 8? ¿Hay otros códigos que sugeriría que agreguemos o códigos que podríamos eliminar?

Pregunta 7:

¿Está de acuerdo con nuestra propuesta de exigir que todas las presentaciones al NSM de acuerdo con DTR 6.2.2 R incluyan los códigos de encabezado y las categorías de encabezado relevantes del DTR 8 Anexo 2 R?

Información proporcionada a los PIP

3.21       Para ayudar a garantizar que los PIP reciban los metadatos relevantes, proponemos enmiendas al DTR 6.3.7 R para exigir que la información regulada comunicada a los PIP identifique claramente los nombres, los IPJ y la información principal relevantes.

Pregunta 8:

¿Está de acuerdo con nuestra propuesta de exigir que la información regulada se comunique a los PIP de una manera que identifique claramente los nombres, los IPJ y la información principal relevantes?

Pregunta 9:

Con respecto a las propuestas expuestas en el capítulo 3 de este documento de consulta, ¿está de acuerdo con nuestra propuesta de implementar los requisitos de metadatos propuestos en el segundo semestre de 2025?

Capítulo 4

Requisitos para los PIP

4.1          En este capítulo se exponen los requisitos propuestos para que los PIP utilicen un esquema estándar y una API para realizar envíos al NSM. También proponemos enmiendas a la lista de organismos reguladores que están exentos de ser cobrados por la difusión de información regulada.

Esquema y API

4.2          Las PIP representan más del 90% de la información presentada al NSM. En la actualidad, cada PIP utiliza un esquema y un método de intercambio de datos diferentes con la FCA, lo que requiere una solución técnica a medida para cada PIP. Proponemos introducir el requisito de que los PIP utilicen un esquema estándar y un método de transmisión de datos basado en una API. Expondremos los detalles de esto en una nota técnica como guía de la FCA (consulte el Apéndice 2).

4.3          Somos conscientes de que esto conducirá a cambios en la forma en que los PIP cumplen con sus obligaciones. Sin embargo, consideramos que los cambios tienen varios beneficios:

• Un esquema estándar nos permite implementar controles de calidad de datos mejorados.

• Las API permiten un intercambio y procesamiento de datos más rápidos y estandarizados.

• La estandarización proporciona más claridad a los PIP y a los posibles PIP sobre nuestras expectativas para la presentación de divulgaciones. Esto ayudará a los nuevos participantes en los PIP y fomentará la competencia entre ellos.

• Reducción del riesgo de incompatibilidades con nuestros sistemas, lo que podría provocar retrasos tanto en el cumplimiento de las obligaciones de presentación por parte de los emisores como en el acceso a la información por parte de los usuarios de NSM.

4.4          Reconocemos que los PIP difunden información a otras organizaciones, como los operadores de medios de comunicación. El esquema y el método de transmisión que proponemos se refieren únicamente al suministro de información al NSM, lo que deja a los PIP la libertad de elegir cualquier método para la difusión de información sujeto a los requisitos existentes en el DTR 8.

Pregunta 10:

¿Está de acuerdo con nuestra propuesta de exigir a todos los PIP que utilicen una API y un esquema especificado por la FCA para la transmisión de información al NSM?

Organismos reguladores

4.5          Los PIP deben difundir información regulada que les haya sido proporcionada por cualquiera de los organismos reguladores enumerados en el DTR 8 Anexo 1 R. Los PIP no están autorizados a cobrar a los organismos reguladores enumerados por la difusión de información regulada.

4.6          Algunos de los organismos reguladores enumerados en el DTR 8 Anexo 1 R ya no existen. También hemos identificado los organismos reguladores que deben añadirse a la lista. En consecuencia, proponemos varias enmiendas a la lista de organismos reguladores en el DTR 8 Anexo 1 R.

Pregunta 11:

¿Está de acuerdo con las enmiendas propuestas al DTR 8 Anexo 1 R?

Pregunta 12:

Con respecto a las propuestas expuestas en el capítulo 4 de este documento de consulta, ¿está de acuerdo con nuestra propuesta de implementar los requisitos propuestos en el segundo semestre de 2025?

La orientación de esta Nota Técnica complementa el DTR 8.4.30R sobre la presentación de información regulada por parte de los PIP.

El propósito de esta Nota Técnica es guiar a los PIP en el cumplimiento de sus obligaciones de proporcionar información regulatoria. Los PIP deben leer esta Nota Técnica junto con DTR 8. Reglas

Nuestro sitio web también ofrece más información sobre las especificaciones técnicas del sistema.

Nuestro enfoque para la transmisión y el intercambio de datos

DTR 8.4.30R requiere que los PIP proporcionen de forma gratuita toda la información regulada que difunden a la FCA.

El sistema de presentación del Mecanismo Nacional de Almacenamiento (NSM) de la FCA utiliza una interfaz segura de máquina a máquina para intercambiar datos. Los PIP necesitan consumir API para enviar los archivos de anuncio y los metadatos relacionados. La información regulada deberá ser presentada por los PIP utilizando archivos XML estandarizados para los cuales la FCA proporcionará las definiciones de esquema XML (XSD). Todos los mensajes intercambiados usarán un cuerpo de mensaje JSON con XML como archivo adjunto.

La FCA facilita las validaciones de nivel de archivo y contenido en relación con cada presentación de PIP para garantizar que los datos presentados se alineen con los esquemas acordados y puedan procesarse. Los comentarios sobre los resultados de la validación y el estado del procesamiento de datos se pondrán a disposición de los PIP a través de una solicitud de API. Si falta un campo obligatorio, o no se cumplen los requisitos de calidad de los datos y, en consecuencia, la información enviada por el PIP no pudo ser procesada, el PIP podrá ver los comentarios correspondientes y organizar el reenvío de la información.

Los PIP y la FCA podrán intercambiar datos a través de 3 puntos finales de API:

• La primera API será una API de autenticación, que requiere que el PIP proporcione credenciales en el encabezado de la API. El ID de cliente y el secreto de cliente serán compartidos de forma segura a su debido tiempo por la FCA. Solo las direcciones IP incluidas en la lista de permitidos de los sistemas PIP podrán conectarse a las API de NSM. Una vez que NSM procese y autentique la solicitud, se generará un token de autenticación y se proporcionará como respuesta al PIP.

• A continuación, el PIP puede utilizar la segunda URL de API utilizando el token de autenticación proporcionado en la primera respuesta de API. Esta solicitud de API debe contener los metadatos en un cuerpo JSON con un anuncio XML como archivo adjunto. La respuesta de NSM será un acuse de recibo y un ID de comentarios único.

• La tercera URL de la API proporciona el estado de procesamiento y los resultados de validación de los archivos enviados, ya sea para un envío específico o para un grupo de envíos. La solicitud de API debe realizarse mediante un esquema JSON, según lo definido por la FCA.

Tabla: Requisitos de datos y normas de calidad



Cómo lograr un aterrizaje suave – Una perspectiva histórica de los ciclos de política monetaria


25 de septiembre de 2024

Por: Ema Ivanova, Thomas McGregor, Stefano Nardelliy Annukka Ristiniemi

Las opiniones expresadas en cada entrada del blog son las de los autores y no representan necesariamente las opiniones del Banco Central Europeo ni del Eurosistema.

La tarea de los bancos centrales es ayudar a la economía a sortear los shocks y encaminar la inflación hacia el objetivo. En esta entrada del blog del BCE se plantea qué podemos aprender de los ciclos de política monetaria anteriores sobre cómo controlar la inflación y, al mismo tiempo, lograr un aterrizaje suave de la economía.

La economía es un poco como un avión, y los bancos centrales son un poco como sus pilotos. Ajustan sus instrumentos de política para guiar a sus economías a través de turbulencias, shocks y crisis, con el objetivo de aterrizar suavemente en su destino: la estabilidad de precios. Cuando la inflación es demasiado alta, los bancos centrales aumentan las tasas de interés para desacelerar la economía y reducir la inflación. Así como los pilotos calculan su aproximación y comienzan el descenso hacia su destino final, las autoridades deben juzgar cuándo comenzar a relajar las tasas de política para alcanzar su meta de inflación y lograr un aterrizaje suave para la economía. Y, al igual que los pilotos reales, pueden aprender de experiencias anteriores para mejorar su forma de responder a condiciones difíciles y aumentar las posibilidades de lograr un aterrizaje suave.

Esto es precisamente lo que hemos hecho, analizando un total de 48 ciclos de política monetaria en nueve economías diferentes a lo largo de un período de 50 años (un promedio de cinco ciclos por país).[3]De estos 48 “vuelos”, aproximadamente un tercio terminaron en aterrizajes suaves, es decir, la inflación volvió a su nivel objetivo en dos años sin que la economía entrara en recesión. Entonces, ¿qué factores determinan la brusquedad del vuelo y la suavidad con la que el avión aterriza en la pista?

El ciclo típico de la política monetaria

Los ciclos de política monetaria son episodios en los que las tasas de política monetaria suben rápidamente desde un nivel mínimo o estable hasta alcanzar un máximo local, antes de mantenerse en ese nivel o de volver a disminuir hasta un nuevo mínimo. En nuestra muestra, los bancos centrales han tendido a aumentar las tasas de política monetaria en alrededor de 20 puntos básicos por mes antes de mantenerlas en su altitud de crucero durante ocho meses y luego recortarlas en 38 puntos básicos por mes durante el descenso. Al comienzo de los ciclos de ajuste, la inflación promedió 2,8%, el crecimiento del PIB 5,9% y el desempleo 6,6%. En el momento del primer recorte de tasas, la inflación era, en promedio, incluso más alta, 4,1%, mientras que el crecimiento disminuyó marcadamente, en promedio, a 2,8% (Cuadro 1). Esto pone de relieve una importante conclusión de nuestro análisis: los bancos centrales han tendido a comenzar a relajar la postura de política monetaria con la inflación todavía relativamente alta, posiblemente impulsados ​​por preocupaciones sobre la disminución del crecimiento y los riesgos para la estabilidad financiera. Resulta que los ciclos de política monetaria exitosos tienden a caracterizarse por una caída del crecimiento en torno al momento del primer recorte de tasas, seguida de una fuerte recuperación económica y una caída de la inflación durante los dos años siguientes (gráfico 1). En los episodios de aterrizaje suave, esta desaceleración del crecimiento allana el camino para una caída de la inflación. Los aterrizajes duros, por otro lado, se caracterizan por recortes de tasas en medio de recesiones profundas, sin que haya casi ninguna diferencia en los resultados de inflación en comparación con los aterrizajes suaves.

Tabla 1

Condiciones macroeconómicas promedio en el momento del primer recorte de tasas en los ciclos de política monetaria de los principales bancos centrales

* La muestra completa incluye los 48 ciclos de política monetaria de nueve bancos centrales desde 1970.

Gráfico 1

Inflación y crecimiento a lo largo del ciclo de política

(variación porcentual interanual basada en datos mensuales)

Choques y crisis: ciclos fallidos

No todos los ciclos lograron reducir la inflación a la meta. Definimos como ciclos exitosos aquellos en los que la inflación vuelve a la meta dentro de los dos años siguientes al inicio del primer recorte de tasas. Con base en esta clasificación, los bancos centrales tuvieron éxito en poco menos de un tercio de los casos, mientras que en los casos restantes la inflación se mantuvo significativamente por encima de la meta dos años después del inicio de la flexibilización de la política monetaria o terminó por debajo de la meta.

Los shocks de oferta, como los repentinos aumentos de los precios del petróleo en los años setenta, fueron uno de los factores que más probablemente provocaron el fracaso de los ciclos de política monetaria. Ante los shocks de oferta, los bancos centrales aumentaron las tasas de interés más rápidamente (23 puntos básicos por mes) que, en otros episodios, pero también se vieron obligados a reducirlas más rápidamente (42 puntos básicos por mes) y en mayor medida (510 puntos básicos de recortes) a medida que aumentaban los costos económicos y el sector financiero se veía sometido a tensiones. Más del 70% de los ciclos de shocks de oferta en nuestra muestra terminaron en una recesión o una crisis financiera. Como resultado, las tasas de política cayeron sustancialmente por debajo de sus niveles iniciales durante esos ciclos. El período promedio de tenencia también fue más corto, alrededor de 7,5 meses. El desafiante entorno macroeconómico creado por los shocks de oferta se refleja en los datos. En el momento del primer recorte de tasas, la inflación promediaba típicamente alrededor del 6,1%, con un crecimiento de alrededor del 2,1% y un desempleo del 5,5%.

Hay tres factores que generalmente diferencian los ciclos de políticas exitosos de los que no lo son (gráfico 2). En primer lugar, los mejores resultados en materia de inflación se correlacionan con condiciones iniciales más favorables, como una inflación más baja y un mayor crecimiento económico. En segundo lugar, el crecimiento tiende a ser menor, tanto en las fases de ajuste como de flexibilización, en los episodios exitosos en comparación con los que no lo son. Y en tercer lugar, los ciclos fallidos suelen caracterizarse por tasas reales bajas, si no negativas, en las que la inflación es más alta que las tasas de interés. Vale la pena señalar que cuatro de los ciclos de nuestra muestra terminaron con el inicio de la pandemia de COVID-19, lo que explica, por ejemplo, la pronunciada caída del crecimiento del PIB poco después del primer recorte de tasas en el momento t=0.

Gráfico 2

Comparación de ciclos de flexibilización exitosos con niveles de inflación por debajo y por encima de los límites

(puntos porcentuales de las tasas de política monetaria, variación porcentual interanual de la inflación y el crecimiento con base en datos mensuales)

Aterrizaje suave: ciclos exitosos

Los aterrizajes suaves son poco frecuentes y suelen ser más fáciles de lograr en teoría que en la práctica. ¿Por qué, entonces, son tan difíciles de lograr? Requieren un cuidadoso equilibrio entre dos fuerzas que empujan en direcciones opuestas: desacelerar la economía lo suficiente para que la inflación vuelva a la meta, sin ir demasiado lejos y desencadenar una recesión. Este equilibrio es más fácil de lograr en condiciones macroeconómicas propicias.

Esto se refleja en los datos. Casi todos los aterrizajes suaves están asociados a shocks de demanda, lo que sugiere que los shocks de oferta son más difíciles de sortear. También se caracterizan por períodos de mantenimiento más largos, de alrededor de nueve meses en promedio, un ritmo más lento de recortes de tasas, de 29 puntos básicos por mes, y tasas de interés reales más altas en el momento del primer recorte en comparación con los episodios de aterrizajes duros. Esto sugiere que los ajustes bruscos de política tienen menos probabilidades de tener éxito que los ciclos en los que los ajustes se realizan de manera más gradual.

Los aterrizajes suaves suelen producirse cuando el pico de inflación es más bajo, en particular en el caso de la inflación básica (inflación general excluyendo componentes volátiles como los alimentos y la energía). Otros factores son que el desempleo aumenta sólo modestamente, las pérdidas del mercado de valores siguen siendo limitadas y las expectativas de inflación se mantienen bien ancladas (gráfico 3). Los aterrizajes bruscos, por otra parte, suelen ir de la mano de una crisis financiera, una desaceleración prolongada del crédito a las empresas y los hogares y un alto desempleo, incluso cuando se recortan agresivamente las tasas. Estos recortes tampoco suelen producir una diferencia significativa en los resultados de la inflación.

Gráfico 3

Indicadores macroeconómicos clave en ciclos de flexibilización exitosos

(variación porcentual interanual de la inflación, el crecimiento y el crédito; porcentaje de desempleo; variación porcentual interanual del promedio móvil de tres meses de los precios de las acciones)

El comportamiento de las expectativas de inflación es otro factor que distingue entre aterrizajes duros y suaves. Si los bancos centrales son creíbles, las expectativas de inflación deberían permanecer bien ancladas durante todo el ciclo de política monetaria. Resulta que, en los aterrizajes duros, las expectativas de inflación a largo plazo disminuyen entre el comienzo de la fase de ajuste y el comienzo de la fase de flexibilización. Esto probablemente refleja el hecho de que los bancos centrales a menudo se ven obligados a aplicar medidas de flexibilización por shocks adversos o una economía en rápida desaceleración. No ocurre lo mismo en los aterrizajes suaves, en los que las expectativas tienden a permanecer notablemente estables durante todo el ciclo.

¿Qué significa esto para el ciclo actual?

De la misma manera que los pilotos deben vigilar las condiciones atmosféricas a lo largo de su trayectoria de vuelo, los bancos centrales deben evaluar la trayectoria de la inflación y las condiciones macroeconómicas prevalecientes, ajustando sus instrumentos para garantizar que la inflación vuelva a la meta en el momento oportuno y minimizando el daño a la economía. Como nos han demostrado los ciclos de política monetaria anteriores, los shocks de oferta son un desafío clave porque hacen más difícil combatir la inflación y al mismo tiempo lograr un aterrizaje suave. Los bancos centrales generalmente han subido agresivamente las tasas en respuesta a los shocks de oferta. Las tasas también se redujeron antes en las fases inflacionarias, y más rápidamente, posiblemente en respuesta a un debilitamiento de las perspectivas de crecimiento y a una disminución de las expectativas de inflación. Estas respuestas pasadas no llevaron a aterrizajes suaves en el pasado.

Hoy, el BCE se enfrenta a un conjunto singular de desafíos. La inflación general se disparó hasta un máximo histórico del 10,6% en octubre de 2022, impulsada por una combinación de shocks de oferta, la dinámica de reapertura tras la pandemia, factores geopolíticos adversos y cambios estructurales. En respuesta, el BCE elevó los tipos de interés oficiales en 450 puntos básicos a lo largo de 15 meses y los mantuvo así durante nueve meses antes de recortarlos por primera vez en junio de 2024. Como resultado, la inflación ha disminuido rápidamente y las últimas proyecciones prevén que vuelva al objetivo del 2% en el segundo semestre de 2025. Y aunque la economía se estancó entre el segundo semestre de 2022 y finales de 2023, el crecimiento se ha reanudado en el primer semestre de este año. Además, el desempleo está cerca de mínimos históricos y, aunque los riesgos para la estabilidad financiera siguen contenidos, las tensiones geopolíticas son una fuente importante de riesgo. Todos estos son signos positivos que indican que se evitará un aterrizaje brusco en el ciclo actual a menos que se produzcan nuevos shocks adversos en la economía.



Aumentar la resiliencia en materia de ciberseguridad con los nuevos productos DORA


Publicado el 26 de julio de 2024 por Editor

El 17 de julio, las Autoridades Europeas de Supervisión (ABE, EIOPA y ESMA) publicaron un segundo lote de productos de políticas en virtud de la Ley de Resiliencia Operativa Digital (DORA). Este paquete integral incluye cuatro borradores finales de normas técnicas regulatorias (RTS), un conjunto de normas técnicas de implementación (ITS) y dos directrices, todos diseñados para reforzar la resiliencia operativa digital del sector financiero de la UE.

Las nuevas regulaciones se centran en mejorar el marco de presentación de informes sobre incidentes relacionados con las TIC, introducir requisitos de pruebas de penetración basadas en amenazas y delinear el diseño del marco de supervisión.

Las iniciativas de la ESA se alinean con esfuerzos más amplios para aumentar la resiliencia en materia de ciberseguridad, especialmente a la luz de incidentes recientes como el error de software CrowdStrike Falcon, que causó importantes interrupciones en las TI a nivel mundial. Este incidente subraya la necesidad crítica de contar con una resiliencia cibernética sólida y capacidades de respuesta ante incidentes. A medida que las empresas dependen cada vez más de sistemas de TI complejos, la importancia de mantener la continuidad operativa y salvaguardar los datos se vuelve primordial.

El episodio de CrowdStrike sirve como un duro recordatorio de que incluso los fallos menores de software pueden tener consecuencias de gran alcance. Por lo tanto, la implementación de los requisitos de DORA es oportuna, con el objetivo de garantizar la prestación continua e ininterrumpida de servicios financieros en toda la UE. El marco regulatorio mejorado enfatiza las medidas proactivas, como las pruebas periódicas y la mejora de los informes de incidentes, para mitigar los riesgos cibernéticos de manera efectiva.

Las ESA ya han adoptado las directrices, mientras que el proyecto final de normas técnicas se ha presentado a la Comisión Europea para su revisión. Estas medidas contribuirán significativamente a la resiliencia y la seguridad del sector financiero, haciendo frente a las ciberamenazas actuales y emergentes.

Para obtener más detalles sobre los nuevos productos de políticas bajo DORA, consulte aquí, y para obtener más información sobre CrowdStrike, consulte aquí.

Ciberseguridad DORA ESAS Resiliencia


La interrupción de CrowdStrike y Microsoft revela importantes problemas de resiliencia

En el punto de mira: control de calidad, resiliencia empresarial y puntos únicos de fallo

Mathew J. Schwartz

• 19 de julio de 2024

Cualquiera que pudiera dudar de hasta qué punto las empresas dependen de los sistemas de TI no necesita más que observar cómo un pequeño fallo en el software de ciberseguridad Falcon de CrowdStrike ha provocado una disrupción global. Algunos dicen que tal vez no sea solo la mayor disrupción de TI de este año, sino la mayor de la historia.

Los expertos dicen que el incidente es un recordatorio de que todas las empresas, independientemente de que utilicen o no una marca particular de software de seguridad, necesitan mantener una sólida confianza empresarial y capacidades de respuesta a incidentes, ya que pueden ocurrir cortes de TI inesperados en cualquier momento (ver: Bancos y aerolíneas afectados por corte masivo en PC con Windows).

Se espera que CrowdStrike, que cotiza en bolsa, enfrente preguntas difíciles de inversores, reguladores y clientes sobre sus prácticas de prueba y gestión de cambios, así como preguntas más amplias sobre los proveedores de software, los puntos únicos de falla y si los sistemas operativos necesitan mejores defensas contra el software que se comporta mal.

Basta con observar el impacto de esta falla de software, que provocó que muchas PC con Windows mostraran una «pantalla azul de la muerte» y se reiniciaran en un bucle imparable. Las interrupciones resultantes provocaron la cancelación de procedimientos hospitalarios, aviones y trenes; dejaron a los clientes sin poder acceder a aplicaciones bancarias o pagar en persona en algunas tiendas con tarjetas de crédito; impidieron que los principales medios de comunicación transmitieran noticias en vivo; y mucho más.

«No creo que sea demasiado pronto para decirlo: será la mayor interrupción de TI de la historia», dijo el experto australiano en ciberseguridad y violación de datos Troy Hunt en una publicación en la plataforma social X. «Básicamente, esto es lo que nos preocupaba a todos con el Y2K, excepto que esta vez realmente sucedió».

Aun así, los accidentes ocurren y los analistas de Wall Street dijeron que esperan que este episodio tenga poco o ningún impacto a largo plazo en la reputación o el valor de las acciones de CrowdStrike. Las acciones de CrowdStrike cayeron 38,09 dólares por acción, o un 11%, a 304,96 dólares al cierre del mercado el viernes.

El director ejecutivo de CrowdStrike, George Kurtz, apareció en NBC News el viernes por la mañana para disculparse. «Lo sentimos profundamente», dijo, y atribuyó la interrupción al fallo en el código que se envió a algunos clientes a través de las actualizaciones automáticas de software de la empresa. «Esa actualización tenía un error de software y provocó un problema con el sistema operativo de Microsoft».

«Lo de hoy no fue un incidente de seguridad ni cibernético», dijo Kurtz en una declaración a Information Security Media Group. «Nuestros clientes siguen estando completamente protegidos. Entendemos la gravedad de la situación y lamentamos profundamente los inconvenientes y las interrupciones. Estamos trabajando con todos los clientes afectados para garantizar que los sistemas vuelvan a funcionar y puedan prestar los servicios con los que cuentan sus clientes».

CrowdStrike afirmó que había corregido el fallo y había comenzado a distribuir la solución a través de actualizaciones de software automáticas. Los administradores afirman que esto ha solucionado el problema en algunos equipos, servidores y servidores virtuales afectados. El proveedor también ha instado a todos los clientes a que estén atentos a su portal de soporte y se pongan en contacto con los representantes de la empresa.

Aun así, varios administradores de TI han informado que han tenido que reparar manualmente sistemas físicos que se han quedado atascados en un bucle de reinicio. Como resultado, reparar todos los sistemas afectados podría llevar una cantidad considerable de tiempo, a menos que CrowdStrike o quizás Microsoft puedan ofrecer formas más automatizadas de solucionar el problema.

Numerosos administradores de TI afirman que han despejado su agenda para trabajar durante el fin de semana. Muchos prevén tener que acudir al lugar de trabajo para recuperar manualmente cualquier PC atascado en un bucle de reinicio, y la clasificación sigue siendo la orden del día. «Las organizaciones deberán priorizar los sistemas que son más críticos para su negocio y recuperarlos en orden de prioridad», dijo el consultor de ciberseguridad Brian Honan, quien dirige BH Consulting, con sede en Dublín.

También puede ser necesario clasificar a los equipos de TI. «Si bien muchas organizaciones afectadas querrán volver a la normalidad lo antes posible, el personal de TI necesitará apoyo más allá de las horas inmediatas de respuesta, en particular porque a menudo se pasa por alto el impacto mental y físico de los incidentes cibernéticos», dijo Pia Hüsch, investigadora del Royal United Services Institute, un grupo de expertos británico en defensa y seguridad.

Característica de seguridad importante: Rechazo de colisiones

No es la primera vez que una mala actualización de software provoca que los sistemas se bloqueen y luego se reinicien en un bucle sin fin. Una pregunta que se plantea con frecuencia es: ¿qué hace a continuación un proveedor?

El gigante de la red de distribución de contenidos Akamai se enfrentó a este problema hace 20 años, cuando se distribuyó en una actualización una actualización de metadatos incorrecta que especificaba cómo debía gestionarse el tráfico de cada cliente. Esto provocó que los servidores que se encontraban con la actualización incorrecta se bloquearan y se reiniciaran, volvieran a encontrar la actualización incorrecta y siguieran bloqueándose y reiniciándose, dijo Andy Ellis, CISO de Akamai en ese momento, que ocupó el cargo durante 25 años.

«Al menos, tuvimos una rápida recuperación y el incidente se solucionó muy rápidamente. Pero al realizar el análisis de seguridad, se trataba de un peligro que queríamos mitigar mejor, por lo que adoptamos el rechazo de accidentes», dijo Ellis, que ahora es socio operativo de la firma de capital de riesgo de ciberseguridad YL Ventures, en una publicación en X.

El enfoque de Akamai para rechazar fallas implicaba que su software recibiera una actualización y la colocara en una carpeta temporal, probara la actualización para asegurarse de que funcionara y solo la moviera de la carpeta temporal a su ubicación permanente si funcionaba.

«Si las cosas no salían bien, la aplicación se bloqueaba y, al reiniciarse, nunca se daba cuenta de la actualización tóxica. Se había revertido automáticamente y solo había sufrido una única falla mientras tanto», dijo Ellis.

Este enfoque no solucionará todos los tipos de problemas de actualización automática de software y puede resultar complejo de codificar debido a otros problemas que también pueden provocar que una aplicación se bloquee. «Pero si estás escribiendo software que se actualiza dinámicamente, el rechazo de bloqueos es una de las muchas prácticas de seguridad que debes incorporar», afirmó.

Además de analizar lo que CrowdStrike debería hacer, la interrupción también resalta cómo las protecciones a nivel del sistema operativo no evitaron que este tipo de software enviara a los sistemas Windows a un ciclo interminable de fallas y reinicios, dijo JJ Guy, CEO de Sevco Security.

«Eso es el resultado de la poca capacidad de recuperación del sistema operativo Microsoft Windows», dijo en una publicación en LinkedIn. «Cualquier software que cause fallas repetidas al iniciar el sistema no debería ser recargado automáticamente. Tenemos que dejar de crucificar a CrowdStrike por un error, cuando es el comportamiento del sistema operativo el que está causando las fallas sistemáticas repetidas».

Preguntas sobre resiliencia

Las interrupciones causadas por el error de CrowdStrike, que comenzaron el jueves y parecieron alcanzar su punto máximo el viernes, son un recordatorio del efecto que cualquier interrupción de TI puede tener en las empresas, los socios y los clientes. Esto indica la necesidad de una planificación sólida de la resiliencia dentro de cada empresa, independientemente del software o los servicios que utilice.

«Las organizaciones deben considerar los riesgos cibernéticos como riesgos empresariales y no simplemente como riesgos informáticos, y planificar su gestión en consecuencia», afirmó Honan, que fundó el primer equipo de respuesta a emergencias informáticas de Irlanda. «En particular, las organizaciones deben diseñar, implementar y probar periódicamente planes sólidos de resiliencia cibernética y continuidad empresarial, no solo para sus propios sistemas, sino también para los servicios y sistemas de los que dependen dentro de su cadena de suministro».

Los expertos recomiendan que las organizaciones desarrollen planes de resiliencia empresarial diseñados para enfrentar las principales amenazas que enfrentan, que pueden incluir interrupciones inesperadas de TI debido a ataques de ransomware, errores de empleados o desastres naturales. Aún más importante, dicen, es poner en práctica estos planes porque, para ser efectivos, deben involucrar a muchas partes diferentes de una organización, no solo a TI, y tener un mandato de arriba hacia abajo (ver: Respuesta a incidentes: mejores prácticas en la era del ransomware).

Supervisión del cumplimiento normativo

Esto no debería ser una novedad para los consejos directivos expertos en ciberseguridad. En la UE, tanto la Directiva de Seguridad de la Información y las Redes 2 (NIS2) como la Ley de Resiliencia Operativa Digital (DORA) exigen que las organizaciones reguladas tomen «las medidas adecuadas para gestionar el riesgo cibernético dentro de sus propias organizaciones y, lo que es igual de importante, dentro de su cadena de suministro», afirmó Honan.

Los equipos de ciberseguridad tienen un papel crucial que desempeñar no solo para defender los sistemas, sino también para ayudar a que vuelvan a funcionar en caso de incidente, ya sea un ataque, un error de un empleado o una mala actualización de software de un proveedor.

Este fin de semana, los equipos de TI trabajarán hasta altas horas de la noche para intentar restaurar los sistemas afectados. Después de eso, es de esperar que los CIO y CISO se pregunten qué lecciones deben aprenderse de las interrupciones de CrowdStrike.

«Puedo decirles: si la ‘actualización de mal proveedor’ no es parte de un manual de respuesta a incidentes, debería serlo el lunes», dijo Ian Thornton-Trump, CISO de Cyjax.

Schwartz es un periodista galardonado con dos décadas de experiencia en revistas, periódicos y medios electrónicos. Ha cubierto el sector de la seguridad de la información y la privacidad a lo largo de su carrera. Antes de unirse a Information Security Media Group en 2014, donde ahora se desempeña como editor ejecutivo de DataBreachToday y de la cobertura de noticias europeas, Schwartz fue reportero de seguridad de la información para InformationWeek y colaborador frecuente de DarkReading, entre otras publicaciones. Vive en Escocia.



AICPA aborda la ética de la IA en las auditorías


Publicado el 26 de julio de 2024 por Editor

El Instituto Estadounidense de Contadores Públicos Certificados (AICPA) organizó recientemente su último webcast A&A Focus, en el que se analizó en profundidad las implicancias éticas del uso de la inteligencia artificial (IA) en los procedimientos de auditoría. El evento, parte de una serie mensual, contó con las opiniones de los principales expertos en contabilidad, auditoría y aseguramiento.

Danielle Supkis-Cheek, vicepresidenta de análisis e inteligencia artificial de Caseware, dirigió el debate sobre la ética de la inteligencia artificial. Supkis-Cheek destacó que, si bien las herramientas de inteligencia artificial son cada vez más comunes en la profesión contable, no eximen a los profesionales de sus responsabilidades éticas. Comparó el uso de la inteligencia artificial con la contratación de personal o expertos, y subrayó la necesidad de una revisión y supervisión adecuadas de los resultados generados por la inteligencia artificial.

Supkis-Cheek también destacó el riesgo de sesgo de automatización, instando a los auditores a mantener un escepticismo profesional y a no confiar demasiado en los resultados de la IA sin una evaluación crítica. Además, señaló la creciente importancia de las habilidades de ingeniería de indicaciones, sugiriendo que la elaboración de indicaciones precisas y efectivas se convertirá en una competencia valiosa para los profesionales de la contabilidad.

Básicamente, la conclusión del seminario web refleja la nuestra aquí en XBRL International: la IA se perfila como una herramienta interesante y útil, cuando se usa de manera efectiva en manos de un profesional; sin embargo, no debería verse como un sustituto del análisis de calidad.


Resumen de A&A Focus: La ética del uso de IA en una auditoría

La entrega de julio de la serie de noticieros mensuales también incluyó un vistazo al Informe a las Naciones de la ACFE publicado recientemente y la primera de una serie de conversaciones sobre el reconocimiento de ingresos y los activos digitales.

Por Dave Arman, contador público

22 de julio de 2024

Recientemente, la AICPA organizó otra edición de su popular serie A&A Focus, una transmisión web mensual diseñada para mantener a los miembros actualizados sobre los últimos avances en contabilidad, auditoría y aseguramiento. El evento, presentado por Bob Durak, director de Servicios Técnicos de A&A, y Andrew Merryman, gerente sénior de Servicios Técnicos de A&A, contó con la participación de cuatro expertos en la materia que compartieron sus conocimientos sobre varios temas importantes, incluida la consideración de la ética al utilizar herramientas de inteligencia artificial (IA) en los procedimientos de auditoría y cómo la información del informe de la Asociación de Examinadores de Fraude Certificados (ACFE) publicado recientemente, Fraude ocupacional 2024: un informe para las naciones, puede ayudar a los auditores en sus prácticas.

La transmisión también dio inicio a dos sesiones de varios meses sobre temas comunes de reconocimiento de ingresos y el nuevo mundo de los activos digitales y su tratamiento contable y de auditoría. La serie es gratuita para los miembros de AICPA, es fácil registrarse y se gana una hora de CPE por mes.

Los miembros de AICPA pueden ver una grabación a pedido de la transmisión en la página web de la serie y encontrar recursos valiosos adicionales exclusivos para miembros.

Consideraciones éticas al utilizar IA en contabilidad y auditoría

Danielle Supkis-Cheek, contadora pública, vicepresidenta y directora de análisis e inteligencia artificial en Caseware, inició los segmentos de expertos invitados y abordó las consideraciones éticas en torno al uso de la inteligencia artificial en contabilidad y auditoría. Supkis-Cheek enfatizó que, si bien las herramientas de inteligencia artificial son cada vez más comunes, no eximen a los profesionales de sus obligaciones éticas. Comparó el uso de la inteligencia artificial con el aprovechamiento del personal o de los expertos, y enfatizó la necesidad de una revisión y supervisión adecuadas de los resultados generados por la inteligencia artificial.

Supkis-Cheek también destacó el sesgo de automatización como una consideración clave, instando a los profesionales a mantener el escepticismo profesional al utilizar herramientas de IA. También señaló la creciente importancia de las habilidades de ingeniería de indicaciones para usar la IA de manera efectiva, sugiriendo que la capacidad de crear indicaciones precisas y efectivas puede convertirse en una habilidad valiosa para los profesionales de la contabilidad.

El debate sobre la ética de la IA también abordó los esfuerzos de la profesión contable por desarrollar políticas y mejores prácticas en torno al uso de la IA. A medida que la tecnología continúa evolucionando, la profesión debe lograr un equilibrio entre aprovechar las capacidades de la IA y garantizar el cumplimiento de los estándares éticos y el criterio profesional.

Comprender los conceptos básicos de los activos digitales

A continuación, Robert Sledge, CPA, socio de KPMG y miembro del Grupo de trabajo sobre activos digitales de la AICPA, ofreció una descripción general de esta área en rápida evolución. El Grupo de trabajo sobre activos digitales es un grupo de trabajo conjunto dependiente del Comité ejecutivo de informes financieros (FinREC) y del Comité ejecutivo de servicios de auditoría. El grupo de activos digitales está formado por subgrupos de contabilidad y auditoría. Juntos, estos subgrupos aportan conocimientos especializados de los líderes de la industria y de la AICPA para abordar las consideraciones relacionadas con los riesgos predominantes en el espacio de los activos digitales. Con procedimientos de auditoría sugeridos centrados en las transacciones más comunes que se observan en la actualidad, la ayuda práctica equipa a los profesionales para enfrentar los desafíos que presenta el ecosistema de activos digitales en evolución.

Sledge afirmó que los activos digitales se definen como registros digitales creados mediante criptografía y registrados en registros distribuidos, a menudo denominados cadenas de bloques. Hizo hincapié en la amplia diversidad de activos digitales, desde criptoactivos como bitcoin hasta tokens no fungibles (NFT) que representan activos digitales o físicos únicos.

Sledge destacó la importancia de comprender la naturaleza y el propósito específicos de cada activo digital, ya que esta comprensión es crucial para determinar los tratamientos contables, los controles internos y los enfoques de auditoría adecuados. También destacó la guía práctica recientemente actualizada del AICPA sobre contabilidad y auditoría de activos digitales, que proporciona una guía no autorizada sobre estas cuestiones complejas.

El debate sobre los activos digitales subrayó la necesidad de que los contadores y auditores se mantengan informados sobre las tecnologías emergentes y sus implicaciones para la presentación de informes y la verificación financiera. A medida que los activos digitales se vuelven más frecuentes en las transacciones comerciales, los profesionales deben estar preparados para afrontar los desafíos únicos que presentan.

Lo que el informe de fraude ocupacional de la ACFE puede decirles a los auditores

El tercer segmento del webcast se centró en el fraude ocupacional, con la participación de David Zweighaft, CPA, socio de RSZ Forensic Associates, sobre el Fraude ocupacional 2024: Informe a las naciones. Este informe bienal proporciona datos valiosos sobre esquemas de fraude, perpetradores, métodos de detección y controles antifraude, y sirve como un recurso crucial para los profesionales a la hora de evaluar y mitigar los riesgos de fraude.

Zweighaft señaló que, si bien la apropiación indebida de activos sigue siendo el tipo de fraude más común, el fraude en los estados financieros suele dar lugar a las mayores pérdidas monetarias. Destacó la utilidad del informe para fundamentar las evaluaciones de riesgo de fraude durante las auditorías, y abogó por la celebración de debates exhaustivos con todo el equipo de auditoría y con el personal del cliente en todos los niveles para identificar posibles vulnerabilidades.

Zweighaft observó que el cambio hacia el trabajo remoto y la mayor dependencia de la documentación electrónica en los últimos años han alterado el panorama del riesgo de fraude. Este cambio pone de relieve la necesidad de que los profesionales reevalúen y adapten continuamente sus estrategias de detección y prevención del fraude para abordar los riesgos cambiantes en la era digital.

Reconocimiento de ingresos y FASB ASC 606: una descripción general de los desafíos actuales

El segmento final del webcast abordó los desafíos actuales del reconocimiento de ingresos según el Tema 606 de la FASB ASC, Ingresos provenientes de contratos con clientes, con la participación de Angela Newell, CPA, socia de BDO y expresidenta de FinREC. A pesar de estar vigente durante varios años, la norma sigue presentando complejidades para muchos profesionales y empresas.

Newell destacó que, si bien el Tema 606 creó un modelo único e integral para el reconocimiento de ingresos en todas las industrias, el proceso y la forma de pensar en torno al reconocimiento de ingresos han cambiado fundamentalmente. Señaló que, incluso en los casos en que las cifras finales de ingresos se mantuvieron prácticamente sin cambios, el camino para llegar a esas cifras a menudo implica consideraciones y juicios significativamente diferentes.

Entre los desafíos actuales que se destacaron se encuentran las decisiones sobre quién es el principal y quién el agente, la identificación de obligaciones de desempeño diferenciadas dentro de los contratos y la contabilización de las contraprestaciones variables. La complejidad de estas cuestiones subraya la necesidad de seguir centrándose en el reconocimiento de ingresos en los programas de formación y desarrollo profesional.

Newell también se refirió a los requisitos de divulgación ampliados en virtud del Tema 606, que han aumentado significativamente el volumen y el detalle de la información relacionada con los ingresos en los estados financieros. Este cambio tiene implicaciones no solo para los preparadores sino también para los auditores a la hora de evaluar la idoneidad y precisión de estas divulgaciones mejoradas.

Durante la transmisión por Internet, los anfitriones destacaron que estos temas eran complejos y que podrían beneficiarse de un debate más profundo en eventos futuros. Subrayaron la importancia de mantenerse al día con los avances en materia de contabilidad y auditoría para mantener altos estándares de práctica en un entorno empresarial en rápida evolución.

En otros asuntos

Además de los segmentos temáticos destacados, la transmisión web de A&A Focus Series brindó actualizaciones sobre varios temas emergentes de actualidad:

Mirando hacia el futuro

El webcast concluyó con un avance del A&A Focus del próximo mes, en vivo el 7 de agosto de 2024, que contará con debates sobre el uso de la tecnología en una auditoría, específicamente al realizar procedimientos de evaluación de riesgos, una visita de nuestros colegas en el área de revisión por pares y una mirada a El Marco de Información Financiera para Pequeñas y Medianas Entidades (FRF para PYMES), sus beneficios y la orientación a sus clientes. A lo largo de 2024, el AICPA planea aprovechar la Serie de Enfoques A&A como un canal vital para mantener a los miembros informados sobre los nuevos desarrollos contables, de auditoría y de informes que impactan su trabajo en todas las industrias y dominios de práctica. Los miembros pueden acceder a los archivos de sesiones pasadas aquí.

Dave Arman, contador público certificado y MBA, es gerente sénior de Calidad de auditoría en AICPA y CIMA, que en conjunto forman la Asociación de Contadores Profesionales Certificados Internacionales. Para comentar este artículo o sugerir una idea para otro artículo, comuníquese con Jeff Drew a Jeff.Drew@aicpa-cima.com.



Actualización de la taxonomía IFRS 2024 – se recibieron comentarios sobre los cambios para la IFRS 18


Publicado el 13 de septiembre de 2024 por Editor

La decisión del Consejo de Normas Internacionales de Contabilidad (IASB) de actualizar la Taxonomía Contable NIIF sigue a la publicación en abril de 2024 de la NIIF 18, que establece un nuevo estándar para presentar y revelar datos financieros.

La NIIF 18 introduce una importante revisión de la forma en que se presenta y divulga la información financiera en los estados financieros, reemplazando a la NIC 1 y ofreciendo una mejora notable en términos de la realidad digital de la presentación de informes en la actualidad. La nueva norma requiere una taxonomía actualizada que la acompañe, con comentarios de las partes interesadas sobre el borrador publicado por la NIIF esta semana.

La NIIF 18 tiene como objetivo mejorar la claridad, la coherencia y la comparabilidad de los estados financieros. Entre las actualizaciones más importantes se encuentran los nuevos requisitos de presentación y revelación destinados a mejorar la forma en que se comunica la información financiera. Entre ellos, se incluyen la obligación de presentar totales y subtotales específicos en el estado de resultados, la divulgación de indicadores de rendimiento definidos por la dirección (MPM, por sus siglas en inglés) y el perfeccionamiento de los principios para la agregación y desagregación de la información.

Entre las 15 cartas de comentarios (que puede consultar aquí) que recibió el IASB, en XBRL International hemos alentado al IASB a «ir hacia donde se encuentre el objetivo». Esto significa que nos gustaría ver un enfoque más ambicioso: creemos que las preocupaciones sobre las limitaciones actuales del software son innecesarias dado el largo plazo de implementación de la NIIF 18. Recomendamos adoptar metadatos legibles por máquina, que mejorarían la precisión y reforzarían la coherencia a través de funciones de software como los menús desplegables. Las mejoras de software necesarias se pueden realizar a tiempo, y la adopción de soluciones digitales con visión de futuro garantizará que los informes financieros evolucionen para satisfacer las demandas del mañana, lo que generará una mayor transparencia y conocimiento para todos.

El objetivo es mejorar la transparencia estandarizando las métricas clave en los estados financieros y garantizando la coherencia en la forma en que se clasifican los ingresos y los gastos en categorías como operación, inversión y financiación.


Taxonomía contable IFRS 2024—Actualización propuesta 1 NIIF 18 Presentación y revelación en los estados financieros—Encuesta

Propósito del documento: El Consejo de Normas Internacionales de Contabilidad (IASB, por sus siglas en inglés) agradece las opiniones de las partes interesadas, quienes pueden enviar respuestas a la Actualización de la Taxonomía Propuesta a través de una encuesta o una carta de comentarios.

El propósito de este documento es proporcionar a las partes interesadas una visión general de la encuesta únicamente; por favor, no envíe este documento en respuesta a la Actualización de la Taxonomía Propuesta.

Este documento se proporciona solo a título informativo. Para enviar una encuesta en respuesta a la actualización de la taxonomía propuesta, acceda a la encuesta directamente aquí.

Descargo de responsabilidad: En la medida en que lo permita la ley aplicable, el IASB y la Fundación IFRS (Fundación) renuncian expresamente a toda responsabilidad que surja de esta publicación o de cualquier traducción de la misma, ya sea por contrato, agravio o de otro modo, a cualquier persona con respecto a cualquier reclamo o pérdida de cualquier naturaleza, incluidas pérdidas directas, indirectas, incidentales o consecuentes, daños punitivos, multas o costas.

La información contenida en esta publicación no constituye un consejo y no debe sustituir los servicios de un profesional debidamente calificado.

© Fundación IFRS 2024

Todos los derechos reservados. Los derechos de reproducción y uso están estrictamente limitados. Para obtener más información, póngase en contacto con la Fundación en permissions@ifrs.org


A quien corresponda:

RE: Taxonomía contable IFRS 2024 – Actualización propuesta 1, NIIF 18 Presentación y divulgación en los estados financieros

Agradecemos la oportunidad de responder a esta invitación para comentar sobre la Taxonomía Contable IFRS 2024 – Actualización Propuesta 1, Presentación y Divulgación de la NIIF 18 en los Estados Financieros.

Como presidente y director ejecutivo, respondo en nombre de XBRL US, una organización de estándares sin fines de lucro, con la misión de mejorar la eficiencia y la calidad de los informes en los EE. UU. mediante la promoción de la adopción de estándares de informes comerciales. XBRL US es una jurisdicción de XBRL International, el consorcio sin ánimo de lucro responsable de desarrollar y mantener la especificación técnica de XBRL (un estándar de datos libre y abierto ampliamente utilizado en todo el mundo para la elaboración de informes por parte de empresas públicas y privadas, así como de agencias gubernamentales). Nuestros miembros incluyen firmas de contabilidad, empresas públicas, proveedores de software, datos y servicios, así como otras organizaciones sin fines de lucro y organizaciones de estándares.

Trabajamos en estrecha colaboración con la taxonomía de las NIIF, en nuestro trabajo con los proveedores de software que apoyan a los declarantes de las NIIF y en el desarrollo de reglas de validación de la calidad de los datos que ayudan a los emisores a crear datos coherentes y utilizables a través de sus presentaciones. Desde 2018, el Centro para la Calidad de los Datos de XBRL US apoya a los declarantes de las NIIF y a los proveedores que trabajan con ellos mediante la creación y distribución de normas disponibles gratuitamente para los declarantes de las NIIF.

Esta carta aborda preguntas específicas planteadas en la encuesta correspondiente a la invitación a comentar.

Atributos de los conceptos

Apoyamos el uso de un enfoque de partidas para identificar las diferentes categorizaciones que definen las actividades comerciales de operaciones, financiamiento, inversiones, impuestos y operaciones discontinuadas. Sin embargo, estamos de acuerdo con las preocupaciones planteadas por Zach Gast en su opinión disidente con respecto a la identificación de la categoría a la que está asociada cada partida. Para identificar si una partida está operando, financiando o invirtiendo, creemos que el enfoque basado en rasgos debe incorporarse a la taxonomía de las NIIF.

Esto se está aplicando a la taxonomía US GAAP utilizando la taxonomía del metamodelo que asocia los rasgos respectivos a un concepto. Esto permite, por ejemplo, identificar aquellas partidas que están en funcionamiento, invirtiendo, financiando, impuestos sobre la renta y operaciones discontinuadas.

El metamodelo US GAAP se publicó por primera vez en 2024 como prototipo para comentarios. El FASB continúa este esfuerzo con la publicación de la Taxonomía GAAP de EE. UU. de 2025 y está agregando una cantidad significativa de rasgos a la taxonomía, para facilitar la identificación y comprensión de elementos de línea específicos.

Alentamos al equipo de IFRS a utilizar este mecanismo para asignar atributos inmutables a partidas específicas en la taxonomía. La adición de estos atributos facilita lo siguiente:

• Encontrar el concepto adecuado,

• Crear reglas basadas en rasgos o atributos de conceptos,

• Eliminar la ambigüedad sobre el significado de un concepto, y

• Imponer disciplina en el desarrollo de taxonomías.

La especificación que define los rasgos se define en el registro de roles de vínculo mediante el rol de arco de concepto de rasgo. Actualmente se encuentra en versión candidata y se planea que se adopte como un estado reconocido.

El uso del mecanismo de propiedades XBRL mediante referencias XBRL no debe utilizarse para capturar las propiedades de las líneas de pedido. Porque las propiedades definidas en la norma IFRS 18 son inmutables y no dependen del contexto. Por ejemplo, una propiedad como la fecha de vencimiento del concepto puede cambiar y no es un rasgo del concepto en sí. El mecanismo de propiedades se ha utilizado para admitir información específica del contexto y los rasgos no. En segundo lugar, los rasgos admiten un mecanismo de subclase de clase que significa que el mantenimiento de los rasgos es más fácil de mantener. En tercer lugar, este es el mecanismo que se está utilizando en la taxonomía US GAAP y creemos que es importante representar los metadatos de manera coherente entre las principales taxonomías contables.

Elementos no GAAP

El enfoque propuesto utiliza un solo elemento genérico para representar las medidas de desempeño definidas por la gerencia (MPM). A continuación, la taxonomía utiliza un enfoque dimensional para distinguir entre los diferentes tipos de medidas y los valores asociados a ellas.

No se debe utilizar un enfoque dimensional para definir los MPM. La desagregación dimensional no debe utilizarse para cambiar el significado de la partida o para definir el significado de un concepto. Las dimensiones se deben utilizar para agrupar hechos con atributos similares, de modo que el análisis se pueda realizar dentro de un constructo dimensional constante, como realizar cálculos sobre valores con el mismo período o evaluar valores para el mismo segmento. El uso de dimensiones para definir los atributos de un hecho debe realizarse en la línea de pedido. El uso de un enfoque dimensional como el propuesto dará como resultado datos que son difíciles de interpretar para los usuarios y representan un uso inesperado de las dimensiones.

Los declarantes deben definir elementos de extensión para representar los MPM y deben incluir relaciones base de enlace de cálculo para indicar cómo estas medidas se relacionan con los conceptos de las NIIF.

Gastos por naturaleza

El enfoque propuesto utiliza un eje de gastos por naturaleza para permitir a los usuarios determinar la naturaleza de los gastos por función. Estamos de acuerdo en que las partidas no deben usarse como miembros para identificar gastos por naturaleza. El cambio propuesto debe incluir un mecanismo para relacionar el gasto por partida por naturaleza con el miembro de gasto por naturaleza relacionado, de modo que quede claro qué miembros están asociados con cada partida. Diferentes archivadores de estados financieros podrían representar gastos de depreciación, por ejemplo, utilizando la partida individual de depreciación o utilizando el elemento Resultado (pérdida) de explotación (véase la tabla E3) con el miembro de depreciación. Vincular el miembro por naturaleza a la línea de pedido por naturaleza ayudaría a resolver este método duplicado de etiquetado para los usuarios de datos.

En segundo lugar, creemos que la taxonomía necesita implementar reglas de apoyo que garanticen que los gastos por naturaleza no se puedan utilizar con miembros que aparecen en el eje de gastos por naturaleza.


COMENTARIOS DE XBRL INTERNATIONAL SOBRE EL BORRADOR DE LAS ENMIENDAS A LA NORMA IFRS 18

Gracias por la oportunidad de comentar sobre el trabajo inicial del Equipo de Taxonomía y el Equipo de IFRS18 sobre las enmiendas propuestas a la taxonomía contable de IFRS. Aplaudimos la orientación digital que es evidente a lo largo de la NIIF 18 y apoyamos en gran medida el enfoque que la Fundación ha demostrado en relación con la divulgación digital de los estados financieros primarios de las NIIF. En estos comentarios, instamos al Equipo a que reconozca el papel central de la taxonomía de las NIIF y acepte que se requerirán algunas mejoras de software relativamente menores para dar efecto a la intención política del IASB.

Como saben, XBRL International es la organización global sin ánimo de lucro que desarrolla estándares y está detrás del estándar XBRL. Nuestros estándares son abiertos y de licencia libre, y se utilizan en todo el mundo1 para facilitar la elaboración de informes empresariales digitales en una amplia gama de dominios de informes. Tenemos un propósito específico de interés público: mejorar la rendición de cuentas y la transparencia del rendimiento empresarial a nivel mundial, proporcionando un estándar de intercambio de datos abiertos para la presentación de informes empresariales. Contamos con el apoyo de 19 capítulos independientes en todo el mundo que se centran en el periodismo digital en sus propios países y regiones.

En el anexo se expone nuestra respuesta a sus preguntas.

En resumen:

Q2: Metadatos de la categoría. Recomendamos que el equipo reconsidere su enfoque en relación con la categorización de las partidas en el estado de pérdidas y ganancias. En lugar de utilizar sufijos de etiqueta, que serían propensos a errores, difíciles de aplicar y especialmente complejos dado el gran número de idiomas utilizados en las revelaciones de las NIIF, se recomienda que se agregue una propiedad legible por máquina. Ofrecemos dos sugerencias sobre cómo lograrlo.

Q3: Conciliación de MPM. Instamos al equipo a que reconsidere el enfoque que propone. No confiamos en que las propuestas existentes para la conciliación de los hechos comunicados con arreglo a las NIIF puedan prepararse o consumirse de manera coherente o precisa en todo el mundo. La identificación de los MPM se puede realizar a través de mecanismos estructurados alternativos que no afecten ni comprometan el modelado. Hacemos varias sugerencias para enfoques alternativos, pero ahora comprendemos algo de la complejidad que existe en la reconciliación de MPM y reconocemos algunas de las imperfecciones de todas estas propuestas. No obstante, se recomienda que se requieran metadatos de taxonomía adicionales o metadatos de informe (o ambos).

Patina hasta donde estará el disco.

Es evidente que existe cierta reticencia dentro del equipo de taxonomía a adoptar un enfoque que actualmente podría no ser totalmente compatible con todo el software de preparación que se utiliza en todo el mundo. Dados los plazos de implementación de la NIIF 18, creemos que esta precaución no está justificada. Sé más valiente. Le instamos a que modifique su enfoque para lograr los objetivos políticos del proyecto PFS. La NIIF 18 representa una mejora notable para la divulgación de información y presta especial atención a la realidad digital de la presentación de informes en la actualidad.

Por favor, no abandone estos objetivos simplemente porque no pueden ser necesariamente compatibles con el software existente, desarrollado en el pasado. Se trata de mejoras relativamente sencillas, que básicamente requieren una experiencia de usuario y cambios de sintaxis compatibles que simplemente señalan algunas propiedades adicionales. En el pasado, hemos visto múltiples ejemplos de mejoras de software que se entregan a medida que evolucionan los estándares y las taxonomías.

En otras palabras, por favor, «patina hacia donde estará el disco». Es mucho mejor exigir el suministro de metadatos legibles por máquina tanto para Q2 como para Q3. En lugar de confiar en una ortografía coherente o en enfoques coherentes de requisitos de taxonomía de extensiones relativamente complejos (ninguno de los cuales funcionará), la coherencia se puede aplicar mediante la provisión de menús desplegables habilitados para software o componentes de experiencia de usuario similares. Para ayudar a lograr esto, le sugerimos encarecidamente que acompañe sus enfoques revisados con ejemplos de Inline XBRL.

Hay tiempo más que suficiente para que el software admita estos nuevos enfoques, y un enfoque de metadatos legibles por máquina garantizará que los requisitos de divulgación de la NIIF 18 sean aplicados de manera coherente por los emisores y, lo que es igual de importante, que el software consumidor pueda analizar el rendimiento corporativo de la manera que pretende el IASB.

Estaremos encantados de seguir analizando las sugerencias de esta carta y del Anexo, y de demostrar algunas de las opciones con los materiales XBRL Inline ejemplares que hemos desarrollado para analizar las opciones propuestas en el borrador de los materiales.

Del mismo modo, estaremos encantados de debatir la posibilidad de añadir soporte para probar la conformidad del software con el enfoque IFRS seleccionado en el programa XBRL International Software Certification.

No dude en ponerse en contacto con nosotros. Puede comunicarse conmigo a la dirección de correo electrónico anterior.

Gracias por su tiempo y la oportunidad de comentar.


Septiembre 3, 2024

Asunto: Carta de comentarios sobre la propuesta de actualización de la taxonomía IFRS – Taxonomía contable IFRS 2024 Actualización 1 – Presentación e información a revelar de la NIIF 18 en los estados financieros

Estimada señora, querido señor:

Agradecemos la oportunidad de comentar sobre la Actualización de la Taxonomía IFRS propuesta por el Consejo de Normas Internacionales de Contabilidad (IASB) – Actualización 1 de la Taxonomía Contable IFRS 2024, publicada en julio. Hemos consultado con miembros seleccionados del grupo de trabajo ESEF Mapping de XBRL France, y esta carta representa sus opiniones. Este grupo de trabajo está compuesto por expertos en XBRL y ESEF, proveedores de software, auditores y preparadores.

En líneas generales, estamos de acuerdo con las propuestas, excepto en lo que se refiere a la categorización mínima de los elementos de las partidas en categorías del estado financiero de rendimiento financiero, lo que obligará a los preparadores a maximizar el uso de extensiones, lo que perjudicará la comparabilidad. Recomendamos proporcionar más posibilidades de categorización. Tenemos comentarios menores con respecto a otros aspectos de las propuestas. El apéndice de esta carta, junto con el archivo Excel adjunto, contiene nuestras respuestas detalladas a las preguntas.

Por favor, póngase en contacto con nosotros en gilles.maguet@xbrl-eu.org si desea discutir cualquiera de los temas planteados en esta carta.

Atentamente


Apéndice

Pregunta 1 – Enfoque general y metodología (párrafos 1 a 21) ¿Está de acuerdo con la decisión del IASB:

(a) propuesta de enfoque general para los elementos existentes con referencia a la NIC 1;

(b) propuesta de añadir elementos categóricos para los nuevos requisitos de la NIIF 18 y que los elementos categóricos propuestos reflejen adecuadamente los requisitos de la NIIF 18; y

(c) propuesta de agregar elementos basados en los Ejemplos Ilustrativos que acompañan a la NIIF 18 solo si el IASB espera razonablemente que las entidades utilicen esos elementos para etiquetar partidas en sus estados financieros digitales?

Si no es así, especifique qué cambios sugiere y por qué.

Estamos de acuerdo con el enfoque y la metodología generales del IASB.

Sin embargo, nos gustaría sugerir:

1) Considerar agregar un par de elementos adicionales que cubran las nuevas disposiciones de la NIIF 18 que podrían permitir evitar múltiples extensiones

2) Considerar la posibilidad de añadir etiquetas para líneas de pedido incompletas por naturaleza

4.1 Etiquetas adicionales relacionadas con las nuevas disposiciones de la NIIF 18 que podrían considerarse

Sugerimos considerar agregar un par de elementos (resaltados en azul) que creemos que permitirían evitar la creación de múltiples extensiones, lo que permitiría obtener datos más comparables. Estas sugerencias se basan principalmente en observaciones que hicimos durante el ejercicio de trabajo de campo.

• Etiqueta adicional en la categoría de inversión de la cuenta de resultados

Ingresos (gastos) por inversiones en empresas asociadas, negocios conjuntos y subsidiarias no consolidadas, invirtiendo (NIIF 18.53(a))

Este concepto abarcaría la proporción de las ganancias o pérdidas de las participadas contabilizadas en el patrimonio, así como las ganancias o pérdidas en su disposición, que con frecuencia pueden presentarse en una sola línea según lo permitido por la NIIF 18.23, que es el caso del Ejemplo 1A en el ejercicio de trabajo de campo («Participación en las ganancias y ganancias por enajenación de asociadas y negocios conjuntos»)

• Etiquetas adicionales en la categoría de financiamiento de la cuenta de resultados

Gastos (ingresos) de pasivos financieros, financiamiento (NIIF 18.60)

Gastos por intereses (ingresos por intereses) de otros pasivos, financiación (NIIF 18.61)

En efecto, las etiquetas actuales dedicadas a la categoría de financiamiento no permiten capturar casos en los que el gasto de los pasivos financieros incluye componentes que no son intereses.

Además, esperamos que muchos preparadores tengan una sola línea para los gastos (ingresos) por intereses relacionados con los pasivos que surgen de transacciones que no involucran solo la obtención de financiamiento.

• Etiqueta general en las categorías de inversión/financiación de la cuenta de resultados

Todos los Ingresos Gastos Clasificados en la Categoría de Inversión

Todos los Ingresos Gastos Clasificados en la Categoría de Financiamiento

Creemos que un elemento general para ingresos y gastos en las categorías de financiamiento/inversión sería útil para los preparadores que tienen una sola línea en estas categorías y para servir como anclas para extensiones en estas categorías cuando la base de agregación seleccionada por el preparador no permite un ancla más precisa.

A efectos de anclaje, sería muy práctico tener elementos separados que representen los ingresos totales clasificados en la categoría de inversión, los gastos totales clasificados en la categoría de inversión y lo mismo en la categoría de financiación.

• Etiqueta adicional en el estado de situación financiera

Pasivos financieros que surgen de transacciones que involucran solo la obtención de financiamiento (con variantes corrientes / no corrientes)

Siguiendo las nuevas disposiciones de la NIIF 18, es posible que los preparadores deseen tener una partida en el estado de situación financiera que esté alineada con la NIIF 18.59(a). Esto también podría ser muy útil como ancla más ancha.

4.2 Etiquetas adicionales que podrían considerarse para líneas de pedido incompletas por naturaleza

Cuando los preparadores utilizan una presentación mixta para los gastos operativos, algunas partidas por su naturaleza están incompletas, es decir, no reflejan la totalidad de la naturaleza especificada, parte de la cual se captura en una partida por función.

Ese será típicamente el caso de un banco de seguros que presenta gastos por naturaleza para sus actividades bancarias e incluye epígrafes de la NIIF 17 para la actividad de seguros. Normalmente, la partida de beneficios para empleados no estará completa, ya que parte de los beneficios para empleados se capturará en «Gastos de servicios de seguro de contratos de seguro emitidos». Esto también parece ser común en la industria inmobiliaria.

Por lo tanto, sugerimos considerar la posibilidad de tener algunos conceptos adicionales para los gastos especificados por naturaleza que podrían etiquetarse, por ejemplo, como «[gastos por naturaleza] excluyendo los capturados en una partida por función», a fin de evitar multiplicar las extensiones para tales casos. Las partidas a las que se refiere la parte faltante de la naturaleza especificada del gasto serán claras si el preparador etiqueta la tabla relacionada con los gastos especificados por naturaleza.

Pregunta 2: Requisitos de presentación del estado de pérdidas y ganancias (párrafos 23 a 58)

(a) ¿Está de acuerdo con el enfoque propuesto por el IASB de utilizar modelos de partidas para los requisitos de presentación del estado de pérdidas y ganancias, específicamente:

(i) para las partidas de ingresos o gastos y subtotales que solo puedan ser clasificados en la misma categoría por todas las entidades, cambiar las etiquetas de esos elementos de línea para reflejar la información de la categoría;

(ii) para partidas de ingresos o gastos que puedan ser clasificadas en más de una categoría por una sola entidad o en diferentes categorías por diferentes entidades:

i. cambiar la etiqueta de los elementos de las partidas existentes para reflejar el hecho de que representan montos totales, posiblemente comprendiendo partidas de ingresos o gastos en diferentes categorías;

ii. añadir elementos de partida que reflejen la información de la categoría para cada categoría en la que se espere razonablemente que una entidad presente el elemento de la partida; y

(iii) para los subtotales definidos ‘ganancia o pérdida operativa’ y ‘ganancia o pérdida antes de financiamiento e impuestos sobre la renta’ requeridos por la NIIF 18 y los subtotales enumerados en el párrafo 118 de la NIIF 18, agregar elementos de partida si no existe ningún elemento de partida relacionado en la taxonomía contable de la NIIF?

Si no es así, especifique qué cambios sugiere y por qué.

b) ¿Tiene alguna opinión sobre el uso de los metadatos de las categorías como mecanismo para reflejar la información de las categorías (por ejemplo, además del enfoque propuesto de modelización de partidas para los requisitos de presentación del estado de pérdidas y ganancias u otras mejoras futuras)?

En caso afirmativo, especifique por qué recomendaría el uso de metadatos de categoría o, alternativamente, por qué desaconsejaría su uso.

Con respecto a la pregunta a), creemos que la propuesta de cambiar la Taxonomía Contable de las NIIF para distinguir las categorías de operaciones operativas, inversiones, financiamiento, impuestos sobre la renta y operaciones discontinuadas mediante el uso de etiquetas específicas para las partidas que reflejen la categoría, junto con una partida total, es una solución práctica para implementar la nueva estructura de la NIIF 18 del estado de pérdidas y ganancias.

En términos generales, estamos de acuerdo con las propuestas que figuran en los incisos i), ii) y iii) a), y a continuación se explican algunos comentarios de menores.

Sin embargo, no estamos de acuerdo con la pregunta ii) ii), que implica que muchas partidas relacionadas con el estado de la ejecución financiera sólo se clasifican como «totales».

Falta de categorización de las líneas de pedido más allá de la categorización como «total»

En efecto, para las partidas de ingresos o gastos que podrían clasificarse en más de una categoría, creemos que se han agregado muy pocas partidas en la actualización de la taxonomía de la propuesta, lo que resultará en que los preparadores tengan que usar muchas extensiones para los casos en que las etiquetas directas estaban disponibles hasta ahora, lo que perjudicará la comparabilidad.

Creemos que el principio debería ser el siguiente: en el caso de las partidas de ingresos o gastos que puedan clasificarse en más de una categoría por una sola entidad o en diferentes categorías por diferentes entidades, se deben agregar elementos de partida para reflejar la información de la categoría para cada categoría en la que se espera razonablemente que una entidad:

– Presentar el elemento de partida en el anverso del estado de ejecución financiera

– Utilizar el concepto como un ancla estrecha para una partida (extensión) del estado de rendimiento financiero etiquetado, o

– Utilizar el concepto como una desagregación de una partida del estado de rendimiento financiero.

Esto debería dar lugar a que casi todos los elementos clasificados como «totales» en la PTU también se clasifiquen en al menos una categoría adicional, de modo que el concepto pueda ser utilizado por los preparadores y se pueda mitigar la desventaja presentada en el párrafo 47 d).

Hemos identificado 120 etiquetas que solo se clasifican como «totales». Creemos que más del 75% de estas etiquetas podrían utilizarse en el estado de rendimiento financiero, o como anclajes estrechos o desagregación de elementos del estado de rendimiento financiero. Por lo tanto, la ausencia de categorización más allá de «Total» generará extensiones innecesarias y falta de información para las extensiones debido a la falta de anclajes estrechos apropiados para las extensiones.

En particular, creemos que todas las variantes de:

– depreciación

– amortización

– pérdida por deterioro

– reversión de la pérdida por deterioro

– gastos por intereses

– ingresos por intereses

deben clasificarse en otras categorías «totales» para que puedan utilizarse en el estado de resultados financieros, como anclas estrechas o como desglose de partidas de pérdidas y ganancias.

Pregunta 3: Requisitos de divulgación para las medidas de desempeño definidas por la gerencia (párrafos 59 a 80)

¿Está de acuerdo con el modelo propuesto para las medidas de desempeño definidas por la gerencia, específicamente:

(a) utilizando modelos dimensionales con dos ejes para la conciliación entre una medida de rendimiento definida por la dirección y el subtotal más directamente comparable enumerado en el párrafo 118 de la NIIF 18, o el total o subtotal específicamente requerido para ser presentado o revelado por las Normas de Contabilidad NIIF; y

b) ¿Utilizar elementos de partidas de los estados financieros primarios como elementos de partidas?

De no ser así, describa qué modelo alternativo sugiere y por qué.

Coincidimos con la propuesta global del IASB con dos ejes para la conciliación entre el MPM y los subtotales normativos.

Sin embargo, tenemos algunas observaciones que se relacionan con la implementación detallada de los modelos para las medidas de desempeño definidas por la administración, que son las siguientes:

1) Definición de un nivel inicial de miembros en el eje para la conciliación de elementos

2) Si el eje de conciliación de partidas es relevante para los impuestos sobre la renta y efecto del NIC

3) Necesidad de orientación sobre las convenciones de signos y los cálculos XBRL para la conciliación de MPM

4) Problema de señalización en la tabla D4

3.1 Definición de un nivel inicial de miembros en el eje para la conciliación de elementos

Creemos que sería beneficioso definir un nivel inicial de miembros en el eje que representa los elementos de conciliación en la divulgación de MPM. Esto permitiría a los emisores anclar a sus miembros personalizados en este primer nivel de clasificación común, proporcionando miembros de extensión más significativos y facilitando el análisis y la comparación.

Los miembros del primer nivel podrían basarse en la Medicina General e incluir:

1. Deterioro de activos intangibles y fondo de comercio

2. Deterioro de valor de activos tangibles

3. Amortización de activos intangibles adquiridos en combinaciones de negocios

4. Efecto de las combinaciones de negocios (costos de adquisición, revalorización de participaciones anteriores, cambios en la contraprestación contingente)

5. Efectos de las enajenaciones o interrupciones de las operaciones

6. Participación en las ganancias o pérdidas de las asociadas y negocios conjuntos

7. Reestructuración

8. Litigios

9. Divisas y derivados

10. Pagos basados en acciones

3.2 Si el eje de conciliación de partidas es relevante para los impuestos sobre la renta y el efecto del NIC

Encontramos que el uso del mismo eje «Conciliación de partidas en la conciliación de medidas de desempeño definidas por la gerencia» tanto para la partida de conciliación como para el impuesto sobre la renta y el INC puede resultar confuso. En efecto, a excepción de las medidas de rendimiento definidas por la administración después de impuestos, el impuesto sobre la renta y el NIC no son elementos de conciliación, son simplemente información adicional relacionada con los elementos de conciliación.

La confusión se ilustra a continuación, con un ejemplo en la página 58 de la PTU.

3.3 Necesidad de orientación de aplicación sobre convenciones de signos y cálculos XBRL para la conciliación de MPM

No hay ningún formato requerido para presentar la conciliación de MPM. Por lo tanto, algunos preparadores pueden presentar la conciliación comenzando con la medida IFRS, agregando los elementos de conciliación y obteniendo el MPM. Otros pueden comenzar con el MPM, deducir las partidas de conciliación y obtener la medida IFRS.

Esto puede llevar a cierta confusión en cuanto al signo que debe utilizarse para los elementos de conciliación y los cálculos XBRL que deben realizarse, en su caso.

Por lo tanto, creemos que sería útil que la actualización de la taxonomía contuviera alguna orientación sobre la convención de signos que debería aplicarse a los elementos de conciliación, por ejemplo, que un gasto (con un atributo de saldo DT) debe firmarse como negativo cuando el gasto se elimina de la medida IFRS para obtener la medida MPM, o cuando se agrega a la medida MPM para obtener la medida IFRS. Esto implicaría que la relación aritmética entre las etiquetas siempre sería MPM = Medida IFRS + Elementos de conciliación (aunque no se describa debido al modelado dimensional).

También creemos que sería útil obtener orientación sobre los cálculos XBRL, teniendo en cuenta los cálculos duplicados. Profundizamos en esta cuestión en 4.7

3.4 Problema de señalización en la tabla D4

También observamos un problema de señalización en la tabla D4 del apéndice D que podría valer la pena corregir si este ejemplo se presenta como parte de la actualización de la taxonomía. Se trata de la cantidad de 589 para la línea «Gasto por impuesto a la renta» y la columna «Gasto por reestructuración» que debe ser positiva.



Costos de la vivienda: ¿un último obstáculo en la última milla de la desinflación?


Boletín del BIS | No. 89 | 15 de julio de 2024

Por: Ryan Niladri Banerjee, Denis Gorea, Deniz Igan y Gabor Pinter

Texto completo en formato PDF (1,236kb) | 9 páginas

Conclusiones clave

  • La inflación retrocedió desde sus picos recientes, pero el aumento del costo de la vivienda sigue siendo elevado. Esta fortaleza refleja los cambios inducidos por la pandemia en la oferta y la demanda de viviendas, que agravaron aún más las presiones existentes derivadas de la escasez de viviendas de larga data y las tendencias demográficas.
  • El fuerte crecimiento del componente de vivienda de la inflación puede ser una preocupación para la política monetaria porque tiende a ser más persistente que los componentes relacionados con otros servicios y bienes, lo que refleja rezagos en la medición y cambios poco frecuentes en los alquileres.
  • En el corto plazo, los alquileres y los costos de la vivienda pueden aumentar después de un ajuste de la política monetaria si los propietarios transfieren los mayores costos financieros a los inquilinos, los desarrolladores inmobiliarios reducen la nueva oferta o más hogares optan por alquilar en lugar de comprar.

Sobre los autores


Los costos de la vivienda representan una gran parte del gasto de los hogares, especialmente en las economías avanzadas, por lo que constituyen un componente importante del índice de precios al consumidor (IPC). Estos costos han seguido aumentando a un ritmo acelerado durante los últimos dos años en muchas economías, a pesar de la intensa fase de endurecimiento de la política monetaria. ¿Ha evolucionado de manera diferente el componente de vivienda del IPC (H-IPC)1 en comparación con episodios de desinflación anteriores? ¿Es su fortaleza motivo de preocupación para la política monetaria? En este Boletín se hace un balance de las pruebas y se argumenta que la respuesta a ambas preguntas es afirmativa.

El componente de vivienda del IPC: evolución reciente y datos estilizados

La evolución del IPC-H muestra algunas diferencias con respecto a las desinflaciones anteriores. Desde que la inflación tocó techo, la tasa mediana de crecimiento del IPC-H se ha moderado, pero sigue siendo elevada (gráfico 1.A). Por el contrario, los episodios anteriores experimentaron una disminución de 2 puntos porcentuales 12 meses después del pico. Las últimas lecturas siguen a un rápido aumento en los 16 meses anteriores a ese pico.

Dicho esto, la adherencia del H-CPI no es universal. En los AE, el crecimiento del IPC H se sitúa en torno al 4,5% de media, no muy lejos de su máximo alcanzado en el primer trimestre de 2023 (gráfico 1.B). En las economías de mercados emergentes (EME), el crecimiento del IPC-H ha caído mucho más rápidamente (gráfico 1.C). Por el contrario, el comportamiento de otros componentes del IPC ha sido más similar entre las EA y las EME. El crecimiento de los precios de los servicios, excluida la vivienda, sigue siendo elevado en ambos grupos de países, mientras que el de los precios de los bienes ha seguido disminuyendo.

La relativa mayor adherencia del IPC-H en los países agrotóxicos podría deberse en parte a las diferencias en las estructuras económicas y el apoyo de las políticas. Estas podrían incluir más oportunidades para trabajar desde casa en las economías avanzadas debido a una mejor infraestructura de telecomunicaciones, más empleos aptos para el teletrabajo, así como un mayor apoyo fiscal y altas tasas de ahorro en medio de tasas de interés reales negativas.

El fuerte crecimiento del IPC H puede ser motivo de preocupación para la política monetaria, ya que tiende a ser muy persistente. En las economías agro activas, la persistencia del crecimiento del IPC-H es superior a la de los bienes y servicios, excluyendo la vivienda (gráfico 2.A). Esto significa que una vez que el crecimiento del H-IPC aumenta, puede permanecer elevado durante un período prolongado. Dada la actual tasa de crecimiento del 4,5% del IPC-H en la mediana de los EA, dentro de dos años, la tasa de crecimiento del IPC-H podría seguir estando alrededor de 0,5 puntos porcentuales por encima de su media a largo plazo. Por el contrario, el crecimiento de los precios de los servicios y de los bienes estaría en línea con sus medias a largo plazo. El H-IPC también es persistente en las EME, aunque no tanto.

Esta alta persistencia refleja dos factores: en primer lugar, cómo se miden los costos de la vivienda y, en segundo lugar, cómo evolucionan los alquileres de mercado, una variable subyacente clave para los costos de la vivienda, a lo largo del tiempo.

La metodología de medición de los alquileres introduce una persistencia en los datos de alrededor de seis meses. Para garantizar la comparabilidad a lo largo del tiempo, los organismos de estadística toman muestras de los alquileres de las mismas viviendas. Para limitar los costos de recopilación de datos y dado que los alquileres cambian con poca frecuencia, no recopilan datos para la misma unidad todos los meses. En su lugar, dividen la muestra en subgrupos y, por lo general, toman muestras de cada subgrupo cada seis meses. Luego, si el alquiler de una vivienda aumenta un mes después de la fecha de muestreo, pasarán otros cinco meses (la siguiente fecha de muestreo) para que esto aparezca en el índice. La influencia de este muestreo escalonado es evidente: el crecimiento del IPC-H alcanza su punto máximo al menos seis meses después de un aumento de las rentas de mercado de los inmuebles de nueva contratación (gráfico 2.B).

Además de la persistencia resultante de los retrasos en las mediciones, la variable latente subyacente también está sujeta a persistencia. La persistencia de la variable subyacente refleja una combinación de características económicas e institucionales de los mercados de alquiler. Estos incluyen la indexación, los contratos plurianuales y los límites a los aumentos anuales para los inquilinos existentes, las fricciones de búsqueda e información (véase Genesove (2003) y Gallin y Verbrugge (2019)). Muchos de los mismos factores tienden a introducir un grado de obsolescencia o retroceso en el IPC-H, ya que las rentas de los contratos existentes se ajustan más lentamente que las de los nuevos.

Determinantes de la evolución reciente del coste de la vivienda

¿Por qué el crecimiento del coste de la vivienda ha sido tan fuerte y pegajoso en el reciente episodio de inflación? En cierta medida, este dinamismo forma parte del dinamismo de los precios de los servicios en su conjunto, debido a la reversión de la brusca rotación de la demanda de servicios a bienes al inicio de la pandemia (Amatyakul et al (2024)). Pero también hay varios factores de oferta y demanda específicos de la vivienda.

Por el lado de la demanda, los cambios inducidos por la pandemia (por ejemplo, el trabajo a distancia) se tradujeron normalmente en una mayor demanda de servicios de vivienda. Estos acontecimientos se produjeron en el contexto de cambios demográficos y patrones migratorios a largo plazo (véanse García y Paciorek (2022) y Gravelle (2023)). La generación del milenio que llega a la edad adulta ha aumentado sustancialmente el número de personas en edad de formación del hogar en los EA después de 2020. Y una mayor incidencia de trabajadores nacidos en el extranjero se ha asociado con una mayor inflación del H-IPC en los EA después de 2020 (gráfico 3.A), mientras que había poca correlación positiva entre ambos antes de la pandemia.

Por el lado de la oferta, la «terming» de la deuda hipotecaria de los hogares a tipos fijos durante el período bajo y largo ha reducido la oferta de vivienda en el segmento de viviendas existentes (gráfico 3.B). Los propietarios de viviendas han bloqueado contratos hipotecarios a largo plazo con tasas de interés sustancialmente más bajas que las de las nuevas originaciones. Esto los ha incentivado a posponer la mudanza, reduciendo así la oferta de viviendas disponibles para la venta (Fonseca y Liu (2023), Liebersohn y Rothstein (2023), Batzer et al (2024)). La pandemia también exacerbó la escasez de viviendas que ya era visible desde hacía algún tiempo en bastantes países. Las interrupciones de las obras de construcción y el aumento vertiginoso de los costes de los insumos redujeron el número de nuevas viviendas que entraban en el mercado (gráfico 3.C).

El impacto de la política monetaria en los costes de la vivienda

El fuerte crecimiento del IPC H podría plantear un desafío específico a la política monetaria si es menos receptiva que otras categorías. Sin duda, como para cualquier otra categoría de gasto y al restringir la demanda agregada, un endurecimiento de la política monetaria también reducirá la demanda de servicios de vivienda. Sin embargo, otros canales podrían compensar al menos parte de este efecto, especialmente a corto plazo.

En primer lugar, los alquileres pueden aumentar en la medida en que los propietarios puedan trasladar los costos de oportunidad más altos a los inquilinos. Este efecto puede verse reforzado por factores institucionales, como la indexación parcial de las rentas a las tasas de interés. En segundo lugar, las tasas de política monetarias más altas también pueden aumentar los costos de financiamiento de los desarrolladores inmobiliarios y, por lo tanto, reducir la oferta. En tercer lugar, las opciones de tenencia de la vivienda pueden cambiar, con implicaciones para el precio de las viviendas alquiladas en comparación con las propiedades ocupadas por sus propietarios. Más hogares, especialmente los que compran por primera vez, recurrirían al alquiler en lugar de a la propiedad tras un aumento de las tasas hipotecarias, lo que aumentaría la demanda de propiedades de alquiler. Un efecto de equilibrio parcial de estas opciones de vivienda significaría un aumento de los alquileres. La respuesta limitada o lenta de la oferta en los segmentos de construcción para alquiler podría exacerbar el impacto.

Hay algunas pruebas de que las fuerzas que empujan al alza los alquileres cuando se endurece la política monetaria pueden, de hecho, compensar el efecto negativo que se produce a través de la demanda agregada. Como resultado, los alquileres y el IPC-H pueden aumentar tras un shock de política monetaria contractivo (Dias y Duarte (2019), Koeniger et al (2022)). Como mínimo, parece haber un largo desfase entre el endurecimiento de la política monetaria y el posterior descenso del IPC-H. En los EA, el H-IPC responde finalmente de forma estadísticamente significativa, pero tarda 18 meses en hacerlo, casi el doble que los demás componentes del IPC (gráfico 4.A). En las EME, la respuesta parece más rápida y mayor que en las AE, y más o menos a la par con el resto del IPC (gráfico 4.B).

Es difícil determinar definitivamente si el efecto de la política monetaria sobre el IPC H ha sido diferente desde la pandemia. Los datos disponibles después de la pandemia abarcan un período demasiado corto para una inferencia estadística sólida. Las interrupciones relacionadas con la pandemia añaden una volatilidad extraordinaria a los datos y complican aún más las cosas. Teniendo en cuenta estas advertencias, la evidencia sugiere un efecto más débil del endurecimiento monetario sobre el IPC-H en los EA posteriores a 2020 (gráfico 4.C). El efecto sobre el componente no inmobiliario tiene el signo negativo esperado y es mayor, aunque con un nivel bajo de significación estadística. Por el contrario, la respuesta del H-CPI es estadísticamente insignificante y tiene el signo equivocado. La estimación puntual es positiva 12 meses después del endurecimiento, mientras que en la muestra anterior a 2020 ya es negativa en el mismo horizonte.

Consideraciones de política

La compleja relación entre los costos de la vivienda y la inflación plantea muchas consideraciones. Dos parecen ser particularmente relevantes en la coyuntura actual.

En primer lugar, la evolución de los costes de la vivienda podría dar pistas sobre la trayectoria futura de la inflación. Por un lado, los retrasos en la medición y el ajuste de las rentas significan que hay un fuerte elemento retrospectivo en las lecturas actuales del crecimiento del IPC-H. Esto sugeriría restar importancia a esas lecturas. Por otro lado, la alta persistencia intrínseca sugiere que el IPC-H revela información sobre las tendencias subyacentes a corto plazo. Además, la importancia de este elemento en el coste de la vida puede aumentar su papel como fuente de efectos de segunda ronda.7 En relación con esto, a medida que los bancos centrales consideran relajar la política a corto plazo, los cambios en la demanda y la oferta de vivienda podrían introducir aumentos adicionales en las lecturas de inflación. Por ejemplo, en varios casos puede haber más demanda de vivienda reprimida de lo que parece. Los hogares que están atrapados en sus hipotecas a plazo fijo, así como los que se quedan como inquilinos porque las tasas son demasiado altas, pueden volver al mercado una vez que las tasas bajen. De ser así, es posible que las políticas deseen estar atentas a esta posibilidad y tenerla en cuenta en las decisiones.

En segundo lugar, una mayor contribución a la inflación de los costos de la vivienda podría informar la calibración de la política monetaria. Una menor sensibilidad de los costes de la vivienda a la política monetaria en comparación con otros componentes del IPC exigiría un endurecimiento más estricto de la política para lograr el mismo resultado. Y la mayor inercia sugeriría mantener una postura firme durante más tiempo.



Porqué las finanzas inclusivas deben ser fundamentales para la respuesta climática


A medida que nos acercamos a la semana de alto nivel de la Asamblea General de las Naciones Unidas y a la conferencia de las Naciones Unidas sobre el cambio climático COP29, la agenda climática mundial se está definiendo mediante intensos debates en torno a la financiación climática. Pero en gran medida está ausente de este debate la cuestión de quién tiene acceso a esta financiación.

Es bien sabido la necesidad de canalizar la financiación climática hacia las manos de los más afectados por el cambio climático. El tema está en el centro de las conversaciones sobre pérdidas y daños y fue central en el discurso del secretario general de la ONU, António Guterres, en el Día Mundial del Medio Ambiente, donde subrayó que es «una vergüenza que los más vulnerables sean luchando desesperadamente para hacer frente a una crisis climática que no hicieron nada para crear», y argumentó que «el sistema financiero mundial debe ser parte de la solución climática». También ha sido clave para las negociaciones de la COP desde que se estableció el Mecanismo Internacional de Varsovia sobre Pérdidas y Daños en 2013.

Existe un claro llamamiento mundial para que se destine más financiación climática a apoyar a los países de ingresos bajos y medianos, para que financie la adaptación y para que llegue directamente a quienes más lo necesitan. Sin embargo, el mundo está lejos de lograr esta visión. Se han canalizado aproximadamente 4,8 billones de dólares a la acción climática, pero el 75 por ciento de esto se ha invertido en países de altos ingresos y se estima que menos del 10 por ciento llega a los niveles locales.

La respuesta, sin embargo, podría estar a nuestro alcance. En un documento reciente de CGAP, argumentamos que las finanzas inclusivas pueden ser la forma más efectiva de distribuir el financiamiento climático a nivel de base y permitir una transición justa y una acción climática verdaderamente global.

Los servicios financieros son un facilitador fundamental para cualquier acción climática que las personas quieran emprender. Los productos de ahorro y crédito equipan a las personas para invertir en tecnologías más limpias, adoptar prácticas más sostenibles y construir medios de vida más resilientes. Las remesas y los pagos gubernamentales son cruciales para ayudar a los hogares a sobrevivir a las crisis climáticas y evitar mecanismos de afrontamiento negativos. Las soluciones de seguros fortalecen la gestión de riesgos, desbloquean la inversión en medios de vida y ayudan a las personas afectadas a reconstruir sus vidas después de una crisis.

Por el contrario, sin acceso a la financiación, las personas afectadas por el cambio climático no pueden anticipar, enfrentar y recuperarse adecuadamente de las perturbaciones climáticas, ni pueden adaptarse para aumentar su resiliencia y mejorar sus medios de vida. Por lo tanto, es esencial que esta financiación sea accesible para todas las personas que experimentan los impactos climáticos, incluidas las de los países de ingresos bajos y medianos, que son desproporcionadamente vulnerables.

Esta oportunidad fue destacada en nuestro documento por el Presidente del Banco Mundial, Ajay Banga, y Su Majestad la Reina Máxima de los Países Bajos, Defensora Especial del Secretario General de las Naciones Unidas para las Finanzas Inclusivas para el Desarrollo. Afirmaron que «las finanzas inclusivas tienen un papel único y fundamental que desempeñar para garantizar que la financiación climática llegue a las manos de los más vulnerables y los empodere para actuar… Dada la creciente escala y frecuencia de las perturbaciones climáticas, ahora es el momento de una acción unida para hacer de las finanzas inclusivas una piedra angular de la respuesta climática».

Las finanzas inclusivas son un canal maduro, de bajo riesgo y alto impacto que los financiadores climáticos deben aprovechar. El sector de las finanzas inclusivas ya es un ecosistema bien establecido, que dirige de manera efectiva y segura grandes volúmenes de financiamiento de inversionistas de impacto, fondos intermediarios e instituciones financieras de desarrollo a las poblaciones de bajos ingresos a través de instituciones financieras fuertemente reguladas. Los proveedores de servicios financieros inclusivos (FSP, por sus siglas en inglés) tienen relaciones existentes en comunidades de bajos ingresos, un profundo conocimiento de las necesidades de los clientes y experiencia en cómo satisfacer esas necesidades con soluciones financieras. También cuentan con estrictos controles internos para evitar la mala asignación o el uso indebido de fondos y son cuidadosamente supervisados por los reguladores bancarios. Esto les permite desplegar el capital de manera eficiente y eficaz donde más se necesita.

Los proveedores de servicios financieros inclusivos han hecho esto a gran escala durante décadas. Un ejemplo es la revolución del dinero móvil (MM): en 2012, había 30 millones de usuarios activos de MM en todo el mundo, mientras que hoy en día hay 1.800 millonesde cuentas que procesan 1.4 billones de dólares al año. La mayoría de ellos están en manos de usuarios no bancarizados y de bajos ingresos.

Además, los proveedores de finanzas inclusivas han establecido un sólido historial de servicio a los segmentos de bajos ingresos de manera efectiva y de resultados positivos, lo que ha sido demostrado por numerosas evaluaciones. Por el contrario, el desembolso existente para el financiamiento climático existente para los países de ingresos bajos y medianos ha sido difícil de desembolsar, con grandes cantidades de tickets y procesos de desembolso que duran años. La proporción de desembolsos para la asistencia para el desarrollo relacionada con la adaptación es de sólo el 59 por ciento, en comparación con el 91 por ciento para la asistencia para el desarrollo en el extranjero en general. El Fondo Verde para el Clima y otros financiadores similares son criticados rutinariamente por procesos engorrosos que a menudo toman cinco años o más antes de que se desembolse el dinero.

Los PSF inclusivos tienen un papel único que desempeñar en la ampliación de la base de la acción climática a los 8 mil millones de personas que viven en el mundo hoy en día. Son la forma más eficaz de convertir grandes cantidades de financiación climática en financiación de pequeña cuantía que llega directamente a los hogares de bajos ingresos, con evaluaciones de riesgos adicionales relativamente ligeras y un tiempo de respuesta rápido.

Las finanzas inclusivas también pueden ayudar a aliviar la brecha mundial de financiamiento climático. Tiene una trayectoria comprobada en la movilización de capital privado para la acción de desarrollo, habiendo transformado el sector de organizaciones no gubernamentales y orientado a subvenciones hace 30 años a una industria comercial masiva en la actualidad. Los préstamos globales de los proveedores de servicios financieros inclusivos superan ahora los 180.000 millones de dólares al año.

Es hora de que las finanzas inclusivas ocupen su lugar esencial en la agenda climática. A medida que se desarrollan las negociaciones mundiales sobre la financiación climática, la cuestión de cómo llegar y empoderar a las personas más afectadas debe ocupar un lugar central. Las finanzas inclusivas ofrecen un medio poderoso para garantizar que la acción climática esté al alcance de todas las personas en nuestro planeta que se está calentando.


05 junio 2024

Discurso especial del secretario general sobre la acción climática «El momento de la verdad»

António Guterres

Queridos amigos del planeta,

Hoy es el Día Mundial del Medio Ambiente.

También es el día en que el Servicio de Cambio Climático Copernicus de la Comisión Europea informa oficialmente de que mayo de 2024 es el mayo más caluroso de la historia.

Esto marca doce meses consecutivos de los meses más calurosos de la historia.

Durante el último año, cada vuelta del calendario ha subido la temperatura.

Nuestro planeta está tratando de decirnos algo. Pero parece que no estamos escuchando.

  “Tenemos una opción: crear puntos de inflexión para el progreso climático, o precipitarnos hacia puntos de inflexión para el desastre climático. Este es un momento de todo incluido. Las Naciones Unidas están totalmente comprometidas: trabajan para fomentar la confianza, encontrar soluciones e inspirar la cooperación que nuestro mundo necesita tan desesperadamente. Somos Nosotros, los Pueblos, contra los contaminadores y los especuladores. Juntos, podemos ganar. Pero es hora de que los líderes decidan de qué lado están. Mañana es demasiado tarde. Ahora es el momento de movilizarse, ahora es el momento de actuar, ahora es el momento de cumplir.”  

Queridos amigos,

El Museo Americano de Historia Natural es el lugar ideal para hacer el punto.

Este gran museo cuenta la increíble historia de nuestro mundo natural. De las vastas fuerzas que han dado forma a la vida en la tierra durante miles de millones de años.

La humanidad es solo un pequeño punto en el radar.

Pero al igual que el meteorito que acabó con los dinosaurios, estamos teniendo un impacto descomunal.

En el caso del clima, no somos los dinosaurios.

Somos el meteorito.

No solo estamos en peligro.

Nosotros somos el peligro.

Pero también somos la solución.

Así que, queridos amigos,

Estamos en el momento de la verdad.

La verdad es que … casi diez años después de que se adoptara el Acuerdo de París, el objetivo de limitar el calentamiento global a largo plazo a 1,5 grados centígrados pende de un hilo.

La verdad es que … El mundo está arrojando emisiones tan rápido que para 2030, un aumento de temperatura mucho mayor estaría casi garantizado.

Los nuevos datos de los principales científicos del clima publicados hoy muestran que el presupuesto de carbono restante para limitar el calentamiento a largo plazo a 1,5 grados es ahora de alrededor de 200 mil millones de toneladas.

Esa es la cantidad máxima de dióxido de carbono que la atmósfera de la Tierra puede absorber si queremos tener una oportunidad de mantenernos dentro del límite.

La verdad es que… Estamos agotando el presupuesto a una velocidad imprudente, arrojando alrededor de 40 mil millones de toneladas de dióxido de carbono al año.

Todos podemos hacer los cálculos.

A este ritmo, todo el presupuesto de carbono se romperá antes de 2030.

La verdad es que … Las emisiones globales deben caer un nueve por ciento cada año hasta 2030 para mantener vivo el límite de 1,5 grados.

Pero van en la dirección equivocada.

El año pasado aumentaron un uno por ciento.

La verdad es que… Ya nos enfrentamos a incursiones en territorio de 1,5 grados.

La Organización Meteorológica Mundial informa hoy que hay un ochenta por ciento de posibilidades de que la temperatura media anual mundial supere el límite de 1,5 grados en al menos uno de los próximos cinco años.

En 2015, la probabilidad de que se produjera una infracción de este tipo era casi nula.

Y hay un cincuenta por ciento de posibilidades de que la temperatura media durante todo el próximo quinquenio sea 1,5 grados más alta que en la época preindustrial.

Estamos jugando a la ruleta rusa con nuestro planeta.

Necesitamos una rampa de salida de la autopista al infierno climático.

Y la verdad es que… Tenemos el control de la rueda.

El límite de 1,5 grados sigue siendo casi posible.

Recordemos que es un límite a largo plazo, medido en décadas, no en meses o años.

Por lo tanto, superar el umbral de 1,5 por un corto tiempo no significa que el objetivo a largo plazo esté disparado.

Significa que tenemos que luchar más duro.

Ahora.

La verdad es que… La batalla por 1,5 grados se ganará o se perderá en la década de 2020, bajo la mirada de los líderes de hoy.

Todo depende de las decisiones que esos líderes tomen, o dejen de tomar, especialmente en los próximos dieciocho meses.

Es la hora de la verdad climática.

La necesidad de actuar no tiene precedentes, pero también lo es la oportunidad, no solo de cumplir con el clima, sino también con la prosperidad económica y el desarrollo sostenible.

La acción climática no puede ser prisionera de las divisiones geopolíticas.

Por lo tanto, mientras el mundo se reúne en Bonn para las conversaciones sobre el clima y se prepara para las cumbres del G7 y el G20, la Asamblea General de las Naciones Unidas y la COP29, necesitamos la máxima ambición, la máxima aceleración, la máxima cooperación, en una palabra, la máxima acción.

Así que, queridos amigos,

¿Por qué todo este alboroto sobre 1,5 grados?

Porque nuestro planeta es una masa de sistemas complejos y conectados. Y cada fracción de grado de calentamiento global cuenta.

La diferencia entre 1,5 y dos grados podría ser la diferencia entre la extinción y la supervivencia de algunos pequeños estados insulares y comunidades costeras.

La diferencia entre minimizar el caos climático o cruzar peligrosos puntos de inflexión.

1,5 grados no es un objetivo. No es un objetivo. Es un límite físico.

Los científicos nos han alertado de que el aumento de las temperaturas probablemente significaría:

El colapso de la capa de hielo de Groenlandia y la capa de hielo de la Antártida Occidental con un aumento catastrófico del nivel del mar;

La destrucción de los sistemas de arrecifes de coral tropicales y de los medios de vida de 300 millones de personas;

El colapso de la corriente del mar de Labrador que alteraría aún más los patrones climáticos en Europa;

Y el derretimiento generalizado del permafrost que liberaría niveles devastadores de metano, uno de los gases más potentes que atrapan el calor.

Incluso hoy en día, estamos empujando los límites planetarios al límite, rompiendo récords de temperatura global y cosechando el torbellino.

Y es una parodia de la justicia climática que los menos responsables de la crisis sean los más afectados: las personas más pobres; los países más vulnerables; Pueblos Indígenas; mujeres y niñas.

El uno por ciento más rico emite hasta dos tercios de la humanidad.

Y los eventos extremos impulsados por el caos climático se están acumulando:

Destruyendo vidas, golpeando las economías y golpeando la salud;

Destruyendo el desarrollo sostenible; obligar a la gente a abandonar sus hogares; y sacudir los cimientos de la paz y la seguridad, a medida que las personas se desplazan y se agotan los recursos vitales.

Ya este año, una brutal ola de calor ha azotado Asia con temperaturas récord, marchitando cultivos, cerrando escuelas y matando a personas.

Ciudades desde Nueva Delhi hasta Bamako y Ciudad de México son abrasadoras.

Aquí en los Estados Unidos, las tormentas salvajes han destruido comunidades y vidas.

Hemos visto desastres por sequía declarados en todo el sur de África;

Las lluvias extremas inundan la Península Arábiga, África Oriental y Brasil;

Y un blanqueamiento masivo de corales a nivel mundial causado por temperaturas oceánicas sin precedentes, que supera las peores predicciones de los científicos.

El costo de todo este caos está golpeando a la gente donde más duele:

Desde la ruptura de las cadenas de suministro hasta el aumento de los precios, la creciente inseguridad alimentaria y los hogares y negocios no asegurables.

Esa factura seguirá creciendo. Incluso si las emisiones llegaran a cero mañana, un estudio reciente encontró que el caos climático aún costará al menos 38 billones de dólares al año para 2050.

El cambio climático es la madre de todos los impuestos encubiertos que pagan las personas comunes y los países y comunidades vulnerables.

Mientras tanto, los padrinos del caos climático, la industria de los combustibles fósiles, obtienen ganancias récord y se dan un festín de billones en subsidios financiados por los contribuyentes.

Queridos amigos,

Tenemos lo que necesitamos para salvarnos a nosotros mismos.

Nuestros bosques, nuestros humedales y nuestros océanos absorben carbono de la atmósfera. Son vitales para mantener vivo el 1,5, o para hacernos retroceder si superamos ese límite. Debemos protegerlos.

Y tenemos las tecnologías que necesitamos para reducir las emisiones.

Las energías renovables están en auge a medida que los costos se desploman y los gobiernos se dan cuenta de los beneficios de un aire más limpio, buenos empleos, seguridad energética y un mayor acceso a la energía.

La energía eólica y solar terrestre son la fuente más barata de nueva electricidad en la mayor parte del mundo, y lo han sido durante años.

Las energías renovables ya representan el treinta por ciento del suministro mundial de electricidad.

Y las inversiones en energía limpia alcanzaron un récord el año pasado, casi duplicándose en los últimos diez años.

La energía eólica y solar están creciendo más rápido que cualquier otra fuente de electricidad en la historia.

La lógica económica hace inevitable el fin de la era de los combustibles fósiles.

Las únicas preguntas son: ¿Llegará ese final a tiempo? ¿Y la transición será justa?

Queridos amigos,

Debemos asegurarnos de que la respuesta a ambas preguntas sea: sí.

Y debemos garantizar el futuro más seguro posible para las personas y el planeta.

Eso significa tomar medidas urgentes, particularmente durante los próximos dieciocho meses:

Para reducir drásticamente las emisiones;

Proteger a las personas y la naturaleza de los extremos climáticos;

Impulsar la financiación climática;

Y para tomar medidas drásticas contra la industria de los combustibles fósiles.

Permítanme analizar cada elemento por separado.

En primer lugar, enormes recortes de emisiones. Liderados por los grandes emisores.

Los países del G20 producen el ochenta por ciento de las emisiones globales, tienen la responsabilidad y la capacidad de estar al frente.

Las economías avanzadas del G20 deberían llegar más lejos y más rápido;

Y mostrar solidaridad climática proporcionando apoyo tecnológico y financiero a las economías emergentes del G20 y a otros países en desarrollo.

El próximo año, los gobiernos deben presentar las llamadas contribuciones determinadas a nivel nacional, es decir, planes nacionales de acción climática. Y estos determinarán las emisiones para los próximos años.

En la COP28, los países acordaron alinear esos planes con el límite de 1,5 grados.

Estos planes nacionales deben incluir objetivos absolutos de reducción de emisiones para 2030 y 2035.

Deben abarcar todos los sectores, todos los gases de efecto invernadero y toda la economía.

Y deben mostrar cómo los países contribuirán a las transiciones mundiales esenciales para alcanzar los 1,5 grados, lo que nos sitúa en el camino hacia el cero neto mundial para 2050; eliminar gradualmente los combustibles fósiles; y alcanzar hitos globales en el camino, año tras año y década tras década.

Eso incluye, para 2030, contribuir a reducir la producción y el consumo mundial de todos los combustibles fósiles en al menos un treinta por ciento; y cumplir los compromisos asumidos en la COP28 para poner fin a la deforestación, duplicar la eficiencia energética y triplicar las energías renovables.

Todos los países deben cumplir y desempeñar el papel que les corresponde.

Eso significa que los líderes del G20 trabajan en solidaridad para acelerar una transición energética global justa alineada con el límite de 1,5 grados. Deben asumir sus responsabilidades.

Necesitamos cooperación, no señalamientos.

Significa que el G20 alinee sus planes nacionales de acción climática, sus estrategias energéticas y sus planes para la producción y el consumo de combustibles fósiles, dentro de un futuro de 1,5 grados.

Significa que el G20 se compromete a reasignar los subsidios de los combustibles fósiles a las energías renovables, el almacenamiento y la modernización de la red, y el apoyo a las comunidades vulnerables.

Significa que el G7 y otros países de la OCDE se comprometen a: acabar con el carbón para 2030; y crear sistemas de energía libres de combustibles fósiles y reducir la oferta y la demanda de petróleo y gas en un sesenta por ciento, para 2035.

Significa que todos los países ponen fin a los nuevos proyectos de carbón, ahora. Particularmente en Asia, hogar del noventa y cinco por ciento de la nueva capacidad de energía de carbón planificada.

Significa que los países que no pertenecen a la OCDE creen planes de acción climática para ponerlos en el camino de poner fin a la energía del carbón para 2040.

Y significa que los países en desarrollo creen planes nacionales de acción climática que funcionen como planes de inversión, estimulen el desarrollo sostenible y satisfagan la creciente demanda de energía con energías renovables.

Las Naciones Unidas están movilizando a todo nuestro sistema para ayudar a los países en desarrollo a lograrlo a través de nuestra iniciativa Promesa Climática.

Todas las ciudades, regiones, industrias, instituciones financieras y empresas también deben ser parte de la solución.

Deben presentar planes de transición sólidos para la COP30 del próximo año en Brasil, a más tardar:

Planes alineados con 1,5 grados, y las recomendaciones del Grupo de Expertos de Alto Nivel de la ONU sobre Net Zero.

Planes que cubran las emisiones a lo largo de toda la cadena de valor;

Ello incluye objetivos provisionales y procesos de verificación transparentes;

Y que se mantengan alejados de las dudosas compensaciones de carbono que erosionan la confianza pública mientras hacen poco o nada para ayudar al clima.

No podemos engañar a la naturaleza. Las falsas soluciones serán contraproducentes. Necesitamos mercados de carbono de alta integridad que sean creíbles y con reglas consistentes para limitar el calentamiento a 1,5 grados.

También animo a los científicos e ingenieros a que se centren urgentemente en la eliminación y el almacenamiento de dióxido de carbono, para hacer frente de forma segura y sostenible a las emisiones finales de las industrias pesadas más difíciles de limpiar.

E insto a los gobiernos a que los apoyen.

Pero permítanme ser claro: estas tecnologías no son una bala de plata; No pueden ser un sustituto de los recortes drásticos de emisiones ni una excusa para retrasar la eliminación gradual de los combustibles fósiles.

Pero tenemos que actuar en todos los frentes.

Queridos amigos,

La segunda área de acción es aumentar la protección contra el caos climático de hoy y mañana.

Es una vergüenza que los más vulnerables se queden varados, luchando desesperadamente para hacer frente a una crisis climática que no hicieron nada para crear.

No podemos aceptar un futuro en el que los ricos estén protegidos en burbujas con aire acondicionado, mientras que el resto de la humanidad es azotada por un clima letal en tierras inhabitables.

Debemos salvaguardar a las personas y las economías.

Todas las personas de la Tierra deben estar protegidas por un sistema de alerta temprana para 2027. Insto a todos los asociados a que aumenten el apoyo al plan de acción de las Naciones Unidas de alerta temprana para todos.

En abril, el G7 puso en marcha el Centro Acelerador de la Adaptación.

Para la COP29, esta iniciativa debe traducirse en acciones concretas: apoyar a los países en desarrollo en la creación de planes de inversión en adaptación y ponerlos en práctica.

E insto a todos los países a que establezcan claramente sus necesidades de adaptación e inversión en sus nuevos planes climáticos nacionales.

Pero el cambio sobre el terreno depende del dinero que esté sobre la mesa.

Por cada dólar necesario para adaptarse a condiciones climáticas extremas, solo hay unos cinco centavos disponibles.

Como primer paso, todos los países desarrollados deben cumplir su compromiso de duplicar la financiación de la adaptación a por lo menos 40.000 millones de dólares al año para 2025.

Y deben establecer un plan claro para cerrar el déficit de financiación de la adaptación antes de la COP29 en noviembre.

Pero también necesitamos una reforma más fundamental.

Eso me lleva a mi tercer punto: las finanzas.

Queridos amigos,

Si el dinero hace girar el mundo, los flujos financieros desiguales de hoy nos están enviando hacia el desastre.

El sistema financiero mundial debe ser parte de la solución climática.

Los desorbitados pagos de la deuda están agotando los fondos para la acción climática.

Los costos de capital a nivel de extorsión están poniendo a las energías renovables prácticamente fuera del alcance de la mayoría de las economías en desarrollo y emergentes.

Sorprendentemente, y a pesar del auge de las energías renovables de los últimos años, las inversiones en energía limpia en las economías en desarrollo y emergentes fuera de China se han estancado en los mismos niveles desde 2015.

El año pasado, solo el quince por ciento de las nuevas inversiones en energía limpia se destinaron a mercados emergentes y economías en desarrollo fuera de China, países que representan casi dos tercios de la población mundial.

Y África albergó menos del uno por ciento de las instalaciones de energías renovables del año pasado, a pesar de su riqueza de recursos naturales y su vasto potencial de energías renovables.

La Agencia Internacional de Energía informa que las inversiones en energía limpia en economías en desarrollo y emergentes más allá de China deben alcanzar hasta 1,7 billones de dólares al año para principios de la década de 2030.

En resumen, necesitamos una expansión masiva de la financiación pública y privada asequible para impulsar nuevos y ambiciosos planes climáticos y ofrecer energía limpia y asequible para todos.

La Cumbre del Futuro que se celebrará en septiembre es una oportunidad para impulsar la reforma de la arquitectura financiera internacional y la adopción de medidas contra la deuda. Insto a los países a que lo hagan.

E insto a las Cumbres del G7 y del G20 a que se comprometan a utilizar su influencia dentro de los Bancos Multilaterales de Desarrollo para hacerlos mejores, más grandes y más audaces. Y capaz de apalancar mucha más financiación privada a un costo razonable.

Los países deben hacer contribuciones significativas al nuevo Fondo para Pérdidas y Daños. Y asegurarse de que esté abierto a los negocios para la COP29.

Y deben unirse para garantizar un sólido resultado financiero de la COP de este año, que fomente la confianza, catalice los billones necesarios y genere impulso para la reforma de la arquitectura financiera internacional.

Pero nada de esto será suficiente sin nuevas e innovadoras fuentes de financiación.

Es hora de poner un precio efectivo al carbono y gravar las ganancias inesperadas de las empresas de combustibles fósiles.

Para la COP29, necesitamos que los pioneros pasen de explorar a implementar gravámenes de solidaridad en sectores como el transporte marítimo, la aviación y la extracción de combustibles fósiles, para ayudar a financiar la acción climática.

Estos deben ser escalables, justos y fáciles de recopilar y administrar.

Nada de esto es caridad.

Es el interés propio ilustrado.

La financiación climática no es un favor. Es un elemento fundamental para un futuro habitable para todos.

Queridos amigos:

En cuarto y último lugar, debemos confrontar directamente a aquellos en la industria de los combustibles fósiles que han mostrado un celo implacable por obstruir el progreso, durante décadas.

Se han gastado miles de millones de dólares para distorsionar la verdad, engañar al público y sembrar dudas.

Doy las gracias a los académicos y a los activistas, a los periodistas y a los denunciantes, que han sacado a la luz esas tácticas, a menudo con un gran riesgo personal y profesional.

Hago un llamado a los líderes de la industria de los combustibles fósiles para que entiendan que si no están en el camino rápido hacia la transformación de la energía limpia, están llevando a su negocio a un callejón sin salida, y nos están llevando a todos con ustedes.

El año pasado, la industria del petróleo y el gas invirtió un mísero 2,5 por ciento de su gasto total de capital en energía limpia.

Duplicar la apuesta por los combustibles fósiles en el siglo XXI es como redoblar la apuesta por las herraduras y las ruedas de carruaje en el XIX.

Por lo tanto, a los ejecutivos de los combustibles fósiles les digo: sus enormes beneficios les dan la oportunidad de liderar la transición energética. No te lo pierdas.

Las instituciones financieras también son críticas porque el dinero habla.

Debe ser una voz para el cambio.

Insto a las instituciones financieras a que dejen de financiar la destrucción de los combustibles fósiles y empiecen a invertir en una revolución mundial de las energías renovables;

Presentar planes públicos, creíbles y detallados para la transición [de la financiación] de los combustibles fósiles a la energía limpia con objetivos claros para 2025 y 2030;

Y revelar sus riesgos climáticos, tanto físicos como transitorios, a sus accionistas y reguladores. En última instancia, dicha divulgación debería ser obligatoria.

Queridos amigos,

Muchos en la industria de los combustibles fósiles han maquillado descaradamente de verde, incluso cuando han tratado de retrasar la acción climática, con cabildeo, amenazas legales y campañas publicitarias masivas.

Han sido ayudados e instigados por empresas de publicidad y relaciones públicas -Mad Men -recuerden la serie de televisión- que alimentan la locura.

Hago un llamamiento a estas empresas para que dejen de actuar como facilitadoras de la destrucción del planeta.

Deje de aceptar nuevos clientes de combustibles fósiles, a partir de hoy, y establezca planes para eliminar los existentes.

Los combustibles fósiles no solo están envenenando nuestro planeta, sino que también son tóxicos para tu marca.

Su sector está lleno de mentes creativas que ya se están movilizando en torno a esta causa.

Están gravitando hacia las empresas que luchan por nuestro planeta, no por destruirlo.

También hago un llamamiento a los países para que actúen.

Muchos gobiernos restringen o prohíben la publicidad de productos que dañan la salud humana, como el tabaco.

Algunos están haciendo lo mismo con los combustibles fósiles.

Insto a todos los países a que prohíban la publicidad de las empresas de combustibles fósiles.

E insto a los medios de comunicación y a las empresas tecnológicas a que dejen de aceptar publicidad de combustibles fósiles.

Todos tenemos que ocuparnos también del lado de la demanda. Todos podemos marcar la diferencia adoptando tecnologías limpias, reduciendo gradualmente los combustibles fósiles en nuestras propias vidas y utilizando nuestro poder como ciudadanos para impulsar un cambio sistémico.

En la lucha por un futuro habitable, la gente de todo el mundo está muy por delante de los políticos.

Haz que tus voces sean escuchadas y que tus decisiones cuenten.

Queridos amigos,

Tenemos una opción.

Creando puntos de inflexión para el progreso climático, o precipitándose hacia puntos de inflexión para el desastre climático.

Ningún país puede resolver la crisis climática de forma aislada.

Este es un momento de todo incluido.

Las Naciones Unidas están totalmente comprometidas: trabajan para fomentar la confianza, encontrar soluciones e inspirar la cooperación que nuestro mundo necesita tan desesperadamente.

Y a los jóvenes, a la sociedad civil, a las ciudades, regiones, empresas y otros que han liderado la lucha hacia un mundo más seguro y limpio, les digo: Gracias.

Estás en el lado correcto de la historia.

Hablas en nombre de la mayoría.

Seguid así.

No pierdas el ánimo. No pierdas la esperanza.

Somos nosotros, los Pueblos, contra los contaminadores y los especuladores. Juntos, podemos ganar.

Pero es hora de que los líderes decidan de qué lado están.

Mañana será demasiado tarde.

Ahora es el momento de movilizarse, ahora es el momento de actuar, ahora es el momento de cumplir.

Este es nuestro momento de la verdad.

Y les doy las gracias.



Se publicó el primer borrador de las nuevas transformaciones iXBRL


Publicado el 20 de julio de 2024 por Editor

El Consejo de Normas XBRL ha aprobado la publicación de un Borrador de Trabajo Público inicial de la versión 6 del Registro de Reglas de Transformación XBRL en Línea.

Las transformaciones XBRL en línea definen cómo el texto legible por humanos en un documento XBRL en línea se transforma en datos legibles por máquina. Por ejemplo, el registro contiene transformaciones para muchos de los diferentes formatos de fecha que se utilizan en todo el mundo.

Esta última actualización del registro agrega transformaciones para brindar un mejor soporte a los valores enumerados y un borrador inicial de transformaciones propuestas por la reciente Nota del Grupo de Trabajo de Etiquetado de Bloques de Texto.

Se anima a los proveedores de software y otros usuarios a revisar y proporcionar comentarios sobre las nuevas funciones.

El borrador del registro se puede encontrar en nuestro sitio de especificaciones.

TRANSFORMACIONES XII NOTICIAS


Definiciones

1. Estado

El Consejo de Normas XBRL ha aprobado la publicación de este borrador de trabajo público con el fin de obtener comentarios. Se invita a los revisores a enviar comentarios sobre este documento al Grupo de trabajo de mantenimiento y especificación base (spec@xbrl.org).

2. Introducción (no normativa)

Este Registro de reglas de transformación es publicado por XBRL International Inc. en apoyo de las especificaciones para Inline XBRL. Las reglas de transformación definidas aquí se utilizan para permitir que las cadenas de texto en documentos Inline XBRL se conviertan en los tipos de datos utilizados en los documentos de instancia XBRL.

XBRL International Inc. publicará periódicamente nuevas versiones de este Registro de reglas de transformación. Cada versión se identifica por su espacio de nombres XML, como se describe a continuación.

3. espacios de nombres XML

El espacio de nombres para esta versión de este registro es:

http://www.xbrl.org/inlineXBRL/transformation/PWD/2024-06-18

Las versiones anteriores de este registro tenían los siguientes espacios de nombres:

3.1 fecha-día-mes

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthType

Patrón de entrada

[0-9]{1,2}[^0-9]+[0-9]{1,2}

Tipo de salida

xs:gMonthDay

Transforma una fecha numérica en el orden «día mes», con separador no numérico, en el formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido, xs:gMonthDaypor lo que, por ejemplo, «30/02» no está permitido.

  • Fecha numérica en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta 1 o 2 dígitos para el mes.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 02»).

3.2 fecha-día-mes-año

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthYearType

Patrón de entrada

[0-9०-९]{1,2}[^0-9०-९]+[0-9०-९]{1,2}[^0-9०-९]+([0-9०-९]{1,2}|[0-9०-९]{4})

Tipo de salida

xs:date

Transforma una fecha numérica en el orden «día, mes, año», con separadores no numéricos, en el formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30.02.09» no está permitido.

  • Fecha numérica en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta 1 o 2 dígitos para el mes.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30-02-2008»).

3.3 fecha-día-mesnombre-bg

Descripción

Transforma la fecha búlgara al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameBgType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ян|фев|мар|апр|май|маи|юни|юли|авг|сеп|окт|ное|дек|ЯН|ФЕВ|МАР|АПР|МАЙ|МАИ|ЮНИ|ЮЛИ|АВГ|СЕП|ОКТ|НОЕ|ДЕК|Ян|Фев|Мар|Апр|Май|Маи|Юни|Юли|Авг|Сеп|Окт|Ное|Дек)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha búlgara en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 febrero» no está permitido.

  • Fecha búlgara en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.4 fecha-día-mesnombre-cs

Descripción

Transforma la fecha checa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameCsType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ledna|února|unora|března|brezna|dubna|května|kvetna|června|cervna|července|cervence|srpna|září|zari|října|rijna|listopadu|prosince|led|úno|uno|bře|bre|dub|kvě|kve|čvn|cvn|čvc|cvc|srp|zář|zar|říj|rij|lis|pro|LEDNA|ÚNORA|UNORA|BŘEZNA|BREZNA|DUBNA|KVĚTNA|KVETNA|ČERVNA|CERVNA|ČERVENCE|CERVENCE|SRPNA|ZÁŘÍ|ZARI|ŘÍJNA|RIJNA|LISTOPADU|PROSINCE|LED|ÚNO|UNO|BŘE|BRE|DUB|KVĚ|KVE|ČVN|CVN|ČVC|CVC|SRP|ZÁŘ|ZAR|ŘÍJ|RIJ|LIS|PRO|Ledna|Února|Unora|Března|Brezna|Dubna|Května|Kvetna|Června|Cervna|Července|Cervence|Srpna|Září|Zari|Října|Rijna|Listopadu|Prosince|Led|Úno|Uno|Bře|Bre|Dub|Kvě|Kve|Čvn|Cvn|Čvc|Cvc|Srp|Zář|Zar|Říj|Rij|Lis|Pro)\.?

Tipo de salida

xs:gMonthDay

Transforma la fecha checa en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. února» no está permitido.

  • Fecha checa en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30. února»).

3.5 fecha-día-mesnombre-cy

Descripción

Transforma la fecha galesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameCyType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^0-9a-zA-Z]+(ion|chwe|maw|ebr|mai|meh|gor|aws|med|hyd|tach|rhag|ION|CHWE|MAW|EBR|MAI|MEH|GOR|AWS|MED|HYD|TACH|RHAG|Ion|Chwe|Maw|Ebr|Mai|Meh|Gor|Aws|Med|Hyd|Tach|Rhag)[^0-9]{0,7}

Tipo de salida

xs:gMonthDay

Transforma la fecha galesa en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30ain Chwefror» no está permitido.

  • Fecha galesa en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30ain Chwefror»).

3.6 fecha-día-mesnombre-da

Descripción

Transforma la fecha danesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameDaSvType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|maj|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha danesa en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 de febrero» no está permitido.

  • Fecha danesa o sueca en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.7 fecha-día-mesnombre-de

Descripción

Transforma la fecha alemana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameDeType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|jän|jaen|feb|mär|maer|mar|apr|mai|jun|jul|aug|sep|okt|nov|dez|JAN|JÄN|JAEN|FEB|MÄR|MAER|MAR|APR|MAI|JUN|JUL|AUG|SEP|OKT|NOV|DEZ|Jan|Jän|Jaen|Feb|Mär|Maer|Mar|Apr|Mai|Jun|Jul|Aug|Sep|Okt|Nov|Dez)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha alemana en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. Februar» no está permitido.

  • Fecha alemana en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.8 fecha-día-mesnombre-el

Descripción

Transforma la fecha griega al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameElType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ιαν|ίαν|φεβ|μάρ|μαρ|απρ|άπρ|αρίλ|άρίλ|αριλ|άριλ|μαΐ|μαι|μάι|μαϊ|μάϊ|ιούν|ίούν|ίουν|ιουν|ιούλ|ίούλ|ίουλ|ίουλ|ιουλ|αύγ|αυγ|σεπ|οκτ|όκτ|νοέ|νοε|δεκ|ΙΑΝ|ΊΑΝ|IΑΝ|ΦΕΒ|ΜΆΡ|ΜΑΡ|ΑΠΡ|ΆΠΡ|AΠΡ|AΡΙΛ|ΆΡΙΛ|ΑΡΙΛ|ΜΑΪ́|ΜΑΙ|ΜΆΙ|ΜΑΪ|ΜΆΪ|ΙΟΎΝ|ΊΟΎΝ|ΊΟΥΝ|IΟΥΝ|ΙΟΥΝ|IΟΥΝ|ΙΟΎΛ|ΊΟΎΛ|ΊΟΥΛ|IΟΎΛ|ΙΟΥΛ|IΟΥΛ|ΑΎΓ|ΑΥΓ|ΣΕΠ|ΟΚΤ|ΌΚΤ|OΚΤ|ΝΟΈ|ΝΟΕ|ΔΕΚ|Ιαν|Ίαν|Iαν|Φεβ|Μάρ|Μαρ|Απρ|Άπρ|Aπρ|Αρίλ|Άρίλ|Aρίλ|Aριλ|Άριλ|Αριλ|Μαΐ|Μαι|Μάι|Μαϊ|Μάϊ|Ιούν|Ίούν|Ίουν|Iούν|Ιουν|Iουν|Ιούλ|Ίούλ|Ίουλ|Iούλ|Ιουλ|Iουλ|Αύγ|Αυγ|Σεπ|Οκτ|Όκτ|Oκτ|Νοέ|Νοε|Δεκ)[^0-9]{0,8}

Tipo de salida

xs:gMonthDay

Transforma la fecha griega en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 Φεβρουαρίου» no está permitido.

  • Fecha griega en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 Φεβρουαρίου»).

3.9 fecha-día-mesnombre-es

Descripción

Transforma la fecha en inglés al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameEnType

Patrón de entrada

[0-9]{1,2}[^0-9]+(January|February|March|April|May|June|July|August|September|October|November|December|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC|JANUARY|FEBRUARY|MARCH|APRIL|MAY|JUNE|JULY|AUGUST|SEPTEMBER|OCTOBER|NOVEMBER|DECEMBER)

Tipo de salida

xs:gMonthDay

Transforma la fecha inglesa en el orden «día mes» al formato estándar de fecha recurrente W3C/ISO «–MM-DD». Cuando una fecha contiene varios nombres de meses (por ejemplo, «30 de enero, marzo y abril»), la transformación debe coincidir con la última ocurrencia. El resultado debe ser válido, xs:gMonthDaypor lo que, por ejemplo, «30 de febrero» no está permitido.

  • Fecha en inglés en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día, con sufijo ordinal opcional.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no impone un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.10 fecha-día-mesnombre-es

Descripción

Transforma la fecha española al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameEsType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic|ENE|FEB|MAR|ABR|MAY|JUN|JUL|AGO|SEP|OCT|NOV|DIC|Ene|Feb|Mar|Abr|May|Jun|Jul|Ago|Sep|Oct|Nov|Dic)[^0-9]{0,7}

Tipo de salida

xs:gMonthDay

Transforma la fecha española en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 de febrero» no está permitido.

  • Fecha española en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no impone un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.11 fecha-día-mesnombre-et

Descripción

Transforma la fecha de Estonia al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameEtType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jaan|veebr|märts|marts|apr|mai|juuni|juuli|aug|sept|okt|nov|dets|JAAN|VEEBR|MÄRTS|MARTS|APR|MAI|JUUNI|JUULI|AUG|SEPT|OKT|NOV|DETS|Jaan|Veebr|Märts|Marts|Apr|Mai|Juuni|Juuli|Aug|Sept|Okt|Nov|Dets)[^0-9]{0,5}

Tipo de salida

xs:gMonthDay

Transforma la fecha estonia en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. veebruar» no está permitido.

  • Fecha en estonio en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30.09.2016»).

3.12 fecha-día-mesnombre-fi

Descripción

Transforma la fecha finlandesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameFiType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^0-9a-zA-Z]+(tam|hel|maa|huh|tou|kes|hei|elo|syy|lok|mar|jou|TAM|HEL|MAA|HUH|TOU|KES|HEI|ELO|SYY|LOK|MAR|JOU|Tam|Hel|Maa|Huh|Tou|Kes|Hei|Elo|Syy|Lok|Mar|Jou)[^0-9]{0,8}

Tipo de salida

xs:gMonthDay

Transforma la fecha finlandesa en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. helmikuuta» no está permitido.

  • Fecha finlandesa en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30. hemikuuta»).

3.13 fecha-día-mesnombre-fr

Descripción

Transforma la fecha francesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameFrType

Patrón de entrada

[0-9]{1,2}[^0-9]+(janv|févr|fevr|mars|avr|mai|juin|juil|août|aout|sept|oct|nov|déc|dec|JANV|FÉVR|FEVR|MARS|AVR|MAI|JUIN|JUIL|AOÛT|AOUT|SEPT|OCT|NOV|DÉC|DEC|Janv|Févr|Fevr|Mars|Avr|Mai|Juin|Juil|Août|Aout|Sept|Oct|Nov|Déc|Dec)[^0-9]{0,5}

Tipo de salida

xs:gMonthDay

Transforma la fecha francesa en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 février» no está permitido.

  • Fecha en francés en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.14 fecha-día-mesnombre-hora

Descripción

Transforma la fecha croata al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameHrType

Patrón de entrada

[0-9]{1,2}[^0-9]+(sij|velj|ožu|ozu|tra|svi|lip|srp|kol|ruj|lis|stu|pro|SIJ|VELJ|OŽU|OZU|TRA|SVI|LIP|SRP|KOL|RUJ|LIS|STU|PRO|Sij|Velj|Ožu|Ozu|Tra|Svi|Lip|Srp|Kol|Ruj|Lis|Stu|Pro)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha croata en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. veljače» no está permitido.

  • Fecha croata en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30. veljače»).

3.15 fecha-día-mesnombre-it

Descripción

Transforma la fecha italiana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameItType

Patrón de entrada

[0-9]{1,2}[^0-9]+(gen|feb|mar|apr|mag|giu|lug|ago|set|ott|nov|dic|GEN|FEB|MAR|APR|MAG|GIU|LUG|AGO|SET|OTT|NOV|DIC|Gen|Feb|Mar|Apr|Mag|Giu|Lug|Ago|Set|Ott|Nov|Dic)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha italiana en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 febbraio» no está permitido.

  • Fecha italiana en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.16 fecha-día-mesnombre-lv

Descripción

Transforma la fecha letona al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameLvType

Patrón de entrada

[0-9]{1,2}[^0-9]+(janv|febr|marts|apr|maijs|jūn|jun|jūl|jul|aug|sept|okt|nov|dec|JANV|FEBR|MARTS|APR|MAIJS|JŪN|JUN|JŪL|JUL|AUG|SEPT|OKT|NOV|DEC|Janv|Febr|Marts|Apr|Maijs|Jūn|Jun|Jūl|Jul|Aug|Sept|Okt|Nov|Dec)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha letona en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. februāris» no está permitido.

  • Fecha letona en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.17 fecha-día-mesnombre-nl

Descripción

Transforma la fecha holandesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameNlType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|maa|mrt|apr|mei|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAA|MRT|APR|MEI|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Maa|Mrt|Apr|Mei|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha holandesa en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 februari» no está permitido.

  • Fecha holandesa en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.18 fecha-día-mesnombre-no

Descripción

Transforma la fecha noruega al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameNoType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|mai|jun|jul|aug|sep|okt|nov|des|JAN|FEB|MAR|APR|MAI|JUN|JUL|AUG|SEP|OKT|NOV|DES|Jan|Feb|Mar|Apr|Mai|Jun|Jul|Aug|Sep|Okt|Nov|Des)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha noruega en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 de febrero» no está permitido.

  • Fecha noruega en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.19 fecha-día-mesnombre-pl

Descripción

Transforma la fecha polaca al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnamePlType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^0-9a-zA-Z]+(sty|lut|mar|kwi|maj|cze|lip|sie|wrz|paź|paz|lis|gru|STY|LUT|MAR|KWI|MAJ|CZE|LIP|SIE|WRZ|PAŹ|PAZ|LIS|GRU|Sty|Lut|Mar|Kwi|Maj|Cze|Lip|Sie|Wrz|Paź|Paz|Lis|Gru)[^0-9]{0,9}

Tipo de salida

xs:gMonthDay

Transforma la fecha polaca en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. lutego» no está permitido.

  • Fecha polaca en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30. lutego»).

3.20 fecha-día-mesnombre-pt

Descripción

Transforma la fecha portuguesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnamePtType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|fev|mar|abr|mai|jun|jul|ago|set|out|nov|dez|JAN|FEV|MAR|ABR|MAI|JUN|JUL|AGO|SET|OUT|NOV|DEZ|Jan|Fev|Mar|Abr|Mai|Jun|Jul|Ago|Set|Out|Nov|Dez)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha en portugués en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 de febrero» no está permitido.

  • Fecha portuguesa en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.21 fecha-día-mesnombre-ro

Descripción

Transforma la fecha rumana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameRoType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ian|feb|mar|apr|mai|iun|iul|aug|sep|oct|noi|nov|dec|IAN|FEB|MAR|APR|MAI|IUN|IUL|AUG|SEP|OCT|NOI|NOV|DEC|Ian|Feb|Mar|Apr|Mai|Iun|Iul|Aug|Sep|Oct|Noi|Nov|Dec)[^0-9]{0,7}

Tipo de salida

xs:gMonthDay

Transforma la fecha rumana en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 februarie» no está permitido.

  • Fecha rumana en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.22 fecha-día-mesnombre-sk

Descripción

Transforma la fecha eslovaca al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameSkType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|máj|maj|jún|jun|júl|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MÁJ|MAJ|JÚN|JUN|JÚL|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Máj|Maj|Jún|Jun|Júl|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha eslovaca en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30. februára» no está permitido.

  • Fecha eslovaca en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.23 fecha-día-mesnombre-sl

Descripción

Transforma la fecha eslovena al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameSlType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|maj|jun|jul|avg|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AVG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Avg|Sep|Okt|Nov|Dec)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha eslovena en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 de febrero» no está permitido.

  • Fecha eslovena en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.24 fecha-día-mesnombre-sv

Descripción

Transforma la fecha sueca al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameDaSvType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|maj|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]{0,6}

Tipo de salida

xs:gMonthDay

Transforma la fecha sueca en el orden «día mes» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «30 februari» no está permitido.

  • Fecha danesa o sueca en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.25 fecha-día-mesnombre-año-bg

Descripción

Transforma la fecha búlgara al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearBgType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ян|фев|мар|апр|май|маи|юни|юли|авг|сеп|окт|ное|дек|ЯН|ФЕВ|МАР|АПР|МАЙ|МАИ|ЮНИ|ЮЛИ|АВГ|СЕП|ОКТ|НОЕ|ДЕК|Ян|Фев|Мар|Апр|Май|Маи|Юни|Юли|Авг|Сеп|Окт|Ное|Дек)[^0-9]+([0-9]{1,2}|[0-9]{4})[^0-9]*

Tipo de salida

xs:date

Transforma la fecha búlgara en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30 febrero 2008» no está permitido.

  • Fecha búlgara en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.26 fecha-día-mesnombre-año-cs

Descripción

Transforma la fecha checa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearCsType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ledna|února|unora|března|brezna|dubna|května|kvetna|června|cervna|července|cervence|srpna|září|zari|října|rijna|listopadu|prosince|led|úno|uno|bře|bre|dub|kvě|kve|čvn|cvn|čvc|cvc|srp|zář|zar|říj|rij|lis|pro|LEDNA|ÚNORA|UNORA|BŘEZNA|BREZNA|DUBNA|KVĚTNA|KVETNA|ČERVNA|CERVNA|ČERVENCE|CERVENCE|SRPNA|ZÁŘÍ|ZARI|ŘÍJNA|RIJNA|LISTOPADU|PROSINCE|LED|ÚNO|UNO|BŘE|BRE|DUB|KVĚ|KVE|ČVN|CVN|ČVC|CVC|SRP|ZÁŘ|ZAR|ŘÍJ|RIJ|LIS|PRO|Ledna|Února|Unora|Března|Brezna|Dubna|Května|Kvetna|Června|Cervna|Července|Cervence|Srpna|Září|Zari|Října|Rijna|Listopadu|Prosince|Led|Úno|Uno|Bře|Bre|Dub|Kvě|Kve|Čvn|Cvn|Čvc|Cvc|Srp|Zář|Zar|Říj|Rij|Lis|Pro)[^0-9a-zA-Z]+[^0-9]*([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha checa en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30. února 2008» no está permitido.

  • Fecha checa en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30. února 2008»).

3.27 fecha-día-mesnombre-año-año

Descripción

Transforma la fecha galesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearCyType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^0-9a-zA-Z]+(ion|chwe|maw|ebr|mai|meh|gor|aws|med|hyd|tach|rhag|ION|CHWE|MAW|EBR|MAI|MEH|GOR|AWS|MED|HYD|TACH|RHAG|Ion|Chwe|Maw|Ebr|Mai|Meh|Gor|Aws|Med|Hyd|Tach|Rhag)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha galesa en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30ain Chwefror 2008» no está permitido.

  • Fecha galesa en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de abril de 2008»).

3.28 fecha-día-mesnombre-año-da

Descripción

Transforma la fecha danesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearDaSvType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|maj|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha danesa en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2009» no está permitido.

  • Fecha en danés o sueco en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.29 fecha-día-mesnombre-año-de

Descripción

Transforma la fecha alemana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearDeType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|jän|jaen|feb|mär|maer|mar|apr|mai|jun|jul|aug|sep|okt|nov|dez|JAN|JÄN|JAEN|FEB|MÄR|MAER|MAR|APR|MAI|JUN|JUL|AUG|SEP|OKT|NOV|DEZ|Jan|Jän|Jaen|Feb|Mär|Maer|Mar|Apr|Mai|Jun|Jul|Aug|Sep|Okt|Nov|Dez)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha alemana en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30. Februar 2008» no está permitido.

  • Fecha alemana en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.30 fecha-día-mesnombre-año-el

Descripción

Transforma la fecha griega al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearElType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ιαν|ίαν|φεβ|μάρ|μαρ|απρ|άπρ|αρίλ|άρίλ|αριλ|άριλ|μαΐ|μαι|μάι|μαϊ|μάϊ|ιούν|ίούν|ίουν|ιουν|ιούλ|ίούλ|ίουλ|ίουλ|ιουλ|αύγ|αυγ|σεπ|οκτ|όκτ|νοέ|νοε|δεκ|ΙΑΝ|ΊΑΝ|IΑΝ|ΦΕΒ|ΜΆΡ|ΜΑΡ|ΑΠΡ|ΆΠΡ|AΠΡ|AΡΙΛ|ΆΡΙΛ|ΑΡΙΛ|ΜΑΪ́|ΜΑΙ|ΜΆΙ|ΜΑΪ|ΜΆΪ|ΙΟΎΝ|ΊΟΎΝ|ΊΟΥΝ|IΟΎΝ|ΙΟΥΝ|IΟΥΝ|ΙΟΎΛ|ΊΟΎΛ|ΊΟΥΛ|IΟΎΛ|ΙΟΥΛ|IΟΥΛ|ΑΎΓ|ΑΥΓ|ΣΕΠ|ΟΚΤ|ΌΚΤ|OΚΤ|ΝΟΈ|ΝΟΕ|ΔΕΚ|Ιαν|Ίαν|Iαν|Φεβ|Μάρ|Μαρ|Απρ|Άπρ|Aπρ|Αρίλ|Άρίλ|Aρίλ|Aριλ|Άριλ|Αριλ|Μαΐ|Μαι|Μάι|Μαϊ|Μάϊ|Ιούν|Ίούν|Ίουν|Iούν|Ιουν|Iουν|Ιούλ|Ίούλ|Ίουλ|Iούλ|Ιουλ|Iουλ|Αύγ|Αυγ|Σεπ|Οκτ|Όκτ|Oκτ|Νοέ|Νοε|Δεκ)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha griega en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30 Φεβρουαρίου 2008» no está permitido.

  • Fecha griega en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.31 fecha-día-mesnombre-año-es

Descripción

Transforma la fecha en inglés al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearEnType

Patrón de entrada

[0-9]{1,2}[^0-9]+(January|February|March|April|May|June|July|August|September|October|November|December|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC|JANUARY|FEBRUARY|MARCH|APRIL|MAY|JUNE|JULY|AUGUST|SEPTEMBER|OCTOBER|NOVEMBER|DECEMBER)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha en inglés en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los años de un dígito están entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2009» no está permitido. Cuando una fecha contiene varios nombres de meses (por ejemplo, «30 de enero, marzo y abril de 1969»), la transformación debe coincidir con la última ocurrencia.

  • Fecha en inglés en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día, con sufijo ordinal opcional.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.32 fecha-día-mesnombre-año-es

Descripción

Transforma la fecha española al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearEsType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic|ENE|FEB|MAR|ABR|MAY|JUN|JUL|AGO|SEP|OCT|NOV|DIC|Ene|Feb|Mar|Abr|May|Jun|Jul|Ago|Sep|Oct|Nov|Dic)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha española en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2008» no está permitido.

  • Fecha española en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.33 fecha-día-mesnombre-año-et

Descripción

Transforma la fecha de Estonia al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearEtType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jaan|veebr|märts|marts|apr|mai|juuni|juuli|aug|sept|okt|nov|dets|JAAN|VEEBR|MÄRTS|MARTS|APR|MAI|JUUNI|JUULI|AUG|SEPT|OKT|NOV|DETS|Jaan|Veebr|Märts|Marts|Apr|Mai|Juuni|Juuli|Aug|Sept|Okt|Nov|Dets)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha en estonio en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30. veebruar 2008» no está permitido.

  • Fecha en estonio en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.34 fecha-día-mesnombre-año-fi

Descripción

Transforma la fecha finlandesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearFiType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^0-9a-zA-Z]+(tam|hel|maa|huh|tou|kes|hei|elo|syy|lok|mar|jou|TAM|HEL|MAA|HUH|TOU|KES|HEI|ELO|SYY|LOK|MAR|JOU|Tam|Hel|Maa|Huh|Tou|Kes|Hei|Elo|Syy|Lok|Mar|Jou)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha finlandesa en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30. helmikuuta 2008» no está permitido.

  • Fecha finlandesa en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30. helmikuuta 2008»).

3.35 fecha-día-mesnombre-año-fr

Descripción

Transforma la fecha francesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearFrType

Patrón de entrada

[0-9]{1,2}[^0-9]+(janv|févr|fevr|mars|avr|mai|juin|juil|août|aout|sept|oct|nov|déc|dec|JANV|FÉVR|FEVR|MARS|AVR|MAI|JUIN|JUIL|AOÛT|AOUT|SEPT|OCT|NOV|DÉC|DEC|Janv|Févr|Fevr|Mars|Avr|Mai|Juin|Juil|Août|Aout|Sept|Oct|Nov|Déc|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha francesa en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30 de febrero de 2008» no está permitido.

  • Fecha en francés en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.36 fecha-día-mesnombre-año-hola

Descripción

Transforma la fecha en hindi basada en el calendario gregoriano al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearHiType

Patrón de entrada

([0-9]{1,2}|[०-९]{1,2})[^0-9०-९]+(जनवरी|फरवरी|मार्च|अप्रैल|मई|जून|जुलाई|अगस्त|सितंबर|अक्टूबर|नवंबर|दिसंबर)[^0-9०-९]+([0-9]{2}|[0-9]{4}|[०-९]{2}|[०-९]{4})

Tipo de salida

xs:date

Transforma la fecha en hindi basada en el calendario gregoriano en el orden «día mes año» (usando nombres en hindi para los meses gregorianos; p. ej. «19 सितंबर 2012»; números arábigos o devanagari para día y año; p. ej. «१९ सितंबर २०१२») en el formato estándar de fecha W3C/ISO «AAAA-MM-DD». Acepta dígitos dobles para el año.

  • Fecha en hindi basada en el calendario gregoriano en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día, en números árabes o devanagari.
  • Acepta nombres en hindi no abreviados para los meses del calendario gregoriano.
  • Acepta 2 o 4 dígitos para el año, en números árabes o devanagari.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «45 de marzo de 2001»).

3.37 fecha-día-mesnombre-año-hora

Descripción

Transforma la fecha croata al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearHrType

Patrón de entrada

[0-9]{1,2}[^0-9]+(sij|velj|ožu|ozu|tra|svi|lip|srp|kol|ruj|lis|stu|pro|SIJ|VELJ|OŽU|OZU|TRA|SVI|LIP|SRP|KOL|RUJ|LIS|STU|PRO|Sij|Velj|Ožu|Ozu|Tra|Svi|Lip|Srp|Kol|Ruj|Lis|Stu|Pro)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha croata en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30. veljače 2008» no está permitido.

  • Fecha croata en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de julio de 2008»).

3.38 fecha-día-mesnombre-año-it

Descripción

Transforma la fecha italiana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearItType

Patrón de entrada

[0-9]{1,2}[^0-9]+(gen|feb|mar|apr|mag|giu|lug|ago|set|ott|nov|dic|GEN|FEB|MAR|APR|MAG|GIU|LUG|AGO|SET|OTT|NOV|DIC|Gen|Feb|Mar|Apr|Mag|Giu|Lug|Ago|Set|Ott|Nov|Dic)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha italiana en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 febbraio 2008» no está permitido.

  • Fecha italiana en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.39 fecha-día-mesnombre-año-nl

Descripción

Transforma la fecha holandesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearNlType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|maa|mrt|apr|mei|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAA|MRT|APR|MEI|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Maa|Mrt|Apr|Mei|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha holandesa en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2008» no está permitido.

  • Fecha holandesa en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.40 fecha-día-mesnombre-año-no

Descripción

Transforma la fecha noruega al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearNoType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|mai|jun|jul|aug|sep|okt|nov|des|JAN|FEB|MAR|APR|MAI|JUN|JUL|AUG|SEP|OKT|NOV|DES|Jan|Feb|Mar|Apr|Mai|Jun|Jul|Aug|Sep|Okt|Nov|Des)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha noruega en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2008» no está permitido.

  • Fecha noruega en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.41 fecha-día-mesnombre-año-pl

Descripción

Transforma la fecha polaca al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearPlType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^0-9a-zA-Z]+(sty|lut|mar|kwi|maj|cze|lip|sie|wrz|paź|paz|lis|gru|STY|LUT|MAR|KWI|MAJ|CZE|LIP|SIE|WRZ|PAŹ|PAZ|LIS|GRU|Sty|Lut|Mar|Kwi|Maj|Cze|Lip|Sie|Wrz|Paź|Paz|Lis|Gru)[^0-9]+([0-9]{1,2}|[0-9]{4})[^0-9]*

Tipo de salida

xs:date

Transforma la fecha polaca en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30. lutego 2008 r» no está permitido.

  • Fecha en polaco en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de julio de 2008»).

3.42 fecha-día-mesnombre-año-pt

Descripción

Transforma la fecha portuguesa al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearPtType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|fev|mar|abr|mai|jun|jul|ago|set|out|nov|dez|JAN|FEV|MAR|ABR|MAI|JUN|JUL|AGO|SET|OUT|NOV|DEZ|Jan|Fev|Mar|Abr|Mai|Jun|Jul|Ago|Set|Out|Nov|Dez)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha portuguesa en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30 de Februaryeiro de 2008» no está permitido.

  • Fecha portuguesa en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.43 fecha-día-mesnombre-año-ro

Descripción

Transforma la fecha rumana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearRoType

Patrón de entrada

[0-9]{1,2}[^0-9]+(ian|feb|mar|apr|mai|iun|iul|aug|sep|oct|noi|nov|dec|IAN|FEB|MAR|APR|MAI|IUN|IUL|AUG|SEP|OCT|NOI|NOV|DEC|Ian|Feb|Mar|Apr|Mai|Iun|Iul|Aug|Sep|Oct|Noi|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha rumana en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2008» no está permitido.

  • Fecha rumana en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.44 fecha-día-mesnombre-año-sk

Descripción

Transforma la fecha eslovaca al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearSkType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|máj|maj|jún|jun|júl|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MÁJ|MAJ|JÚN|JUN|JÚL|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Máj|Maj|Jún|Jun|Júl|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha eslovaca en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «30. februára 2008» no está permitido.

  • Fecha eslovaca en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.45 fecha-día-mesnombre-año-sl

Descripción

Transforma la fecha eslovena al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearSlType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|maj|jun|jul|avg|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AVG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Avg|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha eslovena en el orden «día mes año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2008» no está permitido.

  • Fecha eslovena en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.46 fecha-día-mesnombre-año-sv

Descripción

Transforma la fecha sueca al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthnameYearDaSvType

Patrón de entrada

[0-9]{1,2}[^0-9]+(jan|feb|mar|apr|maj|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha sueca en el orden «día, mes, año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, «30 de febrero de 2009» no está permitido.

  • Fecha en danés o sueco en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.47 fecha-día-mesromano

Descripción

Transforma la fecha romana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthromanType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^XVIxvi]((I?(X|V|I)I{0,3})|(i?(x|v|i)i{0,3}))

Tipo de salida

xs:gMonthDay

Transforma la fecha utilizando números romanos para el mes en el orden «día mes» en el formato estándar de fecha recurrente W3C/ISO «–MM-DD». El resultado debe ser válido, xs:gMonthDaypor lo que, por ejemplo, «30 II» no está permitido.

  • Fecha romana en el orden «día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 II»).

3.48 fecha-día-mesaño-romano

Descripción

Transforma la fecha romana al formato W3C/ISO.

Tipo de entrada

ixt:dateDayMonthromanYearType

Patrón de entrada

[0-9]{1,2}[^0-9]*[^XVIxvi]((I?(X|V|I)I{0,3})|(i?(x|v|i)i{0,3}))[^XVIxvi][^0-9]*([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha utilizando números romanos en el orden «día mes año» en el formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009. El resultado debe ser válido, xs:datepor lo que, por ejemplo, «30 II 2008» no está permitido.

  • Fecha romana en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 II 2008»).

3.49 fecha-ind-día-mes-nombre-año-hi

Descripción

Transforma la fecha hindi basada en el Calendario Nacional Indio en el Calendario Gregoriano utilizando el formato W3C/ISO.

Tipo de entrada

ixt:dateIndDayMonthnameYearHiType

Patrón de entrada

([0-9]{1,2}|[०-९]{1,2})[^0-9०-९]+((C\S*ait|चैत्र)|(Vai|वैशाख|बैसाख)|(Jy|ज्येष्ठ)|(dha|ḍha|आषाढ|आषाढ़)|(vana|Śrāvaṇa|श्रावण|सावन)|(Bh\S+dra|Proṣṭhapada|भाद्रपद|भादो)|(in|आश्विन)|(K\S+rti|कार्तिक)|(M\S+rga|Agra|मार्गशीर्ष|अगहन)|(Pau|पौष)|(M\S+gh|माघ)|(Ph\S+lg|फाल्गुन))[^0-9०-९]+([0-9]{2}|[0-9]{4}|[०-९]{2}|[०-९]{4})

Tipo de salida

xs:date

Transforma una fecha en hindi basada en el Calendario Nacional Indio en el orden «día mes año» (usando nombres en hindi para los meses Saka, o la transliteración latina equivalente; por ejemplo, «11 पौष 1921» o «11 Pausha 1921»; y numerales árabes o devanagari; por ejemplo, ११ पौष १९२१) en el Calendario Gregoriano usando el formato estándar de fecha W3C/ISO «AAAA-MM-DD». Acepta dos dígitos para el año. Se supone que los años de dos dígitos caen entre 2000 y 2099 en el Calendario Gregoriano.

  • Fecha en hindi basada en el calendario nacional indio en el orden «día mes año».
  • Acepta 1 o 2 dígitos para el día, en números árabes o devanagari.
  • Acepta nombres en hindi para los meses Saka o transliteraciones latinas equivalentes.
  • Acepta 2 o 4 dígitos para el año, en números árabes o devanagari.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «45 Chaitra 2001»).
  • La parte de la expresión regular que representa el mes se divide mediante corchetes en doce grupos de captura y cada conjunto de contenidos corresponde a las expresiones alternativas aceptables para el mes respectivo.

3.50 fecha-japón-era-año-mes

Descripción

Transforma la fecha japonesa al formato W3C/ISO.

Tipo de entrada

ixt:dateJpnEraYearMonthType

Patrón de entrada

(明治|明|大正|大|昭和|昭|平成|平|令和|令)[\s ]*([0-90-9]{1,2}|元)[\s ]*(年)[\s ]*([0-90-9]{1,2})[\s ]*(月)

Tipo de salida

xs:gYearMonth

Transforma la fecha japonesa en el formato «año de la era mes» (por ejemplo, «令和元年5月») al formato estándar de fecha W3C/ISO «AAAA-MM». El resultado debe ser un xs:gYearMonth, por lo que, por ejemplo, «令和元年13月» no está permitido.

  • Fecha japonesa en el orden «era año mes» (por ejemplo, «令和元年5月»).

3.51 fecha-jpn-era-año-mes-día

Descripción

Transforma la fecha japonesa al formato W3C/ISO.

Tipo de entrada

ixt:dateJpnEraYearMonthDayType

Patrón de entrada

(明治|明|大正|大|昭和|昭|平成|平|令和|令)[\s ]*([0-90-9]{1,2}|元)[\s ]*(年)[\s ]*([0-90-9]{1,2})[\s ]*(月)[\s ]*([0-90-9]{1,2})[\s ]*(日)

Tipo de salida

xs:date

Transforma la fecha japonesa en el formato «era año mes día» (por ejemplo, «令和元年5月31日») al formato de esquema XML. El resultado debe ser válido xs:date, por lo que, por ejemplo, «令和元年2月30日» no está permitido.

  • Fecha japonesa en el orden «era año mes día» (por ejemplo, «令和元年5月31日»).

3.52 fecha-mes-día

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthDayType

Patrón de entrada

[0-9]{1,2}[^0-9]+[0-9]{1,2}

Tipo de salida

xs:gMonthDay

Transforma una fecha numérica en el orden «mes día», con separador no numérico, en el formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser un xs:gMonthDay válido, por lo que, por ejemplo, «02/30» no está permitido.

  • Fecha numérica en el orden «mes día».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta 1 o 2 dígitos para el mes.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «02 30»).

3.53 fecha-mes-día-año

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthDayYearType

Patrón de entrada

[0-9]{1,2}[^0-9]+[0-9]{1,2}[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma una fecha numérica en el orden «mes día año», con separadores no numéricos, en el formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «02.30.09» no está permitido.

  • Fecha numérica en el orden «mes día año».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta 1 o 2 dígitos para el mes.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30/02/2008»).

3.54 fecha-mes-año

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthYearType

Patrón de entrada

[0-9०-९]{1,2}[^0-9०-९]+([0-9०-९]{1,2}|[0-9०-९]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha numérica en el orden «mes año», con separador no numérico, en el formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha numérica en el orden «mes año».
  • Acepta 1 o 2 dígitos para el mes.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.
  • El esquema no impone un mes válido (por ejemplo, acepta «13 2008»).

3.55 fecha-mesnombre-día-es

Descripción

Transforma la fecha en inglés al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameDayEnType

Patrón de entrada

(January|February|March|April|May|June|July|August|September|October|November|December|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC|JANUARY|FEBRUARY|MARCH|APRIL|MAY|JUNE|JULY|AUGUST|SEPTEMBER|OCTOBER|NOVEMBER|DECEMBER)[^0-9]+[0-9]{1,2}[a-zA-Z]{0,2}

Tipo de salida

xs:gMonthDay

Transforma la fecha inglesa en el orden «mes día» al formato estándar de fecha recurrente W3C/ISO «–MM-DD». Acepta dígitos únicos para D. Acepta meses en forma completa o abreviada, con separador no numérico. Se acepta cualquier ordinal de una o dos letras. El resultado debe ser válido, xs:gMonthDaypor lo que, por ejemplo, «30 de febrero» no está permitido. Cuando una fecha contiene varios nombres de meses (por ejemplo, «30 de enero, marzo y abril»), la transformación debe coincidir con la primera aparición.

  • Fecha en inglés en el orden «mes día».
  • Acepta 1 o 2 dígitos para el día, con sufijo ordinal opcional de una o dos letras.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no impone un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.56 fecha-mesnombre-día-hu

Descripción

Transforma la fecha húngara al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameDayHuType

Patrón de entrada

(jan|feb|márc|marc|ápr|apr|máj|maj|jún|jun|júl|jul|aug|szept|okt|nov|dec|JAN|FEB|MÁRC|MARC|ÁPR|APR|MÁJ|MAJ|JÚN|JUN|JÚL|JUL|AUG|SZEPT|OKT|NOV|DEC|Jan|Feb|Márc|Marc|Ápr|Apr|Máj|Maj|Jún|Jun|Júl|Jul|Aug|Szept|Okt|Nov|Dec)[^0-9]{0,7}[^0-9]+[0-9]{1,2}

Tipo de salida

xs:gMonthDay

Transforma la fecha húngara en el orden «mes día» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «február 30» no está permitido.

  • Fecha húngara en el orden «mes día».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero»).

3.57 fecha-mesnombre-día-lt

Descripción

Transforma la fecha lituana al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameDayLtType

Patrón de entrada

(sau|vas|kov|bal|geg|bir|lie|rugp|rgp|rugs|rgs|spa|spl|lap|gru|grd|SAU|VAS|KOV|BAL|GEG|BIR|LIE|RUGP|RGP|RUGS|RGS|SPA|SPL|LAP|GRU|GRD|Sau|Vas|Kov|Bal|Geg|Bir|Lie|Rugp|Rgp|Rugs|Rgs|Spa|Spl|Lap|Gru|Grd)[^0-9]{0,6}[^0-9]+[0-9]{1,2}[^0-9]*

Tipo de salida

xs:gMonthDay

Transforma la fecha lituana en el orden «mes día» al formato estándar de fecha periódica W3C/ISO «–MM-DD». El resultado debe ser válido xs:gMonthDay, por lo que, por ejemplo, «Vasaris 30 d» no está permitido.

  • Fecha lituana en el orden «mes día».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Requiere un separador no numérico.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «Vasaris 30 d»).

3.58 fecha-mesnombre-día-año-es

Descripción

Transforma la fecha en inglés al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameDayYearEnType

Patrón de entrada

(January|February|March|April|May|June|July|August|September|October|November|December|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC|JANUARY|FEBRUARY|MARCH|APRIL|MAY|JUNE|JULY|AUGUST|SEPTEMBER|OCTOBER|NOVEMBER|DECEMBER)[^0-9]+[0-9]{1,2}[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:date

Transforma la fecha en inglés en el orden «mes día año» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los años de un dígito están entre 2000 y 2009. El resultado debe ser un xs:date válido, por lo que, por ejemplo, no se permite «30 de febrero de 2009». Cuando una fecha contiene varios nombres de meses (por ejemplo, «30 de enero, marzo y abril de 1969»), la transformación debe coincidir con la primera aparición.

  • Fecha en inglés en el orden «mes día año».
  • Acepta 1 o 2 dígitos para el día, con sufijo ordinal opcional.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «30 de febrero de 2008»).

3.59 fecha-mesnombre-año-bg

Descripción

Transforma la fecha búlgara al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearBgType

Patrón de entrada

(ян|фев|мар|апр|май|маи|юни|юли|авг|сеп|окт|ное|дек|ЯН|ФЕВ|МАР|АПР|МАЙ|МАИ|ЮНИ|ЮЛИ|АВГ|СЕП|ОКТ|НОЕ|ДЕК|Ян|Фев|Мар|Апр|Май|Маи|Юни|Юли|Авг|Сеп|Окт|Ное|Дек)[^0-9]+([0-9]{1,2}|[0-9]{4})[^0-9]*

Tipo de salida

xs:gYearMonth

Transforma la fecha búlgara en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha búlgara en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.60 fecha-mesnombre-año-cs

Descripción

Transforma la fecha checa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearCsType

Patrón de entrada

(leden|ledna|lednu|únor|unor|února|unora|únoru|unoru|březen|brezen|března|brezna|březnu|breznu|duben|dubna|dubnu|květen|kveten|května|kvetna|květnu|kvetnu|červen|cerven|června|cervna|červnu|cervnu|červenec|cervenec|července|cervence|červenci|cervenci|srpen|srpna|srpnu|září|zari|říjen|rijen|října|rijna|říjnu|rijnu|listopad|listopadu|prosinec|prosince|prosinci|led|úno|uno|bře|bre|dub|kvě|kve|čvn|cvn|čvc|cvc|srp|zář|zar|říj|rij|lis|pro|LEDEN|LEDNA|LEDNU|ÚNOR|UNOR|ÚNORA|UNORA|ÚNORU|UNORU|BŘEZEN|BREZEN|BŘEZNA|BREZNA|BŘEZNU|BREZNU|DUBEN|DUBNA|DUBNU|KVĚTEN|KVETEN|KVĚTNA|KVETNA|KVĚTNU|KVETNU|ČERVEN|CERVEN|ČERVNA|CERVNA|ČERVNU|CERVNU|ČERVENEC|CERVENEC|ČERVENCE|CERVENCE|ČERVENCI|CERVENCI|SRPEN|SRPNA|SRPNU|ZÁŘÍ|ZARI|ŘÍJEN|RIJEN|ŘÍJNA|RIJNA|ŘÍJNU|RIJNU|LISTOPAD|LISTOPADU|PROSINEC|PROSINCE|PROSINCI|LED|ÚNO|UNO|BŘE|BRE|DUB|KVĚ|KVE|ČVN|CVN|ČVC|CVC|SRP|ZÁŘ|ZAR|ŘÍJ|RIJ|LIS|PRO|Leden|Ledna|Lednu|Únor|Unor|Února|Unora|Únoru|Unoru|Březen|Brezen|Března|Brezna|Březnu|Breznu|Duben|Dubna|Dubnu|Květen|Kveten|Května|Kvetna|Květnu|Kvetnu|Červen|Cerven|Června|Cervna|Červnu|Cervnu|Červenec|Cervenec|Července|Cervence|Červenci|Cervenci|Srpen|Srpna|Srpnu|Září|Zari|Říjen|Rijen|Října|Rijna|Říjnu|Rijnu|Listopad|Listopadu|Prosinec|Prosince|Prosinci|Led|Úno|Uno|Bře|Bre|Dub|Kvě|Kve|Čvn|Cvn|Čvc|Cvc|Srp|Zář|Zar|Říj|Rij|Lis|Pro)[^0-9a-zA-Z]+[^0-9]*([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha checa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha checa en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.61 fecha-mesnombre-año-cy

Descripción

Transforma la fecha galesa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearCyType

Patrón de entrada

(ion|chwe|maw|faw|ebr|mai|fai|meh|feh|gor|ngor|aws|med|fed|hyd|tach|dach|nhach|thach|rhag|rag|ION|CHWE|MAW|FAW|EBR|MAI|FAI|MEH|FEH|GOR|NGOR|AWS|MED|FED|HYD|TACH|DACH|NHACH|THACH|RHAG|RAG|Ion|Chwe|Maw|Faw|Ebr|Mai|Fai|Meh|Feh|Gor|Ngor|Aws|Med|Fedi|Hyd|Tach|Dach|Nhach|Thach|Rhag|Rag)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha galesa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha galesa en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.62 fecha-mesnombre-año-da

Descripción

Transforma la fecha danesa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearDaSvType

Patrón de entrada

(jan|feb|mar|apr|maj|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha danesa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito entre 2000 y 2009.

  • Fecha en danés o sueco en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.63 fecha-mesnombre-año-de

Descripción

Transforma la fecha alemana al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearDeType

Patrón de entrada

(jan|jän|jaen|feb|mär|maer|mar|apr|mai|jun|jul|aug|sep|okt|nov|dez|JAN|JÄN|JAEN|FEB|MÄR|MAER|MAR|APR|MAI|JUN|JUL|AUG|SEP|OKT|NOV|DEZ|Jan|Jän|Jaen|Feb|Mär|Maer|Mar|Apr|Mai|Jun|Jul|Aug|Sep|Okt|Nov|Dez)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha alemana en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha alemana en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.64 fecha-mesnombre-año-el

Descripción

Transforma la fecha griega al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearElType

Patrón de entrada

(ιαν|ίαν|φεβ|μάρ|μαρ|απρ|άπρ|αρίλ|άρίλ|αριλ|άριλ|μαΐ|μαι|μάι|μαϊ|μάϊ|ιούν|ίούν|ίουν|ιουν|ιούλ|ίούλ|ίουλ|ίουλ|ιουλ|αύγ|αυγ|σεπ|οκτ|όκτ|νοέ|νοε|δεκ|ΙΑΝ|ΊΑΝ|IΑΝ|ΦΕΒ|ΜΆΡ|ΜΑΡ|ΑΠΡ|ΆΠΡ|AΠΡ|AΡΙΛ|ΆΡΙΛ|ΑΡΙΛ|ΜΑΪ́|ΜΑΙ|ΜΆΙ|ΜΑΪ|ΜΆΪ|ΙΟΎΝ|ΊΟΎΝ|ΊΟΥΝ|IΟΎΝ|ΙΟΥΝ|IΟΥΝ|ΙΟΎΛ|ΊΟΎΛ|ΊΟΥΛ|IΟΎΛ|ΙΟΥΛ|IΟΥΛ|ΑΎΓ|ΑΥΓ|ΣΕΠ|ΟΚΤ|ΌΚΤ|OΚΤ|ΝΟΈ|ΝΟΕ|ΔΕΚ|Ιαν|Ίαν|Iαν|Φεβ|Μάρ|Μαρ|Απρ|Άπρ|Aπρ|Αρίλ|Άρίλ|Aρίλ|Aριλ|Άριλ|Αριλ|Μαΐ|Μαι|Μάι|Μαϊ|Μάϊ|Ιούν|Ίούν|Ίουν|Iούν|Ιουν|Iουν|Ιούλ|Ίούλ|Ίουλ|Iούλ|Ιουλ|Iουλ|Αύγ|Αυγ|Σεπ|Οκτ|Όκτ|Oκτ|Νοέ|Νοε|Δεκ)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha griega en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha griega en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.65 fecha-mes-nombre-año-es

Descripción

Transforma la fecha en inglés al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearEnType

Patrón de entrada

(January|February|March|April|May|June|July|August|September|October|November|December|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC|JANUARY|FEBRUARY|MARCH|APRIL|MAY|JUNE|JULY|AUGUST|SEPTEMBER|OCTOBER|NOVEMBER|DECEMBER)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha en inglés en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los años de un dígito están entre 2000 y 2009. Cuando una fecha contiene varios nombres de meses (por ejemplo, «enero, marzo y abril de 1969»), la transformación debe coincidir con la primera aparición.

  • Fecha en inglés en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.66 fecha-mesnombre-año-es

Descripción

Transforma la fecha española al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearEsType

Patrón de entrada

(ene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic|ENE|FEB|MAR|ABR|MAY|JUN|JUL|AGO|SEP|OCT|NOV|DIC|Ene|Feb|Mar|Abr|May|Jun|Jul|Ago|Sep|Oct|Nov|Dic)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha española en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito entre 2000 y 2009.

  • Fecha española en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.67 fecha-mesnombre-año-et

Descripción

Transforma la fecha de Estonia al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearEtType

Patrón de entrada

(jaan|veebr|märts|marts|apr|mai|juuni|juuli|aug|sept|okt|nov|dets|JAAN|VEEBR|MÄRTS|MARTS|APR|MAI|JUUNI|JUULI|AUG|SEPT|OKT|NOV|DETS|Jaan|Veebr|Märts|Marts|Apr|Mai|Juuni|Juuli|Aug|Sept|Okt|Nov|Dets)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha estonia en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito entre 2000 y 2009.

  • Fecha en estonio en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.68 fecha-mesnombre-año-fi

Descripción

Transforma la fecha finlandesa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearFiType

Patrón de entrada

(tam|hel|maa|huh|tou|kes|hei|elo|syy|lok|mar|jou|TAM|HEL|MAA|HUH|TOU|KES|HEI|ELO|SYY|LOK|MAR|JOU|Tam|Hel|Maa|Huh|Tou|Kes|Hei|Elo|Syy|Lok|Mar|Jou)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha finlandesa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha finlandesa en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.69 fecha-mesnombre-año-fr

Descripción

Transforma la fecha francesa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearFrType

Patrón de entrada

(janv|févr|fevr|mars|avr|mai|juin|juil|août|aout|sept|oct|nov|déc|dec|JANV|FÉVR|FEVR|MARS|AVR|MAI|JUIN|JUIL|AOÛT|AOUT|SEPT|OCT|NOV|DÉC|DEC|Janv|Févr|Fevr|Mars|Avr|Mai|Juin|Juil|Août|Aout|Sept|Oct|Nov|Déc|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha francesa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha en francés en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.70 fecha-mesnombre-año-hola

Descripción

Transforma la fecha en hindi basada en el calendario gregoriano al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearHiType

Patrón de entrada

(जनवरी|फरवरी|मार्च|अप्रैल|मई|जून|जुलाई|अगस्त|सितंबर|अक्टूबर|नवंबर|दिसंबर)[^0-9०-९]+([0-9]{2}|[0-9]{4}|[०-९]{2}|[०-९]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha en hindi basada en el calendario gregoriano en el orden «mes año» (usando nombres en hindi para los meses gregorianos; p. ej. सितंबर 2012) y numerales arábigos o devanagari; p. ej. सितंबर २०१२) en el formato estándar de fecha W3C/ISO «AAAA-MM». Acepta dígitos dobles para el año.

  • Fecha en hindi basada en el calendario gregoriano en el orden «mes año».
  • Requiere nombres en hindi no abreviados para los meses del calendario gregoriano.
  • Acepta 2 o 4 dígitos para el año, en números árabes o devanagari.
  • Requiere un separador no numérico.

3.71 fecha-mesnombre-año-hora

Descripción

Transforma la fecha croata al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearHrType

Patrón de entrada

(sij|velj|ožu|ozu|tra|svi|lip|srp|kol|ruj|lis|stu|pro|SIJ|VELJ|OŽU|OZU|TRA|SVI|LIP|SRP|KOL|RUJ|LIS|STU|PRO|Sij|Velj|Ožu|Ozu|Tra|Svi|Lip|Srp|Kol|Ruj|Lis|Stu|Pro)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha croata en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha croata en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.72 fecha-mesnombre-año-it

Descripción

Transforma la fecha italiana al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearItType

Patrón de entrada

(gen|feb|mar|apr|mag|giu|lug|ago|set|ott|nov|dic|GEN|FEB|MAR|APR|MAG|GIU|LUG|AGO|SET|OTT|NOV|DIC|Gen|Feb|Mar|Apr|Mag|Giu|Lug|Ago|Set|Ott|Nov|Dic)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha italiana en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha italiana en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.73 fecha-mesnombre-año-nl

Descripción

Transforma la fecha holandesa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearNlType

Patrón de entrada

(jan|feb|maa|mrt|apr|mei|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAA|MRT|APR|MEI|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Maa|Mrt|Apr|Mei|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha holandesa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha holandesa en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.74 fecha-mesnombre-año-no

Descripción

Transforma la fecha noruega al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearNoType

Patrón de entrada

(jan|feb|mar|apr|mai|jun|jul|aug|sep|okt|nov|des|JAN|FEB|MAR|APR|MAI|JUN|JUL|AUG|SEP|OKT|NOV|DES|Jan|Feb|Mar|Apr|Mai|Jun|Jul|Aug|Sep|Okt|Nov|Des)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha noruega en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha noruega en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.75 fecha-mesnombre-año-pl

Descripción

Transforma la fecha polaca al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearPlType

Patrón de entrada

(sty|lut|mar|kwi|maj|cze|lip|sie|wrz|paź|paz|lis|gru|STY|LUT|MAR|KWI|MAJ|CZE|LIP|SIE|WRZ|PAŹ|PAZ|LIS|GRU|Sty|Lut|Mar|Kwi|Maj|Cze|Lip|Sie|Wrz|Paź|Paz|Lis|Gru)[^0-9]+([0-9]{1,2}|[0-9]{4})[^0-9]*

Tipo de salida

xs:gYearMonth

Transforma la fecha polaca en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha en polaco en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.76 fecha-mesnombre-año-pt

Descripción

Transforma la fecha portuguesa al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearPtType

Patrón de entrada

(jan|fev|mar|abr|mai|jun|jul|ago|set|out|nov|dez|JAN|FEV|MAR|ABR|MAI|JUN|JUL|AGO|SET|OUT|NOV|DEZ|Jan|Fev|Mar|Abr|Mai|Jun|Jul|Ago|Set|Out|Nov|Dez)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha portuguesa en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha portuguesa en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.77 fecha-mesnombre-año-ro

Descripción

Transforma la fecha rumana al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearRoType

Patrón de entrada

(ian|feb|mar|apr|mai|iun|iul|aug|sep|oct|noi|nov|dec|IAN|FEB|MAR|APR|MAI|IUN|IUL|AUG|SEP|OCT|NOI|NOV|DEC|Ian|Feb|Mar|Apr|Mai|Iun|Iul|Aug|Sep|Oct|Noi|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha rumana en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha rumana en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.78 fecha-mesnombre-año-sk

Descripción

Transforma la fecha eslovaca al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearSkType

Patrón de entrada

(jan|feb|mar|apr|máj|maj|jún|jun|júl|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MÁJ|MAJ|JÚN|JUN|JÚL|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Máj|Maj|Jún|Jun|Júl|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha eslovaca en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha eslovaca en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.79 fecha-mesnombre-año-sl

Descripción

Transforma la fecha eslovena al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearSlType

Patrón de entrada

(jan|feb|mar|apr|maj|jun|jul|avg|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AVG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Avg|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha eslovena en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha eslovena en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.80 fecha-mesnombre-año-sv

Descripción

Transforma la fecha sueca al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthnameYearDaSvType

Patrón de entrada

(jan|feb|mar|apr|maj|jun|jul|aug|sep|okt|nov|dec|JAN|FEB|MAR|APR|MAJ|JUN|JUL|AUG|SEP|OKT|NOV|DEC|Jan|Feb|Mar|Apr|Maj|Jun|Jul|Aug|Sep|Okt|Nov|Dec)[^0-9]+([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha sueca en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha en danés o sueco en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.81 fecha-mes-año-romano

Descripción

Transforma la fecha romana al formato W3C/ISO.

Tipo de entrada

ixt:dateMonthromanYearType

Patrón de entrada

((I?(X|V|I)I{0,3})|(i?(x|v|i)i{0,3}))[^XVIxvi][^0-9]*([0-9]{1,2}|[0-9]{4})

Tipo de salida

xs:gYearMonth

Transforma la fecha utilizando números romanos en el orden «mes año» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha romana en el orden «mes año».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.82 fecha-año-día-mesnombre-lv

Descripción

Transforma la fecha letona al formato W3C/ISO.

Tipo de entrada

ixt:dateYearDayMonthnameLvType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]+[0-9]{1,2}[^0-9]+(janv|febr|marts|apr|maijs|jūn|jun|jūl|jul|aug|sept|okt|nov|dec|JANV|FEBR|MARTS|APR|MAIJS|JŪN|JUN|JŪL|JUL|AUG|SEPT|OKT|NOV|DEC|Janv|Febr|Marts|Apr|Maijs|Jūn|Jun|Jūl|Jul|Aug|Sept|Okt|Nov|Dec)[^0-9]*

Tipo de salida

xs:date

Transforma la fecha letona en el orden «año día mes» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «2008. gada 30. februāris» no está permitido.

  • Fecha en letón en el orden «año día mes».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «2008. gada 30. februāris»).

3.83 fecha-año-mes

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthType

Patrón de entrada

([0-90-9]{1,2}|[0-90-9]{4})[^0-90-9]+[0-90-9]{1,2}[^0-90-9]*

Tipo de salida

xs:gYearMonth

Transforma la fecha numérica en el orden «año mes», con separador no numérico, en el formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009.

  • Fecha numérica en el orden «año mes».
  • Acepta 1, 2 o 4 dígitos para el año.
  • Acepta 1 o 2 dígitos para el mes.
  • Requiere un separador no numérico.
  • El esquema no impone un mes válido (por ejemplo, acepta «2008 13»).

3.84 fecha-año-mes-día

Descripción

Transforma la fecha numérica al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthDayType

Patrón de entrada

([0-90-9]{1,2}|[0-90-9]{4})[^0-90-9]+[0-90-9]{1,2}[^0-90-9]+[0-90-9]{1,2}[^0-90-9]*

Tipo de salida

xs:date

Transforma una fecha numérica en el orden «año mes día», con separadores no numéricos, en el formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están entre 2000 y 2099 y los de un dígito están entre 2000 y 2009. El resultado debe ser un xs:date, por lo que, por ejemplo, «09.02.30» no está permitido.

  • Fecha numérica en el orden «año mes día».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta 1 o 2 dígitos para el mes.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Los valores numéricos pueden representarse mediante formatos de medio ancho o de ancho completo.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «2008 2 30»).

3.85 fecha-año-mesnombre-día-hu

Descripción

Transforma la fecha húngara al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthnameDayHuType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]+(jan|feb|márc|marc|ápr|apr|máj|maj|jún|jun|júl|jul|aug|szept|okt|nov|dec|JAN|FEB|MÁRC|MARC|ÁPR|APR|MÁJ|MAJ|JÚN|JUN|JÚL|JUL|AUG|SZEPT|OKT|NOV|DEC|Jan|Feb|Márc|Marc|Ápr|Apr|Máj|Maj|Jún|Jun|Júl|Jul|Aug|Szept|Okt|Nov|Dec)[^0-9]+[0-9]{1,2}

Tipo de salida

xs:date

Transforma la fecha húngara en el orden «año mes día» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «2008. február 30» no está permitido.

  • Fecha húngara en el orden «año mes día».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «2008. február 30»).

3.86 fecha-año-mesnombre-día-lt

Descripción

Transforma la fecha lituana al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthnameDayLtType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]*[^0-9a-zA-Z]+(sau|vas|kov|bal|geg|bir|lie|rugp|rgp|rugs|rgs|spa|spl|lap|gru|grd|SAU|VAS|KOV|BAL|GEG|BIR|LIE|RUGP|RGP|RUGS|RGS|SPA|SPL|LAP|GRU|GRD|Sau|Vas|Kov|Bal|Geg|Bir|Lie|Rugp|Rgp|Rugs|Rgs|Spa|Spl|Lap|Gru|Grd)[^0-9]+[0-9]{1,2}[^0-9]*

Tipo de salida

xs:date

Transforma la fecha lituana en el orden «año mes día» al formato estándar de fecha W3C/ISO «AAAA-MM-DD». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009. El resultado debe ser válido xs:date, por lo que, por ejemplo, «2008 m. Vasaris 30 d» no está permitido.

  • Fecha lituana en el orden «año mes día».
  • Acepta 1 o 2 dígitos para el día.
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere separadores no numéricos.
  • El esquema no exige un día del mes válido (por ejemplo, acepta «2008 m. Vasaris 30 d»).

3.87 fecha-año-mesnombre-es

Descripción

Transforma la fecha en inglés al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthnameEnType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]+(January|February|March|April|May|June|July|August|September|October|November|December|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC|JANUARY|FEBRUARY|MARCH|APRIL|MAY|JUNE|JULY|AUGUST|SEPTEMBER|OCTOBER|NOVEMBER|DECEMBER)

Tipo de salida

xs:gYearMonth

Transforma la fecha en inglés en el orden «año mes» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están entre 2000 y 2099 y los años de un dígito están entre 2000 y 2009. Cuando una fecha contiene varios nombres de meses (por ejemplo, «1969, enero, marzo y abril»), la transformación debe coincidir con la última aparición.

  • Fecha en inglés en el orden «año mes».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.88 fecha-año-mesnombre-hu

Descripción

Transforma la fecha húngara al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthnameHuType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]+(jan|feb|márc|marc|ápr|apr|máj|maj|jún|jun|júl|jul|aug|szept|okt|nov|dec|JAN|FEB|MÁRC|MARC|ÁPR|APR|MÁJ|MAJ|JÚN|JUN|JÚL|JUL|AUG|SZEPT|OKT|NOV|DEC|Jan|Feb|Márc|Marc|Ápr|Apr|Máj|Maj|Jún|Jun|Júl|Jul|Aug|Szept|Okt|Nov|Dec)[^0-9]{0,7}

Tipo de salida

xs:gYearMonth

Transforma la fecha húngara en el orden «año mes» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha húngara en el orden «año mes».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.89 fecha-año-mesnombre-lt

Descripción

Transforma la fecha lituana al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthnameLtType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]*[^0-9a-zA-Z]+(sau|vas|kov|bal|geg|bir|lie|rugp|rgp|rugs|rgs|spa|spl|lap|gru|grd|SAU|VAS|KOV|BAL|GEG|BIR|LIE|RUGP|RGP|RUGS|RGS|SPA|SPL|LAP|GRU|GRD|Sau|Vas|Kov|Bal|Geg|Bir|Lie|Rugp|Rgp|Rugs|Rgs|Spa|Spl|Lap|Gru|Grd)[^0-9]*

Tipo de salida

xs:gYearMonth

Transforma la fecha lituana en el orden «año mes» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha lituana en el orden «año mes».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.90 fecha-año-mesnombre-lv

Descripción

Transforma la fecha letona al formato W3C/ISO.

Tipo de entrada

ixt:dateYearMonthnameLvType

Patrón de entrada

([0-9]{1,2}|[0-9]{4})[^0-9]+(janv|febr|marts|apr|maijs|jūn|jun|jūl|jul|aug|sept|okt|nov|dec|JANV|FEBR|MARTS|APR|MAIJS|JŪN|JUN|JŪL|JUL|AUG|SEPT|OKT|NOV|DEC|Janv|Febr|Marts|Apr|Maijs|Jūn|Jun|Jūl|Jul|Aug|Sept|Okt|Nov|Dec)[^0-9]{0,7}

Tipo de salida

xs:gYearMonth

Transforma la fecha letona en el orden «año mes» al formato estándar de fecha W3C/ISO «AAAA-MM». Se supone que los años de dos dígitos están comprendidos entre 2000 y 2099 y los de un dígito están comprendidos entre 2000 y 2009.

  • Fecha en letón en el orden «año mes».
  • Acepta meses en forma completa o abreviada.
  • Acepta 1, 2 o 4 dígitos para el año.
  • Requiere un separador no numérico.

3.91 fijo-vacío

Descripción

Transforma una cadena de formato libre en una cadena sin contenido.

Tipo de entrada

xs:string

Tipo de salida

ixt:fixedEmptyType

Esta transformación permite asociar una selección de datos de formato libre con un concepto XBRL vacío. Se utiliza en casos en los que, por ejemplo, se define un concepto vacío como un indicador, pero es conveniente vincular el uso de ese indicador a la información que se muestra en el documento XBRL en línea.

3.92 fijo-falso

Descripción

Transforma una cadena de forma libre en un valor booleano falso.

Tipo de entrada

xs:string

Tipo de salida

ixt:fixedFalseType

Esta transformación permite la asociación de una declaración de texto o un texto legal estándar en un documento escrito con un concepto booleano en un documento de instancia XBRL.

3.93 fijo-verdadero

Descripción

Transforma una cadena de forma libre en un valor booleano verdadero.

Tipo de entrada

xs:string

Tipo de salida

ixt:fixedTrueType

Esta transformación permite la asociación de una declaración de texto o un texto legal estándar en un documento escrito con un concepto booleano en un documento de instancia XBRL.

3.94 cero fijos

Descripción

Transforma cualquier texto en cero.

Tipo de entrada

xs:string

Tipo de salida

ixt:fixedZeroType

Reformatea varios guiones Unicode como cero.

3,95 num-coma-decimal

Descripción

Transforma una cadena numérica en un formato decimal definido por el esquema.

Tipo de entrada

ixt:numCommaDecimalType

Patrón de entrada

[\.  0-9]*(,[ 0-9]+)?

Tipo de salida

ixt:nonNegativeDecimalType

Transforma un número con separador de fracciones coma («,») y separadores de dígitos opcionales en un número no negativo según el formato decimal definido por el esquema.

  • Valores numéricos positivos con una coma como separador de fracciones.
  • No se aceptan signos ni exponenciales.
  • Se permiten puntos, espacios o espacios sin interrupción como separadores de dígitos opcionales.
  • Si hay un separador de fracciones, debe ir seguido de al menos un dígito.

3,96 num-punto-decimal

Descripción

Transforma una cadena numérica en un formato decimal definido por el esquema.

Tipo de entrada

ixt:numDotDecimalType

Patrón de entrada

[, 0-9]*(\[ 0-9]+)?

Tipo de salida

ixt:nonNegativeDecimalType

Transforma un número con separador de fracciones de punto («.») y separadores de dígitos opcionales en un número no negativo según el formato decimal definido por el esquema.

  • Valores numéricos positivos con un punto como separador de fracciones.
  • No se aceptan signos ni exponenciales.
  • Se permiten comas, espacios o espacios sin interrupción como separadores de dígitos opcionales.
  • Si hay un separador de fracciones, debe ir seguido de al menos un dígito.

3,97 num-unidad-decimal

Descripción

Transforma una cadena numérica en un formato decimal definido por el esquema.

Tipo de entrada

ixt:numUnitDecimalType

Patrón de entrada

([0-90-9\.]+)([^0-90-9\.,,][^0-90-9]*)([0-90-9]{1,2})([^0-90-9]*)

Tipo de salida

ixt:nonNegativeDecimalType

Transforma el valor monetario de una cadena mixta con indicadores de unidad de cadena y separadores de miles opcionales en un número no negativo según el formato decimal definido por el esquema. Admite formatos de ancho completo y medio.

  • Valores numéricos positivos con sufijos de cadena de unidades. No se aceptan signos ni exponentes.
  • Debe tener al menos un dígito antes y después del primer sufijo de cadena de unidad.
  • La parte fraccionaria está limitada a dos dígitos y se supone que está en centésimas.
  • Los valores numéricos pueden representarse mediante formatos de medio ancho o de ancho completo.
  • Se permiten punto, coma o coma de ancho completo como separadores de dígitos opcionales.
  • El sufijo de la cadena de unidad es obligatorio después de la parte entera, pero opcional después de la parte fraccionaria; por lo tanto: ‘3.000 euro 5 cent’.

3.98 num-coma-decimal-apos

Descripción

Transforma una cadena numérica en un formato decimal definido por el esquema.

Tipo de entrada

ixt:numCommaDecimalAposType

Patrón de entrada

[\.’´’′ 0-9]*(,[ 0-9]+)?`

Tipo de salida

ixt:nonNegativeDecimalType

Transforma un número con separador de fracciones coma («,») y separadores de dígitos opcionales en un número no negativo según el formato decimal definido por el esquema. Se permiten caracteres de apóstrofo como separadores de dígitos, además de los permitidos por num-comma-decimal.

  • Valores numéricos positivos con una coma como separador de fracciones.
  • No se aceptan signos ni exponenciales.
  • Se permiten puntos, espacios, espacios sin interrupción y varios signos de puntuación similares a apóstrofos como separadores de dígitos opcionales.
  • Si hay un separador de fracciones, debe ir seguido de al menos un dígito.

3,99 num-punto-decimal-apos

Descripción

Transforma una cadena numérica en un formato decimal definido por el esquema.

Tipo de entrada

ixt:numDotDecimalAposType

Patrón de entrada

[,’´’′ 0-9]*(.[ 0-9]+)?`

Tipo de salida

ixt:nonNegativeDecimalType

Transforma un número con separador de fracciones de punto («.») y separadores de dígitos opcionales en un número no negativo según el formato decimal definido por el esquema. Se permiten caracteres de apóstrofo como separadores de dígitos, además de los permitidos por num-dot-decimal.

  • Valores numéricos positivos con un punto como separador de fracciones.
  • No se aceptan signos ni exponenciales.
  • Se permiten comas, espacios, espacios sin interrupción y varios signos de puntuación similares a apóstrofos como separadores de dígitos opcionales.
  • Si hay un separador de fracciones, debe ir seguido de al menos un dígito.

3.100 num-unidad-decimal-apos

Descripción

Transforma una cadena numérica en un formato decimal definido por el esquema.

Tipo de entrada

ixt:numUnitDecimalAposType

Patrón de entrada

([0-90-9\.’´»′']+)([^0-90-9.,,’´’′'][^0-90-9]*)([0-90-9]{1,2})([^0-90-9]*)

Tipo de salida

ixt:nonNegativeDecimalType

Transforma el valor monetario de una cadena mixta con indicadores de unidad de cadena y separadores de miles opcionales en un número no negativo según el formato decimal definido por el esquema. Admite formatos de ancho completo y medio. Se permiten caracteres de apóstrofo como separadores de miles, además de los permitidos por num-unit-decimal.

  • Valores numéricos positivos con sufijos de cadena de unidad.
  • No se aceptan signos ni exponenciales.
  • Debe tener al menos un dígito antes y después del primer sufijo de cadena de unidad.
  • La parte fraccionaria está limitada a dos dígitos y se supone que está en centésimas.
  • Los valores numéricos pueden representarse mediante formatos de medio ancho o de ancho completo.
  • Se permiten puntos, comas, comas de ancho completo y varios caracteres similares a apóstrofos como separadores de dígitos opcionales.
  • El sufijo de la cadena de unidad es obligatorio después de la parte entera, pero opcional después de la parte fraccionaria; por lo tanto: ‘3.000 euro 5 cent’.

3.101 texto enriquecido con html

Descripción

Transforma un extracto HTML en un extracto HTML de texto enriquecido.

Tipo de entrada

xs:string

Tipo de salida

xs:string

Esta transformación modifica un fragmento HTML y lo convierte en un fragmento de texto enriquecido apto para visualizarse en un visualizador iXBRL. Esta transformación está diseñada para usarse junto con el @escapeatributo establecido en true.

Los elementos y atributos del fragmento HTML se conservan, eliminan o editan según el nombre del elemento. Se conserva todo el contenido de texto, incluso si no se conserva el elemento que lo contiene. Se eliminan todos los DTD, comentarios e instrucciones de procesamiento.

Se conservan los siguientes elementos en el espacio de nombres HTML:

  • a
  • b
  • bdo
  • bdi
  • br
  • caption
  • code
  • dd
  • dl
  • dt
  • em
  • h1
  • h2
  • h3
  • h4
  • h5
  • h6
  • hr
  • i
  • li
  • ol
  • p
  • pre
  • small
  • strong
  • sub
  • sup
  • table
  • tbody
  • td
  • tfoot
  • thead
  • th
  • tr
  • u
  • ul

Cualquier otro elemento en cualquier espacio de nombres no se conserva.

Se eliminan todos los atributos excepto:

  • el diratributo; y
  • atributos detallados en la tabla siguiente.

NOTA: la regla de exclusión de atributos se aplica a todos los atributos no mencionados explícitamente anteriormente, incluidos id, classy style, así como a xmlnslos atributos y xml:atributos. El xml:baseatributo es irrelevante porque las etiquetas retenidas no contienen URL relativas. Cualquier atributo dentro del alcance xml:langdebe capturarse en una languagedimensión en el hecho de destino (es responsabilidad del software de creación de informes construir etiquetas iXBRL de manera adecuada para lograr esto).

La salida se normaliza según estas reglas:

  • Todos los valores de atributos se definen mediante comillas dobles.
  • Cualquier elemento sin contenido de texto se cierra automáticamente.
  • Los atributos se ordenan lexicográficamente por nombre de atributo.
  • Hay un espacio antes de cada declaración de atributo y no hay otros espacios sintácticos en la declaración del elemento.

3.102 html-base64-img

Descripción

Fuente de imagen

Tipo de entrada

xs:string

Tipo de salida

xs:base64Binary

Esta transformación extrae el contenido base64 de una URL de esquema de datos en el valor del atributo src de un elemento img HTML.

3.103 enumeración

Descripción

Transforma XHTML escapado con títulos extensos en valores adecuados para su uso en conceptos de enumeración.

Tipo de entrada

xs:string

Tipo de salida

xs:token

La cadena de salida se ensambla tomando el valor del atributo de título en cada etiqueta span descendiente con clase -ixt-enumeration, ordenando lexicográficamente y separando con espacios, según lo requiere enum2: enumerationSetItem Type.



Trabajar desde casa potencia la productividad


Un aumento de cinco veces en el trabajo remoto desde la pandemia podría impulsar el crecimiento económico y traer beneficios más amplios

La economía tiene fama de ser una ciencia deprimente. Lamentablemente, los trabajos recientes que destacan la desaceleración del crecimiento de la productividad que se remonta a la década de 1950 no son una excepción. Pero yo tengo una visión más optimista debido a las grandes ganancias de productividad prometidas por el aumento del trabajo desde casa inducido por la pandemia.

El trabajo desde casa se multiplicó por diez tras el estallido de la pandemia y se ha estabilizado en aproximadamente cinco veces su nivel anterior a la pandemia. Esto podría contrarrestar la desaceleración de la productividad y generar un aumento del crecimiento económico en las próximas décadas. Si la IA produce más producción, la era del crecimiento lento podría haber terminado.

El análisis se basa en la descomposición del crecimiento económico que realizó el premio Nobel Robert Solow, uno de los economistas más famosos de todos los tiempos. El artículo clásico de Solow de 1957 destaca cómo el crecimiento proviene tanto del aumento de los insumos de factores como el trabajo y el capital como del crecimiento de la productividad bruta. Baso mi análisis en su marco de trabajo destacando, por turnos, cómo cada uno de estos factores promoverá un crecimiento más rápido.

Mano de obra

La forma más sencilla de ver el impacto de la mano de obra es la evidencia de las encuestas realizadas en Estados Unidos, Europa y Asia que muestran que el trabajo híbrido supone un aumento de aproximadamente el 8 por ciento en el salario. El trabajo híbrido es el patrón típico para los trabajadores de oficina, gerentes y otros profesionales, que implica generalmente dos o tres días a la semana fuera de la oficina. Para entender por qué los empleados considerarían que esto vale el 8 por ciento de su salario, tenga en cuenta que los trabajadores típicos pasan alrededor de 45 horas a la semana en la oficina, pero pasan cerca de otras 8 horas a la semana desplazándose. Por lo tanto, trabajar desde casa tres días a la semana les ahorra alrededor de cinco horas a la semana, aproximadamente el 10 por ciento de su trabajo semanal total y tiempo de viaje.

A la mayoría de las personas no les gusta viajar al trabajo, por lo que valoran aún más este ahorro de tiempo. Viajar al trabajo es la actividad más detestada del día, incluso más detestada que el trabajo en sí. Esto hace que sea fácil entender por qué el empleado promedio valora tanto trabajar desde casa, con su capacidad de ahorrar horas de dolorosos desplazamientos semanales, junto con la flexibilidad de poder vivir más lejos del trabajo.

Este valor del trabajo desde casa tiene un poderoso impacto en la oferta laboral. En la economía global hay decenas de millones de personas que están al borde de la fuerza laboral, por lo que pequeños cambios en el atractivo del trabajo pueden hacer que muchos millones de ellas obtengan empleo. Esta fuerza laboral marginal incluye a quienes tienen responsabilidades de cuidado de niños o ancianos, a quienes están cerca de jubilarse y a algunas personas en áreas rurales.

Un ejemplo de este impacto del trabajo desde casa en la oferta laboral son los aproximadamente 2 millones de empleados con discapacidad que están trabajando en los EE. UU. después de la pandemia. Estos aumentos en el empleo de personas con discapacidad se han producido principalmente en ocupaciones con un alto nivel de trabajo desde casa. Los empleados con discapacidad se benefician de dos maneras: primero, al evitar largos desplazamientos y segundo, al poder controlar su entorno de trabajo desde casa.

Otro ejemplo es el empleo femenino en edad productiva en Estados Unidos, que ha aumentado aproximadamente un 2 por ciento más rápido que el empleo masculino en edad productiva desde la pandemia. El mayor papel de las mujeres en el cuidado de los niños podría estar impulsando este aumento en la participación femenina en la fuerza laboral a través del trabajo desde casa, según una investigación reciente.

En conjunto, estos efectos podrían incrementar la oferta laboral en varios puntos porcentuales.

Por supuesto, este cálculo toma como base la población actual. A largo plazo, el trabajo desde casa también podría aumentar las tasas de fertilidad. Una historia que he escuchado repetidamente al hablar con cientos de empleados y gerentes es cómo el trabajo remoto facilita la crianza de los hijos. Esto es quizás más evidente en el este de Asia, donde las largas jornadas laborales, los agotadores desplazamientos y las intensas presiones parentales han llevado a una rápida caída de la fertilidad. Si los padres pueden trabajar dos o tres días a la semana en casa, en particular con horarios flexibles que les permitan compartir las responsabilidades parentales, esto podría aumentar las tasas de natalidad. Un análisis preliminar basado en datos de encuestas de EE.UU. sugiere que quizás se deseen tener entre 0,3 y 0,5 hijos más por pareja cuando ambos trabajan desde casa un día o más a la semana.

Capital

El impacto beneficioso del trabajo desde casa sobre el capital proviene de la liberación a largo plazo de espacio de oficina para otros usos, como el residencial y el comercio minorista. Si los empleados trabajan desde casa dos o tres días a la semana, la sociedad necesita menos espacio de oficina, y ese espacio se puede utilizar para otras actividades. También reduce el tráfico de los desplazamientos, lo que frena la necesidad de infraestructura de transporte adicional. Un uso más intensivo de nuestro capital doméstico (el espacio y el equipamiento de nuestras casas y apartamentos) puede permitir a la sociedad ahorrar en el uso de transporte y capital de oficina, que se puede redistribuir a otros usos. En los principales centros urbanos, aproximadamente la mitad del terreno está cubierto de espacio de oficina, y dado que la ocupación de oficinas es ahora un 50 por ciento inferior a los niveles anteriores a la pandemia, existe un gran potencial de reducción del espacio de oficina.

Datos recientes sobre velocidades de conducción muestran que el tráfico ahora se mueve alrededor de 2 o 3 millas por hora más rápido durante el viaje matutino, lo que reduce la necesidad de infraestructura de transporte adicional y le ahorra al viajero típico unos minutos al día.

A largo plazo, permitir que los empleados trabajen de forma parcial o total a distancia también libera terrenos actualmente infrautilizados para la construcción de viviendas, lo que aumenta de manera efectiva la oferta de terrenos utilizables. Muchas ciudades importantes están muy congestionadas porque la mayoría de los empleados no quieren vivir a más de una hora de viaje del centro. Si solo se les requiere que trabajen un par de días a la semana, se les permite realizar desplazamientos más largos, lo que libera espacio más alejado de los centros urbanos para el uso de viviendas.

En conjunto, estas contribuciones de capital también podrían incrementar la producción en un pequeño porcentaje en las próximas décadas.

Productividad

Los estudios microeconómicos clásicos de empresas e individuos suelen concluir que el trabajo híbrido, el patrón habitual de aproximadamente el 30 por ciento de las fuerzas laborales de Estados Unidos, Europa y Asia, tiene un impacto más o menos uniforme en la productividad. El trabajo desde casa beneficia a los trabajadores al ahorrarles agotadores desplazamientos y, por lo general, proporciona un entorno de trabajo más tranquilo. Pero, al reducir el tiempo en la oficina, también puede reducir la capacidad de los empleados para aprender, innovar y comunicarse. Estos efectos positivos y negativos se compensan entre sí, por lo que no generan un impacto neto en la productividad del trabajo desde casa híbrido, según sugiere la investigación.

El impacto del trabajo totalmente remoto, que ha sido adoptado por alrededor del 10 por ciento de los empleados, depende en gran medida de lo bien que se gestione. Algunos estudios que examinaron el trabajo totalmente remoto durante los primeros días de la pandemia encontraron grandes impactos negativos, posiblemente debido al caos de los primeros confinamientos. Otros estudios encontraron grandes impactos positivos, generalmente en actividades más autodirigidas, como el trabajo en centros de llamadas o de ingreso de datos en empresas bien administradas.

En resumen, el impacto del trabajo totalmente remoto es tal vez neutro, porque las empresas tienden a adoptarlo solo cuando esas modalidades de trabajo coinciden con la actividad laboral (a menudo, tareas como codificación o soporte informático, realizadas por empleados capacitados en un entorno controlado). Pero si bien los impactos micro productivos en cualquier empresa individual pueden ser neutros, el enorme poder de la inclusión en el mercado laboral significa que el impacto macroeconómico agregado probablemente sea positivo.

Para explicar los beneficios de la inclusión en el mercado laboral, hay que tener en cuenta que los puestos de trabajo totalmente presenciales solo pueden ser ocupados por empleados que se encuentren cerca. Por ejemplo, un puesto de recursos humanos o de tecnología de la información en Nueva York solo puede ser ocupado por un residente local. Incluso si hay personas en Bulgaria, Brasil o Belice que serían más adecuadas, no pueden realizar el trabajo si no están allí en persona. Pero tan pronto como los puestos se pueden cubrir de forma remota, los empleadores pasan de contratar al mejor empleado local a contratar al mejor empleado regional para el trabajo híbrido y al mejor empleado global para el trabajo totalmente remoto.

Estudios recientes sobre discriminación y reasignación de puestos de trabajo destacan cómo la expansión de los mercados laborales a un grupo más amplio de empleados potenciales puede tener enormes beneficios para la productividad. Pasar de 10 a 10.000 candidatos calificados para un puesto permite una combinación mucho más productiva, en particular si la IA puede ayudar a seleccionar a los solicitantes. El trabajo remoto permite la combinación global entre empleados y empresas, lo que impulsa la productividad laboral.

Otro beneficio macro de la productividad del trabajo desde casa es su impacto positivo en la contaminación del transporte. Se estima que el aumento del trabajo desde casa ha reducido los volúmenes de tráfico en los desplazamientos diarios en Estados Unidos y Europa en un 10 por ciento. Esto ha reducido la contaminación, en particular las emisiones de partículas pesadas de bajo nivel. Los estudios de salud han vinculado la contaminación con daños cognitivos y de productividad. Reducir la contaminación no solo mejora nuestra calidad de vida, sino que también puede aumentar el crecimiento.

Bucle de retroalimentación positiva

Un ciclo de retroalimentación positiva (desde el trabajo desde casa hasta un crecimiento más rápido y viceversa) potencia estos impactos. Una larga historia de efectos del tamaño del mercado en economía destaca cómo las empresas se esfuerzan por innovar para atender a mercados más grandes y lucrativos. Cuando se pasa de 5 millones a 50 millones de personas que trabajan desde casa todos los días, las principales empresas de hardware y software, las empresas emergentes y los financiadores toman nota. Esto conduce a una aceleración de nuevas tecnologías para atender a esos mercados, mejorando su productividad y crecimiento.

Ese ciclo de retroalimentación ya ha comenzado. La proporción de nuevas solicitudes de patentes en la Oficina de Patentes y Marcas de Estados Unidos que utilizan repetidamente términos como “trabajo remoto”, “trabajo desde casa” o similares se mantuvo estable hasta 2020, pero ha comenzado a aumentar (véase el gráfico 2). Esto pone de relieve la mejora de las tecnologías. Mejores cámaras, pantallas y software y tecnologías como la realidad aumentada y virtual y los hologramas aumentarán la productividad del trabajo híbrido y remoto en el futuro. Esto generará un ciclo de retroalimentación positivo entre el crecimiento y el trabajo desde casa.

Una crítica al auge del trabajo desde casa es el daño que ha causado a los centros urbanos. Es cierto que el gasto en comercios minoristas ha caído en los centros urbanos, pero esta actividad se ha trasladado a los suburbios y el gasto de consumo general ha recuperado su tendencia anterior a la pandemia. Tal vez lo más problemático sea la gran reducción de las valoraciones de los espacios de oficinas comerciales. Aunque esto representa una pérdida de valoración para los inversores en el sector de oficinas, la liberación de espacio en el centro de la ciudad para uso residencial hará que, a largo plazo, la vida en el centro sea más asequible. El coste de la vida en la ciudad aumentó drásticamente en los años 1990 y 2000, lo que hizo que muchos empleados de ingresos medios y bajos no pudieran trabajar en los centros urbanos. Esto es especialmente problemático porque muchos de estos trabajadores prestan servicios esenciales, como bomberos, policía, enseñanza, atención sanitaria, alimentación, transporte y otros trabajos que solo se pueden realizar en persona. Reducir la cantidad de espacio para uso de oficinas en los centros urbanos y convertirlo en uso residencial haría que la vivienda fuera más asequible para estos trabajadores esenciales.

El aumento del teletrabajo en 2020 ha ayudado a compensar la desaceleración de la productividad previa a la pandemia y está impulsando el crecimiento presente y futuro. Ser economista generalmente significa equilibrar ganadores y perdedores. Analizar los cambios en la tecnología, el comercio, los precios y las regulaciones suele tener efectos mixtos, con grandes grupos de ganadores y perdedores. Cuando se trata de trabajar desde casa, los ganadores superan ampliamente a los perdedores. Las empresas, los empleados y la sociedad en general han cosechado enormes beneficios. En mi vida como economista, nunca he visto un cambio que sea tan beneficioso en términos generales.

Esto me deja en la inusual situación de ser un “científico deprimente” optimista, pero es una situación en la que me siento feliz mientras escribo esto mientras trabajo desde casa. 

Trabajar desde casa no era una opción para la mayoría de las personas antes del 11 de marzo de 2020, cuando la vida laboral y familiar colisionaron de repente. había estudios sobre el impacto potencial del trabajo remoto mucho antes de que la pandemia lo lanzara a la sociedad y ahora tiene datos que sugieren que las empresas deberían ceñirse al modelo de trabajo híbrido.