Italo Giurizzato Junior

Bom dia Lazaro, Favor conseguir com a prefeitura ou com o provedor que atende ela para recepcionar as NFS-e, as URLs de Homologação e Produção.

Bom dia Ailton, Pelo que me consta a cidade de Campo Grande/MS já esta implementada no componente ACBrNFSe. Provedor: IssDSF

Bom dia Pablo, Fiz uma alteração na rotina que define o nome do PDF do evento. É necessário agora a compilação do ACBrNFeMonitor.

Bom dia Vanessa, Pesquisando na Internet achei esta função que calcula o DigestValue, não testei. function DigestValue(XML: String; out Dados: WideString): Boolean; var HashedData: IHashedData; AlgoHash : CAPICOM_HASH_ALGORITHM; begin Try AlgoHash := CAPICOM_HASH_ALGORITHM_SHA1; HashedData := CoHashedData.Create; HashedData.Algorithm := AlgoHash; HashedData.Hash(XML); Dados := HashedData.Value; Result := True; except on E: Exception do begin Result := False; MessageDlg(E.Message, mtError, [mbOk], 0); end; end; end; O segundo parâmetro é o retorno, ou seja o DigestValue.

Bom dia Leandro, Post como anexo os 2 XML (gerado pelo site e pelo componente) para que possamos analisar.

Bom dia, Favor atualizar os fontes e testar novamente a consulta.

Bom dia Lucio, O componente esta configurado para a versão 1.00a (ve100a)? Você esta lendo o manual desatualizado, por favor baixe a NT 2013/004 versão 1.00a de Outubro/2013 Você esta usando os schemas do pacote PL_MDFe_100a_pre (correcao) ?

Vanessa, Segundo a Especificação Técnica, diz que quando o XML receber a assinatura o DigestValue tem que ser exatamente igual ao informado no QR-Code. Ai temos um problema, pois quando é realizado a assinatura o DigestValue fica com 28 caracteres, mas quando é calculado o Hash no XML fica com 40. O próximo teste é comparar esses 2, caractere por caractere. Para saber se no segundo caso devemos pegar os 28 primeiros caracteres ou os últimos, ....

Leandro, Não post o seu problema em vários tópicos, por favor siga as regras do fórum. Obs: já lhe respondi sobre o seu problema em outro tópico.

Bom dia Leandro, Por favor atualize os fontes e teste novamente.

Bom dia EFV, A CC-e é um evento, sendo assim, estude o programa exemplo do componente ACBrCTe. Ele esta na pasta: ...\Exemplos\ACBrCTe\Delphi.

Bom dia Jefferson, Quanto ao erro de propriedade não existente, favor executar o passo a passo que esta em um arquivo TXT dentro da pasta ...\Fontes\ACBrNFSe. Com relação ao retorno do Web Service, a mensagem esta clara. O RPS já foi enviado, agora você tem que aguardar. Alguns provedores passam o dia recebendo os lotes de RPS, mas só processam durante a madrugada, portanto só no dia seguinte que você vai conseguir o XML da NFS-e referente ao RPS enviado, para isso, deve-se realizar uma consulta.

Bom dia Anderson, Favor atualizar os fontes e testar novamente.

Bom dia Vanessa, O que tudo indica, sim, a sua rotina esta correta. Só falta checar 2 coisas: 1. oACBrNFe.NotasFiscais.Items[ 0 ].XML esta retornando o XML inteiro da NF-e (sem a assinatura)? 2. O tamanho em caracteres do sDigestValue é o mesmo quando TipoTransmissao é igual a 'N'?

Bom dia Eric, Como você esta emitindo NF-e aconselho você executar o comando enviar da seguinte forma: AcbrNfe.Enviar(1, False, False) O primeiro parâmetro se refere ao numero do lote a ser enviado (aconselho ser um numero sequencial, controlado pela sua aplicação) O segundo quando False faz com que o DANFE não seja impresso automaticamente. O terceiro se refere ao modo de envio: False = Assíncrono, True = Síncrono O modo Síncrono foi criado para a NFC-e, que poderá ser liberado ou não pela SEFAZ para as NF-e. Faça essa alteração e realize novos testes.

