Italo Giurizzato Junior

Boa tarde Paulo, Muito obrigado pela colaboração, vou analisar, estando tudo OK, vou enviar para o repositório.

No segundo link que você postou abre uma pagina com vários outros links. Tem um chamado "XML de exemplo", os arquivos req*.xml se refere aos XMLs de envio e os resp*.xml são os de retorno. Veja os de envio, a assinatura se encontra no grupo Header, todos os demais provedores assinam o XML que se encontra no grupo Body. Pelo que eu entendi, analisando os XMLs de envio, o XML é gerado, o grupo Body é montado, uma assinatura é realizada no conteúdo desse grupo e a mesma é colocada no grupo Header. A geração do XML do RPS segue a versão 2 do layout da ABRASF, mas a assinatura tinha que fazer diferente, tenha dó. Caso você queira colocar a mão na massa, boa sorte.

Bom dia Sergio, Ontem tive problemas com o envio da correção, acabei enviando hoje de manhã. Favor atualizar os fontes e fazer novos testes.

Mariana, Lendo outras postagens sobre o provedor Betha aqui no fórum, me parece que somente o webservice implementado segundo a versão 1 do layout da ABRASF do provedor Betha é que funciona, já o outro que foi implementado segundo a versão 2 não funciona. Como dito, segundo relatos em outras postagens.

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

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

Bom dia Mariana, Que informações você quer enviar e para quem? Desculpe não entendi.

Bom dia a todos, O provedor Betha possui 2 WebServices, um foi implementado segundo a versão 1 do layout da ABRASF e o outro foi implementando segundo a versão 2. Note que existe os arquivos INI: Betha.ini e Bethav2.ini Veja também o arquivo Cidades.ini, vocês encontram cidades cujo provedor é Betha e outras que é Bethav2. É desta forma que informamos ao provedor se uma cidade vai usar um provedor ou outro.

Bom dia a todos, Se não me falha a memória esse provedor elotech realiza uma assinatura digital totalmente diferente da adota em todos os Documentos Fiscais Eletrônicos.

Bom dia Gabriel, Emitir NFS-e via Site é uma coisa, emitir via WebService é outra. Pelo Site o seu cliente tem que entrar com o usuário e senha ou CNPJ e senha, essas informações permite ao Site deixar ou não a pessoa emitir a NFS-e. Por outro lado no WebService não temos o usuário e senha e sim o certificado digital que contem o CNPJ do emitente, portanto é através do certificado digital que o WebService decide se deixa ou não a nota ser emitida. No caso do provedor Betha, se faz necessário gerar e assinar o XML do RPS e após a montagem do Lote de RPS o mesmo deve ser assinado, resumindo: tanto o RPS quando o Lote de RPS devem ser assinados. E para assinar é preciso do certificado digital. No arquivo INI do provedor tem uma seção chamada: Assinar, onde temos os campos RPS e Lote, ambos com o valor 1, altere para zero e tente enviar, para ver se o provedor aceita. Mas faça esse teste junto com esse cliente, para ele ver que não é possível a emissão da nota sem o certificado.

Bom dia, Favor anexar a unit alterada para que possamos analisar.

Bom dia Anderson, Qual é o método que você esta usando para baixar o XML? Você poderia anexar um XML que ocorre o problema?

Bom dia, Esse provedor não segue um padrão de local de assinatura teremos que analisar e encontrar uma solução para o problema. Muito obrigado pelo XML de exemplo.

Bom dia Adailson, E porque você esta baixando o XML do Portal do MDF-e? Caso tenha perdido o XML (coisa que não pode ocorrer) e ao baixar do Portal vem sem o protocolo de autorização, é muito simples de resolver. Se você é o emitente do MDF-e, basta carregar o XML baixado através do LoadFromFile e em seguida executar o método Consultar. Pronto o XML será atualizado e ficará completo, ou seja, assinado e com o protocolo de autorização.

Bom dia Vanderlei, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Sérgio, Eita passou batido, muito obrigado pela observação, vou fazer a correção e enviar para o repositório ainda hoje.

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.

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.