Italo Giurizzato Junior

Bom dia Foley, O componente antigo ao pegar o retorno do web services substituía todas as vogais acentuadas por não acentua e o cedilha por "C" desta forma esse problema não ocorria.

Bom dia Sérgio, Será necessário você emitir 2 MDF-e. Vamos chamar esses 2 Estados de AA e BB. No primeiro você vai informar SP como Estado de saída, como Estado de descarregamento o AA e vai relacionar todos os CT-e. No segundo você vai informar AA como Estado de Saída, como Estado de descarregamento o BB e vai relacionar somente os CT-e que vão ser entregues em BB. Quando o caminhão sair de AA a caminho de BB, você deve encerrar o primeiro MDF-e e quando o caminhão finalizar a segunda entrega em BB, o segundo MDF-e deverá ser encerrado. OBS: o caminhão pode sair de SP já com os 2 MDF-e emitidos.

Bom dia Daniel, Anexa o TXT que você criou para que possamos analisar.

Boa tarde a todos, Se não deseja que o PDF do DANFE seja salvo juntamente com o executável da sua aplicação, basta definir um Path em PathPDF.

Foley, Acredito que seja necessário fazer mais alguns ajustes no componente.

Boa tarde vipeol, Você esta realizando testes do método DistribuicaoDFe em ambiente de homologação ou de produção? Essas notas tanto o emitente quanto o destinatário possuem o mesmo CNPJ e o valor da nota é de 1 centavo com certeza trata-se de teste. A data de emissão dessas notas é recente?

Boa tarde Marcelo, Tenho um cliente que utiliza certifico A3 a um bom tempo já atualizei a aplicação diversas vezes e nunca o certificado foi apagado do cartão. Sugere aos seus clientes a mudar para o A1, vai ter que atualizar todo ano, sim, mas não vai ter mais esse tipo de problema.

Adilson, Testa com o Cidades.INI que eu enviei para o repositório.

Boa tarde Dorivan, É o que eu afirmo no paragrafo que você citou na sua postagem. Só lançamos mão da consulta caso de envio assíncrono ou caso ocorra algum problema no retorno e o XML sem fica sem o protocolo. Neste último caso devemos ter o componente carregado com o XML da NFC-e para que possamos realizar a consulta. Se o retorno dessa consulta for que a nota esta autorizada o protocolo será acrescentado ao XML.

Boa tarde Isaac, Você tem que utilizar os schemas da pasta: ...\Exemplos\ACBrDFe\Schemas\NFe

Boa tarde Willian, Antes de enviar o CT-e para SEFAZ, foi enviado o evento de EPEC? Se não foi isso significa que a SEFAZ esta fazendo algo de errado.

Boa tarde, Não, é preciso fazer mais alguns ajustes para que as vogais acentuadas sejam tratadas de forma correta.

Boa tarde Adilson, Muito obrigado pela colaboração. Já enviei para o repositório.

Bom dia Willian, O problema é que o CT-e foi rejeitado, pelo simples fato da sua forma de emissão ser 4 = EPEC e o seu tipo ser diferente de Normal. Resumindo, quando enviamos um EPEC o tipo do CT-e tem que ser Normal.

Bom dia, Abra o XML que você anexou como "ERRO" com o bloco de notas e tire o acento da vogal A da palavra Funcionários. Depois salve a alteração e tente abrir ele novamente com o navegador.

Bom dia, Não, o retorno contendo o numero do protocolo que atesta que o lote de RPS foi recebido pelo provedor é retornado no mesmo instante. Essa propriedade serve para definir um tempo entre o envio do lote e a consulta a situação do mesmo. Dependendo do provedor, após o envio lote, devemos consultar a sua situação, e repetir esse consulta enquanto a sua situação for em processamento. Quando passar a ser lote processado devemos consultar o lote e como resultado teremos os XML das NFS-e ou as mensagens de erros. Como é de se esperar um congestionamento de requisições no provedor é interessante dar a ele um tempo antes de realizar a primeira consulta a situação do lote. Existe uma outra propriedade onde você pode definir o tempo entre uma tentativa e outra para saber se o lote já foi processado ou não, bem como o numero de tentativas. Espero ter ajudado.

