Linkedin

Total de visualizações de página

domingo, 4 de setembro de 2011

O Manual da Reunião Efetiva


Agendamento a tempo. Existem as reuniões de emergência, mas também existem as que ocorrem em cima da hora porque algum gestor não se organizou.
A antecedência necessária depende do tema e contexto: às vezes, 30 minutos de antecedência podem ser suficientes, e em outras vezes 48h pode ser pouco. Mas reuniões marcadas com 5 minutos de antecedência não produzirão decisões tão eficientes quanto as marcadas com tempo suficiente para os participantes reunirem e atualizarem informações.
Horário para encerrar. Toda reunião previamente agendada tem horário para iniciar, mas é comum não haver previsão de horário para encerrar.
Algumas reuniões (por exemplo, assembleias realizadas entre pares, como as de condôminos ou trabalhistas) não devem mesmo encerrar sem ser por comum acordo, mas uma reunião de equipe de projeto ou entre membros de uma mesma organização pode e deve ser planejada para caber em um determinado horário, e a existência de uma hora marcada para o seu fim pode ser um instrumento adicional para manter a objetividade nas discussões.

Pauta preliminar. Todas as pessoas chamadas a participar devem saber, já no primeiro contato verificando sua disponibilidade para participar da reunião, quais os assuntos que serão tratados, e qual o objetivo de quem está promovendo o encontro (É para comunicar algo? Para decidir algo? Muda o que já se planejou?), para que possam responder e se preparar adequadamente.
Definir uma pauta inicial, ainda que bem simples – pode ser distribuída em um simples e-mail informal – é essencial.

Pauta definitiva. Quando a reunião já estiver completamente agendada, é hora de divulgar uma versão mais completa da pauta, incluindo os temas originais e possíveis outros temas adicionais que tenham sido sugeridos por outros participantes, local e horário (de início e fim), e lista de quem estará presente.

Elenco de apoio: quanto maior o número de participantes sem interesse direto no assunto que estiver sendo tratado, maior será a complexidade (desnecessária!) da comunicação na reunião. Se você tem uma pauta bem definida, pode dispensar os participantes que foram chamados apenas para um ponto específico dela, assim que este ponto for tratado. Deixe isso claro desde o princípio, para que todos vejam isso como um ponto positivo, e não como uma rejeição!

Reunião não é sinônimo de assembleia. Pessoas que você gostaria que participassem da reunião apenas para que estejam informados, ou para o caso de terem alguma opinião, em geral podem fazê-lo apropriadamente a partir da leitura da pauta e da ata.
Uma reunião só com as pessoas envolvidas diretamente tem mais chances de ser produtiva – mas cuidado para não sofrer um “choque de realidade” pós-reunião: chame para o encontro também as pessoas que compreendem os detalhes práticos das situações em análise, e não apenas os tomadores de decisão.

Telefonemas e interrupções. É uma constante: quem está em uma reunião geralmente preferiria estar em outro lugar, e tem outras obrigações ocorrendo em paralelo.  A cortesia manda não deixar o celular levar vantagem: quem abriu mão de seus compromissos para estar no mesmo ambiente que você deve ser privilegiado com a sua atenção.
Mas a cortesia não basta: é importante haver uma política clara quanto ao tratamento de ligações, torpedos, etc. É aceitável lidar com eles no próprio ambiente da reunião? É preferível sair da sala? Ou eles devem ser ignorados por toda a duração do encontro? Exceções são inevitáveis, mas a regra para os casos normais, quando definida, é melhor que o improviso e a incerteza.

Cuidado com os detalhes de implementação. Quando a reunião ocorre entre pessoas que conhecem operacionalmente (a fundo ou não) o assunto em discussão, é comum que as discussões sobre “como” fazer algo sejam muito mais saborosas do que a mera decisão sobre “o que” fazer, que normalmente é o objeto da reunião.
Assim, quase ninguém resiste a entrar neste debate (“em que linguagem vai ser?”, “com qual ferramenta?”, “qual a potência do motor?”, “no meu tempo isso era feito com arquivos-texto”, etc) logo após a decisão sobre “o que” fazer ter sido tomada. Só que isso tende a fugir da pauta, a não envolver todos os presentes, e até a adiantar perigosamente decisões técnicas que deveriam ser feitas com mais análise.
Se você notar que isso está ocorrendo, proponha uma reunião (não no mesmo dia!) para tratar especificamente do assunto, e prossiga com sua pauta original!

