Modulo EDI

Módulo EDI
Electronic Data Interchange

(Nice Zero)
Contenido
1. Objetivo...............................................................................................................................5
2. Descripción..........................................................................................................................5
3. Requerimientos generales...................................................................................................6
3.1. Requerimientos para la persistencia de información.................................................6
3.2. Requerimientos específicos de UI...............................................................................6
4. Diagrama de contexto del módulo......................................................................................7
5. Arquitectura.........................................................................................................................8
6. Diagrama Entidad Relación.................................................................................................9
7. Descripción de entidades..................................................................................................10
8. Diagrama de casos de uso.................................................................................................55
9. Casos de uso......................................................................................................................56
9.1. Maestros........................................................................................................................56
9.1.1. Maestros básicos simples..........................................................................................56
9.1.2. Maestros básicos con descripción con cultura..........................................................56
9.1.3. Maestros básicos sin gestión CRUD...........................................................................56
9.1.4. Maestros complejos...................................................................................................57
9.2. Partners (Interlocutores)...............................................................................................57
9.2.1. Local Stations (Internos)............................................................................................57
9.2.1.1. Listar/Consultar.....................................................................................................58
9.2.1.2. Alta.........................................................................................................................58
9.2.1.3. Editar......................................................................................................................60
9.2.1.4. Eliminar..................................................................................................................60
9.2.1.5. Vincular un rol........................................................................................................61
9.2.1.6. Desvincular un rol..................................................................................................62
9.2.2. External Partners.......................................................................................................63
9.2.2.1. Listar/Consultar.....................................................................................................64
9.2.2.2. Alta.........................................................................................................................64
9.2.2.3. Editar......................................................................................................................65
9.2.2.4. Eliminar..................................................................................................................65
9.2.3. Relaciones entre Local Stations.................................................................................66
9.2.3.1. Ver listado..............................................................................................................66
9.2.3.2. Ver LSs lógicas vinculadas a una física...................................................................67
9.2.3.3. Alta de una LS lógica..............................................................................................68
9.2.3.4. Editar una LS lógica................................................................................................69
9.2.3.5. Vincular una LS lógica a una LS física.....................................................................70
9.2.3.6. Editar información de comunicaciones y contactos..............................................71
9.2.3.6.1. Métodos de comunicación. Vincular.....................................................................73
9.2.3.6.2. Métodos de comunicación. Desvincular................................................................74
9.2.3.6.3. Tipos de documento y plantillas. Alta...................................................................74
9.2.3.6.4. Tipos de documento y plantillas. Editar................................................................76
9.2.3.6.5. Tipos de documento y plantillas. Eliminar............................................................77
9.2.3.6.6. Contactos. Alta.......................................................................................................78
9.2.3.6.7. Contactos. Editar....................................................................................................79
9.2.3.6.8. Contactos. Eliminar................................................................................................80
9.2.3.6.9. Formas de contactar. Alta......................................................................................81
9.2.3.6.10. Formas de contactar. Editar...............................................................................82
9.2.3.6.11. Formas de contactar. Eliminar...........................................................................83
9.2.3.7. Desvincular una LS lógica de una LS física.............................................................83
9.2.3.8. Mover a otro interlocutor interno.........................................................................84
9.2.3.9. Búsqueda...............................................................................................................85
9.2.4. Relaciones entre Local Stations y External Partners.................................................87
9.2.4.1. Ver listado..............................................................................................................87
9.2.4.2. Seleccionar un LS física (interlocutor interno físico).............................................88
9.2.4.3. Ver partners lógicos vinculados a uno físico.........................................................89
9.2.4.4. Alta de un external partner lógico.........................................................................89
9.2.4.5. Editar un external partner LS lógico......................................................................90
9.2.4.6. Vincular un external partner físico con una LS física.............................................90
9.2.4.7. Vincular un external partner lógico en una relación LS – External Partner..........91
9.2.4.8. Editar información de comunicaciones y contactos..............................................92
9.2.4.9. Eliminar una relación comercial............................................................................92
9.2.4.10. Mover a otro external partner físico.....................................................................93
9.2.4.11. Búsqueda...............................................................................................................93
9.3. Mensajes........................................................................................................................95
9.3.1. De entrada.................................................................................................................95
9.3.1.1. Ingresar a la interfaz de mensajes.........................................................................95
9.3.1.2. Seleccionar un interlocutor para visualizar sus mensajes.....................................96
9.3.1.3. Editar......................................................................................................................98
9.3.1.4. Eliminar..................................................................................................................98
9.3.1.5. Ver detalles............................................................................................................99
9.3.1.6. Ver mensaje...........................................................................................................99
9.3.1.7. Ver fichero .edi del mensaje................................................................................100
9.3.1.7.1. Descargar fichero .edi del mensaje.....................................................................102
9.3.1.8. Ver fichero .edi de la transmisión........................................................................103
9.3.1.8.1. Descargar fichero .edi de la transmisión.............................................................103
9.3.1.9. Ver documento....................................................................................................104
9.3.1.10. Ver log de comunicaciones..................................................................................105
9.3.1.11. Ver en un nuevo Tab del navegador....................................................................105
9.3.2. De salida...................................................................................................................106
9.3.2.1. Ingresar a la interfaz de mensajes.......................................................................106
9.3.2.2. Seleccionar un interlocutor para visualizar sus mensajes...................................107
9.3.2.3. Editar....................................................................................................................108
9.3.2.4. Eliminar................................................................................................................108
9.3.2.5. Ver detalles..........................................................................................................109
9.3.2.6. Ver mensaje.........................................................................................................109
9.3.2.7. Ver contenido del mensaje..................................................................................110
9.3.2.7.1. Formatear contenido...........................................................................................111
9.3.2.7.2. Descargar contenido............................................................................................112
9.3.2.8. Ver contenido de la transmisión..........................................................................112
9.3.2.8.1. Formatear contenido...........................................................................................113
9.3.2.8.2. Descargar contenido............................................................................................113
9.3.2.9. Ver documento....................................................................................................114
9.3.2.10. Ver log de comunicaciones..................................................................................115
9.3.2.11. Ver en otra pestaña del navegador.....................................................................116
10. Puesta en escena del módulo......................................................................................117
1. Objetivo
Presentar los requerimientos del módulo EDI, así como el análisis y diseño junto con las especificaciones
técnicas y funcionales.
2. Descripción
EDI (Electronic Data Interchange) es un módulo que principalmente permite monitorizar las
transmisiones (intercambio) de información con otras empresas.
Para poder describir como fluyen las transmisiones se hace necesario identificar las partes que
intervienen en la transmisión, las cuales serán denominadas “Partners” (interlocutores).
En la aplicación se tienen partners internos que se denominan “Estaciones locales” y estás a su vez
pueden ser físicas o lógicas; las físicas son las únicas que pueden intervenir directamente en una
transmisión y las lógicas son, por así decirlo, ubicaciones que dependen de una física; por ejemplo, para
GBFoods se puede tener como centro de gestión la estación local física “GB” y para ésta tener varias
estaciones locales lógicas que identifican las diferentes fábricas de “GB”.
También se tienen partners externos, que no son más que otras empresas, pero estos partners pueden
ser físicos o lógicos; los físicos son los que identifican los centros de gestión como tal de una empresa y
los lógicos son una delegación, sucursal, etc, por ejemplo, un partner externo físico puede ser “El Corte
Inglés” y un partner externo lógico es “El Corte Inglés de Diagonal”.
Se hace necesario aclarar que las transmisiones se hacen entre una Estación local física y un partner
externo físico, aunque alguno de los ficheros (mensajes) tengan como procedencia o destino una
estación local lógica y/o un partner externo lógico.
En este proceso las transmisiones en realidad lo que pretenden es enviar ficheros de un sitio a otro y en
una transmisión se pueden presentar uno o N mensajes, tantos como ficheros enviados y cada mensaje
(o fichero) puede variar su origen y su destino respecto a los demás, por lo tanto y asumiendo algunos
ejemplos planteados antes, se puede tener una transmisión entre GB (estación local física) y el Corte
Inglés (partner externo físico”) y dentro de dicha transmisión tener dos mensajes, uno que tiene como
origen la fábrica en Barcelona de GB (estación local lógica) y como destino el Corte Inglés de plaza
Cataluña (partner externo lógico) y el segundo tiene como origen la fábrica en Murcia de GB (estación
local lógica) y como destino el Corte Inglés de diagonal (partner externo lógico).
Al final se requiere disponer de una UI que permita a los usuarios visualizar los mensajes que se poseen
registrados, de manera que se pueda acotar el listado según un rango de fechas y que se pueda hacer un
filtrado según algunas condicionantes dadas sobre algunos de los campos de los mensajes.
También es necesario que en la aplicación se pueda definir todo lo necesario para configurar las
transmisiones de los mensajes, lo cual implica tener todas las interfaces necesarias para gestionar los
proceso CRUD de las diferentes entidades maestras, así como de otras entidades que permitan registrar
la información de los partners así como la de las relaciones existentes entre ellos para las transmisiones,
que pueden ser de tres para formas: estación local física con estación local lógica, estación local física
con partner externo físico y estación local física con partner externo físico y partner externo lógico.
3. Requerimientos generales
 Tener un registro de las transmisiones que se realicen entre las “Estaciones locales” y los
“Partners externos”.
 Tener un registro de los partners que intervienen en las transmisiones, tanto “Estaciones
locales” como “Partners externos”.
 Poder establecer relaciones así:
o Entre las “Estaciones locales” físicas con sus “Estaciones locales” lógicas.
o Entre las “Estaciones locales” físicas con “Partners externos” físicos
o Para cada una de las relaciones entre “Estaciones locales” físicas con “Partners
externos” físicos relacionar los “Partners externos” lógicos.
Un “Partner externo” físico puede tener relaciones con varias “Estaciones locales” ya que el
partner externo puede intercambiar documentos con varias estaciones locales, concepto que
se extiende a las partner externos lógicos.
 Para cada relación que se establezca se requiere la siguiente información tanto para
“Estaciones locales” como “Partners externos”:
o Path en donde se guardan los ficheros recibidos y path de dónde se deben obtener
para un envío.
o Registrar los métodos de comunicación habilitados para las transmisiones.
o Registrar los tipos de documentos permitidos en las transmisiones y las plantillas que
se emplean para la visualización adecuada del documento enviado en los mensajes.
o Información de contactos, con sus roles y diferentes maneras de contactar
En cada relación es posible que intervengan tres partners (una estación local, un
partner y un segundo partner (padre) que sería el físico al que está vinculado el lógico
si es el caso); así la información registrada en este punto rige para las comunicaciones
con el partner.
 Poder hacer una gestión de:
o Tipos de documentos
o Plantillas de impresión
o Roles de contactos
o Formas de contactar
o Tipos de mensajes
o Estado de las comunicaciones
o Dirección de envío de las transmisiones
o Formato de los mensajes
Tener la posibilidad de gestionar las operaciones CRUD para los casos que lo
requieran.
 Incluir una UI en la cual se pueda monitorizar los mensajes y en la cual los usuarios puedan
generar consultas que tengan persistencia para dicho usuario.
 Incluir una UI en la cual se pueda monitorizar las transmisiones
3.1. Requerimientos para la persistencia de información

La información se aloja en una BD SqlServer en un servidor del cliente
3.2. Requerimientos específicos de UI

Interfaz web
4. Diagrama de contexto del módulo
5. Arquitectura
Servidor:
Desarrollo en: aspNet Core
Aplicación instalada en IIS
Cliente:
Desarrollo en: Angular
Navegador Web: Crome, FireFox, IExplorer

6. Diagrama Entidad Relación
EdiCommunicationTypeCultures
EdiCommunicationTypes Id
Id TenantId AbpLanguages
Id
TenantId UpdateDate
CreationTime
UpdateDate EdiCommunicationTypeId
CreatorUs erId
CtionTypeDes cription LanguageId
DeleterUserId
CultureDescription
DeletionTime
DisplayName
EdiPartnerCommConfigs
Icon
Id
IsDeleted
TenantId
LastM odificationTime
UpdateDate
EdiContactComTypes LastM odifierUserId
EdiPartnerRelationshipId
Id
Name
EdiCommunicationMethodId
EdiContactRoleCultures
TenantId
EdiPrintTemplates
Id
EdiDocumentType UpdateDate UpdateDate
Id CommTypeResource Culture
TenantId
TenantId EdiPartnerContactId CultureDescription
CreateDate
UpdateDate EdiContactRoleId
UpdateDate
DocTypeName LanguageId
TemplateName
TemplateScheme EdiDirection EdiCommunicationStatus

EdiPartnerContacts Id Id
Id TenantId TenantId
TenantId EdiContactRoles UpdateDate UpdateDate
ContactName Id
DirectionCode StatusCode EdiMessages
TenantId Id
ContactNotes DirectionDescription StatusDescription
CreationDate TenantId
CreationDate
UpdateDate Transmiss ionId

EdiDocumentExchangeInfos UpdateDate
RolDescription Status Id
Id EdiPartnerRelationshipId
StationPartnerId
TenantId
MsgTypeId
UpdateDate
EdiTransmissions
EdiPartnerRelationshipId Id
MsgFormatId EdiMessageType
Id
DocumentTypeId
EdiDocumentTypeId TenantId
CreateDate TenantId
EdiPrintTemplateId DirectionId
UpdateDate UpdateDate
CommunicationM ethodId
Source M sgType
StationPartnerId
Destination
Source
EdiMessageFormat
EdiPartnerRelationships Destination
Filepath
Id
Id Filename
Status Id
TenantId
TenantId SourceDocument
CreateDate
UpdateDate
PartnerId SourceDate
UpdateDate
M sgFormat
LocalStationId Reference1
Transmiss ionDate
ParentPartnerId
InterchangeControlRef
PrnRshipActive
Format
UpdateDate
PrnRshipInputFolder
EdiPartners
Id
EdiPartnerTypes TenantId
Id UpdateDate
TenantId
PrnIsLocalStation
UpdateDate EdiPartnerTypeId
PtypActive PrnCode
PtypCode PrnName
PtypeDescription PrnShortName
PtypCommunication PrnExternalCode
PrnAddress
PrnPos talCode EdiLocalStationRoles

Id
PrnCity
TenantId
PrnCountry
UpdateDate
EdiCommunicationMethod LocalStationId
Id RoleId
TenantId
UpdateDate
M ethodCode
M ethodDescription
7. Descripción de entidades
Entidad: EdiPartnerType
Tipificación de los partners. Se identifican inicialmente dos tipificaciones:
 Root: (partner Físico), hace referencia a la central de un partner sin referirse a ningún punto de
venta/suministro en específico (ejemplo Carrefour).
 Logical: (partner lógico), hace referencia a un punto de venta/suministro/delegación/fábrica
específica de un partner (ejemplo Carrefour–La maquinista ó Fábrica de Murcia de GB).
Es un maestro “cerrado”. El campo PtypDescription, es una key para presentar el texto en la cultura
correspondiente.
Datos de la entidad Valor

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.Masters
en la solución servidor en las diferentes capas y en la solución de
angular identifica la carpeta dentro de la cual se va a generar la
carpeta de los componentes necesarios para la gestión de la entidad)
Plural EdiPartnerTypes
Nombre tabla EdiPartnerTypes
Entidad base Entity
Primary key Int
Información de migración
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) No
Crear vista modal (Si/No) No
Crear botón para exportar a Excel (Si/No) No
Posición en el menú (además de indicar la ubicación en el menú del Root
panel izquierdo de la aplicación indica el “Module” al cual se van a
adicionar los componentes generados)
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría
Hacer seguimiento para el historial (si/No) No
Propiedades y navegaciones
Propiedad Tipo + longitud Descripción Filtro Listado Add/Up

