FDD-17662-BSTRONG Web Service Bogota Validado

DocuSign Envelope ID: 33F43D5D-75BF-4935-9F57-1EEFDE2DDB54
ESPECIFICACIÓN FUNCIONAL GAP-FIT
Web Service y Referencia de Pago
Gecolsa, Gestión de pagos y Recaudos
Preparado por:
SRF CONSULTORES S.A.S
Calle 119 # 14 a - 26
Teléfono: + 57 1 300 4901 - 3004902
Bogotá - Colombia
Información del documento
Nombre del documento: Documento Análisis de Requerimientos

Cliente: GECOLSA
Proyecto No:
Nombre del proyecto: BSTRONG
Sistema: D365 FINANCIAL AND OPERATIONS
Versión: D365 7.3 Update 15
Paginas:
Autor: David Camilo Téllez
Fecha de inicio del documento: 02/02/2018
Fecha última actualización:
Fecha de validación del
documento:
Documento recibido por:
Fecha:
Contenido
1. ANTECEDENTES ....................................................................................................................... 5
1.1 Consideraciones Generales .................................................................................................... 5
1.2 Propósito ................................................................................................................................ 5
2. DESCRIPCION DE LA MODIFICACIÓN ........................................................................................ 5
2.1. Lógica de Negocio (Dynamics 365) ........................................................................................ 5
2.1.1. Referencia de Anticipo .................................................................................................. 5
2.1.2. Impresión de los formatos para el cliente .................................................................... 7
2.1.3. Referencia de Pago: ....................................................................................................... 7
2.2. Lógica del Sistema para el WS:............................................................................................. 13
2.3. Servicio Web para Banco de Bogotá .................................................................................... 14
2.3.1. Método Referencia de Pago/Referencia de anticipo (Documento Bango Bogotá:
Caso de uso No1. Consulta de Factura por número de Factura): .............................................. 14
2.3.2. Método Resumen de Facturas (Documento Baco: Caso de uso No. 2 Resumen de
Facturas): ..................................................................................................................................... 16
2.3.3. Método Recaudo (Documento del Banco: 8.4 Caso de uso No. 4 Notificación de
pago de factura): ......................................................................................................................... 19
2.3.4. Reverso de pago de factura (Documento Banco: Caso de uso No 5 Reverso del pago
de Factura): .................................................................................................................................. 22
3. MANEJO DE ERRORES ............................................................................................................ 25
4. ROLES DE SEGURIDAD ........................................................................................................... 26
5. CASOS DE PRUEBA................................................................................................................. 26
Test Plan 1 – Generación de una Referencia de Anticipo en OV ..................................................... 26
Test Plan 2 – Generación de una Referencia de Anticipo en Llamada de Servicio .......................... 26
Test Plan 3 – Generación de una Referencia de Anticipo en Contrato de Rental ........................... 27
Test Plan 4 – Generación de una Referencia de Pago en Factura de OV ........................................ 27
Test Plan 5 – Generación de una Referencia de Pago en Llamada de ServicioError! Bookmark not
defined.
Test Plan 6 – Generación de una Referencia de Pago en Contrato de RentalError! Bookmark not
defined.
Test Plan 7 – Consumo de Servicios Web Bogotá............................................................................ 28
Test Plan 8 Consumo de Servicios Web Bogotá .............................................................................. 30
Test Plan 9 – Consumo de Servicios Web Bogotá Anticipo Contrato .............................................. 31
Test Plan 10 – Consumo de Servicios Web Bogotá Anticipo Llamada de Servicio .......................... 31
Test Plan 11 – Consumo de Servicios Web Bogotá Reversión Pago ................................................ 32
Elaboró
Nombre Rol en el Proyecto Firma
Realizó
CONSULTOR
DAVID CAMILO TELLEZ
DYNAMICS AX
Revisó
COORDINADOR
HERNAN RUGELES DE
CONSULTORÍA
GERENTE DE
OMAR COBO
PROYECTO
Aprobó
Nicolas Tobón Gerente de Proyecto
Yamile Sierra Process Leader

1. ANTECEDENTES
Actualmente Dynamics 365 no cuenta con un servicio Web que lo conecte con las entidades bancarias
mediante las cuales Gecolsa y sus filiales recaudan dinero. Este WS también requiere unas nuevas
validaciones y lógica del sistema que permita reconocer cuando es un pago de una factura o cuando es
un anticipo.
1.1 Consideraciones Generales
Se requiere el desarrollo e implementación de varias funcionalidades para el recaudo de dinero haciendo

