Los conceptos técnicos de Breve®

EjemploPara trabajar en Breve, que corre en el navegador, basta un i3 o un i5 de una generación reciente. Un i7 se nota en diseño, video o con muchos programas pesados abiertos.

Al implementarLa generación pesa más que el número: un i5 nuevo suele ser más rápido que un i7 de hace diez años. Se mira el modelo completo, no solo la i.

EjemploCon ocho gigabytes de RAM se trabaja bien en Breve con varias pestañas abiertas. Con cuatro, el navegador se pone lento.

Al implementarSi una computadora se pone lenta con muchas pestañas o programas abiertos, la falta de RAM suele ser la causa. Ampliarla es de las mejoras más baratas.

EjemploUna computadora con SSD enciende en segundos y abre el navegador al instante. Lo que se guarda en Breve no está en ese disco, sino en la nube.

Al implementarCambiar un disco duro viejo por un SSD es la mejora que más se nota en una computadora lenta. Antes se copia lo que hay en él, porque eso no está en la nube.

EjemploComo Breve corre en el navegador, se usa en Windows, macOS, Android o iPhone sin instalar nada, y cada pantalla se acomoda al tamaño del equipo.

Al implementarUn equipo con un sistema operativo que ya no recibe actualizaciones es un riesgo, aunque todavía encienda. Se revisa antes de ponerlo a trabajar.

EjemploLos recibos de un punto de venta se imprimen en impresoras térmicas, casi siempre en rollos de ochenta milímetros.

Al implementarPara lo que hay que guardar por años, como una factura que se archiva, se imprime en papel normal o se guarda en PDF. El papel térmico no dura.

EjemploEn Breve, el código de un ítem puede ser el de sus barras, y con el lector se busca al instante al facturar o al contar el inventario.

Al implementarAntes de comprar lectores, se revisa que los productos ya tengan su código de barras cargado en el ítem. Sin eso, el lector escribe un número que nadie reconoce.

EjemploCada vez que alguien abre Breve, su teléfono y el servidor de Breve se reconocen por su IP.

Al implementarCuando un usuario dice que «no entra», saber desde qué conexión lo intenta ayuda a descartar si el problema es su red.

EjemploLas computadoras de una oficina tienen IP privadas y salen a Internet con la IP pública de su router.

Al implementarSi una integración pide autorizar una IP, es la pública la que hay que dar, nunca la privada.

EjemploUn banco o una aseguradora puede pedir la IP fija de un sistema antes de recibir sus llamadas, y una base de datos bien protegida solo acepta las de sus servidores.

Al implementarAntes de probar con un sistema que usa lista blanca, confirmar por escrito que la IP ya fue autorizada. Es la causa más común de que «no conecta».

EjemploEl sitio de Breve está en breve.do. Quien administra el dominio decide a qué servidor apunta cada nombre.

Al implementarUn cambio de DNS no se ve en todas partes al mismo tiempo (ver la propagación). Se planifica y no se hace el día de una demostración.

EjemploEl sitio de Breve está en breve.do, con la extensión de República Dominicana, corta y fácil de decir.

Al implementarConviene registrar también las variantes más parecidas al dominio de la empresa, como la .com o la .com.do, para que nadie las use para confundir a sus clientes.

EjemploQuien tiene el registro de un dominio decide a qué servidor apunta la página y a dónde llegan los correos de la empresa.

Al implementarEl dominio debe quedar a nombre de la empresa, con un correo que alguien lea. Si vence sin renovarse, se caen a la vez la página y el correo, y pasado un plazo otro lo puede registrar.

EjemploCuando una empresa cambia su página o su correo de proveedor, mientras dura la propagación unos ven lo nuevo y otros lo viejo.

Al implementarLos cambios de DNS se hacen con tiempo y fuera de las horas de más uso. Antes se baja el tiempo de la copia, que se llama TTL, para que el cambio corra más rápido.

EjemploSi los correos que una empresa envía con su propio dominio llegan a la carpeta de spam de sus clientes, lo primero que se revisa son esos registros en su DNS.

Al implementarAntes de enviar facturas o avisos desde un dominio propio, se configuran el SPF, el DKIM y el DMARC. Sin ellos, muchos correos legítimos terminan en spam.

EjemploLos audios de Cultura comercial salen de audio.breve.do, separados del sitio.

Al implementarSi un cliente quiere usar su propio dominio para correos o enlaces, el subdominio se crea en su DNS. Lo hace quien administra su dominio.

