You are on page 1of 16

Demanda

Recepción y tratamiento del
fichero de FDV
October de 2014



1
Contenido
1. Objetivo .................................................................................................................................... 2
2. Consideraciones sobre el fichero, su validación y aceptación .................................................. 2
3. Procesos .................................................................................................................................. 3
3.1 Recepción y Tratamiento de Archivos ............................................................................... 3
3.2 Proceso de Actualización de DNE ..................................................................................... 3
3.3 Proceso de Cierre de Edición ............................................................................................ 4
4. Descripción técnica .................................................................................................................. 4
4.1 Recepción de formulario Excel .......................................................................................... 4
4.2 Importación de datos desde formulario Excel .................................................................... 4
4.2.1 Caratula ..................................................................................................................... 4
4.2.2 Territorios ................................................................................................................... 5
4.2.3 Territorios_UTC ......................................................................................................... 6
4.2.4 UTC_CP .................................................................................................................... 7
4.3 Tratamiento de datos Importados desde formulario Excel ................................................. 8
4.3.1 FVTAS_CABECERA .................................................................................................. 8
4.3.2 FVTAS_NIVELES ...................................................................................................... 8
4.3.3 FVTAS_EDICION ...................................................................................................... 9
4.3.4 FVTAS_UTC ............................................................................................................ 10
4.3.5 FVTAS_CP .............................................................................................................. 11
4.4 Consumo de tablas ......................................................................................................... 12
4.4.1 Flat File TD con FV .................................................................................................. 12
4.4.2 Flat File CDD con FV ............................................................................................... 13
4.4.3 Catálogo de Fuerza de venta – TD_CAT_Forca_VendasYYYYMM ......................... 13
4.4.4 Catálogo de Producto – TD_CAT_ProdutosYYYMM ................................................ 14
4.4.5 Lista de Catálogos estándar a generar .................................................................... 14
4.5 Compendio de criterios de validación .............................................................................. 15
4.5.1 Integridad de la fuerza de ventas ............................................................................. 15
4.5.2 Fuerza de ventas Con “UTC asignada a un único territorio” o no ............................. 15
4.5.3 Fuerza de ventas “Jerarquica” o “UTC x Nivel FV” .................................................. 15
4.5.4 CP’s no asignados a ningún UTC ............................................................................ 15
4.5.5 UTC’s no asignados a ningún CDG_NIVEL6_UNICO .............................................. 15
4.5.6 Tratamiento de errores - Validación ......................................................................... 15
4.5.7 Generación del reporte de Validación (Error o Warning) .......................................... 16
4.5.8 Generación del reporte de Confirmación .................................................................. 16
4.6 Archivos de referencia adjuntos (Layout de FF TD y CDD) ............................................. 16




Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



2
1. Objetivo
Describir el circuito de recepción y validación de la Fuerza de Ventas a ser aplicada en la
generación de servicios.

2. Consideraciones sobre el fichero, su validación y aceptación
Se ha definido un modelo de Excel que contempla todas las características previstas de
configuración de una fuerza de ventas.
El cliente puede descargar este modelo para completar:
 Una carátula con parámetros del fichero y su procesamiento.
 Aquellas hojas que le permiten describir a su fuerza de ventas.

En la carátula se configuran aspectos como:
 La auditoría en la que será utilizado
 La vigencia
Según la frecuencia con la que el cliente quiera actualizar su fichero, podrá elegir entre
dos modalidades:
- Vigente para una única edición, y en la carátula indica la única edición en la que
será utilizado
- Recurrente y el fichero estará vigente desde su aceptación hasta que el cliente
informe un nuevo fichero
 Jerarquía
La cobertura de la fuerza de venta se puede informar de dos maneras:
- Jerárquica
La cobertura se define al nivel de los Sectores, y se infiere para los niveles
superiores de la jerarquía
- No jerárquica
Se informa la cobertura de los distintos niveles de la fuerza de ventas.

Cuando el cliente informa un nuevo archivo de fuerza de ventas, automáticamente se mueve
a una carpeta HISTORIAL la versión previa que pudiera existir (tanto del fichero como del
documento confirmación).
En la carpeta de upload se encuentran los ficheros y confirmaciones vigentes, o que entrarán
en vigencia en el futuro inmediato.

Inicialmente cuando el cliente informa un fichero se lo verifica y se le informa el resultado de
la validación: ésta es una validación temprana.
Posteriormente, si tiene lugar una actualización del DNE, se lo valida nuevamente e informa el
resultado al cliente.
A las validaciones del fichero predefinidas por CloseUp se sumará la posibilidad de que el
cliente cree sus propias reglas, permitiendo así que pueda obtener controles adicionales.
El informe que recibe el cliente tiene dos finalidades:
 Que pueda corregir errores que impiden el uso del fichero