una conexión directa desde D365 hacia los bancos. Esta funcionalidad permitirá recaudar el dinero en
conexión directa con las entidades bancarias de una manera más eficiente.
1.2 Propósito
Recaudar dinero de los clientes de manera más eficiente y que a su vez permita agilizar los procesos de
recaudo en el sistema.
2. DESCRIPCION DE LA MODIFICACIÓN
Este desarrollo permitirá recaudar más rápido las cuentas por cobrar de la compañía al igual que los
anticipos, los pagos parciales y reducirá la operatividad del área de cartera. Este desarrollo se dividirá
en varias funcionalidades, la primera será la lógica que modificar en el sistema, la segunda será la lógica
del sistema que compete al WS y la tercera será el WS como tal.
2.1. Lógica de Negocio (Dynamics 365)
Se solicitan campos y conceptos nuevos para desarrollar en el sistema con el fin que los servicios web
con el banco funcionen correcta y eficientemente.
2.1.1. Referencia de Anticipo

Se requiere que, en los parámetros del módulo de Cuentas por cobrar, pestaña Secuencias numéricas se
cree un nuevo campo llamado Referencia de Anticipo, este campo deberá consultar la tabla de
Secuencias numéricas para escoger una, esta consulta debe filtrar las secuencias numéricas que
pertenecen a la compañía en la que se está parametrizando además de consultar solo las secuencias
numéricas que son continuas. (Este parámetro es por empresa)
La construcción de esta secuencia se realizará de la siguiente manera:

01005000000001
Los primeros 3 caracteres (010) identificarán la empresa para cual se está recaudando. (Irá como
constante en la secuencia numérica). Esto con el fin que dentro del mismo servicio el sistema sepa por
cual entidad jurídica va a recaudar.
Los siguientes 2 caracteres (05) identificarán que es un anticipo (es fijo 05 Anticipo, 01 Factura). (Irá
como constante en la secuencia numérica). Esto permitirá que el sistema sepa que lo que se va a
registrar es un anticipo y no un recaudo o abono a cuenta.
Los siguientes 9 números son la numeración única de la referencia de anticipo.

Para identificar la secuencia de anticipo en los caracteres 4 y 5 se requiere crear un nuevo campo
llamado formato de anticipo en los parámetros del módulo de cuentas por cobrar, debe ser un campo
texto de longitud 2. Allí se parametrizará este valor que debe coincidir manualmente con la secuencia
numérica creada.
Esta Referencia consumirá un número cada vez que se genere la confirmación de los siguientes
documentos:
1. Órdenes de venta: Con la creación de la OV en el encabezado del documento se deberá generar
este número. Este campo deberá poderse visualizar, pero no editar del encabezado de la orden de
venta.
2. Llamadas de servicio (Proyecto): Cuando el proyecto se cree, se debe crear el número de referencia
de anticipo para que el cliente pueda realizar el anticipo. Se debe poder visualizar en el maestro del
proyecto. (Esto es a nivel de Proyecto no de subproyecto, en caso que se requiera los subproyectos
deben heredar el número del proyecto). Este campo se debe visualizar, pero no debe ser editable
3. Contratos: Cuando el Contrato se cree, se debe crear el número de referencia de anticipo para que
el cliente pueda realizar el anticipo. Este campo se debe visualizar, pero no debe ser editable
2.1.2. Impresión de los formatos para el cliente

Se requiere modificar los siguientes reportes para complementar la impresión de la referencia:
2.1.2.1. Reporte de confirmación de órdenes de Venta: (No confirmación Proforma)
Se requiere agregar la referencia en la parte superior derecha.
2.1.2.2. Informe de Proyectos

No requiere un formato de impresión, se le comunicará al cliente de manera externa, por vía
telefónica o por correo electrónico.
2.1.2.3. Informe de Contrato

3. No requiere un formato de impresión, se le comunicará al cliente de manera externa, por vía
telefónica o por correo electrónico.
3.1.1. Referencia de Pago:

