<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
  <title>Blog de Bitspace Software</title>
  <link>https://bitspace.software/blog/</link>
  <atom:link href="https://bitspace.software/blog/feed.xml" rel="self" type="application/rss+xml"/>
  <description>Notas de quien pone los sistemas en producción: DTE con Hacienda, automatización, integraciones y operación para empresas de El Salvador y la región.</description>
  <language>es</language>
  <lastBuildDate>Mon, 02 Nov 2026 04:00:22 GMT</lastBuildDate>
  <item>
    <title>Integrar sin reemplazar: cómo conectar el ERP que ya tienes</title>
    <link>https://bitspace.software/blog/integrar-sin-reemplazar/</link>
    <guid isPermaLink="true">https://bitspace.software/blog/integrar-sin-reemplazar/</guid>
    <pubDate>Sun, 01 Nov 2026 12:00:00 GMT</pubDate>
    <category>Integraciones</category>
    <description>Casi ninguna empresa necesita cambiar de sistema. Necesita que los que tiene se hablen. Qué conectar primero, qué nunca, y cómo evitar que una integración se vuelva otro proceso manual.</description>
    <content:encoded><![CDATA[<p>Cuando una empresa siente que &quot;el sistema ya no da&quot;, la primera idea suele ser cambiarlo. Es la idea más cara y casi nunca la correcta. En la mayoría de los casos el ERP hace bien su trabajo; lo que no existe es la conexión entre el ERP y el resto: el CRM, la facturación electrónica, el correo, la hoja de comisiones. Y esa conexión hoy la hace una persona, copiando.</p>
<p>Integrar es construir ese puente. Y se puede hacer sin tocar lo que ya funciona.</p>
<h2>Empieza por el mapa de lo que viaja a mano</h2>
<p>Antes de hablar de tecnología, haz un inventario de tres columnas: qué dato se mueve, de dónde a dónde, y quién lo mueve. Por ejemplo:</p>
<table>
<thead>
<tr>
<th>Dato</th>
<th>Origen → destino</th>
<th>Quién, cuándo</th>
</tr>
</thead>
<tbody><tr>
<td>Pedido confirmado</td>
<td>CRM → ERP</td>
<td>Vendedor, cada pedido</td>
</tr>
<tr>
<td>Factura emitida</td>
<td>ERP → correo del cliente</td>
<td>Asistente, al final del día</td>
</tr>
<tr>
<td>Pago recibido</td>
<td>Banco → ERP → CRM</td>
<td>Contadora, cada mañana</td>
</tr>
<tr>
<td>Stock disponible</td>
<td>ERP → catálogo web</td>
<td>Nadie (está desactualizado)</td>
</tr>
</tbody></table>
<p>Ese mapa ya dice por dónde empezar: la fila que más veces al día ocurre y la fila donde el retraso cuesta dinero. Lo demás puede esperar.</p>
<h2>Cinco reglas que evitan que la integración se vuelva un problema</h2>
<h3>1. Cada dato tiene un dueño</h3>
<p>Para cada fila del mapa, decide qué sistema es la verdad. El cliente vive en el CRM; la factura vive en el ERP; el pago vive en el banco. Los demás sistemas reciben una copia, nunca la editan. Cuando dos sistemas pueden editar el mismo dato, aparecen las versiones contradictorias y nadie sabe cuál es la correcta.</p>
<h3>2. Un dato viaja en una sola dirección</h3>
<p>Del dueño hacia los demás. Las integraciones bidireccionales existen, pero cada una duplica el trabajo de diseño y los puntos de falla. Si crees que necesitas una, casi siempre es porque no decidiste el dueño del punto anterior.</p>
<h3>3. Si corre dos veces, no duplica</h3>
<p>Una integración va a ejecutarse dos veces por error en algún momento: un reintento, un corte de luz, alguien que pulsa el botón otra vez. Tiene que ser capaz de reconocer &quot;este pedido ya lo pasé&quot; y no crearlo de nuevo. Esto se decide al inicio, con un identificador único por registro, y es lo que separa una integración seria de un script.</p>
<h3>4. Deja rastro, y define qué pasa con los errores</h3>
<p>Cada ejecución queda registrada: qué entró, qué salió, cuánto tardó, qué falló. Y cuando algo falla, alguien específico se entera por un canal específico, con la información suficiente para corregirlo. Una integración que falla en silencio es peor que no tener integración, porque todos creen que el dato ya pasó.</p>
<h3>5. No integres por pantalla si hay otra puerta</h3>
<p>Los robots que hacen clic sobre la interfaz de otro sistema se rompen con cada actualización. Si el sistema tiene API, se usa la API. Si tiene base de datos accesible, se lee la base de datos. Si solo exporta archivos, una exportación programada a CSV es una integración perfectamente válida y barata. La pantalla es el último recurso.</p>
<h2>Un recorrido típico</h2>
<p>Así se ve un flujo completo en una empresa mediana, una vez conectado:</p>
<ol>
<li>El vendedor confirma el pedido en el CRM.</li>
<li>El pedido aparece en el ERP sin que nadie lo digite.</li>
<li>El ERP genera la factura, y la capa de DTE la firma y la transmite a Hacienda.</li>
<li>Con el sello de recepción, el cliente recibe su DTE por correo.</li>
<li>Cuando el pago entra, se registra en el ERP y el CRM marca la cuenta como pagada.</li>
</ol>
<p>Cinco pasos, cero digitación doble. Cada sistema sigue siendo el que era. Lo nuevo es el puente, y el puente es pequeño.</p>
<h2>Qué cuesta y cuánto tarda</h2>
<p>Depende de cuántas filas del mapa se conectan y de qué puertas ofrece cada sistema. Pero la primera conexión, la que más duele, normalmente está en producción entre tres y seis semanas. A partir de ahí, cada conexión adicional es más rápida porque la infraestructura ya existe: el registro, los avisos de error, la forma de reintentar.</p>
<p>Si quieres saber cuáles de tus filas conviene conectar primero, el mapa de tres columnas es un buen punto de partida para una conversación. Nosotros lo revisamos sin costo.</p>
]]></content:encoded>
  </item>
  <item>
    <title>Automatizar no es digitalizar: la diferencia que cuesta horas</title>
    <link>https://bitspace.software/blog/automatizar-no-es-digitalizar/</link>
    <guid isPermaLink="true">https://bitspace.software/blog/automatizar-no-es-digitalizar/</guid>
    <pubDate>Thu, 22 Oct 2026 12:00:00 GMT</pubDate>
    <category>Automatización</category>
    <description>Pasar un formulario de papel a Google Forms no es automatizar. Es mover el trabajo manual de lugar. La prueba de fuego es una sola pregunta.</description>
    <content:encoded><![CDATA[<p>Muchas empresas nos dicen &quot;ya automatizamos&quot; cuando lo que hicieron fue digitalizar. Son cosas distintas, y la diferencia se mide en horas de trabajo cada semana.</p>
<p><strong>Digitalizar</strong> es hacer el mismo proceso en una pantalla. El formulario de papel pasa a ser un formulario web. La libreta de pedidos pasa a ser una hoja compartida. El dato ahora es digital, pero cada paso sigue necesitando que una persona lo ejecute.</p>
<p><strong>Automatizar</strong> es que el sistema ejecute el paso sin que nadie lo pida. La solicitud entra, la regla decide, el aviso sale, y la persona solo interviene cuando algo se sale de lo normal.</p>
<h2>La prueba de fuego</h2>
<p>Para saber en cuál de las dos estás, toma cualquier proceso y pregunta: <strong>¿quién pulsa el botón?</strong></p>
<p>Si la respuesta es &quot;Carmen revisa el correo cada mañana y aprueba las que cumplen&quot;, está digitalizado. Si la respuesta es &quot;las que cumplen se aprueban solas y Carmen ve las tres que no&quot;, está automatizado. Mismo proceso, misma persona, pero en el segundo caso Carmen recuperó la mañana.</p>
<h2>Tres niveles, en la práctica</h2>
<p>Casi todo proceso pasa por tres etapas. Saber en cuál estás ayuda a decidir el siguiente paso sin saltarse ninguno.</p>
<p><strong>Nivel 1: registro digital.</strong> El dato existe en un sistema, con fecha y responsable. Es el mínimo, y es donde se queda la mayoría. Ejemplo: las solicitudes de compra se cargan en un formulario en vez de enviarse por WhatsApp.</p>
<p><strong>Nivel 2: flujo con avisos.</strong> El sistema sabe en qué estado está cada cosa y avisa a quien toca. Nadie tiene que preguntar &quot;¿y mi solicitud?&quot;. Ejemplo: cuando una solicitud lleva dos días sin respuesta, el jefe de área recibe un recordatorio.</p>
<p><strong>Nivel 3: ejecución automática con excepciones.</strong> El sistema ejecuta el paso cuando se cumplen las condiciones, y solo escala lo que no encaja. Ejemplo: toda compra menor a cierto monto, de un proveedor aprobado y con presupuesto disponible, se aprueba sola. Las demás llegan a una persona con todo el contexto a la vista.</p>
<p>El nivel 3 es donde aparecen las horas. Pero el nivel 3 sin el 1 y el 2 no funciona: no se puede automatizar una decisión sobre datos que nadie registra.</p>
<h2>Un caso concreto: avisos de mora</h2>
<p>En Aquora, nuestro sistema para juntas de agua, el aviso de mora era un trabajo de tarde entera: revisar el listado, identificar quién lleva dos meses sin pagar, buscar el número, escribir el mensaje. Digitalizado, el listado sale solo pero alguien sigue escribiendo los mensajes. Automatizado, el sistema identifica cada mes a quién corresponde, envía el aviso por WhatsApp con el monto exacto y registra que se envió. La persona encargada ve un reporte de qué se envió y responde solo a quien contesta.</p>
<p>No cambió el proceso. Cambió quién pulsa el botón.</p>
<h2>Qué no conviene automatizar</h2>
<p>Automatizar tiene un costo, y hay casos donde no se recupera.</p>
<ul>
<li><strong>Pasos que requieren criterio.</strong> Si cada caso es distinto y la decisión depende de hablar con alguien, automatiza el registro y los avisos, no la decisión.</li>
<li><strong>Procesos que cambian cada mes.</strong> Una regla que se reescribe constantemente cuesta más mantenerla que ejecutarla a mano. Primero estabiliza el proceso, luego automatiza.</li>
<li><strong>Lo que ocurre tres veces al año.</strong> Si un paso toma 20 minutos y pasa tres veces al año, no hay automatización que se pague.</li>
</ul>
<p>La regla general: automatiza el 80% repetitivo y deja el 20% de excepciones a una persona con contexto. Intentar cubrir el 100% suele costar más que el 20% que se quería eliminar.</p>
<h2>Por dónde empezar esta semana</h2>
<p>Elige un proceso que ocurra todos los días. Anota cada paso y, al lado, quién lo ejecuta. Los pasos donde la respuesta es &quot;una persona copia, revisa o avisa&quot; son los candidatos. Empieza por el que más veces al día ocurre, no por el más complicado. El primer resultado debería estar en producción en semanas, y a partir de ahí los siguientes salen solos.</p>
]]></content:encoded>
  </item>
  <item>
    <title>DTE con Hacienda: lo que conviene saber antes de integrar</title>
    <link>https://bitspace.software/blog/dte-con-hacienda-lo-que-conviene-saber-antes-de-integrar/</link>
    <guid isPermaLink="true">https://bitspace.software/blog/dte-con-hacienda-lo-que-conviene-saber-antes-de-integrar/</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <category>Facturación electrónica</category>
    <description>Ambientes, firma, sello de recepción, contingencia e invalidación. Lo que se descubre en la semana dos del proyecto, contado antes de empezar.</description>
    <content:encoded><![CDATA[<p>Integrar un sistema de facturación con el Ministerio de Hacienda para emitir Documentos Tributarios Electrónicos (DTE) no es difícil en el sentido técnico. Es una API con JSON, autenticación por token y un esquema por tipo de documento. Lo que vuelve largo el proyecto es todo lo que rodea a esa API: los ambientes, la firma, los plazos y las reglas de operación que no aparecen en el ejemplo de código.</p>
<p>Estas son las ocho cosas que conviene saber antes de la primera reunión con el equipo de sistemas.</p>
<h2>1. Hay dos ambientes, y el de pruebas es obligatorio</h2>
<p>Hacienda expone un ambiente de pruebas y uno de producción, con credenciales distintas. Para pasar a producción hay que completar un set de pruebas por cada tipo de documento que vas a emitir. Si solo emites facturas de consumidor final y crédito fiscal, pruebas dos tipos. Si además emites notas de crédito, remisiones o facturas de exportación, cada una tiene su propio set.</p>
<p>La consecuencia práctica: define desde el principio qué tipos de DTE necesita tu operación. Cada tipo que agregues después es una ronda de pruebas adicional.</p>
<h2>2. La firma vive en tu lado, no en Hacienda</h2>
<p>Cada DTE se firma con un certificado que Hacienda emite a nombre del contribuyente. El servicio de firma corre en tu infraestructura, y el documento firmado es lo que se envía. Eso implica tres cosas que alguien tiene que asumir: dónde corre ese servicio, quién custodia la contraseña del certificado, y quién está pendiente de su vencimiento. Un certificado vencido detiene la facturación completa sin previo aviso.</p>
<h2>3. El sello de recepción es tu única prueba</h2>
<p>Cuando Hacienda procesa un DTE, responde con un sello de recepción. Ese sello, junto con el JSON firmado que enviaste, es la evidencia de que el documento existe legalmente. Guarda los dos, tal cual, sin regenerarlos. Si en una auditoría necesitas demostrar qué se emitió, no sirve &quot;lo que mi sistema cree que envió&quot;; sirve lo que Hacienda selló.</p>
<p>Un diseño sano guarda el JSON enviado, la respuesta completa de Hacienda y la fecha y hora de cada intento, incluidos los rechazados.</p>
<h2>4. Los correlativos son por establecimiento y punto de venta</h2>
<p>Cada DTE lleva un número de control que incluye el tipo de documento, el establecimiento, el punto de venta y un correlativo. Ese correlativo no es &quot;el siguiente número de mi sistema&quot;; es el siguiente número de esa combinación. Si tienes dos cajas en dos sucursales, son dos secuencias independientes que nunca deben cruzarse ni repetirse.</p>
<p>Además, cada documento lleva un código de generación único. Si lo reutilizas por error, Hacienda rechaza el documento, y descubrirlo en caja a las 5 de la tarde de un viernes es una mala experiencia.</p>
<h2>5. Diseña la contingencia antes de necesitarla</h2>
<p>Hacienda puede no responder: mantenimiento, caída de tu internet, saturación. La normativa contempla un modo de contingencia en el que emites el documento sin transmitirlo en el momento y lo reportas después, dentro de un plazo definido. Lo importante es que tu sistema sepa hacerlo solo: detectar que no hay respuesta, seguir facturando en contingencia, encolar los documentos y transmitirlos cuando vuelva el servicio, con el evento de contingencia correspondiente.</p>
<p>Si la contingencia depende de que alguien recuerde &quot;hay que reenviar los de ayer&quot;, vas a incumplir el plazo tarde o temprano.</p>
<h2>6. Invalidar no es borrar</h2>
<p>Un DTE con sello ya existe. Si tiene un error, no se edita: se invalida mediante un evento con motivo, y en los casos que corresponde se emite el documento correcto que lo sustituye. Para ajustes sobre un crédito fiscal ya contabilizado, lo que corresponde normalmente es una nota de crédito o débito, no una invalidación. Tu sistema tiene que distinguir estos casos y guiar a la persona de caja, porque la diferencia tiene efectos fiscales.</p>
<h2>7. Entregar el documento al receptor es tu responsabilidad</h2>
<p>Emitir no es suficiente. El receptor debe recibir el DTE: el JSON y su representación gráfica, normalmente por correo electrónico, con el código QR que permite verificarlo en el portal de Hacienda. Eso significa que tu sistema necesita el correo del cliente, un envío confiable y un registro de que se entregó. Es un paso pequeño que, hecho a mano, se convierte en la tarea más repetitiva del día.</p>
<h2>8. No tienes que cambiar de ERP</h2>
<p>La pregunta que más escuchamos es &quot;¿tengo que cambiar mi sistema de facturación?&quot;. Casi nunca. Lo que necesitas es una capa que tome la venta de tu sistema actual, construya el JSON, lo firme, lo transmita, guarde el sello y lo entregue al cliente. Tu ERP sigue siendo el ERP. Esa capa es exactamente lo que construimos en Financial OS, y el mismo enfoque aplica si prefieres integrarlo por tu cuenta.</p>
<h2>Lista corta para la primera reunión</h2>
<ul>
<li>Qué tipos de DTE emite la operación hoy, y cuáles emitirá en 12 meses.</li>
<li>Cuántos establecimientos y puntos de venta, para definir las secuencias.</li>
<li>Dónde correrá el servicio de firma y quién custodia el certificado.</li>
<li>Qué pasa, paso a paso, cuando Hacienda no responde.</li>
<li>Cómo se guarda y consulta el sello de cada documento.</li>
<li>Cómo y quién entrega el DTE al cliente.</li>
</ul>
<p>Con esas seis respuestas, la integración deja de ser un proyecto de meses y se convierte en uno de semanas.</p>
]]></content:encoded>
  </item>
  <item>
    <title>Cuándo una hoja de cálculo deja de ser suficiente</title>
    <link>https://bitspace.software/blog/cuando-una-hoja-de-calculo-deja-de-ser-suficiente/</link>
    <guid isPermaLink="true">https://bitspace.software/blog/cuando-una-hoja-de-calculo-deja-de-ser-suficiente/</guid>
    <pubDate>Tue, 06 Oct 2026 12:00:00 GMT</pubDate>
    <category>Operación</category>
    <description>La hoja no falla de golpe. Se vuelve lenta, luego frágil, luego secreta. Cinco señales medibles y qué hacer en cada una sin tirar lo que funciona.</description>
    <content:encoded><![CDATA[<p>Casi todas las empresas que conocemos operan sobre hojas de cálculo. No es un error: una hoja es la herramienta más rápida que existe para ordenar un proceso que todavía está cambiando. El problema no es empezar con Excel. El problema es no darse cuenta de cuándo dejó de ser una hoja y se convirtió en el sistema central de la empresa.</p>
<p>Esa transición no avisa. Un día la hoja de inventario tiene 14 pestañas, tres personas la editan al mismo tiempo y el cierre de mes depende de que una sola persona esté en la oficina. Nadie decidió eso. Pasó.</p>
<h2>Cinco señales que se pueden medir</h2>
<p>No hace falta intuición. Estas cinco señales se pueden contar, y con dos de ellas presentes ya conviene actuar.</p>
<h3>1. Existe una &quot;versión final v3&quot;</h3>
<p>Si en la carpeta compartida hay <code>inventario_final.xlsx</code>, <code>inventario_final_v2.xlsx</code> y <code>inventario_final_REAL.xlsx</code>, la hoja ya tiene un problema de concurrencia. Dos personas necesitan escribir sobre los mismos datos y el archivo no lo permite, así que lo resuelven copiando. Cada copia es una verdad distinta.</p>
<h3>2. Hay fórmulas que solo una persona entiende</h3>
<p>Pregunta quién puede explicar cómo se calcula el saldo de un cliente o el costo promedio de un producto. Si la respuesta es un nombre propio, el proceso está en la cabeza de esa persona, no en la hoja. El día que se va de vacaciones, la empresa opera a ciegas.</p>
<h3>3. El reporte mensual tarda más de una mañana</h3>
<p>Mide cuánto tiempo pasa entre &quot;necesito el reporte&quot; y &quot;aquí está&quot;. Si son horas de filtrar, copiar, pegar y revisar que los totales cuadren, ese tiempo es el costo real de la hoja. Un reporte que sale de un sistema tarda segundos y sale igual cada vez.</p>
<h3>4. Alguien copia datos entre dos lugares</h3>
<p>El vendedor anota el pedido en una hoja, luego lo digita en el sistema de facturación, luego lo apunta en el cuaderno de despacho. Cada vez que una persona teclea el mismo dato dos veces, esa persona es la integración. Y las personas se equivocan, se enferman y renuncian.</p>
<h3>5. El dato no coincide con la realidad y nadie sabe desde cuándo</h3>
<p>El inventario de la hoja dice 42 unidades, la bodega tiene 37, y la diferencia apareció en algún momento de los últimos dos meses. Sin un registro de quién cambió qué y cuándo, no se puede encontrar el error. Solo se puede volver a contar.</p>
<h2>Lo que cuesta no actuar</h2>
<p>Un ejemplo para poner números, con cifras conservadoras: dos personas dedican 45 minutos al día a consolidar, revisar y corregir hojas. Son 30 horas al mes. A eso súmale el error que se descubre tarde: una factura emitida con un precio viejo, un pedido despachado dos veces, una cuenta por cobrar que nadie persiguió porque no aparecía en la pestaña correcta. Ese segundo costo casi siempre es mayor que el primero, y nunca aparece en ningún reporte.</p>
<h2>Qué hacer, en orden</h2>
<p>Lo peor que puede pasar es tirar la hoja y comprar un sistema genérico que obliga a cambiar el proceso. La hoja tiene algo valioso: es la especificación exacta de cómo opera la empresa hoy. Se aprovecha así.</p>
<p><strong>Primero, identifica el registro maestro.</strong> De todas las pestañas, hay una que es la verdad: la lista de productos, el padrón de clientes, el listado de contratos. Esa es la que se mueve primero a una base de datos con acceso controlado. Todo lo demás se deriva de ella.</p>
<p><strong>Segundo, mueve lo que tiene concurrencia.</strong> Lo que varias personas escriben al mismo tiempo (pedidos, cobros, movimientos de inventario) necesita un sistema que registre cada cambio con usuario y fecha. Lo que una sola persona analiza puede seguir en Excel por mucho tiempo.</p>
<p><strong>Tercero, deja la hoja para lo que sirve.</strong> Analizar, proyectar, armar un escenario. Un buen sistema exporta a Excel en un clic. La hoja pasa de ser la base de datos a ser una vista de la base de datos, que es lo que siempre debió ser.</p>
<p><strong>Cuarto, elimina la doble digitación.</strong> Cada dato que una persona teclea dos veces es un candidato a integración. Ahí es donde se recuperan las horas.</p>
<h2>Una prueba rápida</h2>
<p>Si quieres saber en qué punto estás, haz esto el lunes: pide el total de cuentas por cobrar vencidas a más de 30 días. Cronometra cuánto tarda en llegar y cuántas personas tuvieron que intervenir. Si tardó menos de un minuto y no intervino nadie, tu operación está bien servida. Si no, ya sabes por dónde empezar.</p>
]]></content:encoded>
  </item>
</channel>
</rss>