Bom dia a todos, Analisando ambos os XMLs (anexados pelo Duarte), notei que o problema é a posição da assinatura. Pois bem, notem que o arquivo INI possui dois campos referentes a assinatura: RpsGerar e LoteGerar. Para a maioria dos provedores que possuem o método GerarNFSe devemos configurar esses dois campos da seguinte forma: RpsGerar=1 ou 0 LoteGerar=0 para que o RPS seja assinado ou não. Para os provedores que admitem um lote (com 2 ou 3 RPS) no Gerar devemos configurar da seguinte forma: RpsGerar=0 LoteGerar=1 ou 0 para que o Lote seja assinado ou não. Notem que o XML dito como correto (anexado pelo Duarte) a assinatura esta dentro do grupo <Rps>, isso significa que é o RPS que esta sendo assinado. Por outro lado o XML dito como errado, a assinatura esta dentro do grupo <GerarNfseEnvio>, isso significa que é o Lote que esta sendo assinado. Peço que desfaçam as alterações realizadas nos fontes do componente e altere a configuração no arquivo INI do provedor de: RpsGerar=0 LoteGerar=1 para RpsGerar=1 LoteGerar=0 E realizam novos testes.

Bom dia a todos, Por favor prestem muita atenção onde postar os seus problemas. Aqui é um lugar destinado ao componente ACBrMDF-e e este se utiliza somente da SEFAZ-RS, pois é esta que recepciona todos os MDF-e emitidos por todos os Estados Brasileiros. Luiz, na sua primeira postagem você não informa o que esta sendo emitido, se é NF-e, NFC-e, CT-e ou MDF-e.

Maiko, Leia a Cartilha Nacional do MDF-e. https://mdfe-portal.sefaz.rs.gov.br/

Bom dia Luciano, Não existe mais o grupo de informações de Local de Entrega, bem como Local de Coleta.

Maiko, Se você gera um código aleatório para o documento a ser emitido, código este que vai compor a chave esta correto. Mas procure salvar esse código aleatório juntamente com os demais dados do documento no banco de dados. Por exemplo temos o nMDF que é o numero do MDF-e e o cMDF que é o código aleatório do MDF-e, ambos vão fazer parte da chave do MDF-e. Pois bem na tabela que entre outras coisas temos o numero do MDF-e crie mais um campo para armazenar o código aleatório. Isso deve ser feito antes de alimentar o componente com os dados, desta forma quando você for alimentar o componente para emitir o MDF-e, você vai atribuir a nMDF e a cMDF informações lidas do banco de dados. Caso seja necessário gerar novamente o XML de um MDF-e a chave deste novo será igual ao do antigo. Quando devemos gerar novamente o XML? Por exemplo quando o digníssimo usuário fez o favor de deletar o mesmo.

Bom dia, Uma dica abra o arquivo INI do provedor Tecnos, Você vai descobrir que ele não possui Web Services para os serviços: Recepcionar, ConsultarSituacao, Gerar e Substituir do resto ele possui. Sendo assim, dos 4 métodos de consulta que você postou um você não vai conseguir usar pelo motivo exposto acima, concorda?

Bom dia Jairo, Abra o arquivo INI chamado Cidades.INI e veja como foi incluída as demais cidades que se utilizam do provedor Tecnos. Faça o mesmo para a cidade desejada. Note que existe dois campos que no caso dessa cidade fica: NomeURL_H=sclara NomeURL_P= ??? procure saber como fica para o caso do ambiente de produção, pois as URLs que você postou são apendas do ambiente de homologação.

Bom dia Danny, Muito obrigado pela informação, já alterei o arquivo INI do provedor SimplISS.

Bom dia Antonio, Eu lhe pedi para anexar os XML e não postar um resumo deles, desculpe assim não tem como eu avaliar o problema. Outra coisa a TAG <GerarNfseEnvio> é um grupo que contem a o XML do RPS assinado e a assinatura é feita com base no conteúdo do grupo <InfRps>.