|
|
|
DICAS |
|
Função EnviaEmail |
Na função EnviaEmail, utilizada em Regras e no Gerador de Relatórios, existem comportamentos diferentes de acordo com cada cenário, quando entre os e-mails dos destinatários há e-mail inválido.
Abaixo estão descritos os cenários que representam o comportamento da função:
Cenário 01:
Envio de e-mail para endereços corretos.
1. Deseja-se enviar um e-mail para joao@senior.com.br;
2. A rotina envia o e-mail sem problemas;
3. joao@senior.com.br recebe o e-mail.
Cenário 02:
Envio de e-mail para endereços corretos, porém com no mínimo um endereço incorreto de outro servidor.
1. Deseja-se enviar um e-mail para os endereços:
a) joao@senior.com.br (existe)
b) maria@teste.com.br (não existe)
2. A rotina envia o e-mail para o endereço que existe;
a) joao@senior.com.br recebe o e-mail.
3. O provedor teste.com.br está programado para retornar um aviso ao remetente informando que maria@teste.com.br não existe;
4. O remetente recebe o aviso.
Obs.: Alguns provedores podem estar programados para não retornar o aviso, logo o remetente não o receberá.
Cenário 03:
Envio de e-mail para endereços corretos, porém com no mínimo um endereço incorreto do próprio domínio.
1. Usuário Pedro utiliza o domínio de e-mails da Senior (senior.com.br);
2. Deseja-se enviar um e-mail para os endereços:
a) jose.silva@senior.com.br (existe)
b) jose@senior.com.br (não existe)
3. O servidor da Senior retorna um código maior que 400, que caracteriza erro, informando quejose@senior.com.br é um usuário inexistente.
4. A rotina entra em uma exceção e não finaliza o envio do e-mail - ninguém recebe.
Cenário 04:
Envio de e-mail para endereços corretos, porém com no mínimo um endereço inválido.
a) Para a rotina, um endereço inválido é aquele que não possui pelo menos um ponto e o @.
1. Deseja-se enviar um e-mail para os endereços:
a) joao@senior.com.br (existe)
b) joaoteste.com.br (inválido)
c) jose (inválido)
2. A rotina valida esses endereços (antes de enviar os comandos de endereços de e-mail ao servidor);
3. É gerada uma exceção e o envio não é finalizado - ninguém recebe.
Cenário 05:
Envio de e-mail para endereços corretos, porém com no mínimo um endereço de um domínio que não existe.
1. Deseja-se enviar um e-mail para os endereços:
a) jose.silva@senior.com.br (existe)
b) jose@ceniorinv.com.br (servidor não existe)
2. A rotina envia o e-mail para o endereço que existe;
a) jose.silva@senior.com.br recebe o e-mail.
3. O remetente recebe o aviso de que o servidor ceniorinv.com.br não existe.
Obs.: Alguns provedores podem estar programados para não retornar o aviso, logo o remetente não o receberá.
O comportamento da rotina considera todos os endereços - dos campos "Para", "Com cópia" e "Com cópia oculta".
Local:
Recursos > Implementações > Gerador Relatórios Recursos > Implementações > Gerador Telas Recursos > Implementações > Editor Regras |
|
|
Função que busca o IP de origem da marcação do Captura Ponto Web |
É possível descobrir o IP de origem da marcação registrada no Captura Ponto Web através de uma regra por processo.
A função WRemoteAddr poderá ser utilizada na regra por processo 306 - Gravar Marcações no Captura Ponto Web. Essa função retorna o endereço IP da estação que está acessando o sistema e pode ser utilizada apenas nos sistemas Web.
Local:
Ronda Ponto > Ajuda > Conteúdo e índice > Pesquisar por WRemoteAddr |
|
|
Integração Rubi x Sapiens – Cadastro do Fornecedor |
Ao alterar qualquer informação na Ficha Complementar de um terceiro, quando há integração com o Sapiens, o sistema emite uma mensagem perguntando se o usuário deseja alterar informações do Fornecedor. Quando o usuário confirma ocorre o erro “Erro ao gravar histórico do fornecedor!”.
Esta situação foi identificada na versão 5.5.3.1, e já está sendo tratada. Como contorno, é necessário alterar alguma informação na Ficha Básica do terceiro antes de alterar a Ficha Complementar. Se a empresa e a filial forem as mesmas, basta usar este contorno uma vez, depois será possível atualizar todos os fornecedores para a empresa/filial através da Ficha Complementar.
Local:
Colaboradores > Ficha Cadastral > Complementar |
Integração Rubi x Sapiens – Projeto e Fase |
Ao efetuar a Integração Financeira com Projeto e Fase, foi verificado na tabela R047PER que os campos CodPjr e CodFas eram apresentados sem nenhum registro. A Integração Financeira é realizada com sucesso no Rubi, mas ao realizar a baixa dos títulos no Sapiens, o sistema consiste que falta ser informado o rateio.
Em Colaboradores > Ficha Cadastral > Terceiros, guia Projetos, foi verificado que existia uma data de alteração em 01/06/2011 com a opção “S” no campo Controla Projeto/Fase, sendo que a RPCI (Recibo de Pagamento ao Contribuinte Individual) deste Terceiro foi lançada com competência 06/2011, mas no momento de realizar a Integração Financeira o cálculo ativo selecionado era referente a competência 05/2011.
Nesta situação, o sistema busca a competência do código de cálculo ativo ao realizar a Integração Financeira e não a competência de lançamento da RPCI e como não encontrava histórico de controle de Projeto/Fase em 05/2011 lançava os campos CodPjr e CodFas zerados.
Local: Integração Sapiens > Integração Financeira > Integração Financeira |
|
|
| Relatórios de PPRA por GHE |
Ao emitir os relatórios SMGH003.GER e SMGH006.GER do menu Segurança > PPRA por GHE > Listar as informações do agente e demais dados abaixo não estão sendo demonstrados, somente é impresso o GHE e os respectivos Locais e Cargos ou Posto de Trabalho.
Verificamos que esta situação ocorre porque estes modelos de relatório estão exigindo a informação da Data de Término da Vigência da Revisão do GHE, cadastrada em Segurança > PPRA por GHE > Revisão do GHE, campo Vigência.
Esta situação já está sendo tratada. Como contorno para emissão destes relatórios, basta informar a data de término no campo Vigência da Revisão do GHE.
Local:
Segurança > PPRA por GHE > Listar |
|
|
|
Se não deseja mais receber este e-mail de Dicas, clique aqui. |
|
|
|
|
|
Nenhum comentário:
Postar um comentário