Italo Giurizzato Junior

Paulo, Mas já esta liberado o ambiente de homologação?

Boa tarde, O titulo da sua postagem se refere a Encerrar o MDF-e sem o XML, isso é possível, basta você ter a chave e o protocolo de autorização do mesmo. Como não esta mais gravando o XML de retorno que tem o protocolo de autorização? O componente possui 3 propriedades Salvar quais são os valores delas?

Boa tarde Eric, Que eu saiba se o XML possui a string do QR-Code o mesmo será impresso no DAMDFE. Quem usa o Fortes Report posso garantir que sim, pois fiz testes com ele, já não posso dizer a mesma coisa para quem usa o Fast Report. Eu não vejo problema nenhum a impressão do QR-Code antes da data prevista. Entendo que antes de outubro/2019 a impressão é facultativa depois de outubro será obrigatória.

Paulo, Que maravilha, os caras não conseguem seguir um padrão deles para todas as cidades atendidas por eles. Testa com os arquivos abaixo: Cidades.ini SimplISS.ini

Boa tarde Eraldo, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e faça novos testes usando o programa exemplo.

Boa tarde Paulo, Segundo a sua primeira postagem o webservice do SimplISS só vai estar liberado para a cidade de Blumenau a partir do dia 16/09/2019, logo toda tentativa de envio vai ocorrer erro antes dessa data. Outra coisa para mim essa URL de homologação esta errada. Pois a URL de homologação utilizadas por todas as cidades que o provedor atente é: [URL_H] RecepcaoLoteRPS=http://wshomologacao.simplissweb.com.br/nfseservice.svc

Boa tarde, A nota que houve a rejeição 232 temos: indPres=1 Já a nota que foi autorizada temos: indPres=9 Experimente colocar 9 nessa nota que recebeu a rejeição 232 para ver se vai ser rejeitada novamente ou autorizada.

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.