Id* Int Pk
PtypActive* Bool Indica si la tipificación está activa o no.
PtypCode* Nvarchar[2] F: identifica la tipificación de un punto físico X
L: identifica la tipificación de un punto lógico
PtypDescription* Nvarchar[20] Es una key de cultura para presentar la Descripción X
según la cultura
PtypCommunication* Bool True: tiene comunicación X
False: no tiene comunicación.
PtypCategory* Nvarchar[10] [EDI |FTP] X
Indices:
 Unique indexs:
o UIDX_PnerType_CatCode => Campos: PtypCategory + PtypCode
 Indexs: ninguno:
Carga inicial
PtypActive PtypCode DescriptionKey PtypCommunication PtypCategory

True F PartnerRoot True EDI
True L PartnerLogical False FTP
Entidad: EdiPartner
Identifica cada una de las partes que pueden estar implicadas en las transmisiones y sus
correspondientes mensajes. Si hay duplicidad por varios dominios se repiten.
Existen partners internos, denominados “estaciones locales” y “partners externos” simplemente

identificados como partners.

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.Partners
Plural EdiPartners
Nombre tabla EdiPartners
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Crear vista modal (Si/No) Si
Crear botón para exportar a Excel (Si/No) Si
Posición en el menú (además de indicar la ubicación en el menú del Main
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría
Hacer seguimiento para el historial (si/No) Si
Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

Id* Int Pk
PrnIsLocalStation* Bool por defecto false Si es true indica que es una estación local de la
compañía. Si es false indica un partner con quien la
compañía se puede comunicar.
PartnerTypeId* Fk Identifica el tipo de partner.
Foreign key de la relación:
EdiPartner * .. 1 EdiParternType
PrnCode* Nvarchar[35] Código asignado al partner X X X

PrnName* Nvarchar[100] Nombre del partner X X
PrnShortName* Nvarchar[30] Nombre corto del partner X
UpdateDate* DateTime
PrnExternalCode Nvarchar[35] null Código externo3
PrnAddress Nvarchar[100] null Dirección del partner X
PrnPostalCode Nvarchar[25] null Código postal del partner X
PrnCity Nvarchar[200] null Ciudad del partner X
PrnCountry Nvarchar[3] null País del partner X
PrnVatNumber Nvarchar[35] null CIF del partner X
PrnNotes Nvarchar[500] null Notas X
CreateDate* DateTime Fecha/hora de creación
UpdateDate* DateTime Fecha/hora última actualización X
Indices:
 Unique indexs:
o UIDX_Partner_Code => Campos: PrnCode
 Indexs: ninguno
Restricciones, hay q verificar al agregr un partner físico o lógico que no exista una relación para la local station seleccionada.
Al dar de alta un partner desde la pantalla de Relaciones, se debe permitir establecer la relación, dos acciones por separado.
Entidad: EdiLocalStationRoles
Registra los roles (dentro de la aplicación), que pueden ver la información de una local station, por lo
que esta relación solo se puede establecer para registros de EdiPartners que cumplan con:
Partner.LocalStation == true && Partner.PartnerType.Category = “EDI” && Partner.PartnerType.Code == “F”.

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.Partners
Plural EdiPartners
Nombre tabla EdiPartners
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
LocalStationId* Fk Identifica la Local station de la relación.
EdiLocalStationRoles * .. 1 EdiPartern
Eliminación en cascada
RoleId Fk Identifica el rol de la relación.
EdiPartnerRoles * .. 1 Roles
Sin eliminación en cascada
Indices:
 Unique indexs:
o UIDX_LStationRole => Campos: LocalStationId + RoleId
 Indexs: ninguno
Entidad: EdiPartnerRelationship
Registrar la información de las relaciones existentes entre las estaciones locales y los partners, estos
últimos a dos niveles, es decir, se puede registrar la relación entre una local station y un partner físico
(para este caso no se especifica parent partner) o se puede registrar la relación de una local station con
un partner lógico indicando el parent partner (partner físico) al cual está asociado.

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.PartnerRelation
Plural EdiPartnerRelationships
Nombre tabla EdiPartnerRelationships
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
PartnerId* Fk Identifica el partner externo X
EdiPartner 1 .. * EdiPartnerRelationship
SIN Eliminación en cascada
LocalStationId Fk Identifica la local station X
EdiPartner 1 .. * EdiPartnerRelationship
ParentPartnerId Fk null Identifica el padre de PartnerId. Debe ser un X
EdiPartner con ParentType.Code == “F”.
EdiPartner 0/1 .. * EdiPartnerRelationship
PrnRshipActive Bool por defecto true Indica si la relación está activa o no. X X
True:
False:
PrnRshipInputFolder Nvarchar[500] Carpeta de entrada del proceso de integración. X
PrnRshipOutputFolder Nvarchar[500] Carpeta de salida del proceso de integración. X
Indices:
 Unique indexs:
o UIDX_PrnRship_PartnerStation => Campos: LocalStationId + PartnerId + ParentPartnerId
 Indexs:
o IDX_PrnRship_LocalStation = > Campos: LocalStationId
Nota 1:
En una relación entre Estaciones locales (registro de una local station física) se asigna lo siguiente:
LocalStationId => es la local station física
PartnerId => es la local station física
ParentPartnerId=> null
En una relación entre Estaciones locales (Física y Lógica) se asigna lo siguiente:
PartnerId => es la local station lógica
ParentPartnerId=> es la local station física
En una relación entre una Estación local y un partner físico se asigna lo siguiente:
PartnerId => es el partner físico
ParentPartnerId=> null
En una relación entre una Estación local y un partner lógico vinculado a uno físico se asigna lo siguiente:
PartnerId => es el partner lógico
ParentPartnerId=> es el partner físico
Nota 2: cuidado al hacer el update-database, posiblemente solicite modificar la acción en el OnDelete

ya que asume que puede presentarse un error
Entidad: EdiDocumentExchangeInfo (ojo estaba PartnerMessages)
Identifica los tipos de documentos que pueden intercambiarse entre dos Partners (Local station y
partner externo) que han establecido su relación en EdiPartnerRelationship.

Plural EdiDocumentExchangeInfo
Nombre tabla EdiDocumentExchangeInfo
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
PartnerRelationshipId* Fk Identifca la relación entre partners a la cual
pertenece la información.
EdiDocumentsExchangeInfo * .. 1 EdiPartnerRelationship
DocumentTypeId* Fk Identifica un tipo de documento admitido en el X X
intercambio de información.
EdiDocumentsExchangeInfo * .. 1 EdiDocumentType
UpdaetDate* DateTime
PrintTemplateId Fk Identifica un tipo de documento admitido en el X X
intercambio de información.
EdiDocumentsExchangeInfo * .. 1 EdiDocumentType
CommunicationMethodId* Fk Identifica el método de comunicación empleado X X
en la transmisión del tipo de documento
especificado.
EdiDocumentsExchangeInfo * .. 1 EdiCommunicationMethd
Indices:
 Unique indexs: UIDX_DocEx_RelationDocType

o Campos: PartnerRelationshipId + DocumentTypeId.
 Indexs: ninguno
Entidad: EdiDocumentType
Maestro que registra los tipos de documentos que se pueden intercambiar entre partners.
Es un maestro abierto, sin gestión de cultura.

Plural EdiDocumentTypes
Nombre tabla EdiDocumentTypes
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
DocTypName Nvarchar[50] Nombre del tipo de documento. ´X X
Indices:
 Unique indexs:
o UIDX_ DocumentTypes_Name => Campos: DocTypName
 Indexs: ninguno
Entidad: EdiPrintTemplate
Registra las diferentes plantillas que se pueden emplear para un tipo de documento.
Falta definir el campo TemplateScheme

Plural EdiPrintTemplates
Nombre tabla EdiPrintTemplates
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
CreateDate*
UpdateDate*
DocumentTypeId Fk Identifica el tipo de documento para el que se ha
diseñado la plantilla
EdiPrintTempalte * .. 1 EdiDocumentType
TemplateName* Nvarchar[50] Nombre de la plantilla
TemplateScheme Nvarchar[1000] Contenido del esquema de impresión. Url a recurso
o contenido como tal de la plantilla?
Indices:
 Unique indexs:
o UIDX_Ptemplate_Name => Campos: TemplateName
 Indexs: ninguno
Entidad: EdiDocRule (MessagePartnerRules)
Registra las reglas que se aplican a cada tipo de documento. Es cerrado junto a DocType? O cerrado a
medias, es decir cerrado para DocType, pero abierto para ingresar las reglas.

Plural EdiDocRules
Nombre tabla EdiDocRules
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si/No
Crear vista modal (Si/No) Si/No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
DocumentTypeId Fk Identifica el tipo de documento para el que se ha
diseñado la plantilla
DirectionId* Nvarchar[30] Identifica el sentido en el cual se aplica la regla,
desde … Qué proceso condiciona, cómo se aplica?
Rule* Nvarchar[1000] Descripción de la regla. Cómo se describe
Indices:
 Unique indexs:
o UIDX_Rules_Rule => Campos: DocumentTypeId + DirectionId, pueden haber varias reglas en el mismo sentido.
 Indexs: ninguno
Entidad: EdiRuleDirection
Es un maestro cerrado que registra las dos direcciones en que se pueden aplicar las reglas de un
mensaje

Plural EdiRuleDirections
Nombre tabla EdiRuleDirections
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
DirectionCode Nvarchar[1] Código asignado
DirectionDescription* Nvarchar[12] Descripción. (es key de recurso)
Indices:
 Unique indexs: UIDX_Ptemplate_DtypeName

o Campos: DocumentTypeId + TemplateName
 Indexs: ninguno
Carga inicial:
Description Code
Source 1
Destination 2
Entidad: EdiPartnerContact
Registra los contactos que tiene la empresa con un partner externo según una local station física, en
otras palabras, dada una relación entre una Local station (física) y un partner externo (físico) se puede
definir un conjunto de contactos con el partner externo.

Plural EdiPartnerContacts
Nombre tabla EdiPartnerContacts
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
PartnerRelationshipId* Fk Identifica la relación a la cual se le está vinculando
un contacto.
EdiPartnerContact * .. 1 EdiPartnerRelationship
ContactName Nvarchar[40] Nombre del contacto
ContactRoleId Fk Identifica el rol del contacto vinculado al partner
EdiPartnerContact * .. 0/1 EdiContactRole
CreationDate* DateTime Fecha/hora de creación
ContacNotes Nvarchar[250], Null Notas respecto a la relación del partner con el
contacto especificado
Indices:
 Unique indexs: UIDX_

o Campos:
 Indexs: ninguno
Entidad: EdiContactRole (cultura en EdiContactRoleCulture)
Registra los roles que pueden asumir los contactos de los partners.
Es un maestro “abierto” con cultura para el campo RolDescription.

Plural EdiContactRoles
Nombre tabla EdiContactRoles
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
CreationDate* DateTime
RolDescription Nvarchar[50], Null Descripción del rol. Gestión con cultura
Indices:
 Unique indexs:
o
 Indexs: ninguno
Entidad: EdiContactComType
Registra las diferentes maneras de contactar a un contacto

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.PartnerRelations
Plural EdiContactComTypes
Nombre tabla EdiContactComTypes
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
PartnerContactId Fk Identifica el PartnerContact al que se le está
relacionado un tipo de comunicación
EdiPartnerContact * .. 1 EdiContact
CommunicationTypeId Fk Identifica el tipo de comunicación
EdiPartnerContact * .. 1 EdiContact
CommTypeResource Nvarchar[300] Es la descripción referida a la forma de
comunicación que se ha vinculado
Indices:

o Campos:
 Indexs: ninguno
Entidad: EdiCommunicationType (cultura en EdiCommunicationTypeCulture)
Registra los posibles canales de comunicación con las personas de contacto de los partners.
Es un maestro “abierto” con cultura para el campo CtionTypeDescription.

Plural EdiCommunicationTypes
Nombre tabla EdiCommunicationTypes
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
CtionTypeDescription Nvarchar[50], Null Descripción del tipo de comunicación. Gestión con
cultura
Indices:
 Unique indexs:
o
 Indexs: ninguno
Carga inicial:
es-ES en-US it-IT fr-FR de-DE

Teléfono Phone
Correo E-mail
Fax Fax
Whatsup
Facebook
Entidad: EdiPartnerCommConfig
Registra los diferentes métodos de comunicación que se tienen con un partner externo.

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.PartnerRelations
Plural EdiPartnerCommConfigs
Nombre tabla EdiPartnerCommConfigs
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) No
Auditoría

Id* Int Pk
PartnerRelationshipId* Fk Identifica el partner
EdiPartnerCommConfig * .. 1 EdiPartnerRelationship
CommunicationMethodId* Fk Identifica el método de comunicación
EdiPartnerCommConfig * .. 1 EdiCommunicationMethod
Indices:

o Campos:
 Indexs: ninguno
Entidad: EdiCommunicationMethod
Es un maestro que registra los diferentes métodos de comunicación que se pueden dar entre partners.
Es un maestro “cerrado” sin cultura.

Plural EdiCommunicationMethod
Nombre tabla EdiCommunicationMethod
Entidad base Entity
Primary key Int
Add-Migration No
Update-Database No
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
MethodCode* Nvarchar[5] Código del método
MethodDescription* Nvarchar[50] Descripción del método de comunicación, key de
recurso de cultura
Indices:
 Unique indexs:
o UIDX_CommMethod_Code Campos: MethodCode
o UIDX_CommMethod_Description Campos: MethodDescription
o
 Indexs: ninguno
Carga inicial:
MethodCode MethodDescription
1 AS2
2 FTP
3 SFTP
Entidad: EdiMessageType
Es un maestro abierto que registra los tipos de mensajes. Sin control de cultura.

Plural EdiMessageTypes
Nombre tabla EdiMessageTypes
Entidad base Entity
Primary key Int
Add-Migration No
Update-Database No
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
MsgType* Nvarchar[70] Descripción.
UpdateDate DateTime
CreationDate DateTime
Indices:
 Unique indexs: UIDX_Mtype_Description

o UIDX_MessageType => Campos: MsgType
 Indexs: ninguno
Carga inicial:
MsgType
DESADV_LO
INSDES_LO_CUSTOMER
INVRPT_LO_CQC
OSTRPT_LO
RECADV_LO
INVRPT_LO
INSDES_LO_TRANSFER
PRICAT_LO
Entidad: EdiMessageFormat
Es un maestro cerrado (sin cultura) que registra los formatos de los mensajes.

Plural EdiMessageFormats
Nombre tabla EdiMessageFormats
Entidad base Entity
Primary key Int
Add-Migration No
Update-Database No
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
MsgFormat* Nvarchar[70] Descripción.
Indices:

o UIDX_MessageFormat => Campos: MsgFormat
 Indexs: ninguno
Carga inicial:
Description
EDIFACT
TXT
…. Hay más?
Entidad: EdiCommunicationStatus
Es un maestro cerrado que registra los “estados” en los que se pueden encontrar las transmisiones y
mensajes. Sin gestión de culturas.

Plural EdiCommunicationStatus
Nombre tabla EdiCommunicationStatus
Entidad base Entity
Primary key Int
Add-Migration No
Update-Database No
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
StatusCode* Int Código asignado
StatusDescription Nvarchar[50] Key de cultura.
*
Color* Nvarchar[20] Color identificativo
Image* Nvarchar[30] Texto identificativo de la imagen
Indices:
 Unique indexs:
o UIDX_CommStatus_Description => Campos: StatusDescription
o UIDX_CommStatus_Code => Campos: StatusCode
 Indexs: ninguno
Carga inicial:
Code Description es-Es fr it de pt nl fi se

