Versión del documento:

DETALLE DEL SERVICIO WEB 1.0

SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019

FECHA: 2020-03-02
NOMBRE DE LA FUNCIONALIDAD: Consulta Certificado Tradición
ID REQUERIMIENTO: SDTA-SNR-WS-BAC-051_Certificado Tradición
CASO DE USO APROBADO FASE I: N/A
Devolver los datos contenidos en los certificados con el fin de otorgar
la información suficiente sobre un predio, debe incluir la información
JUSTIFICACIÓN DEL REQUERIMIENTO: completa de las solicitudes vigentes en el sistema de registro de la
matrícula, esto quiere decir relacionar cualquier número de turno o
radicado que se encuentre en trámite.
CHEQUEO CON LA SNR: BACHUE

2. APLICACIONES AFECTADAS

Funcionalidad: (Marcar con una X las funcionalidades

Lista de requisitos no tecnológicos.
impactados con el requerimiento, en dado caso que no
se encuentran incluirlo (s)
1. Pruebas UAT.
2. Manuales de Usuario.
Registro Aprobación
Digitador masivo Entrega
X Consulta Correcciones
Reportes Cuenta Cupo
Notificaciones Recursos
Registro Parcial
Otros: Portal Gis

Plataforma y/o aplicación: (Marcar con una X los aplicativos y módulos impactados con el requerimiento, en dado caso
que no se encuentran incluirlo (s)
X BACHUE BANCOS CATASTRO
SGD GOBERNACION SEDE ELECTRONICA
ARGIS CA
GEOLOCALIZACION CERTICAMARA
Otros: Consumidores externos: Ventanilla Única de la Construcción, Nodo de tierras, Estudios Traditicios,
Exentos.

3. CONTROLES DE ACCESO
El control de acceso a nivel de servicios se realiza por un usuario de CA. Este usuario se autenticará como una cuenta de
servicio a través de política de seguridad establecida en el BUS, realizando autenticación con CA por WS-Security
<<Se debe listar el nombre del rol establecido para el módulo o funcionalidad, de acuerdo con la necesidad>>.
No. Funcionalidad Rol y/o Usuario.
1. Consumir servicio SPP_CI_CertificadoTradicion Pendiente por definir con SNR
4. DESCRIPCIÓN DEL REQUERIMIENTO
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019

5. Detalle

5.1 Nombre Servicio: SPP_EE_CertificadoTradicion

COMPONENTE Bus (OSB)

DOMINIO Servicios Expuesto a Entidades Externas
NOMBRE DE LA OPERACIÓN TIPO DE PROTOCOLO DE ESTILO DE
COMUNICACION COMUNICACIÓN COMUNICACION
consultarCT síncrona SOAP/HTTP/S Request/Reply

5.1.1 Nombre Operación consultarCT

5.1.1.1 Condiciones de la operación

 Realizar búsqueda de la información de un predio a partir de:

- Matrícula, es decir, Círculo y Número de Matrícula Inmobiliaria,

- Número Predial, es decir el Identificador Catastral, CHIP si es un predio de Bogotá, aplica también referencia
o cédula catastral asignada por el IGAC,
- Número Predial Anterior, en dado caso que se busque por una versión anterior de número predial,
- NUPRE,

 A nivel general, la consulta puede estar segmentada en varios grupos:

- Información básica: entre otros datos: matrícula inmobiliaria, código de la ORIP, NUPRE, estado del NUPRE,
dirección actual del predio, ubicación geográfica detallada con departamento, municipio, nombre del barrio
y/o vereda, fecha de apertura del folio, fecha de registro de folio, radicación, NIR, áreas del inmueble,
linderos, etc.,

- listado de propietarios vigentes al momento de la consulta,

- campo BLOP de complementaciones,

- listado de Salvedades,

- listado de direcciones anteriores,

- listado de matrículas matriz,

- listado de matrículas derivadas,

 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019

- listado de medidas cautelares,

- listado de trámites en curso,

- datos de auditoria y resumen de la consulta como código y descripción del mensaje de respuesta, fecha con
horas, minutos y segundos del momento de respuesta de la consulta con su consecutivo respectivo.

 Para el campo de salida “numeroConsulta”: el valor a retornar es un número consecutivo que se incrementa con
cada consumo de la operación “consultarCT”. Para esto, se esperaría una implementación en el OSB o alguna
característica nativa del producto que permita dar respuesta a esta condición. Para los casos de consumos de
Nodo Central, se devolvería también el número gestionado por el Bus de servicios OSB, pero se necesitaría
registro de tipoLogResultadoConsulta.consecutivoConsulta donde después se pueda consultar y relacionar con el
numeroConsulta gestionado por el OSB, así como los valores de codMensaje, descripcionMensaje y
fechaHoraConsulta.

 Para el campo de salida “fechaHoraConsulta” el valor es el timestamp de la respuesta al cliente Web Service que
consuma este servicio. Se deberá realizar con una implementación desde el OSB. Para esto, se esperaría una
implementación en el OSB o alguna característica nativa del producto que permita dar respuesta a esta condición.
Para los casos de consumos a Nodo Central, se devolvería también la variable de tiempo gestionada por OSB.

 Es necesario, llevar un registro por usuario de los consumos y controlarlos de alguna forma parametrizando la
cantidad máxima permitida por día, por usuario y por servicio; es decir, por cuenta de Web Service, de tal forma
que al momento de alcanzar la cantidad máxima de consumos parametrizada por día por usuario se devuelva
ERROR 480.

A continuación, se expone mediante diagrama de comunicaciones y explicación los consumos a legados necesarios:

1 Ingresa por este flujo para conocer si la información del predio a consultar ha
sido migrada o no, basado en la ORIP a la que pertenece el predio. El servicio a
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019

consumir es SUT_CB_ConsultaMigracion, la operación es

“consultaMigracionPredio” enviándole el tipoIdentificacionPredio y el
numIdentificacionPredio. Se tiene en cuenta el elemento boolean de
“informacionMigrada”, donde si viene con valor “true” indica que la
información del predio consultado ha sido migrada.
1.1, 1.2, 1.3, 1.4, Estos pasos ocurren, a partir del resultado de paso 1, siempre y cuando se
1.5, 1.6, 1.7 y 1.8 determine si la información de la ORIP del predio consultado ha sido migrada.
De esta forma, se deberán consumir del CORE los servicios con las operaciones
relacionadas en diagrama, con las salidas de estos servicios se arma la salida de
SBB_EE_CertificadoTradicion.
2 Esa línea indica que se debe consumir NOC-03, para los casos donde
“consultarMigracionPredio” ha devuelto “false” en su elemnto
“informacionMigrada”.

 A continuación, los WSDL y sus XSD de Legados del CORE:

En el anterior ZIP, tener en cuenta que pueden venir más servicios de los listados en el diagrama. Se relaciona solo
en este documento el ZIP completo de los WSDL y XSD del CORE para Coexistencia. Ya en cada documento de
Servicios Expuestos a Entidades Externas enmarcados en Coexistencia, en cada diagrama de comunicaciones
aparece el que se deba usar en cada uno.

 Po otra parte, para las consultas a Legado Nodo Central el WSDL y el XSD que le corresponde a este
servicio:

 Ahora, de acuerdo con la sociabilización realizada, adjunto un Proyecto NetBeans donde se implementó
la lógica para obtener una lista de propietarios recorriendo las anotaciones de Nodo Central.

 Luego, para mayor descripción de cada campo se tiene en el XSLX insertado seguido a este párrafo,
hoja “SBB_EE_CertificadoTradicion”. Esto también para tener el mapeo completo de los campos entre
SBB_EE_CertificadoTradicion y sus legados: servicios de Core Bachué y NOC03-
ServicioConsultaCertificadoTradicion.
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019

 Y por último el XSD con las entradas y salidas que corresponde a la especificación descritas también en
las secciones 5.1.1.3 y 5.1.1.4 de este documento.

5.1.1.2 Códigos de error

codError Descripción
200 “”
La cuenta de usuario (mencionar la cuenta de usuario que va por la cabecera y que
será la que hace autenticación con CA ) tiene (mencionar la cantidad máxima de
consumos permitida por usuario para este servicio ) consumos máximos permitidos
480 por día, por lo que hoy a alcanzado este número.
404 La consulta no obtuvo resultados
470 ORIP no válida
Debe venir valor en numDocumentoPersona cuando llega valor en
484 tipoDocumentoPersona.
Debe venir valor en numNIT cuando NO llega valor en los elementos
485 tipoDocumentoPersona y numDocumentoPersona.
Debe venir algún valor para realizar la búsqueda, bien sea por numNIT para
consultar predios de una persona jurídica o tipoDocumentoPersona y
486 numDocumentoPersona cuando se trate de persona Natural.
Debe venir uno de estos valores en tipoIdentificacionPredio: numeroPredial,
487 numeroPredialAnterior, NUPRE y matricula.
El predio consultado no está disponible para el convenio… [valor], pertenece a la
489 ORIP [nomCirculoRegistral] 
Debe venir valor en tipoDocumentoPersona cuando llega valor en
490 numDocumentoPersona.
491 Debe venir información en numIdentificacionPredio
Dado que se recibió “matricula” en campo “tipoIdentificacionPredio” el valor:
(escribir valor recibido) recibido en campo “numIdentificacionPredio” no corresponde
492 al valor de una matrícula válida.
493 Debe venir información en convenio
494 Código de convenio: (poner valor recibido) no válido.
495 Debe venir valor en “claseAnotacion”, se espera “normal” o “medidaCautelar”
El predio consultado no está disponible para el convenio… [valor], pertenece a la
499 ORIP [nomCirculoRegistral]
500 Error en la operación

5.1.1.3 Entrada

DATOS DE ENTRADA
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019

CAMPO (Nombre del Tamaño TIPO (tipo de OBLIGATORIO DESCRIPCIÓN

campo de entrada) (Longitu dato del (Requerido: SI, Realizar una breve descripción del
d el campo de No Requerido: campo.
campo) entrada). NO)
Corresponde al tipo de identificación
por el cual podemos buscar un predio.
El dominio de datos va con los
tipoIdentificacionPredio 5 string NO
siguientes valores: matricula,
numeroPredial,
numeroPredialAnterior, NUPRE
Al seleccionar un tipo de
Identificación predio, se espera
en este campo el número
correspondiente; para el caso
de “matricula”, el sistema toma
numIdentificacionPredio 50 string NO
los tres primeros caracteres
como Código del Circulo
Registral y los siguientes como
el Número de Matrícula
Inmobiliaria.
Código del convenio que tiene la
convenio 100 string SI SNR con Entidades Externas que
necesiten este servicio.

5.1.1.4 Salida

DATOS DE SALIDA
CAMPO Tamaño TIPO OBLIGATORIO DESCRIPCIÓN

(Nombre del (Tipo de dato

(Longitud (Requerido: SI, No Realizar una breve descripción
campo de del campo de
el campo) Requerido: NO) del campo.
entrada) entrada).

Inicializa Salida Consulta Certificado Tradición

Número de matrícula inmobiliaria
o número de folio con el que se
numMatriculaI identifica el predio. Valores
nmobiliaria 30 string NO posibles: 1529389
Código del círculo o código de ORIP
codCirculoRegi al que corresponde el predio.
stral 3 string NO Valores posibles: 50C
Nombre de la ORIP al que
nomCirculoReg corresponde el predio. Valores
istral 100 string NO posibles: BOGOTA ZONA CENTRO
Número Único Predial. Valores
NUPRE 64 string NO posibles: 01001360007
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019
 Versión del documento:
DETALLE DEL SERVICIO WEB 1.0
SBB_EE_CertificadoTradicion
Fecha de Vigencia:
23/08/2019