marcoanjos

Pode ser por que o CTe foi rejeitado.

Há algum tempo o provedor da betha parou de realizar o cancelamento da NFSe. Verificando o manual de integração da betha (v1) percebi que eles alteraram a url do serviço de cancelamento. Eu alterei a url no arquivo betha.ini: CancelaNFSe=https://e-gov.betha.com.br/e-nota-contribuinte-ws/cancelarNfse?wsdl para: CancelaNFSe=https://e-gov.betha.com.br/e-nota-contribuinte-ws/cancelarNfseV02?wsdl Dessa forma voltou a funcionar. Só estou registrando minha experiência porque não achei nada no fórum a respeito disso, espero que possa ser útil. Betha.ini

Olá amigos, estou tendo um problema relacionado a timeout. Em certos clientes do interior, a internet é muito ruim, via rádio, há perda de pacotes, cai no meio da transmissão, e por aí vai... Quando isso acontece durante o processo de envio o sistema leva muito tempo para retornar uma exception, as vezes fica 2 ou 3 minutos processando o envio. Estou tentando usar o timeout do componente, especificamente a propriedade ACBrNFe.Configuracoes.WebServices.TimeOut=10000, o que eu acredito que faria com que o processo fosse interrompido caso eu não tivesse um retorno em 10 segundos, mas isso não acontece. Não sei se estou no caminho certo, agradeço qualquer ajuda, Obrigado

Bom dia Volmir, estou com esse mesmo problema no ambiente de homologação "00000 - O servico ou a CNAE informado nao estao relacionados ou nao existem. *" , no ambiente de produção estou com outro erro, a nota é enviada, processada com sucesso mas não consigo pegar o retorno do lote, acontece o mesmo contigo?

Vou te mandar um trecho de código que pode te ajudar a debugar, descobrir o problema, mas vai ter que testar em produção. Verifique também como estão sendo gerados os arquivos xxx-ped-can.xml e xxx-can.xml. Talvez o problema esteja na configuração do componente, verifique se todos os parâmetros estão sendo preenchidos conforme o programa exemplo do componente. Tenha certeza que o componente esteja atualizado, faça um rebuild na sua aplicação após atualizar, uma certa vez pra funcionar tive que remover o componente do form e adiciona-lo novamente. Segue o fragmento de código: var msg:string; ACBrNFSe1.NotasFiscais.Clear; ACBrNFSe1.NotasFiscais.LoadFromFile(caminho_do_arquivo_xxx-nfse.xml); try // Codigo de Cancelamento // 1 - Erro de emissão // 2 - Serviço não concluido // 3 - RPS Cancelado na Emissão resultado:=ACBrNFSe1.CancelarNFSe(IntToStr(1)); if resultado then begin with dm.ZQuery do begin msg := 'Cancelamento Homologado'+#13+#13; msg := msg+'NFSe Nº '+nfse_numero+#13; msg := msg+'Código do Cancelamento: '+ACBrNFSe1.WebServices.CancNfse.CodigoCancelamento+#13; msg := msg+'Data Hora: '+FormatDateTime('dd/MM/yyyy hh:mm:ss',ACBrNFSe1.WebServices.CancNfse.DataHora); Messagebox(0,pchar(msg) , 'Resultado Cancelamento NFS-e:', MB_OK or MB_ICONINFORMATION); end; except on e:Exception do begin Application.MessageBox(PChar('Erro'+#13+ 'Erro: '+e.Message),'Erro',MB_ICONSTOP+MB_TASKMODAL); msg:=copy(ACBrNFSe1.WebServices.CancNFSe.RetWS,pos('<Mensagem>',ACBrNFSe1.WebServices.CancNFSe.RetWS)+10,(pos('</Mensagem>',ACBrNFSe1.WebServices.CancNFSe.RetWS)-pos('<Mensagem>',ACBrNFSe1.WebServices.CancNFSe.RetWS)-10)); msg:=msg+chr(13)+copy(ACBrNFSe1.WebServices.CancNFSe.RetWS,pos('<Correcao>',ACBrNFSe1.WebServices.CancNFSe.RetWS)+10,(pos('</Correcao>',ACBrNFSe1.WebServices.CancNFSe.RetWS)-pos('<Correcao>',ACBrNFSe1.WebServices.CancNFSe.RetWS)-10)); Application.MessageBox(pchar(msg),'Mensagem retornada',MB_OK+MB_ICONINFORMATION); end; end;

No ambiente de produção cancela, acabei de testar. Em homologação não funciona, a Betha sabe do problema há tempos e não arruma, o componente está OK.