Un fichero puede rechazarse tanto por errores, como por una cantidad tal de
advertencias que superan el umbral permitido.
 Que pueda estar prevenido de las advertencias generadas, pues pueden afectar al


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



3
entregable de un modo inapropiado.

Al momento de procesar un servicio cuya orden indica que requiere fichero, se exige contar
con:
 un fichero válido y vigente para la auditoría
 la correspondiente confirmación.
La confirmación es un documento que sube el cliente aceptando el uso de un fichero en
particular para la generación del entregable (la confirmación va a tener el código de reporte de
warnings en el que se basa)
Cuando un cliente adopta una vigencia recurrente del fichero, sólo se solicitará una primera
confirmación, y luego se la utilizará edición a edición sin solicitar nuevas confirmaciones
(mientras el fichero sea válido y en tanto no actualice el fichero).

3. Procesos
3.1 Recepción y Tratamiento de Archivos
Este proceso verifica que tipo de archivo se cargo, si se cargo le realiza las validaciones
correspondientes para autentificar dicho archivo. El usuario va a enterarse por medio de un
informe el resultado obtenido.



3.2 Proceso de Actualización de DNE
Cuando se modifica el DNE, se controlan los ficheros válidos existentes e informan sus
warnings para su posterior análisis


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



4
En este proceso se le eliminará la confirmación a un fichero válido y confirmado que tenga
vigencia exclusivamente para la edición (fichero no recurrente), ya que en este caso, al
nuevo informe de warnings le debe corresponder una nueva confirmación.

3.3 Proceso de Cierre de Edición
Cuando se disponibilizan las órdenes de servicio se verificará que exista un fichero válido y
confirmado para aquellas ordenes que requieran fichero, solicitándole al cliente los
archivos faltantes.



4. Descripción técnica
4.1 Recepción de formulario Excel
Los clientes o el área de Client Service de la filial depositaran el formulario Excel en el
inbox designado para cada cliente.
El sistema deberá tratar individualmente cada formulario

4.2 Importación de datos desde formulario Excel
Los datos del formulario deben ser importados a la base de datos Oracle en un área
equivalente funcionalmente a la de Órdenes de Servicio, para ser tratada y validada previo
a la transferencia al stage de producción.
El formato de importación propuesto (sujeto a revisión por el área de desarrollo) consiste
en una tabla para cada hoja del workbook.
Se adjuntan los scripts de creación de las tablas temporales utilizadas durante la fase
prototipo:

4.2.1 Caratula
La caratula resume la información necesaria para interpretar las siguiente tres siguientes


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



5
hojas del workbook.
En resumen:
 Nombre y código del fabricante
 Si la FV será de uso recurrente o no. Ver sección 2 de este documento
 Determinar si aplica la validación que fuerza que un UTC sea asignado a un único
(y solo uno) territorio para cada Unidad (unidade) de Negocio.
 Determinar si es posible aplicar criterio de verificación de UTC asignada al nivel
más bajo (Jerárquica) de FV o cada uno de los niveles de la FV.
 Establece los nombres a ser utilizados para cada uno de los niveles a que se
define la FV. Las columnas conteniendo nulos indican que el nivel no está en uso.

Estructura:

CREATE TABLE "xxxxx"." CARATULA"
( "COLUMNA1" VARCHAR2(51 BYTE),
"COLUMNA2" VARCHAR2(20 BYTE),
"COLUMNA3" VARCHAR2(20 BYTE),
"COLUMNA4" VARCHAR2(20 BYTE),
"COLUMNA5" VARCHAR2(20 BYTE),
"COLUMNA6" VARCHAR2(20 BYTE),
"COLUMNA7" VARCHAR2(20 BYTE)
)

Ejemplo de vuelco:




