Herramientas personales

Homologar

De Punto Salud Docs

Saltar a: navegación, buscar

IntegreEInnove.png

La información en esta página está orientada a desarrolladores que desean realizar la tarea técnica de integración con PuntoSalud. La integración u homologación aquí referida, es la implementación de funcionalidades para que los usuarios puedan desde su misma aplicación de gestión realizar la obtención de autorizaciones sin necesidad de salir de su entorno de trabajo. De esta manera no solo se evita la doble carga de información que se realiza en otras alternativas como en la solicitud de autorizaciones vía POS o por IVR, si no que se agiliza la operación al prestador permitiéndole interactuar con su sistema, y su nomencladores y pudiendo procesar las respuestas obtenidas instantáneamente evitando así gastos administrativos.

Para permitir la integración se ofrecen una serie de herramientas o posibilidades entre las cuales el desarrollador puede optar libremente de acuerdo a sus necesidades y experiencia.

Empezar! Recursos Respuestas

Detalle finales de la integración:




Formatos:

Mecanismos:

Aplicaciones:

Mantener:

Mejorar:

En esta sección encontrará los enlaces a cada uno de los Recursos y Manuales requeridos, guías para seleccionar la versión a utilizar de acuerdo a su tecnología y el tipo de usuario al que apunta su aplicación. En caso de tener alguna duda puede informarla a la Mesa de Ayuda y contactar directamente al soporte para desarrolladores vía mail.


Empezar!

¿Por qué encarar una integración?

Integrar u homologar su aplicación permitirá que los usuarios, sus clientes, puedan aprovechar las ventajas de tener una autorización de quien finalmente pagará los servicios médicos que está prestando ANTES de que se produzca el gasto médico, evitando así todo tipo de débitos por motivos administrativos. Simplificando y agilizando la presentación de la facturación por tener ya pre-auditadas las prestaciones realizadas y medicamentos dispensados. Asegurando que las prestaciones son facturadas adecuadamente de acuerdo a la condición de IVA de cada paciente atendido al tomar de la respuesta este entre otros datos y evitando refacturaciones y demoras. Permitiéndole a los pacientes que acuden los centros donde es usado su sistema, puedan acceder a la cobertura que ellos pactaron con los financiadores sin necesidad de realizar trámites previos.

En definitiva eliminando toda la incertidumbre que genera usualmente la utilización de una cobertura médica, haciendo a su vez más eficiente la operación administrativa de los prestadores médicos y financiadores y más simple el acceso para los pacientes.

¿Qué significa hacer una transacción?

Esquema funcionamiento.png

El intercambio de datos entre los prestadores de salud, y los entes financiadores para realizar la validación de los consumos prestacionales en tiempo real se realiza mediante una transacción. Una transacción es un proceso indivisible en el cuál el prestador envía cierta información al ente financiador y tras ser procesada, éste devuelve una respuesta.

Ejemplos de Transacciones
Operación Requerimiento (Información enviada) Respuesta (Información recibida)
Consultar estado de un beneficiario Identificación del prestador, identificación del beneficiario, fechas, otros datos auxiliares Estado del beneficiario (habilitado, inhabilitado, etc.)
Informar que se realizará una prestación a un beneficiario Identificación del prestador, identificación del beneficiario, código de la prestación, fechas, otros datos auxiliares Autorizado (número de autorización) o Rechazado (Motivo del rechazo)

Para simplificar la realización de transacciones entre el prestador y el ente financiador, SITEL (una herramienta de ITC) se encarga del intercambio de información entre las dos partes independizándolas de los problemas tecnológicos que implica la interconexión de dos sistemas informáticos heterogéneos y distantes. SITEL es básicamente una plataforma Cliente/Servidor. SITEL Cliente se encuentra instalado en el prestador y SITEL Servidor es el encargado de interactuar con el ente financiador.

¿Cómo seleccionar un método y formato?

