Rodrigo Miranda

Affe, estou lendo as respostas aqui e estamos passando por todos os problemas listados. Agora detectamos um que está arrancando os cabelos do pessoal do PCP aqui. Temos uma estagiária aqui que estamos chamando de Samara (O chamado), ela passa o dia com o suporte e abrimos 2 chamados de correção por dia. Tá de lascar isso, em alguns casos só na OUVIDORIA que resolvemos. []´s Miranda.

Eu tenho isso montado, mas não é no RM, pq os caras aqui querem fluxo de caixa pra 60 dias, e se for via SQL o banco senta. A solução foi criar em ASPNET consultando direto o Oracle.

Nós implantamos a versão 11.40 no começo do mês, estamos com tantos problemas que não estamos tendo tempo para mais nada, são abertos em 2 chamados por dia. O Cálculo e Relatórios .NET ainda não utilizamos. Mas o resto do sistema está um verdadeiro inferno.

Caros, Tenho algumas customizações que fazem inclusão de movimento via SQL, migramos da versão 11.20 para a 11.40. Nessa nova versão, me parece que a RM resolveu ativar todas as validações que ela nunca fez. Temos uma rotina de importação de movivmento por arquivo texto, e ele vinha apresentando problemas de local de estoque. O erro apresentado refere-se a não existência daquele local de estoque. O movimento tem 3 locais de estoque que podem ser preenchidos, se for preencher o local de estoque, preencha também a filial do local de estoque, senão nem alteração do movimento poderá ser feita, seguem abaixo: CODLOC - CODFILIAL CODLOCDESTINO - CODFILIALDESTINO CODLOCENTREGA - CODFILIALENTREGA É claro que o suporte do RM Nucleus ainda não "solucionou" o nosso problema, mas como não podemos esperar conseguimos resolver o problema.

Para resolver o nosso problema, a Totvs passou um script pra alterar o IDPRD na tabela TRELSLD, que é a tabela utilizada para a ficha física financeira do produto. Segundo eles, o conversor que utilizamos não atualizou essa tabela, por isso todos os produtos estavam com seus saldos furados.

Quando preciso fazer esse tipo de alteração faço direto no Banco de Dados, (ALTER TABLE), o RM é bem esperto nesse ponto, ele entende a alteração, mas pra isso é preciso analisar direito, pois, troca de tipo pode detonar todo o processo.

Foi trabalho braçal entrei no SQL Developer e descobri oq esses mequetrefes fizeram, vc não imagina o rolo que está. Se preparem para os realórios de pedido, no nosso caso, temos faturamento parcial, os campos de quantidade mudaram tb, os que usaremos serão: QUANTIDADE, QUANTIDADETOTAL e QUANTIDADEORIGINAL.

Nós utilizamos a regeração de saldo uma vez por semana, migramos agora para a versão 11.40. Não sei oq aconteceu, mas o Nucleus cagou o saldo de todos os produtos, tá tudo uma zona. Estamos falando com o suporte para ver oq é que está acontecendo, mas a principio é a troca do ID do Produto que zuou contudo.

Se não me engano o RM tem integração de login com o Active Directory da Microsoft, se você quiser implantar uma política de segurança de senha mais severa acho que essa é a melhor opção.

Nós temos o produto e contratamos o suporte Totvs, o atendimento telefônico é uma lástima, abrimos o chamado via web e temos que ligar, são horas pendurado ao telefone e as vezes temos que ligar 3 vezes pra conseguir um atendente que entenda e consiga solucionar a dúvida. Esse suporte SLA é diferente do suporte normal ?? []´s Rodrigo Miranda.

Nós testamos a versão 11.50, já na tela de cadastro de produto e movimento começou a dar pane, erro de DbNull no banco. Como não podemos perder tempo, vamos migrar para a 11.40 e esperar a 11.50 estar estável.

Consegui falar com o pessoal responsável pela conversão e segundo eles eu posso remover esses campos das minhas tabelas. Foi uma versão do conversor que se baseava na tabela "sysobjects" para criar os campos, mas o mesmo já foi corrigido para se basear na tabela de metadados do RM. Portanto, quem baixou o conversor, entre em contato com o suporte para baixar uma versão mais atualizada do conversor. []´s

Não estamos em produção ainda, mas a Totvs já nos liberou para rodar em produção. O que percebemos é que as telas estão uma carroça tremenda. Ontem fizemos um teste com o nosso servidor de banco de dados Oracle de produção para ver se era a base de dados que estava causando isso, mas é da aplicação mesmo a lentidão. De qualquer maneira, percebi que todas as tabelas do bando foram alteradas, criaram 4 campos em todas elas: RECCREATEDBY VARCHAR2(50 BYTE) RECCREATEDON DATE RECMODIFIEDBY VARCHAR2(50 BYTE) RECMODIFIEDON DATE Inclusive nas tabelas de customização, que o RM não acessa, mas as minhas aplicações sim. Liguei no suporte, mas o pessoal de banco de dados não sabe informar sobre isso. Vamos ver como fica isso. []´s

Exatamente por isso eu prefiro descobrir o que aconteceu, no caso da TPRD que foi dividida em 3, em alguns casos isso é ótimo para a performance.

Estou migrando todas as minhas customizações e sentenças SQL para a nova versão, e estou encontrando algumas mudanças, então segue mais uma: DNATUREZA -> DCFOP Existe uma view com o nome DNATUREZA, mas quem quiser simplificar e melhorar a performance das consultas, sugiro reavaliar.