Italo Giurizzato Junior

Mariana, Não é no XML e sim no código do componente. Como disse antes, ou você implementa um DANFSE especifico para o provedor Betha ou faz uma alteração no DANFSE que já existe de tal forma que se o provedor for o Betha imprimir o conteúdo do campo Discriminação em um formato legível, caso contrario imprimi o conteúdo do campo como um texto normal.

Boa tarde Diego, Só fazendo um teste para saber. Envia um lote com 3 RPS e propositadamente informe a alíquota errada em um deles. Depois veja como fica o retorno.

Boa tarde, O XML que você anexou foi enviado e autorizado pela SEFAZ. Você quer emitir uma nota complementar dessa cujo XML você anexou? Se sim, essa nota complementar consta o grupo <pag>?

Boa tarde ALA, Muito obrigado pela colaboração, já vou enviar para o repositório.

Boa tarde Mariana, É preciso criar um DANFSE especifico para o provedor Betha ou fazer um tratamento, por conta nessas informações no campo Discriminacao. Caso contrario o PDF vai sair bagunçado mesmo.

Boa tarde Altamiro, A montagem do seu arquivo TXT esta errado. No campo tpEvento você esta informando o código 110111, só que esse código é do evento de cancelamento, o da carta de correção é 110110.

Boa tarde Altamiro, No caso de erro de Schema o envio da Carta de Correção chega a ser enviada? É gerado o XML de envio do evento da Carta de Correção? Se sim favor anexar. No caso de erro não catalogado é problema na SEFAZ, sendo assim, você deve entrar em contato com a SEFAZ e expor o problema. Detalhe importante: A Carta de Correção e Cancelamento são eventos, logo o XML da nota não tem utilidade nenhuma para nós, e sim os XML de envio (*-ped-eve.xml) e de retorno (*-eve.ml) do evento.

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

Bom dia Leandro, Maravilha, fico feliz que deu certo.

Leandro, O componente esta configurado para a versão 3.00?

Leandro, O XML atualizado vai ser salvo conforme a configuração do componente.

Carlos, Será que o WebService de homologação com a tal checagem de certificado já esta funcionando? Tente também aumentar o valor de Timeout.

Boa tarde Rodrigo, O problema desse XML é uma vogal com acento na palavra: ITAJAI.

Leandro, Esse XML não contem o protocolo de autorização, se você carregar ele para poder efetuar o encerramento, o componente não vai encontrar o protocolo de autorização. Carregue esse XNL e faz uma consulta para atualizar o XML com o protocolo de autorização. Depois use o XML atualizado para efetuar o encerramento.

Carlos, Tente com o libCapicom.

Boa tarde Leandro, O Recibo que você se refere é o Protocolo de Autorização? Se sim, vide o programa exemplo. Agora se o Recibo que você se refere é o Recibo retornado ao enviar o MDF-e para SEFAZ, ai não tem como.

Carlos, Qual é o valor de SSLLib na configuração do programa exemplo?

Matheus, Realmente esta faltando, vamos providenciar a implementação do comando e disponibilizar a sua sintaxe no manual. Essas alterações é bem provável que só sejam disponibilizadas na próxima versão semanal para que é SAC.

Boa tarde Matheus, Não tem o comando MDFe.EnviarEvento ?

Boa tarde a todos, Alguém sabe dizer se esse layout do XML é exclusivo da Caixa ou é um layout a ser adotado por todos os Bancos?

Boa tarde Fábio, Como dito na postagem anterior, pelo fato do provedor não seguir o layout da ABRASF, o manual estar confuso e por não ter tempo no momento, não vou implementar esse provedor.

Boa tarde Carlos, Tente fazer o seguinte: no arquivo INI do provedor existe um campo chamado UseCertificado, se o valor for zero altere para 1 e faça um novo teste.

Muito obrigado pela colaboração, vou analisar as mudanças.

Bom dia Carlos, O provedor da cidade Montes Claros/MG é Pronimv2 e este requer o certificado digital para poder assinar o Lote de RPS antes do envio. Ao meu ver não se faz necessário nenhuma alteração.

Bom dia, Seria interessante você anexar as alterações que fora feitas nos arquivos Cidades.ini e Publica.ini em virtude da mudança de provedor, desta forma outros desenvolvedores podem ajudar nos testes.