Polarização e monólogos. A não ser que alguns participantes tenham sido designados como ouvintes, reuniões devem garantir voz e vez a todos os integrantes, pois as conclusões comprometerão igualmente a todos.
Ao perceber que um debate está se polarizando ou mesmo que algum participante está tentando impedir que outro conclua suas ideias, intervenha! Certifique-se que todos terão oportunidade de se expressar, se possível sem limitar o direito de réplicas.

Temas fora da pauta. Se durante a reunião surgirem temas não conexos aos da pauta mas apropriados ao público presente, o secretário deve tomar nota deles, e a reunião prossegue sobre os pontos originais da pauta.
Ao final da reunião, com base nas anotações, os temas extras podem ser colocados em discussão, ou agendados para ocasião futura (e este agendamento também deverá constar na ata ou registro da reunião).

Secretaria é essencial

Toda reunião precisa de um secretário ou secretária previamente designado. Pode ser um dos participantes, que recebe esta atribuição adicional, ou uma pessoa que não participa das deliberações da reunião em si (embora esteja presente), mas fica encarregada de secretariá-la.
O papel do secretário é simples, mas exige atenção: ele deve ficar encarregado de acompanhar os pontos da pauta, para certificar-se de que serão todos discutidos, tomar notas sobre as decisões relacionadas e gerar uma ata ou resumo sumarizando-as – logo após a reunião.
Idealmente, antes de encerrar a reunião o secretário deve ser convidado a ler suas anotações sobre as decisões tomadas, para certificar-se de que todos os presentes têm o mesmo entendimento (naturalmente eles terão outra oportunidade para confirmar se concordam também com a ata ou registro, após sua produção).
O ideal é haver um mecanismo previamente definido sobre a forma de divulgar esta ata: todos precisam assinar, ou apenas a autoridade responsável pela reunião? É um documento público ou não? Quanto mais firme for esta política, mais automática será a difusão das informações da reunião. Como um bônus adicional, o secretário pode ficar encarregado de propor fazer a pauta avançar ao perceber que está sendo dedicado muito tempo a algum problema secundário.
Modelo de ata de reunião
O modelo de ata do Efetividade.net está à disposição, mas sabemos que em reuniões de equipe nem sempre é necessário seguir o velho modelo formal de ata: um registro simples (ou o chamado “resumo executivo”), com uma descrição informal em texto livre, é suficiente para preservar a memória da reunião.
Mas, seja qual for o modelo, os itens abaixo não podem faltar na sua ata ou registro de reunião:
  • Tema da reunião
  • Motivo da sua realização
  • Data, horário, duração e local em que se realizou
  • Quem a conduziu (se for o caso), quem secretariou e quem esteve presente
  • Tópicos discutidos e decisões tomadas
  • Para cada decisão registrada, idealmente deve constar qual será a próxima ação e quem entre os presentes é o responsável por ela
Fonte :

http://www.efetividade.net/2011/05/02/reuniao/

Tipos de dados

Primitivos


Tipos primitivos de dados, são aqueles fornecidos pelas linguagens e que não serão, necessariamente, os mesmo em todas as linguagens. A linguagem funcional Haskell, por exemplo, apresenta tipos primivos muito interessantes. Os tipo primitivos mais comuns são:

int -> tipo de dado que representa um numero inteiro: 23, -1989, etc


real -> tipo de dado que representa um ponto flutuante: 3.0, -8.76, etc

caracter - > tipo de dado que representa um ou mais caracteres entre aspas simples ou dupla. Também conhecido como alfanumérico.
lógico - > tipo de dado logico que só pode assumir dois valores: verdadeiro ou falso ideal para estruturas de teste.

De um modo geral, os tipos inteiro, real e caracter (que armazena só um caracter) apresentam as mesmas características em várias linguagens.

sexta-feira, 2 de setembro de 2011

Linguagem Natural/fluxo/linguagem ual

