Ir al contenido principal
Alex Astudillo
Blog de Alex Astudillo

Diseñar sistemas. Entender el negocio.

Artículos sobre arquitectura de software, automatización y finanzas para tomar mejores decisiones técnicas y de negocio.

Destacado evaluación de inversiones

VAN y TIR con un ejemplo: evaluar una inversión antes de comprometer capital

El VAN y la TIR permiten analizar los mismos flujos previstos desde dos perspectivas: valor actual y tasa de retorno. VAN y TIR con un ejemplo: evaluar una inversión antes de comprometer capital El valor actual neto (VAN) y la tasa interna de retorno (TIR) ayudan a evaluar una inversión a partir de sus flujos de caja previstos. El VAN expresa el resultado estimado en dinero de hoy; la TIR expresa una tasa implícita en esos flujos. Ambos dependen de los supuestos utilizados. Qué es el VAN y cómo se calcula El VAN descuenta los flujos de caja futuros y los compara con la inversión inicial. En la sección 11.4, OpenStax describe el descuento de los flujos a su valor presente y la resta de la inversión inicial. La fórmula es: VAN = −I₀ + Σ desde t = 1 hasta n de [FCₜ / (1 + r)ᵗ] I₀: inversión inicial. FCₜ: flujo neto de caja del periodo t. r: tasa de descuento por periodo. t: periodo en que se recibe o paga cada flujo. n: número de periodos evaluados. Un VAN positivo indica que, según...
Leer el artículo

Explorar por tema

Arquitectura

APIs, microservicios y decisiones de diseño.

 Automatización

IA aplicada, flujos y controles operativos.

 Finanzas

Contabilidad, liquidez y rentabilidad.

Últimos artículos

Ver todos
Finanzas

VAN y TIR en la compra de un equipo: cómo tomar una decisión

El VAN y la TIR ayudan a evaluar el desembolso inicial de un equipo frente a sus flujos futuros. VAN y TIR en la compra de un equipo: cómo tomar una decisión Comprar un equipo exige comparar su costo inicial con el dinero adicional que se espera obtener o ahorrar durante su vida útil. El valor actual neto (VAN) y la tasa interna de retorno (TIR) ayudan a ordenar esa decisión, siempre que los flujos y la tasa de descuento reflejen las condiciones de la empresa. El siguiente caso es hipotético: no se han proporcionado datos suficientes para recomendar la compra de un equipo concreto. Qué indican el VAN y la TIR El VAN expresa en dinero de hoy el valor estimado que añade una inversión después de descontar sus flujos futuros a una tasa exigida. Para una inversión inicial seguida de flujos anuales, se calcula así: VAN = −inversión inicial + suma de [flujo neto del año t / (1 + tasa de descuento) elevado a t] Un VAN positivo indica que los flujos proyectados superan la inversión inicial des...
costes

Antes de subir precios: calcula el efecto en tu margen y punto de equilibrio

Antes de subir el precio, conviene comparar el margen por venta, los costes y distintos niveles de demanda. Antes de subir precios: calcula el efecto en tu margen y punto de equilibrio Una subida de precios puede aumentar la contribución de cada venta y reducir las unidades necesarias para cubrir costes. Pero, si vendes menos, el beneficio total también puede bajar. Antes de decidir, compara el precio actual y el propuesto para un mismo periodo y revisa si cambiará alguno de tus costes. Calcula el margen de contribución El margen de contribución unitario es el precio de venta menos el coste variable por unidad. Ese importe ayuda a cubrir los costes fijos y, una vez cubiertos, contribuye al beneficio. OpenStax, sección 3.1 , lo describe como el exceso del precio de venta sobre el coste variable unitario: «selling price exceeds its total variable cost per unit» . Margen unitario = precio de venta − coste variable por unidad. Margen porcentual de contribución = margen unitario ÷ precio ...
Análisis de datos

Ventas por mes en PostgreSQL: una consulta útil para tu primer tablero

