Italo Giurizzato Junior

Bom dia a todos, A diferença da versão 1.04 e 2.00 para o componente é apenas a estrutura do XML nada mais. Não existe uma rotina de envio para a 1.04 e outra para 2.00 Portanto se esta ocorrendo alguma lentidão (envio/autorização/impressão) ou é a internet do emitente ou é a SEFAZ.

Bom dia Lucio, O componente ACBrMDFe já foi alterado segundo a NT 2014/003 divulgada pela SEFAZ-RS no dia 23/06/2014. Os Schemas que acompanham o programa exemplo do componente também foram atualizados. Tudo esta disponível no repositório.

Bom dia Junior, O provedor E&L não segue o padrão ABRASF, a estrutura é semelhante mas não é igual veja esse fragmento do XML: XML segundo o provedor E&L: <Endereco> <LogradouroTipo>Rua</LogradouroTipo> <Logradouro>LOGRADOURO</Logradouro> <LogradouroNumero>999</LogradouroNumero> <LogradouroComplemento>Casa</LogradouroComplemento> <Bairro>CENTRO</Bairro> <CodigoMunicipio>9999999</CodigoMunicipio> <Municipio>NOME MUNICIPIO</Municipio> <Uf>ES</Uf> <Cep>99999999</Cep> </Endereco> o mesmo fragmento segundo o padrão ABRASF: <Endereco> <Endereco>RUA PRINCIPAL</Endereco> <Numero>100</Numero> <Complemento>APTO 11</Complemento> <Bairro>CENTRO</Bairro> <CodigoMunicipio>2103000</CodigoMunicipio> <Uf>MA</Uf> <Cep>69301040</Cep> </Endereco> Notou as diferenças (negrito): TAGs de nomes diferentes e ausências de outras no padrão ABRASF.

Bom dia Mattos, Se os seus fontes estão atualizados, se os Paths estão na sequencia correta no Library Paths do Delphi, concluo que o seu Delphi esta encontrando algum DCU antigo e utilizando-o na compilação. Na pasta que contem os fontes da sua aplicação, não existe nenhum .PAS ou .DCU do pcnConversao ?

Bom dia a todos, Para utilizar mais de um NVE será necessário fazer uma alteração no componente. Pois quando essa TAG foi implementada como sendo um Elemento, passou desapercebido o número de ocorrências. Que no caso de um Elemento o normal é aparecer 0-1 (opcional) ou 1-1 (obrigatório). No caso da TAG: NVE (Elemento) o número de ocorrências é: 0-8, isso significa que ela é opcional mas pode ocorrer até 8 vezes. No seu exemplo Elton, teríamos: <NVE>AA0001</NVE> <NVE>AB0001</NVE> <NVE>AC0001</NVE>

Bom dia Maiquel, Para dar inicio a implementação precisamos: * Quais são as cidades atendidas por esse provedor? * Dos Schemas de validação. * Das URLs de homologação e produção de cada cidade atendida. * Se conseguir, exemplos de arquivos SOAP de envio, consulta, cancelamento, .... seria ótimo.

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.

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 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.