Comercio electrónicoVentas en redes sociales: campañas, programación y prompts
Programa contenido, revisa campañas Meta y usa cuatro prompts de IA. Conecta el marketing con pedidos de ecommerce y registros ERP en Social Hub.
Coordina tienda en línea, POS y entregas con reservas, inspección de devoluciones y conciliación del cobro contra entrega. Guía con ejemplos prácticos.
Autor
Anichur Rahaman

Dos personas quieren la última chaqueta azul: una está en caja y otra termina su compra en línea. Ambas pantallas muestran una unidad disponible. ¿Quién se la lleva? Es un ejemplo didáctico, no un caso real de un cliente. Expone el problema central: un canal promete algo antes de que el otro se entere.
Más canales sirven cuando puedes cumplir sus promesas. No necesitas vender en todas partes. Si combinas web, tienda y pedidos por chat, necesitas una autoridad definida sobre el inventario, reglas por ubicación y un camino visible para resolver excepciones.
Seguiremos la chaqueta desde la disponibilidad hasta la reserva, el despacho, la devolución y la liquidación del dinero. La idea es entender las decisiones que hacen confiable el inventario, sin suponer que una base compartida elimina cualquier error.
Los registros maestros que compiten son una causa frecuente de sobreventa. También influyen las recepciones registradas tarde, los conteos incorrectos, las reservas vencidas sin liberar, el POS sin conexión y los SKU mal relacionados. Sistemas separados pueden funcionar bien con responsabilidades, entrega de mensajes, conciliación y gestión de fallos bien diseñadas. Sincronizar no es, por sí mismo, un defecto.
Los síntomas te van a sonar:
Separa el canal de venta de la ubicación física. La web es un canal; la sucursal es una ubicación. Un pedido puede surtirse desde varias ubicaciones según sus reglas. Un proceso de inventario con autoridad definida puede publicar vistas de disponibilidad de solo lectura. Esas vistas pueden retrasarse: la aceptación final necesita una reserva protegida, no una pantalla desactualizada.

Conserva un registro de movimientos físicos: recepciones, despachos, traspasos, devoluciones inspeccionadas y ajustes aprobados. Lleva las reservas como compromisos relacionados, pero distintos. Reservar cambia lo que puedes prometer; no saca una caja del almacén. Los saldos resumidos agilizan las consultas si se actualizan de forma consistente y pueden conciliarse con sus registros de respaldo.
Define las cantidades por SKU, ubicación y unidad de medida. Si tienes mercancía dañada o stock de seguridad, tres etiquetas no bastan:
| Cantidad | Significado |
|---|---|
| En existencia | Físicamente en la ubicación, incluidas unidades bloqueadas si esa definición las abarca. |
| Reservado | Comprometido para pedidos aceptados, todavía sin despachar. |
| No disponible | Dañado, en cuarentena o bloqueado por otro motivo, sin incluir reservas. |
| Margen de seguridad | Cantidad retenida por separado, si la política lo utiliza. |
| Disponible para prometer | Existencia − reservado − no disponible − margen de seguridad, sin categorías superpuestas. |
Ejemplo: 12 unidades en existencia, 3 reservadas, 2 dañadas o en cuarentena y 1 de seguridad. Si las categorías no se superponen, disponible para prometer = 12 − 3 − 2 − 1 = 6. Una orden de compra en camino no es mercancía lista para despachar. Si aceptas pedidos contra recepciones futuras, muéstralos como una promesa distinta con una fecha realista.
Volvamos a la última chaqueta. Comprobar disponibilidad y confirmar la reserva debe ser una operación protegida: otra venta no puede tomar la misma pieza entre ambos pasos. Un libro de movimientos no lo garantiza por sí solo. Libera una reserva una sola vez al cancelar o vencer; consumirla al despachar no debe descontar dos veces el stock físico. Para un POS sin conexión, asigna un cupo separado o limita las promesas de la última pieza hasta reconectar.
Este recorrido breve muestra almacenes, sucursales, movimientos de inventario y alertas de bajo inventario en un solo sistema.
Una plataforma compartida puede simplificar el punto de venta, pero el negocio debe decidir sus reglas. Prueba lo siguiente en vez de darlo por automático:
El estado de entrega aporta evidencia sobre un paquete; no prueba el cobro ni define por sí solo cuándo reconocer ingresos. Mantén separados cumplimiento, pago, devolución y liquidación. Automatiza lo que admita la integración y asigna las excepciones pendientes a una persona responsable.
Ejemplo de pago contra entrega: el transportista cobra 100 unidades monetarias, descuenta una comisión documentada de 8 y transfiere 92. Concilia cobro bruto, comisión y abono bancario juntos. Si transfiere 90, deja los 2 restantes visibles para investigar, sin darlos de baja en silencio. Finanzas determina cuentas y tratamiento fiscal. Una devolución posterior a la liquidación necesita ajustes vinculados; no debe borrar la evidencia del pago original.
El recorrido de entregas que verás abajo muestra paqueterías, zonas, repartidores y el estatus en vivo de cada paquete.
| Indicador | Definición |
|---|---|
| Exactitud por línea | Líneas SKU-ubicación correctas ÷ líneas revisadas × 100; informa aparte diferencias de valor. |
| Cancelación por stock | Pedidos aceptados cancelados por falta de stock ÷ aceptados de la misma cohorte. |
| Resultado de entrega | Paquetes entregados, parciales, devueltos y abiertos, por cohorte de despacho. |
| Abonos sin conciliar | Importe y antigüedad de diferencias sin explicar, no solo archivos importados. |
| Plazo de liquidación | Tiempo de entrega a liquidación para lo liquidado, más antigüedad de lo pendiente. |
Acuerda una línea base y objetivos con Operaciones y Finanzas. Define cohorte, período y denominador antes de comparar. No existe un porcentaje saludable de inventario ni una meta de siete días para todos los cobros contra entrega. Estos indicadores combinan inventario, entregas y pagos; un libro de stock no basta para calcularlos todos.
Usa la demo de StoreConsole para probar tu pedido entre Inventario, POS y Entregas. Confirma los módulos, capacidades del transportista y permisos de tu configuración. Pide ver un conflicto por la última pieza, una devolución dañada y un abono sin conciliar, además de una venta exitosa.
Revisión: 4 de noviembre de 2026. La documentación de estados de Shopify explica por qué no toda la existencia física se puede vender. PostgreSQL documenta bloqueos que ayudan a una transacción bien diseñada, sin sustituirla. Los cálculos y flujos son ejemplos didácticos, no garantías de funciones del producto.
Anichur Rahaman es arquitecto de software y creador de StoreConsole. Diseña sistemas de comercio y ERP para negocios en crecimiento, con enfoque en arquitectura orientada a eventos, integridad de datos y operación en servidores propios.
Sobre el autor
Anichur Rahaman
Seguir Leyendo