linguagem natural
O inicio do algoritmo começa a primeira ordem e terminal com a ultima ordem, Você poderá, ou nao, numerar os passos.
fluxograma
estrutura basica
inicio -> a sequencia de passos devera estar compreendida  os simboloes de inicio e de fim.

linguagem UAL.
Estrutura basica
Todos os comandos serao colocados apos o comando prog e antes do comando fimprog
inicio
prog nome
o nome do algoritmo é obrigatorio e só poderá ter letras e numeors
fim
fimprog
comando que finaliza o algoritmo. não tem parâmetro.


os caracteres de controla \n e \t são usados com o comando imprima para que o programador tenha poder de decidir onde o dados.

quando você está digitando no word, muitas vezes pressionada a tecla enter para passar par aa próxima linha. é exatamente isso que representa \n, a tecla 'enter'

quando você quer fazer o parágrafo de forma mais rápida, pressiona tab  e o cursos se desloca para uma columa pré-determinada. em programação, geralmente, essas colunas são 1 9 17 25 33 41 49 57 65 73 e chamamos de zona o conjunto de 8 colunas.

operador
+
adição
2 + 3
-
subtração
14-5
*
multiplicação
4 * 3
/
Divisão real
20/3 ou 20/3.5
div
divisão inteira
8 div 5
%
resto da divisão inteira
30%4
**
Potencialização
2**3



segunda-feira, 29 de agosto de 2011

Teoria da Informação de Shannon

A Teoria da Informação de Shannon faz essa distinção, mas, na prática, os dois termos se confundem, e os dados originais são chamados de dados de entrada e os dados resultantes do processamento são chamados de dados de saída.

domingo, 28 de agosto de 2011

COMO RESOLVER UM PROBLEMA


A forma como se resolve um problema é muito pessoal, mas nada nos impede que sigamos alguns conselhos como, por exemplo, os do matemático húngaro George Pólya, que nasceu em 1887 e faleceu em 1995. Seus trabalhos contribuíram de forma significativa para a Matemática atual e incluíram séries, análise combinatória, probabilidades, entre outros. Ele escreveu alguns livros e, em um dos seus livros, ensinou como resolver problemas, em quatro fases, independentes de serem matemáticos ou não. Apresentamos abaixo as quatro fases sugeridas por ele.
1. Compreenda o problema
• Identifique os dados.
• Identifique a incógnita.
• Identifique a condição.
• Verifique se possível satisfazer a condição com os dados fornecidos.
2. Planeje
• Tente encontrar uma relação entre os dados e a incógnita.
• Procure achar alguma semelhança entre esse problema e outro que já resolveu.
• Releia o problema se não tiver conseguido encontrar as etapas necessárias para resolvê-lo.
• Quando tiver conseguido, escreva as etapas sem ser prolixo e impreciso.
3. Execute o plano
• Acompanhe todas as etapas.
• Verifique se conseguiu atingir o objetivo.
4. Reflita sobre a solução
• Consegue justificar todas as etapas?
• Consegue visualizar outra solução?
• Consegue ver uma outra aplicação para a solução encontrada?

RicardoMororó: Curiosidades de Diofanto

RicardoMororó: Curiosidades de Diofanto

Curiosidades de Diofanto

http://www.educ.fc.ul.pt/icm/icm2001/icm23/curiosidadesdiofanto.htm

sábado, 27 de agosto de 2011

COMPATIBILIZADORES PROTHEUS 11 - 2011 27/08/11 07:58


