Italo Giurizzato Junior

Bom dia Maiko, Na versão 2.00 o termo é Local de Coleta e não de Retirada. Acredito que ao informar o Local de Coleta não muda em nada no tipo de serviço. E pelo que estou entendendo o material a ser transportado pertence a transportadora, é por isso que ela é o remetente, correto? Quanto a impressão, o DACTE não contempla a impressão do Local de Coleta e Entrega, neste caso há necessidade também de informar esse endereço no campo de observação. Esse Local de Coleta pertence a transportadora? Se sim, porque não informa-lo como sendo o endereço do remetente?

Bom dia a todos, Se um tipo ou constante ou identificador é apontando como inexistente pelo Delphi e no fonte ele esta declarado. Verifique se no Library Paths a pasta que contem esse fonte não esta depois da pasta que contem o componente que você esta compilando. Por exemplo (lista do Library Paths): C:\ACBr\Fontes\ACBrCTe C:\ACBr\Fontes\PCN2 Como o ACBrCTe se utiliza de algumas units que estão na pasta PCN2 a ordem correta é: C:\ACBr\Fontes\PCN2 C:\ACBr\Fontes\ACBrCTe Espero ter ajudado.

Bom dia Eduardo, O Exemplo que você postou esta correto. O componente que permite incluir essa TAG: NVE apenas uma unica vez, portanto precisa ser corrigido.

Bom dia Lazaro, Inclui a cidade no provedor GovBR em função dos Schemas que você postou. Caso não o Web Services rejeite o lote de RPS vamos ter que mudar essa cidade para o provedor Pronim. Favor atualizar os fontes e iniciar os testes.

Boa tarde, No final dessa portaria notei que o CT-e deve contem informações sobre o caminhão e do motorista. Para que essas informações constem no XML e consequentemente no DACTE, o CT-e tem que ser Lotação. Como o MDF-e é para carga fracionada, conclui-se que não há necessidade de emitir o MDF-e, apenas o CT-e.

Boa tarde, Se você levar em consideração o tomador, podemos dizer que o CT-e é lotação, uma vez que o tomador é único. Neste caso o CT-e sendo de lotação, devemos informar o caminhão e o motorista e sendo assim não se faz necessário o MDF-e, visto que o mesmo é destinado a carga fracionada. Se você levar em consideração o destinatário, podemos dizer que o CT-e é fracionado, uma vez que temos vários destinatários. O CT-e sendo de carga fracionada, não informamos o caminhão e o motorista. Carga fracionada e transporte interestadual deve-se emitir o MDF-e mesmo que tenhamos apenas um CT-e.

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.