4.2.2 Territorios
La hoja de territorios define el nombre de la unidad de FV y las identificaciones y nombres
de los miembros de la FV, asociando cada uno de los miembros del nivel más bajo con sus
superiores jerárquicos, hasta alcanzar el nivel de Unidade.
La hoja maneja un numero finito de niveles para facilitar la definición por parte de los
clientes, pero se recomienda que, posterior a la importación, la definición se almacene en
una tabla jerárquica que permita un numero variable de niveles.
Las columnas con contenido nulo indican que el nivel NO está en uso. Como los niveles se
definen por pares de columnas, NO es admisible que el CDG sea nulo y DESC no lo sea.
Las únicas columnas que son obligatoriamente no nulas son:
CDG_UNIDADE, DESC_UNIDADE, CDG_NIVEL6, DESC_NIVEL6
Las columnas no nulas deben tener contenido TEXTO. Las columnas CDG de cada nivel
deben contener una cantidad de caracteres idéntica dentro de cada nivel.
COLUMNA1 COLUMNA2 COLUMNA3 COLUMNA4 COLUMNA5 COLUMNA6 COLUMNA7
Nome do Fabricante BESINS <= Seleccion
Codigo do Fabricante 12229 <=Nao Modificar
FV uso recurrente Si <= Seleccion
Validar UTC asignada a un unico Nivel (SI/NO) Nao <= Seleccion
Tipo Fuerza de Ventas (Jerarquica o UTC x Nivel FV) Jerarquica <= Seleccion
Nombres de Nivel Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5 Nivel 6
REGIÃO DISTRITO TERRITORIO


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



6
Por ejemplo, CDG_NIVEL1 no puede contener valores como “1”, “21”, “30”. La forma
aceptable seria “01”, “21”, “30”.
El largo de la descripción de cada miembro está limitado por el tamaño de la columna. Si
una descripción se trunca, debe generarse un reporte de warning no crítico para el cliente.

Estructura:

CREATE TABLE "xxxx"." TERRITORIOS"
( "CDG_UNIDADE" VARCHAR2(2 BYTE),
"DESC_UNIDADE" VARCHAR2(10 BYTE),
"CDG_NIVEL1" VARCHAR2(10 BYTE),
"DESC_NIVEL1" VARCHAR2(60 BYTE),
"CDG_NIVEL2" VARCHAR2(10 BYTE),
"DESC_NIVEL2" VARCHAR2(60 BYTE),
"CDG_NIVEL3" VARCHAR2(10 BYTE),
"DESC_NIVEL3" VARCHAR2(60 BYTE),
"CDG_NIVEL4" VARCHAR2(10 BYTE),
"DESC_NIVEL4" VARCHAR2(60 BYTE),
"CDG_NIVEL5" VARCHAR2(10 BYTE),
"DESC_NIVEL5" VARCHAR2(60 BYTE),
"CDG_NIVEL6" VARCHAR2(10 BYTE),
"DESC_NIVEL6" VARCHAR2(60 BYTE)
)

Ejemplo del vuelco



4.2.3 Territorios_UTC
Esta tabla define el tipo de UTC que utiliza la FV y la asignación de cada UTC a uno o más
elementos de NIVEL6.
Todos los elementos de NIVEL6 deben tener asignado no menos de una UTC, y solo
elementos de NIVEL6 pueden ser insertados en la tabla.

En el caso que “Validar UTC asignada a un único Nivel (SI/NO)” contenga “No”, todos los
elementos de cada NIVELn deben tener asignado no menos de una UTC.

La asignación de una UTC a más de un elemento de NIVEL6 solo es válida en caso que
“Validar UTC asignada a un único Nivel (SI/NO)” contenga “Si”.

En el caso que el CDG_TIPO_UTC mayor a “0”, se interpreta que el CDG_TIPO_UTC se
corresponde con alguna de las definiciones de UTC pre-establecidas por Close Up.
CDG_UNIDADE DESC_UNIDADE CDG_NIVEL1 DESC_NIVEL1 CDG_NIVEL2 DESC_NIVEL2 CDG_NIVEL3 DESC_NIVEL3 CDG_NIVEL4 DESC_NIVEL4 CDG_NIVEL5 DESC_NIVEL5 CDG_NIVEL6 DESC_NIVEL6
1 Lun 1 1 101 101 10101 10101
1 Lun 1 1 101 101 10102 10102
1 Lun 1 1 101 101 10103 10103
1 Lun 1 1 101 101 10104 10104
1 Lun 1 1 101 101 10105 10105
1 Lun 1 1 101 101 10106 10106
1 Lun 1 1 101 101 10107 10107
1 Lun 1 1 101 101 10108 10108
1 Lun 1 1 101 101 10109 10109
1 Lun 1 1 101 101 10199 10199
1 Lun 1 1 102 102 10201 10201


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



7
Al momento existe solo una de estas definiciones, pero potencialmente se pueden incluir
tipos de UTC con mayor o menor granularidad geográfica.

En el caso que el CDG_TIPO_UTC sea “0”, se interpreta que la definición de las UTC es
provista por el cliente mediante la asignación de CPs a cada una de las UTC definidas y
requiere que la hoja UTC_CP contenga una definición valida (criterio definido en párrafo
4.2.4 UTC _CP)