EjemploCuando se guarda una factura, la pantalla le manda el pedido al servidor de Breve, que la revisa, la guarda y contesta.

Al implementarSi algo falla para todos a la vez, suele ser el servidor. Si falla para una sola persona, suele ser su equipo o su conexión.

EjemploBreve y su sitio solo funcionan con HTTPS. Nada viaja en texto abierto.

Al implementarSi el navegador avisa que la conexión no es segura, no se continúa: se revisa la dirección, porque puede ser un enlace falso.

EjemploEn la nube, cada pieza importante tiene su firewall: una base de datos bien protegida solo deja pasar a los servidores que la usan.

Al implementarMuchas oficinas bloquean sitios en su red. Si Breve no abre en la oficina pero sí en el celular, se le pide al técnico de la empresa que permita la dirección de Breve.

EjemploEn la nube, el servidor de un sistema puede vivir en su propia red virtual, con la base de datos en una subred a la que solo él llega.

Al implementarConectar el sistema de un cliente por una red privada se coordina con su equipo técnico desde el principio, no el día de salida.

EjemploCuando un banco o una aseguradora solo acepta llamadas de una IP, el sistema que las hace sale por un NAT con una IP fija, aunque detrás tenga varios servidores.

Al implementarEs lo que permite dar una sola IP para una lista blanca, aunque detrás haya varios servidores.

EjemploEl sitio breve.do se sirve así y carga rápido aunque su origen esté lejos.

Al implementarDespués de publicar un cambio, una copia vieja puede verse unos minutos. Recargar la página suele resolverlo.

EjemploPor eso el servidor de una aplicación y su base de datos conviene que estén en la misma región: cada consulta tarda unas diez veces menos que entre regiones distintas.

Al implementarSi una pantalla tarda en todas partes, se revisa el servidor. Si tarda solo en un lugar, se mide la conexión de ese lugar.

EjemploSubir la foto de la factura de un suplidor pide mucho más ancho de banda que guardar una factura en Breve, que pesa muy poco.

Al implementarPara enviar fotos o videos desde la calle o desde una obra, conviene probar la conexión antes.

EjemploEn una oficina, el wifi une las computadoras y los celulares con el router, y el router con el proveedor de Internet.

Al implementarSi Breve va lento solo en un rincón de la oficina, el problema suele ser la señal del wifi, no Breve. Una computadora que no se mueve va mejor con cable.

EjemploUn vendedor en la calle puede tener una impresora de recibos portátil unida a su celular por Bluetooth.

Al implementarBluetooth no es Internet: el equipo unido no recibe nada de la nube si el celular no tiene conexión. Cada equipo se empareja una vez, y otra vez si se cambia de celular.

EjemploBreve se usa desde el navegador de la computadora o del celular, sin instalar nada.

Al implementarSi una pantalla se ve rara después de una actualización, lo primero es recargar. Un navegador muy viejo también puede fallar: conviene tenerlo al día.

EjemploBreve corre en Microsoft Azure. Si se daña la computadora de la oficina, las facturas siguen ahí.

Al implementarEl cliente no instala servidores. Lo que sí necesita es una buena conexión y equipos al día.

EjemploPara la empresa que lo usa, Breve es SaaS: entra y trabaja. Por dentro, Breve corre sobre servicios PaaS de Azure.

Al implementarCon SaaS, el cliente no paga ni administra servidores, pero tampoco decide cuándo se actualiza. Conviene decirlo desde el principio.

EjemploLas piezas de producción de una solución van en un grupo y las de pruebas en otro, para no confundirlas.

Al implementarSeparar pruebas de producción también separa los costos, y deja ver cuánto cuesta cada cosa.

EjemploLas soluciones de IMS están en regiones de Azure en los Estados Unidos.

Al implementarBancos y aseguradoras suelen preguntar dónde están sus datos. La respuesta es la región.

EjemploLos archivos que guarda Breve en Azure se guardan con varias copias, y los respaldos de su base de datos tienen una copia más fuera de Azure.

Al implementarLa redundancia no reemplaza el respaldo. Si alguien borra algo, se borra en todas las copias a la vez.

EjemploEl plan del servidor de Breve permite publicar una versión nueva en un espacio de pruebas antes de pasarla a producción.

Al implementarUn plan más grande cuesta más cada mes. Se sube por una necesidad medida, no por si acaso.

