sesistemas

Bom dia, Estou implementando uma rotina usando a função "DistribuicaoDFe". Estou recebendo a mensagem de retorno compactada conforme a NT 2014/002 e depois extraindo as informações conforme li no fórum. Minha dúvida é a respeito ao retorno, uma nota fiscal que já foi manifestada a DistribuicaoDFe vai me retornar o resumo ou o próprio arquivo XML? Agradeço a atenção. Att.

Foi antes

EMBarbosa Respondendo as suas perguntas, também estou a entender a situação ocorrida em meu cliente, pois até então este sistema em especial era responsabilidade de outro programador aqui da empresa. Porém após sua saída, a responsabilidade deste sistema passou para minha mão, e não fui detalhadamente instruído sobre os detalhes deste sistema ou BD em especial. Desde então começou a acontecer este problema no cliente. Então eu também estou a entender a situação. Não sei por que o sweep foi configurado para ser executado manualmente.

EMBarbosa, estou enviando os dados estatísticos das duas tabelas que faço inserção. Obrigado pelas dicas e pelo link, vou estudar detalhadamente aqui. OP_ENCAUTCLA (222) Primary pointer page: 363, Index root page: 364 Average record length: 58.23, total records: 91753 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 550, data page slots: 550, average fill: 77% Fill distribution: 0 - 19% = 1 20 - 39% = 0 40 - 59% = 0 60 - 79% = 549 80 - 99% = 0 Index FK_OP_ENCAUTCLA_1 (2) Depth: 2, leaf buckets: 41, nodes: 91753 Average data length: 0.00, total dup: 91748, max dup: 23664 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 35 60 - 79% = 2 80 - 99% = 4 Index FK_OP_ENCAUTCLA_3 (3) Depth: 2, leaf buckets: 23, nodes: 91753 Average data length: 0.00, total dup: 91752, max dup: 91752 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 0 60 - 79% = 1 80 - 99% = 22 Index FK_OP_ENCAUTCLA_OP_CADPNEU (4) Depth: 2, leaf buckets: 130, nodes: 91753 Average data length: 6.22, total dup: 141, max dup: 2 Fill distribution: 0 - 19% = 5 20 - 39% = 0 40 - 59% = 121 60 - 79% = 4 80 - 99% = 0 Index FK_OP_ENCAUTCLA_OP_ENCAUTO_T (1) Depth: 2, leaf buckets: 28, nodes: 91753 Average data length: 0.65, total dup: 83219, max dup: 31 Fill distribution: 0 - 19% = 1 20 - 39% = 0 40 - 59% = 0 60 - 79% = 0 80 - 99% = 27 Index PK_OP_ENCAUTCLA (0) Depth: 2, leaf buckets: 132, nodes: 91753 Average data length: 18.12, total dup: 0, max dup: 0 Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 0 60 - 79% = 0 80 - 99% = 131 OP_ENCAUTO_T (223) Primary pointer page: 365, Index root page: 366 Average record length: 52.58, total records: 8568 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 49, data page slots: 49, average fill: 74% Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 0 60 - 79% = 49 80 - 99% = 0 Index FK_OP_ENCAUTO_T_OP_AUTOCLAVE (1) Depth: 2, leaf buckets: 3, nodes: 8568 Average data length: 0.00, total dup: 8563, max dup: 2662 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 1 60 - 79% = 1 80 - 99% = 1 Index FK_OP_ENCAUTO_T_OP_INIAUTO (2) Depth: 2, leaf buckets: 7, nodes: 8568 Average data length: 6.72, total dup: 271, max dup: 249 Fill distribution: 0 - 19% = 1 20 - 39% = 0 40 - 59% = 0 60 - 79% = 0 80 - 99% = 6 Index PK_OP_ENCAUTO_T (0) Depth: 2, leaf buckets: 7, nodes: 8568 Average data length: 6.91, total dup: 0, max dup: 0 Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 0 60 - 79% = 0 80 - 99% = 6 AdilsonPazzini, Já até tentei fazer o sweep manual, mas os únicos recursos que já tive resultado foi o Backup/Restore e o comando SET STATISTICS INDEX, porém os dois são recomendados a serem executados exclusivamente. Caindo no mesmo problema. tendo que parar o sistema para fazer a correção.

