Diogo Loff

Ola!
No componente ACBrNFSeX, quando importado um XML de um RPS do provedor Betha, esta ocorrendo erro no campo de DataVencimento. O tipo esta incorreto.
 
Atualmente no fonte esta:
DataVencimento := ObterConteudo(ANodes[i].Childrens.FindAnyNs('DataVencimento'), tcDat);
 
O correto é:
DataVencimento := ObterConteudo(ANodes[i].Childrens.FindAnyNs('DataVencimento'), tcDatVcto);
 
Fonte Betha.LerXml.pas
Linha 98.
 
Segue anexo fonte alterado.
 
Betha.LerXml.pas

Ao meu ver é um erro, pois, antes fazia agora não mais.
Também todas as outras funções da NFe como gerar nfe e eventos, estão trazendo path completo, pelo que vi só a opção de donwload que não o faz mais.
 
Vou anexar aqui os fontes, ao meu ver minha sugestão resolve, porem fica fora do padrão dos outros objetos como NF e Eventos. Também não entendi porque o objeto abaixo é destruido e depois recriado novamente sem o path. Então creio que vocês deveriam avaliar para se manter o padrão conforme das demais funções.
 
Segue os fontes.
 
Obrigado!
ACBrNFeWebServices.pas

Ola!
Estou testando as novas possibilidades de consulta CNPJ pelas APIs que foram disponibilizadas no ACBrConsultaCNPJ e senti falta de exceção quando vem um erro do servidor. Como por exemplo o ReceitaWS com mais de 3 consultas por minuto já da erro, porem no componente não esta acontecendo nada.
 
Fica sugestão a alteração que fiz.
Implementei na ReceitaWS e na BrasilAPI.
Em ambas adicionei um else se não deu certo, para lançar uma exceção do campo "message".
if (Trim(LJsonObject.Values['message'].AsString) <> '') then
    raise EACBrConsultaCNPJWSException.Create(LJsonObject.Values['message'].AsString);
 
Obrigado.
ACBrConsultaCNPJ.WS.BrasilAPI.pas ACBrConsultaCNPJ.WS.ReceitaWS.pas

Segue:
IPM.LerXml.pas IPM.GravarXml.pas

Cidade de Campo Largo, precisa de uma atualização no arquivo ACBrNFSeXServicos.ini. No original não tem ambiente de homologação, mas o mesmo esta disponivel, e no municipio não pode gerar o grupo rps, e esta faltando o "Params=NaoGerarGrupoRps:"
Segue o correto:
Nome=Campo Largo
UF=PR
Provedor=IPM
Versao=1.01
Params=NaoGerarGrupoRps:
ProRecepcionar=https://ws-campolargo.atende.net:7443/atende.php?pg=rest&service=WNERestServiceNFSe
HomRecepcionar=https://treinamento.atende.net/?pg=rest&service=WNERestServiceNFSe&cidade=treina_campolargo
 
Também aqui ocorre o problema da competencia que coloquei em outro topico. Já o problema do identificador não ocorre, pois não gera conforme indicado acima.
 

Boa tarde!
Informo que consegui. O pessoal da Daruma acabou me respondendo por e-mail agora pouco, já fazia dias que estava tentando contato.
 
Até o Juliomar escreveu que não seria possível, mas o meu ECF é credenciado como DESENVOLVEDOR então eu posso sim fazer isto.
 
Mas voltando ao problema, se alguém passar por isto segue:
Liberar no Firewall a porta 1070, também não pode ter nenhum tipo de impedimento de conexão com o IP da Daruma, 200.220.138.84.
Também precisa adicionar o aplicativo TOOL FS800i nas exceções de antivirus.
Feito isto vai funcionar. Mas somente funciona se o ECF cadastrado lá na base da Daruma estiver como DESENVOLVEDOR.
 
 
Também aproveitando o POST, para quem estiver desenvolvendo para esta impressora, eu fiz praticamente todos os testes já e ela esta funcionando perfeitamente.
 
Somente duas questões que o ACBR não esta muito legal, é para as mensagens de papel, para este modelo quando da problema de papel, a impressora acaba acusando erro de "Não esta em linha", tive que tratar estas mensagens. Já a versão anterior da Daruma por exemplo uma Mach 2 apresenta as mensagens corretas, sem necessidade de tratamento.
E também no momento de gerar a redução Z, se possuir por exemplo pre-venda pendente, e não colocar um sleep entre um comando e outro, da problema, parece que a impressora esta executando os comandos mais lento, porem meio que retorna que já deu certo e vai para o proximo (não sei se me fiz entender). Acontece o mesmo na virada de mês que precisa gerar o MFD logo na redução Z, para resolver estas situações tive que colocar uns delays no código entre um procedimento e outro. Já na Mach 2 não acontece isto.
 
No mais tudo certo.