Estructura

CREATE TABLE "xxxx"." TERRITORIO_UTC"
( "CDG_TIPO_UTC" VARCHAR2(1 BYTE),
"CDG_UTC" VARCHAR2(10 BYTE),
"CDG_NIVEL6" VARCHAR2(10 BYTE)
)

Ejemplo del vuelco



4.2.4 UTC_CP
Esta tabla define la asignación de CPs a cada UTC.
Todos los CPs deben ser asignados a un UTC. Un CP no puede estar asignado a más de
un UTC. Cada uno de los UTC deben tener no menos de n CPs asignado, donde n >0 y
donde n debe ser un parámetro configurable en la base de datos. El valor a signar por
defecto es 3, aunque debería estar basado en que cada UTC contenga no menos de 3
puntos de venta activos pertenecientes al canal Farmacias.

Dado que el volumen de CPs es muy grande se recomienda restar particular atención a la
modalidad de lectura desde la hoja Excel. Durante la etapa de prototipo, se exporto a CSV
previo a la carga en base de datos.

Estructura

CREATE TABLE "xxxx"." UTC_CP"
( "CDG_UTC" VARCHAR2(10 BYTE),
"CP" VARCHAR2(8 BYTE)
)


CDG_TIPO_UTC CDG_UTC CDG_NIVEL6
0 1300002 10101
0 1306008 10101
0 1300004 10101
0 1304001 10101
0 1304002 10101
0 1304003 10101
0 1304004 10101


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



8
Ejemplo del vuelco



4.3 Tratamiento de datos Importados desde formulario Excel
La información almacenada en las tablas de importación debe ser insertada en un conjunto
de cuatro tablas: FVTAS_EDICION, FVTAS_NIVELES, FVTAS_UTC, FVTAS_CP.
La inserción en cada tabla solo se realiza después de realizar los controles descriptos y
obtener como resultado un conjunto de datos valido o con una cantidad de warnings
inferior al límite que se establecer por parámetro en la base de datos.
La inserción es descripta en los párrafos siguientes.

4.3.1 FVTAS_CABECERA
Esta tabla cumple la función de identificar unívocamente una inserción de FV, permitiendo
asociarla con su correspondiente validación y confirmación.
Los datos para insertar esta información, a excepción del código de país, se toman de la
tabla CARATULA (párrafo 4.2.1). Si consideran necesario, discutamos las ventajas o des-
ventajas de asumir el país de la carpeta de donde se levanta el archivo o incorporar a la
planilla Excel este dato.
La combinación de campos CDG_PAIS, CDG_LABORATORIO, CDG_EDICION,
CDG_TIPO_EDICION, insertados en la misma, debe ser asociado a un ID generado
automáticamente. Este ID, a los fines prácticos, reemplaza a la combinación de campos
para evitar la redundancia en las tablas descriptas abajo.

Estructura

CREATE TABLE "xxxxx"."FVTAS_EDICION"
( "CDG_PAIS" VARCHAR2(2 BYTE),
"CDG_LABORATORIO" VARCHAR2(5 BYTE),
"CDG_EDICION" NUMBER(5,0),
"CDG_TIPO_EDICION" VARCHAR2(1 BYTE),
"FV_CTL_ID" NUMBER
)

Ejemplo del vuelco



4.3.2 FVTAS_NIVELES
Esta tabla almacena los nombre asignados a cada uno los niveles de FV definidos en la
tabla CARATULA (párrafo 4.2.1).
La estructura original de esta tabla esta des-normalizada. Consideramos apropiado llevarla
a una estructura normalizada por cuestiones de eficiencia de almacenamiento y flexibilidad
en la cantidad de niveles. Por razones de compatibilidad con los procesos implementados
CDG_PAIS CDG_LABORATORIO CDG_EDICION CDG_TIPO_EDICION FV_CTL_ID
04 00364 364 M 1
04 12229 364 M 2


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



9
en QV sería conveniente que exhiba la información en el formato de la tabla existente para
facilitar la transición.
Como se indica arriba, la cantidad de niveles es variable y depende de las columnas que
se hayan completado el la planilla Excel desde donde se importa. Esta planilla típicamente
contiene 6 niveles, pero potencialmente puede variar, anteponiéndose a CDG_NIVEL1
parejas de columnas CDG y DESC para nivel desde A hasta Z.

Estructura

