Afiliação de opções binárias Mato Grosso do Sul: Hierarquia de usuários do sistema de negociação

Hierarquia Geográfica.

Este capítulo descreve a administração da Hierarquia Geográfica, para estabelecer informações geográficas mestras para validação de endereços e outros propósitos.

Este capítulo abrange os seguintes tópicos:

Visão geral da hierarquia de geografia.

Hierarquia de Geografia é um modelo de dados que permite estabelecer relações conceituais pai-filho entre as geografias. Uma geografia, como Tóquio ou Peru, descreve um limite na superfície da Terra. Os aplicativos podem extrapolar informações com base nessa rede de relacionamentos geográficos hierárquicos.

Por exemplo, na Geography Hierarchy, o estado da Califórnia é definido como o pai do condado de San Mateo, que é o pai de Redwood City, que é o pai do código postal 94065. Se você inserir apenas 94065, o aplicativo pode determinar que o código postal é na Califórnia, ou que a cidade correspondente é Redwood City.

O Oracle Trading Community Architecture (TCA) e outros aplicativos do Oracle E-Business Suite podem alavancar a Geography Hierarchy para vários usos relacionados a locais, como validação de endereço em tempo real e cálculo de impostos. As informações geográficas estão localizadas centralmente no TCA e compartilhadas entre todos os aplicativos.

Nota: O TCA não fornece informações geográficas, mas o modelo de dados e recursos para configurar e armazenar essas informações.

Conceitos e Definições.

O nível superior da hierarquia de geografia é País, portanto, a hierarquia contém essencialmente países e suas geografias filho. Outros aspectos da hierarquia da geografia incluem:

Tipo de Geografia: Um agrupamento de regiões geográficas (por exemplo, Cidade, Província e Distrito) ou físicas (por exemplo, Ilha, Montanha e Continente).

Geografia: um espaço físico com limites que é uma instância definida de um tipo de geografia. Por exemplo, San Jose é uma geografia do tipo geografia da cidade.

Estrutura do país: um agrupamento hierárquico de tipos de geografia para um país. Por exemplo, a estrutura para os Estados Unidos é: Estado, Condado, Cidade e depois Código Postal.

Uso de Geografia: Uma classificação de um conjunto de tipos de geografia para indicar a finalidade e o uso desses dados, por exemplo, para tributação. Por exemplo, os tipos de geografia Estado, Condado e Cidade podem ser usados para calcular o imposto sobre vendas nos EUA.

Hierarquia de Geografia de Referência Mestre: Os dados da Hierarquia de Geografia considerados como a única fonte de verdade. São todos os dados, incluindo os tipos de geografia e as geografias, que você define e mantém na administração da Hierarquia Geográfica do TCA.

O uso de geografia para toda a hierarquia é Referência mestre e os tipos e geografias geográficos definidos são considerados geografia e tipos de geografia de referência mestre. Por exemplo, o País é um tipo de geografia universalmente reconhecido e os Estados Unidos são considerados uma geografia mestra.

Dados de hierarquia de referência mestre A geografia é usada como a origem para validar endereços e para criar hierarquias geográficas definidas pelo usuário, que incluem limites ou zonas, para usos específicos de negócios. Portanto, embora a hierarquia de referência geográfica seja a fonte de verdade para dados geográficos, por exemplo, com todos os estados dos EUA definidos, as hierarquias geográficas definidas pelo usuário contêm entidades com limites arbitrários, ou seja, zonas fiscais que abrangem vários estados dos EUA em cada zona.

Hierarquia de Geografia Definida pelo Usuário: Uma classificação de dados geográficos, criada a partir dos dados de referência mestre ou inseridos manualmente, para fins tributários. Uma hierarquia geográfica definida pelo usuário pode ter:

Zonas: limites geográficos definidos pelo usuário para o uso de geografia específico, com base nos dados da hierarquia de referência mestre da geografia. Por exemplo, um uso de geografia de impostos pode ter a zona de impostos de San Jose e um uso de geografia de vendas na região da região de vendas do sudoeste. Os limites da zona da Região de Vendas do Sudoeste incluiriam vários estados de referência principais, por exemplo, Califórnia, Arizona, Nevada, Utah e Novo México.

Tipo de zona: uma camada ou um agrupamento de zonas, por exemplo, os tipos de zona Imposto de renda e Regiões de vendas. O tipo de zona Regiões de Vendas conteria zonas como Região de Vendas Sudoeste, Região de Vendas Centro-Oeste e assim por diante.

Geography Name Referencing é o processo de validação e mapeamento de elementos de endereço de registros existentes da tabela de localização em relação às regiões geográficas de referência mestre. Por exemplo, para um registro de endereço específico, o valor de CA na coluna STATE da tabela HZ_LOCATIONS é mapeado para a geografia de referência principal da CA.

Administrando a hierarquia de geografia.

Configure e mantenha a Hierarquia Geográfica de Referência Mestre, que pode:

Ser usado em todo o Oracle E-Business Suite para várias finalidades e tarefas relacionadas a locais, por exemplo, validação de endereço.

Forneça a estrutura subjacente a partir da qual os administradores criam zonas de impostos para hierarquias geográficas definidas pelo usuário.

Nota: Você executa tarefas de configuração para hierarquias geográficas definidas pelo usuário fora da administração da Hierarquia Geográfica. Para criar e atualizar zonas de imposto e tipos de zona, use o Oracle E-Business Tax.

Na página Hierarquia de Geografia: Países, você pode acessar os vários recursos para administrar cada país na Hierarquia de Geografia de Referência Mestre. A lista original dos países disponíveis vem da tabela FND_TERRITORIES. Depois de definir inicialmente a hierarquia de um país, você pode continuar a mantê-lo usando a mesma funcionalidade de administração.

Pré-requisitos

Opcionalmente, use as pesquisas Recebíveis para adicionar e gerenciar os tipos de código e os provedores de dados disponíveis para definir as regiões. Esta tabela mostra os tipos de pesquisa.

Consulte: Definindo Pesquisas de Recebíveis, Guia de Implementação de Contas a Receber do Oracle.

Processo de Administração.

Defina estruturas de país de tipos de geografia para estabelecer como as geografias do país estão relacionadas hierarquicamente.

Crie tipos de geografia conforme necessário.

Importante: você deve definir a estrutura do país antes de definir geografias específicas para um tipo de geografia dentro dessa estrutura. Você deve definir uma estrutura de país completa e precisa na primeira vez, porque não é possível inserir novos níveis entre os níveis existentes após as geografias estarem definidas. Você pode adicionar novos níveis abaixo do nível mais baixo em uma estrutura.

Por exemplo, você deseja usar a hierarquia de geografia para validação de endereço dos Estados Unidos. Para a estrutura do país dos EUA, você define o tipo de geografia País como pai de Estado, Estado como pai do Condado, Condado como pai da Cidade e Cidade como pai do Código Postal.

Visualize e defina a lista de geografias para um tipo de geografia específico na estrutura do país. Veja: Visualizando e Definindo Geografias.

Por exemplo, para os Estados Unidos, você define primeiro todos os estados para o tipo de geografia do estado, os municípios em cada estado, as cidades de cada município e os códigos postais de cada cidade.

Para cada geografia na lista, você também pode clicar em Atualizar para inserir detalhes adicionais.

Dica: O acesso aos Detalhes da vista (para a lista de geografias) e a Atualização correspondente (para informações específicas de uma geografia) estão disponíveis de maneira hierárquica, com base na estrutura do seu país. Em cada página Detalhes da vista, você pode acessar a lista de geografias para o tipo de geografia um nível abaixo.

Por exemplo, quando você clica em Exibir Detalhes para Estados Unidos na página Geografia de Hierarquia: Países, você obtém uma lista de estados dentro dos EUA. Para cada estado, você pode clicar em Visualizar Detalhes para obter a lista de municípios dentro desse estado ou clicar em Atualizar para esse estado. Então, se você quiser atualizar informações para Redwood City, o caminho de navegação é: View Details for United States & gt; Ver detalhes para California & gt; Ver detalhes para San Mateo & gt; Atualização para Redwood City.

Atualização: mantenha informações específicas de uma geografia. Veja: Atualizando Geografias.

Por exemplo, enquanto você define um estado específico nos EUA, pode inserir nomes ou códigos alternativos para esse estado.

Gerenciar as validações: especifique os estilos de endereço e nível de validação da geografia no nível do país e mapeie os tipos de geografia nas estruturas dos países para os atributos da tabela de locais para fins de validação de endereço ou de imposto. Veja: Gerenciando Validações.

Execute o processo de referência de nome geográfico para mapear endereços em tabelas de localização para dominar as geografias de referência. Esse mapeamento é usado para cálculo de impostos. Veja: Processo de Referência de Geografia.

Dica: defina estas opções de perfil relacionadas:

HZ: Tamanho do lote para confirmar registros no processo de referência de nome geográfico.

HZ: Número de trabalhadores para uma determinada solicitação de referência de nome geográfico.

Importante: Se você também estiver usando a formatação de endereço flexível e tiver um estilo de endereço atribuído ao país que está administrando, verifique se a configuração da hierarquia de Geografia está consistente.

Consulte: Formatação de Endereço, Guia do Usuário da Oracle Community Community Architecture.

Definindo Estruturas de Países.

Para o país selecionado, defina a estrutura hierárquica dos tipos de geografia para estabelecer:

Como as geografias podem ser relacionadas.

Os tipos de geografias que você pode definir para esse país.

Os tipos de geografia disponíveis para geografia ou validação de impostos.

Com o tipo de geografia do país implicitamente no topo da estrutura, os níveis subseqüentes são numerados com 1 como o próximo nível após o país.

Cuidado: Depois de definir primeiro uma estrutura de país, você não poderá inserir níveis posteriormente. Você só pode adicionar tipos de geografia abaixo do nível mais baixo atual e excluir tipos de geografia sem geografias definidas. Essa configuração geralmente é um procedimento único, portanto, certifique-se de definir uma estrutura de país completa e precisa na primeira vez.

Você deve adicionar um tipo de geografia como um nível na estrutura do país para poder definir uma geografia para esse tipo de geografia em um país. Por exemplo, antes de definir o estado da Califórnia, o tipo de geografia do Estado deve ser adicionado à estrutura do país dos Estados Unidos.

O país para o qual você deseja definir uma estrutura deve estar na tabela FND_TERRITORIES.

Esta tabela descreve alguns termos nas páginas usadas para este procedimento.

Se a estrutura do país estiver completamente indefinida, então, opcionalmente, copie a estrutura de outro país.

O aplicativo fornece um conjunto de tipos de geografia de referência mestre disponíveis. Se necessário, você pode criar um tipo de geografia exclusivo antes de adicioná-lo a essa ou a qualquer outra estrutura de país.