EjemploPara una carga de miles de facturas o una demostración grande, un servidor se puede subir de plan unas horas y bajarlo después.

Al implementarEn la nube, escalar es un cambio de minutos, no una compra de equipos. Pero cuesta: se planifica con fecha de regreso.

EjemploEl servidor de Breve responde a su propio chequeo de salud, que también revisa la conexión con la base de datos.

Al implementarUn chequeo en verde dice que el servicio responde, no que cada pantalla funcione. Eso se prueba aparte.

EjemploBreve es una aplicación web: se usa igual en la computadora de la oficina y en el celular.

Al implementarBasta una dirección y un usuario. Lo que se revisa es el navegador y la conexión.

EjemploBreve no es una aplicación nativa: no está en las tiendas, se instala desde el navegador.

Al implementarSi un cliente busca a Breve en la tienda de su celular, no lo va a encontrar. Se le enseña a instalarla como PWA.

EjemploBreve es una PWA: desde el navegador del celular se agrega a la pantalla de inicio y abre como cualquier aplicación.

Al implementarAl instalarla se aceptan las notificaciones para recibir los avisos. Cada teléfono se instala por separado.

EjemploGracias a su service worker, Breve abre rápido y se actualiza sola. Sin conexión abre, pero no puede traer ni guardar datos.

Al implementarSi un usuario sigue viendo una versión vieja, cerrar y volver a abrir la aplicación suele bastar.

EjemploBreve publica versiones con frecuencia, cada una con su número, y las notas de actualización cuentan lo nuevo.

Al implementarAl reportar un problema, la versión que aparece en la aplicación ayuda a saber si ya está corregido.

EjemploBreve tiene un ambiente de desarrollo aparte de producción, para probar sin tocar los datos de los clientes.

Al implementarLa capacitación se hace en un ambiente o una empresa de prueba, como la de demostración, nunca con los datos reales del cliente.

EjemploEl código de Breve vive en GitHub, con cada cambio anotado.

Al implementarCuando algo empezó a fallar «desde ayer», el historial dice qué cambió ayer.

EjemploLa API de Breve se despliega primero en un espacio de pruebas y después se intercambia con producción, para que el cambio sea casi instantáneo.

Al implementarUn despliegue se avisa y se programa fuera de las horas de más uso del cliente.

EjemploCada cambio de Breve en GitHub se compila solo, y la versión aprobada se publica sola.

Al implementarUna publicación automática no es una publicación sin control: lo que se controla es lo que entra a la versión aprobada.

EjemploCuando Breve agrega un campo, como un dato más en la ficha del cliente, primero cambia la base y después publica la pantalla que lo usa.

Al implementarAntes de una migración se hace un respaldo. Es el seguro de que se puede volver atrás.

EjemploLos errores de Breve quedan registrados con su hora, y su uso se mide con telemetría.

Al implementarAl reportar un error, la hora exacta y lo que se estaba haciendo permiten encontrarlo en el registro en minutos.

EjemploUna alerta puede avisarle al equipo técnico cuando los errores de una aplicación suben de golpe, antes de que los usuarios llamen.

Al implementarUna alerta que nadie lee no sirve. Cada una tiene que llegarle a alguien que sepa qué hacer.

EjemploEl stack de Breve es Angular en las pantallas, .NET en el servidor, una base de datos SQL y la nube de Microsoft Azure, con el código en GitHub.

Al implementarCuando un cliente pregunta con qué está hecho un sistema, la respuesta es su stack. Lo que conviene saber es si es conocido, si tiene soporte y si se consigue gente que lo maneje.

EjemploLas pantallas de Breve están hechas con Angular y TypeScript, y funcionan en cualquier navegador al día, en la computadora o en el celular.

Al implementarTodo eso corre en el navegador. Si una pantalla se ve bien en un equipo y mal en otro, la diferencia suele estar en el navegador o en el tamaño de la pantalla, no en los datos.

EjemploEl servidor de Breve está hecho en .NET, con el lenguaje C#. Guarda en una base de datos SQL, y desde ahí habla con la DGII y con WhatsApp.

Al implementarLas reglas importantes, como un permiso o un límite de crédito, se validan en el backend. Lo que solo se esconde en la pantalla no está protegido.

EjemploEn una factura, el color y la forma del botón de guardar son UI. Que la factura se pueda hacer sin saltar de pantalla en pantalla es UX.

