[ad_1]
Hola,
He leído muchos artículos sobre el desarrollo de aplicaciones POS con la biblioteca MS POS.net en C#. Sin embargo, mi requisito es un poco diferente.
Quiero crear una aplicación C# que se instalará como complemento del software POS existente (en cualquier dispositivo POS). Estoy creando un complemento para registrar detalles adicionales sobre la factura y el cliente en la base de datos.
tengo las siguientes dudas
1. ¿Es posible?
2. Si la respuesta a 1 es sí, ¿puede haber dos software que puedan recibir eventos desde el dispositivo POS? ¿Te gusta el código de barras que se escanea?
Cualquier ayuda muy apreciada
Saludos
Taher
Solución 1
1. ¿Es posible?
En cualquier ¿Dispositivo POS? NO.
El dispositivo POS más común en todo el mundo es una caja registradora antigua. No puedes ejecutar una aplicación C# en eso.
Probablemente los siguientes dispositivos POS más comunes en todo el mundo sean los sistemas POS patentados proporcionados por empresas como NCR que se instalan en los principales minoristas. No necesariamente ejecutan Windos, e incluso si lo hacen, no estarán configurados para permitirle instalar complementos de terceros.
La pequeña y mediana empresa promedio utiliza una caja registradora o compró un dispositivo POS de alguien como NCR o HP, quienes también les vendieron el software que lo ejecuta. Como mínimo, el software rastrea el inventario o genera informes de ventas. Y ese mismo proveedor tiene una opción de software que rastreará detalles adicionales, y ya está integrada y funcionando con ese sistema. No es probable que esos proveedores tengan muchos incentivos para ofrecerle una API abierta para agregarla a su sistema, y tampoco es probable que una empresa promedio corra el riesgo de optar por una solución de terceros si puede obtenerla del mismo proveedor. .
Entonces, ¿a qué te diriges?
De hecho, busque un dispositivo POS para el que desee desarrollar su aplicación.
¿Es solo un lector de códigos de barras, más un lector de banda magnética y algún software que se ejecuta en una computadora con Windows?
En ese caso, SÍ, es posible dependiendo de cuánto trabajo quieras hacer.
(Pero antes de continuar, averigüe si alguien realmente usará lo que tiene en mente. ¿Cuántas empresas tienen ese tipo de sistema POS? ¿El proveedor original ya ofrece una opción de software similar a la que tiene en mente? Encueste a algunos de las empresas y averigüe si (a) necesitan o quieren lo que usted tiene en mente y (b) si se lo comprarían a usted en lugar de al proveedor original).
2. Si la respuesta a 1 es sí, ¿puede haber dos software que puedan recibir eventos desde el dispositivo POS? ¿Te gusta el código de barras que se escanea?
SÍ, pero es posible que tengas que escribir tu propio controlador de dispositivo para hacerlo.
Es bastante improbable que el software POS existente tenga una API abierta de la que puedas obtener los datos. También es bastante improbable que los autores originales del software POS diseñaran el sistema con la idea de compartir el lector de banda magnética y el lector de código de barras con otro paquete de software.
Si ese es el caso, aún podría reemplazar los controladores de dispositivos existentes para esos dispositivos (o, quizás más simple, agregar un controlador a la cadena de controladores de dispositivos para los dispositivos) para poder interceptar los datos del dispositivo a medida que van al otro paquete de software.
(Para darle una idea de lo que estoy hablando, aquí hay un artículo de proyecto de código sobre cómo interceptar pulsaciones de teclas:
Monitoreo de pulsaciones de teclas[^]
Interceptar datos de algún otro dispositivo es quizás más complejo, pero los conceptos son los mismos).
Si tiene que escribir un controlador a nivel de kernel para hacer lo que quiere, terminará escribiéndolo en C o C++ nativo en lugar de C#.
Entonces la respuesta es:
Si es posible.
PERO, a menos que haya una razón realmente convincente para hacerlo, no vale la pena la cantidad de trabajo que implica.
Solución 2
¡Es absolutamente posible! Familiarícese con cómo funcionan juntos los componentes del POS. 1) Interfaz POS en la que está trabajando el cajero. 2) EPS o el sistema de pago que se conectará al terminal POS, pinpad, lector de códigos de barras, báscula y se conectará con el procesador/banco, etc. Descubra el formato del paquete TCP/IP, ya que muchos procesadores utilizan una red específica. protocolo: desde XML hasta algún tipo de protocolo TLV, etc. Cree una aplicación cliente/servidor para interceptar el paquete proveniente del EPS que va al procesador, extraiga los datos necesarios que desea almacenar en una base de datos y reenvíe el paquete al procesador. luego recibe la respuesta del procesador y la envía de regreso al POS.
NOTA: ¡todo esto supone que no hay cifrado involucrado! Además, con este enfoque no sabrá acerca de las transacciones en efectivo, cheques o tarjetas de regalo, ya que pueden procesarse a través de diferentes procesadores a menos que agregue un “rastreador” para cada destino posible.
POS—>EPS—->SU SNIFFER—>Procesador—>Banco: Y luego de vuelta.
[ad_2]
コメント