CREATE TABLE "xxxxx"."FVTAS_NIVELES"
(
"FV_CTL_ID" NUMBER
"NOME_NIVEL1" VARCHAR2(15 BYTE),
"NOME_NIVEL2" VARCHAR2(15 BYTE),
"NOME_NIVEL3" VARCHAR2(15 BYTE),
"NOME_NIVEL4" VARCHAR2(15 BYTE),
"NOME_NIVEL5" VARCHAR2(15 BYTE),
"NOME_NIVEL6" VARCHAR2(15 BYTE),
"CDG_TIPO_UTC" VARCHAR2(1 BYTE),
"FV_CTL_ID" NUMBER
)

Ejemplo del vuelco



4.3.3 FVTAS_EDICION
Esta tabla almacena el código y el nombre asignado el miembro de FV de cada uno de los
niveles (6) a reportar. La información a insertar se encuentra en la tabla TERRITORIOS
(párrafo 4.2.2)
La estructura original de esta tabla esta des-normalizada. Consideramos apropiado llevarla
a una estructura normalizada por cuestiones de eficiencia de almacenamiento y flexibilidad
en la cantidad de niveles.
Por razones de compatibilidad con los procesos implementados en QV sería conveniente
que, además, exhiba la información en el formato de la tabla existente para facilitar la
transición.
Como se indica arriba, la cantidad de niveles es variable y depende de las columnas que
se hayan completado el la planilla Excel desde donde se importa. Esta planilla típicamente
contiene 6 niveles, pero potencialmente puede variar, anteponiéndose a CDG_NIVEL1
parejas de columnas CDG y DESC para nivel desde A hasta Z.

FV_CTL_ID NOME_NIVEL1 NOME_NIVEL2 NOME_NIVEL3 NOME_NIVEL4 NOME_NIVEL5 NOME_NIVEL6 CDG_TIPO_UTC
1 null null null REGIAO DISTRITO TERRITORIO 0
2 null null null REGIÃO DISTRITO TERRITORIO 0


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



10
Estructura

CREATE TABLE "xxxxx"."FVTAS_EDICION"
(
"FV_CTL_ID" NUMBER,
"CDG_TIPO_EDICION" VARCHAR2(1 BYTE),
"CDG_UNIDADE" VARCHAR2(2 BYTE),
"DESC_UNIDADE" VARCHAR2(10 BYTE),
"CDG_NIVEL1" VARCHAR2(10 BYTE),
"DESC_NIVEL1" VARCHAR2(60 BYTE),
"CDG_NIVEL2" VARCHAR2(10 BYTE),
"DESC_NIVEL2" VARCHAR2(60 BYTE),
"CDG_NIVEL3" VARCHAR2(10 BYTE),
"DESC_NIVEL3" VARCHAR2(60 BYTE),
"CDG_NIVEL4" VARCHAR2(10 BYTE),
"DESC_NIVEL4" VARCHAR2(60 BYTE),
"CDG_NIVEL5" VARCHAR2(10 BYTE),
"DESC_NIVEL5" VARCHAR2(60 BYTE),
"CDG_NIVEL6" VARCHAR2(10 BYTE),
"DESC_NIVEL6" VARCHAR2(60 BYTE),
"CDG_NIVEL6_UNICO" VARCHAR2(10 BYTE),
)

Ejemplo del vuelco



4.3.4 FVTAS_UTC
Esta tabla explicita la asignación de UTC a cada código único de nivel 6 (habitualmente
territorios de FV) y se alimenta desde la tabla TERRITIRIO_UTC (párrafo 4.2.3)

Estructura

CREATE TABLE "xxxxx"."FVTAS_UTC"
( "FV_CTL_ID" NUMBER,
"CDG_NIVEL6_UNICO" VARCHAR2(10 BYTE),
"CDG_UTC" VARCHAR2(10 BYTE),
)

Ejemplo del vuelco
FV_CTL_ID CDG_UNIDADE DESC_UNIDADE CDG_NIVEL1 DESC_NIVEL1 CDG_NIVEL2 DESC_NIVEL2 CDG_NIVEL3 DESC_NIVEL3 CDG_NIVEL4 DESC_NIVEL4 CDG_NIVEL5 DESC_NIVEL5 CDG_NIVEL6 DESC_NIVEL6 CDG_NIVEL6_UNICO
2 1 BESINS 23 NORTE 01 FERNANDA SCARAMUSSA 01 BELEM CAPITAL - Milena 230101
2 1 BESINS 24 NORDESTE - HR3 01 HR3 05 PETROLINA - Vago 240105
2 1 BESINS 14 SUL 01 CLEBER FLORENCIO 01 Maria Dalila da S. Benoni 140101
2 1 BESINS 23 NORTE 01 FERNANDA SCARAMUSSA 04 REGIÃO NOROESTE - Vago 230104
2 1 BESINS 12 RJI 01 SILVANA SANTOS 04 Jana Carla G. Rodrigues Romano 120104
2 1 BESINS 15 SPI 01 MARCIO COSTA 01 Luciano Albiero 150101
2 1 BESINS 14 SUL 01 CLEBER FLORENCIO 03 Fabiano Soares Machado 140103
1 1 Lun 1 1 101 101 10103 10103 10103
1 1 Lun 1 1 101 101 10107 10107 10107
1 1 Lun 1 1 102 102 10202 10202 10202
1 1 Lun 1 1 103 103 10303 10303 10303
1 1 Lun 1 1 103 103 10305 10305 10305
1 1 Lun 1 1 105 105 10501 10501 10501


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