DATA ÚLTIMA ATUALIZAÇÃO 27/08/11 07:58
COMPATIBILIZADORES PROTHEUS 11 - 2011
VERSÃO DO PROTHEUS MÓDULO COMPATIBILIZADOR
VERSÃO DO PROTHEUS MÓDULO COMPATIBILIZADOR
PROTHEUS 11 FISCAL U_UPDSIGAFIS
PROTHEUS 11 TMS TMSP11R1
PROTHEUS 11 U_UPDSFT
PROTHEUS 11 MNT E FROTA U_UPDMNT02
PROTHEUS 11 U_IMPSPED
PROTHEUS 11
U_UPDMNT03
PROTHEUS 11 U_UPDSPED
PROTHEUS 11
U_UPDMNT04
PROTHEUS 11 NFEP11R1
PROTHEUS 11
U_UPDMNT05
PROTHEUS 11 ATIVO FIXO U_UPDATF
PROTHEUS 11
U_UPDMNT06
PROTHEUS 11 CONTABILIDADE U_CTRL0002
PROTHEUS 11
U_UPDMNT07
PROTHEUS 11 U_UPDCTBHI
PROTHEUS 11
U_UPDMNT08
PROTHEUS 11 U_UPDCTB
PROTHEUS 11
U_UPDMNT09
PROTHEUS 11 FINANCEIRO U_UPDFIN
PROTHEUS 11
U_UPDMNT15
PROTHEUS 11 U_UPDFINLOTE
PROTHEUS 11
U_UPDMNT20
PROTHEUS 11 GESTÃO PESSOAL RHUPDMOD
PROTHEUS 11
U_UPDMNT22
PROTHEUS 11 RHMANAD
PROTHEUS 11
U_UPDMNT24
PROTHEUS 11 COMPRAS U_UPDCOM05
PROTHEUS 11
U_UPDMNT26
PROTHEUS 11
U_UPDCOM06
PROTHEUS 11
U_UPDMNT27
PROTHEUS 11
U_UPDCOM08
PROTHEUS 11
U_UPDMNT29
PROTHEUS 11
U_UPDCOM09



PROTHEUS 11
U_UPDCOM10



PROTHEUS 11
U_UPDCOM17



PROTHEUS 11
U_UPDCOM18



PROTHEUS 11 FATURAMENTO U_UPDSIGAFAT



PROTHEUS 11
U_UPDFAT06



PROTHEUS 11
U_UPDFAT07



PROTHEUS 11
U_UPDFAT15



PROTHEUS 11 PCP U_UPDPCP05
FALTA VERIFICAR

PROTHEUS 11
U_UPDPCP09



PROTHEUS 11
U_UPDPCP10



PROTHEUS 11
U_UPDPCP11



PROTHEUS 11 PMS U_UPDPMS



PROTHEUS 11 CALL CENTER U_TKUPDADJ



PROTHEUS 11
U_TKUPDADM



PROTHEUS 11
U_UPDTMK45



PROTHEUS 11 ESTOQUE U_UPDEST08



PROTHEUS 11
U_UPDEST13



PROTHEUS 11
U_UPDEST14



PROTHEUS 11
U_UPDEST20



PROTHEUS 11
U_UPDEST23



PROTHEUS 11
U_UPDEST24



PROTHEUS 11
U_UPDEST25



PROTHEUS 11
U_UPDEST27



PROTHEUS 11
U_UPDEST31



COMPATIBILIZADORES PROTHEUS 10 - 2011 27/08/11 07:57