Los pasos básicos serán:

  1. Seleccionar el formato adecuado para su producto
  2. Realizar las modificaciones necesarias
  3. Probar la integración
  4. Pedirle a su cliente que solicita las altas a las prepagas y obras sociales con las que desea realizar la operación en línea
  5. Coordinar con ITC la instalación de aplicativos de comunicaciones si fuese necesario
  6. Actualizar su aplicación
  7. Verificar si utiliza nomencladores propios
  8. Comunicar a los usuarios contactos con la Mesa de Ayuda
  9. Finalmente puede poner a disposición de nuestra Mesa de Ayuda documentación para que podamos guiar a los usuarios de su aplicación cuando se comuniquen con nosotros.

1. Seleccionar el formato adecuado para su producto

Esta es una guía simplificada para guiarlo en su elección.

Aplicaciones propias ya homologadas con Formatos de TercerosAplicaciones comerciales ya homologasWeb ServiceAdesfaCliente ActiveXV250 PrestadoresIntercambio de ArchivosFormatos V250 o XMLFormatos V250 o XMLSocket TCPSeleccionFormato.png
Acerca de esta imagen

2. Realizar las modificaciones necesarias

Es muy importante que la transacción sea realizada antes de que se produzca el gasto médico.

Así por ejemplo si tiene un sistema de farmacia, debería obtener la respuesta antes de emitir el ticket fiscal de esta manera obtiene del financiador, las cantidades, precios de los medicamentos y coberturas asignadas al afiliado, pudiendo corregir los montos del ticket fiscal antes de facturarle al cliente el neto.

En el caso de un prestador médico (ya sea un consultorio u hospital) hay diferentes puntos donde se puede realizar un control efectivo y capitalizar las ventajas, a saber:

  • Al momento de asignar un turno: la Verificación del Afiliado o Afiliado y Prestación, le permite al prestador asignar un turno solo a pacientes con cobertura, o por lo menos aquellos que no la tengan que lo sepan de antemano antes de concurrir el centro médico. Evitando que quede un turno vacío para el prestador y permitiéndolo también al paciente que solucione su problema de afiliación antes de concurrir a la consulta.
  • Al momento de la atención: a diferencia del caso anterior en lugar de Verificar aquí se realiza una transacción similar que Informa los servicios solicitados. La diferencia radica que en caso de ser Aprobada esta última, los servicios solicitados quedan acreditados en una cuenta corriente del prestador, en cambio la Verificación no. En los casos necesarios el prestador obtendrá también el copago que debe cobrarle al paciente además de los datos usuales.
  • Al momento de la facturación: en muchos casos, el prestador realizar un control administrativo posterior a la atención para verificar que se han seguido todos los procedimientos requeridos por el financiador con el objeto de evitar débitos. En estos casos será necesario que el personal de administración pueda realizar Anulaciones e Informar Prestaciones. Las autorizaciones obtenidas no pueden modificarse, se precisa realizar un cambio debe anular la transacción dado que se encuentra acreditada y volverla a informar.

3. Probar la integración

Una vez terminal la homologación comuníquese con ITC para obtener un alta de prueba en el o los financiadores que desee testear. La homologación es única para todos los financiadores. ITC actúa como un gateway de procesamiento que realiza las conversiones de semántica (del contenido del mensaje) y de sintaxis (del formato) para que pueda ser interpretado por cada financiador.

4. Altas en Financiadores

Normalmente el prestador debe solicitar un alta en cada financiador. Este es necesario dado que el financiador no solo es quien cubre los costos de la validación pero principalmente porque muchas de las validaciones requieren que se encuentre cargada las condiciones de contratación pactadas entre prestador y financiador. Generalmente esta alta se inicia a través de ITC que intenta agilizar los contactos con cada financiador.

5. Instalación y Actualización de Aplicativo