11



4.3.5 FVTAS_CP
Esta tabla solo es requerida en el caso que el tipo de UTC especificado sea 0. Este valor
identifica UTC definidos por el cliente. Inicialmente, esta será una práctica común, aunque
esperamos que los clientes vayan migrando gradualmente hacia alguno de los tipos de
UTC definidos por Close Up y que serán alimentados dentro de nuestro modelo de datos
en una tabla similar a FVTAS_CP o en la misma FVTAS_CP con valores de FV_CTL_ID
prefijados.

Estructura

CREATE TABLE "xxxxx"."FVTAS_CP"
( "CDG_PAIS" VARCHAR2(2 BYTE),
"CDG_LABORATORIO" VARCHAR2(5 BYTE),
"CDG_EDICION" NUMBER(5,0),
"CDG_UTC" VARCHAR2(10 BYTE),
"CP" VARCHAR2(8 BYTE),
"FV_CTL_ID" NUMBER
)

Ejemplo del vuelco





FV_CTL_ID CDG_NIVEL6_UNICO CDG_UTC
1 10799 1136006
1 10799 1136007
1 10799 1136009
1 10799 1136010
1 10799 1136011
1 10799 1136012
1 10799 1136013
1 10799 1136014
1 10799 1136016
1 10799 1136017


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



12
4.4 Consumo de tablas
Las tablas arriba descriptas se consumen tanto para las aplicaciones QV que requieren FV
como por los procesos que incorporan información de Fuerza de ventas a los Flat Files de
TD y CDD.

4.4.1 Flat File TD con FV
El FF de TD se basa en la información de AGG_2, agregada por UTC (std o customizado)
en lugar de CP.
Se prevé el desarrollo de una variante de AGG_2 para el momento en que una proporción
importante de los clientes utilicen el UTC estándar de Close Up, de manera de mejorar la
productividad.
La auditoría TD conecta la Información del FF con la Fuerza de ventas a nivel del UTC
(UNDGEO como nombre de columna en FF).
Por razones de protección de la confidencialidad del dato, para Brasil, no se exhibe
ninguna información a nivel de detalle más granular (Ej.: CP).
Esta regla puede variar de país en país, dependiendo de la cantidad de PDV que se
encuentran en la unidad geográfica de mayor granularidad a la que se espera detallar la
información.

Una implementación, que seguramente puede ser optimizada mediante el reemplazo de
las clausulas “where in” por joins se adjunta como soporte al archivo de ejemplo que se
disponibilizará con este documento.

Ejemplo de vista de extracción del FF TD

CREATE VIEW FF_TD_000301_201407 AS SELECT
a.CDG_ANIO_MES COD_ANOMES,
a.CDG_EMPAQUE COD_APRECENTACAO,
a.CDG_TIPO_PTO_VTA COD_CANAL,
a.CDG_TIPO_TX COD_TIPO_TRANSACAO,
NVL(fv.CDG_UTC,'9999999') UNDGEO,
-- a.CDG_POSTAL,
SUM(a.cantidad) UND,
SUM(a.importe) R$
FROM VS04M.agg_2 a
INNER JOIN VS04M.empaques e
ON e.cdg_empaque = a.cdg_empaque
INNER JOIN VS04M.productos p
ON p.cdg_producto = e.cdg_producto
LEFT JOIN VSCONSULTA.FVTAS_CP FV
on fv.cp = a.cdg_postal

INNER JOIN (SELECT
CDG_EMPAQUE
FROM VS04M.MERCADOS_EMPAQUES
WHERE CDG_MERCADO IN
(
SELECT
CDG_MERCADO
FROM VS04M.ORDEN_SERVICIO_MERCADOS
WHERE CDG_ORDEN_SERVICIO IN


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



13
(
SELECT CDG_ORDEN_SERVICIO
FROM VS04M.ORDEN_SERVICIO
WHERE CDG_LABORATORIO =301 --IDENTIFICAR L ORDEN DE SERVICIO
)
)
) EMPAQUES ON a.cdg_empaque = EMPAQUES.CDG_EMPAQUE
WHERE 1=1
AND p.cdg_laboratorio = '00301'
AND fv.cdg_laboratorio = '00301'
AND FV.cdg_EDICION = 364
AND FV.cdg_PAIS = 04