Al implementarLas quejas de «no lo encuentro» o «me equivoqué de botón» son de UX. Se anotan con la pantalla y el paso exacto, porque ayudan a mejorar la solución para todos.

EjemploLas pantallas de Breve son el frontend, en el navegador. El servidor que guarda las facturas y habla con la DGII es el backend.

Al implementarUn botón que no responde suele ser del frontend. Un dato que se guarda mal casi siempre es del backend. Distinguirlo acorta el soporte.

EjemploLas pantallas de Breve le piden todo a la API de Breve. Un sistema externo, con permiso, puede cargar clientes o ítems por esa misma API.

Al implementarCuando un cliente quiere conectar su sistema, las preguntas son qué datos, en qué dirección y cada cuánto. Con eso se define la integración.

EjemploLa API de Breve tiene un endpoint para cada cosa que se puede hacer en sus pantallas.

Al implementarUna integración se documenta endpoint por endpoint: qué recibe, qué devuelve y qué errores puede dar.

EjemploAbrir la lista de facturas es un GET. Guardar una factura nueva es un POST.

Al implementarSi un sistema externo «envía» y nada aparece en Breve, se revisa la respuesta de cada petición: ahí está el porqué.

EjemploSi un usuario intenta una acción que su perfil no permite, Breve responde con un 403 y la pantalla avisa que no tiene permiso.

Al implementarUn 401 se arregla volviendo a entrar, un 403 dando el permiso, y un 500 se reporta a soporte con la hora exacta.

EjemploCada factura viaja entre las pantallas de Breve y su servidor en JSON.

Al implementarPara una carga por la API, un ejemplo en JSON vale más que una explicación larga.

EjemploCada e-CF de Breve se arma en XML antes de firmarse y enviarse a la DGII.

Al implementarUn rechazo de la DGII por formato casi siempre señala un campo del XML. El mensaje de rechazo dice cuál.

EjemploBreve está integrado con la DGII para los comprobantes electrónicos y con WhatsApp para enviar documentos y conversar con los clientes.

Al implementarToda integración necesita un responsable de cada lado, un ambiente de pruebas y un acuerdo de qué pasa cuando uno de los dos no responde.

EjemploCuando un cliente le escribe a una empresa por WhatsApp, Meta le avisa a Breve con un webhook, y Breve comprueba la firma del aviso para saber que de verdad viene de Meta.

Al implementarSi los avisos dejan de llegar, se revisa primero la configuración del sistema que avisa. El que espera no puede hacer nada solo.

EjemploEn Breve, un mensaje nuevo de WhatsApp o un pedido aparecen en pantalla en cuanto llegan, y se ve quién está conectado.

Al implementarAlgunas redes de oficina cortan estas conexiones. Si los avisos no llegan solo en una red, es esa red la que hay que revisar.

EjemploLa API de Breve solo atiende a las pantallas de Breve. Una página cualquiera no puede pedirle datos con la sesión de un usuario.

Al implementarUn error de CORS no se arregla en la computadora del usuario. Es configuración del servidor.

EjemploBreve cuenta las peticiones a algunos servicios y, si alguien se pasa, responde con un 429 y le pide esperar.

Al implementarUna carga masiva por la API se hace por lotes y con pausas, para no chocar con el límite.

EjemploUna pantalla puede reintentar una o dos veces si el servidor se está reiniciando, antes de mostrar un error.

Al implementarReintentar algo que crea datos, como una factura, puede duplicarlo. Antes de repetir un envío se confirma que el primero no entró.

EjemploBreve usa Microsoft Azure para la nube y la inteligencia artificial, y Meta para WhatsApp.

Al implementarCuando falla un proveedor externo, la solución puede estar bien y aun así no funcionar. Conviene saber dónde se consulta el estado de cada uno.

EjemploBreve carga por detrás el padrón de contribuyentes de la DGII, para que al escribir un RNC aparezca el nombre de la empresa.

Al implementarSi un dato que depende de un proceso automático no aparece, puede que ese proceso todavía no haya corrido.

EjemploLas facturas, los clientes, los ítems y los asientos de Breve viven en una base de datos SQL en Azure.

Al implementarLos datos que entran mal se quedan mal. La calidad de la carga inicial decide la calidad de los reportes.

EjemploBreve usa una base de datos relacional: cada factura apunta a su cliente, a sus ítems y a su asiento, y por eso un reporte puede cruzar ventas, cobros y contabilidad.