Encontrei várias informações do mesmo problema que o meu neste link, inclusive o Carlos H. Cantu e a Ann Harrison respondem algumas das questões debatidas. https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/113456 Segue o resultado do gstat -a sobre o meu banco antes do Backup/Restore conforme pedido: Database header page information: Flags 0 Checksum 12345 Generation 53246264 Page size 16384 ODS version 11.2 Oldest transaction 52758700 Oldest active 52758701 Oldest snapshot 52758701 Next transaction 52759521 Bumped transaction 1 Sequence number 0 Next attachment ID 486652 Implementation ID 26 Shadow count 0 Page buffers 0 Next header page 0 Database dialect 3 Creation date Jun 19, 2012 13:44:11 Attributes force write Variable header data: *END* Neste caso EMBarbosa, eu estou usando um ClienteDataSet, o sistema trava quando eu dou um "post" nos meus dados inseridos no CDS. Mas quando eu faço um insert comum com dados aleatórios no próprio IBExpert, seja qual for os dados inseridos, o banco fica lento do mesmo jeito. Conforme AdilsonPazzini me falou, o número de Transições está mais alto que o normal, porém eu não entendo como é feito esta estatística. Este número é o resultado de todas as transações feitas no banco até o momento, ou são as transações em aberto ? E qual seria um número de transações considerado normal para um aplicação deste tamanho ?

Estou enviando as estatísticas do meu banco em questão. Até gostaria de uma "luz" na interpretação destes dados pois que não entendo muito bem não. Database header page information: Flags 0 Checksum 12345 Generation 53246782 Page size 16384 ODS version 11.2 Oldest transaction 52759983 Oldest active 52759984 Oldest snapshot 52759984 Next transaction 52759985 Bumped transaction 1 Sequence number 0 Next attachment ID 486764 Implementation ID 26 Shadow count 0 Page buffers 0 Next header page 0 Database dialect 3 Creation date Jun 19, 2012 13:44:11 Attributes force write Variable header data: *END*

O Problema acontece num determinado INSERT que faço na tabela que falei Demora uns 40 segundos na minha máquina, na do cliente então... Ai quando eu faço um Backup/Restore o problema some, e a inserção acontece instantaneamente. Eu já excluí a aplicação como problema pois o mesmo INSERT sendo executado diretamente pelo IBExpert fica lento do mesmo jeito. Pesquisei bastante e descobri que o FB tem alguns problemas com índices quando o banco começa a ficar maior. Só que eu não posso ficar parando o serviço do meu cliente para fazer backup e restaurar toda vez que começar a ficar lento.

adilsonpazzini Eu testei fazer apenas o Backup e não resolveu, acredito que a reindexação é feita apenas no Restore EMBasrbosa A princípio também desconfiei ser algum outro problema, mas não consegui encontrar outra solução melhor (fora o SET STATISTICS INDEX conforme descrevi acima, apesar de ser uma solução paliativa) Também encontrei em alguns fóruns outras pessoas com o mesmo problema, mas igualmente sem solução. A propósito, em outros clientes que usam o mesmo sistema não acontece este erro. Meu banco atualmente tem 790 MB e a tabela que está travando tem 90 mil registros.

Existe uma maneira de regerar completamente todos os índices em um banco de dados FireBird sem ser através do backup/restore? Ao longo de meses ou anos, o banco de dados está ficando cada vez mais lento, mas ao fazer um backup e restaurar a correção é imediata. Gostaria de obter o mesmo resultado sem ter parar a execução do sistema. O que eu tentei até agora: - Recalcular estatísticas sobre todos os índices( FOR SELECT rdb$index_name FROM rdb$indices INTO :name DO SET STATISTICS INDEX :name). Este parecia ter um efeito pequeno, então eu comecei a executá-lo automaticamente a cada mês, mas o efeito é muito pequeno e, eventualmente, um backup / restore é novamente necessário. - Backup e restauração. Isso funciona muito bem, mas requer um acesso exclusivo ao banco de dados. E meus usuários não estão muito felizes em parar o serviço para fazer Backup / Restore. Eu estou usando o Firebird versão 2.5 Alguém pode me apontar para alguma solução com gbak ou gfix que eu desconheça, ou alguma outra solução que possa ser utilizada em tempo de execução? Att. Antar Ferreira

Consegui identificar o problema! Este CT-e foi emitido a mais de 30 dias e por isso não é possível fazer uma carta de correção pra ele. A mensagem retornada pelo WebService não está muito sugestiva, e por isso vou ter que fazer um tratamento no meu sistema ao enviar a carta de correção. Atenciosamente.