GROUP BY a.CDG_ANIO_MES, a.CDG_EMPAQUE, a.CDG_TIPO_PTO_VTA, a.CDG_TIPO_TX,
NVL(fv.CDG_UTC,'9999999')
;

4.4.2 Flat File CDD con FV
Este FF NO reemplaza el entregable actual de CDD FF.
El FF de CDD se basa en los datos de AGG_7 y se vincula la FV con el Punto de Venta a
través de los CPs que definen cada UTC.
Las columnas de FF son exactamente las mismas que las de CDD FF, con el agregado de
una columna CDG_UTC (UNDGEO) que actúa como vínculo con FV.

4.4.3 Catálogo de Fuerza de venta – TD_CAT_Forca_VendasYYYYMM
El catalogo detalla código y descripción de la Unidad de negocio, y de cada uno de los
niveles que componen la FV.
También provee el vínculo entre los miembro de FV, al incluir el CDG_UTC
Un ejemplo de qry, que debe ser adaptado a la estructura Jerarquica de la tabla de niveles,
se detalla más abajo para mostrar la información a generar como FF, obviamente
ajustando los nombres de columna a los que figuran en la PPT adjunta

Ejemplo

SELECT
E.CDG_EDICION,
E.CDG_TIPO_EDICION,
E.CDG_UNIDADE UNIDADE,
E.DESC_UNIDADE,

E.CDG_NIVEL4 REGIAO,
E.DESC_NIVEL4 DESC_REGIAO,
E.CDG_NIVEL5 DISTRITO,
E.DESC_NIVEL5 DESC_DISTRITO,
E.CDG_NIVEL6 TERRITORIO,
E.DESC_NIVEL6 DESC_TERRITORIO,
E.CDG_NIVEL6_UNICO,
U.CDG_UTC UTC
FROM FVTAS_EDICION E
INNER JOIN FVTAS_UTC U ON e.cdg_nivel6_unico = u.cdg_nivel6_unico


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



14
WHERE e.cdg_laboratorio = 301 AND u.cdg_laboratorio = 301

4.4.4 Catálogo de Producto – TD_CAT_ProdutosYYYMM
El Catalogo contiene las características principales de los empaques incluidos
En los mercados definidos para la auditoria TD o CDD. La información de mercados es
extraída de las órdenes de servicio habilitadas. Los nombres de las columnas en el FF
deben ser consistentes entre auditorias y respeta la definición de columnas definida en la
PPT adjunta.

Ejemplo

SELECT m.desc_mercado, e.cdg_empaque, e.barras, SUBSTR(e.abreviatura, 1,
LENGTH(e.abreviatura)-3),
SUBSTR(e.abreviatura, 1, LENGTH(e.abreviatura)-3)|| e.descripcion,
c.descripcion, d.desc_droga_uni, l.descripcion, r.desc_corporacion,
p.cdg_clasetn1|| p.cdg_clasetn2|| p.cdg_clasetn3|| DECODE(p.cdg_clasetn4, 0, NULL,
p.cdg_clasetn4), p.generico, p.marca_otc
FROM VS04M.empaques e
INNER JOIN VS04M .productos p
ON e.cdg_producto = p.cdg_producto
INNER JOIN VS04M .concentraciones c
ON c.cdg_concentracion = p.cdg_concentracion
INNER JOIN VS04M .drogas_uni d
ON d.cdg_droga_uni = p.cdg_droga_uni
INNER JOIN VS04M .laboratorios l
ON p.cdg_laboratorio = l.cdg_laboratorio
INNER JOIN VS04M .corporaciones r
ON r.cdg_corporacion = l.cdg_corporacion
INNER JOIN VS04M.mercados_empaques me
ON me.cdg_empaque = e.cdg_empaque
INNER JOIN VS04M.mercados m
ON me.cdg_mercado = m.cdg_mercado
INNER JOIN VS04M.orden_servicio_mercados osm
ON osm.cdg_mercado = me.cdg_mercado
INNER JOIN VS04M.orden_servicio os
ON osm.cdg_orden_servicio = os.cdg_orden_servicio
INNER JOIN VS04M.orden_servicio_auditorias osa
ON osa.cdg_orden_servicio = osm.cdg_orden_servicio
WHERE 1=1
AND os.cdg_laboratorio = '00301' --edicion, etc
AND osa.cdg_auditoria= 2

