Italo Giurizzato Junior

Eraldo, Ao abrir o arquivo Cidades.INI e procurar pela cidade de código 2504009, encontrei a cidade Campina Grande/PB, é essa? Se sim, temos uma incoerência, pois no arquivo Cidades.INI consta que essa cidade é atendida pelo provedor ISSIntel e não pelo WebISSv2. Essa cidade mudou de provedor? Se sim, favor solicitar junto ao provedor as URLs de homologação e de produção.

Bom dia Denys, Abra o XML que você anexou através de um navegador e veja no final dele que as tags: username e password estão vazias. Sem essas informações o provedor não vai aceitar.

Bom dia Gilson, A alíquota que você esta informando esta errada para essa empresa, caso ela esteja correta é preciso realizar o cadastro da mesma, acredito eu via site, pois pelo componente isso não é possível ser feito.

Bom dia Nilton, Acredito que neste caso devemos informar que a série é UNICA. IdentificacaoRps.Serie := 'UNICA';

Bom dia Juliano, Acredito que o problema é o provedor que formata os valores no XML. Abra esse XML que você anexou usando um navegador, vai notar que o valor da tag <ValorServicos> é 1.035,00 em vez de 1035,00 Notou a diferença? Tem o ponto "." de milhar. Se remover esse ponto tenho certeza que o erro não vai mais ocorrer. Deve ser removido também o ponto de milhar das tags: BaseCalculo e ValorLiquidoNFSe.

Bom dia a todos, Pessoal o correto é com duas barras, conforme consta no arquivo INI do provedor. Se não for com duas // o namespace ao utilizar o libWinCrypt ocorre erro ao tentar assinar o lote. Foi necessário alterar o schema para que ocorresse a validação. Como o WSDL do provedor esta errado, ou seja, com apenas uma barra, se fez necessário incluir uma gambiarra na unit ACBrNFSeWebServices, que realiza a troca das duas barras por apenas uma, desta forma quando o XML chegar no provedor ele consegue processar com sucesso. Essa gambiarra tinha sido feita apenas para o método Enviar para fim de testes, agora foi estendida para os demais métodos. Favor atualizar os fontes e façam novos testes. Por favor utilizem o arquivo INI que esta no repositório bem com o schema, não façam nenhuma alteração, do tipo trocar as duas barras por uma.

Bom dia Sérgio, Com relação ao DIFAL favor entrar em contato com o contador do seu cliente para saber como deve proceder. No que diz respeito a versão, não existe ve300a e sim ve300 que atende tanto a versão 3.00 quanto a 3.00a.

Bom dia Léo, Eu não trabalho com o Fast Report, mas farei um teste com o Fortes usando o seu XML. Vou passar o problema para os consultores que tem mais intimidade com o Fast para eles verem o que esta ocorrendo.

Bom dia, Então pede para eles explicarem porque no exemplo deles esta 2530000 e em vez de 0025300. E também porque ao informar o código 0025300 a rejeição continua a mesma.

Bom dia Luiz, Com esse teste, para mim esta claro que a SEFAZ-MT não implementou a alteração da regra J07 referente ao evento de não embarque que consta na Nota Técnica 2018/001. Neste caso peço que entre em contato com a SEFAZ e exponha o problema.

Bom dia Josevaldo, No caso do MDF-e o modo de envio é sempre Síncrono, portanto é enviado um MDF-e de cada vez. Apesar de na resposta constar o campo nRec, ele vai sempre estar vazio, pois essa informação só existe no envio de NF-e e CT-e que aceitam o modo assíncrono, ou seja, um lote com até 50 documentos.

Bom dia Eraldo, Procure sempre realizar os testes utilizando o programa exemplo do componente. Com relação a configuração use a da imagem abaixo: O erro esta ocorrendo ao tentar enviar o Lote? Se sim, procure sempre informar que o lote tem apenas 1 RPS ou 2 a titulo de teste. Todos os arquivos de todas as pastas estão atualizados?

Boa tarde Carlos, Note que no retorno temos a rejeição 999 que é típica quando a SEFAZ esta com algum problema. Outra coisa importante, existem outros eventos de comprovante de entrega para o CT-e informado no evento?

Boa tarde Léo, Seria bom você anexar o XML para que possamos realizar testes. Outra coisa importante o DACTE foi gerado pelo Fortes ou Fast Report?