Bom dia, Estou tentando fazer uma Carta de Correção em produção e estou tendo a seguinte Rejeição: CT-e nao consta na base de dados da SEFAZ. Porém, este CT-e está autorizado no site da receita, e se eu realizar a consulta pelo componente, eu obtenho os dados corretos da autorização. Em outros conhecimentos eu não tenho este problema. Gostaria da ajuda de vocês para identificar este problema. Segue como estou preenchendo as informações no componente e o XML do CT-e em questão: FrmPrincipal.ACBrCTe1.EventoCTe.Evento.Clear; With FrmPrincipal.ACBrCTe1.EventoCTe.Evento.Add Do Begin if (UpperCase(cbbAmbiente.Properties.Items.Items[cbbAmbiente.ItemIndex].Value) = 'P') then InfEvento.tpAmb := taProducao else InfEvento.tpAmb := taHomologacao; infEvento.cOrgao := StrToIntDef(Copy(EmpCodCidade, 1, 2), 0); InfEvento.chCTe := edtChaveCTe.Text; infEvento.CNPJ := EmpCNPJ; infEvento.tpEvento := teCCe; infEvento.nSeqEvento := StrToInt(edtNumSequencial.Text); infEvento.dhEvento := now; infEvento.detEvento.descEvento := 'Carta de Correcao'; infEvento.detEvento.xCondUso := 'A Carta de Correção é disciplinada pelo Art. 58-B do CONVÊNIO/SINIEF 06/89: '+ 'Fica permitida a utilização de carta de correção, para regularização de erro '+ 'ocorrido na emissão de documentos fiscais relativos à prestação de serviço de '+ 'transporte, desde que o erro não esteja relacionado com: I - as variáveis que '+ 'determinam o valor do imposto tais como: base de cálculo, alíquota, diferença de '+ 'preço, quantidade, valor da prestação;II - a correção de dados cadastrais que '+ 'implique mudança do emitente, tomador, remetente ou do destinatário;III - a '+ 'data de emissão ou de saída.'; infEvento.detEvento.infCorrecao.Clear; dsCCE.DataSet.First; while NOT dsCCE.DataSet.Eof do begin With infEvento.detEvento.infCorrecao.Add Do Begin grupoAlterado := dsCCE.DataSet.FieldByName('GRUPO_ALT').AsString; campoAlterado := dsCCE.DataSet.FieldByName('CAMPO_ALT').AsString; valorAlterado := dsCCE.DataSet.FieldByName('VALOR_ALT').AsString; if(Trim(edtNumItemAlterado.Text) <> '')then nroItemAlterado := dsCCE.DataSet.FieldByName('NO_IT_ALT').AsInteger; dsCCE.DataSet.Next; end; End; End; FrmPrincipal.ACBrCTe1.EnviarEventoCTe( StrToInt(edtNumSequencial.Text)); Atenciosamente Wislei

Bom dia a todos, Nós estamos tendo um problema em um cliente aqui na empresa com a emissão, consulta, cancelamento do CT-e (eventos que utilizando o acesso a internet) em um de nossos clientes. Este cliente possui um servidor com o Windows Server 2003 e já estamos esgotando as tentativas de correção. Em outros clientes já tivemos alguns problemas, mas conseguimos corrigir ajustando as configurações de permissão de usuário, proteção do sistema, executar o sistema como administrador, e nada até agora. O problema é que este cliente já utilizava um outro sistema de emissão de CT-e e o mesmo funcionava sem problemas. Gostaria de saber o que mais podemos tentar, o que pode estar faltando instalar ou alguma dependência que posso verificar? Lá está funcionando atualmente em uma outra máquina com Windows 7, mas gostaríamos de resolver este problema sem ter que formatar a máquina. Atenciosamente. Wislei de Brito Fernandes.

Bom dia Pessoal, Estou com uma dúvida, a tag <dhSaiEnt> tem como eu passar somente o campo data? o cliente não quer que saia a hora, por que a hora ele vai preencher a mão. Tentei fazer deste jeito e o webService rejeitou: <dhSaiEnt>2015-01-24</dhSaiEnt> Att.

Boa tarse Boa tarde Italo. Sim, são dois CNPJ diferentes 1 emite NFe e outro emite CTe Vou tentar instalar o emissor do governo para ver se vai funcionar. Att.

Boa tarde Italo, O mesmo cliente também esta emitido NFe na mesma máquina. Então creio que não seja problema de antivírus e firewall. Peguei a base do cliente e tentei enviar CTe no meu computador aqui no escriório enviou normalmente. Att.

Boa tarde Italo, O mesmo cliente também esta emitido NFe na mesma máquina. Então creio que não seja problema de antivírus e firewall. Peguei a base do cliente e tentei enviar CTe no meu computador aqui no escriório enviou normalmente. Att.

Boa tarde, Estou instalando o CTe em um cliente novo e todas a rotinas do CTe estão dando erros. O processo de consulta esta dando o erro abaixo: The server name or address could not be resolved - URL:https://cte.fazenda.mg.gov.br/cte/services/CteConsulta- SOAPAction:http://www.portalfiscal.inf.br/cte/wsdl/CteConsulta/cteConsultaCT. Pode ser algum problema na rede do cliente? Att.