Boa tarde Italo, eu percebi isso, também verifiquei que a má formação do retorno acontece apenas quando há algum erro no cancelamento, por incrível que pareça quando o cancelamento é homologado o retorno é parseado com sucesso e não há erros. Quanto ao suporte da betha, apenas as prefeituras, clientes diretos tem acesso ao suporte, os desenvolvedores tem no máximo acesso ao fórum da ferramenta, que não resolve quase nada. Não temos muito o que fazer indo por esse caminho, mesmo assim vou tentar reportar isso. Por enquanto vou tratar na minha aplicação quando houver erro de cancelamento. Outra coisa, percebi que o no ambiente de homologação da betha, quando a nfse é processada, no seu xml retornado são omitidas informações relacionadas ao prestador, portando quando fazemos um LoadFromFile no cancelamento, não são carregadas informações importantes como código do município, inscrição municipal do prestador, de forma que o pedido de cancelamento é formado sem essas informações. A solução que achei pra testar em homologação foi após o LoadFromFile, escrever diretamente no objeto as informações que faltam, segue um exemplo: with ACBrNFSe1.NotasFiscais.Add do begin NFSe.Numero := nfseNumero; NFSe.IdentificacaoRps.Numero := rpsNumero; NFSe.IdentificacaoRps.Serie := serie; NFSe.IdentificacaoRps.Tipo := trRPS; NFSe.PrestadorServico.IdentificacaoPrestador.Cnpj := dm.cnpj; NFSe.PrestadorServico.IdentificacaoPrestador.InscricaoMunicipal:= dm.im; NFSe.PrestadorServico.Endereco.CodigoMunicipio := dm.cMunicipio; NFSe.MotivoCancelamento := sMotivo; end; espero que essas informações possam ser úteis a alguém, obrigado.

Olá, acabei de testar, quando tento cancelar uma NFS-e na BETHA, retorna "Erro de validação de script". Pelo que vi, acredito que o problema não esteja no pedido de cancelamento (xxx.ped-can.xml) pois ele chega a ser processado pelo webservice da betha, de forma que ele retorna o arquivo xxx-can.xml. No meu teste, eu tentei cancelar uma nota fora do prazo, no arquivo de retorno (xxx-can.xml), percebi que na tag código, veio um descrição ao invés de um código numérico, talvez o componente não esteja conseguindo parsear corretamente o arquivo de retorno, gerando esse erro de script. Segue o arquivo de retorno em anexo. 708-can.xml

Parece que a betha alterou a forma de cancelamento recentemente e parou de funcionar na Trunk2. Até poucos dias atras estava funcionando perfeitamente mas apenas em ambiente de produção. Irei fazer alguns testes nessa semana, posto aqui os resultados.

Olá Volmir, realmente, mesmo com todos os parâmetros necessários preenchidos (discutidos neste tópico), no ambiente de homologação da betha persiste esse erro, mas em produção funciona direitinho, ta OK. Na betha tem dessas coisas, não é a primeira nem vai ser a ultima, testa em produção se cancelar bola pra frente, foi o que eu fiz. Aproveitando quero agradecer mais uma vez ao Ítalo pelo belíssimo trabalho e pelo seu esforço em nos manter na luz =)

Bom dia Italo, Michel, obrigado pela ajuda, testei aqui e como o Michel mencionou, em ambiente de produção não acontece o erro, vou atualizar os fontes novamente e retorno aqui os resultados.

As propriedades já estão configuradas e o erro persiste, eu coloquei manualmente no arquivo Cidades.ini a cidade que estou testando: [4108502] Nome=General Carneiro UF=PR Provedor=Betha será que o erro está relacionado a isso? O arquivo do pedido de cancelamento parece estar OK. Talvez o erro seja no ambiente de homologação da betha. 61-can.xml 61-ped-can.xml Seguem os arquivos... 61-can.xml 61-ped-can.xml

Olá Italo, obrigado por responder, você se refere a essas propriedades? ACBrNFSe1.Configuracoes.Geral.Emitente.CNPJ := edtEmitCNPJ.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.InscMun := edtEmitIM.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.RazSocial := edtEmitRazao.Text; ACBrNFSe1.Configuracoes.Geral.CodigoMunicipio := StrToIntDef(edtCodCidade.Text, 0); se sim, eu já possuo na minha aplicação.

Olá, não pude testar antes o cancelamento, atualizei os fontes em 03/02/2016, quando tento cancelar retorna: "Código do Município da prestação do serviço Inválido" . Estou testando no ambiente de homologação da Betha. Observando o XML da NFSe vi que em algumas tags <CodigoMunicipio> o valor está igual a zero, por ser ambiente de homologação. Será que pode ser isso? Agradeço qualquer ajuda, Obrigado.

Olá, estou testando o componente ACBrNFSe para trabalhar com o provedor BETHA no Trunk 2, os fontes foram atualizados dia 07/01/2016. Conseguir enviar e consultar lotes, até aí tudo OK. Testando o cancelamento me deparei com um erro que não encontrei nada a respeito no forum. Faço um LoadFromFile do arquivo da NFSe e executo o método: ACBrNFSe1.CancelarNFSe(codigo); nesse ponto acontece o erro: javax.xml.bind.UnmarshallException: unexpected element (uri:"http://www.betha.com.br/e-nota-contribuinte-ws" local:"Pedido") Expected elements are <{}Pedido>) O sistema chega a gerar o xx-ped-can.xml (em anexo) Comparando o xx-ped-can.xml com um outro arquivo que foi processado, notei que ele não tem assinatura digital, talvez a falha esteja ocorrendo nesse ponto. Agradeço qualquer ajuda, Obrigado. 49-ped-can.xml