1 Pending Pendiente En attente In sospeso In afwachting Pendente In afwachting Vireillä I väntan på.
2 Sent Enviado Envoyé Inviato Verzonden Enviei Verzonden Lähetetyt Skickats
3 Delivered Entregado Livré Consegnato Geleverd Entregue Geleverd Toimitettu Levereras
4 Received Recibido Reçu Ricevuto Ontvangen Recebido Ontvangen Otettu vastaan Mottagen
5 Error Error Erreur Errore Fout Erro Fout Virhe Fel
Entidad: EdiDirection
Es un maestro cerrado que sirve para indicar la dirección de envió de una transmisión desde el punto de
vista de la empresa propietaria de la aplicación.

Plural EdiDirections
Nombre tabla EdiDirections
Entidad base Entity
Primary key Int
Add-Migration Si
Update-Database Si
User interface
Crear UI (Si/No) No
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Int Pk
DirectionCode* int Código asignado.
DirectionDescription* Nvarchar[50] key de recurso
Color Nvarchar[20] Color identificativo
Image Nvarchar[30] Texto identificativo de la imagen
Indices:

o UIDX_Direction_Code => campos: DirectionCode
o UIDX_Direction_Description => campos DirectionDescription
o
 Indexs: ninguno
Carga inicial:
DirectionDescription En-US es-Es fr it de pt nl fi se ca

1 Outbound Outbound Saliente Sortant In entrata Uitgaand Saída Uitgaande Lähtevä Utgående Sortint
e
2 Inbound Inbound Entrante Entran In uscita Inkomend De entrada Inkomend Saapuva Inkommande Entrant
t
Entidad: EdiTransmission
Registra la información de las transmisiones. Esta información se carga desde un proceso externo a la
aplicación.

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.Mensajes
Plural EdiTransmissions
Nombre tabla EdiTransmissions
Entidad base Entity
Primary key Int
Add-Migration No
Update-Database No
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Pk
IdTransmission GUID Id de la transmisión, viene dado por una
aplicación externa. Es un GUID (unique identifier)
CommunicationMethodId* Fk Identifica el método de comunicación empleado
en la transmisión.
EdiTransmission * .. 1
EdiCommunicationMethod
DirectionId* Fk Identifica en qué sentido se hizo la
comunicación, desde el punto de vista de la
empresa.
EdiTransmission * .. 1 EdiDirection
StationPartnerId* Fk “Local station” de la transmisión.
Debe ser una local station “física”
EdiTransmission * .. 1 EdiPartner
SourceId Fk Partner que origina la transmisión.
EdiTransmission * .. 0/1 EdiPartner
DestinationId Fk Partner destino de la transmisión.
EdiTransmission * .. 0/1 EdiPartner
StatusId* Fk Identifica el status actual de la transmisión.
EdiTransmission * .. 1 EdiCommunicationStatus
CreationDate* DateTime Fecha de creación.
UpdateDate* DateTime Fecha de última actualización
TransmissionDate DateTime Fecha de transmisión, Fecha hora de inicio o
fecha y hora de finalización.
InterchangeControlDef Nvarchar[14] ¿??
Format Nvarchar[50] ¿??
Reference Nvarchar[100] ¿??
FilePath Nvarchar[150] Ruta donde se guarda el fichero en servidor
FileName Nvarchar[150] Nombre del fichero transmitido
Indices:
 Unique indexs:
o
 Indexs: ninguno
Entidad: EdiMessage
Registra la información de los mensajes enviados en una transmisión. Esta información se carga desde
un proceso externo a la aplicación.