Al implementarSi un cliente se carga dos veces, sus facturas quedan repartidas entre los dos registros y ningún reporte cuadra. Antes de cargar, se revisa que cada cliente exista una sola vez.

EjemploLas imágenes de las facturas recibidas y los documentos que Breve envía por WhatsApp se guardan en el almacenamiento de Azure.

Al implementarLas fotos del celular pesan. Si se cargan muchas, conviene revisar su tamaño.

EjemploEl logo que va en las facturas y cotizaciones de Breve sale nítido cuando viene en vectores, del libro de marca de la empresa.

Al implementarCuando una empresa entrega su logo para los documentos, se le pide en vectores. Un logo copiado de WhatsApp sale pixelado al imprimirlo.

EjemploLa foto de la factura de un suplidor que se carga en Breve es un mapa de bits.

Al implementarUna foto se puede achicar sin problema, pero no agrandar sin que pierda calidad. Lo que no quedó en los píxeles, ningún programa lo puede leer después.

EjemploLas fotos del celular se guardan casi siempre en JPG, y por eso se envían y se cargan rápido.

Al implementarSi la lectura con IA de una factura falla, casi siempre es una foto muy comprimida o reenviada muchas veces. Se toma de nuevo, con buena luz, en vez de mandar la misma.

EjemploBreve genera sus facturas, cotizaciones y reportes en PDF, listos para imprimir o enviar.

Al implementarUn PDF escaneado es una foto por dentro: no se puede buscar ni copiar su texto. Y tapar un dato con un recuadro negro no lo borra (ver la anonimización).

EjemploLos episodios de Cultura comercial y de Cultura técnica se publican en MP3, a 128 kilobits por segundo, en estéreo.

Al implementarPara escuchar en el celular sin gastar muchos datos, el MP3 está bien. Para editar, se trabaja con el original sin comprimir y el MP3 se saca al final.

EjemploUna foto del celular guarda la fecha, la orientación y a veces la ubicación. Por eso una foto tomada de lado aparece derecha en la pantalla.

Al implementarAntes de compartir una foto o un documento, conviene saber qué metadatos lleva: pueden decir más de lo que se quiere.

EjemploLa base de datos de Breve tiene copias automáticas, otra que se exporta cada día y una copia más fuera de Azure.

Al implementarAntes de un cambio grande en los datos de un cliente, como una carga masiva, se hace una copia.

EjemploEl navegador guarda una copia de las pantallas de Breve para abrir rápido, y por eso una versión nueva se aplica al navegar de nuevo.

Al implementarAnte un dato que «no cambia», recargar o esperar unos minutos. Si sigue igual, ya no es la caché.

EjemploBreve exporta el 606 en Excel, las facturas en PDF y los e-CF en XML, y acepta cargas por plantillas o por su API.

Al implementarUna importación necesita una plantilla con columnas fijas. Un archivo distinto cada vez es una carga distinta cada vez.

EjemploBreve guarda sus fechas en la hora de República Dominicana, para que una factura de las once de la noche no aparezca al día siguiente.

Al implementarCuando un reporte no cuadra por un día, se revisan los registros cercanos a la medianoche: ahí es donde más se confunden.

EjemploCada archivo que guarda Breve lleva un identificador único en su nombre, para que nunca se confunda con otro aunque se llamen igual.

Al implementarPara pedir ayuda sobre un registro, se da su número, no solo el nombre: los nombres se repiten.

EjemploAl entrar a Breve con su usuario y contraseña, la persona se autentica. Que vea Ventas y no Nómina lo decide su perfil.

Al implementarCuando alguien «no ve un menú», no es que la cuenta esté mal: es su autorización. Se revisa su perfil.

EjemploEn Breve los permisos se revisan dos veces: la pantalla esconde lo que el perfil no permite y el servidor lo rechaza aunque alguien lo intente por otro camino.

Al implementarUna cuenta por persona, nunca compartida. Los perfiles se arman por papel (vendedor, cajero, contador), no por nombre.

EjemploLa sesión de Breve vence sola, y por eso después de un tiempo pide entrar de nuevo.

Al implementarEn computadoras compartidas, se cierra la sesión al terminar. Una sesión abierta es una puerta abierta.

EjemploCada pantalla de Breve envía su token con cada petición, y el servidor lo valida antes de responder.

Al implementarUn token nunca se pega en un chat ni en un correo. Quien lo tiene entra como usted mientras no venza.