La consulta transforma las filas de ventas en un resumen mensual para alimentar el tablero. Ventas por mes en PostgreSQL: una consulta útil para tu primer tablero Una consulta mensual puede preparar dos medidas para un primer tablero: la cantidad de filas de ventas y la suma de sus importes. El siguiente ejemplo es una adaptación propia basada en componentes documentados de PostgreSQL. La consulta mensual El ejemplo supone que cada fila de ventas representa una venta, que monto es numérico y que fecha_venta es una fecha o marca de tiempo compatible. Copia esta consulta y adapta los nombres a tu esquema: SELECT date_trunc('month', fecha_venta)::date AS mes, COUNT(*) AS cantidad_ventas, SUM(monto) AS total_ventas FROM ventas WHERE fecha_venta IS NOT NULL GROUP BY 1 ORDER BY 1; date_trunc lleva cada fecha al inicio de su mes y conserva el año. La sección 9.9.2 de la documentación indica que los campos menos significativos se fijan en “zero (or one, for day and month)” . En el...
Calidad de datos

Cómo encontrar clientes duplicados en PostgreSQL con SQL

GROUP BY resume los correos repetidos; una función de ventana permite conservar las filas de cada grupo. Cómo encontrar clientes duplicados en PostgreSQL con SQL Para localizar posibles clientes duplicados, empieza por decidir qué campos deben coincidir. Los ejemplos usan una tabla clientes con las columnas id y email . Dos filas que comparten correo no necesariamente representan a la misma persona: adapta la comparación a tu regla de negocio y revisa las coincidencias. Contar los correos repetidos Esta consulta muestra cada correo no nulo que aparece más de una vez y su número de registros: SELECT email, COUNT(*) AS cantidad FROM clientes WHERE email IS NOT NULL GROUP BY email HAVING COUNT(*) > 1 ORDER BY cantidad DESC; La sección 7.2.3 de PostgreSQL 18 explica que HAVING elimina grupos. La consulta agrupa por correo, conserva los grupos con más de una fila y excluye previamente los valores nulos. Ver todas las filas de cada grupo duplicado Una función de ventana permite contar...
Consultas SQL

Cómo diagnosticar una consulta lenta en PostgreSQL con EXPLAIN

Leer el plan desde los accesos a datos hacia las operaciones superiores ayuda a localizar dónde se concentra el trabajo. Cómo diagnosticar una consulta lenta en PostgreSQL con EXPLAIN Un plan de ejecución ayuda a localizar dónde se concentra el trabajo de una consulta y a comparar lo que PostgreSQL esperaba con lo que ocurrió. Esta guía se basa en la documentación de PostgreSQL 18; comprueba los detalles correspondientes a tu versión. 1. Captura un plan representativo Para investigar una consulta de lectura, puedes empezar con EXPLAIN (ANALYZE, BUFFERS) SELECT ...; . Como recomendación práctica, usa parámetros y volúmenes representativos y elige con cuidado dónde y cuándo medir. La referencia de EXPLAIN, sección Description e indicación Important , advierte que con ANALYZE «the statement is actually executed»: la sentencia se ejecuta realmente. Se descarta la salida de SELECT, pero ocurren sus demás efectos. Revisa la sentencia y las funciones que invoque antes de ejecutarla. Para sent...
costos

Cómo revisar precios cuando tus costos cambian en una economía dolarizada

La revisión del precio comienza por actualizar los costos y evaluar cuánto aporta cada venta. Cómo revisar precios cuando tus costos cambian en una economía dolarizada Vender en dólares no impide que cambien los costos en dólares. Para revisar un precio, puedes estimar cuánto cuesta reponer el producto o prestar el servicio, calcular cuánto deja cada venta y comprobar si ese aporte alcanza para cubrir los gastos fijos con un volumen de ventas razonable. 1. Actualiza el costo de reposición Estima cuánto costaría volver a adquirir o producir una unidad: producto o materia prima, mano de obra directa, flete y otros costos pertinentes. La guía de precios de la BDC , en «Calculate your direct costs», incluye materias primas, aranceles, flete y mano de obra directa. En «Calculate your break-even point» también indica: “include these indirect costs” («incluye estos costos indirectos»). Usar el costo de reposición actualizado es una recomendación de planificación para esta revisión; puede dif...
API de pagos

Cómo diseñar una API de pagos idempotente: claves, reintentos y estados