4.4.5 Lista de Catálogos estándar a generar
TD_CAT_ProdutosYYYYMM
TD_CAT_ATCYYYYMM
TD_CAT_TIPO_TXYYYYMM
TD_CAT_Mercado_LinhaYYYYMM


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



15

4.5 Compendio de criterios de validación
4.5.1 Integridad de la fuerza de ventas
Todos los miembros de la fuerza de ventas, salvo los de NIVEL1 (o A en caso de exceder
los 6 niveles de FV) deben tener como padre un único miembro de la FV.
Todos los miembros de la fuerza de ventas, salvo los de NIVEL6 deben tener como hijo a,
al menos un miembro de la fuerza de ventas.
Si no se cumplen ambas condiciones, se reporta error.

4.5.2 Fuerza de ventas Con “UTC asignada a un único territorio” o no
En el caso que “Validar UTC asignada a un único Nivel (SI/NO)” contenga “No”, todos los
elementos de cada NIVELn deben tener asignado no menos de una UTC.
La asignación de una UTC a más de un elemento de NIVEL6 solo es válida en caso que
“Validar UTC asignada a un único Nivel (SI/NO)” contenga “Si”.
En caso el flag este en estado “SI”, cada UTC debe estar asignada a un único padre de
Nivel 6. Caso contrario, si un UTC es asignado a más de un padre, reporta error.

4.5.3 Fuerza de ventas “Jerarquica” o “UTC x Nivel FV”
Si la FV es Jerarquica, todos los distintos niveles de FV se calculan por agregación directa
de los niveles inferiores.
Si la FV es “UTC x Nivel FV”, todos los miembros de la FV deben tener asociados código
de UTC. Si algún miembro de la FV no tiene asignado UTC, se reporta error.

4.5.4 CP’s no asignados a ningún UTC
Todos los CPs del DNE que no están asignados a algún UTC deben ser asignados a un
UTC Genérico “99999999” y este UTC debe ser asignado a un CDG_NIVEL6_UNICO
(territorio) Genérico “99999999”. Reportar warning.

4.5.5 UTC’s no asignados a ningún CDG_NIVEL6_UNICO
Si algún UTC queda sin asignar, debe ser asignado a un CDG_NIVEL6_UNICO (territorio)
Genérico “99999999”. Reportar warning

4.5.6 Tratamiento de errores - Validación
El tratamiento de los errores varía dependiendo de la naturaleza “Recurrente” o NO de la
FV.

Cuando un cliente adopta una vigencia recurrente del fichero, sólo se solicitará una
primera confirmación, y luego se la utilizará edición a edición, sin solicitar nuevas
confirmaciones, siempre y cuando el fichero solo registre warnings y no errores, y
obviamente no actualice el fichero.

Para los casos en los que el cliente NO usa FV Recurrente, debe enviar / re-enviar la FV
para cada ciclo, indicando a que ciclo corresponde la FV.
La FV debe ser validada en forma estricta, esto significa que cualquier reporte de
validación que incluya warnings deberá ser confirmado mediante el envió de un archivo de


Demanda
Recepción y tratamiento del
fichero de FDV
October de 2014



16
confirmación que, para ser aceptado, debe ser generado por el cliente incluyendo el nro
random de control descripto en 4.5.7.

4.5.7 Generación del reporte de Validación (Error o Warning)
La validación es predecesor a la confirmación.
En este reporte se deben detallar todos los errores y warnings detectados en el proceso
descripto en 4.5.6.
En caso de que la FV sea válida, debe generar un número random de control, que no se
repita en forma predecible, que será incluido en el reporte de validación y se utilizara para
asegurar que cuando el cliente envía el archivo de confirmación, confirma con
conocimiento de los warnings reportados.

4.5.8 Generación del reporte de Confirmación
Ante la recepción de un archivo de confirmación, se debe verificar coincidencia del nro de
control incluido en el archivo con el nro de control asociado con el último reporte de
warning generado para el cliente-ciclo.
En caso de coincidencia se debe generar un reporte de confirmación, indicando la
aceptación del archivo de confirmación recibido, indicando que esto habilita el
procesamiento del servicio tan pronto como los datos estén disponibles.

4.6 Archivos de referencia adjuntos (Layout de FF TD y CDD)
Hacer click sobre los documentos embebidos para abrir.


CUP_RelacaoBases_
20140905.pptx
CUP_Layout_FlatFile
_20140905.xlsx