Namespace (especifica el path/carpeta donde se ubicarán las clases Edi.Mensages
Plural EdiMessages
Nombre tabla EdiMessages
Entidad base Entity
Primary key Int
Add-Migration No
Update-Database SNo
User interface
Crear UI (Si/No) Si
Multi tenancy
Host (Si/No) Si
Tenant ((Si/No) Si
Auditoría

Id* Pk
IdMessage* GUID Es el Id externo del mensaje, viene dado por una
aplicación externa. Es un GUID (unique identifier)
IdTransmission GUID Identifica la transmisión a la que pertenece el
mensaje. Es un GUID (unique identifier)
Nullable
StationPartnerId* Fk “Local station” de la transmisión.
Debe ser una local station “física”
EdiMessage * .. 1 EdiPartner
StatusId* Fk Identifica el status actual de la transmisión.
EdiMessage * .. 1 EdiCommunicationStatus
MsgTypeId* Fk Tipo de mensaje.
EdiMessage * .. 1 EdiMessageType
MsgFormatId* Fk Formato del mensaje.
EdiMessage * .. 1 EdiMessageFormat
DocumentTypeId* Fk Tipo de documento del mensaje.
EdiMessage * .. 1 EdiDocumentType
CreationDate* DateTime Fecha de creación. Se crea al transmitir ¿???
UpdateDate* DateTime Fecha de actualización
SourceId Fk Partner de origen del fichero, puede ser física o
local
EdiMessage * .. 0/1 EdiPartner
DestinationId Fk Partner destino del fichero, puede ser física o local
EdiMessage * .. 0/1 EdiPartner
FilePath Nvarchar[150]
FileName Nvarchar[150]
SourceDocument Nvarchar[80] null Número de documento
SourceDate DateTime null
Reference1 Nvarchar[80] null
Indices:
 Unique indexs:
o
 Indexs: ninguno
8. Diagrama de casos de uso
9.
Casos de uso
9.1. Maestros
Se definen como maestros a todo el conjunto de entidades que se emplean para dar un soporte de
información o de categorización de datos para las entidades principales de un módulo. Estas entidades
requieren que la aplicación incluya la gestión de sus acciones CRUD de una manera simple y estándar,
salvo para aquellos que se identifiquen como entidades cerradas que no requieren de gestión ya que
poseen una carga inicial de información que es además constante.
9.1.1. Maestros básicos simples

Los maestros básicos simples son aquellas entidades cuyo CRUD se ciñe a las funcionalidades estándar
definidas en la aplicación, es decir y resumiendo, al ingresar se presenta un listado y en la parte superior
se poseen los botones para dar de alta, editar, ver, eliminar un registro, exportar a Excel y PDF más la
casilla de búsqueda rápida. La información se presenta paginada y es posible definir algún filtro para
hacer una consulta acotada. El grid incluye un menú contextual que en sus opciones básicas incluye:
“Copiar las filas seleccionadas”, “Editar el registro en una nueva pestaña” y “ver el registro en una nueva
pestaña”.
La pantalla de edición es simple ya que se solicitan los datos de la entidad y al finalizar o se guarda o se
cancela.
También se incluye la funcionalidad de bloqueos de registros y la de notificaciones y actualización si

algún registro se modifica.
Entre estos maestros se encuentran los mantenimientos para:
 EdiDocumentTypes
 EdiPrintTempaltes
 EdiMessageType
Los casos de uso de cada mantenimiento se ciñen a lo establecido en el documento de “Casos de Uso
Maestros.docx” en el apartado “Maestros básicos simples”.
9.1.2. Maestros básicos con descripción con cultura

Esta categoría se diferencia de los maestros básicos, en que se posee un campo (generalmente
“Description” u otro similar), que requiere que su texto se ingrese en varios idiomas, con el fin de que
cada usuario visualice el campo “Description” en la cultura que posea activa al emplear la aplicación.
Entre estos maestros se encuentran los mantenimientos para:
 EdiContactRole / EdiContactRoleCulture
 EdiCommType / EdiCommTypeCulture
Los casos de uso de cada mantenimiento se ciñen a lo establecido en el documento de “Casos de Uso
Maestros.docx” en el apartado “Maestros básicos con descripción con cultura”.
9.1.3. Maestros básicos sin gestión CRUD

Esta es una categoría que agrupa aquellas entidades que poseen una carga inicial en el momento de la
instalación de la aplicación o posterior a ella y que no necesita que algún usuario gestione su
información ya que es estática para todas las posibilidades de uso, lo cual implica que no es necesario
disponer de interfaces para la gestión de las funcionalidades CUD.
Estas entidades poseen un servicio para poder consultar los registros.
Puede darse el caso que una entidad de estas incluya una entidad secundaria de cultura y por lo tanto
las diferentes funcionalidades en el lado servidor son iguales a una entidad con gestión de cultura.
Entre estos maestros se encuentran:
 EdiPartnerType
 EdiCommuniactionMethod
 EdiMessageFormat
 EdiCommunicactionStaus (con gestión de cultura)
 EdiDirection (con gestión de cultura)
9.1.4. Maestros complejos

En esta categoría se encasillan aquellas entidades de maestros que poseen o una gestión más compleja
de la información o una configuración del estilo maestro–detalle(s) que requieren que la UI de edición
no sea un simple listado de campos y por lo tanto es necesario diseñar una UI específica según las
necesidades de la entidad y las funcionalidades vinculadas.
La gestión de la información de estas entidades por lo tanto sería igual a la gestión de una entidad
principal para un módulo, asumiendo cada una las funcionalidades básicas e incluyendo sus propias
funcionalidades.
Entre estos se encuentran los siguientes mantenimientos:
 Local Stations (entidad EdiPartners)

 External Partners (entidad EdiPartners)
La especificación detallada se hace en los casos de uso de Partners
9.2. Partners (Interlocutores)
9.2.1. Local Stations (Internos)

Se entienden como “Local stations” (estaciones locales) a los “partners” de una transmisión que hacen
referencia a un punto interno (dominio) de la empresa. Estas Local stations pueden ser un punto
principal (físico) o secundario (lógico), entiéndase por ejemplo en caso de GBFoods que un punto
principal es GB (Gallina blanca) y un punto secundario es la fábrica de Murcia de GB.
Para todos los partners se poseen unos datos básicos, pero para las Local Stations físicas, se posee
además una relación con uno o varios “roles de usuarios”; esto con el fin de acotar los usuarios que
pueden establecer relaciones con dicha Local Station ya sea con Local Stations lógicas o con Partners
externos (físicos y lógicos).
La persistencia de información en BD de las Local Stations y los Partners Externos se lleva en la misma
tabla y la misma entidad; igualmente comparten el mismo servicio pero no todos los métodos.
Las Locas Stations aparte de las funcionalidades CRUD y las incluidas de manera genérica para el grid
incluye las funcionalidades de vincular y desvincular un rol.
9.2.1.1. Listar/Consultar
Descripción: el usuario desea visualizar el listado para hacer una consulta específica o una operación
CRUD.
Interfaz de usuario
En esta interfaz de usuario además de visualizarse el listado de las Local Stations, también se puede
activar la vista de los roles vinculados a la Local Station seleccionada.
Especificaciones técnicas y/o funcionales (ETF):
 Las especificaciones técnicas y funcionales de la gestión del grid se ciñen a las dadas en el
documento “Implementaciones iniciales Nice 3Zero.docx”, en el apartado “Componente
genérico para Grids”.
 El método que recibe las peticiones de consulta es:
Task<DataSourceResult> GetEdiLocalStationsGrid([DataSourceRequest]DataSourceRequest request, string culture)
Este método retorna los registros que cumplan con la condición PrnIsLocalStation == true
9.2.1.2. Alta
Descripción: el usuario desea dar de alta un registro, para lo cual se asume que se encuentra en el
listado y clica en el botón de [Nuevo registro]
Interfaz de usuario

 Para identificar el tipo de cada dato y la longitud máxima permitida consultar la sección
“Descripción de entidades”
 Al guardar el servidor asigna la fecha de creación y actualización.
 Al guardar o cancelar y retornar al listado, este se presenta en el “estado” en el cual se
encontraba con anterioridad. Entiéndase “estado” como la configuración, lo cual incluye los
filtros aplicados, agrupación realizada, página específica, lo cual implica tener activo una variant
si es del caso.
 El método que recibe la petición de alta es
Task<BaseReturn> CreateOrEditRtn(CreateOrEditEdiPartnerDto input)
Si el registro que se guarda corresponde a una Local Station física, también se inserta un
registro en la tabla de EdiPartnersRelationship (consultar el apartado “Descripción de las
entidades implicadas” referencia a la entidad “EdiPartnerRelationship”, para más detalle de la
información que se guarda), con el fin de llevar el registro de la configuración de base para las
comunicaciones que se realicen con dicha Local Station.
 Los diferentes Dto empleados poseen su documentación en el código.
 Para seleccionar el tipo de interlocutor se emplea el componente
“adxLookupModalComponent” indicando la url del servicio de la entidad EdiPartnerType y
presentando los campos PtypeDescription (Descripción) y PtypCode (Tipo).
9.2.1.3. Editar
Descripción: el usuario desea editar un registro, para lo cual se asume que se encuentra en el listado,
selecciona un registro y clica en [Editar].
Interfaz de usuario
Es la misma del Alta.

 Al guardar, en servidor se asigna la fecha de actualización.
 En servidor se comprueba que la fecha de actualización en BD no sea posterior a la fecha de
actualización en el registro a guardar, de serlo en el Dto de retorno se asigna {ProcessOk =
False, ErrorCode= AdxConsts.UpdateDateValidation} y en cliente se presenta al usuario el
mensaje de error.
si es del caso.
 El método que recibe la petición de edición es
Task<BaseReturn> CreateOrEditRtn(CreateOrEdit[Entidad]Dto input)
9.2.1.4. Eliminar
Descripción: el usuario desea eliminar un registro, para lo cual se asume que se encuentra en el listado,
y ha seleccionado el registro (o los registros) a eliminar y clica en [Eliminar].
Interfaz de usuario
 Si el registro a eliminar posee registros vinculados de otras tablas, se presenta un mensaje de
error estándar en cliente.
 El método que recibe la petición de eliminar es:
Task<DeleteResponseDto> DeleteEdiPartners(DeleteRequestDto input)
En caso de eliminar una Local Station física, se debe eliminar el registro vinculado en
EdiPartnerRelationship.
9.2.1.5. Vincular un rol

Descripción: el usuario desea vincular un rol a una Local Station física, para lo cual se asume que se
encuentra en el listado, y ha seleccionado la Local Station.
Interfaz de usuario
Pasos
En cliente En Servidor
1. El usuario selecciona el checkbox “Ver
roles” en caso de que no estuviese
seleccionado previamente.
2. La aplicación lanza una consulta para
obtener los roles vinculados a la Local
Station seleccionada
3. El servicio de EdiLocalStationRolesAppService
recibe la petición y retorna los roles vinculados
4. La aplicación presenta un panel a la
derecha con un listado de los roles
vinculados
5. El usuario clica en el botón de [Vincular rol]
6. La aplicación presenta una ventana modal
para hacer selección de un Rol. Y hace una
petición a servidor para obtener los roles
7. El servicio de RoleAppService recibe la petición y
retorna los roles posibles a seleccionar.
8. Se visualizan los roles en la ventana modal.
9. El usuario selecciona el rol deseado con
doble clic.
10. La aplicación hace una solicitud a servidor
para vincular el Rol a la Local Station
recibe la petición, da de alta el registro.
actualizar los registros vinculados a la
Local Station seleccionada
14. La aplicación presenta el listado de roles
actualizado.
Flujos alternativos
Paso 9: Si el usuario no desea vincular ningún
Rol clica en el botón de [Cerrar]. La
aplicación cierra la ventana modal.

 Solo se pueden vincular roles a una Local Station física.
 En la vista modal para seleccionar el Rol a vincular se excluyen los roles ya vinculados.
 Las especificaciones técnicas y funcionales de la ventana modal para seleccionar el Rol
coinciden con las especificaciones para seleccionar un registro referente a una foreign key, esto
se puede consultar en el documento “Implementaciones iniciales Nice3Zero.docx” apartado
“Componente de selección de registro (fk selector/item selector)”.
 El método que recibe la petición para consultar los roles vinculados a una Local Station es:
Task<DataSourceResult> GetEdiLocalStationRolesGrid([DataSourceRequest]DataSourceRequest request, string culture)
 El método que recibe la petición para consultar los roles posibles a seleccionar es
Task<DataSourceResult> GetRolesGrid([DataSourceRequest]DataSourceRequest request)
 El método que recibe la petición para vincular el rol a la Local Station es
Task CreateOrEdit(CreateOrEditEdiLocalStationRoleDto input)
9.2.1.6. Desvincular un rol

Descripción: el usuario desea desvincular un rol a una Local Station física, para lo cual se asume que se
encuentra en el listado, ha seleccionado la Local Station, ha activado el panel de “Ver roles”.
Interfaz de usuario
La misma de vincular un rol

Pasos
1. El usuario selecciona el Rol a desvincular y
clica en el botón de [Desvincular].
2. La aplicación hace una pregunta de
confirmación. El usuario confirma.
3. La aplicación hace una petición a servidor
para desvincular el rol.
recibe la petición y desvincula el rol
actualizar los registros vinculados a la
Local Station seleccionada
7. La aplicación presenta el listado de roles
actualizado.
Flujos alternativos
Paso 2: Si el usuario no desea desvincular el
Rol no confirma la acción.

 Solo se pueden vincular roles a una Local Station física.
 En la vista modal para seleccionar el Rol a vincular se excluyen los roles ya vinculados.
 Las especificaciones técnicas y funcionales de la ventana modal para seleccionar el Rol
coinciden con las especificaciones para seleccionar un registro referente a una foreign key, esto
se puede consultar en el documento “Implementaciones iniciales Nice3Zero.docx” apartado
“Componente de selección de registro (fk selector/item selector)”.
 El método que recibe la petición para consultar los roles vinculados a una Local Station es:
Task<DataSourceResult> GetEdiLocalStationRolesGrid([DataSourceRequest]DataSourceRequest request, string culture)
 El método que recibe la petición para desvincular el rol es
Task Delete(EntityDto input)
 Los diferentes Dtos empleados poseen su documentación en el código.
9.2.2. External Partners

Se entienden como “External Partners” a los partners de una transmisión que hacen referencia a puntos
externos de la empresa. Un External Partner registrado en la aplicación puede hacer referencia a un
punto físico o lógico; entiéndase por ejemplo en el caso de El Corte Inglés que la sede administrativa
principal es el punto físico y la sede en la diagonal es un punto lógico.
La persistencia de información en BD de las Local Stations y los External Partners se lleva en la misma
tabla y la misma entidad; igualmente comparten el mismo servicio pero no todos los métodos.
Las diferentes operaciones CRUD que se realizan para los External Partners son exactamente iguales que
para un maestro básico simple, por lo cual no se hace ninguna descripción detallada de los pasos pero si
se hace más énfasis en las especificaciones técnicas y funcionales. También se hace necesario aclarar
que para los External Partners físicos no se registran vínculos con roles como si se hace con las Local
Stations físicas.
9.2.2.1. Listar/Consultar
Descripción: el usuario desea visualizar el listado para hacer una consulta específica o una operación
CRUD.
Interfaz de usuario
Pasos
1. El usuario selecciona la opción de menú
“Edi\Interlocutores\Externos”
2. La aplicación pasa a la UI del listado de
interlocutores externos y hace una petición
a servidor
3. El servicio de EdiPartners recibe la petición, la
procesa y retorna la respuesta
4. La aplicación presenta la información en el
grid
Flujos alternativos
Paso :

Task<DataSourceResult> GetEdiPartnersGrid([DataSourceRequest]DataSourceRequest request, string culture)
Este método retorna los registros que cumplan con la condición PrnIsLocalStation == false
9.2.2.2. Alta
Descripción: el usuario desea dar de alta un registro, para lo cual se asume que se encuentra en el
listado y clica en el botón de [Nuevo registro]
Interfaz de usuario
Es la misma interfaz que para dar de alta una Local Station.

 Al guardar el servidor asigna la fecha de creación y actualización.
si es del caso.
9.2.2.3. Editar
selecciona el registro a editar y clica en [Editar].
Interfaz de usuario
Es la misma interfaz que para dar de alta una Local Station

 Al guardar el servidor asigna la fecha de actualización.
si es del caso.
9.2.2.4. Eliminar
y ha seleccionado el registro (o los registros) a eliminar y clica en [Eliminar].
Interfaz de usuario
Es el mismo mensaje de confirmación para cuando se elimina una Local station

Task<DeleteResponseDto> DeleteEdiPartners(DeleteRequestDto input)
9.2.3. Relaciones entre Local Stations
Una de las necesidades del módulo de EDI es poder vincular Local Stations (LSs) lógicas con una LS física
y registrar la información que rige las comunicaciones de las LSs físicas así como información referente a
personas de contactos tanto de las físicas como de las lógicas.
9.2.3.1. Ver listado

Descripción: el usuario desea visualizar las relaciones existentes entre las LS a las cuales tiene acceso.
Interfaz de usuario
Pasos
“Edi\Interlocutores\Estructura interna”
2. La aplicación pasa a la UI de estructura
interna y hace una petición a servidor para
presentar todas las LS físicas a las cuales el
usuario activo tiene acceso
4. La aplicación presenta las LS y cada registro
se visualiza contraído
Flujos alternativos
Paso :

 El listado que se presenta está condicionado al usuario activo, ya que cada LS física posee
relaciones con varios Roles de usuarios y por lo tanto solo los usuarios que estén incluidos en
dichos roles podrán visualizar en este listado las relaciones de dicha LS física.
Task<List<GetEdiPartnerForViewDto>> LocalStationsForUser(GetPartnersInput input)
Este método retorna los registros que cumplan con la condición PrnIsLocalStation == true &&
ParnterTypeFk.PtypCode == “F” y además se verifica que sean registros a los cuales el usuario
activo tenga acceso.
Este método también tiene en cuenta si el usuario a ingresado un texto de la casilla de
“búsqueda” y si además se ha indicado que se realice la búsqueda en interlocutores lógicos
9.2.3.2. Ver LSs lógicas vinculadas a una física

Descripción: el usuario desea visualizar las LSs lógicas vinculadas a una física para lo cual se asume que
se encuentra en el listado de “Estructura interna”.
Interfaz de usuario
Pasos
1. El usuario da clic sobre el icono de + que
posee a la izquierda el registro del
interlocutor físico que se desea desplegar
2. La aplicación activa un componente interno
para presentar los interlocutores lógicos y
este hace una petición a servidor para
obtener los registros que posee vinculados.
3. El servicio de EdiPartners recibe la petición y
retorna un Dto con los registros vinculados
4. La aplicación los registros vinculados al
registro desplegado.
Flujos alternativos
Paso :

 El método que recibe las peticiones para retornar de los registros lógicos vinculados es:
Task<List<GetEdiPartnerForViewDto>> LogicalStationsForRootStation(GetLogicalStationsInput input)
9.2.3.3. Alta de una LS lógica
Descripción: el usuario desea dar de alta una nueva LS lógica, para lo cual se asume que se encuentra
en el listado de “Estructura interna”.
Interfaz de usuario
Es la misma UI que se emplea para dar de alta un interlocutor en la UI de interlocutores internos.
Pasos
1. El usuario primero clica sobre un registro
de interlocutor físico y clica en el botón
de [+] (Nuevo interlocutor interno lógico)
2. La aplicación pasa a la UI de edición de
interlocutores.
3. El usuario ingresa los datos y al finalizar
clica en [Guardar].
La aplicación envía los datos para dar de
alta el registro.
4. El servicio de EdiPartners recibe la petición y da de
alta el registro
5. La aplicación presenta una notificación que
indica que el registro se ha guardado
correctamente.
interna y pregunta al usuario si desea
vincular el nuevo interlocutor con el
interlocutor físico que había seleccionado
antes de dar clic en el botón de [+]. El
usuario responde afirmativamente a la
pregunta.
7. El servicio de EdiPartnerRelationship recibe la
petición de dar de alta la relación y guarda el
registro.
8. La aplicación presenta el listado de
estructura interna tal como se tenía antes
de clicar el botón de [+].
Flujos alternativos
Paso 6: si el usuario no responde
afirmativamente para establecer la
relación, se pasa directamente al paso 8.

 El método que recibe las peticiones para dar de alta el registro del nuevo interlocutor es:
El método asigna la fecha de creación y de actualización y el TenanId por defecto
 El método empleado que recibe la petición para guardar la relación es:
Task CreateOrEdit(CreateOrEditEdiPartnerRelationshipDto input)
El método asigna la fecha de creación y de actualización y el TenanId por defecto
 Como solo es posible dar de alta interlocutores “Lógicos”, el campo “Tipo de interlocutor” ya
asume este valor y no es modificable por el usuario.
 Para saber los valores que se asignan a los diferentes campos de la relación ver la sección
“Descripción de entidades”, específicamente donde se define la entidad
“EdiPartnerRelationship”.
 Ventana modal para que el usuario confirme si desea establecer un vínculo entre las LS
9.2.3.4. Editar una LS lógica

Descripción: el usuario desea editar el registro de una LS lógica, para lo cual se asume que se
encuentra en el listado de “Estructura interna”.
Interfaz de usuario
Es la misma UI que se emplea para editar un interlocutor en el CRUD de interlocutores internos.
Pasos
1. El usuario despliega el registro del
interlocutor físico al que está vinculado el
interlocutor lógico que desea editar,
selecciona el interlocutor lógico y clica en el
botón de editar.
2. La aplicación comprueba que el registro no
esté bloqueado y luego pasa a la UI de
edición de interlocutores.
3. Se hace una petición a servidor para
obtener el registro a editar
4. El servicio de EdiPartners recibe la petición, busca
el registro y retorna un Dto con el mismo
5. El usuario edita los datos y al finalizar clica
en [Guardar]. La aplicación hace una
petición a servidor para guardar el registro.
6. El servicio de EdiPartners recibe la petición,
guardar el registro y retorna un Dto con
información del resultado del proceso.
7. Si en el Dto de retorno ProcessOk == true se
presenta una notificación que indica que el
registro se ha guardado correctamente.
interna (o relaciones comerciales) y
presenta el listado tal como se tenía antes
de clicar el botón de editar.
Flujos alternativos
Paso 2: si el registro está bloqueado se
presenta un mensaje indicando dicho
suceso y no es posible editar el registro.
Paso 5: si el usuario clica en el botón de
[Cancelar] la aplicación pasa directamente
al paso 8.
Para el paso 6: la aplicación antes de actualizar el
registro verifica que el valor del campo
“UpdateDate” en BD sea igual al mismo campo en el
Dto que se recibe, en caso tal de que sea diferente
es porque han actualizado el registro mientras se
editaba y en este caso se retorna en el Dto
ProcessOk = false y ErrorCode = “UpdateDateError”,
lo cual implica que en cliente se debe presentar un
mensaje notificando el hecho. La aplicación Cliente
queda en la UI de edición.

 El método que recibe la petición para guardar el registro es:
 Como solo es posible editar interlocutores “Lógicos” el campo “Tipo de interlocutor” no es
modificable por el usuario.
9.2.3.5. Vincular una LS lógica a una LS física

Descripción: el usuario desea vincular una LS lógica con una LS física, para lo cual se asume que se
Interfaz de usuario
Selección de uns LS lógica con el
componente adxLookupModalComponent
Pasos
1. El usuario selecciona el registro del
interlocutor físico al que desea vincular el
interlocutor lógico que va a seleccionar y
clica en el botón de [Lógico].
para hacer la selección.
3. El usuario selecciona el registro y clica en
[Ok] o da doble clic sobre el registro.
4. La aplicación desactiva la ventana modal y
hace una solicitud a servidor para guardar
la relación entre los dos interlocutores
petición, define un nuevo registro le asigna la
fecha de creación la de actualización y el tenantId
y da de alta la relación.
6. La aplicación presenta el listado tal como se
tenía antes de clicar el botón [+Logico].
Flujos alternativos
al paso 6.

 El método que recibe la petición para guardar el registro de la relación es:
9.2.3.6. Editar información de comunicaciones y contactos

Descripción: el usuario desea editar la información de comunicación y contactos vinculada a una LS
física o simplemente la información de contactos de una LS lógica, para lo cual se asume que se
Interfaz de usuario
Pasos
1. El usuario selecciona el registro del cual
desea ver la información de
comunicaciones y contactos y clica en el
respectivo botón de la parte superior.
2. La aplicación pasa a la UI de “Edición de
información de comunicaciones y
contactos”.
3. La aplicación hace solicitud a servidor para
recuperar toda la información de
comunicaciones y contactos vinculada con
el registro que había seleccionado el
usuario.
petición, consulta a BD la información requerida y
retorna un Dto con todos los datos.
5. La aplicación recibe el Dto y presenta la
información en la UI distribuida
6. El usuario edita los datos y al final clica en
el botón de [Guardar].
7. La aplicación lanza a servidor una petición 8. El servicio de EdiPartnerRelationship recibe la
para guardar el registro. petición, consulta a BD la información requerida y
retorna un Dto con todos los datos.
9. La aplicación presenta una notificación
indicando que se ha guardado el registro
correctamente.
10. La aplicación retorna a la UI de
“Estructura interna” y presenta el listado
tal como se tenía antes de la edición.
Flujos alternativos
al paso 6.

 La información que se registra en esta UI es crucial para las transmisiones del interlocutor
vinculado (PartnerId) en la relación (es el último o único interlocutor que se visualiza en el título
de la UI, al cual identificaremos como el interlocutor de base en los siguientes casos de uso),
ya que aquí se identifica la configuración que rige cada una de sus transmisiones, como los
métodos de comunicación empleados y las plantillas que se emplearán para visualizar el
contenido de los diferentes tipos de documentos que se envían o reciben.
Además es posible gestionar información sobre los contactos del interlocutor base.
 El método que recibe la petición para consultar el registro de la relación es:
Task<GetEdiPartnerRelationshipForEditOutputTk> EditRelationshipTk(EditEdiRelationInput input)
Task<BaseReturn> CreateOrEditTk(CreateOrEditEdiPartnerRelationshipDtoTk input)
Este método se encarga de verificar que no se haya editado previamente el registro y de
asignar la fecha de actualización a cada uno de los registros de detalle implicados que se
actualicen. En el Dto se reciben todas las colecciones de los registros de detalle y se procede a
realizar la operación requerida para cada uno (dar de alta, actualizar o eliminar).
 Para las funcionalidades de cada uno de los “tabs” que hay en la UI consultar sus
correspondientes casos de uso dependientes del presente.
 Los “tabs” de “Métodos de comunicación” y “Doc y plantillas” solo están visibles cuando se
edite un registro de EditPartnerRelationship en donde EdiPartnerId corresponde a una relación
con un Partner en el cual EdiPartnerTypeFk.PtypCommunication == true.
 Para tener más referencia técnica sobre la gestión del Dtos para consultar y guardar
información compleja que incluye registros de detalles, consultar el documento “Empleo de
Dto’s para gestionar módulos.docx”.
9.2.3.6.1. Métodos de comunicación. Vincular
Descripción: el usuario desea vincular (dar de alta) un método de comunicación para el interlocutor de
base de la relación, para lo cual se asume que se encuentra en el tab de “Métodos de comunicación” en
la UI de “Editar información de comunicación y contactos”.
Interfaz de usuario
Selección de un método de comunicación con el
Pasos
1. El usuario da clic al botón [+].
para hacer la selección del método a
vincular.
3. El usuario selecciona el registro y clica el
botón [Ok] o da doble clic sobre el registro
a seleccionar.
4. La aplicación agrega el método a la
colección de métodos
Flujos alternativos
[Cancelar] la aplicación no agrega ningún
método

 La colección de métodos seleccionados se vincula con la entidad EdiPartnerCommConfigs
 En el Dto del nuevo registro se asigna [Dto].action == EntityAction.Add
 Para más información técnica y funcional sobre el component adxLookupModalComponent
consultar la sección “Componente de selección de registro” del documento “Implementaciones
iniciales en Nice 3Zero.docx”.
9.2.3.6.2. Métodos de comunicación. Desvincular

Descripción: el usuario desea desvincular (eliminar) un método de comunicación para el interlocutor
de base de la relación, para lo cual se asume que se encuentra en el tab de “Métodos de comunicación”
en la UI de “Editar información de comunicación y contactos”.
Interfaz de usuario
Pasos
1. El usuario selecciona del listado el registro
del método a desvincular y da clic al botón
“Eliminar”.
2. La aplicación retira el registro de la
colección de métodos
Flujos alternativos
Paso :

 En el Dto del registro se asigna [Dto].action == EntityAction.Deleted, salvo que se detecte que
dicho registro había sido añadido en el proceso de edición actual y por lo tanto simplemente se
elimina de la colección. Si realmente se debe eliminar el registro se agrega su Dto a una
colección de métodos de comunicación a eliminar.
9.2.3.6.3. Tipos de documento y plantillas. Alta

Descripción: el usuario desea vincular (dar de alta) una plantilla de edición para un tipo de documento
específico que se envía o recibe en las transmisiones del interlocutor de base, para lo cual se asume que
se encuentra en el tab de “Tipos de doc. y plantillas” en la UI de “Editar información de comunicación y
contactos”.
Interfaces de usuario
Listado de Tipos de documentos y plantillas
Ventana modal de edición de Tipo de documento y plantilla
Pasos
para que el usuario seleccione el tipo de
documento la plantilla de edición que
desea vincular a dicho documento y el
método de comunicación que rige las
transmisiones de dicho tipo de documento.
Al final clica en [Ok]
3. La aplicación agrega el método a la
colección de documentos y plantillas
Flujos alternativos
método

 La colección de documentos y plantillas se vincula con la entidad EdiDocumentExchangeInfo
 En la venta modal se poseen botones para seleccionar y desvincular un tipo de documento. Se
emplea el componente genérico de selección y se interactúa de manera estándar con dicho
componente.
Selección de un tipo de documento con el
 En la venta modal se poseen botones para seleccionar y desvincular una plantilla para
formatear el tipo de documento seleccionado (en la UI de mensajes). En la ventana de
selección de la plantilla se presenta un listado de plantillas seleccionadas que estén
directamente vinculadas con el tipo de documento seleccionado por el usuario.
Selección de una plantilla con el


9.2.3.6.4. Tipos de documento y plantillas. Editar

Descripción: el usuario desea editar un registro de tipo de documento y plantilla, para lo cual se asume
que se encuentra en el tab de “Tipos de doc. y plantillas” en la UI de “Editar información de
comunicación y contactos”.
Es la misma UI empleada para dar de alta un tipo de documento y plantilla
Pasos
1. El usuario da clic al botón de “Editar”.
para que el usuario edite la información. Al
final clica en [Ok]
3. La aplicación actualiza los datos en el Dto y
presenta la información actualizada en el
listado
Flujos alternativos
[Cancelar] la aplicación no asume ningún
cambio

 En el Dto del registro se asigna [Dto].action == EntityAction.Update, salvo que se detecte que
dicho registro había sido añadido en el proceso de edición actual y por lo tanto se debe
conservar la asignación de EntityAction.Add.
9.2.3.6.5. Tipos de documento y plantillas. Eliminar

Descripción: el usuario desea desvincular (eliminar) un tipo de documento y su plantilla para el
interlocutor de base de la relación, para lo cual se asume que se encuentra en el tab de “Tipos de doc. y
plantillas” en la UI de “Editar información de comunicación y contactos”.
Interfaz de usuario
Pasos
del tipo de documento y plantilla a
desvincular y da clic al botón “Eliminar”.
colección de tipos de documentos y
plantillas.
Flujos alternativos
Paso :

colección de documentos y plantillas a eliminar.
9.2.3.6.6. Contactos. Alta

Descripción: el usuario desea dar de alta un contacto del interlocutor de base, para lo cual se asume
que se encuentra en el tab de “Contactos” en la UI de “Editar información de comunicación y
contactos”.
Listados de contactos y formas de contactar
Ventana modal de edición de Contacto
Pasos
para que el usuario seleccione el rol del
contacto, ingrese el nombre del contacto y
si lo requiere alguna nota. Al final clica en
[Ok]
3. La aplicación agrega el contacto a la
colección de contactos
Flujos alternativos
contacto

 La colección de contactos se vincula con la entidad EdiPartnerContact.
 En la venta modal se poseen botones para seleccionar y desvincular un rol. Se emplea el
componente genérico de selección y se interactúa de manera estándar con dicho componente.
Selección del rol del contacto con el


9.2.3.6.7. Contactos. Editar

Descripción: el usuario desea editar un registro de contacto, para lo cual se asume que se encuentra en
el tab de “Contactos” en la UI de “Editar información de comunicación y contactos”.
Es la misma UI empleada para dar de alta un contacto

Pasos
1. El usuario da clic al botón de “Editar”.
final clica en [Ok]
listado
Flujos alternativos
cambio

9.2.3.6.8. Contactos. Eliminar

Descripción: el usuario desea eliminar contacto para el interlocutor de base de la relación, para lo cual
se asume que se encuentra en el tab de “Contactos” en la UI de “Editar información de comunicación y
contactos”.
Interfaz de usuario
Pasos
del tipo de documento y plantilla a
desvincular y da clic al botón “Eliminar”.
colección de tipos de documentos y
plantillas.
Flujos alternativos
Paso :

colección de contactos a eliminar.
9.2.3.6.9. Formas de contactar. Alta

Descripción: el usuario desea vincular una forma de contactar a un contacto del interlocutor de base,
para lo cual se asume que se encuentra en el tab de “Contactos” en la UI de “Editar información de
comunicación y contactos”.
Ventana modal de edición de Forma de contactar
Pasos
1. El usuario selecciona un contacto y luego da
clic al botón [+] del listado de formas de
contactar
para que el usuario seleccione la forma de
contactar e ingrese la descripción (número
de teléfono, correo, ...). Al final clica en
[Ok]
3. La aplicación agrega la forma de contactar a
la colección de formas de contactar
vinculada al contacto seleccionado.
Flujos alternativos
[Cancelar] la aplicación no agrega ninguna
forma de contactar.

 La colección de formas de contactar se vincula con la entidad EdiContactComTypes.
 En la venta modal se poseen botones para seleccionar y desvincular un medio de contacto. Se
emplea el componente genérico de selección y se interactúa de manera estándar con dicho
componente.
Selección de una manera de contactar con el

9.2.3.6.10. Formas de contactar. Editar

Descripción: el usuario desea editar un registro de forma de contactar, para lo cual se asume que se
encuentra en el tab de “Contactos” en la UI de “Editar información de comunicación y contactos”.
Es la misma UI empleada para dar de alta una forma de contactar
Pasos
1. El usuario da clic al botón de “Editar” del
listado de formas de contactar.
final clica en [Ok]
listado
Flujos alternativos
cambio

9.2.3.6.11. Formas de contactar. Eliminar

Descripción: el usuario desea eliminar una forma de contactar para el contacto seleccionado del
interlocutor de base de la relación, para lo cual se asume que se encuentra en el tab de “Contactos” en
la UI de “Editar información de comunicación y contactos”.
Interfaz de usuario
Pasos
1. El usuario selecciona del listado de formas
de contactar el registro a eliminar y da clic
al botón “Eliminar”.
colección de formas de contactar vinculada
al contacto seleccionado.
Flujos alternativos
Paso :

colección de formas de contactar a eliminar vinculada al contacto seleccionado.
9.2.3.7. Desvincular una LS lógica de una LS física

Descripción: el usuario desea eliminar la relación entre una LS física y una LS lógica, para lo cual se
asume que se encuentra en el listado de “Estructura interna”.
Interfaz de usuario
Pasos
1. El usuario selecciona el registro la LS
lógica que desea desvincular, luego clica
en el botón de “desvincular interlocutor
lógico”
2. La aplicación presenta una pregunta de
confirmación al usuario
3. El usuario confirma la operación
4. La aplicación lanza una solicitud a 5. El servicio de EdiPartnerRelationship recibe la
servidor para eliminar la relación. petición, verifica que el registro no tenga
dependencias y luego lo elimina.
indicando que se ha eliminado el registro
correctamente.
Flujos alternativos
Paso 3: si el usuario no confirma no se realiza
operación alguna.
Paso 5: si el registro posee algún vínculo con algún
otro registro, en el Dto de retorno se informa de
ello.

Task DeleteRelation(DeleteRelationRequestDto input)
 Consultar las ETF para el caso de uso de “Eliminar” de los Maestros básicos simples” en el
documento “Casos de uso Maestros.docx”.
9.2.3.8. Mover a otro interlocutor interno

Descripción: el usuario desea vincular a un interlocutor físico uno o varios interlocutores lógicos
vinculados a otro interlocutor físico, para lo cual se asume que se encuentra en el listado de “Estructura
interna”.
Interfaz de usuario
Pasos
1. El usuario selecciona un registro de un
interlocutor lógico y luego clica en el
botón de “Mover a otro interlocutor”
2. La aplicación presenta una ventana de
diálogo donde pide al usuario seleccionar
entre: “Mover solo el registro
seleccionado” o “Mover todos los
registros vinculados a AAA” (donde AAA
es el interlocutor físico al que está
vinculado el interlocutor lógico
seleccionado. También presenta un
listado con los interlocutores para
seleccionar aquel al que desea mover el o
los interlocutores lógicos.
3. El usuario hace sus selecciones y clica en
el botón de [Cambiar], también puede dar
doble click sobre el interlocutor que
desea seleccionar.
confirmación de la operación.
5. La aplicación lanza una solicitud a
servidor para eliminar la relación.
6. El usuario confirma y la aplicación lanza
una solicitud a servidor para realizar el o
los cambios indicados por el usuario
7. El servicio de EdiPartnerRelationships recibe la
petición y hace el o los intercambios.
indicando que se ha procesado la petición
satisfactoriamente y hace una recarga de
los interlocutores lógicos que están
vinculados con el interlocutor físico del cual
se ha o han removido.
Flujos alternativos
operación alguna.

Task<BaseReturn> SwapLocalStations(SwapEdiParentDto swapEdiParentDto)
9.2.3.9. Búsqueda
Descripción: el usuario desea filtrar el listado realizando una búsqueda bajo un patrón de texto que
ingrese en la casilla de búsqueda, para lo cual se asume que se encuentra en el listado de “Estructura
interna”.
Interfaz de usuario
Pasos
1. El usuario ingresa un texto en la casilla de
búsqueda
para obtener los registros que cumplan con
la búsqueda.
retorna un Dto con los registros filtrados
4. La aplicación presenta los registros
retornados
Flujos alternativos
Paso :

 El método que recibe las peticiones es:
La consulta tiene como premisa que solo se retornan registros a los cuales el usuario activo
tiene acceso. Se buscan los registros de interlocutores físicos en los que el campo prnName o
prnCode contenga el texto ingresado, además si en la UI estaba seleccionado el check box de
“Buscar en interlocutores lógicos” se busca también el texto ingresado en los registros de los
interlocutores lógicos, pero es de tener en cuenta que solo se retornan registros de
interlocutores físicos, por lo cual si se encuentra un interlocutor lógico se busca el interlocutor
físico al cual está vinculado y si aún no estaba en el resultado de la consulta se incluye.
9.2.4. Relaciones entre Local Stations y External Partners
Otra de las necesidades del módulo de EDI es definir los flujos de las transmisiones de mensajes. Estos
flujos se pueden dar desde o hacia una Local Station física y hacia o desde un External Partner físico.
Para esto se requiere relacionar cada Local Station física con cada uno de los External Partners físicos
con los que realiza transmisiones y además relacionar cada External Partner con todos sus External
Partner lógicos. Extra al establecimiento de las relaciones mencionadas también se requiere registrar la
información que rige las comunicaciones con los External Partners físicos además de información
referente a las personas de contacto de los External Partners tanto físicos como lógicos.
9.2.4.1. Ver listado

Descripción: el usuario desea ingresar a la interface de relaciones comerciales.
Interfaz de usuario
Pasos
“Edi\Interlocutores\Relaciones
comerciales”
2. La aplicación pasa a la UI de relaciones
comerciales y hace una petición a servidor
para obtener las LS físicas a las cuales el
usuario activo tiene acceso
4. La aplicación vincula las LS retornadas con
el combo de “Interlocutores internos”.
Identifica si hay alguna LS (interlocutor
interno) activo de forma global en la
aplicación y de ser así lo deja seleccionado
en el combo de lo contrario deja
seleccionado el primero de la lista.
5. A partir de este punto la aplicación se
comporta como si se hubiera hecho una
selección en el combo, por lo tanto
continuar en el siguiente caso de uso
Flujos alternativos
Paso :

 El listado que se vincula al combo condicionado al usuario activo, ya que cada LS física posee
relaciones con varios Roles de usuarios y por lo tanto solo los usuarios que estén incluidos en
dichos roles podrán visualizar en este listado las relaciones de dicha LS física.
Este método retorna los registros que cumplan con la condición PrnIsLocalStation == true &&
ParnterTypeFk.PtypCode == “F” y además se verifica que sean registros a los cuales el usuario
activo tenga acceso.
9.2.4.2. Seleccionar un LS física (interlocutor interno físico)

Descripción: el usuario desea visualizar las relaciones existentes entre una LS y los External Partners.
Interfaz de usuario
Pasos
1. El usuario selecciona del combo una LS
(interlocutor interno)
para obtener los external partners físicos
que están vinculados a la LS seleccionada
4. La aplicación presenta los external partners
y cada registro se visualiza contraído
Flujos alternativos
Paso 2: si no hay LS seleccionada en el combo
no se continúa con el proceso

Task<List<GetEdiPartnerForViewDto>> ExternalPartnersForLocalStations(GetPartnersInput input)
Este método también tiene en cuenta si el usuario a ingresado un texto de la casilla de
“búsqueda” y si además se ha indicado que se realice la búsqueda en interlocutores lógicos. El
texto insertado en la casilla de búsqueda se comprueba en los campos de “PrnName” y
“PrnCode”
9.2.4.3. Ver partners lógicos vinculados a uno físico
Descripción: el usuario desea visualizar los partners lógicos vinculados a uno físico, para lo cual se
asume que se encuentra en el listado de “relaciones comerciales”.
Interfaz de usuario
Pasos
1. El usuario da clic sobre el icono de + que
posee a la izquierda el registro del
interlocutor físico que se desea desplegar
2. La aplicación activa un componente interno
para presentar los interlocutores lógicos y
este hace una petición a servidor para
obtener los registros que posee vinculados.
retorna un Dto con los registros vinculados
vinculados al registro desplegado.
Flujos alternativos
Paso :

 El método que recibe las peticiones para retornar de los registros lógicos vinculados es:
Task<List<GetEdiPartnerForViewDto>> LogicalStationsForRootStation(GetLogicalStationsInput input)
9.2.4.4. Alta de un external partner lógico

Descripción: el usuario desea dar de alta un nuevo external partner lógico, para lo cual se asume que
se encuentra en el listado de “Relaciones comerciales”.
Interfaz de usuario
Es la misma UI que se emplea para dar de alta un interlocutor en la UI de interlocutores externos.
Pasos
Los pasos son los mismos que los indicados en el caos de uso Alta de una LS lógica
 Las mismas que las dadas en el caso de uso Alta de una LS lógica
 Igualmente se presenta una ventana modal para que el usuario confirme si desea establecer un
vínculo con el external partner que se había seleccionado
9.2.4.5. Editar un external partner LS lógico

Descripción: el usuario desea editar el registro de un external partner lógico, para lo cual se asume que
se encuentra en el listado de “Relaciones comerciales”.
Interfaz de usuario
Es la misma UI que se emplea para dar de alta un interlocutor en la UI de interlocutores externos.
Pasos
Los pasos son los mismos que los indicados en el caos de uso Editar una LS lógica

 Las mismas que las dadas en el caso de uso Editar una LS lógica
9.2.4.6. Vincular un external partner físico con una LS física

Descripción: el usuario desea vincular un external partner físico con una LS física, para lo cual se asume
que se encuentra en la UI de “Relaciones comerciales”.
Interfaz de usuario
Selección de un External partner físico con el
Pasos
1. El usuario clica en el botón de [Relación
comercial].
para hacer la selección.
3. El usuario selecciona el registro y clica en
[Ok] o da doble clic sobre el registro.
4. La aplicación desactiva la ventana modal y
hace una solicitud a servidor para guardar
la relación entre los dos interlocutores
petición, define un nuevo registro le asigna la
fecha de creación la de actualización y el tenantId
y da de alta la relación.
6. La aplicación presenta el listado actualizado
por lo cual se visualiza el registro del
external partner que se acaba de vincular
Flujos alternativos
al paso 6 y no se observa ningúna relación
nueva.

9.2.4.7. Vincular un external partner lógico en una relación LS – External

Partner
Descripción: el usuario desea vincular un external partner lógico bajo una relación entre una LS física y
un external partner físico, para lo cual se asume que se encuentra en la UI de “Relaciones comerciales”.
Interfaz de usuario
Selección de external partner lógico con el
Pasos
Los mismos que en el caso de uso Vincular una LS lógica a una LS física.
 Las mismas que en el caso de uso Vincular una LS lógica a una LS física.
9.2.4.8. Editar información de comunicaciones y contactos

Descripción: el usuario desea editar la información de comunicación y contactos vinculada a la relación
entre una LS física y un external partner físico, o simplemente la información de contactos de un
external partner lógico, para lo cual se asume que se encuentra en la UI de “Relaciones comerciales”.
Todas las funcionalidades vinculadas a este caso de uso, así como las funcionalidades de los casos de uso
derivados de este se pueden consultar en el caso de uso “Editar información de comunicaciones y
contactos” y sus derivados vinculados a “Estructura interna”.
9.2.4.9. Eliminar una relación comercial

Descripción: el usuario desea eliminar la relación comercial entre una LS física y un external partner
físico o una relación entre un external partner lógico y uno físico para bajo una LS física, para lo cual se
asume que se encuentra en la UI de “Relaciones comerciales”.
Interfaz de usuario
Pasos
1. El usuario selecciona el registro del
external partner físico o lógico con el cual
desde eliminar la relación, luego clica en
el botón de “Eliminar vínculo entre
interlocutores”
confirmación al usuario
3. El usuario confirma la operación
4. La aplicación lanza una solicitud a 5. El servicio de EdiPartnerRelationship recibe la
servidor para eliminar la relación. petición, verifica que el registro no tenga
dependencias y luego lo elimina.
indicando que se ha eliminado el registro
correctamente.
Flujos alternativos
operación alguna.
Paso 5: si el registro posee algún vínculo con algún
otro registro, en el Dto de retorno se informa de
ello.

Task DeleteRelation(DeleteRelationRequestDto input)
 Si el usuario solicita eliminar una relación comercial entre una LS física y un external partner
físico y existen relaciones con external partners lógicos dependientes de dicha relación,
servidor informa que no se puede eliminar por tener relaciones, por lo tanto primer sería
necesrio eliminar las relaciones con los external partner lógicos y luego la relación con el
external partner físico.
 Consultar las ETF para el caso de uso de “Eliminar” de los Maestros básicos simples” en el
documento “Casos de uso Maestros.docx”.
9.2.4.10. Mover a otro external partner físico

Descripción: el usuario desea vincular a un interlocutor físico uno o varios interlocutores lógicos
vinculados a otro interlocutor físico, para lo cual se asume que se encuentra en el listado de “Relaciones
comerciales”.
Este caso de uso posee la misma funcionalidad al caso de uso “Mover a otro interlocutor interno” de la
UI de “Estructura interna”
9.2.4.11. Búsqueda
Descripción: el usuario desea filtrar el listado realizando una búsqueda bajo un patrón de texto que
ingrese en la casilla de búsqueda, para lo cual se asume que se encuentra en el listado de “Relaciones
comerciales”.
Interfaz de usuario
Pasos
1. El usuario ingresa un texto en la casilla de
búsqueda
para obtener los registros que cumplan con
la búsqueda.
retorna un Dto con los registros filtrados
retornados
Flujos alternativos
Paso :

 El método que recibe las peticiones es:
Task<List<GetEdiPartnerForViewDto>> ExternalPartnersForLocalStations(GetPartnersInput input)
La consulta tiene como premisa que solo se retornan registros de interlocutores físicos que
tengan una relación con el interlocutor interno que este seleccionado en la UI. Se buscan los
registros de interlocutores físicos en los que el campo prnName o prnCode contenga el texto
ingresado, además si en la UI estaba seleccionado el check box de “Buscar en interlocutores
lógicos” se busca también el texto ingresado en los registros de los interlocutores lógicos, pero
es de tener en cuenta que solo se retornan registros de interlocutores físicos, por lo cual si se
encuentra un interlocutor lógico se busca el interlocutor físico al cual está vinculado y si aún no
estaba en el resultado de la consulta se incluye.
9.3. Mensajes
Dentro de los requerimientos del módulo de EDI se incluye la necesidad de monitorear los mensajes y
transmisiones que se hacen desde los partners internos hacia los externos y viceversa, así como la
posibilidad de realizar algunas operaciones específicas para dichos mensajes.
Dentro del ámbito EDI una transmisión puede incluir varios mensajes y cada transmisión incluye un
fichero .edi que será alojado en servidor en una carpeta específica dependiendo del partner del que
proceda o al que se vaya a enviar, la ruta y el nombre del fichero se guarda junto con otros datos de la
transmisión en su correspondiente registro. De la misma manera cada uno de los mensajes incluidos en
una transmisión se guardan en ficheros independientes que podrían estar o no en una misma ruta, la
información de la ruta y el nombre de cada fichero se guarda junto con el resto de datos de un mensaje.
Las transmisiones se realizan directamente entre partners físicos y los mensajes que contiene pueden
“provenir de un” y/o “ir dirigidos a un” partner lógico.
9.3.1. De entrada
9.3.1.1. Ingresar a la interfaz de mensajes

Descripción: el usuario desea ingresar a la interfaz de mensajes.
Interfaz de usuario
Pasos
1. El usuario selecciona del menú la opción
“Edi\Mensajes\De Entrada”
2. La aplicación hace una consulta para saber
con qué dominios puede interactuar el
usuario activo
3. El servicio de Partners recibe la petición la procesa
y retorna el listado de interlocutores internos con
los cuales puede interactuar según los vínculos
establecidos entre Usuarios y Roles y Partners y
Roles.
4. La aplicación recibe la respuesta y la vincula
al combo de selección de interlocutores
internos; verifica si hay algún interlocutor
activo de forma global y lo deja
seleccionado en el combo, de lo contrario
deja activo el primero del listado.
A partir de este punto la aplicación se

comporta como si el usuario hubiese
seleccionado un interlocutor, ver el siguiente
caso de uso
Flujos alternativos
Para el paso 4: si no hay interlocutores el
combo queda vacío, no se presenta
mensaje alguno.

 El método que recibe la petición de consulta es
9.3.1.2. Seleccionar un interlocutor para visualizar sus mensajes

Descripción: el usuario desea ver los mensajes vinculados a un interlocutor interno para lo cual se
asume que se encuentra en la interfaz de mensajes.
Interfaz de usuario
Pasos
1. El usuario selecciona del combo un
interlocutor interno.
La aplicación hace una petición a servidor
para obtener los mensajes.
2. El servicio correspondiente a los mensajes recibe
la petición, la procesa y retorna los N registros de
la primera página.
3. Se recibe la respuesta y se presenta el
listado.
4. El interlocutor seleccionado se deja como el
interlocutor activo de manera global en la
aplicación.
5. El usuario realiza un filtro sobre una
columna del grid, ingresa un texto a buscar
o hace un cambio de página
6. El servicio de mensajes recibe la petición, la
procesa y retorna los N registros de la página
solicitada
7. Se recibe la respuesta y se presenta en el
listado
Flujos alternativos
Para el paso 1: Si se han realizado
previamente modificaciones sobre la
configuración del grid (filtros, página,
agrupación) dichas configuraciones se
siguen asumiendo para la nueva consulta
del interlocutor seleccionado.
Para los pasos 3 y 7: si no hay registros se
presenta un texto, en la cultura activa,
indicando que no hay registros para
presentar

 Los campos a visualizar en el listado son:
Campo Texto Especificaciones

communicationStatusFk.code Estado Presentación de icono con color y
texto (según cultura) referente a cada
estado.
Agrupable.
sourceFk.name Remitente Agrupable
destinationFk.name Destino Agrupable
messageTypeFk.msgType Tipo Agrupable
messageFormatFk.msgFormat Formato Agrupable
documentTypeFk.docTypeName Tipo doc. Agrupable
sourceDate Fecha de
mensaje
(dd/mm/yyyy)
sourceDocument Identificativo del
mensaje
updateDate Actualización
reference1 Ref 1 Se visualizan 30 caracteres y se posee
un tooltip para presentar el
contenido completo del campo
reference2 Ref 2 Se visualizan 30 caracteres y se posee
un tooltip para presentar el
contenido completo del campo
id No visible
idMessage No visible
stationPartnerId No visible
 El elemento seleccionado del combo se debe incorporar a la instancia de GridSettings del
componente en su item state.filter.filters como condición de filtrado para la consulta de los
mensajes:
{ logic: 'and', filters: [{ field: "stationPartnerId", operator: "eq", value: comboItemSelected.id }] }
 De igual manera se debe incorporar a la instancia de GridSettings del componente en su item
state.filter.filters una condición de filtrado para acotar la consulta a aquellos mensajes cuyo
valor en el campo SourceDate no sea anterior a un año. Si es necesario modificar este rango de
fechas el usuario debe hacer dicho ajuste empleando el botón de [Selección de fechas]
 El método que recibe las peticiones de consulta de mensajes es:

Task<DataSourceResult> GetEdiInboundMessagesGrid([DataSourceRequest]DataSourceRequest request, string culture)
Este método retorna los registros que cumplan con la condición
EdiTransmissionFk.EdiDirectionFk.DirectionCode = “2”
9.3.1.3. Editar
selecciona un registro y clica en [Editar]. PENDIENTE.
Interfaz de usuario

mensaje de error.
si es del caso.
9.3.1.4. Eliminar
y ha seleccionado el registro (o los registros) a eliminar y clica en [Eliminar]. PENDIENTE.
Interfaz de usuario
Task<DeleteResponseDto> DeleteEdiMessages(DeleteRequestDto input)
En caso de eliminar una Local Station física, se elimina el registro vinculado en
9.3.1.5. Ver detalles

Descripción: el usuario desea visualizar los detalles de los mensajes, para lo cual se asume que se
encuentra en el listado.
Interfaz de usuario
Visualización del panel de dealles
Pasos
1. El usuario desliza el switch de detalles a la
derecha para activar el panel de “Detalles”.
2. La aplicación presenta el panel de
“Detalles” y según el botón seleccionado en
el panel obra en consecuencia
Flujos alternativos
Para el paso :

 La información que se visualiza en el panel de “Detalles” corresponde al último botón
seleccionado en dicho panel (no hay persistencia de esto ni para la aplicación ni para el
usuario).
 El botón de [Ver mensaje] es el botón activo por defecto en el panel de “Detalles” por lo cual si
al desplegar el panel no había antes un botón activo se asume dicha funcionalidad.
 El componente principal del panel es “detailsMessage.component.ts” el cual es reutilizado
cuando se presenta el panel de detalle del mensaje en una nueva pestaña del navegador
9.3.1.6. Ver mensaje

Descripción: el usuario desea ver el detalle de un mensaje, para lo cual se asume que está visualizando
un listado de mensajes y ha seleccionado el check de “Detalles”
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Ver datos
del mensaje]
2. La aplicación hace una petición a servidor 3. El servicio de Mensajes recibe la petición de
parar traer la información del mensaje visualización del registro, procesa la solicitud y
retorna un Dto con la información.
panel los datos del mensaje
Flujos alternativos
Para el paso :

 Información a presentar
Campo Texto
IdMessage Id
communicationStatusFk.code Estado
sourceFk.name Remitente
destinationFk.name Destino
messageTypeFk.msgType Tipo
messageFormatFk.msgFormat Formato
documentTypeFk.docTypeName Tipo doc.
sourceDate Fecha de mensaje (dd/mm/yyyy)
sourceDocument Identificativo del mensaje
reference1 Ref 1
reference2 Ref 2
Reference3 Ref 3
Reference4 Ref 4
Reference5 Ref 5
IdTransmisión Id transmisión
transmission.createDate Fecha de transmisión
transmission.updateDate Última actualización
transmission.SourceFk.Name Remitente de la transmición
transmission.DestinationFk.Name Destino de la transmisión
transmission.interchangeControlRef Control de referencia de intercambio
transmission.refrence Referencia
 El método que recibe la petición de visualziación es:
Task<GetEdiMessageForViewDetailsDto> GetEdiMessageForView (int Id)
El Dto de retorno incluy dos Dtos uno para la información del mensaje y otro para la información de la transmisión
vinculada
9.3.1.7. Ver fichero .edi del mensaje

Descripción: el usuario desea ver la información del fichero .edi vinculado al mensaje, para lo cual se
asume que está en el listado de mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Contenido del fichero edi formateado
Contenido del fichero edi sin formatear
Pasos
1. El usuario clica sobre el botón [Fichero .edi
del mensaje]
2. La aplicación presenta en la parte superior
del panel una barra con un check y un
botón
3. La aplicación hace una petición para
obtener el contenido del mensaje
4. El servicio de mensajes recibe la petición, lee el
fichero .edi y retorna su contenido a la aplicación
cliente
5. La aplicación presenta por defecto el
contenido del fichero .edi formateado, es
decir, habiendo cambiado el carácter
comilla “ ‘ “ por “ ‘ “ + retorno de carro
(“\n”)
Flujos alternativos
Para el paso 5: si el usuario clica en el check
“Fichero edi” o ya estaba seleccionado el
check, entonces se presenta el contenido
del fichero tal cual sin haberse formateado.

 Por defecto al dar clic sobre el botón de [Fichero .edi del mensaje] se asume que el check no
está seleccionado.
 El método que recibe la petición para leer el fichero .edi es
Task<EdiFileResponseDto> MessageEdi(int id)
 El método retorna
return new EdiFileResponseDto { ProcesOk = true, FileContent = content, FormatFileContent = formatContent };
Donde FileContent es el contenido del fichero como tal y FormatFileContent es el contenido del fichero formateado
 El nombre del fichero y la ruta que indica dónde se encuentra se obtienen de los campos
filePath y fileName del mensaje. El filepath es una ruta parcial que se debe concatener a la
derecha con la ruta especificada en la variable “EdiFilesPath” de “Adx” en “appsettings.json” la
cual es una carpeta general para guardar los ficheros .edi.
 En caso tal de que el fichero no exista se retorna
return new EdiFileResponseDto { ProcesOk = false, ErrorMsg = L("FileNotFound") };
9.3.1.7.1. Descargar fichero .edi del mensaje

Descripción: el usuario desea descargar el fichero .edi del mensaje, para lo cual se asume que está
visualizando en el panel de detalles del fichero .edi del mensaje.
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Descargar
edi]
2. La aplicación lanza la descarga del fichero
asumiendo que el contenido del mismo
debe ser lo que se esté visualizando en ese
momento, es decir, con el contenido del
fichero formateado o el contenido tal cual.
Flujos alternativos
Para el paso :

 El fichero descargado tiene el mismo nombre que se tenga especificado en el campo
“FileName” del mensaje, teniendo en cuenta que si se está visualizando el contenido
formateado se le pone el prefijo “Formated_”.
9.3.1.8. Ver fichero .edi de la transmisión
Descripción: el usuario desea ver el contenido del fichero .edi de la transmisión vinculada al mensaje,
para lo cual se asume que está en el listado de mensajes y se visualiza el panel de “Detalles”.
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Fichero .edi
de la transmisión]
del contenido del panel una barra con un
check y un botón
fichero .edi de la transmisión y retorna su
contenido a cliente
5. La aplicación presenta por defecto el
contenido del fichero .edi formateado, es
decir, habiendo cambiado el carácter
comilla “ ‘ “ por “ ‘ “ + retorno de carro
(“\n”)
Flujos alternativos
Para el paso 5: si el usuario clica en el check
“Fichero edi” o ya estaba seleccionado el
check, entonces se presenta el contenido
del fichero tal cual sin haberse formateado.

 Por defecto al dar clic sobre el botón de [Fichero .edi de la transmisión] se asume que el check