Olá Italo, primeiramente parabéns pelo seu trabalho. Me desculpe por insistir, mas preciso perguntar se já houve algum avanço com relação a assinatura do lote+rps (ambos), para que os usuários da betha possam migrar a NFSe para o Trunk2? Tenho acompanhado o change-log do componente mas não vi nada nesse sentido. Agradeço qualquer informação. Att, Marco

Olá Italo, atualizei o componente para a versão que estava no svn em 10/12/2015, tentei enviar uma NFSe para o provedor Betha e percebi que continua assinando apenas o rps. Testei com a propriedade SSLLib do componente ACBrNFSe setada para: libCapicomDelphiSoap e libCapicom, o resultado nas duas configs foi o mesmo. Agradeço qualquer ajuda, att, Marco

Novas cidades atendidas pela Betha: [4102901] Nome=Bituruna UF=PR Provedor=Betha [4108502] Nome=General Carneiro UF=PR Provedor=Betha

Olá, terminei recentemente a homologação do boleto do Sicred usando o layout c240 na remessa, já com os arquivos mais recentes (10/12/2015) do ACBrBoleto da trunk2, gostaria de compartilhar caso tenham interesse de incorporar no projeto. ACBrBancoSicredi.pas

Oi Juliana, estou portando o nosso sistema para o trunk2, agora cheguei na parte do ACBrBoleto. Tenho alguns bancos funcionando normalmente na trunk1 e estou tendo que fazer pequenas modificações para compatibilizar a geração dos arquivos e gostaria de compartilhar e tentar colaborar caso você analise úteis as modificações. O primeiro item que ajustei foi a remessa c240 do banco Sicoob, fiz pequenos ajustes para enviar corretamente os valores e códigos referentes a mora (juros) e multa conforme o manual do banco e também com base na homologação que realizei. Segue arquivo em anexo, Obrigado. ACBrBancoBancoob.pas

OK Italo, valeu pela resposta, vamos aguardar então, Obrigado.

Olá Italo, gostaria de agradecer pelo seu esforço imenso em portar o componente ACBrNFSe para o Trunk2, vejo que diariamente estão subindo alterações relacionadas a NFSe. Apesar de estarem cogitando prorrogar os prazos para a implementação da nota técnica 2015.003 ainda temos a NT 2015.002 e outros fatores nos levando a migrar do Trunk1 para o Trunk2. Pelo que tenho acompanhado já existe um .ini relacionado a Betha. Observando o XML do lote gerado com a versão Trunk1 do componente (no caso da Betha), percebi que o RPS e o Lote são assinados. Apesar do INI da Betha estar setado dessa forma, [Assinar] RPS=1 Lote=1 apenas o RPS está sendo assinado, e o lote está sendo processado com erros pela Betha. Erro retornado: Assinatura Inválida. Estou usando o método: ACBrNFSe1.Enviar(); Poderia me orientar se estou fazendo algo errado?

Bom dia, estou com um problema para cancelar uma NFS-e. O provedor é a Betha. Atualizei o componente dia 10/06/2014. Estou usando o seguinte método: Result := ACBrNFSe1.WebServices.CancelaNFSe('1', '215', '59214522000139', '5178', '4108502'); Quando executo o método retorna a mensagem: " " is not a valid interger value. O erro ocorre na linha 3741 do arquivo ACBrNFSeWebServices na ultima linha desse trecho de código: // Alterado por Rosemir Zeferino em 24/05/2013 if (FProvedor = proIssDsf )then Result := NFSeRetorno.LerXml_provedorIssDsf //falta homologar else if (FProvedor = proEquiplano) then Result := NFSeRetorno.LerXML_provedorEquiplano else Result := NFSeRetorno.LerXml; <<<<<<< ====== aqui a função é a TNFSeConsultarNfseRPS. Pelo que vi o erro está relacionado a segunda etapa do cancelamento, quando o rps é consultado, pois se tento cancelar novamente o WS retorna que a NFS-e já foi cancelada.

Olá Jéter, parabéns a você e a equipe ACBr pelo componente ACBrConvenio115. Estou iniciando a implementação da NF mod 21 e usei o sistema exemplo para geração dos arquivos. Notei que ele gerou três dos quatro arquivos descritos no convênio 115/03, são eles o M - Mestre, I - Item e D - Destinatário. Notei que o arquivo tipo C - "Controle e identificação" não foi gerado. Em que momento esse arquivo é gerado? A sua geração é necessária? att, Marco.

Olá Ederson, obrigado por responder, com o RecuperaXML mais recente do SVN acontece exatamente como eu descrevi, recupera muito bem o xml do layout 2, mas quando tento recuperar qualquer xml do layout 1.1 acontece o travamento. No compilado que o André mandou recupera normalmente os 2 layouts, e notei que ele é um pouco diferente do que tem no SVN, só tem 1 botão "Obter XML", e funciona redondinho. Para ser mais específico, o travamento ocorre quando a função GerarXML é executada, tentei atualizar completamente o ACBr para a versão mais recente, para atualizar também as dependências do arquivo "ACBrHTMLtoXML" mas o resultado foi o mesmo. Agradeço pela atenção, obrigado. Marco