Importante: para garantir que os aplicativos do Oracle E-Business Suite que utilizam a Geography Hierarchy possam permitir que os usuários insiram ou pesquisem um intervalo de valores de código postal, use o tipo de geografia Postal com código postal. Não crie um novo tipo, por exemplo, chamado CEP.

Adicione tipos de geografia conforme necessário. Cada tipo de geografia é adicionado logo abaixo do nível mais baixo atual.

Você pode excluir tipos de geografia somente se as geografias não existirem nesse nível. Se o tipo de geografia não for o nível mais baixo da estrutura do país, exclua não apenas esse nível, mas todos os níveis abaixo dele.

Nota: Se você excluir um tipo de geografia, todos os mapeamentos e uso de validação associados a esse nível também serão excluídos. Veja: Gerenciando Validações.

Visualizando e definindo geografias.

Veja a lista de geografias de um tipo específico de geografia no país selecionado e adicione regiões geográficas conforme necessário. Por exemplo, para o tipo de geografia do estado nos Estados Unidos, você definiria a lista de estados dos EUA.

O tipo de geografia das geografias que você deseja visualizar e definir já deve ter sido adicionado à estrutura do país. Veja: Definindo Estruturas de Países.

Adicione geografias que ainda não estão na lista. O nome e o código digitados são, por padrão, o nome e o código primários para essa geografia. Os nomes e códigos primários são exibidos para os usuários.

Nota: Especifique um tipo de código, se conhecido, e deixe o Usuário inserido como o provedor de dados, conforme você está digitando manualmente nas geografias.

Se você não tiver geografias para inserir neste tipo de geografia, mas tiver geografias para qualquer nível inferior na estrutura do país, selecione Geografias desconhecidas para este nível e vá para a Etapa 4.

Atualize geografias específicas para fornecer mais informações, por exemplo, para inserir nomes ou códigos adicionais ou selecione outra como principal. Veja: Atualizando Geografias.

Conforme necessário, exclua as regiões geográficas para desativá-las, somente se a geografia não tiver geografias ativas no nível subseqüente da estrutura do país.

Nota: todas as geografias filhas da geografia que você está inativando não são mais válidas. Você não pode visualizar ou atualizar essas geografias. Por exemplo, desativar um condado invalida todas as suas cidades e códigos postais, bem como quaisquer zonas definidas pelo usuário nesse município.

Se houver um nível subsequente na estrutura do país, clique em Exibir detalhes para visualizar e definir geografias para o próximo tipo de geografia. Por exemplo, o estado é pai do condado da estrutura de país dos Estados Unidos e, no momento, você está visualizando a lista de estados. Você pode clicar em Visualizar Detalhes da Califórnia para a lista de municípios nesse estado.

Atualizando Geografias.

Atualize uma área geográfica específica, por exemplo, a cidade de São Francisco ou o país dos Estados Unidos, e especifique detalhes como o intervalo de datas da geografia, nomes e códigos primários e alternativos e regiões geográficas pai.

A geografia que você deseja atualizar já deve estar definida. Veja: Definindo Geografias. Se você deseja atualizar um país específico, ele deve estar na tabela FND_TERRITORIES.

Esta tabela descreve alguns termos nas páginas usadas para este procedimento.

Atualize informações gerais para a geografia.

Atualize nomes e códigos primários e alternativos. Os nomes devem ser exclusivos e os códigos exclusivos em um tipo de código.

Um exemplo de uso de nome principal e alternativo está na validação de endereço em tempo real. Por exemplo, o nome principal é CA e os nomes alternativos são Cal e Calif. Se o usuário inserir Cal ou Calif, o aplicativo considera válido e salva o valor na tabela HZ_LOCATIONS como CA.

Você não pode excluir um nome ou código principal até que outro nome ou código seja selecionado como principal.

Se você selecionar um nome ou código diferente como principal, essa alteração será refletida quando você voltar à página Detalhes da vista.

Adicione geografias, de um nível acima na estrutura do país, que são pais da geografia que você está atualizando. Quando essa geografia foi definida pela primeira vez, um relacionamento pai-filho já estava estabelecido.

Por exemplo, ao definir o condado de Humboldt, você adicionou Gilmore City como cidade, então Humboldt é o pai de Gilmore City. Gilmore City, no entanto, também está no condado de Pocahontas, então quando você atualiza Gilmore City, você adiciona Pocahontas como pai ou mãe. Quando você define ou visualiza detalhes para o condado de Pocahontas, Gilmore City já seria exibida como uma cidade dentro daquele condado. Veja: Definindo Geografias.

Gerenciando Validações.

As informações de hierarquia de geografia podem ser usadas para validação de geografia, o que garante que os endereços tenham informações geográficas válidas, como a combinação correta de cidade, estado e código postal. No entanto, como os dados de nível de rua não são incluídos, essa validação não garante que os endereços passem pela validação postal e possam ter entregas postais para esses locais.

A validação de endereço em tempo real no Oracle Trading Community Architecture e em outros aplicativos Oracle E-Business Suite alavancam a validação de geografia com base nas informações configuradas na Geography Hierarchy. Veja: Validação de Endereço em Tempo Real, Guia do Usuário da Oracle Community Community Architecture. A validação e o cálculo do Oracle E-Business Tax também aproveitam a Hierarquia de Geografia.

Use a página Gerenciar validações para executar tarefas que fazem parte da configuração de validação de endereço ou de imposto. Consulte: Configurando a Validação de Endereço em Tempo Real.

Para validação de endereço, especifique o nível de validação para o país. Se o nível não for Sem validação, mapeie a estrutura do país para os atributos da tabela de origem HZ_LOCATIONS e marque o mapeamento com o uso da Geography Validation. Se você também usar a formatação de endereço flexível para esse país, faça o mapeamento usando o estilo de endereço atribuído ao país como um guia.

A estrutura do país já deve estar definida se você deseja mapear os tipos de geografia para os atributos da tabela de locais para fins de geografia ou validação de impostos. Veja: Definindo Estruturas de Países. (Opcional) Os estilos de endereço usados nessa configuração são da FAF (Flexible Address Formatting) para a tabela de origem HZ_LOCATIONS ou da formatação do endereço HR para a tabela de origem HR_LOCATIONS_ALL. Se nenhum dos estilos de endereço for adequado às suas necessidades, crie estilos personalizados e atribua a países. Consulte: Configurando Endereços Flexíveis, Guia de Implementação do Oracle Receivables ou Flexfields Descritivos e Estilos de Endereços, Guia de Administração de Sistemas, Relatórios e Configuração do Oracle Human Resources Management Systems e Alterando Estilos de Endereços Nacionais Padrão, Sistemas de Gerenciamento de Recursos Humanos da Oracle, Relatórios e Sistema Guia de administração.

Esta tabela descreve alguns termos nas páginas usadas para este procedimento.

Erro: Somente endereços completamente válidos podem ser salvos, com todos os elementos de endereço obrigatório inseridos.

Somente campos obrigatórios: os endereços inválidos podem ser salvos sem aviso aos usuários, mas somente se os usuários inserirem um valor para todos os elementos de endereços obrigatórios, conforme definido pelos tipos de geografia selecionados para uso da Geography Validation.

Nenhuma validação: todos os endereços podem ser salvos, incluindo endereços incompletos e inválidos.

Aviso: os endereços inválidos são salvos após os usuários de aviso.

Digite a tabela de origem primeiro, pois isso determina os estilos de endereço disponíveis.

Na primeira vez que você configura a tabela de origem HZ_LOCATIONS ou HR_LOCATIONS_ALL, você seleciona uma tabela de origem, mas não um estilo de endereço, porque deve primeiro configurar um mapeamento de endereço padrão.

Nota: Nenhum estilo representa o mapeamento de validação padrão, que é usado se:

Um país não está associado a um estilo de endereço.

Um aplicativo não está configurado com a formatação de endereço flexível.

O estilo de endereço de FAF ou HR usado em uma situação específica não é configurado aqui com um mapeamento de validação dedicado.

Desde que você configure o mapeamento de validação para Nenhum estilo, você garante que a validação geográfica ou tributária possa ser realizada para qualquer endereço nesse país, com base na sua configuração. Após o No Style ser configurado para a respectiva tabela de origem, você pode definir o mapeamento adicional para estilos de endereço específicos:

Se você usar a formatação flexível de endereço para esse país, selecione HZ_LOCATIONS e o estilo de endereço FAF atribuído a esse país.

Para HR_LOCATIONS_ALL, você pode selecionar qualquer estilo de endereço de RH.

Dica: configure o mapeamento e a validação de geografia apenas para estilos de endereço de RH potencialmente usados para esse país.

Nota: O mapeamento adicional após Nenhum estilo para qualquer tabela de origem é opcional, mesmo se você usar FAF para esse país.

Para estilos de endereço diferentes de Sem estilo, selecione a combinação de tabela de origem e estilo de endereço para exibir o mapeamento de estilo de endereço. Use as informações de estilo para ajudá-lo a mapear o endereço para fins de validação, na próxima etapa.

Mapeie os tipos de geografia da estrutura do país para os atributos da tabela de origem. Você pode mapear tipos diferentes para o mesmo atributo para diferentes estilos de endereço, mas não para o mesmo estilo.

Dica: mapeie apenas os tipos de geografia que você deseja usar para fins de geografia ou validação de impostos. Por exemplo, o mapeamento determina quais elementos de endereço fazem parte do processo de validação de endereço.

Somente elementos mapeados são processados quando a referência de nome geográfico é executada. Veja: Processo de Referência de Geografia.

Para qualquer tipo de geografia mapeada e combinação de atributos, selecione opcionalmente pelo menos um uso de validação, imposto ou geografia. Os elementos de endereço correspondentes aos tipos de geografia devem estar corretos para que o endereço seja considerado válido para o uso selecionado.

Nota: Se um elemento de endereço for mapeado para um tipo de geografia, mas não selecionado para uso de validação de geografia, os valores sugeridos poderão ser fornecidos para esse elemento de endereço durante a entrada de endereço, mas esse elemento não será validado.

A validação geográfica aplica-se apenas à tabela HZ_LOCATIONS.

Validação de geografia: por exemplo, para os Estados Unidos, você especificou o estilo de endereço da América do Norte para os endereços HZ_LOCATIONS. Então, para essa combinação, você mapeia a estrutura do país dos EUA para os atributos HZ_LOCATIONS e especifica que os valores de país, estado e código postal são usados para validação de geografia. Quando o usuário digita um endereço nos EUA usando esse estilo de endereço, o endereço deve ter a combinação correta de país, estado e código postal, com base nos dados da hierarquia da geografia, para ser considerada geograficamente válida.

Use a caixa de seleção Geography Validation para especificar quais elementos de endereço são obrigatórios durante a entrada de endereço, com base no nível de validação de geografia do país selecionado. O nível de validação geográfica para o país pode ser:

Campos Obrigatórios Apenas.

Nota: O uso da Geography Validation determina quais elementos do endereço são obrigatórios durante a entrada do endereço, com base no nível de validação da geografia selecionado. Por exemplo, se o nível de validação for Somente campos obrigatórios, os usuários deverão inserir elementos de endereço com uso de validação geográfica, mas o endereço ainda poderá ser salvo se os valores forem inválidos.

Validação de impostos: por exemplo, para os Estados Unidos, você especificou o estilo de endereço da América do Norte para HR_LOCATIONS_ALL. Em seguida, para essa combinação, mapeie a estrutura do país dos EUA para os atributos HR_LOCATIONS_ALL e especifique que o Condado, o Estado e a Cidade sejam usados para validação de impostos. Quando uma transação de venda envolve um endereço com o estilo de endereço da América do Norte, o endereço deve ter a combinação correta de país, estado e cidade, com base nos dados da hierarquia geográfica, para ser considerada válida para o cálculo de impostos.

Importante: para uso, não pule mais de um nível consecutivo, a menos que você tenha certeza de que os tipos de geografia selecionados podem identificar geograficamente de maneira exclusiva.

Por exemplo, a estrutura do país é: Estado, Município, Cidade e Código Postal, e você deseja selecionar apenas Código Estadual e Postal para geografia ou validação de impostos. No entanto, para a combinação da Califórnia e 94065, a cidade pode ser Redwood Shores ou Redwood City. Nesse caso, você também deve selecionar pelo menos Cidade para geografia ou validação de impostos.

(Apenas validação geográfica) Especifique o nível de validação para este país, se pelo menos um mapeamento for selecionado para uso de validação de geografia.

Nota: Se você selecionar Somente campos obrigatórios, a Validação de geografia mudará para Obrigatório na seção Mapeamento e validação de geografia.

Processo de referência de nomes de geografia.

Execute o processo de referência de nome geográfico para validar os elementos de endereço nas tabelas de localização, como HZ_LOCATIONS e HR_LOCATIONS_ALL, em relação às geografias na hierarquia de geografia de referência mestre. Para cada endereço, ou registro de localização, o programa identifica a geografia de referência mestre para a qual um elemento de endereço é mapeado, se houver. O Oracle E-Business Tax usa essas informações de mapeamento para fins específicos de negócios, como o cálculo de impostos.

A referência de nome geográfico é baseada em dados e configurações de validações de hierarquia de geografia. Veja: Gerenciando Validações.

Processo de referência de nome de geografia e exemplo de uso.

Esta tabela descreve o mapeamento de validação da estrutura de país dos Estados Unidos para a tabela HZ_LOCATIONS, para o estilo de endereço da América do Norte.

Um endereço em HZ_LOCATIONS possui elementos de endereço, conforme mostrado nesta tabela.

O processo de referência de nome geográfico é executado na tabela HZ_LOCATIONS e processa esse endereço. O programa:

Verifica o estilo de endereço associado a esse endereço, neste exemplo, o estilo de endereço da América do Norte. O programa pode usar a configuração de mapeamento de validação correspondente da Geography Hierarchy para a próxima etapa.

Compara cada elemento de endereço, ou atributo HZ_LOCATIONS, que é mapeado para um tipo de geografia na estrutura de país dos EUA, em relação à geografia de referência mestre correspondente definida em Geography Hierarchy. Esta tabela descreve os resultados dessa comparação para cada elemento no endereço acima.

No entanto, se o programa puder encontrar um valor único e correto, como no estado, o elemento de endereço será corrigido e mapeado de acordo.

Fornece os resultados para este e todos os outros endereços processados no log de programa simultâneo. O log especifica o status do mapeamento e explica por que os registros recebem o status Erro.

Conforme indicado no mapeamento de validação Geography Hierarchy, os tipos de geografia Country, State, County e City são usados para validação de impostos. Para qualquer endereço, o imposto é calculado com base nas geografias de referência mestre para as quais cada elemento do endereço é mapeado, como resultado da referência do nome geográfico. Para o endereço neste exemplo, se os elementos de endereço de estado e município não puderem ser mapeados, a validação e o cálculo de impostos não poderão ocorrer para impostos estaduais e municipais, mas podem para impostos de país e cidade, porque esses elementos de endereço são validados e mapeados.

Pré-requisitos

Para os países para os quais você executa a referência de nomes geográficos:

Definir a estrutura do país da hierarquia de geografia. Veja: Definindo Estruturas de Países.

Defina geografias para cada tipo de geografia na estrutura do país. Consulte: Exibindo e definindo geografias e atualizando geografias.

Mapeie os tipos de geografia na estrutura do país para os atributos da tabela de localização e especifique o uso de geografia. Veja: Gerenciando Validações.

Defina estas opções de perfil:

HZ: Tamanho do lote para confirmar registros no processo de referência de nome geográfico.

HZ: Número de trabalhadores para uma determinada solicitação de referência de nome geográfico.

Dica: Se o desempenho do processo de referência de nome geográfico for baixo, verifique com o administrador do banco de dados sobre o aumento do número de trabalhadores.

Parâmetros do programa.

Nome da tabela de localização: selecione a tabela com os registros de endereço que você deseja processar, HZ_LOCATIONS ou HR_LOCATIONS.

Tipo de Execução: Especifique para processar todos os registros, apenas os registros que resultaram em erro anteriormente ou apenas os novos registros que este programa nunca processou.

Uso do Endereço: Especifique para executar o programa para uso de validação de imposto ou de geografia, ou ambos. O programa fornece resultados que correspondem aos elementos de endereço e tipos de geografia com o uso selecionado.

País: insira o país para processar endereços para.

ID do local e ID do local Para: Insira um intervalo de IDs de local para identificar os endereços a serem processados.

Data de início e Data de término: insira um intervalo de datas para processar apenas os endereços ativos dentro desse intervalo.

Gerente de Relacionamento.

Este capítulo descreve o uso do Relationship Manager para visualizar, criar e editar relacionamentos entre as partes existentes no Registro do TCA.

Este capítulo abrange os seguintes tópicos:

Visão geral do gerente de relacionamento.

Use o Relationship Manager do Oracle Trading Community Architecture (TCA) para criar e gerenciar relacionamentos entre as partes existentes no Registro do TCA.

Nota: Você visualiza e gerencia apenas as partes do tipo Organização e Pessoa no Gerenciador de relacionamento.

O uso de relacionamentos para modelar as interações entre as partes no Registro do TCA ajuda você a tomar melhores decisões de negócios. Por exemplo, você pode analisar e gerenciar relacionamentos com concorrentes e parceiros, ou relacionamentos corporativos entre subsidiárias e corporações controladoras.

No Relationship Manager, você obtém uma visão abrangente das funções desempenhadas por uma única parte em relação a outras partes no Registro, bem como uma visão hierárquica para relacionamentos hierárquicos. Além de visualizar relacionamentos, você pode criar, editar e encerrar relacionamentos.

Seu administrador pode configurar o Gerenciador de relacionamento. Consulte: Configurando o Relationship Manager, Guia de Administração de Arquitetura do Oracle Trading Community.

Visão geral de relacionamentos.

O modelo de relacionamento do TCA permite registrar relacionamentos complexos e reais entre entidades no Registro do TCA. Você pode analisar não apenas relacionamentos diretos, como aqueles com seus concorrentes, mas também indiretos, como os clientes de seus clientes. Você também pode gerenciar relacionamentos hierárquicos para entender melhor, por exemplo, a hierarquia de gerenciamento em uma organização.

Um relacionamento representa a maneira como duas entidades interagem umas com as outras, com base no papel que cada entidade assume em relação ao outro. Por exemplo, a relação de emprego entre uma pessoa e uma organização é definida pelo papel da pessoa como empregado e organização como empregador.

Além disso, todo relacionamento é recíproco. Cada entidade é o sujeito ou objeto, dependendo da perspectiva ou direção. Por exemplo, se Joe é o empregado da Oracle, então Joe é o sujeito e o Oracle é o objeto. Oracle como o empregador de Joe, que vira o assunto e objeto, ainda descreve o mesmo relacionamento.

Frase de Relacionamento e Pares de Função.

Um par de frase e função de relacionamento contém um par de frases e um par de funções correlacionados, que descreve os papéis recíprocos que as duas entidades desempenham no relacionamento. Por exemplo, uma frase de relação e um par de funções contém o par de frase Empregado e Empregador da frase, bem como o par de funções Empregado e Empregador.

Todo relacionamento é baseado em um par de frases e papéis de relacionamento. Mesmo que apenas pares de frases sejam usados no Relationship Manager, o par de funções correspondente ainda é armazenado no sistema para cada relacionamento.

Um par de frases, como Employee Of e Employer Of, descreve o papel de qualquer entidade no relacionamento como o assunto. Por exemplo, Joe como sujeito do relacionamento teria Employee Of como a frase e Oracle como assunto teria Employer Of. A outra entidade no relacionamento seria o objeto.

Um par de funções de relacionamento, como Empregado e Empregador, descreve as duas entidades, independentemente da direção do relacionamento. Por exemplo, Joe tem a função Employee e a função Oracle the Employer, tanto como assunto ou objeto.

Cada par de frase e função de relacionamento também determina o tipo de entidades para o relacionamento. Por exemplo, a função Empregador de frase e Empregador pode ser definida para que o empregador seja uma parte do tipo Organização e o empregado uma parte do tipo Pessoa.

Quando você cria um relacionamento com uma frase ou função de relacionamento, a direção reversa do relacionamento é criada automaticamente com a outra frase ou função no par. Por exemplo, se você definir Joe como o funcionário da Oracle, o Oracle como empregador de Joe também será criado.

Tipo de Relacionamento.

Cada par de frase e função de relacionamento pertence a um tipo de relacionamento, que categoriza os tipos de relacionamentos que você pode criar. Por exemplo, a frase de relacionamento e o par de funções descritos acima pertenceriam a um tipo de vínculo empregatício.

Os tipos de relacionamento determinam se os relacionamentos criados com o tipo são hierárquicos e, se não, se podem ser circulares ou não. Para mais informações, consulte: Características do relacionamento.

Todo tipo de relacionamento deve conter pelo menos um par de frase e função. O TCA fornece tipos de relacionamento e pares de frase e função, mas o administrador pode criar novos, conforme necessário. Consulte: Administrando Relacionamentos, Guia de Administração de Arquitetura do Oracle Trading Community e Tipos, Frases e Funções de Relacionamento Semeados, Guia de Referência de Arquitetura do Oracle Trading Community.

Intervalo de datas de relacionamento.

Ambas as direções de um relacionamento compartilham uma data de início e término. A data de início significa quando o relacionamento é iniciado, não necessariamente quando foi criado. Likewise, the end date is when the relationship ends.

