Regras de afectação das impressoras ao lançamento de uma lista
Introdução
No momento de lançamento de uma lista, um valor por defeito pode ser proposto de maneira automática em função do contexto para indicar o destino de edição (impressora, ficheiro, mensagens...). Este valor por defeito pode provir do utilizador, da listam do estabelecimento... com um conjunto de regras de prioridade sofisticada Este documento descreve as regras e as prioridades de afectação das impressoras em função do contexto.
Pré-requisitos
Diferentes parâmetros podem ser descritos para gerar as afectações de impressoras :
A tabela dos destinos permite de definir as impressoras disponíveis para os utilizadores, assim que o tipo de saida associado Notemos que o tipo de saída é o menu local numéro 22, que é parametrizável.
A parametrização dos utilizadores que permite definir uma tabela dos destinos por defeito e por tipo, seja directamente, seja fazendo referência a outro utilizador.
O dicionário das listas definindo as listas com destino por defeito, um tipo que servirá de filtro (excepto se se trata do primeiro valor que está chave mestra), e uma fórmula permitindo exprimir o valor do complemento descrito as seguir.
A tabela dos destinos por utilizadorr, que definie as regras as mais finas de afectação de destino (por triplo utilizador, complemento, lista).
Regras de afectação detalhadas
Uma primeira observação está a fazer. Antes toda a afectação de destino, estes dois casos particulares permitindo definir uma impressora de maneira particular :
O ponto de entrada DEFIMP está utilizado por um desenvolvimento específico, o código chamado pode impor um destino a partir de regras particulares. Este ponto de entrada, priotitário, foi chamado em fim de algoritmo (sabe-se qual impressora terá sido escolhido por defeito em aplicando todas as outras regras).
O programa chamador (se a impressão foi chamada directamente por um tratamento) pode impor o destino.
Se se execeptue estes dois casos particulares, as regras de afectaçaõ são definidas a seguir. O algoritmo começa por determinar os três valores seguintes :
No dicionário das listas, um Tipo de saída está definido. O algoritmo de determinação a seguir não vai pesquisar que uma destino do tipo correspondemte se o tipo de pedido na lista não o primeiro da lista (de outro modo dito, se o destino encontrado não tem bom tipo, a pesquisa continua). Falta bem entendido igualmente que o destino seja activo, e que o utilizador tenha o direito de utilizar - é o acesso em execução sobre o código associado ao destino se for o caso disso. Se o destino não está neste caso, a pesquisa continuará.
Se a zona Fórmula complemento está registado no dicionário das listas, avalia-se o resultado da fórmula , que está chamado complemento. O complemeto pode estar um exempo um código de estabelecimento, se a lista lançada se lança para os dados de um estabelecimento Assim, o destino utilizado poderá depender do estabeleciento afectado por edição. Se a zona Fórmula complemento não está registada, considera-se que o valor complemento está vazio. Na fórmula de cálculo utilizado, pode-se colocar : constantes, funções, o valor de um parâmetro de lista pela sintaxe PARAM(NOMPARAM), ondeNOMPARAM é o código do parâmetro tal que é definido no dicionário da lista, as variáveis cujo aquelas que são registados no contexto - por exemplo o estabelecimento por defeito de um utilizador para um dado módulo, que pode ser encontrado no quadro GFCYDEF...
Enfim, na seguda, utiliza-se como parâmetro de determinação o código do utilizador conectado, excepto se, na sua ficha, existe um outro código utilizador na zona Destinos utilizador (para este parâmetro permite definir que um utilizador tenha as mesmas regras de afectação que um outro utilizador modelo). Pode existir as indirecções sucessivas sobre o código utilizador, mas em caso de anelagem na lista, toma-se como código utilizador de partida.
Os três valores (tipo de saida pesquisada, valor código complemento, código utilizador) sendo deteminadas, as regras de determinação está então o seguinte :
Refere-se à tabela dos destinos por utilizador. Se existe uma linha nesta tabela para a lista corrente, o código utilizador afectado, e o valor de complemto calcuçado precedentemnte, é o destino definido sobre a linha que vai ser utilizada.
Se nenhum valor está encontrado para o triplo, e se o valor do complemento avaliado não está vazio, refere-se todo de mesmo a esta mesma tabela em pesquisando uma linha com o código utilizador e o código estado idóneo, e com a zona complemento vazio (se a zona complememnto estando vazio, ter-se-á realizado a pesquisa à etapa precedente ). Se uma linha existe, toma-se o destino correspondente.
Por defeito, toma-se o destino definido na ficha da lista (se ela existe).
Se o destino não está sempre encontrado, toma-se o destino do bom tipo definido sobre a ficha utilizador (se ela existe)
Se o destino não está sempre encontrada, pesquisa-se o destino do bom tipo associado ao estabeleicmento por defeito de utilizador (parâmetro PRT1, PRT2, PRT3, PRT4). O estabelecimento do utilizador depende à vez do seu perfil função, e do módulo ao qual a lista pertence. Esta pesquisa se faz bem entendido em utilizando as regras habituais de hirarquia estabelecimento/sociedade/dossier para os valores parâmetros.
Por defeito, se um lançamento em batch está feito, escolhe-se o primeiro destino do bom tipo. Se está em edições directa depois um posto de trabalho, o primeiro destino de tipo Pré-visualização será proposto.
Se o destino foi definido na tabela dos destinos por utilizador ou num dicionário das listas, uma check box Obrigatório lhe está associado Se ela não está assinalada, o destino assim detrerminado não foi obrigatório, e o utilizador pode então alterar de destino ou redefinir aquele em escolhendo destino/servidor/nome de impressora/características. Um destino determinado a partir das outras regras não está jamais considerado como obrigatório.