Italo Giurizzato Junior

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

Bom dia Laudelino, Caso ainda não tenha lido, te aconselho a ler a Cartilha Nacional do MDF-e que encontra-se disponível no Portal Nacional do MDF-e. https://mdfe-portal.sefaz.rs.gov.br/

Bom dia Maiko, Eu sempre aconselho a realizar uma consulta caso não obtenha o numero do protocolo como retorno após o envio. Esse procedimento deve ser adotado para a NF-e, NFC-e, CT-e, MDF-e e etc. Só devemos enviar novamente, caso ao consultar a SEFAZ informar que o respectivo documento não se encontra na sua base de dados.

Bom dia Maiko, Tente incluir antes da sua rotina as seguintes linhas: ACBrMDFe.Manifestos.Clear; ACBrMDFe.Manifestos.LoadFromFile(NomeArquivo); Para carregar o XML do MDF-e que se deseja Encerrar. Se houver alteração na carga ou troca de veículo devemos efetuar o encerramento do MDF-e e emitir um novo. Favor ler a Cartilha Nacional do MDF-e disponibilizada no Portal Nacional do MDF-e. https://mdfe-portal.sefaz.rs.gov.br/

Bom dia Hugo, O componente não gera o XML da NFS-e, apenas o extrai do retorno e salva em disco. Notei que o XML que você anexou possui vários caracteres de espaço em branco entre as TAGs, abri com o bloco de notas e removi manualmente. Notei também que na TAG Complemento do endereço do Prestador de serviço a abreviação da palavra apartamento continha um carácter especial, troque por ponto. Feitas essas alterações o XML é aberto sem nenhum problema pelo navegador. Favor entrar em contato com o provedor para saber o motivo de o mesmo esta acrescentando os espaços em branco entre as TAGs.

Bom dia Augusto, Você poderia anexar o XML com a assinatura na posição errada e o outro com a assinatura na posição correta, pois acredito que podemos resolver o problema se a alteração que você fez em ACBrDFeSSL.

Bom dia Renan, Pela mensagem de erro noto que esta faltando a URL de consulta do QR-Code. Para qual UF você esta emitindo a NFC-e?

Bom dia Carlos, A url que você diz que esta errada consta no arquivo: ACBrNFeServicos.INI Favor corrigir e fazer um novo teste, caso funcione 100% favor nos dar um retorno para que possamos atualizar e enviar para o repositório.

Bom dia Felipe, Exatamente toda vez que é executado o ADD é criado um novo item que neste caso uma nova nota na lista.

Walter, Por favor não fique postando o mesmo problema diversas vezes. Vamos respeitar as regras do fórum. O seu questionamento já respondi em outra postagem sua.

Bom dia Walter, Entre em contato com o emitente das NF-e para saber como as mesmas foram emitidas. Se foi através do SVC será necessário esperar até a SEFAZ-Virtual de Contingência replicar essas notas para a SEFAZ-MG. Se foi através do evento EPEC, o emitente tem por obrigação enviar as notas para a SEFAZ-MG assim que os problemas forem sanados.

Bom dia Luiz, Estou estudando a melhor maneira de resolver esse problema, sem gerar efeitos colaterais nos demais componentes.

Bom dia Felipe, Você não pode quebrar a rotina que alimenta o componente em várias, uma vez que as propriedades que recebem os valores pertencem a um único elemento de uma lista.

Farnetani, O grupo <ICMSUFDest> só deve ser gerado se a venda for interestadual a consumidor final, caso contrario não é para ser gerado. Neste caso você pode atribuir tudo zero para que o grupo não seja gerado. Se tratando do Trunk, desculpe, mas você não acha que já passou da hora de ter migrado para o Trunk2? Faz um ano que estamos pedindo para que o pessoal migre.

Bom dia Célio, Você esta usando os fontes do Trunk2? Esta usando o ACBrInstall_Trunk2 para instalar os componentes?

Bom dia Angelo, Favor entrar em contato com o emitente da Nota e lhe informar que a aplicação dele esta gerando o XML de forma errada. Se ele for uma pessoa responsável vai passar o problema para quem desenvolveu a aplicação e exige a correção.