Se requiere que, en los parámetros del módulo de Cuentas por cobrar, pestaña Secuencias numéricas
se cree un nuevo campo llamado Referencia de Pago, este campo deberá consultar la tabla de
Secuencias numéricas para escoger una, esta consulta debe filtrar las secuencias numéricas que
pertenecen a la compañía en la que se está parametrizando además de consultar solo las secuencias
numéricas que son continuas.
Esta Referencia consumirá un número cada vez que se genere una factura en el sistema, este número
será único por cada factura emitida y se generará de manera automática e inmodificable, este
consecutivo se manejará por entidad jurídica. Los puntos donde se genera factura en el sistema son los
siguientes:
1. Módulo de Cuentas por Cobrar, Factura de Servicios: Cuando se registre la factura (Momento en el que
se crea el número de factura), el sistema debe generar el número de Referencia de pago y consumir el
consecutivo de los parámetros mencionado anteriormente.
2. Módulo de Cuentas por cobrar, Ventas y marketing, órdenes de Venta Factura: Cuando se registre
la factura de la orden de venta, el sistema debe generar el número de Referencia de pago y consumir el
consecutivo de los parámetros mencionado anteriormente.
3. Módulo Proyectos  Factura de proyectos: Cuanto se registre la factura (No la prefactura), el sistema
debe generar el número de Referencia de pago y consumir el consecutivo de los parámetros mencionado
anteriormente.
4. Módulo Alquiler (Rental)  Facturación Rental: En el momento en que se facture el servicio

presado (registro contable), el sistema debe generar el número de Referencia de pago y
consumir el consecutivo de los parámetros mencionado anteriormente.
La construcción de esta secuencia se realizará de la siguiente manera:

01001000000001
Los primeros 3 caracteres (010) identificarán la empresa para cual se está recaudando. (Irá como
constante en la secuencia numérica). Esto con el fin que dentro del mismo servicio el sistema sepa por
cual entidad jurídica va a recaudar.
Los siguientes 2 caracteres (01) identificarán que es una referencia de pago (es fijo 05 Anticipo, 01
Factura). (Irá como constante en la secuencia numérica). Esto permitirá que el sistema sepa rápidamente
que lo que debe consultar es una factura.
Los siguientes 9 números son la numeración única de la referencia de pago.
Cada que se registre una factura de las mencionadas anteriormente el sistema deberá consumir un
número e imprimirlo en los formatos de factura:
Para identificar la secuencia de pago en los caracteres 4 y 5 se requiere crear un nuevo campo llamado
formato de pago en los parámetros del módulo de cuentas por cobrar, debe ser un campo texto de
longitud 2. Allí se parametrizará este valor que debe coincidir manualmente con la secuencia numérica
creada.
1. Módulo de Cuentas por Cobrar, Factura de Servicios y notas de interés
2. Módulo de Cuentas por cobrar, Ventas y marketing, órdenes de Venta Factura:

3. Módulo Proyectos  Factura de proyectos:

4. Módulo Alquiler (Rental)  Facturación Rental:

Nota: Tener en cuenta que algunos de estos formatos de facturas son personalizados por NAXT
3.2. Lógica del Sistema para el WS:
Se requiere un servicio web que conecte directamente la plataforma bancaría con D365 utilizando
como puente el filehub dispuesto para SK global.
Recaudos
Entidad Requiere Certificado SI/NO Tipo? Tipo de Conexiones
Banco de Bogotá Si/ VPN (Certificado o autofirmado) Web Service
Dentro de la carpeta Configurar en el módulo de cuentas por cobrar se debe crear una carpeta llamada
Servicios Web.
Dentro de esta carpeta se debe crear un formulario llamado Parámetros WS Banco Bogotá este
formulario deberá contener 3 campos donde se puedan relacionar diarios contables de, uno bajo la
etiqueta Diario de cobros, el segundo Diario de Anticipos, el tercero Diario de reversión, estos campos
deben ser tipo lista desplegable y deben filtrar solo los nombres de diarios contables (formulario
nombres de diarios) que son tipo diario de cobros. El tercer campo llamado Diario de reversión debe
filtrar al formulario nombres de diarios, solo mostrar los que son tipo diariamente.
3.3. Servicio Web para Banco de Bogotá
Para la conexión con el Banco de Bogotá se definen los siguientes métodos de Servicio Web:
3.3.1. Método Referencia de Pago/Referencia de anticipo (Documento Bango Bogotá: Caso de uso No1.
Consulta de Factura por número de Factura):
Por medio de este método, el usuario del Banco podrá consultar una Referencia de Pago/ Referencia de
anticipo de manera manual. El método indicará si la factura existe para ese cliente y el valor pendiente
de pago para proceder a realizar la transacción.
Para este método el banco ha definido los siguientes campos de envío y recepción del mensaje en el
Web Service:
Consulta (Desde el Banco hacia Dynamics):
 Consulta manual