De acuerdo al mecanismo usado es normalmente necesaria la instalación de una aplicación de comunicaciones dentro del prestador médico. Esta aplicación, es provista por ITC, y es necesaria para tomar el mensaje, encriptarlo, establecer el vínculo con ITC y transmitirlo. Normalmente el funcionamiento de esta aplicación es transparente o invisible al usuario de la aplicación de gestión.

Aplicaciones ya homologadas con Formatos de Terceros

La política de ITC es intentar aceptar distintos formatos que prestadores puedan tener ya implementados, permitiendo así la reutilización de una homologación existente para poder interactuar con los financiadores atendidos por ITC. Existen en la actualidad una cantidad de formatos funcionando y otros en desarrollo. Si usted posee un sistema de gestión homologado y su formato no se encuentra disponible aquí comuníquese con nosotros para que podamos analizar su implementación.

Entre los formatos disponibles están:

Entre los formatos en desarrollo:

Aplicaciones comerciales homologadas

El listado aquí no constituye un apoyo al uso de una aplicación determinada, si no es información provista para que usted pueda realizar su propia evaluación. Corresponde solo a aplicaciones comerciales y desarrollos propios que se encuentran a disposición:

Mercado Aplicación
Sistemas de Farmacia
Gestión de Hospitales
Laboratorios de Análisis Clínicos
Odontología

Si su aplicación no aparece aquí y desea incluirla contáctese con nosotros.

Manejo de Credenciales con Banda Magnética

Cuando realiza la integración de aplicaciones, la lectura de la banda magnética no requiere un manejo especial. Esta lectura es en todos los casos tomada con un lector con interfase de teclado o con interfase USB que se comporta como un teclado. Es decir los datos se ingresan como si fuesen tipeados por el operador. Esta lectura no requiere un parseo, esto es importante dado que la magnetización de las credenciales en el sector de la salud no se encuentra estandarizada no hay y entonces ninguna garantía de que la misma no cambia de financiador en financiador y a lo largo del tiempo para el mismo financiador cuando este cambia de proveedor.

La lectura de la banda, es enviada en los formatos V250, V107 o Adesfa tal cual es leída, todos los caracteres son enviados en un mismo campo. En la respuesta de la transacción obtendrá todos los datos de la credencial parseados, número, nombre, sexo, etc.

Nomencladores Propios

Independiente del formato utilizado, el prestador puede utilizar su propia forma de denominar gran parte de la información enviada. ITC toma la función de transcodificar o convertir estas porciones del mensaje para que pueda ser interpretada por cada financiador. Entre los nomencladores propios que se pueden manejar son el de prestaciones, motivos de ingreso y egreso de internación, motivos de finalización de terapia en tratamientos por sesiones, y el manejo de medicamentos durante la internación entre otros. En el caso de los diagnósticos en general es un dato no controlado en línea, es decir se aceptará el código enviado, en algunos formatos se solicita la identificación de la nomenclatura del diagnóstico además del código.

En general el resto de los datos se intenta que sean estandarizados, así por ejemplo la identificación de los prestadores se realizar mediante CUIT, y en algunos casos de los prescriptores y efectores también. ITC convierte estos valores a la nomenclatura requerida por el financiador en todos los casos.

Recursos

Formatos

Dispensa de Medicamentos Servicios Médicos
De longitud fija Formato V250 Farmacia Formato V107 Prestadores
Formato V250 Prestador
De longitud variable Formato ADESFA Cliente ActiveX
Formato Prestadores XML

Mecanismos

Web Service Farmacia

  • El método a invocar se llama ProcesarXML.
Operation Notes
Public Parameters:
InformarPrestacion(
string version, in string version de los archivos que envía (por ej. para XML farmacia enviar V251)
string empresa, in string código de empresa (ver valores en la tabla)
string actividad, in string actividad (por ej. Farmacia enviar 1 ver la actividad en la descripción del formato. Permite indicar formas especiales de procesamiento de la transacción de acuerdo al tipo de actor)
string licencia, in string licencia (es un dato a solicitar no es público)
string mensaje ):string in string mensaje (se incluye la transacción).