no está seleccionado.
Task<EdiFileResponseDto> TransmissionEdi(int id)
 El método retorna
return new EdiFileResponseDto { ProcesOk = true, FileContent = content, FormatFileContent = formatContent };
Donde FileContent es el contenido del fichero como tal y FormatFileContent es el contenido del fichero formateado
filePath y fileName de la transmisión vinculada al mensaje. El filepath es una ruta parcial que se
debe concatenar a la derecha con la ruta especificada en la variable “EdiFilesPath” de “Adx” en
“appsettings.json” la cual es una carpeta general para guardar los ficheros .edi.
 En caso tal de que el fichero no exista se retorna
return new EdiFileResponseDto { ProcesOk = false, ErrorMsg = L("FileNotFound") };
9.3.1.8.1. Descargar fichero .edi de la transmisión

Descripción: el usuario desea descargar el fichero .edi de la transmisión, para lo cual se asume que está
visualizando en el panel de detalles el fichero .edi de la transmisión.
Interfaz de usuario
Pasos
edi]
4. La aplicación lanza la descarga del fichero
asumiendo que el contenido del mismo
debe ser lo que se esté visualizando en ese
momento, es decir, con el contenido del
fichero formateado o el contenido tal cual.
Flujos alternativos
Para el paso :

 El fichero descargado tiene el mismo nombre que se tenga especificado en el campo
