In Dynamics AX transaction time is one hour ahead when not using using daylight savings tim...
Existem casos em que o AX2009 exibe a hora "errada" no AX 2009, e isso causa diversos problemas como trabalhos em lote executados em hora errada, notas fiscais enviadas com hora errada e outros diversos problemas...
Ocorre que o AX entende que está em uma região que utiliza o horário de verão, e caso o sistema operacional esteja configurado para adiantar automaticamente o relógio neste período o AX também atualiza o relógio em 01 hora.
Existem inumeros posts falando de classes no AX para ajuste destas configurações... deem uma googlada e verão muito material sobre o assunto.
Uma solução simples é simplesmente alterar o "Timezone" do AX indo no menu Ferramentas > Opções > Fuso Horário Preferido.
Neste caso, utilize fuso horário que não tenha o horário de verão. eu por exemplo alterei para "(GMT-03:00) Buenos Aires, Georgeown."
Assim a data e hora de sessão do usuário no AX ficam corretas e o usuário poderá usar o AX normalmente!
Na minha opinião este problema deveria ser corrigido no AX2009 pela Microsoft, mas sei que minha opnião é apenas, e nada além do que, minha opnião, portanto, caso tenham alguma reclamação sobre este metodo,... gritem!!!!
Até a próxima!
Fonte: KB2537489
Translate
Mostrando postagens com marcador data. Mostrar todas as postagens
Mostrando postagens com marcador data. Mostrar todas as postagens
terça-feira, 11 de outubro de 2016
quarta-feira, 17 de setembro de 2014
Test Data Transfer Tool - Instalação!
Olá pessoal!
Neste post vou compartilhar com vocês a instalação da ferramenta Test Data Transfer Tool.
Nesta semana, após criar uma nova VM de AX2012 R3 eu precisei importar os dados de testes disponibilizados pela Microsoft, e para que isso fosse possível eu precisava utilizar esta ferramenta, neste caso eu documentei o processo de instalação e de importação dos dados para o Dynamics AX!
A Ferramenta Test Data Transfer Tool é uma ferramenta de linha de comando pode ser utilizada para importar e exportar dados entre ambientes de homologação e desenvolvimento (teste, demo...).
Já para ambientes de produção ela só deverá ser utilizada para exportação de dados, única e exclusivamente para exportação!
Faça o download do instalador pelo Information Source Services para efetuar a instalação!
Obs: Todo o processo descrito abaixo foi executado no servidor onde o SQL Server está instalado, está ferramenta exige o componente bcp.exe do SQL. Caso você precise executar este processo de outro servidor, certifique-se de que o componente SQL Server Client Tools esteja instalado neste servidor e também no servidor de banco de dados!
Após efetuar o download e descompactar o executável clique com o botão direito sobre ele e execute-o como administrador, clique em Next na tela exibida.
Aceite os termos de uso e clique em Next.
Clique em Next novamente.
E agora clique em Install.
Clique em Finish.
E verifique se no diretório C:\Program Files foi criada a pasta conforme imagem abaixo:
Pronto, ferramenta instalada! Nenhum mistério ou dificuldade, fácil fácil!
Agora vamos ao DemoData, efetue o download do arquivo na pagina do Partner Source, e após download descompacte o arquivo para uma pasta de fácil acesso no servidor. Depois de descompactado esta pasta ocupou quase 17GB no disco!
Agora, no menu iniciar do Windows, localize o prompt de comando (CMD), clique com o botão direito do mouse sobre ele e escolha a opção executar como administrador.
No CMD acesse o diretório da ferramenta usando o seguinte comando:
cd /d C:\Program Files (x86)\Microsoft Dynamics AX 2012 Test Data Transfer Tool (Beta)
Agora estamos dentro da pasta do Test Data Transfer Tool, onde está o executável que usaremos para importar os dados!!
Mas antes de executar o comando de importação é necessário para o serviço do AX, então, vá la nos serviços do Windows e pare o serviço!
Com o serviço parado vamos ao comando para importação de dados"
DP.exe Import c:\DemoData MicrosoftDynamicsAX
DP.exe = Nome do executável
Import = Ação a ser iniciada pelo executável
c:\DemoData = O nome da pasta onde estão os arquivos descompactados
MicrosoftDynamicsAX = Nome do bando de dados para os arquivos serão importados
Após digitar o comando acima e pressionar o ENTER a tela abaixo será exibida. Leia com atenção e após entender a mensagem digite Y para continuar.
Agora o executável está verificando o comando e permissões necessárias, aguarde!
Se tudo estiver ok a importação irá começar e a tela abaixo será exibida.
Aguarde o termino do processo que pode levar de minutos a algumas horas, no meu caso foram horas mesmo!!!
Note que no meu caso ocorreram erros, neste caso acesse via Windows Explorer o diretório de instalação da ferramenta e abra o arquivo DPlog.txt, e analise os erros.
Finalizado o processo ao acessar o AX você verá as varias empresas importadas para o AX!
Lembrando que neste caso eu utilizei o DemoData disponibilizado, exportado, pela Microsoft no Partner Source, por esta razão tantas empresas foram importadas. Caso precise de uma única empresa será necessário efetuar o processo de exportação de dados usando a Test Data Tranfer Tool, assunto este para um próximo post!
No inicio do post está o link para o TechNet, de onde tirei estas informações, lá tem muito mais, sugiro veemente que leiam!
Até a próxima pessoal!
Neste post vou compartilhar com vocês a instalação da ferramenta Test Data Transfer Tool.
Nesta semana, após criar uma nova VM de AX2012 R3 eu precisei importar os dados de testes disponibilizados pela Microsoft, e para que isso fosse possível eu precisava utilizar esta ferramenta, neste caso eu documentei o processo de instalação e de importação dos dados para o Dynamics AX!
A Ferramenta Test Data Transfer Tool é uma ferramenta de linha de comando pode ser utilizada para importar e exportar dados entre ambientes de homologação e desenvolvimento (teste, demo...).
Já para ambientes de produção ela só deverá ser utilizada para exportação de dados, única e exclusivamente para exportação!
Faça o download do instalador pelo Information Source Services para efetuar a instalação!
Obs: Todo o processo descrito abaixo foi executado no servidor onde o SQL Server está instalado, está ferramenta exige o componente bcp.exe do SQL. Caso você precise executar este processo de outro servidor, certifique-se de que o componente SQL Server Client Tools esteja instalado neste servidor e também no servidor de banco de dados!
Após efetuar o download e descompactar o executável clique com o botão direito sobre ele e execute-o como administrador, clique em Next na tela exibida.
Aceite os termos de uso e clique em Next.
Clique em Next novamente.
E agora clique em Install.
Clique em Finish.
E verifique se no diretório C:\Program Files foi criada a pasta conforme imagem abaixo:
Pronto, ferramenta instalada! Nenhum mistério ou dificuldade, fácil fácil!
Agora vamos ao DemoData, efetue o download do arquivo na pagina do Partner Source, e após download descompacte o arquivo para uma pasta de fácil acesso no servidor. Depois de descompactado esta pasta ocupou quase 17GB no disco!
Agora, no menu iniciar do Windows, localize o prompt de comando (CMD), clique com o botão direito do mouse sobre ele e escolha a opção executar como administrador.
No CMD acesse o diretório da ferramenta usando o seguinte comando:
cd /d C:\Program Files (x86)\Microsoft Dynamics AX 2012 Test Data Transfer Tool (Beta)
Agora estamos dentro da pasta do Test Data Transfer Tool, onde está o executável que usaremos para importar os dados!!
Mas antes de executar o comando de importação é necessário para o serviço do AX, então, vá la nos serviços do Windows e pare o serviço!
Com o serviço parado vamos ao comando para importação de dados"
DP.exe Import c:\DemoData MicrosoftDynamicsAX
DP.exe = Nome do executável
Import = Ação a ser iniciada pelo executável
c:\DemoData = O nome da pasta onde estão os arquivos descompactados
MicrosoftDynamicsAX = Nome do bando de dados para os arquivos serão importados
Após digitar o comando acima e pressionar o ENTER a tela abaixo será exibida. Leia com atenção e após entender a mensagem digite Y para continuar.
Agora o executável está verificando o comando e permissões necessárias, aguarde!
Se tudo estiver ok a importação irá começar e a tela abaixo será exibida.
Aguarde o termino do processo que pode levar de minutos a algumas horas, no meu caso foram horas mesmo!!!
Note que no meu caso ocorreram erros, neste caso acesse via Windows Explorer o diretório de instalação da ferramenta e abra o arquivo DPlog.txt, e analise os erros.
Finalizado o processo ao acessar o AX você verá as varias empresas importadas para o AX!
Lembrando que neste caso eu utilizei o DemoData disponibilizado, exportado, pela Microsoft no Partner Source, por esta razão tantas empresas foram importadas. Caso precise de uma única empresa será necessário efetuar o processo de exportação de dados usando a Test Data Tranfer Tool, assunto este para um próximo post!
No inicio do post está o link para o TechNet, de onde tirei estas informações, lá tem muito mais, sugiro veemente que leiam!
Até a próxima pessoal!
terça-feira, 15 de abril de 2014
CRM2011- Reports Sem Dados
Boa tarde pessoal!
Hoje vou compartilhar com vocês um problema que enfrentei com o CRM2011.
Todo o ambiente de produção deste CRM já havia sido entregue ao cliente, tudo estava funcionando...quase tudo!
Quando um novo relatório era criado e importado para o CRM, ao executa-lo, este relatório não exibia nenhum dado. Durante a criação de um novo relatório era possível ver no preview que tudo estava correto, método de autenticação, banco de dados DataSource...tudo.
Este problema persistiu no cliente por um longo tempo, consultores e desenvolvedores tentaram varias possíveis soluções e nada...
Algumas semanas depois estive neste cliente e comecei a analisar o problema. Primeiro criei um relatório simples no ambiente de homologação, importei ele para o CRM e tudo ok. Neste caso o ambiente de homologação e todos os componentes estão instalados em um único servidor.
No ambiente de produção temos um servidor para cada componente. Repeti a criação de um report, durante o preview ele funcionou normalmente, mas ao importa-lo para o CRM ele novamente não trouxe os dados que deveria trazer.
Comecei a verificar os logs gerados no event viewer e também os logs gerados pelo SQL Server.
Obs: O cliente já havia reportado estas entradas nos logs do SQL Server...
Ao abrir o log do SQL Server, a cada tentativa de geração do relatorio, um novo registro como este logo abaixo era criado:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: 192.168.0.174]
Lembrando que este registro somente era gravado quando o relatório era executado pelo CRM via browser.
Minha duvida, que ainda permanece, é a seguinte... Por que o CRM utiliza autenticação anônima para exibir estes relatórios?
Minha primeira tentativa para tentar corrigir o problema, ainda no ambiente de homologação, foi importar esta conta para a instância do CRM e deixa-la como "SYSADMIN". Esta ação, apesar de não ser a mais correta, resolveu o problema e os relatórios customizados passaram a funcionar.
No ambiente de produção restringi mais a permissão para esta conta e com isso os relatorios também passaram a funcionar!
Portanto, a solução para este problema foi importar esta conta para o SQL Server com as devidas permissões no banco de dados do CRM e Reporting Services.
Resolvido o problema, passei a procurar o porque dele, por qual razão o CRM estava utilizando autenticação anônima para os relatórios customizados, e durante esta pesquisa encontrei o seguinte link:
http://blog.sonomapartners.com/2007/04/kerberos_and_de.html
Depois de ler o post ajustei as configurações no servidor do cliente e tudo funcionou perfeitamente.
Apesar de ser de 2007 este post é muito valido, sugiro a vocês a leitura dele!
Até a próxima pessoal!
Hoje vou compartilhar com vocês um problema que enfrentei com o CRM2011.
Todo o ambiente de produção deste CRM já havia sido entregue ao cliente, tudo estava funcionando...quase tudo!
Quando um novo relatório era criado e importado para o CRM, ao executa-lo, este relatório não exibia nenhum dado. Durante a criação de um novo relatório era possível ver no preview que tudo estava correto, método de autenticação, banco de dados DataSource...tudo.
Este problema persistiu no cliente por um longo tempo, consultores e desenvolvedores tentaram varias possíveis soluções e nada...
Algumas semanas depois estive neste cliente e comecei a analisar o problema. Primeiro criei um relatório simples no ambiente de homologação, importei ele para o CRM e tudo ok. Neste caso o ambiente de homologação e todos os componentes estão instalados em um único servidor.
No ambiente de produção temos um servidor para cada componente. Repeti a criação de um report, durante o preview ele funcionou normalmente, mas ao importa-lo para o CRM ele novamente não trouxe os dados que deveria trazer.
Comecei a verificar os logs gerados no event viewer e também os logs gerados pelo SQL Server.
Obs: O cliente já havia reportado estas entradas nos logs do SQL Server...
Ao abrir o log do SQL Server, a cada tentativa de geração do relatorio, um novo registro como este logo abaixo era criado:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: 192.168.0.174]
Lembrando que este registro somente era gravado quando o relatório era executado pelo CRM via browser.
Minha duvida, que ainda permanece, é a seguinte... Por que o CRM utiliza autenticação anônima para exibir estes relatórios?
Minha primeira tentativa para tentar corrigir o problema, ainda no ambiente de homologação, foi importar esta conta para a instância do CRM e deixa-la como "SYSADMIN". Esta ação, apesar de não ser a mais correta, resolveu o problema e os relatórios customizados passaram a funcionar.
No ambiente de produção restringi mais a permissão para esta conta e com isso os relatorios também passaram a funcionar!
Portanto, a solução para este problema foi importar esta conta para o SQL Server com as devidas permissões no banco de dados do CRM e Reporting Services.
Resolvido o problema, passei a procurar o porque dele, por qual razão o CRM estava utilizando autenticação anônima para os relatórios customizados, e durante esta pesquisa encontrei o seguinte link:
http://blog.sonomapartners.com/2007/04/kerberos_and_de.html
Depois de ler o post ajustei as configurações no servidor do cliente e tudo funcionou perfeitamente.
Apesar de ser de 2007 este post é muito valido, sugiro a vocês a leitura dele!
Até a próxima pessoal!
terça-feira, 10 de dezembro de 2013
Dica do Dia!!!
Olá pessoal!
A dica de hoje é na verdade uma indicação!
Ontem a Microsoft liberou a nova versão, v4, da VM com o AX2012 R2.
Acessem o Partner Source para efetuar o download dela e divirtam-se!!
A dica de hoje é na verdade uma indicação!
Ontem a Microsoft liberou a nova versão, v4, da VM com o AX2012 R2.
Acessem o Partner Source para efetuar o download dela e divirtam-se!!
quinta-feira, 13 de junho de 2013
Five Good Minutes - Cube Data, Power Pivot and Role Center!
Oque é bom a gente compartilha!
No link abaixo você verá um vídeo muito interessante demonstrando algumas funcionalidades dos cubos do AX.
http://www.mcaconnect.net/five-good-minutes-cube-data-power-pivot-role-centers-and-vacation/
Aproveitem!
No link abaixo você verá um vídeo muito interessante demonstrando algumas funcionalidades dos cubos do AX.
http://www.mcaconnect.net/five-good-minutes-cube-data-power-pivot-role-centers-and-vacation/
Aproveitem!
Marcadores:
Cube,
data,
Francisco Silva,
power pivot,
Role Center
Assinar:
Postagens (Atom)