o IBillrefinfo1: Es el número de referencia de pago / referencia de anticipo
o BillerNum: Un valor que usa el banco que no es relevante para D365, sin embargo,
este código se debe devolver en la respuesta
No se requiere Ni cliente ni empresa o convenio porque toda la lógica ya viene dada por la referencia de
Pago o de Anticipo.
Lógica: El sistema debe identificar por los primeros 3 dígitos la empresa que debe consultar. Por los
siguientes 2 dígitos el sistema debe identificar si es referencia de Pago e ir a la tabla de facturas de D365
para consultar la factura y responder.
Si es un anticipo (Referencia 05 en las posiciones 4 y 5) deberá ir a consultar los anticipos en las distintas
fuentes y retornar que el documento existe y se le puede cargar el anticipo.
Respuesta (Desde Dynamics hacia el banco)

Status Code; Status Desc; Se describe la tabla con lo que estos valores deben llevar
Curamt es el monto de la factura/anticipo con 2 decimales (sin puntos ni caracteres

especiales). En caso que el documento es un anticipo debe devolver el monto 10000
Billrefinfo1 Es el número de referencia de pago.
BillerNum: Es el mismo que envió el Banco en la consulta.
3.3.2. Método Resumen de Facturas (Documento Baco: Caso de uso No. 2 Resumen de Facturas):
Por medio de este método, el usuario del banco podrá consultar el resumen de facturas (cinco Facturas
máximo por restricción del banco), utilizando como parámetro el número de identificación. El sistema
debe mostrar las últimas 5 facturas por fecha de vencimiento más próxima a la fecha de la consulta. Es
decir, si la fecha es hoy, se deben tomar las primeras 5 facturas con fecha de vencimiento más cercana
a hoy (hacia adelante, es decir, facturas que no han vencido, si ya se vencieron no debe mostrarlas).
El usuario podrá indicar si el pago debe aplicarse a alguna de las facturas retornadas. Las transacciones
el banco las hace una por na, es decir, no se enviará un solo servicio con las 5 facturas.
Si la identificación cuenta con obligaciones por pagar, la consulta será exitosa y el número de referencia
devuelto en la consulta será el mismo número de referencia
Para esta validación, se han definido los siguientes campos de envío y recepción del mensaje en el Web
Service:
Del Banco hacia Dynamics 365:

Se establecerá consulta solo por los 2 campos obligatorios, el primero será
El Tipo de documento donde solo se habilitará NIT (1) y cédula (0). No se requiere una tabla de
homologación, esto puede ir directamente en el código de la lógica del sistema.
El segundo campo es el tipo de documento, este depende del primero, en caso de NIT se deberá recibir
el NIT con dígito de verificación incluido, pero sin caracteres especiales. En caso de cédula se deberá
recibir solo el número de cédula (no tiene en cuenta dígito de verificación), tampoco debe llevar
caracteres especiales. Esto debe validar contra los campos de identificación de localización Colombia
ubicados en el maestro del cliente. Es importante tener en cuenta que por diseño de proceso de Gecolsa
puede haber más de un cliente creado que tenga el mismo NIT, en ese caso el sistema se debe recorrer
todos los que tengan el mismo número de identificación y devolver las facturas (Solo las facturas, aquí
anticipos no se requiere).
Respuesta (Desde Dynamics hacia el banco)
Status Code; Status Desc; Se describe la tabla con lo que estos valores deben llevar
Solo en caso del código 000 Factura por pagar, el sistema incluirá los datos de factura.
Curamt es el monto de la factura/anticipo con 2 decimales (sin puntos ni caracteres especiales), en