DATA ÚLTIMA ATUALIZAÇÃO 27/08/11 07:57
COMPATIBILIZADORES PROTHEUS 10 - 2011
VERSÃO DO PROTHEUS MÓDULO COMPATIBILIZADOR
VERSÃO DO PROTHEUS MÓDULO COMPATIBILIZADOR
PROTHEUS 10 FISCAL U_UPDSIGAFIS
PROTHEUS 10 TMS TMSP10R1
PROTHEUS 10 U_UPDSFT
PROTHEUS 10 MANUTENÇÃO DE FROTA DE FROTA - NG U_UPDMNT02
PROTHEUS 10 U_UPDCDA
PROTHEUS 10 U_UPDMNT03
PROTHEUS 10 U_UPDNFD
PROTHEUS 10 U_UPDMNT04
PROTHEUS 10 U_UPDAIDF
PROTHEUS 10 U_UPDMNT05
PROTHEUS 10 U_IMPSPED
PROTHEUS 10 U_UPDMNT06
PROTHEUS 10 U_UPDSPED
PROTHEUS 10 U_UPDMNT07
PROTHEUS 10 NFEP10R1
PROTHEUS 10 U_UPDMNT08
PROTHEUS 10 ATIVO FIXO U_UPDATF
PROTHEUS 10 U_UPDMNT09
PROTHEUS 10 U_UPDATF99
PROTHEUS 10 U_UPDMNT15
PROTHEUS 10 CONTABILIDADE U_CTRL0002
PROTHEUS 10 U_UPDMNT20
PROTHEUS 10 U_UPDCTBHI
PROTHEUS 10 U_UPDMNT22
PROTHEUS 10 U_UPDCTB
PROTHEUS 10 U_UPDMNT24
PROTHEUS 10 FINANCEIRO U_UPDFIN
PROTHEUS 10 U_UPDMNT26
PROTHEUS 10 U_UPDFINLOTE
PROTHEUS 10 U_UPDMNT27
PROTHEUS 10 GESTÃO PESSOAL RHUPDMOD
PROTHEUS 10 U_UPDMNT29
PROTHEUS 10 RHMANAD
PROTHEUS 10 U_UPDMNT30
PROTHEUS 10 COMPRAS U_UPDCOM05
PROTHEUS 10 U_UPDMNT31
PROTHEUS 10 U_UPDCOM06
PROTHEUS 10 U_UPDMNT32
PROTHEUS 10 U_UPDCOM08
PROTHEUS 10 U_UPDMNT34
PROTHEUS 10 U_UPDCOM09
PROTHEUS 10 U_UPDMNT35
PROTHEUS 10 U_UPDCOM10
PROTHEUS 10 U_UPDMNT36
PROTHEUS 10 U_UPDCOM17
PROTHEUS 10 U_UPDMNT39
PROTHEUS 10 U_UPDCOM18
PROTHEUS 10 U_UPDMNT43
PROTHEUS 10 FATURAMENTO U_UPDSIGAFAT
PROTHEUS 10 U_UPDMNT44
PROTHEUS 10 U_UPDFAT06
PROTHEUS 10 U_UPDMNT45
PROTHEUS 10 U_UPDFAT07
PROTHEUS 10 U_UPDMNT46
PROTHEUS 10 U_UPDFAT15
PROTHEUS 10 U_UPDMNT47
PROTHEUS 10 PCP U_UPDPCP05
PROTHEUS 10 U_UPDMNT50
PROTHEUS 10 U_UPDPCP09
PROTHEUS 10 U_UPDMNT54
PROTHEUS 10 U_UPDPCP10
PROTHEUS 10 U_UPDMNT55
PROTHEUS 10 U_UPDPCP11
PROTHEUS 10 U_UPDMNT56
PROTHEUS 10 PMS U_UPDPMS
PROTHEUS 10 U_UPDMNT57
PROTHEUS 10 CALL CENTER U_TKUPDADJ
PROTHEUS 10 U_UPDMNT59
PROTHEUS 10 U_TKUPDADM
PROTHEUS 10 U_UPDMNT63
PROTHEUS 10 U_UPDTMK45
PROTHEUS 10 U_UPDMNT65
PROTHEUS 10 ESTOQUE U_UPDEST08
PROTHEUS 10 U_UPDMNT66
PROTHEUS 10 U_UPDEST13
PROTHEUS 10 U_UPDMNT72
PROTHEUS 10 U_UPDEST14
PROTHEUS 10 U_UPDMNT73
PROTHEUS 10 U_UPDEST20
PROTHEUS 10 U_UPDMNT74
PROTHEUS 10 U_UPDEST23
PROTHEUS 10 U_UPDMNT79
PROTHEUS 10 U_UPDEST24
PROTHEUS 10 U_UPDMNT81
PROTHEUS 10 U_UPDEST25
PROTHEUS 10 U_UPDMNT82
PROTHEUS 10 U_UPDEST27
PROTHEUS 10 U_UPDMNT83
PROTHEUS 10 U_UPDEST31
PROTHEUS 10 U_UPDMNT84
PROTHEUS 10 CONFIGURADOR U_UPDIDENT
PROTHEUS 10 U_UPDMNT86




PROTHEUS 10 U_NGATUSEQ

sexta-feira, 26 de agosto de 2011

Limite de crédito de clientes