The relationship date range helps you analyze the history of an entity's relationships. For example, you can see that Joe used to work for Oracle in a subsidiary location for the past two years but has been working at Oracle headquarters since last month.

Relationship Group.

In general, relationship groups are used to determine which relationship roles and phrases are displayed in specific application user interfaces. Groups can also be used to categorize roles and phrases for other functional uses.

Note: Relationship groups do not apply to Relationship Manager. All seeded and user-created relationship phrases are available.

Relationship Characteristics.

Relationships have additional characteristics that relationship types determine.

Hierarchical Relationships.

A hierarchical relationship ranks one entity above the other. For example, in an employment relationship, the employer is ranked above the employee. In the employment hierarchy, the employee would be a child that appears below its parent, the employer. Hierarchical relationships are created with phrase and role pairs that belong to a hierarchical relationship type.

Circular Relationships.

If a relationship type allows for circular relationships, you can create a relationship from Party A to Party B to Party C and back to Party A. For example, Party A is a competitor of Party B, which is a competitor of Party C, which is a competitor of Party A.

Hierarchical relationships cannot be circular. For example, if Alan's manager is Jenny, and Jenny's manager is Chris, then Chris's manager cannot be Alan.

Nonhierarchical relationship types can either allow or prevent circular relationships. For example, marital relationships cannot be circular, while competitive relationships described above can.

Major Features.

Relationship Manager provides these features for relationships between existing parties in the TCA Registry:

Search for the party that you want to manage relationships for.

View the party's basic party information and any available additional details.

View the relationship types that the party is involved in.

View the relationships that the party belongs to for specific types.

View the hierarchy of a hierarchical relationship type.

Create relationships, available when you view the relationship types, relationships, or hierarchies of the party.

Edit existing relationships, including ending the relationship.

Relationship Hierarchy.

Relationship Manager displays hierarchical relationships in a hierarchy, a visual representation of the how parties rank among one another within a given relationship type. For any party in the hierarchy, all parties displayed one level below are its children, and the party displayed a level above is its parent.

For any party in the hierarchy, you can:

Update its relationship by moving the party to another part of the hierarchy.

Create new relationships.

View additional party information, if available.

If you batch load data from D&B or acquire the Enterprise Management global data product (GDP) through online purchase, you can view the provided corporate structure relationships for a specific business in a relationship hierarchy. See: Introduction to D&B.

Party Relationship Management Process.

This diagram describes the general process flow of managing party relationships with the Relationship Manager.

Search for the party that you want to view and manage relationships for and select the party from the search results. See: Searching for Parties and Viewing Results.

Note: If you want to see a relationship hierarchy, keep in mind that the party you search for is the root of the hierarchy.

View the party's overview information as well as the relationship types that it is involved in.

From here, you have three options:

View relationships of selected relationship types. See: Viewing Relationships.

Create new relationships with a relationship type that the party is not currently involved in. See: Creating Relationships.

After you create relationships, Relationship Manager takes you back to view the party's information and relationship types.

View the hierarchy of a hierarchical relationship type. See: Viewing Relationship Hierarchies.

If you choose to view relationships, you can also:

Create new relationships with a relationship type that you are viewing. See: Creating Relationships.

Edit the existing relationships that you are viewing. See: Editing Relationships.

After you edit or create a relationship, Relationship Manager takes you back to view the relationships.

If you choose to view a hierarchy, you can also:

Create relationships for any party in the hierarchy, using the relationship type of the hierarchy. See: Creating Relationships.

After you move parties or create relationships, Relationship Manager takes you back to the hierarchy view.

Searching for Parties and Viewing Results.

Use the Party page to search for and select the party that you want to view and manage relationships for. This search includes parties of type Organization or Person.

If you want to see a relationship hierarchy, keep in mind that the party you search for is the root of the hierarchy. For example, if you view the corporate hierarchy for Party B, you can see Party C as the subsidiary of Party B but cannot see that Party B is a subsidiary of Party A. For more information, see: Viewing Relationship Hierarchies.

From the search results, you select the party that you want and bring up the Overview page. View the party's overview and relationship type information, including:

The relationship types that the party is involved in.

The number of relationships for each type.

Whether the relationship type is hierarchical or not.

Whether the type allows circular relationships or not.

If available, you can access more information about the party from the Additional Details field.

From the Overview page, you can choose to:

Note: You can also access the Overview page from other pages in Relationship Manager by clicking the party name.

Viewing Relationships.

Use the View Relationships page to view the relationships of the selected party. You can view relationships for some or all of the relationship types that the party is involved in.

The selected party is the subject party of all displayed relationships. You also see the object party name and Registry ID, the date range of the relationship, and the source of the relationship, for example user entered or third party. Even relationships with passed end dates are included.

To view relationships for a party:

Navigate to the Overview page for the party that you want to view relationships for. See: Searching for Parties and Viewing Results.

Select at least one relationship type and click the View Relationships button.

The View Relationships page displays relationships for the party within your selected relationship types.

You can choose to:

Creating Relationships.

Use the Create Relationships page to create new relationships between existing parties in the TCA Registry. You can choose to create relationships from three pages:

Overview: Create relationships with a relationship type that is not displayed for the party, which would be the subject of the new relationship.

View Relationships: Create relationships with any of the selected types that you are viewing for the party, which would be the subject of the new relationship.

Hierarchy: Create relationships with any of the parties in the hierarchy as the subject, using the relationship type of the hierarchy.

For example, a relationship phrase pair consists of: Organization is Headquarters Of Organization, and Organization is a Subsidiary Of Organization. If you are working on the party Oracle HQ, you would create a relationship with your party as the subject party and use the appropriate relationship phrase: Oracle HQ is the headquarters of Oracle Branch.

The reverse direction of the relationship, Oracle Branch as the subsidiary of Oracle HQ, is automatically created. You would see this direction of the relationship when you view relationships for Oracle Branch.

You can create multiple relationships between the same two parties, with different relationship phrases, even if relationship date ranges overlap. To use the same relationship phrase for multiple relationships between the same two parties, however, the relationship date ranges must not overlap.

To create relationships:

Navigate to the Overview page for the party that you want to create relationships for. See: Searching for Parties and Viewing Results.

Select the relationship type that you want to create relationships for and click the Go button. The available types that you can create relationships for exclude the types that the party is already involved in.

To create relationships with a type that the party is already involved in, you must first view the relationships within that type. This restriction ensures that you review the existing relationships for a type so that you do not create duplicate relationships.

After viewing current relationships, you select the type to create relationships for and click the Go button. The available types include only the types that you are viewing. See: Viewing Relationships.

Tip: You can also create relationships for any party in a relationship hierarchy. See: Viewing Relationship Hierarchies.

The Create Relationships page displays your selected relationship type as the type for the new relationship, and the selected party is the subject party.

Select a relationship phrase and object party for the relationship, with respect to the subject party.

Optionally change the start date of the relationship, which defaults with the current date.

If you use the current date, the relationship's start time is the system time. If not, the start time is at the beginning of the start date.

Optionally enter an end date.

The relationship's end time is at the end of the end date.

Click the Add Another Row button to create another relationship for the subject party with this same relationship type. Repeat steps 4 through 6.

Click the Apply button.

The confirmation takes you back to the page from where you chose to create relationships. Your new relationships are reflected in that page.

Editing Relationships.

Use the Edit Relationship page to edit a selected relationship for the party that you are viewing relationships for. This party is the subject party, which, along with relationship type and object party, cannot be changed. What you can update in the relationship are:

When you change the relationship phrase, Relationship Manager actually ends the existing relationship and creates a new one with the new phrase. The current date is the end date of the existing relationship.

You can manually enter or change an end date to terminate a relationship at the current or another specified date. You can also extend a relationship by entering a later end date or removing the end date. Even relationships with an end date that already passed can be prolonged by changing or removing the end date.

Any changes that you make to the direction of the relationship with your party as the subject applies to the opposite direction of the relationship. For example, the direction you are editing is: Oracle is the employer of Joe. If you end this relationship, Joe as the employee of Oracle also ends.

Tip: You can also edit hierarchical relationships by moving parties within the hierarchy of a relationship type, which changes the object party. See: Updating Relationships by Moving Parties in a Hierarchy.

To edit a relationship:

Navigate to the View Relationships page for a party with the relationships that you might want to edit. See: Viewing Relationships.

Click the Edit icon for the relationship that you want to edit.

Note: You can edit only relationships with the User Entered source.

In the Edit Relationship page, change the relationship phrase, start date, end date, or any combination of the above.

Click the Apply button.

The confirmation takes you back to the View Relationships page, where you can see the results of your changes.

Viewing Relationship Hierarchies.

Use the Hierarchy page to view a structured hierarchy of the relationships in a given hierarchical relationship type. For example, you get a visual representation of how a corporate structure is set up.

Your selected party is the root at the top of the hierarchy. You can see its children, or parties ranked lower in relationships, but not its parents.

The hierarchy represents a structure of relationships for the date that you specify in the As Of field. The hierarchy displays all relationships that fit both of these criteria:

The start date is before or the same as the as of date.

The end date is after the as of date, or no end date exists.

This table shows an example of three relationships and their date ranges.

This table shows examples of which relationships the hierarchy would display depending on the date in the As Of field.

For each node in the hierarchy, Relationship Manager displays the party's:

Name and Registry ID.

Relationship phrase with respect to its parent party.

Parent party name.

If you have batch loaded data or acquired the Enterprise Management GDP through online purchase, you can also view the corporate hierarchy that D&B provides. See: D&B Hierarchy.

To view a relationship hierarchy:

Navigate to the Overview page for the party that you want to view relationship hierarchies for. See: Searching for Parties and Viewing Results.

Note: Search for and select the party that you want as the highest level, or root, in the hierarchy.

Click the Hierarchy icon for the relationship type that you want to view. Hierarchies are available only for hierarchical relationship types.

Enter the date that you want to view the hierarchy for in the As Of field and click the Go button. By default, the hierarchy is displayed for the current date.

To view the relationships within the hierarchy, click the arrows to expand or collapse levels.

Tip: You can click the Focus icon for the party that you want to view as the root of the hierarchy. Clicking the name of any party in the hierarchy displays the party's overview information and does not render that party as the root of the hierarchy.

Click the Details icon for the party that you want to view additional information for, if available.

Repeat steps 3 to 5 as needed.

From the Hierarchy page, you can choose to:

Note: You cannot update the D&B hierarchy by moving parties within the hierarchy.

D&B Hierarchy.

The D&B hierarchy contains hierarchical corporate relationships that D&B provides through the Enterprise Management global data product (GDP). To access this hierarchy, you select the D&B Hierarchy relationship type, which includes the following relationship phrase pairs:

Parent Of and Subsidiary Of.