caso no exitoso rellenas ceros
Duedt es la fecha de vencimiento de la factura/ anticipo, si el documento de anticipo no tiene fecha de
vencimiento, se debe enviar la fecha del día en la que se está consultando. En caso no exitoso rellenar
fecha del dìa
Billrefinfo1 Es el número de referencia de pago, en caso no exitoso rellenar con ceros
3.3.3. Método Recaudo (Documento del Banco: 8.4 Caso de uso No. 4 Notificación de pago de factura):
Por medio de este método, el usuario del banco podrá recaudar y aplicar el pago de la factura, el cliente
presenta la factura y el usuario digitará manualmente la referencia de pago / anticipo
Para este proceso, se han definido los siguientes campos de envío y recepción del mensaje en el
webservice:
Del Banco hacia Dynamics 364

Clientdt Provista por el banco para saber el date time de Dynamics 365
Rquid Provisto por el Banco como una referencia de pago (Se debe guardar en un capo del diario, para
reversiones)
AuthCode: Código autorización datafono
Networkowner Provisto por el Banco, siempre será OFC
BillerNum: Código NURA, lo envía el banco, no es relevante, hay que guardarlo para la respuesta.
Amt Total de la factura o anticipo que se va a registrar, con 2 decimales
ImmediatePMT Depende de la hora que pagó, no es relevante.
Prcdt Provista por el banco, irá a la fecha de la línea del diario de cobros
Refid1 Número de Referencia de pago o referencia de anticipo
Con esta actualización el sistema deberá crear líneas en un diario de cobros (basado en los parámetros
expresados anteriormente en este documento) ya sea por pago de una factura o por anticipo.
Si es una factura:
A. El sistema deberá crear un diario de cobros (referenciado en los parámetros)

B. Crear una línea de diarios, seleccionar el cliente (En la partida)
C. Traer la Factura para liquidación
D. La contra partida se llenará automáticamente porque viene fija en el diario de cobros
E. Registrar el diario y liquidar la Factura con el recaudo.
F. Las dimensiones financieras de la partida y contrapartida serán las de la factura.
El sistema debe respetar todas las configuraciones del cliente, incluso el perfil de contabilización.
Si es un anticipo:
El diario se debe marcar automáticamente como un Anticipo y llamar el perfil por defecto.
A. El sistema deberá crear un diario de cobros (referenciado en los parámetros)

B. Crear una línea de diarios, seleccionar el cliente (En la partida).
C. Si la Referencia de Anticipo pertenece a una Orden de Venta el sistema debe colocar
automáticamente en el campo Referencia de Pago (el campo estándar) el número de Orden
de venta, esto con el objetivo que el sistema lo cruce utilizando la manera estándar.
D. Si la referencia de Anticipo pertenece a una llamada de servicio el sistema deberá crear la

línea de anticipo al cliente, activando el perfil de contabilización y adicionalmente deberá
crear un registro en el formulario XAP_CashPaymentTotals en por ese valor para notificar
a los operarios de servicio que tienen un anticipo en su llamada.
Este formulario se encuentra en Servicios / todas las llamadas de servicios / elegir llamada
/ barra de acciones / caja registradora / total de pago.
Este formulario se compone de 2 campos, Moneda (siempre será COP) y el monto, el cual
se cargará del pago que realizó el cliente.
E. Si la referencia de Anticipo pertenece a un Contrato de Alquiler, el sistema deberá hacer un

diario de cobros, activar el perfil de anticipo, cargar la cuenta del cliente y adicionalmente
crear un registro en el formulario XAP_CashPaymentTotals en por ese valor para notificar
a los operarios de servicio que tienen un anticipo en su llamada.
Este formulario se encuentra en Alquiler / Contratos / Todos los contratos / elegir el

contrato / barra de acciones / caja registradora / total de pago.
Este formulario se compone de 2 campos, Moneda (siempre será COP) y el monto, el cual
se cargará del pago que realizó el cliente.
En todos los casos, sea referencia de pago o referencia de anticipo, el diario de cobros debe
quedar registrado para que el sistema pueda emitir la respuesta al banco.
Respuesta: De Dynamics hacia el Banco
Statudcode: StatusDesc Los valores de estos campos son descritos en la tabla
3.3.4. Reverso de pago de factura (Documento Banco: Caso de uso No 5 Reverso del pago de Factura):
Por medio de este método, el usuario del banco podrá reversar el pago de la factura cuando el cajero
del Banco comete un error en la transacción.
Para este proceso, se han definido los siguientes campos de envío y recepción del mensaje en el
webservice:
SRF Consultores S.A.S.
DOC-DES-001 2015-02-02 Version 001
Se recibirán desde el banco hacia Dynamics, los siguientes campos:
Página 23 de 33
DOC-DES-001 2015-02-02 Version 001
Clientdt: Es el campo date time de la transacción