Atualizei o ACBr e veio as alterações A mensagem de erro mudou agora esta dando a seguinte mensagem "JPEG error #53" Uso o Delphi XE3, pelos post vi que deu algo parecido do D7

Bom dia, Meu sistema usa a consulta CPF do ACBr. A consulta começou a dar um erro semana passada. Teve alguma mudança no ConsultaCPF? Erro na hora de fazer o download da imagem do captcha Erro HTTP: 500 Em anexo a imagem.

Boa tarde Carlos, Faz todo sentido o que você disse. Irei pesquisar mais neste sentido e postarei aqui caso obtiver sucesso. Atenciosamente.

Alguma sugestão? Algum componente específico para esta finalidade? Att,

Bom dia pessoal, Gostaria da ajuda e opinião de vocês com relação a um problema que estou tendo. Sempre que tenho que fazer uma alteração em uma trigger ou criar uma trigger nova no Firebird diretamente pelo sistema, enfrento alguns problemas. Eu utilizo o componente TSqlQuery sempre que preciso fazer um acesso ao Firebird, seja pra consultas SQL, Insert, Update, etc... Recentemente tive que fazer uma alteração em uma trigger, onde a mesma tinha variáveis declaradas, e ao executar o 'ExecSql', ocorre um erro referente à variável :DATA . E executando o trecho de código no IBExpert funciona normalmente. Segue um exemplo do problema: CREATE TRIGGER TRG_ITENS_ENTRADA_MOVIMENTO FOR ITENS_ENTRADA ACTIVE AFTER INSERT POSITION 0 AS declare variable DATA date; declare variable DESCRICAO varchar(30); begin SELECT ENT_DATA FROM ENTRADAS WHERE ID_ENTRADA = NEW.ITE_ENT INTO :DATA; DESCRICAO = 'REFERENTE A ENTRADA: ' || NEW.ITE_ENT; EXECUTE PROCEDURE INSERE_MOVIMENTO( NULL, NEW.ITE_PRO, NEW.ITE_ENT, 'ENTRADA', :DATA, 'E', :DESCRICAO, 'E', NEW.ITE_QUANTIDADE); end Gostaria de saber como vocês contornam este problema, e como faço para resolver isto? Att,

Boa tarde Ítalo, Eu consegui identificar o problema. O restante do DACTE não foi impresso porque o XML que está sendo gerado quando o Tipo de Serviço do CT-e é 'Redespacho Intermediário', não está incluso as informações dos documentos (notas). Pois na linha 1069 da unit pcteCTeW está tratando a rejeição 694 do manual: Grupo Documentos Transportados não pode ser informado para tipo de serviço redespacho intermediário e serviço vinculado a multimodal. Neste caso, o tratamento deverá ser feito no arquivo do FastReport, para não exibir o Child dos Documentos Originários, assim como está na impressão que você anexou. Se os responsáveis da manutenção dos arquivos do FastReport ou algum colega que tenha maiores conhecimentos puder fazer as devidas alterações, pois tenho tentando sem êxito. Atenciosamente.

Boa tarde Ítalo, Desculpe pois esqueci de mencionar que estou utilizando o FastReport. O mais estranho é que o problema ocorre somente quando vou imprimir o CT-e carregando o XML. No momento do envio não ocorre o problema. Vou analisar melhor a reimpressão e os fontes do FastReport novamente, para ver se está ficando algo sem ser preenchido neste momento. Se tiver alguma dica que pode me ajudar, ficarei grato. Atenciosamente. Wislei.

Bom dia, Estou com um problema na reimpressão do DACTE de CT-e de Redespacho Intermediário que não estou conseguindo identificar a causa. Acontece o seguinte, quando eu faço a emissão de um CT-e deste tipo, tudo ocorre normalmente e ao exibir o DACTE após a autorização, ele fica completo, sem nenhum problema. Mas quando vou reimprimir ele, carregando ele pelo componente (LoadFromFile) e executando a impressão, o DACTE fica incompleto. Será que devo informar alguma propriedade ao componente que está faltando? Pois os demais tipos (Normal, Subcontratação e Redespacho) reimprimem normalmente, apenas o Redespacho Intermediário que ocorre este problema. Segue XML e PDF do DACTE com problemas. Obs: Eu teste pelo Demo_ACBrCTe e ocorre o mesmo problema. Atenciosamente. 31140903341645000186574990000005861540821637.pdf 31140903341645000186574990000005861540821637-cte.xml