Web Service Prestadores

  • Existe un único método con lo siguientes parámetros:
Parámetro Notas
pas Es un token válido para un único lugar físico de un prestador y un financiador determinado. Por ejemplo: 32dbf220f1ab2303592b4a076162c221600ef704
msj Mensaje a enviar. Por ejemplo: <Mensaje><EncabezadoMensaje><VersionMsj>1.0</VersionMsj></EncabezadoMensaje></Mensaje>

Intercambio de Archivos Planos

El mecanismo de funcionamiento de Sitel Cliente fue diseñado para que desde la perspectiva del prestador, la realización de transacciones, sea similar a la utilización de bandejas de entrada y de salida como las que se encuentran en cualquier escritorio del mundo real. Esto traducido a términos informáticos implica que cada terminal que realiza transacciones, utiliza un directorio o carpeta de salida de requerimientos denominado upload y otro directorio o carpeta de entrada de respuestas denominado download. De esta manera, en la bandeja de salida se depositarán los requerimientos y las respuestas correspondientes generadas por el ente financiador se encontrarán en la bandeja de entrada. Depositar un requerimiento en la bandeja de salida (upload) consiste en grabar un conjunto de archivos cuyos nombres y estructuras se encuentran predefinidos (ver Formatos). Otro tanto ocurre con la respuesta. Para obtener la respuesta de la bandeja de entrada (download) debe leerse un conjunto de archivos, también predefinidos, en sus nombres y estructuras.De acuerdo a estos conceptos cuando se realiza una transacción los pasos son:

  1. Generar los archivos del requerimiento
  2. Grabar los archivos en la bandeja de salida (upload)
  3. Esperar la respuesta en la bandeja de entrada (download)
  4. Leer la respuesta de la bandeja de entrada (download)
Pseudo-código sugerido

La realización de una transacción es un proceso de intercambio de información entre el prestador y el financiador. Se describe aquí el pseudo-código sugerido para la homologación cuando se busca que ese intercambio se realice mediante archivos de texto plano o simples copiados localmente en su máquina:

/* en este ejemplo se usa una terminal creada en forma aleatorio como directorio de la terminal */
/* este ejemplo es para homologación de transacciones farmacéuticas utilizando V250 pero es extrapolable a cualquier versión */ 
/* para homologar transacciones de con otros formatos simplemente revise la documentación del mismo todos los formatos */
/* contienen un archivo de identificación en general llamado _svl.0, un archivo de cabecera con datos no repetitivos */
/* normalmente _svl.1 o nnnn.xml y uno o más archivos con items repetitivos _svl.2, _svl.3, _svl.4 etc.  */

Genero un nombre de terminal aleatorio termAleatorio
Mientras exista archivo termAleatorio
{
       /* Existe directorio, genero otro nuevo nombre */
       Genero un nombre de terminal aleatorio termAleatorio
}
Crear directorio termAleatorio\upload
Crear directorio termAleatorio\download
Armar archivo termAleatorio\upload\_svl.1
Si transacción lleva medicamentos {
       Armar archivo termAleatorio\upload\_svl.3
}
Si transacción necesita diagnósticos asociados a la receta {
       Armar archivo termAleatorio\upload\_svl.4
}
/* creo el archivo de identificación de la transacción */
Armar archivo termAleatorio\upload\_svl.0
/* esto dispara la transacción */
Crear archivo tx\termAleatorio
Mientras no exista archivo termAleatorio\estado.rsp
{
       esperar 1 segundo
}
Abrir archivo termAleatorio\estado.rsp
Leer de archivo primer carácter
Cerrar archivo
Si primercaracter del archivo es ‘0’
{
       /* la transacción salió bien a nivel de conexión */
       Si existe termAleatorio\download\_sitel.err {
               /* hubo un error de formato de la transacción */
               /* termAleatorio\download\_sitel.err contiene los errores */
               Imprimir termAleatorio\download\_ticket.prn
               /* es el ticket confeccionado por el validador */
       }
       si no
       {
               Abrir archivo termAleatorio\download\_svl.1
               Mostrar archivo.Comentario/Display
               Si archivo.Error=’0000’
               {
               5
                  /* la transacción está aprobada */
           }
           si no
           {
                     /* la transacción no esta aprobada se puede consultar si alguno */
                     /*  de los items de la receta es responsable de que la transacción 
                         no haya sido aprobada */
                     Abrir archivo2 termAleatorio\download\_svl.3
                     /* el campo archivo2.Error es ’00’ o ’99’ para prescripciones sin error */
                     Cerrar el archivo2
           }
           Cerrar _svl.3
       }
}
si no
{
      /* hubo un problema de conexión */
      Mostrar contenido de termAleatorio\estado.rsp
}
Eliminar la carpeta termAleatorio