NetworkOwner: Siempre OFC
Rquid: Número generado por el banco
AuthCode: Número de autorización datafono, no se requiere.
NetworkOwner: Siempre OFC
BillerNum: Código NURA, no se requiere para la respuesta.
Refid1: Número de la referencia de pago
Amt: Monto de la factura
ImmediatePmt: Jornada en la que se hizo, depende de la hora, no se requiere.
Página 24 de 33
DOC-DES-001 2015-02-02 Version 001
El sistema debe crear un diario contable reversando la transacción que pagó la factura, el diario
que debe utilizar es el diario contable que se estableció en los parámetros del servicio web. Una
vez esta transacción es construida y realizada el sistema enviará la siguiente respuesta:
ServerStatusCode; StatusDesc; son descritos en la siguiente tabla.
CSPRefid: Enviar los últimos 6 números del diario contable creado
4. MANEJO DE ERRORES
El manejo de errores va incluido dentro de las respuestas de consumo de los servicios Web desde
Dynamics hacia el banco, actualmente no hay una respuesta del banco para saber si se consumió el
WS que envía Dynamics.
Cuando el servicio web no funcione se entregará un archivo Asobancaria Técnico 2011filtrado para
importar a Dynamics, esta funcionalidad se cubre con SK.
En caso de que el web Service no funcione se dispondrá de un plan B de migración de archivos

mediante SK.
Página 25 de 33
DOC-DES-001 2015-02-02 Version 001
5. ROLES DE SEGURIDAD
Se requiere establecer un usuario de Dynamics el cual registre las transacciones que vienen por el
servicio web, este usuario deberá validarse con el banco por temas de seguridad. Este usuario
deberá tener un rol de tesorería más una configuración especial en el servidor que le permitirá la
ejecución de servicios web en el banco.
6. CASOS DE PRUEBA
Test Plan 1 – Generación de una Referencia de Anticipo en OV
Cliente: Concretos Argos
Paso 1
Se crea una OV al cliente Concretos Argos, se agregan diferentes artículos (no se requiere un
artículo en puntual a la prueba), Como resultado del paso la OV tiene un estado de Confirmación
No confirmado
Paso 2
Se confirma la Órden de Venta No OV-00000055 (O el número que se haya creado en el paso

anterior) y como resultado de la confirmación el sistema debe crear automáticamente el número
de Referencia de Anticipo 01005000000001.
Paso3
Entrar a la Orden de Venta y consultar en el encabezado el número de anticipo.
Test Plan 2 – Generación de una Referencia de Anticipo en Llamada de Servicio
Cliente: Bayer X000078
Paso 1
Se crea una Llamada de servicio (Proyecto)
Paso 2
Página 26 de 33
DOC-DES-001 2015-02-02 Version 001
Entrar a la llamada de servicio y visualizar el campo Referencia de anticipo, se debió haber creado
la referencia de anticipo 0100500000002, el campo no debe ser modificable
Test Plan 3 – Generación de una Referencia de Anticipo en Contrato de Rental
Cliente: CEMEX COLOLMBIA X254668
Paso 1
Se crea un contrato de alquiler
Paso 2
Entrar a al contrato de alquilar y visualizar el campo referencia de anticipo, se debió haber creado
el número 01005000000003, el campo no debe ser modificable
Test Plan 4 – Generación de una Referencia de Pago en Factura de OV
Cliente: Concretos Argos
Paso 1
Se crea una OV al cliente Concretos Argos, se agregan diferentes artículos (no se requiere un
artículo en puntual a la prueba)., como resultado del paso la OV tiene un estado de Confirmación
No confirmado
Paso 2
Se confirma la Órden de Venta No OV-00000055 (O el número que se haya creado en el paso

anterior) y como resultado de la confirmación el sistema debe crear automáticamente el número
de Referencia de Anticipo 01005000000001.
Página 27 de 33
DOC-DES-001 2015-02-02 Version 001
Test Plan 5 – Consumo de Servicios Web Bogotá
Prerrequisito:
Pago Banco de Bogotá:
Empresa 010
Cliente X000011 CONCRETOS ARGOS
Factura Monto Referencia de pago
AR00001 $ 2,355,331.20 01001000000002
AR00002 $ 1,000,001.75 01001000000003
AR00003 $ 333,333 01001000000004
AR00004 $ 555,999.81 01001000000005
Página 28 de 33
DOC-DES-001 2015-02-02 Version 001
Paso Descripción Resultado Esperado

