Marcia Borchardt

Na ajuda do sistema tem um roteiro para pagar adiantamento "Roteiro para pagar adiantamento" talvez esclareça alguma dúvida inicial

Obrigada pelo retorno. Farei testes apos a inclusao da filial.

Saudações a todos, Vamos implantar uma nova filial. Alguns funcionários irão trabalhar em duas filiais. O RH vai fazer dois registros destes funcionários, um para cada filial. Está é a maneira correta para proceder nestes casos?

Quando abri chamado na TOTVS recebi este retorno: O TRATAMENTO DE RECEBIMENTO OU PAGAMENTO VIA CARTÃO DE CRÉDITO AINDA NÃO ESTA CONTEMPLADO PELO RM FLUXUS. O CAMPO REFERENTE AO EVENTO CONTÁBIL PARA CARTÃO DE CRÉDITO JÁ FOI CRIADO PARA SER INCORPORADO NA FUTURA IMPLEMENTAÇÃO. A CONTABILIZAÇÃO PODERÁ SER TRATADA DE ACORDO COM O PROCESSO INTERNO DA EMPRESA. ESSA FUNCIONALIDADE SERÁ IMPLEMENTADA APÓS A MIGRAÇÃO DA BAIXA PARA .NET QUE SERÁ CONCLUIDA NO 2ºSEMESTRE DE 2011.

Fazer uma varredura dos eventos que compoem o movimento dos funcionários no mês e verificar se algum evento que contabiliza e não provisiona. Primeiramente, definir o que está correto: o valor da provisão ou o valor da contabilização. Em segundo: fazer a contabilização de um único funcionário e analisar para descobrir a diferença.

O campo complemtar é uma alternativa. Porém não fica registrado um histórico dessa avaliação. Sempre será a última avaliação.

select trunc((((VALORORIGINAL - VALOROP5 - VALORDESCONTO) + (VALORJUROS))* power(1 + (0.0333 / 100), CASE WHEN :ESPELHO#2_N > 0 THEN :ESPELHO#2_N ELSE 0 END)) + case WHEN :ESPELHO#2_N > 0 then ((VALORORIGINAL - VALOROP5 - VALORDESCONTO)* 0.02) else 0 END,2) END VALORLIQUI from flan where idlan = :ESPELHO#1_N ESPELHO2 é a diferença entre a data atual e data de vencimento do título. 0.0333 é taxa de juro ao dia que, no caso, é de 0,333% 0,02 é a taxa de multa, 2%

Eu fiz da seguinte maneira: criei uma tabela com a relação dos alunos inscritos no censo. Cada registro armazena o cpf, número de matrícula e os dados pessoais do aluno que o MEC solicitou. Depois criei um relatório no gerador com duas LD's: uma contendo uma consulta SQL dos dados da tabela criada e na outra LD incluí uma segunda consulta SQL com dados do curso do aluno, passando como parâmetro o número de matrícula. Foi super rápido e, inclusive, já foi validado pelo sistema do CENSO.

Acho que é em utilitários/ avisos automáticos.

Aqui na Instituição nós utilizamos o sistema Ronda/Senior nos relógios pontos. Porém temos que mandar todas as atulizações do Chronus para o relógio. Nâo existe uma integração. A nova portaria não permite o bloqueio da batida.

Ele enivaram uma DLL do processo seletivo para arrumar um problema. O sistema não permitia o cadastro de um processo seletivo.

Uma das mudanças que sugiro: - o cliente precisa editar o produto para informar o valor do produto cotado e salvar em cada produto. Antes de fechar a cotação, ele precisa salvar novamente. Eu sugiro que o cliente digite os valores dos produtos cotadas na tela onde aparece a listagem dos produtos. Empresas que contam, pro exemplo, 30 itens, a empresa que fará a cotação precisa editar cada produto para fornecer o valor da cotação. - o cliente não recebe um retorno se a cotação foi enviada com sucesso.

Pelas informnações contidas na ajuda, não é possível renomear usuário devido ao campo controle. Crie um usuário novo e renomeie via banco de dados. Acredito que irá aparecer a seguinte mensagem: CRC inválido.

Pelo que entendi, o total sempre será dividido por 300 e este valor irá gerar a quantidade de pacotes. Se for isto, pode fazer a seguinte maneira: gera uma tabela com 100 registros, por exemplo. Vamos chamá-la de NUMEROS. Depois faz assim: select pacotes.*, n,resultado from (select cliente, pedido, total de volumes/ 300 resultado from /*executa aqui a tua sententeça*/ ) pacotes ,(select n from numeros) num where n <= resultado;

Ao enviar a cotação on-line para o fornecedor, o mesmo recebe um login e uma senha. O desempenho/performance da cotação on-line é baixa. A interface para o usuário não é amigável.