EjemploMuchas empresas guardan las cuentas de su personal en un directorio, como el de Microsoft, para que cada persona entre con la misma cuenta al correo y a otros sistemas.

Al implementarCuando una persona sale de la empresa, su cuenta se desactiva ese mismo día.

EjemploPara enviar mensajes de WhatsApp, Breve usa las credenciales que le entrega Meta, guardadas fuera del código.

Al implementarUna clave que se filtra se cambia de inmediato, aunque «nadie la haya usado».

EjemploLas claves de Breve viven en una bóveda de Azure, no en sus programas.

Al implementarUna clave nunca se escribe en un documento ni en el chat de un proyecto. Va a la bóveda y se cita por su nombre.

EjemploEl servidor de Breve lee su bóveda de secretos y envía correos con su propia identidad, sin una contraseña escrita en ninguna parte.

Al implementarMenos contraseñas guardadas son menos contraseñas que se pueden robar. Cuando el proveedor lo permite, se prefiere esta forma.

EjemploBreve entrega algunos archivos con enlaces que vencen solos, para que no queden abiertos para siempre.

Al implementarSi un enlace «ya no abre», puede haber vencido. Se genera otro desde la aplicación.

EjemploLo que viaja entre el teléfono y Breve va encriptado con HTTPS, y la base de datos y los archivos de Breve se guardan encriptados en Azure.

Al implementarLa encriptación protege el camino y el lugar. Una contraseña débil sigue siendo la puerta más fácil.

EjemploUn sistema bien hecho guarda las claves como hash, y así ni su propio equipo puede leerlas.

Al implementarUn sistema bien hecho no debería poder decirle su clave a nadie. Si se olvida, se crea otra.

EjemploCuando alguien olvida su contraseña de Breve, recibe un código para crear una nueva. Eso es un código de verificación, no doble factor. El correo de la empresa en Google o Microsoft sí puede pedir las dos cosas al entrar.

Al implementarActivar el doble factor en el correo de la empresa también protege a Breve, porque por ese correo se recuperan las contraseñas.

EjemploPara facturar electrónicamente, la empresa necesita el certificado digital de su representante, emitido por una prestadora autorizada por el INDOTEL. Breve lo usa para firmar cada comprobante.

Al implementarEl certificado vence. Se anota la fecha y se renueva antes, o la empresa no podrá emitir comprobantes electrónicos.

EjemploCada e-CF de Breve sale firmado con el certificado de la empresa, y de esa firma sale el código de seguridad que se imprime en la factura.

Al implementarUn comprobante firmado no se corrige a mano. Lo que se corrige, se corrige con una nota de crédito o un documento nuevo.

EjemploEn Breve, cada usuario trabaja dentro de su empresa, y el servidor revisa en cada petición que no pida datos de otra.

Al implementarEn un grupo con varias empresas, un usuario puede tener acceso a más de una. Se asigna empresa por empresa, solo donde hace falta.

EjemploBreve anota en su bitácora los cambios en los datos, con el usuario y la hora, para poder reconstruir lo que pasó.

Al implementarPor eso cada persona tiene su usuario: con una cuenta compartida, la bitácora no puede decir quién fue.

EjemploUn correo con el logo del banco que dice que la cuenta se va a bloquear y pide entrar por un enlace es phishing. El enlace lleva a una copia de la página.

Al implementarAnte la duda, no se toca el enlace: se entra escribiendo la dirección de siempre o se llama al número conocido. Ningún banco serio pide la contraseña por mensaje.

EjemploUna frase larga, como cuatro palabras sin relación, es más segura que una palabra corta con números y símbolos.

Al implementarLa misma contraseña en el correo, en el banco y en Breve es una sola llave para todo. Si se filtra en un servicio, se prueba en los demás.

EjemploLo que está en Breve no está en la computadora de la oficina, así que un ransomware en ese equipo no toca las facturas guardadas en la nube.

Al implementarSe instala solo lo que hace falta, de fuentes conocidas, y con el sistema al día. Los archivos importantes que viven en la computadora se respaldan fuera de ella.

EjemploEn una sesión de soporte, el técnico puede ver la pantalla del usuario y mostrarle el paso exacto, mientras el usuario mira.

Al implementarSolo se da acceso remoto a quien uno llamó, nunca a quien llama de sorpresa ofreciendo ayuda. Al terminar, se cierra el programa.