Bom dia Marlon, O componente ACBrNFe ainda não contempla essa possibilidade. O envio da NF-e "zipada" depende também da SEFAZ ter implementado esse recuso em seu Web Services.

Bom dia a todos, Acredito ter encontrado uma solução para o problema. Não só para os dois provedores mencionados, como para todos os que no XML do RPS aparece o grupo <Rps> duas vezes. Ainda hoje estarei disponibilizando as alterações.

Bom dia Glécio, Muito obrigado pela colaboração, ainda hoje estarei disponibilizando.

Boa tarde Vanessa, Acredito que todos os DANFE - NFC-e que já foram feitos pegam o digVal do XML, no caso de contingência como não esta assinado o seu conteúdo vai ser vazio. Com essa alteração nas Especificações Técnicas sobre o QR-Code vamos ter que voltar a prancheta para resolver essa questão.

Boa tarde Rômulo, Acredito que você já esteja emitindo o CT-e na versão 2.00, correto? Uma vez que a SEFAZ não aceita mais na versão 1.04 desde o dia 2 de junho de 2014. Pois bem, alem de estar emitindo na versão 2.00, você esta ciente que agora temos a CC-e para o CT-e? Esta sabendo que para cancelar um CT-e na versão 2.00 é através de evento? Se você sabe de tudo isso, esta claro o motivo pelo qual as linhas que você mencionou foram comentadas. Simplesmente por que não existe mais o Web Service de cancelamento, agora é por evento. Outra coisa essa linhas foram comentadas em função da publicação da NT 2013/013 - Alteração MOC 2.00 (página 177)

Boa tarde Leonardo, Mais uma vez muito obrigado pela colaboração. Já esta disponível.

Boa tarde Vanessa, No meu entendimento quando emitidos o DANFE da NFC-e em contingência, devemos: 1. Trocar o Tipo de emissão para (tpEmis=9) 2. Assinar o XML 3. Utilizar o Digest Value da assinatura no QR-Code.

Boa tarde, Pesquise no fórum por favor. Existe um tópico que alguns usuários estão tratando desse assunto, mas até agora nada foi disponibilizado para toda a comunidade.

Fabio, Se tratando de uma nota cancelada ao realizar a consulta o XML é alterado? Ou seja o protocolo de autorização é removido e inserido no lugar o de cancelamento? Se sim, isso explica por que na NF-e você consegue imprimir a Tarja de cancelado sem o uso da propriedade NFeCancelada. O mesmo não ocorre com o CT-e.

Augusto, Para consultar o status de serviço, há necessidade de estar com os schemas para a versão que se deseja trabalhar ou seja a 3.10 Vai ai um alerta, a SEFAZ já esta acenando a possibilidade de extinguir o Consultar Status de Serviço. Logo deixe isso como sendo algo opcional na aplicação e não como parte de um processo. Por exemplo no Form coloque um botão para consultar o status e apresentar na tela o resultado da consulta. Só isso e nada a mais. Se a SEFAZ vir realmente a extinguir o Consultar Status, basta você remover a rotina desse botão e remove-lo do Form. O Validar e Assinar estão embutidos no Enviar. O Assinar necessita do certificado instalado e o Validar necessita dos schemas já mencionados no inicio. Três rotinas: 1. Configurar o componente 2. Alimentar o componente com os dados pertinentes a venda 3. Controle de Envio Sendo que este ultimo possui o comando Enviar, que se você passar somente como parâmentro o numero do lote, ele se encarrega de gerar o XML, assinar, validar, gerar o lote, enviar, se autorizado protocolar o XML e imprimir o DANFE. Como você pode ver um único comando resolve praticamente tudo.