Roger, Acredito que você esteja gerando o XML de forma idêntica ao schema. Não é bem assim, veja como esta ficando a sua rotina em comparação com as demais. O que esse provedor disponibilizou foi o arquivo XSD que é o schema, veja com eles se eles fornecem um XML a titulo de exemplo.

Bom dia Roger, Desde já muito obrigado pela colaboração, vou analisar o que você já fez e enviar para o repositório para que outros membros do fórum que precisam utilizar o mesmo provedor, possam também ajudar nos testes e propor correções.

Bom dia Luiz, O primeiro BP-e foi emitido em 06/09/2019 as 08:49:42 com data/hora de embarque: 06/09/2019 - 09:00:00 O evento de Não Embarque foi emitido em 06/09/2019 as 15:22:14 e foi rejeitado pelo motivo: 221 - Prazo para geração do evento de não embarque superior ao limite tolerado em relação a data/hora do embarque. A regra referente a rejeição 221 é a J07 (página 48 do Manual Visão Geral - Abril 2019) e diz: Verificar se data-hora do evento não ultrapassa 24 horas da data-hora de embarque informada no BP-e. Pela regra o evento não poderia ser rejeitado, uma vez que não atingiu o limite de 24 horas em relação da data/hora de embarque. A NT 2018/001 alterou a regra de validação J07 que antes era: Verificar se data-hora do evento não ultrapassa 24 horas da data-hora de embarque informada no BP-e para prestações interestaduais; ou 2 horas em caso de prestações intermunicipais. OBS: Prestações com exterior devem utilizar o prazo de 24h. para: Verificar se data-hora do evento não ultrapassa 24 horas da data-hora de embarque informada no BP-e. O seu BP-e é uma prestação intermunicipal, acredito que a SEFAZ-MT não aplicou essa alteração que estava prevista para 02/02/2018, visto que ela possui o seu Webservice próprio para recepcionar o BP-e. Para comprovar ou não a minha suspeita, faça o seguinte: 1. Emite um BP-e normal com prestação intermunicipal. 2. dentro depois de 1 hora do horário de embarque envie o evento de não embarque. 3. Se o evento for autorizado envie o BP-e de substituição. Se o BP-e substituto for autorizado podemos concluir que a SEFAZ-MT não alterou a regra J07 do evento de não embarque. De posse dos testes realizados, favor entrar em contato com a SEFAZ e expor o problema.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Roberto, Por favor só anexe os arquivos que você fez alguma alteração, os demais não precisa. Desde já muito obrigado pela colaboração, vamos analisar o que você já fez.

Boa tarde a todos, Por favor leia esse artigo: Como obter o XML do Fornecedor.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Laudelino, Você não pode incluir o INI do MDF-e junto com o da NF-e. Existem comandos da NF-e (NFe.comando) e existem comandos do MDF-e (MDFe.Comando). Sendo assim, você gera um arquivo INI para a NF-e e outro para o MDF-e. Muitos comandos são idênticos, inclusive os parâmetros. Um detalhe importante com relação ao MDF-e. Todo MDF-e tem que ser Cancelado caso o transporte não ocorra, ou Encerrado quando toda a carga do caminhão for entregue. Se não encerrar não consegue emitir outro MDF-e para o mesmo caminhão. Existem outras situações que devemos fazer o encerramento. Sugiro que você baixe a Cartilha Nacional do MDF-e que se encontra no Portal da SEFAZ-Virutal do RS - MDF-e e leia com muita atenção, existem diversos exemplos (situações) de transporte.

Bom dia Carlos, No XML de pedido de evento o valor da tag nSeqEvento é 3, no meu entendimento deveria ser 1. E também não consta no XML o grupo infEntrega com a chave da NF-e. Logo o bloco abaixo: while not dmCTe.sqlCTeNFe.Eof do begin with infEvento.detEvento.infEntrega.New do chNFe := dmCTe.sqlCTeNFechavenfe.AsString; dmCTe.sqlCTeNFe.Next; end; não esta sendo executado.

Bom dia Luiz, Pelo que entendo o Fluxo é: 1. Foi emitido o BP-e de numero 100. 2. Foi emitido o evento de não embarque. 3. Foi emitido o BP-e de numero 101 informando que este substitui o de numero 100. Preciso de todos esses XMLs para descobrir o que possa esta ocorrendo.

Se informa o código IBGE correto, ocorre erro, se informa o código que tem no exemplo deles ocorre erro, agora não sei o que fazer. Entre em contato com o provedor e questione eles sobre esse erro.