EjemploLa ficha de un cliente en Breve, con su cédula, su teléfono y su dirección, tiene datos personales.

Al implementarSe pide solo lo que hace falta y se comparte solo con quien lo necesita. Un Excel de clientes enviado por correo también es una fuga.

EjemploPara enseñar en una capacitación el estado de cuenta de un cliente real, se cambian su nombre, su RNC y su teléfono, y el resto queda igual. Es distinto de los datos ficticios de Industrias Montecito, la empresa de demostración de los videos de Breve: esos se inventaron desde cero.

Al implementarAntes de mandar una captura o un archivo a soporte, a un proveedor o a una IA, se quitan los datos personales que no hagan falta. En un PDF, tapar con un recuadro negro no basta: el texto sigue debajo y hay que quitarlo.

EjemploEn el CRM de Breve, cada empresa define su ANS por urgencia, con un tiempo de respuesta y otro de solución, y cada caso que se abre queda con el suyo. Los tiempos de partida van de 2 horas para responder y 4 para resolver en la urgencia más alta, a 8 y 16 horas en la más baja.

Al implementarUn ANS se cumple si se mide. Se registra la hora en que entra cada caso, la de la primera respuesta y la de la solución.

EjemploEn el soporte de Breve, una avería se responde en una hora hábil, y la respuesta la da un técnico, no un acuse automático.

Al implementarEl reloj corre en horas hábiles, dentro del horario de atención. Un caso que entra un viernes a las seis de la tarde empieza a contar el lunes a las ocho.

EjemploEn el soporte de Breve, una avería se responde en una hora hábil.

Al implementarAl reportar una avería se dice qué no se puede hacer, desde cuándo y a cuántas personas afecta. Con eso se clasifica bien a la primera.

EjemploEn el soporte de Breve, una incidencia se responde en cuatro horas hábiles, y una solicitud, en un día hábil.

Al implementarSi todo se reporta como avería, nada es urgente. La pregunta que decide es si se puede seguir trabajando de otra manera.

EjemploSi un total sale mal con ciertos datos, es un error de programa. Si alguien no encuentra dónde se registra una retención, es una duda de uso.

Al implementarUn error se reporta con los pasos para repetirlo, la hora y una captura. Lo que se puede repetir, se puede corregir.

EjemploLos servicios de Azure que usa Breve tienen su disponibilidad comprometida por escrito.

Al implementarNingún servicio tiene el 100 %. Lo importante es saber qué hacer mientras no está: a quién se avisa y cómo se sigue trabajando.

EjemploEn una empresa, la hora pico suele ser la mañana y el cierre de mes, cuando todos facturan y cuadran a la vez.

Al implementarLas publicaciones, las cargas masivas y los mantenimientos se hacen en hora valle. Lo que se mide para saber si un servidor alcanza es la hora pico.

EjemploLa DGII anuncia ventanas de mantenimiento en las que su servicio de comprobantes electrónicos no responde, y en ese rato ningún sistema puede enviarle comprobantes.

Al implementarUna ventana avisada a tiempo no cuenta como avería. Se anuncia con su hora de inicio y de fin, y se confirma al terminar.

EjemploBreve hace este paso solo, antes de enviar los comprobantes de cada empresa.

Al implementarSi el certificado venció o su clave está mal, falla este primer paso y no sale ningún comprobante.

EjemploBreve guarda el TrackId de cada e-CF y con él consulta el estado del comprobante.

Al implementarAnte un comprobante que «no aparece» en la DGII, el TrackId es lo primero que se busca.

EjemploCada factura electrónica de Breve lleva su código de seguridad y su QR.

Al implementarSi un cliente duda de una factura, puede escanear el QR y ver en la DGII que es válida.

EjemploBreve arma y envía ese resumen solo, cuando la factura de consumo no llega al monto.

Al implementarQue una factura de consumo no aparezca completa en la consulta de la DGII no siempre es un error: puede haberse enviado como resumen.

EjemploIndustrias Montecito, la empresa de demostración de Breve, hizo su set de pruebas en junio de 2026, antes de facturar en julio.

Al implementarEl set de pruebas lleva días. Se empieza en cuanto la empresa tiene su certificado, no la semana de salida.

EjemploBreve la carga por detrás y, al escribir un RNC, completa el nombre de la empresa.

Al implementarUn RNC que no aparece puede ser nuevo y no estar todavía en el padrón. Se confirma en la DGII.

