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]]

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,

[[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,

[rolandoj]

Empezado por 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,

Hola a todos,

Gracias por los comentarios que han hecho.

Delphius, como te tomastes tú tiempo para exponer tú opinión sobre el rumbo a seguir, te explico la situación.

Mi problema no es técnico de hacer el componente, ni para ganar experiencia. Yo tengo muchísima experiencia haciendo componentes, Hacer uno más no me aporta nada en ese sentido.

De hecho, salvo una que otra excepción, correspondiente a cosas cuyo desarrollo toma demasiado tiempo, no uso componentes de terceros que no vengan con Delphi.

Entre otras cosas, porque comparto plenamente lo que dices de que depender de un tercero es un problema, así que evito hacerlo en la medida de lo posible.

Es más, siguiendo tú línea crítica, te diré que otra de las razones para haber trabajado en lo posible desde cero ha sido porque hace años que las versiones de Delphi optaron por reinventar la rueda y en cada nueva versión pretendían que, para usar sus nuevos desarrollos, uno reescribiera montones de código que ya funcionaba bien y migrara todo a la "tecnología de moda" que tuvieran. Eso es manejable para estudiantes universitarios o personal académico, o para quienes trabajan en una sola línea; pero, no para los independientes que tenemos muchas líneas de aplicativos comerciales conceptualmente muy distintos

Y ciertamente no parece haberles funcionado bien porque a estas alturas siguen ofreciendo cursos de como migrar desde BDE !!

Volviendo al tema principal, el punto es que ahora estoy atendiendo yo solo varios frentes que funcionalmente son mucho más importantes. Lo de XBRL es una exigencia gubernamental que al tipo de clientes que tengo no les aporta ningún beneficio. Invertirle tiempo para desarrollarlo desde cero no solo no me aporta beneficios, ni académicos ni económicos, ya que mi negocio no es la venta de componentes; sino que encima me complica la vida porque afectaría el tiempo que necesito para otras cosas.

En otras palabras, para mi es un tema de imagen, de la herramienta más que mío ya que, según lo que han comentado todos no hay componentes ni documentación simplificada disponible; así que al tocar el tema la opción sería decirle a los clientes que no hay nada disponible en la herramienta Delphi y que desarrollar nosotros tomaría un tiempo probablemente considerable

En el propio sitio de XBRL mencionan que los programadores tienden a subestimar el tiempo que requiere, aunque dicen que también lo sobreestiman. El caso es que si advierten que la gente subestima el tiempo, me atrevo a apostar que ciertamente no es poco el tiempo que se requiere.

Así, los clientes decidirán la prioridad, y conociendolos, no me cabe duda que optaran por aplazarla y usar por mientras la solución manual

A jhonny,

El tema de las normas internacionales de contabilidad y por ende la XBRL tienen años anunciando que va a entrar en vigencia y a última hora lo aplazan.

Por eso, en años anteriores no lo había planteado aquí, y por lo mismo no me atrevo a decir cuando realmente empezará.

El último anuncio que tengo es que es para el año entrante. Quizás ya volvieron a aplazarlo; pero, como ha pasado tanto tiempo, y ya hemos avanzado bastante en su implementación, me parece que ahora si puede estar muy cerca y es mejor ponerle toda la atención

Saludos

[Casimiro Notevi]

Empezado por rolandoj

Hola a todos,

[jhonny]

Empezado por rolandoj

A jhonny,

El tema de las normas internacionales de contabilidad y por ende la XBRL tienen años anunciando que va a entrar en vigencia y a última hora lo aplazan.

Por eso, en años anteriores no lo había planteado aquí, y por lo mismo no me atrevo a decir cuando realmente empezará.

El último anuncio que tengo es que es para el año entrante. Quizás ya volvieron a aplazarlo; pero, como ha pasado tanto tiempo, y ya hemos avanzado bastante en su implementación, me parece que ahora si puede estar muy cerca y es mejor ponerle toda la atención

Saludos

Hola (Me sentí regañado por Casimiro al notar que no había saludado jejeje), comprendo, la verdad yo veo a las empresas del país bastante quedadas con este tema, quizá es por esto que han aplazado tanto esta normativa. Sin embargo también es cierto lo que dices, aunque se hace urgente si tu mercado son las empresas grandes ya que estás necesitan NIIF plenas, pues la norma ha sido clara desde el principio y las pymes optan por no presentar NIIF plenas mientras no estén obligados (Y procurarán no estarlo según mi apreciación desde que comenzó este tema).

[mamcx]

A m i tambien me interesa el tema, pero en especial la facturacion electronica. Lo ultimo que supe es que se convertira en monopolio de unos pocos, es algo que ahora podriamos ofrecer?

Con respecto a crear los componentes, pues aqui en Colombia la idea de venderle a los desarrolladores no despega ni a palos. Pero venderle a las empresas finales si. Quizas ofrecer un servicio web? Seria practico?

Yo tengo integrado como unos 20 ERPS (parte facturacion, no contabilidad) asi que tengo experiencia, y tambien tengo algo de ayuda en la parte comercial. Pero no estoy enterado como es bien el tema y como ajustar el negocio.

[[Al González]]

Por si sirve de algo, pueden buscar a Darío Álvarez, programador Delphi y C# colombiano, uno de los pioneros de la factura electrónica en México y gran conocedor de todo lo que tiene que ver con XML, servicios Web, facturación electrónica y sistemas de gestión. Conociendo su espíritu emprendedor, no dudo que también él ya esté buscando incursionar en eso de la XBRL.

Este mensaje es apelando a su buen juicio y madurez para compartir algo del conocimiento que posee con esta comunidad.

¡Un abrazo!

Al González.

[rolandoj]

Hola de nuevo a todos,

Gracias por los nuevos aportes.

Se me había olvidado comentar algo. Algunos mencionaron que la facturación electrónica en Colombia se venía primero,

Si tienen información importante, podrían abrir un hilo al respecto. ?

Es que según esta nota :

http://ccce.org.co/noticias/no-hay-a...ctronicas-dian

A fecha 16 de Septiembre ni siquiera existen proveedores de facturación electrónica autorizados en Colombia y el piloto es de solo 58 empresas.

Asumiendo que eso es cierto, encuentro muy improbable que pueda implementarse rápidamente.

Entre otras cosas porque aquí hay mucha gente de pequeñas empresas que ha desarrollado sus propios sistemas y trabajan con desarrollos tan antiguos que aún los hay en DOS. Meterle mano a esos sistemas cuando aún se pelea el hacerlo para el tema de normas internacionales no es facil ni barato.

Eso llevaría a un doble trabajo de transcribir información para la DIAN con los proveedores autorizados y luego hacerlo en sus propios sistema. Es algo muy inconveniente, sin contar conque representa una auditoría en vivo, así que asumo que el tema también tendrá resistencia

Muichos saludos

[[Delphius]]

Rolando, tenemos diferentes perspectivas en algunos puntos, pero déjame decirte algo: es preferible perder tiempo ahora y no seguir pateándolo para más adelante cuando estés frente a frente.
¿Cuánto más creen ustedes (les hablo a los Colombianos, que veo que se están haciendo presente en el hilo) que la autoridad del gobierno competente lo siga "postergando"?
Si es como ha dicho Rolando, de que hay una sospecha que para el año que viene con más razón empezaría ya. Estamos en Octubre, en un pestaneo estamos en Enero del 2017. Ya lo tenemos encima, así que es preferible ser más cauto y preparar la cancha para cuando el gobierno decida darle más vida al tema.

Es preferible tirar un centro antes que seguir avanzando y que se nos acabe la cancha.

Es mi consejo, porque algo similar ha sucedido acá con la Factura Electrónica. Primero hubo un amague, luego puso un plazo de un año. Luego dió unos meses más, y esa fue la definitiva. Ahora todos los grandes comercios están obligados. A llorar a magoya. Quienes se metieron o se animaron a dar soluciones, hasta el día de hoy andan a las corridas. Ya ha sacado 2 versiones, y cambiado la documentación. Si no recuerdo mal, ya llevamos al menos 6 meses con F.E.

Y no queda otra que siempre redondear para arriba cuando estimemos algo... Tanto en plata como en tiempos y demás recursos. Si dices que vas a gastar $4567 por mes, redondea a un 30% por encima. Si dices que te demorará 5 meses, di 8. Si te sobra, fantástico: ese sobrante puede venir bien para prepararse a otros casos.

No eres el único que sufre con las estimaciones y anda justo con los tiempos. ¡Me animo a decir que todos estamos así! Te entiendo lo que es sentirse con el reloj persiguiéndonos... sentir un TIC, TAC por encima de la oreja. Lo que no sea tan importante, o para aquellos proyectos cuyos riesgos de atrazos sean menores es preferible dejarlo de lado (sacrifica el mal menor). Si había vacaciones planeadas... cancelarlas, si no se estaba trabajando los sábados... pues no queda otra que perder ese día de fin de semana para estar al día. Trata de ajustar y cambiar la agenda.
Si te faltan manos, considera la posibilidad de incorporar a alguien más... aunque hay un postulado de la Ingeniería de Software que dice que no siempre agregar más personal a un proyecto lo agiliza.

Y fundamental: volver a hablar con clientes y tratar de conseguir un nuevo plazo con las debidas disculpas. Es preferible decir: "Disculpa me voy a atrasar x semanas. Por las molestias, en lugar de cobrarte 6000 como estaba pactado, te cobro 5300". Tratar de jugar con un poco sobre el porcentaje de ganancia, en lugar de esperar la ganancia de un 25%, esperar un 18% por ejemplo. Igual ganarás... no tanto como esperabas pero posiblemente el cliente lo entienda y acepte estas condiciones en lugar de perderlo.

En fin, obviamente que lo que te propongo sale caro, pretender salir airosamente ya es imposible. Obviamente, se ha salido de la proyectado y planificado. Estamos en Plan de Contingencia. Las cosas cambian cuando se entra en esta etapa... todo se reformula. Nos acaban de meter una bala en la pierna... estamos cojos pero vivos. Lo de ahora es tratar de salir del lugar perdiendo menos sangre posible y evitar el desmayo.
Cuando encontremos un lugar más seguro volveremos a verificar el estatus, y si hay que volver a ajustar el rumbo se hace, si encontramos un nuevo pedazo de tela para reemplazar el que tenemos buenísimo. Nos hacemos otro torniquete y a seguir el camino.
Cuando estemos ya en territorio amigo, si viene el trabajo normal. Nos vamos a la enfermería a que la chica voluptuosa nos atienda, y nos de los resultados de la misión. Descanzamos un poco y reparamos lo que esté roto. Ahora recién se vuelve al plan normal como lo teníamos organizado.

Saludos,

[mamcx]

Adelantarse tiene sentido, pero el problema es que (si no entendi mal) eso solo queda en manos de unos pocos. Si empresarios pequeños podemos hacer una solucion, seria genial.

Podria hacerse un servicio web o una utileria para ofrecer? En tal caso colaborar entre algunos podria resultar interesante.

[rolandoj]

Buenas tardes a todos,

Perdonen la demora; pero, como ya he dicho estoy muy escaso de tiempo.

Sobre facturación electrónica en Colombia he abierto un hilo porque creo que es tiempo de que empiece a tratarse el tema. El hilo es :

http://www.clubdelphi.com/foros/showthread.php?t=90921

mamcx tiene razón acerca de que el negocio principal de facturación electrónica queda, al menos por ahora, en manos de unos pocos, ya que las condiciones para ser proveedor tecnológico nos descartan a nosotros los desarrolladores independientes.

Delphius, veo que tienes ideas preconcebidas y te emocionas con ellas; pero, creo que lo haces en demasía y te olvidas de leer las condiciones particulares de cada caso.

Verás, yo no estoy cogido de tiempo con estos temas porque yo no tengo ningún contrato para desarrollarlos.

Si lees bien lo que escribí antes, verás que el tema de los XBRL es un plus que quiero ofrecerle a mis clientes; pero, ellos ya tienen la alternativa del procesamiento manual. Me preocupa solo por imagen del producto, no porque tenga contrato para agregarlos y mucho menos un tiempo establecido.

Entre otras porque no tiene sentido establecer tiempos en un contrato para desarrollar algo de lo que solo conocemos una pequeñísima parte.

Sobre la facturación electrónica la situación es similar. Ni siquiera nos acercamos a cumplir las condiciones para ser proveedor teconológico de la facturación electrónica. Nuestra participación probablemente será crear una interfase con el proveedor autorizado; pero, el como ni siquiera está definido; entre otras cosas porque si restringen, supuestamente por seguridad, el servicio a unos pocos, que sentido tiene que esos pocos si acepten interfases en línea de terceros ?.

Aunque sería muy perjudicial para las empresas pequeñas, cabe la posibilidad de que solo soporten digitación manual y carga de archivos de texto, con imagen adjunta. En tal caso, el tema ni siquiera aplicaría para nosotros los independientes.

[[Delphius]]

Empezado por rolandoj

Buenas tardes a todos,

Perdonen la demora; pero, como ya he dicho estoy muy escaso de tiempo.

Sobre facturación electrónica en Colombia he abierto un hilo porque creo que es tiempo de que empiece a tratarse el tema. El hilo es :

http://www.clubdelphi.com/foros/showthread.php?t=90921

mamcx tiene razón acerca de que el negocio principal de facturación electrónica queda, al menos por ahora, en manos de unos pocos, ya que las condiciones para ser proveedor tecnológico nos descartan a nosotros los desarrolladores independientes.

Delphius, veo que tienes ideas preconcebidas y te emocionas con ellas; pero, creo que lo haces en demasía y te olvidas de leer las condiciones particulares de cada caso.

Verás, yo no estoy cogido de tiempo con estos temas porque yo no tengo ningún contrato para desarrollarlos.

Si lees bien lo que escribí antes, verás que el tema de los XBRL es un plus que quiero ofrecerle a mis clientes; pero, ellos ya tienen la alternativa del procesamiento manual. Me preocupa solo por imagen del producto, no porque tenga contrato para agregarlos y mucho menos un tiempo establecido.

Entre otras porque no tiene sentido establecer tiempos en un contrato para desarrollar algo de lo que solo conocemos una pequeñísima parte.

Sobre la facturación electrónica la situación es similar. Ni siquiera nos acercamos a cumplir las condiciones para ser proveedor teconológico de la facturación electrónica. Nuestra participación probablemente será crear una interfase con el proveedor autorizado; pero, el como ni siquiera está definido; entre otras cosas porque si restringen, supuestamente por seguridad, el servicio a unos pocos, que sentido tiene que esos pocos si acepten interfases en línea de terceros ?.

Aunque sería muy perjudicial para las empresas pequeñas, cabe la posibilidad de que solo soporten digitación manual y carga de archivos de texto, con imagen adjunta. En tal caso, el tema ni siquiera aplicaría para nosotros los independientes.

Rolando, el que se contradice sos vos.
Tu mismo has dicho que no tiempo suficiente para dedicarle al tema porque tienes cosas más urgentes y necesarias.
Y ahora dices que que no te preocupa los tiempos porque tu idea es algo como un agregado y no hay plazo definido.

Si no hay plazos, entonces tienes tiempo.

¿Al final? ¿Tienes o no tiempo?

Si tu te vas a poner a ver una característica que tiene una gran posibilidad de ser obligatoria a partir del año que viene como algo opcional, con todo respeto tu mismo te estás descartando como una opción a considerar. Esa característica es probable que en no mucho tiempo sea convierta en una restricción operativa y/o legal.
Y como tal, toda restricción afectará al sistema.

Hoy tus clientes pueden aceptar el trabajo manual, pero mañana cuando sea obligatorio y el volumen de cosas sea mayor, van a querer que sea (al menos) más automatizado.

Si la documentación de XBRL está disponible y al alcance de cualquier desarrollador, ¿que te impide a vos tener tu propia implementación? Si obviamos el tema de proyectos actualmente en curso y otras actividades con prioridad, tienes tanto las herramientas, el conocimiento y experiencia suficiente, y la documentación que seguir. ¿Te hace falta más? No. Estás hipotéticamente, y al menos desde el punto de visto del "know how" en igualdad de condiciones que una empresa grande.
En lo que te puede sacar ventaja una empresa grande es que ellos tienen más recursos para destinarle, y quizá puedan sacarlo más rápido por tener más gente, más equipos, y pueden repartirse el trabajo de mejor forma. Pero insisto: tu como ellos tienen el mismo acceso a la doc y esto en última es que posibilita a que hasta un indie haga algo.

¿O acaso se te niega la posibilidad de acceder a la doc? ¿Donde está escrito que sólo las grandes empresas se tienen que repartir la torta? ¿Tu gobierno te impide a vos que hagas tu soft con soporte XBRL?

Sobre la Factura Electrónica no opino mucho, no se como será en tu país. Al menos acá en Argentina la AFIP publicó los documentos para que CUALQUIER desarrollador pueda ofrecer su propia interfaz para acceder a los servicios de la AFIP (que es el UNICO organismo autorizado en emitirlas), dio plazos a los contribuyentes para ponerse y se familiaricen.
La AFIP ofrece sus servicios web que te generan todo, tu como desarrollador lo que ofreces es sólo eres un intermedio. Tu pones el sistema que interactúa con la página y servidores de la AFIP y se te generan los archivos necesarios. Luego tu sistema tomas los archivos y se los entrega (envía por correo) al cliente/comprador*.

*Por cliente no me refiero al usuario que usa tu sistema. Sino al cliente de tu cliente. Espero que se entienda.

Acá nadie es proveedor. Nadie puede reempazar ni hacerse pasar por la AFIP. No hay que registrarse, ni pagar por tener alguna "exclusividad" y nada por el estilo. No hay restricciones, no hay un dedo que diga "vos si vas a poder hacer soft, tu no... mengano sólo podrá hacer uso de la 1/3 parte... y fulanosoft porque estamos prendidos en las licitaciones directas te la regalo completa".
Insisto: acá el que quiere hace su propia implementación y si no simplemente se usa en forma directa el servicio de la AFIP. No te van a impedir, seas un civil de a pie cualquiera, una pyme o una mega empresa. Todos tenemos la libertad y posibilidad de hacer o no hacer, y esto es así porque la AFIP publicó los documentos libremente. No se los dió a Fuanosoft, no es secreto... es PUBLICO. Porque como lo establece la ley ES COSA PUBLICA. Y como tal, todos los ciudadanos debemos ser posibles de poder tener acceso.
Es muy simple: si sos desarrollador, seas indie, tengas una pyme o una empresa bien consolidada, y tienes interés o si ya tenías tu software de gestión y facturación puedes agregarle un módulo de F.E.

Ahora que la documentación de la F.E. que publicó la AFIP deja algunas cosas que desear, y se pudiera pulir mejor eso ya es otra cosa. Y si, hace falta en última tener a un contador como amigo para que aclare algunas cosas, de cuando se hace alguna cosa, cuando es otra, etc.

Saludos,