“FileName” de la transmisión, teniendo en cuenta que si se está visualizando el contenido
formateado se le pone el prefijo “Formated_”.
9.3.1.9. Ver documento

Descripción: el usuario desea ver el documento enviado en el mensaje para su posterior lectura o
descarga, para lo cual se asume que está en el listado de mensajes y está visualizando el panel de
“Detalles”.
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Ver
documento]
2. La aplicación hace una solicitud del
documento al servidor
3. El servicio de mensajes recibe la petición,
identifica el tipo de documento
(ediMessage.docTypeFk.docTypeName), luego
identifica la plantilla que debe aplicar a dicho
documento y genera el pdf y lo retorna a cliente
4. La aplicación presenta el documento en el
pdf viewer control.
Flujos alternativos
Para el paso :

 El método que recibe la petición para leer el documento del mensaje es
Task<EdiFileResponseDto> ReadPdfDocument(EdiFileRequestDto input)
 Para identificar la plantilla que se debe emplear para generar el pdf se tiene en cuenta lo
siguiente:
o En el mensaje el StationPartnerId es el partner al cual pertenece la transmisión y por
ende el mensaje (el seleccionado en el combo).
o En el mensaje el SourceId es el partner “lógico” del que procede el mensaje (un
partner Interno en caso de un mensaje de salida o externo en caso de un mensaje
entrante), y DestinationId el partner “lógico” al que va dirigido (un partner externo en
caso de un mensaje de salida o interno en caso de un mensaje entrante). Estos campos
pueden no tener información lo cual indicaría que es un mensaje entre los partners
especificados en la transmisión. Para tener más claridad en esta explicación los
llamaremos MsgSourceId y MsgDestinationId
o En la transmisión vinculada al mensaje el SourceId es el partner “físico” del que
procede el mensaje (un partner Interno en caso de un mensaje de salida o externo en
caso de un mensaje entrante),y DestinationId el partner “físico” al que va dirigido (un
partner externo en caso de un mensaje de salida o interno en caso de un mensaje
entrante). (Para tener más claridad en esta explicación los llamaremos TraSourceId y
TraDestinationId.
o Para el caso de los mensajes entrantes en relaciones comerciales debe existir un
registro que vincule LocalStationId = StationPartnerId, PartnerId = TraSourceId y
ParentPartnerId = null (donde se relaciona un partner interno físico con un partner
externo físico). Llamaremos este registro como “Relación entre físicos”.
Para el caso de los mensajes salientes en relaciones comerciales debe existir un

registro que vincule LocalStationId = StationPartnerId, PartnerId = TraDestinationId y
ParentPartnerId = null (donde se relaciona un partner interno físico con un partner
externo físico). Igualmente le llamaremos a este registro “Relación ente físicos”.
o Vinculado al registro de “Relación entre físicos” se poseen varios registros de

EdiDocumentExchangeInfo en los cuales se indican los tipos de documentos (campo
EdiDocumentTypeId) que se transmiten entre los partners y para cada documento se
especifica la plantilla que se debe emplear para presentar el documento del mensaje
(campo EdiPrintTemplateId).
o En cada mensaje el campo DocumentTypeId indica el tipo de documento transmitido,
por lo cual se debe seleccionar el registro de EdiDocumentExchangeInfo donde
EdiDocumentTypeId = DocumentTypeId (del mensaje) y asumir la plantilla
(EdiPrintTemplateId) indicada en dicho registro.
o En caso de no existir para el registro de “Relación entre físicos” un registro de
EdiDocumentExchangeInfo con el tipo de documento indicado en el mensaje, se debe
tener en “Estructura interna” un registro de EdiPartnerRelationship con:
Mensajes entrantes: LocalStationId = StationPartnerId, PartnerId = TraDestinationId y
ParentPartnerId = null; en este caso StationPartnerId = TraDestinationId.
Mensajes salientes: LocalStationId = StationPartnerId, PartnerId = TraSourceId y
ParentPartnerId = null; en este caso StationPartnerId = TraSourceId.
Este registro al igual que el de “Relación entre físicos” posee vinculados varios
registros de EdiDocumentExchangeInfo para indicar los tipos de documentos que
dicho partner interno físico puede intercambiar y donde se indica la plantilla a emplear
para presentar su documento, por lo cual se debe seleccionar el registro donde
EdiDocumentTypeId = DocumentTypeId (del mensaje) y asumir la plantilla
(EdiPrintTemplateId) indicada en dicho registro.
Si no se encuentra no es posible presentar el documento y se presenta al usuario un
mensaje indicando el suceso.
o as
 Una vez identificada la plantilla a emplear se procede a leer la información del mensaje y a
generar el pdf según el tipo de mensaje, esto quiere decir que para cada tipo de mensaje hay
una implementación diferente debido a la información implicada y al proceso específico que se
debe seguir en cada caso.
9.3.1.10. Ver log de comunicaciones

Descripción: el usuario desea ver el log de comunicaciones vinculado al mensaje, para lo cual se asume
que está en el listado de mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Log]
2. La aplicación hace una solicitud del log al
servidor
3. El servicio de mensajes recibe la petición y hace
una solicitud del log a una api externa, espera
respuesta y luego retorna dicha respuesta a cliente
4. La aplicación presenta la respuesta tal cual
en el panel de detalles.
Flujos alternativos
Para el paso :

 El método que recibe la petición del log es