Para definir as regras de limite de crédito do cliente é necessário analisar os campos:
• Risco
• Limite de Crédito
• Limite de Crédito Secundário
• Vencimento do Limite de Crédito
• Classe de Crédito
• Moeda do Limite de Crédito
• Parâmetros Utilizados
Risco
Grau de risco na aprovação do crédito do cliente nos pedidos de vendas, onde pode assumir conteúdos
distintos:
• Risco A - significa que não existe risco para venda, ou seja, o pedido de vendas não será bloqueado,
exceto se a data do vencimento do limite de crédito estiver ultrapassada.
• Risco B - esta situação depende do conteúdo do parâmetro "MV_RISCOB" que indica o número de
dias de atraso tolerável no pagamento de títulos de clientes, além disso, será considerado também o
valor do limite de crédito e o data de vencimento do limite de crédito do cliente.
• Risco C - esta situação depende do conteúdo do parâmetro "MV_RISCOC" que indica o número de
dias de atraso tolerável no pagamento de títulos de clientes, além disso, será considerado também o
valor do limite de crédito e o data de vencimento do limite de crédito do cliente.
• Risco D - esta situação depende do conteúdo do parâmetro "MV_RISCOD" que indica o número de
dias de atraso tolerável no pagamento de títulos de clientes, além disso, será considerado também o
valor do limite de crédito e o data de vencimento do limite de crédito do cliente.
• Risco E - significa que existe um grande risco na venda, ou seja, o pedido de vendas sempre será
bloqueado.
• Risco Z - Integração SERASA, liberação de crédito por meio da integração de software de terceiros.

Neste caso, quando liberado o pedido de vendas para faturamento, ficará bloqueado até que o sistema, por
meio da integração SERASA, receba a instrução para sua liberação.
Este recurso está disponível pela parceria da Totvs com a SERASA, com o objeto de facilitar aos clientes o
acesso aos bancos de dados da SERASA, consultando suas informações e atualizando-as, conforme
contrato estabelecido com a SERASA.
Para a atualização das informações financeiras dos clientes (hábitos de pagamentos, perfil de compras,
compromissos vencidos e a vencer) na base de dados da SERASA, deve-se executar a rotina SERASA -Relato.
Para a liberação automática de crédito, configurar o serviço de consulta ao produto RELATO, por meio da
estrutura String de dados - IP23, disponibilizado no Protheus.
Aplicação Prática
Considerando que, no cadastro de um cliente o campo "Risco" está definido como "A", ao liberar um pedido
de vendas de qualquer valor do mesmo, este não será bloqueado, pois quando o cliente está classificado
como "Risco A", indica que não existe restrição para venda, sendo assim todos os pedidos serão
automaticamente liberados por crédito.
Já no caso de outro cliente classificado como "Risco E", na liberação de seus pedidos de vendas,
independente do valor, estes sempre serão bloqueados por crédito.
Dica:
É possível tratar tolerância de dias de atrasos nos pagamentos de títulos do cliente. Para isto, o sistema
disponibiliza os parâmetros: "MV_RISCOB", "MV_RISCOC" e "MV_RISCOD", que devem ser
informados com o número de dias de tolerância de atrasos.
Exemplo:
Estão definidos os parâmetros com os seguintes conteúdos:
• MV_RISCOB = 30 (tolerância de até 30 dias de atraso no pagamento dos títulos)
• MV_RISCOC = 20 (tolerância de até 20 dias de atraso no pagamento dos títulos)
• MV_RISCOD = 10 (tolerância de até 10 dias de atraso no pagamento dos títulos)
Se o cliente for classificado como Risco B, seus pedidos de vendas não serão bloqueados por crédito mesmo
que existam títulos a receber em aberto até 30 dias da data de vencimento real, caso este período seja
ultrapassado, os mesmos serão bloqueados.
Segue o mesmo conceito para os clientes considerados "Risco C" e "Risco D", sempre será analisado o
conteúdo do parâmetro e os dias de atrasos de pagamento dos títulos.
Limite de Crédito
No campo "Limite de Crédito" é definido o valor total do limite de crédito do cliente, valor relacionado ao
campo "Moeda 1" (moeda nacional).
Limite de Crédito Secundário
Este conceito se aplica quando o usuário quer controlar o limite de crédito diferenciado para alguns títulos,
como por exemplo, para notas fiscais e cheques.
Exemplo:
Podemos definir que o limite de crédito primário de um cliente será de 1000,00 e o secundário de 500,00.
Neste caso, se o cliente estiver devendo 800,00 em notas fiscais e 600,00 em cheques (títulos em aberto), o
seu crédito não será aprovado, porque o limite de crédito secundário foi excedido.
• Para tratar "Limite de Crédito Primário" e "Limite de Crédito Secundário" deve-se configurar o
campo "Atualiza Saldo Duplicatas" do cadastro de tipos de títulos, definindo quais movimentos
devem ser controlados pelo limite primário ou secundário conforme o tipo do título.
• Os tipos de títulos não cadastrados neste arquivo serão controlados pelo campo "Limite de Crédito
Primário".
• Todos os tipos de títulos que terão aplicação deste controle devem ser cadastrados na rotina
Tipos de títulos.
Vencimento do Limite
No campo "Vencimento do Limite" é definida a data do vencimento do limite de crédito do cliente e está
diretamente relacionado aos campos "Limite de Crédito" e "Limite de Crédito Secundário".
Classe de Crédito
A avaliação pela classe de crédito permite definir um limite de valor para faturamento por pedido de vendas
do cliente. Esta análise compara o valor do pedido com a "Classe" definida para o cliente e o conteúdo do
parâmetro respectivo à classe (MV_PEDIDOn).
O sistema fará a análise de crédito do pedido considerando também as regras definidas para grau de risco e
limite/vencimento de crédito.
A classe de crédito depende do conteúdo dos parâmetros:
• Classe A - "MV_PEDIDOA"
• Classe B - "MV_PEDIDOB"
• Classe C - "MV_PEDIDOC"
Importante:
Em "Parâmetros" do ambiente Configurador, observe o conteúdo dos parâmetros "MV_PEDIDOA",
"MV_PEDIDOB" e "MV_PEDIDOC", em que devem ser indicados os valores do limite em moeda
corrente para a avaliação dos pedidos de venda, conforme a classe de crédito do cliente (A, B ou C).