EjemploCada factura electrónica de Breve lleva su QR, junto al código de seguridad: al escanearlo se abre la consulta de la DGII con ese comprobante. La versión impresa de los conceptos también trae uno que lleva a la página.

Al implementarUn QR impreso apunta siempre a lo mismo: si la dirección cambia, hay que imprimirlo de nuevo. Y antes de abrir un QR desconocido, se mira la dirección que muestra el celular, porque también se usan para engañar.

EjemploBreve usa la ubicación en las rutas de visita a clientes y en el mapa de contactos.

Al implementarSi la ubicación no aparece, se revisa que el permiso esté dado en el navegador y en el teléfono.

EjemploBreve usa modelos de Azure OpenAI para su chat y para leer documentos.

Al implementarLa IA propone y la persona confirma. Lo que lee una IA se revisa antes de guardarlo.

EjemploUna IA que lee una factura puede confundir un ocho con un tres o inventar un RNC que no se ve bien en la foto.

Al implementarLo que dice una IA se revisa antes de guardarlo, sobre todo cifras, fechas y nombres. Cuanto más importa el dato, más se revisa.

Ejemplo«Resume esta factura» da menos que «Dime el suplidor, la fecha, el total y el ITBIS de esta factura, en una lista».

Al implementarA una IA no se le pegan datos personales ni contraseñas que no hagan falta. Lo que se le escribe puede quedar guardado fuera de la empresa.

EjemploBreve puede leer con IA la foto de la factura de un suplidor, para no escribirla a mano.

Al implementarUna foto derecha, con buena luz y sin cortes se lee mucho mejor. Vale la pena enseñarlo.

EjemploUn sistema que revisa si una foto salió borrosa o que reconoce un objeto en una imagen usa visión por computadora.

Al implementarLas fotos tomadas como pide la guía dan mejores resultados que cualquier ajuste posterior.

EjemploBreve avisa con una notificación cuando llega un mensaje nuevo, y el aviso nuevo de una conversación reemplaza al anterior.

Al implementarSi los avisos no llegan, se revisa que el permiso esté dado en ese navegador y en ese teléfono.

EjemploBreve envía documentos y avisos por WhatsApp con plantillas aprobadas por Meta. Si el cliente escribió en las últimas 24 horas, se le puede responder sin plantilla.

Al implementarUna plantilla nueva tarda en aprobarse y Meta puede rechazarla. Se pide con tiempo.

EjemploLos episodios de Cultura comercial y la historia narrada de Industrias Montecito se graban así, a partir de su guion.

Al implementarEl resultado depende del texto: frases cortas, números escritos como se dicen y nada de abreviaturas.

EjemploLas voces de Cultura comercial y de Radio Breve son artificiales, con nombre y estilo propios, y cada personaje tiene siempre la misma.

Al implementarUna voz se elige oyéndola, no por su etiqueta. Una que dice ser latinoamericana puede sonar española.

EjemploEn los audios de Breve se evitan las exclamaciones que aceleran la voz y las indicaciones de ritmo que le cambiaban el tono.

Al implementarLa naturalidad se gana en el guion: conversación, frases para el oído y una puntuación pensada para cómo se dice.

EjemploLos audios de Breve tienen su diccionario, para que las voces digan «Pinales» y no «Piñales», y wifi o mouse como se dicen en República Dominicana.

Al implementarCada grabación se comprueba pasándola a texto otra vez: si la transcripción no reconoce una palabra, el oyente tampoco la va a entender.

EjemploLas notas de voz que un cliente manda por WhatsApp aparecen escritas en Breve, junto al audio.

Al implementarLa transcripción ayuda a leer rápido, pero ante una duda se escucha el audio original.

EjemploSi una voz de la biblioteca de un proveedor deja de estar disponible, una salida es clonar la de una locutora dominicana, siempre con su permiso por escrito.

Al implementarNunca se clona una voz sin el consentimiento de su dueño. La voz es un dato personal, igual que la cara.

EjemploPara reemplazar una voz que se retira, se pueden diseñar varias candidatas y escoger la que mejor suene en la serie.

Al implementarUna voz diseñada no depende del permiso de nadie, pero se prueba con textos reales antes de usarla.

EjemploUn agente de voz puede contestar una llamada, tomar los datos de un prospecto y pasarle la llamada a una persona cuando hace falta.

Al implementarA quien llama se le dice que habla con un asistente, y siempre tiene un camino para hablar con una persona.