Task<EdiFileResponseDto> MessageLog(EdiFileRequestDto input)
 En caso tal de que se presente un fallo en la petición a la api o cualquier otro inconveniente
inesperado se lanza una UserFriendlyExcepción con una descripción en la cultura activa para
informar del suceso
9.3.1.11. Ver en un nuevo Tab del navegador

Descripción: el usuario desea ver el panel de detalles en otra pestaña del navegador con el fin de
disponer de un espacio más amplio para ver información, para ello se asume que está en el listado de
mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Abrir en un
nuevo tab del navegador]
2. La aplicación abre una nueva pestaña en el 3. El servicio de Mensajes recibe la petición de
navegador para presentar una página que visualización del registro, procesa la solicitud y
muestra el mismo contenido del panel de retorna un Dto con la información.
detalles dentro del marco de la aplicación.
4. Se recibe la respuesta y se presentan los
datos del mensaje
Flujos alternativos
Para el paso 4: si el usuario clica en el botón
de [Cerrar] se pasa al listado de mensajes.

 La aplicación responde tal como si se hubiese acabado de activar el panel de “ver detalles”
9.3.2. De salida
9.3.2.1. Ingresar a la interfaz de mensajes

Descripción: el usuario desea ingresar a la interfaz de mensajes de salida.
Interfaz de usuario
Pasos
Idem al mismo caso de uso de los mensajes de entrada.

 La ruta de menú es “Edi\Mensajes\De salida”.
 El método que recibe la petición de consulta es
9.3.2.2. Seleccionar un interlocutor para visualizar sus mensajes

Descripción: el usuario desea ver los mensajes vinculados a un interlocutor interno para lo cual se
asume que se encuentra en la interfaz de mensajes.
Interfaz de usuario
La misma empleada en “seleccionar un interlocutor para visualizar sus mensajes” para Mensajes de
entrada
Pasos
Idem al mismo caso de uso de los mensajes de entrada.

 Los campos a presentar en el listado son los indicados en el mismo caso de uso de los mensajes
de entrada
 El elemento seleccionado del combo se debe incorporar a la instancia de GridSettings del
componente en su item state.filter.filters como condición de filtrado para la consulta de los
mensajes:
{ logic: 'and', filters: [{ field: "stationPartnerId", operator: "eq", value: comboItemSelected.id }]
 De igual manera se debe incorporar a la instancia de GridSettings del componente en su item
state.filter.filters una condición de filtrado para acotar la consulta a aquellos mensajes cuyo
valor en el campo CreationDate no sea anterior a un año. Si es necesario modificar este rango
de fecha el usuario debe hacer dicho ajuste empleando el botón de [Rango de fechas]
 El método que recibe las peticiones de consulta de mensajes es:
Task<DataSourceResult> GetEdiOutboundMessagesGrid([DataSourceRequest]DataSourceRequest request, string
culture)
Este método retorna los registros que cumplan con la condición
EdiTransmissionFk.EdiDirectionFk.DirectionCode = “1”
9.3.2.3. Editar
selecciona un registro y clica en [Editar]. PENDIENTE.
Interfaz de usuario

mensaje de error.
si es del caso.
9.3.2.4. Eliminar
y ha seleccionado el registro (o los registros) a eliminar y clica en [Eliminar]. PENDIENTE.
Interfaz de usuario

Task<DeleteResponseDto> DeleteEdiMessages(DeleteRequestDto input)
En caso de eliminar una Local Station física, se elimina el registro vinculado en
9.3.2.5. Ver detalles
Descripción: el usuario desea visualizar los detalles de los mensajes, para lo cual se asume que se
encuentra en el listado.
Interfaz de usuario
Pasos
1. El usuario selecciona el check de “Detalles”.
2. La aplicación presenta el panel de
“Detalles” y según el botón seleccionado en
el panel obra en consecuencia
Flujos alternativos
Para el paso :

 La información que se visualiza en el panel de “Detalles” corresponde al último botón
seleccionado en dicho panel (no hay persistencia de la selección ni para la aplicación ni para el
usuario).
 El botón de [Ver mensaje] es el botón activo por defecto en el panel de “Detalles” por lo cual si
al desplegar el panel no había antes un botón activo se asume dicha funcionalidad.
9.3.2.6. Ver mensaje

Descripción: el usuario desea ver el detalle de un mensaje, para lo cual se asume que está visualizando
un listado de mensajes y ha seleccionado el check de “Detalles”
Interfaz de usuario
Pasos
mensaje]
2. La aplicación hace una petición a servidor 3. El servicio de Mensajes recibe la petición de
parar traer la información del mensaje edición del registro, proceso la solicitud y retorna
el registro a editar
panel los datos del mensaje
Flujos alternativos
Para el paso :

 Información a presentar

Campo Texto
IdMessage Id
communicationStatusFk.code Estado
sourceFk.name Remitente
destinationFk.name Destino
messageTypeFk.msgType Tipo
messageFormatFk.msgFormat Formato
documentTypeFk.docTypeName Tipo doc.
sourceDate Fecha de mensaje (dd/mm/yyyy)
sourceDocument Identificativo del mensaje
reference1 Ref 1
reference2 Ref 2
Reference3 Ref 3
Reference4 Ref 4
Reference5 Ref 5
IdTransmisión Id transmisión
transmissionFk.createDate Fecha de transmisión
transmissionFk.updateDate Última actualización
transmissionFk.SourceFk.Name Remitente de la transmición
transmissionFk.DestinationFk.Name Destino de la transmisión
transmissionFk.interchangeControlRef Control de referencia de intercambio
transmissionFk.refrence Referencia
 El método que recibe la petición de edición es:

Task<DeleteResponseDto> CretaeOrEditTk (DeleteRequestDto input)

9.3.2.7. Ver contenido del mensaje

Descripción: el usuario desea ver el contenido como tal del mensaje, para lo cual se asume que está en
el listado de mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Pasos
contenido del mensaje]
del contenido panel una barra con un check
y un botón
cliente
5. La aplicación presenta el contenido tal cual
lo ha recibido.
Flujos alternativos
Para el paso :

 Por defecto al dar clic sobre el botón de [Ver contenido del mensaje] se asume que el check no
está seleccionado.
Task<EdiFileResponseDto> ReadEdiFile(EdiFileRequestDto input)
Donde EdiFileRequestDto.messageOrTransmission = “M”
filePath y fileName del mensaje.
 En caso tal de que se presente un fallo en la lectura del fichero se lanza una
UserFriendlyExcepción con una descripción en la cultura activa para informar del suceso

9.3.2.7.1. Formatear contenido

Descripción: el usuario desea ver el contenido del mensaje pero incluyendo una formateo del salto de
línea (retorno de carro) para una mejor lectura.
Interfaz de usuario
Pasos
1. El usuario selecciona el check de
[Format]
2. La aplicación obtiene una transformación
del contenido del fichero y la presenta en el
panel.
Flujos alternativos
Para el paso 2: si el usuario deselecciona el
check el contenido del mensaje se presenta
nuevamente tal cual lo ha retornado
servidor, es decir, sin la transformación.

 La transformación del contenido del fichero consiste en reemplazar las comillas simples por
comilla simple + salto de línea.
9.3.2.7.2. Descargar contenido

Descripción: el usuario desea descargar el contenido del mensaje, para lo cual se asume que está
visualizando el contenido de un mensaje.
Interfaz de usuario
Pasos
edi]
para descargar el fichero edi
identifica el fichero solicitado y al terminar envía
una notificación al usuario con un enlace para
descargar el fichero.
4. La aplicación cliente presenta un mensaje al
usuario indicando que recibirá una
notificación con un enlace para descargar el
fichero
Flujos alternativos
Para el paso 2: si el check de “Format” está
seleccionado se genera un fichero con
dicha transformación en cliente y se
descarga.


9.3.2.8. Ver contenido de la transmisión

Descripción: el usuario desea ver el contenido como tal de la transmisión, para lo cual se asume que
está en el listado de mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Pasos
contenido de la transmisión]
del contenido del panel una barra con un
check y un botón
cliente
5. La aplicación presenta el contenido tal cual
lo ha recibido.
Flujos alternativos
Para el paso :

 Por defecto al dar clic sobre el botón de [Ver contenido de la transmisión] se asume que el