Headquarters Of and Division Of.

Domestic Ultimate Of and Domestic Subsidiary Of.

Global Ultimate Of and Global Subsidiary Of.

The Domestic Ultimate is the highest ranking entity within a country, while the Global Ultimate is the uppermost entity within the global corporate hierarchy. D&B creates a reporting structure from the lowest level of a corporate hierarchy to the Global Ultimate, providing a complete hierarchical organization structure.

When you purchase the Enterprise Management GDP for any entity, D&B provides a hierarchy containing all the related parents up to the Global Ultimate, but not other entities on the same or lower levels. For example, if you purchase data for a headquarters, then the provided hierarchy includes its Domestic and Global Ultimate, but not its branches or other headquarters reporting to the same Domestic or Global Ultimate. When you subsequently purchase the GDP for entities on the same or lower levels, then the hierarchical links to the original entity are established.

The structure of the D&B hierarchy depends on many additional factors, including the countries that the entities are in, the entity that you purchase the D&B data for, and so on. For more clarification and illustrations of other rules and regulations, see: D&B Hierarchy Examples.

Important: Do not use the Create Relationship API to create D&B hierarchy relationships. See: Create Relationship API, Oracle Trading Community Architecture Technical Implementation Guide .

D&B Hierarchy Examples.

These examples illustrate how the information that you acquire from D&B appear in Relationship Manager as the D&B hierarchy.

In this example, you purchase D&B data for a branch, which has its headquarters within the same country. This table shows the information that you acquire from D&B, including the corporate structure with respect to the branch.

With the information that you acquire from D&B for the branch, Relationship Manager displays the D&B hierarchy as shown in this table:

The Global Ultimate is always at the top of a D&B hierarchy, no matter which country it is in. The Domestic Ultimate is displayed above the headquarters because they are in the same country, and the Domestic Ultimate is the highest ranking within a country. The Domestic Ultimate is always in the same country as the entity that you purchase D&B data for, by definition.

In this example, you purchase D&B data for a branch, which has its headquarters in another country. This table shows the information that you acquire from D&B, including the corporate structure with respect to the branch.

With the information that you acquire from D&B for the branch, Relationship Manager displays the D&B hierarchy as follows in this table:

The Domestic Ultimate and headquarters are displayed on the same level in the hierarchy because they do not necessarily have any relationship to each other. In the previous example, they are in the same country, so the Domestic Ultimate ranks higher by default. In this example, they are in different countries.

The branch appears only as a child of the headquarters, not also of the Domestic Ultimate, because the reporting structure is based on the headquarters/division and parent/subsidiary relationships only. The Global and Domestic Ultimates do appear in the hierarchy with respect to the entity that you purchased D&B data for.

In this example, you purchase D&B data for Vision HQ from Example 1, which also has its headquarters in the same country. This table shows the information that you acquire from D&B, including the corporate structure with respect to Vision HQ as the branch.

With the information that you acquire from D&B first for Example 1 and then 3, Relationship Manager displays the D&B hierarchy as follows in this table:

As you subsequently purchase more D&B data for other entities within the Vision corporate hierarchy, you accordingly fill out its D&B hierarchy and establish more concrete reporting relationships with the hierarchy.

Updating Relationships by Moving Parties in a Hierarchy.

Use the Hierarchy and Move Parties pages to move selected parties within a hierarchy, accordingly updating affected relationships. You can select one or more parties that you want to move under a new parent in the same hierarchy. The parties that you move and the new parent can be on any level of the hierarchy.

Each move ends the existing relationship and creates a new one based on the new structure in the hierarchy. The current date is the end date of the existing relationship as well as the start date of the new relationship.

Note: If you need to change start or end dates after moves, use the Edit Relationships page. See: Editing Relationships.

For example, the current hierarchy has Party A as the parent of Party B, which is the parent of Party C, which is the parent of Party D. You move Party C and select Party A as its new parent. This move ends the relationship for Party B as the parent of Party C and creates a new relationship for Party A as the parent of Party C. Party D moves along with Party C and remains a child of Party C.

This diagram shows the hierarchy before and after the move:

The relationship phrase of the moved relationship stays the same with respect to parties that you move. For example, if Party C was a subsidiary of Party B, it would then be the subsidiary of Party A, and Party D is still a subsidiary of Party C.

To update relationships by moving parties in a hierarchy:

Navigate to the Hierarchy page for the hierarchy that you want to view and manage. See: Viewing Relationship Hierarchies.

Important: To ensure accurate results when you move parties, use the current date as the as of date. All moves are based on the hierarchy as it is today.

Select the party or parties that you want to move and click the Move button.

Note: You cannot move parties with the relationship start date in the future.

In the Move Parties page, expand the hierarchy as necessary to find the new parent party.

Select the new parent party and click the Apply button.

The confirmation takes you back to view the results of your move in the updated relationship hierarchy.

On-line trading system.

Imagens

Classificações

G & mdash; FÍSICA G06 & mdash; INFORMÁTICA; CALCULAR; CONTAGEM G06Q & mdash; SISTEMAS OU MÉTODOS DE PROCESSAMENTO DE DADOS, ESPECIALMENTE ADAPTADOS PARA EFEITOS ADMINISTRATIVOS, COMERCIAIS, FINANCEIROS, GERENCIAIS, DE SUPERVISÃO OU DE PREVISÃO; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR G06Q30/00 — Commerce, e. g. shopping or e-commerce G06Q30/06 — Buying, selling or leasing transactions G06Q30/08 — Auctions, matching or brokerage G — FÍSICA G06 & mdash; INFORMÁTICA; CALCULAR; CONTAGEM G06Q & mdash; SISTEMAS OU MÉTODOS DE PROCESSAMENTO DE DADOS, ESPECIALMENTE ADAPTADOS PARA EFEITOS ADMINISTRATIVOS, COMERCIAIS, FINANCEIROS, GERENCIAIS, DE SUPERVISÃO OU DE PREVISÃO; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR G06Q30/00 — Commerce, e. g. shopping or e-commerce G06Q30/06 — Buying, selling or leasing transactions G06Q30/0601 — Electronic shopping G06Q30/0641 — Shopping interfaces.

Descrição.

CAMPO TÉCNICO.

Group: A set of similar Items that have been described using the Item Parameter Fields belonging to that Group. Groups are linking together in a hierarchy (e. g. in a tree structure). The same group may be linked into several different places in the hierarchy.

Creator: A User who creates and/or translates Groups.

System: A computer system in which the service software is run.

Moderator: A User who has privileges to moderate and administrate certain Groups or Forums.

Item: Item for trading. An item can be a product, service, right, obligation, share certificate, currency, immaterial item; in fact anything that can be traded. Each item belongs to a specific Group (or possibly many specific Groups) in the barter system and has been specified using the Item Parameter Fields of the specific Group(s).

Standard Parameter Field: The system has a set of standard or “library” Parameter Fields that can be applied to many different Groups as Item Parameter Fields. Values belonging to Standard Parameter Fields can be for example; colour, age group (e. g. babies 0-1 year old, children 1-2, etc.), title, open text description, image of the Item, etc.

Specific Parameter Field: Specific Parameter Fields are parameter fields that are specific to a specific Group or Groups. For example, parameter fields for a mountain bike Group may include a description of the fork and shock hardware.

Item Parameter Fields: Metadata for a specific group that is in practice a set of Parameter Fields (Standard Parameter Fields or Specific Parameter Fields) that are used to define and describe all Items that belong to a specific Group. Item Parameter Fields may include both standard and specific parameter fields. An Item Parameter Field allows a user to for example select a value from a predefined list of values, e. g. colours, weights, sizes, or may allow a user to select a value using a free-form entry.

Hierarchy: The organization of all Groups in the system defining the relations between the Groups. The Hierarchy is a tree or in a more general format a directed graph (either a connected or unconnected graph).

Forum: A group of User's having an interest, activity, or purpose in common (e. g. hobby, work place, university, location, etc). Users join a Forum when registering or logging-on to the system.

Value Category: A defined value or value range of an Item. This is important as trades are often based upon matching Items of similar value. In some cases, trades between different value categories can also be allowed. A Value Category could be for example $100-$199.

Inheritance: A group may inherit its Item Parameter Fields from another group. In practice this means that the Item Parameter Fields of the parent group are added to the Item Parameter Fields of a child group (which then may be augmented by adding further Item Parameter Fields).

Parameter Field Creation Tool: A tool that allows a User to define new Parameter Fields for the Item Parameter Fields of a particular group.

Want: Item that a User wants to acquire and is willing to give something in exchange for.

Have: Item that a User has and would like to give away in order to get something else in exchange.

Group name: Cell phones.

Brand of the cell phone (drop down menu); Model of the cell phone (drop down or free text); Condition of the cell phone (drop down menu); Age of the cell phone (drop down including “not known”); Included items, for example phone, charger, user's manual (check mark list);

Country of the apartment (drop down); City of the apartment (search or drop down); Address of the apartment (open text); Size of the apartment (number (of sq. m.)); Number of rooms in apartment (number); Number of persons apartment is suitable for (number);

Claims ( 22 )

Aplicações prioritárias (1)

Publications (1)

ID=39832617.

Aplicativos familiares (1)

Status do país (4)

Cited By (1)

Families Citing this family (1)

Citations (14)

Family Cites Families (12)

Patent Citations (14)

Cited By (2)

Também publicado como.

Documentos semelhantes.

Eventos Jurídicos.

Owner name : NETCYCLER OY, FINLAND.

Free format text : ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KOPONEN, JUHA;KOSKINEN, JUSSI;REEL/FRAME:026002/0624.

On-line trading system.

Classificações

Descrição.

ON-LINE TRADING SYSTEM.

The present invention relates to on-line trading systems and in particular, though not necessarily, to on-line trading systems that allow the general public to either sell or exchange personal items and services.

A number of websites have appeared in recent years to facilitate the exchange or bartering of items and services between members of the public. An example is the Swaptree™ site available at swaptree. In a two-way barter, two people directly swap their items or services. The problem of course with two-way barter is that, particularly for unusual items, it may be difficult for a first party to link up with another party who has exactly what the first party is looking for. The probability of finding a barter partner grows dramatically in large user base when n-way barter is allowed. In an n-way barter a group of people exchange their "Have's" and "Want's". Consider for example the case of three users, Cl, C2 and C3, who each have their own Have's and Want's (written here in brackets (Have, Want)): C1(A, B), C2(B, C) and C3 (C, A). In this case, the exchange can be coordinated to ensure that each user gets what he/she wants.

On-line barter systems are considered in the following publications; US6847938, KR20010025282, WO2006034221, WOO 124091, WO2004027660, US2003088497, JP2003076881, JP2002318936, JP2002269385, WO0139081, WO2008057255, WO2008057276, WO2008057277, US2007244769, US2007244770, US2007244772, US2007244793, US20070244801, US20070255624, WO2007121298, and WO2007121305.