Cómo diseñar una API de pagos idempotente: claves, reintentos y estados Una clave estable permite reconocer los reintentos y consultar el estado de la misma operación. Una API de pagos idempotente identifica los reintentos de una misma operación para no tratarlos como pagos nuevos. Para diseñarla, conviene conservar una clave estable, registrar el estado de la operación y prever qué hacer cuando se pierde la respuesta del proveedor. El siguiente contrato es una propuesta de diseño. Debe adaptarse al proveedor, al método de pago y a los requisitos del negocio; por sí solo no garantiza un cobro único de extremo a extremo. Una clave por operación lógica El cliente puede enviar una cabecera Idempotency-Key en POST /payments y conservarla hasta resolver la operación. Los reintentos del mismo pago usan la misma clave. Una captura o un reembolso son operaciones distintas y reciben claves propias. Una opción es generar un UUID aleatorio sin datos personales. Stripe recomienda «V4 UUIDs, or ...
Consultas SQL

Índices en PostgreSQL: cómo comprobar si una consulta realmente los necesita

La utilidad de un índice se evalúa con mediciones de la consulta y de la carga de trabajo completa. Índices en PostgreSQL: cómo comprobar si una consulta realmente los necesita Para evaluar un índice, mide su efecto sobre la consulta y considera también el coste para el resto de la carga. Un Seq Scan no demuestra por sí solo que falte un índice: la documentación de PostgreSQL 18 presenta el caso de una tabla de 100 filas que probablemente caben en una página, donde una lectura secuencial puede ser apropiada. Es un ejemplo de escala, no una regla para cualquier consulta. Sin una consulta concreta, su plan, los datos y mediciones de la carga, no se puede determinar si un índice específico mejorará el rendimiento o si su beneficio compensará su coste. Este procedimiento ayuda a reunir esa evidencia. 1. Obtén una línea de base Para una consulta SELECT, ejecuta EXPLAIN (ANALYZE, BUFFERS) seguido de la consulta y guarda el resultado. Como criterio de prueba, utiliza datos, parámetros y vo...
Finanzas

Antes de refinanciar una deuda: compara el costo total, no solo la cuota

La cuota, el plazo y los cargos determinan cuánto queda por pagar en cada opción. Antes de refinanciar una deuda: compara el costo total, no solo la cuota Una cuota más baja puede aliviar el presupuesto mensual, pero no siempre significa que la nueva deuda costará menos. Al hablar de refinanciación hipotecaria, la Oficina para la Protección Financiera del Consumidor de Estados Unidos (CFPB) advierte que un plazo más largo «podría significar un pago mensual más bajo, pero pagar más dinero en total». Compara lo que falta por pagar Para decidir, compara los desembolsos futuros de mantener la deuda con los de refinanciar el mismo saldo. No incluyas lo que ya pagaste: ese dinero no cambia entre las dos opciones. Deuda actual: pide el saldo pendiente y el calendario de pagos que queda por delante. Suma las cuotas y los demás pagos futuros aplicables. Nueva deuda: suma todas las cuotas previstas, cualquier pago final y los cargos que debas pagar por separado. Incluye una posible penalizaci...
Arquitectura

Reintentos en APIs: cómo evitar duplicados y sobrecargas

Ilustración generada con IA: una política de reintentos combina seguridad, esperas y límites. Reintentos en APIs: cómo evitar duplicados y sobrecargas Un reintento puede recuperar una llamada que falló, pero también puede repetir una escritura ya ejecutada o añadir presión a un servicio saturado. Una política práctica combina operaciones seguras de repetir, límites de tiempo y de intentos, esperas escalonadas y atención a las indicaciones del servidor. Un timeout no confirma que la operación haya fallado Si una petición agota su tiempo de espera, el servidor podría haber completado la operación aunque el cliente no haya recibido la respuesta. AWS presenta este problema de resultado incierto en «Retrying and side effects» . Antes de repetir una escritura, comprueba que sea seguro hacerlo o que la primera petición no se haya aplicado. La sección 9.2.2 del RFC 9110 define la idempotencia por el efecto previsto de varias peticiones idénticas: debe ser el mismo que el de una sola. PUT, DEL...

Buscar este blog