check no está seleccionado.
Task<EdiFileResponseDto> ReadEdiFile(EdiFileRequestDto input)
Donde EdiFileRequestDto.messageOrTransmission = “T”

9.3.2.8.1. Formatear contenido

Descripción: el usuario desea ver el contenido de la transmisión pero incluyendo una formateo del
salto de línea (retorno de carro) para una mejor lectura.
Interfaz de usuario
Pasos
1. El usuario selecciona el check de
[Format]
2. La aplicación obtiene una transformación
del contenido del fichero y la presenta en el
panel.
Flujos alternativos
Para el paso 2: si el usuario deselecciona el
check, el contenido de la transmisión se
presenta nuevamente tal cual lo ha
retornado servidor, es decir, sin la
transformación.

 La transformación del contenido del fichero consiste en reemplazar las comillas simples por
comilla simple + salto de línea.
9.3.2.8.2. Descargar contenido

Descripción: el usuario desea descargar el contenido de la transmisión, para lo cual se asume que está
visualizando su contenido.
Interfaz de usuario
Pasos
edi]
para descargar el fichero edi
identifica el fichero solicitado y al terminar envía
una notificación al usuario con un enlace para
descargar el fichero.
4. La aplicación cliente presenta un mensaje al
usuario indicando que recibirá una
notificación con un enlace para descargar el
fichero
Flujos alternativos
Para el paso 2: si el check de “Format” está
seleccionado se genera un fichero con
dicha transformación en cliente y se
descarga.


9.3.2.9. Ver documento

Descripción: el usuario desea ver el documento enviado en el mensaje para su posterior lectura o
descarga, para lo cual se asume que está en el listado de mensajes y está visualizando el panel de
“Detalles”.
Interfaz de usuario
Pasos
documento]
2. La aplicación hace una solicitud del
documento al servidor
identifica el tipo de documento
(ediMessage.docTypeFk.docTypeName), luego
identifica la plantilla que debe aplicar a dicho
documento y genera el pdf y lo retorna a cliente
4. La aplicación presenta el documento en el
pdf viewer control.
Flujos alternativos
Para el paso :

 El método que recibe la petición para leer el documento del mensaje es
Task<EdiFileResponseDto> ReadPdfDocument(EdiFileRequestDto input)
 Para identificar la plantilla que se debe emplear para generar el pdf, se busca la plantilla
indicada en EdiDocumentExchangeInfo para el DocumentType dado en el mensaje, donde el
registro de EdiDocumentExchangeInfo debe estar vinculado a un registro de
EdiPartnerRelationship así: Local stationId = transmissionFk.StationPartnerId y PartnerId =
transmissionFk.SourceId y parentId = null; si para esta relación no hay registrada una plantilla
para el tipo de documento del mensaje entonces se busca el registro donde Local stationId =
transmissionFk.StationPartnerId y PartnerId = transmissionFk. StationPartnerId y parentId =
null. Si no se encuentra ninguno de los dos registros de relación indicados o no se encuentra en
ninguno una plantilla para generar el pdf se lanza una UserFriendlyException.

9.3.2.10. Ver log de comunicaciones

Descripción: el usuario desea ver el log de comunicaciones vinculado al mensaje, para lo cual se asume
que está en el listado de mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Pasos
1. El usuario clica sobre el botón [Log]
2. La aplicación hace una solicitud del log al
servidor
3. El servicio de mensajes recibe la petición y hace
una solicitud del log a una api externa, espera
respuesta y luego retorna dicha respuesta a cliente
4. La aplicación presenta la respuesta tal cual
en el panel de detalles.
Flujos alternativos
Para el paso :

Task<EdiFileResponseDto> MessageLog(EdiFileRequestDto input)
informar del suceso

9.3.2.11. Ver en otra pestaña del navegador
Descripción: el usuario desea ver el panel de detalles en otra pestaña del navegador, para lo cual se
asume que está en el listado de mensajes y está visualizando el panel de “Detalles”.
Interfaz de usuario
Pasos
5. El usuario clica sobre el botón [*Tab]
6. La aplicación abre una nueva pestaña en el 7. El servicio de Mensajes recibe la petición de
navegador para presentar una página que visualización del registro, procesa la solicitud y
muestra el mismo contenido del panel de retorna un Dto con la información.
detalles dentro del marco de la aplicación.
8. Se recibe la respuesta y se presentan los
datos del mensaje
Flujos alternativos
Para el paso :

 Task<DeleteResponseDto> ViewDetailsTk (DeleteRequestDto input)
informar del suceso
10. Resúmenes Edi para el dashboard
El dashboard a presentar para el módulo de Edi cuenta con dos filtros generales que son:
 La Local Station para la cual se desea observar la estadística; si no hay ninguna activa se asume
la primera según las disponibles para el usuario activo en la aplicación
 El rango de fechas entre el cual se desea hacer el resumen. Este rango se aplica sobre el campo
UpdateDate tanto para las transmisiones como para los mensajes. Por defecto se asume que el
rango está entre: [El día 1 dos meses previos - La fecha actual], lo cual daría máximo tres
meses. Este rango puede ser modificado por el usuario según sus requerimientos.
La modificación de cualquiera de estos dos filtros implica lanzar de nuevo las consultas para actualizar
todos los resultados estadísticos y cualquier filtro específico de un resultado que se haya seleccionado
será eliminado.
Se cuenta con dos Dto’s para hacer todas las consultas uno para hacer la petición y otro para la
respuesta:
 EdiDashboardRequestDto: siempre debe especificar la Local station para la cual se hace la

petición y el rango de fechas. Para las estadísticas de un partner se debe informar el Id de dicho
partner o el nombre. Más adelante se detallan los campos implicados en cada consulta. En el
código está documentado cada campo.
 EdiDashboardResponseDto: es un único Dto que posee campos para todos los posibles
resultados, por lo cual dependiendo de la consulta realizada se informan unos campos u otros.
Más adelante se detallan los campos implicados en cada consulta. En el código está
documentado cada campo.
Los resúmenes a presentar son los siguientes:
10.1. Estadísticas generales de mensajes y transmisiones

Estadística donde se presentan la cantidad de transmisiones y de mensajes categorizados en entrantes y
salientes con su correspondiente porcentaje.
Método empleado: ediDashboardInfoTotales(request):
Dto EdiDashboardRequestDto de la petición
Campo Valor
LocalStationId Id de la Local station para la cual se desea el resumen. Para el
caso de la primera petición al ingresar a la aplicación, la Local
station es 0 y servidor tomará una Local Station disponible
para el usuario activo.
FechaInicial Primer día del rango para el cual se desea la consulta
FechaFinal Último día del rango parar el cual se desea la consulta
Dto EdiDashboardResponseDto de la respuesta
Campo Valor
LocalStationId Id de la Local station para la cual se hizo la consulta
InboundColor Color identificativo de los mensajes de entrada
OutboundColor Color identificativo de los mensajes de salida
TotInboundMsgs Total de mensajes de entrada
TotOutboundMsgs Total de mensajes de salida
TotInboundTran Total de transmisiones de entrada
TotOutboundTran Total de transmisiones de salida
Ilustración del resumen
10.2. Estadísticas de mensajes y transmisiones clasificadas por fechas

En esta categoría se presentan dos gráficas de líneas una de mensajes y otra de transmisiones.
Se puede hacer selección para ver los resultados detallados al día, a la semana o al mes.
Método empleado: ediDashboardInfoFechasTotales (request):
Campo Valor
IntervaloPorFecha Valores posibles [D | S | M] según si la consulta se desea
resumida por días, semanas o meses.
Campo Valor
TotInboundTran Total de transmisiones de entrada
TotOutboundTran Total de transmisiones de salida
InboundMsg Es el listado por fechas de los mensajes de entrada.
List/Array de tipo StatisticalResultDto donde “Description” es
el dato de la fecha y “Value” la cifra de la cantidad de
mensajes para dicha fecha.
OutboundMsg Es el listado por fechas de los mensajes de salida.
mensajes para dicha fecha.
InboundTran Es el listado por fechas de las transmisiones de entrada.
transmisiones para dicha fecha.
OutboundTran Es el listado por fechas de las transmisiones de salida.
transmisiones para dicha fecha.
GRAFICA DE LINEAS PARA LOS MENSAJES
GRAFICA DE LINEAS PARA LAS TRANSMIONES
10.3. Estadísticas de mensajes clasificados por tipo de mensaje

Presenta dos secciones una para los mensajes de entrada y otra para los mensajes de salida.
En cada sección se presenta una gráfica circular indicando el porcentaje correspondiente a cada tipo de
mensaje y en las etiquetas se muestra el texto identificativo de cada porción acompañado de la cantidad
de mensajes.
Método empleado: “ediDashboardInfoMsgTypeTotales(requestDto)”
Campo Valor
Campo Valor
InboundMsgsForType Es el listado por tipo de los mensajes entrada.
el tipo de mensaje y “Value” la cifra de la cantidad de
mensajes para dicho tipo.
OutboundMsgsForType Es el listado por tipo de los mensajes de salida.
10.4. Estadísticas de mensajes enviados y recibidos por cada partner

Presenta una tabla/gráfica donde se visualiza para cada partner el total de mensajes de entrada y salida.
Solo se presenta el top ten, es decir los 10 partners con más volumen de mensajes (sumados los dos
tipos de mensajes).
Método empleado: “ediDashboardInfoPartnersTotales (requestDto)”
Campo Valor
Campo Valor
ExternalPartnerInfo Es el listado con la información de cada partner
List/Array de tipo ExternalPartnerInfo, el detalle se presenta
en la siguiente tabla
ExternalPartnerInfo
Campo Valor
PartnerName Nombre del Partner (EdiPartner.PrnName)
PartnerId Id del Partner (EdiPartner.Id)
TotInboundMsgs Total de mensajes de entrada para el partner
TotOutboundMsgs Total de mensajes de salida para el partner
InboundMsgsForType Atención: Solo se informa para el primer partner
Es el listado por tipo de los mensajes entrada para el partner.
OutboundMsgsForType Atención: Solo se informa para el primer partner
Es el listado por tipo de los mensajes de salida para el partner
10.5. Estadísticas de mensajes enviados y recibidos vinculados a un partner

clasificados por tipo de mensaje
Presenta dos secciones una para los mensajes de entrada y otra para los mensajes de salida.
En cada sección se presenta una gráfica circular indicando el porcentaje correspondiente a cada tipo de
mensaje y en las etiquetas se muestra el texto identificativo de cada porción acompañado de la cantidad
de mensajes.
El usuario puede seleccionar el partner para el cual desea ver las estadísticas
Método empleado: “ediDashboardInfoPartnersMsgTypesTotales (requestDto)”
Campo Valor
ExternalPartnerId Id (EdiPartners.Id) del partner del cual se desea realizar la
consulta
ExternalPartnerName Name (EdiPartners.PrnName) del partner del cual se desea
realizar la consulta
Nota: para especificar el partner a consultar solo se requiere informar o ExternalPartnerId o
ExternalPartnerName.
Campo Valor
ExternalPartnerInfo Es un listado con un solo elemento con la información del
partner consultado.
List/Array de tipo ExternalPartnerInfo, el detalle se presenta
en la siguiente tabla
ExternalPartnerInfo
Campo Valor
PartnerName Nombre del Partner (EdiPartner.PrnName)
PartnerId Id del Partner (EdiPartner.Id)
TotInboundMsgs Total de mensajes de entrada para el partner
TotOutboundMsgs Total de mensajes de salida para el partner
InboundMsgsForType Es el listado por tipo de los mensajes entrada para el partner.
OutboundMsgsForType Es el listado por tipo de los mensajes de salida para el partner

11. Requerimientos adicionales de desarrollo
12. Puesta en escena del módulo

Para la puesta en marcha del módulo se siguen los siguientes pasos
 Insertar los registros por defecto en las tablas de, ya sea por la instalación de la aplicación o con
el empleo de scripts.
o EdiPartnerType,
o EdiCommunicationMethods,
o EdiCommunicationStatus,
o EdiDirection,
o EdiMessageFormat
o EdiPackagingType (Culture)
 Dar de alta los roles que sean necesarios, por ejemplo:
o Role con control a todo EDI, incluyendo Variants
o Role con control solo a interlocutores internos, incluyendo Variants
o Role con control solo a interlocutores externos, incluyendo Variants
 Dar de alta los usuarios y asignarles los roles, si ya existen los usuarios solo asignarles los roles.
 Dar de alta registros de los maestros:
o EdiCommunicationTypes
o EdiDocumentType
o EdiPrintTemplates
o EdiMessageType
 Al dar de alta registros de Interlocutores internos, para los físicos vincular roles de Admin,
EdiAdminTotal (con acceso a todo Edi), EdiInternal (rol con acceso solo a interlocutores
internos y estructura interna), EdiExternal (rol con acceso solo a interlocutores externos y
relaciones comerciales)
Agregar o vincular cualquier otro rol que sea necesario.
 Dar de alta registros de interlocutores externos tanto físicos como lógicos.
 Definir la estructura interna de interlocutores
 En estructura interna editar la información de “Comunicaciones y contactos” para cada
interlocutor físico (registros principales del grid), e ingresar la información referente a
“Métodos de comunicación” y “Tipos de documentos y plantillas”.
 Definir las relaciones comerciales necesarias para permitir las transmisiones de ficheros
requeridas para la instalación.
 En relaciones comerciales editar la información de “Comunicaciones y contactos” para cada
interlocutor externo físico (registros principales del grid), e ingresar la información referente a
“Métodos de comunicación” y “Tipos de documentos y plantillas”; en caso de no especificar
esta información la configuración especificada para la local station en la estructura interna será
la que indique como presentar los documentos y la que fije las pautas en los procesos de
intercambio.

Modulo EDI

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

Modulo EDI

Cargado por

Copyright:

Formatos disponibles

Módulo EDI

Electronic Data Interchange

3.1. Requerimientos para la persistencia de información

3.2. Requerimientos específicos de UI

Desarrollo en: aspNet Core

Aplicación instalada en IIS

Desarrollo en: Angular

Navegador Web: Crome, FireFox, IExplorer

TemplateScheme EdiDirection EdiCommunicationStatus

TenantId EdiContactRoles UpdateDate UpdateDate

UpdateDate Transmiss ionId

PrnPos talCode EdiLocalStationRoles

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro Listado Add/Up

PtypActive PtypCode DescriptionKey PtypCommunication PtypCategory

Existen partners internos, denominados “estaciones locales” y “partners externos” simplemente

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

PrnCode* Nvarchar[35] Código asignado al partner X X X

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

LocalStationId => es la local station física

PartnerId => es la local station física

En una relación entre Estaciones locales (Física y Lógica) se asigna lo siguiente:

LocalStationId => es la local station física

PartnerId => es la local station lógica

ParentPartnerId=> es la local station física

LocalStationId => es la local station física

PartnerId => es el partner físico

LocalStationId => es la local station física

PartnerId => es el partner lógico

ParentPartnerId=> es el partner físico

Nota 2: cuidado al hacer el update-database, posiblemente solicite modificar la acción en el OnDelete

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

 Unique indexs: UIDX_DocEx_RelationDocType

Es un maestro abierto, sin gestión de cultura.

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

Falta definir el campo TemplateScheme

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

DirectionDescription* Nvarchar[12] Descripción. (es key de recurso)

 Unique indexs: UIDX_Ptemplate_DtypeName

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

 Unique indexs: UIDX_

Es un maestro “abierto” con cultura para el campo RolDescription.

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

 Unique indexs: UIDX_

Es un maestro “abierto” con cultura para el campo CtionTypeDescription.

Datos de la entidad Valor

Propiedad Tipo + longitud Descripción Filtro av. Listado Add/Up

es-ES en-US it-IT fr-FR de-DE