Barter sites share many characteristics with on-line auction and sales sites such as ebay™ and Wigix™ (wigix). However, the former are necessarily more complex in that a search of the listings must identify both have's and want's, and not only have's as in the case of the auction sites. Moreover, a search on a barter site should identify all possible n-way barters. For this reason, especially in the case of a large user base, it is desirable to automate as much as possible the searching process in a barter system, rather than leaving it to the user to "manually" browse through categories and items. Automated searching relies heavily upon the accurate and detailed categorisation of offered items and services and may be carried out "on-demand", i. e. in response to a user entering a Have and a Want into the system, or by way of periodic "clearing" in which user requests are queued and subsequently cleared in a single pass through the system.

In order to simplify the process of listing and identifying items (or services) for exchange, a barter system may make use of statically defined categories. These may be organised in a hierarchical tree-like structure. For example, "LCD televisions" may be a sub-category under the sub-category "television" and the top level category "home electronics". Users, when listing their barter requests in the system, connect each Have and Want with a specific product category (typically at the lowest level in the tree). In addition, users may add a textual description/keywords for the Have's and Want's (and optionally a photograph of the Have). An automated search will typically employ a keyword search within the specified category.

Statically defined categories are necessarily coarse grained. For example, whilst high level genre categories for books may be defined, e. g. history, science fiction, etc, finer definition is not possible, e. g. "Finnish winter war", due to the intensive nature of the categorisation process. In any case, there is always a limit to the degree of classification that a system provider is willing to create, e. g. if a "Finnish winter war" category is defined, a sub-category for "Moscow Peace Treaty" will not.

A further drawback of the current category-based systems is that certain categories may be poorly or inadequately defined. Users must work within the confines of such categories. Yet another drawback is that, on any given site, categories are specified in a single language. Unless a site is to be restricted to a particular geographic region, e. g. Finland, the site will typically operate in English. Of course, this excludes a massive number of potential users.

Whilst these disadvantages are particularly acute in the case of on-line barter systems, they are also present in other on-line trading systems including on-line auction systems.

It is an object of the present invention to overcome or at least mitigate the above noted disadvantages of conventional on-line trading systems. These and other disadvantages may be overcome by allowing users themselves to create and amend product and service categories, and to position these at appropriate levels within a category hierarchy.

According to a first aspect of the present invention there is provided a method of constructing and maintaining a group hierarchy for use in an online trading system accessible to a multiplicity of end users, where nodes of the hierarchy define respective item and/or service groups with progressively increasing levels of detail, items and/or services offered for trade on the system being directly associated with at least one group. The method comprises the steps of receiving end user requests to create respective new groups, each request identifying one or more parameter fields for describing items or services belonging to the group and one or more locations within the existing group hierarchy, and modifying the existing hierarchy to accommodate the new groups.

The method may comprise submitting said end user requests via graphical user interfaces displayed on end user terminals, and delivering the requests via the Internet to a web server or servers on which said trading system is hosted. More particularly, the graphical user interface may be configured to enable an end user to select the location(s) of a new group within the hierarchy.

One embodiment of the invention requires that each said end user request includes a name of the group and a textual description of the group. The request may also include a set of values associated with a parameter field, the values forming a user selectable list.

The method may comprise the further steps of receiving an end user request to modify an existing group and modifying that existing group. More particularly, the request may include: a) an indication of parameter fields to be deleted or added; b) an indication of text to be amended, deleted or added; or c) an indication of a new location for the group within the hierarchy.

The group hierarchy may be stored in a memory of the on-line trading system as one or more directed graphs.

The request may identify a parameter field by way of a selection of parameter field associated with a pre-existing group.

The request may identify a parameter field by way of a selection of a standard parameter field defined by the on-line trading system.

The or at least one of the parameter fields associated with a request may be multidimensional, e. g. allowing an item characteristic to be specified using two or more sub - fields.

According to a second aspect of the present invention there is provided an on-line trading system employing a group hierarchy constructed using the method of the above first aspect, the system maintaining a catalogue of items and/or services for trading, each item and/or service being directly associated with one of said groups.

The on-line trading system may be configured to store, in association with each group, a group name, as well as, for each group with which an item or service is associated, at least one parameter field for defining a property of an item or service associated with the group. The system may be further configured to present to an end user terminal, for a given group, a graphical user interface containing a text entry field for each parameter field of the group, to receive the input text, and to store the input text as an alternative user selectable language. The system may be still further configured to present to an end user terminal, for a given group, a graphical user interface allowing a user to select a language from a set of languages in which text associated with group parameter fields is displayed.

The on-line trading system may be configured to present to an end user terminal, for a given group, a graphical user interface allowing a user to search for items and/or services in the catalogue by selecting values for one or more parameter fields of the group.

The invention is applicable in particular, though not necessarily, to a system for providing a barter service for end users, automatically searching said catalogue to match users' Have's and Want's and delivering results to end users.

The system may be further configured to present to an end user terminal, for a given group, a graphical user interface allowing a user to add, delete and/or amend values associated with a parameter field of that group.

According to a third aspect of the present invention there is provided an online trading system comprising a web server or web server cluster configured to host an on-line trading system accessible by a multiplicity of end users possessing respective user terminals connected to the Internet, the web server or web server cluster comprising: a first memory storing a group hierarchy, where nodes of the hierarchy define respective item and/or service groups with progressively increasing levels of detail, and storing for at least each group at the bottom of the hierarchy at least one user parameter field for describing items or services associated with the group; a second memory for storing details of items and/or services offered for trade on the system including for each item and/or service the identity of at least one group with which that item or service is associated and a user selection for the or each parameter field; and a processor for receiving end user requests to create new groups, each request including one or more user parameter fields for describing items or services belonging to the group and one or more locations within the existing group hierarchy, and for accessing said first memory to modify the existing hierarchy to accommodate the new groups.

According to a fourth aspect of the present invention there is provided an online trading system comprising a web server or web server cluster configured to host an on-line trading system accessible by a multiplicity of end users connected to the Internet, the on-line trading system being arranged to: maintain a hierarchical structure of groups, each group possessing a name and at least those groups at the bottom of the hierarchy each possessing one or more parameter fields defining respective properties of items or services associated with the group; maintain a catalogue of user items and/or services for trade, each item or service being associated with at least one group for the purpose of categorising the item or service and being defined by a user selection for the or each parameter field of the group; receive new group definitions from end users including at least one parameter field and add corresponding new groups to the hierarchical structure; and receive details of new items or services to be added to the catalogue including associations with the new groups and a user selection for the or each parameter field of the groups.

Brief Description of the Drawings.

Figure 1 illustrates schematically a Group or category of an online barter system, including properties of the Group;

Figures 2 A to 2F illustrates various screens of a Graphical User Interface of an online barter system, suitable for User Creation of Group;

Figure 2G illustrates a Screen of the Graphical User Interface of an online barter system that allows a Group Creator to import parameters from an existing Group into a new.

Group being established by the Creator;

Figures 3 A and 3B illustrate a Group hierarchy before and after addition of new Groups to the hierarchy;

Figure 4 shows a screen of a Graphical User interface illustrating a portion of a Group hierarchy;

Figure 5 shows a screen of a Graphical User interface allowing a Group Creator to link a new Group into the existing Group hierarchy;

Figure 6 shows in detail a screen of a Graphical User Interface for allowing a User to create a new Group;

Figure 7 is a flow diagram illustrating a process for creating a new Group;

Figure 8 is a flow diagram illustrating a search procedure for an online trading system; e.

Figure 9 is a flow diagram illustrating a generic search procedure for an online trading system.

It is proposed here to provide an on-line trading system that allows users, by way of a specially designed graphical user interface (GUI), to create, modify, and potentially delete categories used to categorise product and/or service. The system is essentially a web 2.0 based system in that it places implicit trust in the users to act collaboratively and responsibly when handling categories but, at the same time, is self-policing in that mistakes and deliberate errors by the inconsiderate few can be corrected by the responsible majority. As groups of end users will almost always be more knowledgeable than the system operator (consider for example stamp collectors, mountain bikers, or bull dozer enthusiasts), this approach will allow a growing number of product groups to be created that will describe actual items and services in a realistic and truly meaningful way.

Furthermore, this approach will allow users to translate existing categories into another language. A clear benefit is that the structure of the existing category, i. e. its place in the category tree, parameter fields, value, etc, can be retained, with only the text needing to be translated. The category remains as a single category, with different language options.

In the detailed description of an on-line barter system presented below, the following terms are used:

User. System user (person or some other entity, possibly automated) with a specified profile and privileges who trades with the barter system. In some cases a User can also be a guest User without a predefined profile.

Creator. A User who creates and/or translates Groups.

System: A computer system in which the service software is run.

Moderator: A User who has privileges to moderate and administrate certain Groups or.

Standard Parameter Field: The system has a set of standard or "library" Parameter.

Fields that can be applied to many different Groups as Item Parameter Fields. Values belonging to Standard Parameter Fields can be for example; colour, age group (e. g. babies 0-1 year old, children 1-2, etc.), title, open text description, image of the Item, etc.

Item Parameter Fields: Metadata for a specific group that is in practice a set of.

Parameter Fields (Standard Parameter Fields or Specific Parameter Fields) that are used to define and describe all Items that belong to a specific Group. Item Parameter Fields may include both standard and specific parameter fields. An Item Parameter Field allows a user to for example select a value from a predefined list of values, e. g. colours, weights, sizes, or may allow a user to select a value using a free-form entry.

Forum: A group of User's having an interest, activity, or purpose in common (e. g. hobby, work place, university, location, etc). Users join a Forum when registering or logging-on to the system.

Inheritance: A group may inherit its Item Parameter Fields from another group. In practice this means that the Item Parameter Fields of the parent group are added to the.

Item Parameter Fields of a child group (which then may be augmented by adding further Item Parameter Fields).

Parameter Field Creation Tool: A tool that allows a User to define new Parameter.

Fields for the Item Parameter Fields of a particular group.

Want: Item that a User wants to acquire and is willing to give something in exchange for.

Have: Item that a User has and would like to give away in order to get something else in exchange.

Considering further the Item Parameter Fields, these can be complex, e. g. multidimensional. For example, a Parameter Field for weight may have two sub-fields, one for a value, e. g. 10, and one for a dimension, e. g. kg. As a further example, a Parameter Field may comprise nested sub-fields (including sub-fields nested within sub-fields) to allow a graded definition of a characteristic of an Item.

A top-level description of a procedure for defining a new group is as follows:

1. Define the Group description which includes the Group name and possibly a generic description about the Items that the Group includes. 2. Specify the Item Parameter Fields for a Group a. Select Item Parameter Fields for the Group from the list of Standard Parameter Fields b. Copy Specific Parameter Fields from another Group c. Create new Specific Parameter Fields for the Group using a Parameter Field Creation Tool.

3. Link the new Group into the existing Group Hierarchy.

Above steps can be done in any appropriate order. The end result is the complete set of Item Parameter Fields for the Group.

Figure 1 illustrates the structure of a Group named "Bicycles". As well as this name, the Group definition includes a textual description of the group, and a set of Item Parameter Fields. When creating the group, the Creator specifies whether Item Parameter Fields are mandatory (M) or optional (O). Certain of the items are Standard Parameter Fields, e. g. "Brand", "Model", whilst others are Specific Parameter Fields, e. g. "Rim Diameter". Within an Item Parameter Field, the Creator can define a drop down menu with pre-set options. So, for the Item Parameter Field "Colour", the drop down menu may offer various standard colours, red, blue, etc. Of course, these menus themselves may be hierarchical, offering further sub-choices.

Figures 2A to 2F illustrates simplified graphical user interface screens for creating a group such as the Bicycle group of Figure 1. Once a User has logged-on to the barter service, which may require pre-registration, he chooses to create a new group by selecting the appropriate option (Figure 2A): the User clicks on the "Create New Group" button. This takes the User, who is now the Group Creator, to the screen view of Figure 2B. The Creator enters the Group name and description into appropriate fields, and clicks on the "OK, Next" button, taking him to the screen of Figure 2C. This screen allows the Creator to add Item Parameter Fields to the Group, either by using Standard Parameter Fields (using the screen of Figure 2D), creating Specific Parameter Fields (using the screen of Figure 2E), or by importing Parameter Fields from some other already defined Group (see below and Figure 2G). Figure 2F shows the GUI screen after the Creator has added a number of further Item Parameter Fields to the Bicycle Group.

Once a Group has been created, it is necessary to connect the new Group to existing Groups within the Group Hierarchy. Figure 3A illustrates by way of example a simple tree-like hierarchy for items. Primary categories include Vehicles, Art, Clothes, Collectibles, Electronics and Sports. Underneath the Vehicle Group are the Cars and Bicycle Groups. The Bicycle Group is also located under the Sports Group. TVs and Stereos are Groups located under the Electronics Group. Other groups may of course be defined. Items entered into the system may be directly associated only with Groups at the bottom of the tree, although this need not be the case and an item could be associated only with a top level or intermediate Group, e. g. Bicycles. Figure 3B illustrates the Group hierarchy after Creators have created a number of new Groups and connected them into the hierarchy. Figure 4 illustrates how a hierarchical view may be displayed to a User on the GUI of the system. Groups that are underlined are Groups that contain items on offer.

Figure 5 illustrates a screen of the GUI that may be used by a Group Creator to connect an established Group into the Group hierarchy. The displayed screen shows that the Bicycles Group exists under both the Vehicles and Sports Groups. The Creator of a Mountain Bikes Group chooses to add this Group underneath both of the existing Bicycles Groups. It is noted that the system operator may not allow new Groups to be added directly under the top-level Groups, e. g. Vehicles, Art, etc. These top-level Groups are therefore statically defined by the operator. Of course, permissions to connect new Groups may be allocated in a dynamic fashion, e. g. a Creator of a new Group may have permission to allow and disallow the connection of further new Groups beneath his Group.

A new Group may be connected to a specific Forum in which case the Group may only be visible and/or accessible to members of that Forum. This may be important when trading confidential Items. As such, different Users will see different Group Hierarchies, depending upon the Forums of which they members. Figure 2G illustrates a GUI screen that may be displayed to a Creator in the process of establishing a Mountain Bikes Group. As part of the Parameter Field selection process, the Creator chooses to import parameter fields from the existing Bicycle Group.

The Group structure and Hierarchy is language independent. A mechanism may be provided for a) specifying the language of creation of a new Group and b) for translating text of an existing Group into another language. The GUI allows a User to select a language from a language menu and, optionally, to add a new language. The User is then presented for example with a screen which shows on one side the various text fields of the existing group (Group Name, Group Description, Item Parameter Field Names and all the Parameter Field Descriptions), and corresponding but blank fields for the translation. The User completes the blank fields and submits the translation. The User might then have the option to translate text for groups higher up and/or lower down in the same branch of the tree. A User browsing the hierarchy (e. g. to enter a Have or a Want into the system) may select a particular language.

Examples of other Groups and their Item Parameter Fields are: Group name: Cell phones Item Parameter Fields:

Brand of the cell phone (drop down menu);

Model of the cell phone (drop down or free text);

Condition of the cell phone (drop down menu);

Age of the cell phone (drop down including "not known");

Included items, for example phone, charger, user's manual (check mark list);

Picture of the cell phone from different angles (two pictures required: top and back of the phone).

Group name: Time share trading Item Parameter Fields:

Country of the apartment (drop down);

City of the apartment (search or drop down); Address of the apartment (open text);

Size of the apartment (number (of sq. m.));

Number of rooms in apartment (number);

Number of persons apartment is suitable for (number);

Start date (date);

Length of stay offered (number of days).

An approval process may be implemented whereby new Groups and changes to existing Groups are submitted for approval. The submissions are reviewed and approved by another person (who could be another User, another creator User, a system administrator, or a specific service provider). After the approval the new Group, Item Parameter Fields, translation etc is published and brought into use. The approver may of course disapprove of a submission in which case the result is not brought into use. The approver may also give comments based on which the Creator can update the submission whereupon the approval process is repeated.

It is quite likely, indeed expected, that the product category tree will grow such that multiple Groups with very similar properties will exist in parallel. There will thus be a facility to merge Groups. The merge may be done by the system administrator, User, or one of the Group Creators. Permission to implement a Group merge may require a permission granted by the service administrator.

Figure 6 illustrates an alternative GUI screen that is presented to a User after clicking on a Create New Group link. This screen integrates much of the functionality of the screen set of Figures 2A to 2G. The "Add another parent" button may be used repeatedly to enter the new Group into the existing Group Hierarchy. A language selection dropdown menu is provided. The lower entry section allows multiple Item Parameter Fields to be added to the Group.

Figure 7 is a flow diagram illustrating a procedure for creating a Group. Figure 8 is a flow diagram illustrating a detailed procedure for searching for items or services catalogued using the Group Hierarchy structure. In this example, a user selects a first Item Parameter Field and enters a value, in this case "red" and views the results. Note that at this stage the system is searching across all groups. The user then refines the search in a stepwise manner by entering values into other Item Parameter Fields. Figure 9 is a flow diagram illustrating the search procedure at a more abstracted level.

An Item Parameter Field established for a Group will often comprise a set of User selectable entries, e. g. displayed as a drop-down menu on a search page of the GUI. Where a User wishing to add an item or service to a Group (either as a Have or a Want) finds no relevant entry in such a set, the User may add such an entry. Consider for example a User wishing to add a concert ticket to a concert ticket group. If the relevant concert is not contained in an existing set, the User enters the new concert as a new entry for the Parameter Fields. Of course, some "smart" functionality may be introduced into the system to allow it to recognise a new entry that is similar to an existing entry, i. e. to avoid the creation of duplicates in the set. For Groups such as concert tickets, it may also be useful to add a further Parameter Field indicating an expiry date for an item, e. g. the date of a particular concert.

It will be clear that allowing Users to create and modify Groups will result in a catalogue of items and services that classifies the items and services with a much greater degree of accuracy (than conventional trading systems) using "standard" definitions, reducing reliance upon free text descriptions. This in turn greatly increases the accuracy with which automatic searches of a catalogue can be performed.

The on-line barter system described above will typically be hosted on a secure web server or web server cluster operated by the service provider. However, implementation over a peer-to-peer type network might also be possible. Users access the service via the Internet using person computers, laptops, PDAs, mobile phones and the like. In some cases, a special application may reside in the client terminal in order to allow the service to be accessed.

Gerente de Relacionamento.

This chapter describes using Relationship Manager to view, create, and edit relationships among existing parties in the TCA Registry.

This chapter covers the following topics:

Relationship Manager Overview.

Use Oracle Trading Community Architecture (TCA) Relationship Manager to create and manage relationships among existing parties in the TCA Registry.

Note: You view and manage only parties of type Organization and Person in Relationship Manager.

Using relationships to model the interactions among parties in the TCA Registry helps you make better business decisions. For example, you can analyze and manage relationships with competitors and partners, or corporate relationships between subsidiaries and parent corporations.

In Relationship Manager, you get a comprehensive view of the roles that a single party plays with respect to other parties in the Registry, as well as a hierarchical view for hierarchical relationships. Aside from viewing relationships, you can create, edit, and end relationships.

Your administrator can set up Relationship Manager. See: Setting Up Relationship Manager, Oracle Trading Community Architecture Administration Guide .

Relationships Overview.

The TCA relationship model lets you record complex, real-life relationships among entities in the TCA Registry. You can analyze not only direct relationships such as those with your competitors, but also indirect ones such as your customers' customers. You can also manage hierarchical relationships to better understand, for example, the management hierarchy within an organization.

A relationship represents the way two entities interact with each other, based on the role that each entity takes with respect to the other. For example, the employment relationship between a person and an organization is defined by the role of the person as the employee and the organization as the employer.

In addition, every relationship is reciprocal. Each entity is either the subject or object, depending on the perspective, or direction. For example, if Joe is the employee of Oracle, then Joe is the subject and Oracle is the object. Oracle as the employer of Joe, which flips the subject and object, still describes the same relationship.

Relationship Phrase and Role Pairs.

A relationship phrase and role pair contains a correlating phrase pair and role pair, which describes the reciprocal roles that the two entities play in the relationship. For example, a relationship phrase and role pair contains the Employee Of and Employer Of phrase pair as well as the Employee and Employer role pair.

Every relationship is based on a relationship phrase and role pair. Even though only phrase pairs are used in Relationship Manager, the corresponding role pair is still stored in the system for each relationship.

A phrase pair, such as Employee Of and Employer Of, describe the role of either entity in the relationship as the subject. For example, Joe as the subject of the relationship would have Employee Of as the phrase, and Oracle as the subject would have Employer Of. The other entity in the relationship would be the object.

A relationship role pair, such as Employee and Employer, describes the two entities no matter the direction of the relationship. For example, Joe has the Employee role and Oracle the Employer role, both as either the subject or object.

Each relationship phrase and role pair also determines the type of entities for the relationship. For example, the Employer Of phrase and Employer role can be defined so that the employer must be a party of type Organization and the employee a party of type Person.

When you create a relationship with a relationship phrase or role, the reverse direction of the relationship is automatically created with the other phrase or role in the pair. For example, if you define Joe as the employee of Oracle, Oracle as the employer of Joe is also created.

