Publicado el 2 de diciembre de 2023 por Editor
La Comisión de Bolsa y Valores de EE. UU. (SEC) ha lanzado una actualización de su Interactive Data Test Suite, accesible aquí.
El objetivo principal de Interactive Data Test Suite es ayudar a los desarrolladores de software a validar los datos interactivos antes de enviarlos a EDGAR. Esta suite comprende numerosas instancias pequeñas de datos interactivos, esquemas y bases de enlaces.
En la última versión (23.4), el sistema EDGAR ahora admitirá la nueva taxonomía FND con las versiones 2022 y 2023. Además, nuevos tipos de envío, a saber, S-6, S-6/A, N-8B-2, N-8B. -2/A y 487 se han añadido a la lista de documentos Inline XBRL aceptados.
Se anima a los desarrolladores y declarantes a explorar estas actualizaciones y utilizar Interactive Data Test Suite para identificar y corregir oportunamente posibles errores antes del envío real a EDGAR.
Explora la actualización aquí.
SUITE DE PRUEBAS DE DATOS EDGAR SEC EE.UU.
Conjunto de pruebas públicas de datos interactivos
Versión 68d-231120
1. Metas
El propósito del conjunto de pruebas públicas es ayudar a los desarrolladores de software que deben validar los datos interactivos antes de su envío a EDGAR. El conjunto de pruebas consta de muchas instancias pequeñas de datos interactivos, esquemas y bases de vínculos que se clasifican en función de si infringen una comprobación de validación y, en caso afirmativo, qué comprobación de validación infringen y si eso daría lugar a una advertencia o a un error que haría que se rechazaran los datos interactivos.
Los declarantes que adjunten Pruebas Documentales de Datos Interactivos a las presentaciones de EDGAR son responsables del cumplimiento de todas las validaciones en el Capítulo 6 del Volumen II del Manual de Declarantes de EDGAR («el Manual»). La validación automatizada mediante software de preparación puede hacer que sea más eficiente para los declarantes verificar el cumplimiento antes de enviar sus presentaciones a EDGAR. Nada en este conjunto de pruebas tiene la intención de crear nuevos requisitos o cambiar los requisitos existentes para las presentaciones de EDGAR; los declarantes deben consultar las reglas de la Comisión y el Manual para conocer los requisitos de presentación.
La organización del conjunto de pruebas sigue la del Capítulo 6 del Manual. El Capítulo 6 consta de subsecciones que detallan una o más validaciones de Datos Interactivos, y estas subsecciones individuales se agrupan en secciones según el tipo de archivo adjunto (instancia, esquema o base de enlaces) y si las validaciones pueden automatizarse completamente (llamadas secciones de «sintaxis») o si se ocupan de las relaciones que pueden requerir alguna revisión manual o juicio contable (llamadas secciones «semánticas»).
2. Notación
En este documento, los nombres de ruta de acceso utilizan barras diagonales, aunque las pruebas funcionan en cualquier sistema operativo.
3. Versiones
El número de versión principal «68d» se refiere a una versión específica del Manual (borrador o de otro tipo) y el número de versión secundaria «231120» es la fecha de la versión secundaria, formateada como AAMMDD.
4. Instalación
La suite se distribuye como un archivo en formato zip. Extraiga todo el contenido en cualquier ubicación conveniente, conservando las rutas de las carpetas. Contiene una carpeta de nivel superior que corresponde a la versión del Manual.
Todos los archivos están codificados como formato de transmisión universal de 8 bits (UTF-8) o ASCII de EE. UU. El sufijo «.xsd» indica un archivo de esquema XML, «.xsl» indica una hoja de estilo XML (XSL) y el sufijo «.xml» indica cualquier otro tipo de archivo XML.
No hay ejecutables en el archivo de formato zip, excepto para los archivos XSL 1.0 en las subcarpetas «lib» y «conf».
El archivo index.htm es un archivo creado para facilitar la navegación por los archivos de prueba; Resalta los archivos de casos de prueba que contienen comentarios que pueden ayudar a los desarrolladores.
5. Biblioteca
La carpeta «lib» contiene datos de referencia y definiciones utilizadas en varias ubicaciones de la carpeta conf.
5.1 Archivos DTD y ENT
Un archivo de definición de tipo de documento XML (DTD) y tres archivos de declaración de entidad XML (ENT) que se utilizan para validar el contenido sin escape de los bloques de texto y las notas al pie XBRL.
Un bloque de texto es un elemento XML cuyo tipo es «textBlockItemType» en un espacio de nombres que comienza por «http://xbrl.us/us-gaap/».
Una nota al pie XBRL es un elemento XML denominado «footnote» en el espacio de nombres «http://www.xbrl.org/2003/linkbase».
5.2 Esquemas y hojas de estilo
Los archivos test.xsd, testcases.xsl y test.xsl se utilizan para validar y ver archivos *-testcase.xml en un navegador, respectivamente. Todos los elementos están en el espacio de nombres http://edgar/2009/conformance.
6. Casos de prueba
Un archivo de caso de prueba es un archivo XML utilizado por los desarrolladores de software. Los nombres de archivo, los conjuntos de archivos que se van a procesar juntos y los resultados esperados de ese procesamiento. El archivo XML del caso de prueba normalmente se transforma para producir un script de comandos de shell; El script de comando resultante invoca un validador en un archivo de cada variación y almacena el resultado de esa validación. Cuando un validador produce resultados idénticos a los esperados, se dice que es «conforme».
Todos los casos de prueba y sus archivos de prueba se encuentran en la carpeta «conf». Los casos de prueba se agrupan por sección con un esquema de código de ordenación que corresponde al número y título de la sección, por ejemplo:
6.1 Elementos requeridos
Estos elementos nombran a la parte responsable del caso de prueba, que para este conjunto de pruebas es siempre la Oficina de Divulgación Estructurada (OSD) de la SEC.
6.2 Elemento requerido
Por convención, este es el patrón de código de ordenación «6[0-9]{2}-[0-9]{2}», el código de ordenación de una sección como se ha descrito anteriormente. «605-22» significa la sección 6.5.22.
6.3 Elemento requerido
El esquema restringe esto para que contenga una cadena específica que proporcione una referencia legible al Manual: • EDGAR Filer Manual v{versión} 6. {sección}. {subsección} página 6-{página}
6.4 Elemento requerido
Este elemento tiene el texto de la sección correspondiente del Manual, pero solo como referencia; El Manual de Archivadores EDGAR Volumen II v53 es normativo. A veces, este elemento también contiene adiciones entre paréntesis, como (OBSERVACIÓN…) que indica algún detalle de implementación o comentario relacionado, o (TODO …) que indica una brecha de cobertura conocida u otra deficiencia en una versión preliminar.
6.5 Elemento de repetición opcional
Puede haber cualquier número de elementos de referencia, pero cada uno debe tener @specification de atributo que contenga cualquier cadena útil.
7. El elemento
Cada caso de prueba contiene una o más variaciones. Cada variación expone solo un aspecto de la validación que se va a realizar: una variación «no buena» que está destinada a desencadenar exactamente un error de validación o, a veces, una variación «buena» que está destinada a ilustrar el caso base o un caso extremo.
Todos los elementos secundarios que denotan nombres de archivo deben tener contenidos distintos dentro de una sola variación. Por ejemplo, el archivo «this.txt» no puede aparecer como ambos y como.
7.1 Atributo requerido
@id de Por convención, tiene el formato «_[0-9]{3}((gd)|( ng)|(gw))» En el que «GD» siempre indica una variación buena (válida), «NG» indica una variación no buena (no válida o que desencadena un error) y «GW» indica que esta variación es buena con advertencia. Una variación «gw» está pensada como un ejemplo de un envío, que se aceptará con advertencias, donde un envío de tipo «ng» se suspenderá (no se aceptará).
7.2 Elemento requerido de
Contiene texto sin formato de forma libre, aunque por convención comienza con el número de sección y termina con el token GOOD o NOGOOD. Por ejemplo, estos son los nombres de las variaciones en el esquema 605-01-entity-identifier-scheme.
7.3 Elemento requerido de
Contiene texto sin formato de forma libre; De nuevo, por convención, a menudo duplica el contenido del elemento name sin el prefijo numérico, y siempre es breve
7.4 Elemento de repetición opcional de
Puede haber cualquier número de elementos de referencia, pero cada uno debe tener @specification de atributo que contenga cualquier cadena útil.
7.5 Elemento requerido de
El elemento de datos agrupa los archivos de datos interactivos en la variación. Esto tiene instancias, bases de enlaces y esquemas. Aunque, en principio, el conjunto de archivos locales del conjunto de taxonomía detectable (DTS) de la instancia se puede detectar desde la instancia, los archivos de casos de prueba también sirven como una especie de manifiesto para garantizar que un conjunto de archivos esté completo sin contenido superfluo.
7.5.1 Elemento de repetición opcional de
A veces, la validación requiere una entrada externa. Por ejemplo, EDGAR utiliza el número de clave de índice central (CIK) para identificar a los declarantes.
Por ejemplo, las variaciones en el caso de prueba 605-02-entity-identifier-match-cik requieren que se proporcione el CIK del envío como parámetro para la validación de una instancia.
7.5.2 Atributo requerido @name de
Un QName que es el nombre del parámetro. En este conjunto de pruebas, el contenido de QName debe tener el espacio de nombres vacío.
7.5.3 Atributo requerido @datatype de
Un QName que es el tipo de datos del parámetro, normalmente xs:string
7.5.4 Atributo requerido @value
Cadena que se convierte en el tipo de datos especificado y se pasa al validador.
7.5.5 Nombres, tipos y valores de parámetros actualmente en uso
7.6 Elemento de repetición opcional
El nombre de archivo de un tipo de archivo que no es de imagen y que no está relacionado con XBRL. Su nombre de archivo puede ser cualquier nombre de archivo compatible con EDGAR que termine en .txt, .htm o .pdf, y está destinado a indicar que el archivo es el documento principal de una presentación de EDGAR.
7.6.1 Atributo opcional @docType de
El tipo de documento (en el sentido de presentación EDGAR) del documento, por ejemplo, «10-K», «485BPOS».
7.7 Elemento requerido
El nombre de archivo local de la instancia debe ser un nombre de archivo compatible con EDGAR (menos de 24 caracteres, etc.). Por convención, el nombre tiene el siguiente formato:
e6{sección}{sección} [0-9]{3} ((gd)|( ng))-200(8|9)1231.xml
Por ejemplo, e60501001ng se refiere a una instancia no buena que viola la sección 6.5.1 del Manual.
7.9 Elemento de repetición opcional
Cada variación tiene bases de enlaces nombradas con la misma convención de nomenclatura que la instancia.
Muchas variaciones de casos de prueba tienen un conjunto de bases de enlaces comunes denominadas edgar-20081231_*.* o edgar-20091231_*.*. Los archivos de base de enlaces con el mismo nombre «edgar-» difieren de una carpeta a otra.
7.10 Elemento de repetición requerido
Cada variación tiene al menos un esquema con su propio conjunto de bases de enlaces denominadas con la misma convención de nomenclatura que la instancia.
7.11 Elemento de repetición opcional
El nombre de archivo de un tipo de archivo que no es de imagen y que no está relacionado con XBRL. Su nombre de archivo puede ser cualquier nombre de archivo compatible con EDGAR que termine en .txt, .htm o .pdf, y está destinado a indicar que el archivo es un documento no principal de una presentación EDGAR.
7.11.1 Atributo opcional @docType de
El tipo de documento (en el sentido de presentación EDGAR) del documento, por ejemplo, «10-K», «485BPOS».
7.12 Elemento requerido
Para una variación «no buena», el elemento result contiene al menos un elemento.
Para una variación «buena», el elemento result puede contener un elemento.
De lo contrario, el elemento está vacío.
7.12.1 Atributo opcional @expected de
Cuando el resultado esperado va a ser válido sin advertencias u otros mensajes, el atributo @expected puede tener el valor «value».
7.13 Elemento de repetición opcional
El elemento assert contiene información que se utiliza para agrupar información sobre el mensaje de error o advertencia que se espera tras la validación.
8. El elemento
El elemento assert declara la gravedad, la sección EFM asociada y el código de error mnemotécnico que se va a generar. El elemento permite que aparezcan otros atributos que el autor de la variación pueda considerar útiles1.
8.1 Atributo requerido @severity de
Hay dos valores, el más común es «err» y el otro «wrn» significa una advertencia. En el sistema EDGAR, una advertencia no hace que los archivos XBRL se eliminen de un envío; Un error sí.
8.2 Atributo requerido @num de
La sintaxis es la misma que la del contenido del elemento sin el guión. No es idéntico porque en casos excepcionales el @num puede diferir del archivo de caso de prueba donde aparece, como por ejemplo cuando un error no podría ocurrir sin desencadenar otro.
8.3 Atributo requerido @name de
Un código mnemotécnico con tokens de mayúsculas y minúsculas adecuadas separados por guiones, como «No-Presentation-Order». Los tokens son estrictamente mayúsculas y minúsculas, por ejemplo, «No-Xml-Base-Allowed» incluso para el error relacionado con el atributo «xml: base», o «Illegal-Html» para errores relacionados con HTML.
8.4 Atributo opcional @frd de
Un código de dos letras para un grupo relacionado de aserciones; esto aparece en los códigos de error informados por EDGAR, como «60515-cp-No-Xml-Base-Allowed».
8.5 Atributo opcional @countSatisfied de
Con un valor predeterminado de 0, indica el número de aserciones satisfechas en la variación.
8.6 Atributo opcional @countNotSatisfied de
Si se establece de forma predeterminada en 1, indica el número de infracciones de aserción en la variación.
9. Notas sobre la estructura de carpetas y los detalles del archivo
Hay algunas excepciones a la asignación de las subsecciones Manual al conjunto de pruebas. No hay casos de prueba para las secciones del manual marcadas como «Reservado».
En este momento, hay una cobertura incompleta de estas secciones de sintaxis del Manual:
• 603-filing-syntax (algunas subsecciones requieren información como el tipo de archivo adjunto (EX-100, EX-101) que no está disponible en el contenido de los propios archivos XBRL. Algunas de estas variaciones de prueba están contenidas en el directorio, esto, lo que significa que son solo para pruebas del sistema EDGAR y no se pueden validar mediante pruebas fuera de línea).
• No hay pruebas separadas para 605-06, 605-18, 605-26, 607-02, 607-05, 607-06, 609-02, 609-08, 610-07 o 612-04 porque estas secciones no tienen sus propios códigos de error únicos.
Dos archivos de la carpeta 603-04-no-html-character-entities no tienen un XML bien formado; Esto es intencional (E60304001NG, E60304002NG-20081231_lab.xml).
No hay cobertura de estas secciones semánticas porque en este momento no dan lugar a mensajes de advertencia o error EDGAR:
• Semántica de 606 instancias
• Semántica de esquema 608
• 611-semántica de etiquetas
• 613-presentación-semántica
• 615-semántica de cálculo
• 617-definición-semántica
• Semántica de referencia 619
No existen tales subsecciones 6.22.1 a 6.22.4 en el Manual; Estos corresponden, respectivamente, a las tres cuestiones tratadas en la sección 6.22 y al contenido actual del http://www.sec.gov/info/edgar/edgartaxonomies.xmlexpediente
El formulario SDR aparece en el Manual del Declarante EDGAR en el Capítulo 9. El formulario SDR difiere de otros formularios porque permite múltiples instancias XBRL, requiere diferentes nombres de prueba (EX-99. K DEG. INS, por ejemplo, en lugar de EX-101. INS) y varios otros archivos adjuntos .txt y .xml. Las variaciones de prueba específicas para el formulario SDR se encuentran en una carpeta separada y tienen nombres que apuntan al archivo principal del caso de prueba en el Capítulo 6. Por ejemplo, las variaciones de prueba específicas del formulario SDR que son una continuación de 6.3.2 se encuentran en este archivo:
• 902-sdr/60302-sdr-doctype/902-sdr-60302-sdr-doctype-testcase.xml
Los elementos secundarios de apuntan a subcarpetas separadas para cada variación, por ejemplo:
Publicado originalmente: https://www.xbrl.org/news/sec-updates-interactive-data-test-suite-2/