Pretix en eventos regionales: entradas, pagos y corte diario
Mini-caso para usar pretix en cámaras y colegios: entradas, órdenes, pagos, check-in, permisos, API, backup y corte diario verificable.
El corte de caja del sábado falla cuando 37 entradas online y 14 cobradas en puerta no coinciden con la lista de ingreso. En una cámara empresaria de San Martín, Mendoza, el evento regional parece ordenado hasta que tesorería debe explicar quién pagó, quién entró, quién recibió factura y qué anulación fue válida. pretix convierte esa discusión en órdenes, productos, pagos y check-in verificables.
Dónde aparece el desorden del evento
La falla reproducible empieza antes de abrir puertas. Un formulario vende entradas, una transferencia llega sin referencia, recepción imprime una lista vieja y un expositor pide facturación especial. La persona que atiende el mostrador resuelve con criterio, pero el lunes nadie puede reconstruir el corte. El tesorero necesita una sola historia: pedido, medio de pago, estado, comprobante, ingreso y devolución. La documentación de self-hosting de pretix está orientada a administradores de sistemas. La guía de requisitos de instalación enumera servidor WSGI, tareas periódicas, base SQL con recomendación fuerte de PostgreSQL, proxy reverso con SSL y Redis para caché, sesiones y colas. Ese conjunto revela la naturaleza del problema: vender entradas exige más que mostrar un botón de pago; también requiere correo, cola de tareas, sesiones y base transaccional. El objeto concreto es una mesa de acreditación con dos notebooks, lector de QR y una caja chica con efectivo de último momento. Si esa mesa trabaja con listas separadas, el corte diario nace roto. La diferencia puede ser mínima en dinero y enorme en confianza, porque cada entrada mal conciliada abre una discusión distinta.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, se crean productos: entrada general, socio, invitado o capacitación. Segundo, cada producto define precio, categoría, cupo y estado activo. Tercero, pretix crea una orden cuando alguien compra o reserva. Cuarto, el pago queda asociado a esa orden con estado y fecha. Quinto, el check-in valida la entrada en una lista. Sexto, tesorería genera corte con órdenes pagas, pendientes, anuladas y reembolsadas. Séptimo, backup guarda base, configuración y archivos relevantes. La API de pretix expone recursos para órdenes, facturas, transacciones, vouchers, check-in, listas de check-in, equipos, dispositivos y webhooks. En órdenes, los pagos pueden listarse, crearse, confirmarse, cancelarse o reembolsarse con endpoints separados. En listas de check-in, cada lista tiene contador de posiciones y contador de ingresos realizados. En productos, el recurso incluye precio, categoría, estado activo y nombre visible. El dato global suma una razón práctica: PostgreSQL aparece con 55,6% de uso en bases de datos dentro de la encuesta Stack Overflow 2025. Para un evento local, eso ayuda cuando hay que conseguir soporte, revisar consultas o restaurar un respaldo antes de abrir la acreditación.
Qué se instala o configura primero
Un piloto sobrio usa pretix, PostgreSQL, Redis, proxy TLS, correo saliente, dos usuarios con permisos separados y una política de backup. Con dólar oficial venta de ARS 1535, el primer alcance puede ubicarse entre USD 750 y USD 1.900, es decir entre ARS 1.151.250 y ARS 2.916.500. Incluye configuración inicial, productos, medios de pago manuales o integrados según alcance, equipos de trabajo, check-in, corte diario y restauración ensayada. No incluye comisiones de pasarela ni facturación electrónica a medida. UMSA puede acompañar el primer evento con un caso controlado: 120 entradas, 2 categorías, 1 lista de check-in, 2 operadores de mesa y 1 responsable de tesorería. El entregable verificable es un corte con órdenes pagas, pendientes, anuladas, reembolsos, ingresos validados y diferencias explicadas. Si el corte no cierra, la causa debe quedar en el sistema y no en una conversación de pasillo. El diseño operativo se parece al de una mesa de ayuda bien instrumentada. Una nota previa sobre Zammad 7 en cooperativas sirve para comparar permisos, grupos y respaldo. En eventos, los grupos separan venta, acreditación y tesorería; la restauración prueba que la historia completa vuelve antes del próximo encuentro.
Dónde se rompe y cómo probarlo
El primer riesgo es mezclar efectivo con pagos online sin estado común. La señal aparece cuando una entrada figura pendiente y la persona ya ingresó. La prueba crea una orden pendiente, registra pago manual, confirma ingreso y revisa el corte. El segundo riesgo es usar una sola cuenta compartida para acreditación. La señal aparece cuando nadie sabe quién anuló un ingreso. La prueba crea dos operadores, valida dos entradas, anula una y exige usuario, fecha y motivo. El tercer riesgo es respaldar tarde. La señal aparece cuando el evento terminó y el único export quedó en una notebook. La prueba restaura la base en una instancia separada, abre una orden, revisa pago, factura, check-in y lista asociada. La acción de esta semana es elegir el próximo evento y cargarlo completo antes de vender. Producto, orden, pago, check-in y corte deben vivir en el mismo circuito.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.