1 El banco consulta la referencia de pago Se Lanza el web Service desde el banco, llega
01001000000002 a Dynamics y encuentra la factura No
AR00001 Y Envía la respuesta
000 AR00001 2,355,331.20 03032018
2 El banco Lanza el recaudo de la factura El Sistema debe crear un diario de recaudo

enviando los datos requeridos registrando y liquidando la factura AR00001
con los valores mencionados en el
puntoanterior. La factura debe quedar
liquidada con el pago.
El sistema lanza el web services con la

respuesta 00000 indicando exitoso
000 AR00002 1,000,001.75 03032018

con los valores mencionados en el punto
anterior. La factura debe quedar liquidada con
el pago.

000 AR00003 333,333 03032018

el pago.

Página 29 de 33
DOC-DES-001 2015-02-02 Version 001
01001000000008 a Dynamics y no encuentra factura
001 No existe factura
Test Plan 6 Consumo de Servicios Web Bogotá
Pago Banco de Bogotá:
Empresa 010
Cliente X000115 CEMENTOS ARGOS
Factura Monto Referencia de pago
CA00001 $ 1,000,000.00 01001000000025
CA00002 $ 2,000,000.00 01001000000026
CA00003 $ 4,000,000.00 01001000000027
CA00004 $ 5,000,000.00 01001000000028

000 AR00001 2,355,331.20 03032018

el pago.

Página 30 de 33
DOC-DES-001 2015-02-02 Version 001
Test Plan 7 – Consumo de Servicios Web Bogotá Anticipo Contrato
Prerrequisito:
Se crea Un contrato de alquiler al cliente X254668 CEMEX COLOMBIA SA.
No. Contrato: 010-000009
Referencia Anticipo: 01005000000455

1 El banco consulta la referencia de Se Lanza el web Service desde el banco, llega
anticipo 01005000000455 a Dynamics y encuentra el contrato.
000 01005000000455 10000

enviando los datos requeridos. registrando y un anticipo al cliente BAYER por
1.000.000
El cliente abonó 1.000.000
3 El sistema creó el diario 010-0000344 El sistema lanza el web service con la

Y envía respuesta respuesta 00000 indicando exitoso
4 Se ingresa al contrato y desde la Se visualiza un anticipo realizado por el cliente
pestaña total de pago se puede ver el de 1.000.000
anticipo del contrato
Test Plan 8 – Consumo de Servicios Web Bogotá Anticipo Llamada de Servicio
Prerrequisito:
Se crea una llamada de servicio al cliente ECOPETROL
No. llamada: 010-00000233
Referencia Anticipo: 01005000000900

anticipo 01005000000900 a Dynamics y encuentra la llamada
Página 31 de 33
DOC-DES-001 2015-02-02 Version 001
000 01005000000900 10000

enviando los datos requeridos. registrando y un anticipo al cliente
ECOPETROL por 3.500.000

4 Se ingresa a la llamada y desde la Se visualiza un anticipo realizado por el cliente
Test Plan 9 – Consumo de Servicios Web Bogotá Reversión Pago

anticipo 01005000000900 a Dynamics y encuentra la llamada
000 01005000000900 10000

enviando los datos requeridos. registrando y un anticipo al cliente
ECOPETROL por 3.500.000

4 Se ingresa a la llamada y desde la Se visualiza un anticipo realizado por el cliente
Página 32 de 33
DOC-DES-001 2015-02-02 Version 001
Test Plan 10 – Consumo de Servicios Web Bogotá Reversión Pago
El usuario del banco decidió realizar la reversión de una transacción.

1 El banco consulta la siguiente Se Lanza el web Service desde el banco, llega
referencia: a Dynamics para encontrar la transacción, la
transacción es encontrada.
800900100 (nit Ecopetrol)
20190401090044
OFC NetworkOwner
8303830382020 UUID
01005000000900 Referencia de pago
3500000 monto
0 jornada
2 Se aplica la reversión del pago. El Sistema debe crear un diario contable