Copia de los archivos

El árbol de directorio Sitel puede estar, en la misma máquina (local) o remoto en un servidor de comunicaciones (en otra máquina de la red), usualmente un gateway Linux de ITC, que tenga la aplicación de comunicaciones Sitel Cliente instalada.

La copia de los archivos se podrá hacer directamente, vía un Samba (en el caso de un Linux remoto) o también mediante una conexión a un puerto FTP, SCP, o SFTP de server remoto de comunicaciones.

Conexión a un socket TCP

En lugar de copiar archivos de texto en un directorio local o en un recurso compartido de su red como en el caso anterior, puede utilizar una aplicación provista por ITC llamada SitelDispatcher. Con esta aplicación podrá conectarse desde su aplicación utilizando un socket TCP a otra máquina dentro de comunicación de la red que tenga SitelDispatcher y Sitel Cliente.

Se transmitirá con este mecanismo un único archivo que se compone de TAGS que se denominan con el nombre del archivo del formato y corchetes así el archivo _svl.0 aparecerá como [_SVL.0] y debajo de este el contenido, por ejemplo:

Archivo de envío _svl.itc:

[_SVL.0]
V106110PRUEBA00
[_SVL.1]
307010203556105316067195620220301CA  000000MN00123420030422            000000000000            00000000000102031  
[_SVL.2]
888889    1002         
420102    1001         
420101    1001         
420101    1001         
420101    1001         
420101    1001         
[FIN]

Puede abrir "n" conexiones simultáneas al socket TCP sin necesidad de gestionar directorios como ocurre con el caso anterior.

Aplicaciones

  • Ver manual jSitelProcess y bajar aplicación de comunicación: cuando no pueda usarse Sitel Cliente por tener un firewall o debido a que su carrier de Internet tenga cerrados ciertos puertos indispensables, puede utilizar jSitelProcess una aplicación Java que permite el procesamiento de transacciones a través "solo" por Internet pudiendo ser configurado para pasar a través de un proxy como si el usuario "estuviera navegando por Internet" es decir sin abrir puertos especiales, e incluso permitiendo la utilización de password para navegar.

Respuestas

Seguimiento de Reclamos Operativos

Puede dejar su reclamo operativo aquí. Nuestra Mesa de Ayuda atiende reclamos especialmente de índole técnico, los reclamos relacionados con respuestas de los financiadores sin generalmente respondidas directamente por estos. Sus reclamos al respecto pueden ser canalizados por ITC o directamente a través de ellos. Podrá encontrar más datos al respecto consultado directamente en la documentación de cada uno.

Mecanismos de Contingencia

En ciertas condiciones, ya sea por problemas técnicos o operativos necesitará contar con algún mecanismo alternativo para poder realizar autorizaciones en forma circunstancial. Le presentamos aquí las alternativas:

