El standard obligatorio XBRL. Alguién ya sabe algo al respecto

[rolandoj]

Hola a todos,

En Colombia está cerca de entrar en vigencia la obligatoriedad de exportar la información financiera de los programas contables usando el lenguaje standard XBRL (una variación de XML).

El tema se ha planteado desde hace años. Busqué en ocasiones anteriores sin hallar nada, así que pensé esperar que el tema madurara suponiendo que en algú momento habría información para Delphi; pero, buscando ahora de nuevo en los foros, encuentro solo 3 notas que lo mencionan y en las tres nadie parece saber nada al respecto,

La busqueda en internet tampoco ha reflejado nada relacionado con Delphi.

Lo que he hallado en google al parecer estaría indicando de que en últimas no sería un problema para los contadores porque tomarían la información de los sistemas contables y harían sus informes en Excel. Sobre Excel pueden usar herramientas libres para generar XBRL.

Si bien eso da cierta tranquilidad, no tiene presentación profesional que no exportemos los reportes de nuestros aplicativos directamente a XBRL, ya que estaríamos obligando a los usuarios a hacer un procesamiento manual innecesario y quizás potencialmente largo,

Me llama la atención que el standard supuestamente es internacional; pero, nadie parece saber al respecto.

Alguno de ustedes pued aportar algo ?

Gracias de antemano.

Muchos saludos

[dec]

Hola,

No sé si voy a ayudarte en algo, pero, si estamos hablando de un formato que parte de XML, desde Delphi sería posible tanto leerlo como escribirlo, puesto que contamos con componentes como el "TXMLDocument". Entonces, ¿qué problema existe? Quiero decir, si se trata de un formato más o menos estandarizado, estaríamos hablando de leer la especificación/documentación y generar el archivo XML correspondiente desde Delphi. ¿En qué me estoy equivocando o qué estoy dejando pasar por alto?

[rolandoj]

Empezado por dec

Hola,

No sé si voy a ayudarte en algo, pero, si estamos hablando de un formato que parte de XML, desde Delphi sería posible tanto leerlo como escribirlo, puesto que contamos con componentes como el "TXMLDocument". Entonces, ¿qué problema existe? Quiero decir, si se trata de un formato más o menos estandarizado, estaríamos hablando de leer la especificación/documentación y generar el archivo XML correspondiente desde Delphi. ¿En qué me estoy equivocando o qué estoy dejando pasar por alto?

Hola,

Gracias por la sugerencia.

El hecho de que parta de XML no necesariamente significa que en últimas sea XML. Ni sqiuiera he podido encontrar a alguien explicando las diferencias, así que no podría asegurar que el componente XML de Delphi pueda generar XBRL.

Ciertamente, leyendo la especificación completa y comparando la de XML podríamos decirlo, y por supuesto, en últimas, podríamos crear nuestro propio componente; pero, en ese caso nos estaríamos poniendo en el papel de creadores de componente; y podría ser tanto como tener que hacer nuestro propio componente XML

En mi caso, si bien puedo hacer eso, representa un tiempo de investigación, y quizás desarrollo, potencialmente largo; algo indesable ya que no tengo mucho tiempo disponible.

Lo que estoy esperando es que alguien haya desarrollado un compoente para eso o al menos una guia de como hacerlo con el componente XML si es que se puede.

Saludos

[jhonny]

¿Dónde se encuentra la documentación oficial y final de dicho formato?, ¿Sabes de cuando comienza a ser realmente obligatorio?, perdón por responder preguntando, lo que ocurre es que es un tema que me interesa también y del cual no tengo mucha documentación.

[[gatosoft]]

Empezado por rolandoj

Ciertamente, leyendo la especificación completa y comparando la de XML podríamos decirlo, y por supuesto, en últimas, podríamos crear nuestro propio componente; pero, en ese caso nos estaríamos poniendo en el papel de creadores de componente; y podría ser tanto como tener que hacer nuestro propio componente XML

Si estas trabajando en un producto contable/financiero, necesariamente debes pensar en la posibilidad desarrollar tus porpios componentes en algún momento. O lo que terminan haciendo casi todas las empresas de software: Su propio framework.

Y si.. XBRL es XML puro... no debes generar un compnente nuevo XML, solo utilizar lo que hay y generar el archivo bajo ciertas reglas (el estandar)

Johnny, la documentación oficial está en XBRL.org, pero tambien puedes remitirte a la página española

y para Colombia, la información la maneja el ministerio de hacienda.

Si les parece miramos como hacer un proyecto de codigo abierto en GitHub para este.. aunque les confieso que ahora esty mirando mas Facturación electrónica que es lo que se viene.

un saludo,

[jhonny]

Empezado por gatosoft

Johnny, la documentación oficial está en XBRL.org, pero tambien puedes remitirte a la página española

y para Colombia, la información la maneja el ministerio de hacienda.

Si les parece miramos como hacer un proyecto de codigo abierto en GitHub para este.. aunque les confieso que ahora esty mirando mas Facturación electrónica que es lo que se viene.