reversando esta transacción basado en los
parámetros dados en el módulo y en la
información enviada en la reversión.
Página 33 de 33

FDD-17662-BSTRONG Web Service Bogota Validado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

FDD-17662-BSTRONG Web Service Bogota Validado

Cargado por

Copyright:

Formatos disponibles

DocuSign Envelope ID: 33F43D5D-75BF-4935-9F57-1EEFDE2DDB54

ESPECIFICACIÓN FUNCIONAL GAP-FIT

Web Service y Referencia de Pago

Gecolsa, Gestión de pagos y Recaudos

Información del documento

Nombre del documento: Documento Análisis de Requerimientos

Yamile Sierra Process Leader

1.1 Consideraciones Generales

Se requiere el desarrollo e implementación de varias funcionalidades para el recaudo de dinero haciendo

2.1. Lógica de Negocio (Dynamics 365)

2.1.1. Referencia de Anticipo

La construcción de esta secuencia se realizará de la siguiente manera:

Los siguientes 9 números son la numeración única de la referencia de anticipo.

2.1.2. Impresión de los formatos para el cliente

2.1.2.1. Reporte de confirmación de órdenes de Venta: (No confirmación Proforma)

Se requiere agregar la referencia en la parte superior derecha.

2.1.2.2. Informe de Proyectos

2.1.2.3. Informe de Contrato

3.1.1. Referencia de Pago:

4. Módulo Alquiler (Rental)  Facturación Rental: En el momento en que se facture el servicio

La construcción de esta secuencia se realizará de la siguiente manera:

Los siguientes 9 números son la numeración única de la referencia de pago.

1. Módulo de Cuentas por Cobrar, Factura de Servicios y notas de interés

2. Módulo de Cuentas por cobrar, Ventas y marketing, órdenes de Venta Factura:

3. Módulo Proyectos  Factura de proyectos:

4. Módulo Alquiler (Rental)  Facturación Rental:

3.2. Lógica del Sistema para el WS:

3.3. Servicio Web para Banco de Bogotá

Consulta (Desde el Banco hacia Dynamics):

Respuesta (Desde Dynamics hacia el banco)

Curamt es el monto de la factura/anticipo con 2 decimales (sin puntos ni caracteres

Billrefinfo1 Es el número de referencia de pago.

BillerNum: Es el mismo que envió el Banco en la consulta.

Del Banco hacia Dynamics 365:

Se establecerá consulta solo por los 2 campos obligatorios, el primero será

Respuesta (Desde Dynamics hacia el banco)

Curamt es el monto de la factura/anticipo con 2 decimales (sin puntos ni caracteres especiales), en

Del Banco hacia Dynamics 364

A. El sistema deberá crear un diario de cobros (referenciado en los parámetros)

A. El sistema deberá crear un diario de cobros (referenciado en los parámetros)

D. Si la referencia de Anticipo pertenece a una llamada de servicio el sistema deberá crear la

E. Si la referencia de Anticipo pertenece a un Contrato de Alquiler, el sistema deberá hacer un

Este formulario se encuentra en Alquiler / Contratos / Todos los contratos / elegir el

Respuesta: De Dynamics hacia el Banco

Statudcode: StatusDesc Los valores de estos campos son descritos en la tabla

SRF Consultores S.A.S.

ESPECIFICACIÓN FUNCIONAL GAP-FIT

DOC-DES-001 2015-02-02 Version 001

Se recibirán desde el banco hacia Dynamics, los siguientes campos:

SRF Consultores S.A.S.

ESPECIFICACIÓN FUNCIONAL GAP-FIT

DOC-DES-001 2015-02-02 Version 001

Clientdt: Es el campo date time de la transacción

SRF Consultores S.A.S.

ESPECIFICACIÓN FUNCIONAL GAP-FIT

DOC-DES-001 2015-02-02 Version 001

ServerStatusCode; StatusDesc; son descritos en la siguiente tabla.

CSPRefid: Enviar los últimos 6 números del diario contable creado

En caso de que el web Service no funcione se dispondrá de un plan B de migración de archivos

SRF Consultores S.A.S.

ESPECIFICACIÓN FUNCIONAL GAP-FIT

DOC-DES-001 2015-02-02 Version 001

Test Plan 1 – Generación de una Referencia de Anticipo en OV