Aplicação Prática:
Estão definidos os parâmetros com os seguintes conteúdos:
• MV_PEDIDOA = 10000
• MV_PEDIDOB = 5000
• MV_PEDIDOC = 3000
Considerando que, no cadastro de um cliente o campo "Classe" está definido como "A", o campo "Limite de
Crédito" como R$ 10.000,00 e "Vencimento de Crédito" como 31/12/05, ao liberar um pedido de vendas com
valor aproximado de R$ 5.000,00, este não será bloqueado por crédito, pois seu valor é inferior ao limite
máximo definido no parâmetro "MV_PEDIDOA".
Já no caso de outro cliente definido como "Classe B", com o mesmo valor de limite/vencimento de crédito (R$
10.000,00 - 31/12/05), na liberação de um pedido de vendas com valor aproximado de R$ 6.000,00, este será
bloqueado por crédito, pois seu valor é superior ao limite máximo definido no parâmetro "MV_PEDIDOB".
• É importante informar também os campos "Limite de Crédito" e "Data de Vencimento de Crédito".
• Caso informado o risco do cliente, este sempre terá prioridade sobre a classe de crédito ou
limite/vencimento de crédito.
Exemplo:
Se o risco do cliente for definido como "A" e o valor do pedido for maior que a classe definida para o cliente
ou se o limite de crédito estiver excedido, o pedido não será bloqueado por crédito pois para a "Classe = A"
não existe restrição.
Importante:
Na avaliação da "Classe de Crédito", serão bloqueados todos os pedidos de vendas com valor superior
ao limite máximo definido de acordo com a Classe (A, B ou C), mesmo que não tenha excedido o limite
de crédito ou vencimento.
Moeda do Limite de Crédito
O campo "Moeda do LC" é utilizado para definir a moeda forte para controle dos limites de crédito e seus
respectivos saldos, caso não informada será utilizada a moeda informada no parâmetro "MV_MCUSTO".
Aplicação Prática
Se o campo "Moeda do Limite de Crédito" for definido como "1" (moeda nacional), serão utilizados os valores
"Moeda 1" e "Limite de Crédito" no cálculo da análise de crédito do cliente.
Já no caso da "Moeda do Limite de Crédito" for definida como "2", serão utilizados os valores "Moeda 2" e
"Limite de Crédito Secundário" no cálculo da análise de crédito do cliente.
Parâmetros Utilizados:
• MV_CREDCLI
• MV_BLOQUEI
• MV_LIMINCR
• MV_MCUSTO