Mecanismos independientes. Para acceder a estos mecanismos deberá contar con un alta previa:

  • IVR al (011) 4515-0500 (+): no requiere ninguna instalación pero normalmente es complicado disponer de teléfonos con habilitación para realizar llamadas salientes en grandes centros y que además no estén con sus líneas telefónicas saturadas.
  • WebPos (+): simple pero no posee todas las transacciones implementadas, si le permitirá realizar todas las verificaciones para atender a los pacientes sin riesgos. Requiere que disponga de conexión.
  • eMail (+): simple pero requiere el conocimiento de una nueva filosofía de trabajo que es la transacción incremental.

Envío de la transacción como Diferida: las aplicaciones integradas disponen de un tipo de transacción que les permite reeneviar solicitudes pero que estas sean procesadas con la particularidad de que el servicio ya se realizó. Es decir el financiador contempla la posibilidad eventual de que pudiera haber ocurrido un problema técnico al momento del envío de la transacción original y ofrece esta alternativa a través de la cual la transacción es sometida reglas más laxas de control una vez que el problema haya sido solucionado. Esta transacción solo debe utilizar en circunstancias especiales. Su uso injustificado podría derivar en un débito.

Utilización de una aplicación local de validación: PCPOS es una aplicación desarrollada por ITC cuya única función es la realización de transacciones. Es posible utilizar es aplicación ya sea para realizar transacciones poco frecuentes que no se encuentran homologadas en el sistema de gestión, como una aplicación de contingencia, o para ser utiliza en algún lugar aislado que posea el prestador en el cual no disponga de conexión con el sistema principal del centro. El uso de esta aplicación requiere un doble data entry de datos (en la aplicación y luego en el sistema de gestión del prestador. Existen formas de exportar las transacciones procesadas en PCPOS).

Migrar a V250

La principal diferencia de V250 sobre otros formatos, es que V250 introduce el concepto de que la transacción no es solo convertida en formato y transcodificados algunos campos para adaptar la solicitud enviada por el prestador a cada uno de los formatos manejados por los financiadores. Si no que también introduce el concepto de pre/post procesamiento de las transacciones para incorporar nuevas funciones que el financiador no tiene ni puede desarrollar y que son importantes para el prestador. Por ejemplo:

Características Diferencia con el manejo en otros formatos como V107
Anulación de una Transacción Algunos financiadores hacen un procesamiento constante de las transacciones autorizadas en el departamente de facturación. Es así que las transacciones son automáticamente pasadas a facturación y por ende luego de una cantidad de días no pueden ser Anuladas. Esto dificulta a las aplicaciones de gestión y sus usuarios porque pasados varios días el prestador no puede eliminar de su cuenta corriente una transacción que no pretende cobrar y debe hacerlo manualmente. V250 agrega una capa permitiendo la anulación de toda transacción aprobada si el prestador no la ha presentado para cobrar.
Liquidación Electrónica V250 intenta valorizar las prestaciones al momento de la venta, a diferencia de esto la mayoría de los otros formatos dejan al prestador proponer un precio en un proceso extra cuando arman el medio magnético. V250 computará los totales seperando por la condición de IVA de cada afiliado.
Control de Duplicidad Normalmente el financiador no la realiza. Es responsabilidad luego del prestador solicitar la documentación respaldatoria.

Migrar a V107

Si usted ya posee su sistema homologado con versiones anteriores de la familia V10x migrar a V107 le proveerá de las siguientes nuevas funciones, con una modificación muy simple dado que la adopción de este formato es solo una extensión del tamaño de los archivos de envío y recepción.

Función Características nuevas
Campo BANDA Te permite enviar el string leido con un lector sin necesidad de conocer el algoritmo de parseo que difiere de tarjeta en tarjeta y obtener de la respuesta los datos ya parseados.
Datos de respuesta del afiliado enriquecidos En la respuesta obtendrás datos del afiliado que antes solo estaban disponibles con información en el ticket y no como dato. Por ejemplo NOMBRE, SEXO, y FECHANACIMIENTO
Mejor manejo de Cosegures Se incluyen el coseguro total a cobrar al afiliado y los montos discriminados por prestación.
Nuevas transacciones médicas Posibilidad de adjuntar archivos a la transacción permitiendo el envio de datos complementarios: Protocolo Quirúrgico, Protocolo Anestesia, Informe Médico, Resultado de Laboratorio, Pre-factura
Nuevas transacciones administrativas Consulta de Tickets, Consulta de Lotes, Cierres de Lote que permitirán en un futuro la liquidación electrónica sin necesidad de enviar un archivo ni papeles.
Flexibilidad embebida para el futuro Campos filler para incorporar datos futuros de envío o respuesta manteniendo la longitud fija.