un saludo,

Gracias gatosoft por la información, estoy de acuerdo que hay que enfocarse ahora en la facturación electrónica. En cuanto al formato XBRL y hacerlo en conjunto en código abierto, ahora mismo lo veo muy difícil, pues las prioridades como señalas realmente son otras y para hacerlo como código abierto (Y seguramente gratuito sabiendo que lo necesitan empresas que sí pueden pagar un buen precio por esto), sinceramente no creo que suceda eso en mucho tiempo.

[[Delphius]]

La verdad es que no entiendo a que pretendes con el hilo.
El xml no es más que un archivo plano escrito con y siguiendo cierta estructura que uno defina.
El XBRL del que hablan, y de lo estoy viendo de la documentación no deja de ser lo mismo. Data organizada en una estructura que unos tipos locos impusieron como "estándar".

Si el componente que ofrece Delphi no te es suficiente, se lo puede hacer a mano. Te pones a escribir en un TStrings cualquiera, linea a línea siguendo la documentación del estándar y al finalizar lo guardas y listo. Ya tienes generado el archivo listo para ser enviado, compartido, o lo que fuese.
O te encargas de hacer un Adapter que envuelva al TXMLDocument (que sería lo más apropiado)
En fin: que la cosa se resume a que si no hay nada hecho, pues ¡Hazlo tu! Da ese paso, arriesgate. Se el primero, y quien sabe, hasta podrías sacarle algunos billetes y licenciarlo a otros desarrolladores. ¿Cuál es el problema? ¿O no le entiendes al estándar?

Lo lindo que tiene Delphi es que puedes hacer tus propios componentes, tu propia suite, tu propio framework.
Pretender ser sólo un simple albañil que se limita a poner componentes, y que peor... esperar a que alguien haga algo que te "facilite la vida", no te va a llevar demasiado lejos. En algún punto deberás dar ese paso adicional y hacer los tuyos propios. La experiencia que se gana así es mayor.

¿Cual es el miedo? ¡Si la documentación esta! Entiendo tu punto de querer ahorrarte "reinventar la rueda" si alguien ya lo hizo. Es lógico, entendible, y hasta es todo un paradigma: Desarrollo basado en componentes. Lo hacemos todos, tu, yo... hoy en día no creo que se salve nadie.
La cuestión es que hay que entender que no se puede vivir siempre de soluciones de terceras partes.
Y el mayor peligro de basar todos nuestros trabajos (o la mayor parte de éstos), en terceros, es que en el día de mañana si se discontinúa quedas parado.

Si ya estuviste explorando posibilidades y te confirmaste que no hay algo disponible y directo en Delphi, deberás dedicarle el tiempo y sentarte a hacer el esfuerzo adicional. La pregunta, quizá un tanto fuerte y brusca: ¿A que viniste? ¿Cual es el objetivo del hilo? Sabes que en CD no se hacen los trabajos a nadie... Si vas a esperar a que uno de acá te haga el componente que no existe, y hasta incluso según a como te lo imaginas que debiera ser... la tienes difícil.
Además, no siempre las soluciones de terceros (sean componente, units, etc) se ajustan tan fácilmente a nuestros trabajos. Sobre todo si uno ya tiene sus propios frameworks o unidades de propósito general. Cuando se da esto lo habitual es poner un Adapter o un Wrapper sobre el componente de terceros y que el intermediario ofrezca una interfaz a modo Fachada adecuada y que sea "compatible" con lo nuestro.

De todas formas vas a "perder tiempo" a leer el estándar para entender como es la cosa. Ya sea que elijas hacer el trabajo por ti mismo, o bien que uses algo de terceros. Es inevitable. Soluciones mágicas no las hay.

Lamento dar malas vibras, se que no he dicho algo nuevo y que no se haya dicho. Simplemente acoto que resulta extraño tu pedido... Parece como si te estuvieras dudando de como entrarle. Ponte firme. Y si lo quieres y necesitas, pues eso: Hazlo. ¡YA!

Saludos,

[[gatosoft]]

Buen día Rolando,

Primero que todo, estoy de acuerdo con DEC, XBRL es una "particularización" de un archivo XML, por tanto en Delphi existen los componentes y los métodos para trabajarlos. El tema es que debes revisar el estándar y ver que debes implementar.

Por otro lado, en colombia, solo comenzará a regir para NIIF plenas, y conozco muchas empresas grandes que prefieren adopatr NIIF pymes antes de meterse en camisa de once varas. Personalmente estuve en un proceso donde una empresa cambió de parecer ante las exigencias de la norma.

No conozco el estandar pero creo que si quieres implementarlo debes estudiarlo bastante y ponerte a implementarlo, pues para Delphi no creo que hayan componentes o una API disponible como si las hay para otros lenguajes.

Para el caso de Colombia, veo que el tema (al igual que la facturación electrónica) se va a manejar en reserva en las casas de software pues es por ahora ventaja competiviva.

Un saludo,