Relationship Type.

Each relationship phrase and role pair belongs to a relationship type, which categorizes the types of relationships that you can create. For example, the relationship phrase and role pair described above would belong to an employment relationship type.

Relationship types determine if the relationships created with the type are hierarchical, and if not, whether they can be circular or not. For more information, see: Relationship Characteristics.

Every relationship type must contain at least one phrase and role pair. TCA provides seeded relationship types and phrase and role pairs, but your administrator can create new ones as needed. See: Administering Relationships, Oracle Trading Community Architecture Administration Guide and Seeded Relationship Types, Phrases, and Roles, Oracle Trading Community Architecture Reference Guide .

Relationship Date Range.

Both directions of a relationship share a start and end date. The start date signifies when the relationship starts, not necessarily when it was created. Likewise, the end date is when the relationship ends.

Relationship Group.

Note: Relationship groups do not apply to Relationship Manager. All seeded and user-created relationship phrases are available.

Relationship Characteristics.

Relationships have additional characteristics that relationship types determine.

Hierarchical Relationships.

Circular Relationships.

Hierarchical relationships cannot be circular. For example, if Alan's manager is Jenny, and Jenny's manager is Chris, then Chris's manager cannot be Alan.

Nonhierarchical relationship types can either allow or prevent circular relationships. For example, marital relationships cannot be circular, while competitive relationships described above can.

Major Features.

Relationship Manager provides these features for relationships between existing parties in the TCA Registry:

Search for the party that you want to manage relationships for.

View the party's basic party information and any available additional details.

View the relationship types that the party is involved in.

View the relationships that the party belongs to for specific types.

View the hierarchy of a hierarchical relationship type.

Create relationships, available when you view the relationship types, relationships, or hierarchies of the party.

Edit existing relationships, including ending the relationship.

Relationship Hierarchy.

For any party in the hierarchy, you can:

Update its relationship by moving the party to another part of the hierarchy.

Create new relationships.

View additional party information, if available.

Party Relationship Management Process.

This diagram describes the general process flow of managing party relationships with the Relationship Manager.

Search for the party that you want to view and manage relationships for and select the party from the search results. See: Searching for Parties and Viewing Results.

Note: If you want to see a relationship hierarchy, keep in mind that the party you search for is the root of the hierarchy.

View the party's overview information as well as the relationship types that it is involved in.

From here, you have three options:

View relationships of selected relationship types. See: Viewing Relationships.

Create new relationships with a relationship type that the party is not currently involved in. See: Creating Relationships.

After you create relationships, Relationship Manager takes you back to view the party's information and relationship types.

View the hierarchy of a hierarchical relationship type. See: Viewing Relationship Hierarchies.

If you choose to view relationships, you can also:

Create new relationships with a relationship type that you are viewing. See: Creating Relationships.

Edit the existing relationships that you are viewing. See: Editing Relationships.

After you edit or create a relationship, Relationship Manager takes you back to view the relationships.

If you choose to view a hierarchy, you can also:

Create relationships for any party in the hierarchy, using the relationship type of the hierarchy. See: Creating Relationships.

After you move parties or create relationships, Relationship Manager takes you back to the hierarchy view.

Searching for Parties and Viewing Results.

Use the Party page to search for and select the party that you want to view and manage relationships for. This search includes parties of type Organization or Person.

From the search results, you select the party that you want and bring up the Overview page. View the party's overview and relationship type information, including:

The relationship types that the party is involved in.

The number of relationships for each type.

Whether the relationship type is hierarchical or not.

Whether the type allows circular relationships or not.

If available, you can access more information about the party from the Additional Details field.

From the Overview page, you can choose to:

Note: You can also access the Overview page from other pages in Relationship Manager by clicking the party name.

Viewing Relationships.

Use the View Relationships page to view the relationships of the selected party. You can view relationships for some or all of the relationship types that the party is involved in.

To view relationships for a party:

Navigate to the Overview page for the party that you want to view relationships for. See: Searching for Parties and Viewing Results.

Select at least one relationship type and click the View Relationships button.

The View Relationships page displays relationships for the party within your selected relationship types.

You can choose to:

Creating Relationships.

Use the Create Relationships page to create new relationships between existing parties in the TCA Registry. You can choose to create relationships from three pages:

Overview: Create relationships with a relationship type that is not displayed for the party, which would be the subject of the new relationship.

View Relationships: Create relationships with any of the selected types that you are viewing for the party, which would be the subject of the new relationship.

Hierarchy: Create relationships with any of the parties in the hierarchy as the subject, using the relationship type of the hierarchy.

To create relationships:

Navigate to the Overview page for the party that you want to create relationships for. See: Searching for Parties and Viewing Results.

Tip: You can also create relationships for any party in a relationship hierarchy. See: Viewing Relationship Hierarchies.

The Create Relationships page displays your selected relationship type as the type for the new relationship, and the selected party is the subject party.

Select a relationship phrase and object party for the relationship, with respect to the subject party.

Optionally change the start date of the relationship, which defaults with the current date.

If you use the current date, the relationship's start time is the system time. If not, the start time is at the beginning of the start date.

Optionally enter an end date.

The relationship's end time is at the end of the end date.

Click the Add Another Row button to create another relationship for the subject party with this same relationship type. Repeat steps 4 through 6.

Click the Apply button.

The confirmation takes you back to the page from where you chose to create relationships. Your new relationships are reflected in that page.

Editing Relationships.

To edit a relationship:

Navigate to the View Relationships page for a party with the relationships that you might want to edit. See: Viewing Relationships.

Click the Edit icon for the relationship that you want to edit.

Note: You can edit only relationships with the User Entered source.

In the Edit Relationship page, change the relationship phrase, start date, end date, or any combination of the above.

Click the Apply button.

The confirmation takes you back to the View Relationships page, where you can see the results of your changes.

Viewing Relationship Hierarchies.

Your selected party is the root at the top of the hierarchy. You can see its children, or parties ranked lower in relationships, but not its parents.

The hierarchy represents a structure of relationships for the date that you specify in the As Of field. The hierarchy displays all relationships that fit both of these criteria:

The start date is before or the same as the as of date.

The end date is after the as of date, or no end date exists.

This table shows an example of three relationships and their date ranges.

This table shows examples of which relationships the hierarchy would display depending on the date in the As Of field.

For each node in the hierarchy, Relationship Manager displays the party's:

Name and Registry ID.

Relationship phrase with respect to its parent party.

Parent party name.

If you have batch loaded data or acquired the Enterprise Management GDP through online purchase, you can also view the corporate hierarchy that D&B provides. See: D&B Hierarchy.

To view a relationship hierarchy:

Navigate to the Overview page for the party that you want to view relationship hierarchies for. See: Searching for Parties and Viewing Results.

Note: Search for and select the party that you want as the highest level, or root, in the hierarchy.

Click the Hierarchy icon for the relationship type that you want to view. Hierarchies are available only for hierarchical relationship types.

Enter the date that you want to view the hierarchy for in the As Of field and click the Go button. By default, the hierarchy is displayed for the current date.

To view the relationships within the hierarchy, click the arrows to expand or collapse levels.

Click the Details icon for the party that you want to view additional information for, if available.

Repeat steps 3 to 5 as needed.

From the Hierarchy page, you can choose to:

Note: You cannot update the D&B hierarchy by moving parties within the hierarchy.

D&B Hierarchy.

Parent Of and Subsidiary Of.

Headquarters Of and Division Of.

Domestic Ultimate Of and Domestic Subsidiary Of.

Global Ultimate Of and Global Subsidiary Of.

Important: Do not use the Create Relationship API to create D&B hierarchy relationships. See: Create Relationship API, Oracle Trading Community Architecture Technical Implementation Guide .

D&B Hierarchy Examples.

These examples illustrate how the information that you acquire from D&B appear in Relationship Manager as the D&B hierarchy.

With the information that you acquire from D&B for the branch, Relationship Manager displays the D&B hierarchy as shown in this table:

With the information that you acquire from D&B for the branch, Relationship Manager displays the D&B hierarchy as follows in this table:

With the information that you acquire from D&B first for Example 1 and then 3, Relationship Manager displays the D&B hierarchy as follows in this table:

Updating Relationships by Moving Parties in a Hierarchy.

Note: If you need to change start or end dates after moves, use the Edit Relationships page. See: Editing Relationships.

This diagram shows the hierarchy before and after the move:

To update relationships by moving parties in a hierarchy:

Navigate to the Hierarchy page for the hierarchy that you want to view and manage. See: Viewing Relationship Hierarchies.

Important: To ensure accurate results when you move parties, use the current date as the as of date. All moves are based on the hierarchy as it is today.

Select the party or parties that you want to move and click the Move button.

Note: You cannot move parties with the relationship start date in the future.

In the Move Parties page, expand the hierarchy as necessary to find the new parent party.

Select the new parent party and click the Apply button.

The confirmation takes you back to view the results of your move in the updated relationship hierarchy.

User Hierarchy ( Use Case Diagram (UML))

usecase case uml tech software.

Tipo de diagrama:

Diagrama de Casos de Uso (UML)

Diagramas Relacionados.

Por Creately Templates.

Use o modelo de caso de um sistema ATM.

Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.

Atualizado: 6 meses atrás.

Por Creately Templates.

Use o modelo de diagrama de caso do sistema de pedidos de restaurante.

Tagged: caso de uso, caso de uso de restaurante, uso de ordem de restaurante, caso de uso do sistema de pedidos, modelos de casos de uso, modelo de uso, caso de uso de uml.

Atualizado: 6 meses atrás.

Por Creately Templates.

Use o modelo de caso de um sistema de agenciamento de viagens.

Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.

Atualizado: 6 meses atrás.

Por Creately Templates.

Modelo de Exemplo de Diagrama de Casos de Uso do Sistema de RH Online.

Tagged: caso de uso hr sistema, caso de uso do sistema hr, sistema de hr online, caso de uso, diagrama de usecase, modelos de casos de uso.

Atualizado: 2 anos atrás.

Por Creately Templates.

Diagrama de caso de uso Modelo de rede celular Cenário fazendo e recebendo chamadas.

Tagged: usecase, caso, uml, tecnologia, software, caso de uso de rede móvel, caso de uso de rede celular, caso de uso de celular, caso de uso para celular, modelo de caso de uso, modelos de usecase, caso de uso, uml usecase.

Atualizado: 2 anos atrás.

Por Creately Templates.

Use o modelo de diagrama de caso do sistema de negociação financeira.

Tagged: caso de uso, caso de uso de negociação, usecase de negociação financeira, caso de uso de ordem financeira, modelo de caso de uso, modelos de uso.

Afiliação de opções binárias Mato Grosso do Sul

Wednesday, 18 April 2018

Hierarquia de usuários do sistema de negociação

No comments:

Post a Comment