Formatos de medio magnético para presentar facturación

El formato del archivo de liquidación depende del financiador. V250 intenta realizar una estandarización que mediante una única transacción que elimina no solo la necesidad de confeccionar el archivo si no, también la necesidad del cálculo de totales y del envío. Para farmacia V250 y Adesfa (al cual también lo hemos incorporado) tienen esta presentación digital en forma obligatorio a través de los cierres.

Para prestadores médicos, existe en V250 y otros formatos, la capacidad de solicitar digitalmente mediante una transacción la liquidación. Sin embargo varios financiadores no han asignado los valores en la contratación que permitirían obtener el cálculo exacto. En estos casos, donde no se haya implementado la liquidación electrónica es preciso remiter un médio magnético o contactar al financiador para conocer el mecanismo para solicitar la liquidación.

Por ejemplo, en OSDE Metropolitana (pero no en las filiales del interior), deberá remitir un archivo con el siguiente formato OSDE#Liquidación Manual con Medio Magnético.

Anexos

Ejemplo Pseudocódigo utilizando SFTP

/* considera el uso de SFTP */

sftp user@hostTransacciones:/share/terms/term01/estado.rsp 
Si existe archivo estado.rsp
{
       /* Existe una respuesta pendiente de proceso */
       Mostrar mensaje "Transacción anterior terminada anormalmente "
       Guardar archivo term01/download/_svl.itc
       Borrar archivo term01/estado.rsp
}
Armar y grabo localmente archivo _svl.itc
/* ver pseudocódigo para Intercambio de Archivos Planos */
*/ se van colocando los tags requeridos de acuerdo a la información a enviar */

sftp _svl.itc user@hostTransacciones:/share/terms/term01/
/* copio archivo ida */

sftp term01 user@hostTransacciones:/share/terms/tx/
/* copio archivo para disparar la transacción */

Mientras no exista archivo sftp user@hostTransacciones:/share/terms/term01/estado.rsp
{
       esperar 1 segundo
}
Abrir archivo term01\estado.rsp
Leer de archivo primer carácter
Cerrar archivo
Si primercaracter del archivo es ‘0’
{
       /* la transacción salió bien a nivel de conexión */
       sftp user@hostTransacciones:/share/terms/term01/download/_svl.itc
       /* todos los archivos de respuesta del formato vienen dentro de este separado por los TAGS */
       Abrir archivo term01\_svl.itc

       Si existe [_sitel.err] {
               /* hubo un error de formato de la transacción */
               /* los registros luego de [_sitel.err] contienen una descripción de los errores */
               Imprimir [_ticket.prn]
       }
       si no
       {
               Abrir [_svl.1]
               Mostrar archivo.Comentario/Display
               Si archivo.Error=’0000’
               {
               5
                  /* la transacción está aprobada */
           }
           si no
           {
                     /* la transacción no esta aprobada se puede consultar si alguno */
                     /*  de los items de la receta es responsable de que la transacción 
                         no haya sido aprobada */
                     Abrir [_svl.3]
                     /* el campo archivo2.Error es ’00’ o ’99’ para prescripciones sin error */
           }
           Cerrar archivo term01\_svl.itc
       }
}
si no
{
      /* hubo un problema de conexión */
      Mostrar contenido de term01\estado.rsp
}
Si existe archivo term01\estado.rsp
{
      Borrar archivo sftp user@hostTransacciones:rm /share/terms/term01/estado.rsp \ 
}