André Melim

Problema do "X999 - Erro de Conexão: Start tag expected, '<' not found" foi resolvido corrigindo o CNPJ da prefeitura de Paranatinga-MT que estava sendo informado para o componente 'ACBrNFSeX', os demais erros que vieram na sequencia e que esses sim estavam nomeando certinho as tags que deveriam ser informadas/omitidas no xml foram corrigidos atraves das configuracoes feitas no .ini do componente e que encontra-se descrito no print em anexo.

@Italo Giurizzato Junior, consegui dois xml de exemplo fornecidos pela prefeitura de Paranatinga-MT. Creio que deva ajudar voces a saberem o que precisa ser configurado ai no componente TACBrNFSeX para fazer com que os processos de emissão, cancelamento e afins possam funcionar corretamente. Segue em anexo. CancelarNfseEnvio.txt GerarNfseEnvio.txt @Juliomar Marchetti e @Italo Giurizzato Junior, , consegui dois xml de exemplo fornecidos pela prefeitura de Paranatinga-MT. Creio que deva ajudar voces a saberem o que precisa ser configurado ai no componente TACBrNFSeX para fazer com que os processos de emissão, cancelamento e afins possam funcionar corretamente. Segue em anexo.

@Italo Giurizzato Junior, estou com esse erro ai agora... Ver imagem em anexo.

@Italo Giurizzato Junior, deu certo agora a questao de quando alterar o codigo do municipio o componente do ACBr pegar o provedor 'Agili' que se encontra la no arquivo 'ACBrNFSeXServicos.ini'. Eu consegui descobrir aqui como regerar o arquivo .res atraves do bat de compilacao do componente. Agora a questao sao os erros de transmissao encontrados, creio que ira precisar passar mais informacoes la no arquivo .ini (na linha do 'Params=' ou quem sabe ate as urls que o componente devera usar). Como saber quais essas informacoes que eu devo informar la no arquivo .ini? Voce sabe me informar?

Bom dia @Italo Giurizzato Junior Muito obrigado pela sua resposta meu amigo. Atualizamos o componente aqui no final da semana passada conforme as orientacoes. Entao, a principio a questao 'A propriedade CodigoMunicipio tem que ser a ultima a receber o seu valor' o sistema ja esta fazendo, isso ta OK. Sobre a questao da mudanca de provedor dessa cidade o que me informaram foi que mudou recentemente, entao a principio vai ser o 'Agili' mesmo que o componente vai ter que usar para esse codigo de municipio. Sobre as alterações que voce sugeriu ai para o arquivo .ini eu fui la na pasta do componente do ACBr onde se localiza o arquivo 'ACBrNFSeXServicos.ini' e fiz as alterações que voce sugeriu ... [5106307] ; Atualizado em 24/05/2022 Nome=Paranatinga UF=MT Provedor=Agili Versao=1.01 Params=NomeTagAtividadeEconomica:ItemLei116AtividadeEconomica|NaoGerarTag:ItemLei116,CodigoCnae Recompilei o sistema e fiz um teste só pra ver se apos a atribuicao do codigo do municipio o componente iria entender que deve usar o 'Agili' porem ainda continua mudando para o 'Elotech'. Pelo que entendi da sua explicacao seria apenas recompilar o sistema que o componente ja iria entender essas alteracoes (sem necessidade de se colocar o arquivo .ini na pasta do executavel), mas infelizmente nao funcionou nem com o parametro 'Versao' sendo informado com '1.00' ou '1.01'. Em relacao ao parametro 'Params' eu nao sei ainda te informar quais seriam esses parametros que teriam que ser informados (nao tenho esse informacao ainda), porem independente desses parametros (Params) creio que com essas alterações feitas ate o momento no arquivo .ini o componente do ACBr (TACBrNFSeX) ja deveria corrigir o problema de atribuir o provedor 'Elotech' ao inves do 'Agili' apos a atribuicao do codigo do municipio, nao é isso?

Certo, vamos pela solução de colocar na pasta dos Schemas do sistema o arquivo .ini onde vai ter a facilidade do cliente mudar o provedor para a cidade de Paranatinga por esse arquivo. O problema que esta tendo é que mesmo setando o nome do arquivo ini em 'NFSeX.Configuracoes.arquivos.IniServicos' mesmo assim ao passar na linha de comando onde atribui o codigo do municipio nao esta acatando a alteracao que eu fiz la dentro desse arquivo .ini. Esse esta sendo o problema. Tem que fazer algo a mais de pois de setar a propriedade 'IniServicos'?

Bom dia, utilizamos o componente TACBrNFSeX para emissao das notas fiscais de servicos no nosso sistema. Ocorre que um cliente nosso que reside em Paranatinga - MT deseja utilizar o provedor 'Agilil' mas não consegue pois no nosso sistema quando a gente atribui o codigo do municipio ao componente o provedor muda de 'Agili' (setado corretamente no sistema via parametrizacao) para 'Elotech' causando o problema. Temos no nosso sistema... if FileExists( NFSeX.Configuracoes.Arquivos.PathSchemas + 'ACBrNFSeXServicos.ini' ) then NFSeX.Configuracoes.arquivos.IniServicos := NFSeX.Configuracoes.Arquivos.PathSchemas + 'ACBrNFSeXServicos.ini'; <-- tem esse codigo aqui que verifica se existe esse arquivo .ini e entao o carrega NFSeX.Configuracoes.Geral.CodigoMunicipio := StrToIntDef( sAux, 0 ); <-- lugar onde o nosso sistema atriubui o codigo do municipio par ao componente (nesse momento troca de Agili para Elotech) CONSIDERACOES: Esse arquivo .ini eu vi que nao existia na pasta dos Schemas do nosso sistema entao eu copiei ele da pasta dos componentes do ACBr para a pasta dos Schemas do nosso sistema e mudei ref. ao codigo de municipio '5106307' (Paranatinga-MT), o provedor de Elotech para Agili dentro desse arquivo na esperanca que pudesse resolver mas nao resolveu, nao sei se seria o caso de depois de setar o nome do arquivo fazer algo como dar um 'Load' ou algo parecido. Segue em anexo o arquivo .ini alterado para o municipio de Paranatinga-MT. Alguém ai pode me ajudar por favor? Grato pela colaboração, André. ACBrNFSeXServicos.ini

Aparentemente o problema era o cabo mesmo. Trocamos por um cabo de melhor qualidade (marca COMTAC) e funcionou!

Os clientes que utilizam o componente TACBrBAL para capturar o peso das balanças que estão conectadas ao PC via USB nao conseguem utilizar a captura pois após capturar o peso pela primeira vez ao tentar acessar a balança novamente para pegar o peso o componente retorna mensagem de erro de comunicação com a balança. Segundo relatos o problema não ocorre quando a conexão da balança se da via porta COM direto sem passar por adaptador USB. Da a impressão de que após a primeira captura de peso a comunicação com a balança fica aberta e com isso a partir da segunda tentativa a comunicação falha. O grande problema desse tipo de coisa é que pelo que me informaram os PCs novos não estão mais vindo com essas conexões do portas COM por padrão, parece que o USB ta dominando agora. Alguma idéia de como resolver isso? Eu tentei escrever uma rotina la que fecha a porta COM (via API do Windows) e coloquei a chamada a essa rotina depois da captura de peso mas também não consegui resolver o problema (não sei se é esse realmente o problema).

Achei a propriedade aqui ... ACBrBoleto.Banco.LayoutVersaoLote := 944; Aparentemente resolveu, grato pela atenção.

Parece que tem essa propriedade no componente que pelo que entendi se eu setar ela para o valor correspondente '944' aparentemente vai mudar o conteúdo descritivo a ser enviado no arquivo. Como que eu faço pra mudar o valor dessa propriedade pois parece que ela nao está acessível diretamente pelo próprio componente do ACBr. No caso o componente TACBrBoleto que eu tenho no sistema se chama 'Boleto' mas seu eu procurar por 'Boleto.LayOutVersaoLote' nao existe essa propriedade diretamente nele, seria alguma sub-propriedade dentro desse objeto? Segue arquivo de imagem do debug em anexo.

Olá, eu tenho um cliente que utiliza a geração de arquivo de remessa para o banco Unicred. Ele esta tendo problemas na validação desse arquivo devido a um conteúdo descritivo que vai dentro do arquivo de remessa. Segundo a validação do banco Unicred o valor do campo está com o conteudo 'UNICRED DO BRAS' e o correto seria 'UNICRED'. Parece que tem uma propriedade no componente 'TACBrBoleto' que se mudar o valor dela parece corrigir esse problema mas eu nao sei como fazer isso. Alguém pode me ajudar? Segue em anexo o arquivo de remessa gerado pelo nosso sistema e as imagens que o cliente me enviou ref. a homologação do banco. RemessaBanco_2-16072025140759.TXT

Resumindo... ao emitir a nfs-e, caso a nota ja exista la no provedor (ja tenha sido transmitida anteriormente) o componente AcbrNFSEX teria que retornar alguma informação (Numero de Protocolo, Numero da Nota, etc) através da qual eu possa utiliza-la para consultar essa nota de forma a preencher o componente com as informações dessa nota para que eu possa salvar ela no meu banco de dados.

No arquivo txt em anexo tem o trecho de código onde quando da erro na transmissão da nfs-e o sistema verifica no trecho da mensagem de erro e se for ref. a 'nota ja consta no provedor' então o sistema usa o comando 'ConsultarLoteRps' para consultar a nota la no provedor pelo 'NumeroLote' e 'Protocolo' que retornou no componente para que os dados da nota sejam carregados para o componente e com isso se consiga gravar os dados da nota na base de dados do sistema, foi o que pude entender desse código fonte. Basicamente seria essa a ideia, ou seja, se a nota de serviço que estou tentando enviar ja existe la no provedor eu preciso trazer as informações dessa nota de serviço pra gravar na base de dados para contornar a situação onde por exemplo caiu a energia entre o tempo de enviar a nota e gravar nas tabelas do sistema (coisa que o sistema ja faz normalmente). Note que como houve a queda de energia apos o envio eu nao tenho nenhuma informação pra enviar para o comando de consulta, teria que ser algo que o componente devolve no resultado da tentativa de transmissao. DocumentoFiscalServicosENVIAR.txt

Sim, mas no método 'AcbrNFSEX.ConsultarLoteRps' é exigido passar por parametro o 'Protocolo' e o 'Lote' e ai de onde eu vou pegar essa informação? Lembra que se trata de um caso onde não deu tempo de gravar a informação na base de dados pois caiu a energia do computador ou ocorreu um travamento do computador, por exemplo.

Olá pessoal, Temos no nosso sistema a emissão de notas fiscais de serviços NFS-e para alguns provedores e esta funcionando normalmente. O problema é que quando usávamos o componente antigo 'TACBrNFSe' a gente tinha um tratamento la na emissão da NFS-e que fazia com que caso a nota fiscal já estivesse constando no provedor, o sistema já puxasse os dados da nota automaticamente sem dar aqueles tipos de mensagens de erro dizendo que a nota ja foi transmitida (explicando... logicamente ao emitir a nota fiscal, o próximo passo é gravar a informação na base de dados do nosso sistema de forma que o sistema não tente transmitir 2 ou mais vezes a mesma nota, mas imagina que por algum motivo como uma queda de energia faça com que a nota seja emitida/transmitida porém antes de gravar as informações na base de dados tenha ocorrido a queda de energia). Aí vai gerar essa situação onde a nota consta no provedor mas não consta na nossa base de dados por isso existe esse tratamento para quando dá esse tipo de erro o sistema, após carregar os dados da nota fiscal no componente vá para uma procedure que com base nesses dados, grave a nota na nossa base de dados. No arquivo em anexo tem o exemplo. Porém agora que estamos utilizando o componente 'TACBrNFSeX' não estou conseguindo utilizar o mesmo raciocínio para implementar isso pois no componente novo não me retorna o 'NumeroLote' e nem o 'Protocolo'. Alguma idéia de como implementar isso no componente 'TACBrNFSeX'? No exemplo do arquivo em anexo (rotina antiga) estamos implementando isso para o provedor 'proAssessorPublico' porém no caso aqui o cliente pediu para fazer no provedor 'proRLZ' mas creio que a lógica deve ser a mesma. DocumentoFiscalServicosENVIAR.txt

Só te pedir um favor, @Juliomar Marchetti pra voce me avisar ai se a minha alteração foi aprovada a fim de que a gente possa ficar na expectativa de quando atualizar da proxima vez os componentes do ACBr aqui na empresa para que a alteração já possa vir no download dessa atualização, blz? Grato pela atenção.

Segue em anexo os fontes atualizados do ACBr onde após contato com o suporte da Elgin eu consegui implementar a questão do cancelamento do Pix. - ACBrTEFAPI.pas: Acrescentada a propriedade 'bCancelarColeta'. - ACBrTEFAPIElgin.pas: Alterado o procedimento 'TACBrTEFAPIClassElgin.Coletar' para verificar se a propriedade 'bCancelarColeta' estiver 'True' entao executar os comandos para cancelar a coleta. Fontes Atualizados.rar

Novidades com relacao ao cancelamento do PIx da Elgin (componente TACBrTEFAPI).... Entrei em contato com o suporte da Elgin e eles me informaram que eu necessariamente tenho que colocar um comando la dentro do evento 'Coletar' (no caso da Elgin, mais especificamente dentro do evento 'TACBrTEFAPIClassElgin.Coletar') do componente do ACBr. Eu testei aqui e aparentemente funcionou para cancelar a tela do Pix aberta esperando pagamento. O problema é que eu testei isso utilizando uma tecnica que eu nao acho que seja a mais adequada para resolver esse tipo de situacao. No botao 'Cancelar' por exemplo eu crio um arquivo txt no hd e la dentro do evento 'Coletar' eu testo se existe esse arquivo para eventualmente executar os comandos de cancelamento que vai fazer cancelar o pix atual. Eu gostaria de saber se voces conseguem me ajudar no sentido de que la dentro da nossa automacao comercial eu consiga colocar alguma propriedade por exemplo que eu seto ela e que isso seja visivel la dentro do componente para ele entender que o usuario clicou no botao de cancelar, para ficar mais correto, mais profissional. A logica da coisa é que toda as transacoes TEF e PIX sao gerenciadas a partir de uma variavel que eu crio do tipo 'TACBrTEFAPI'. Essa variavel se chama 'API' e dentro dela é que eu teria que setar alguma propriedade por exemplo pra quando passar la no 'Coletar', uma vez que eu seto essa variavel o procedimento consiga 'enxergar' que eu quero tomar uma acao de cancelamento. Alguma ideia?

Será que ninguém mais ta usando esse TEF Elgin pelo componente do ACBr, não esta passando pelos mesmos problemas que eu to passando e pode ajudar?

Onde la no componente 'TACBrTEFAPI' que eu posso mexer para alterar o timeout da operacao do Pix? Ja que eu nao consigo resolver esse problema do componente usando o TEF da Elgin onde pelo que percebi a nova versao de software do TEF da Elgin muda algumas coisas (gera umas tags diferentes) o que faz com que o componente do ACBr por exemplo nao funcione na reimpressao. A minha ideia é baixar la de 3 minutos de timeout para uns 30 segundos para o cliente nao ter que ficar esperando um tempao para conseguir mudar a forma de pagamento quando ta o QRCode do Pix na tela. Alguem pode me ajudar?

Olá. Realmente a função do componente é devolver o espelho para que a aplicação imprima. Mas o que esta acontecendo é que no evento 'QuandoFinalizarOperacao' logo no inicio a propriedade 'RespostaTEF.TextoEspecialOperador' já esta vindo como False o que faz com que o processamento nao entre no 'Else' onde esta o comando para impressão do comprovante TEF. E o que é curioso mesmo se eu desviar o processamento para entrar no 'Else' quando entra na impressão do comprovante 'TclasseTEF.ImprimirTodosComprovantes' la não imprime nada (nao encontra informação para se imprimir, a propriedade 'FTEFAPI.RespostasTEF.Count' esta zerada ). Ver imagens em anexo.

Ta, vamos la... Questão da reimpressão eu estava debugando la onde ta passando e ta disparando o evento 'QuandoFinalizarOperacao', como tem que ser. O problema que eu percebi a principio é que logo ao entrar no evento, a propriedade 'RespostaTEF.Sucesso' ja vem 'False', ou seja, nao passa no 'Else' onde vai imprimir o comprovante (parece que o componente devolveu algo como se não tivesse tido sucesso em encontrar o espelho do comprovante). Ai, na sequencia, para forçar o sistema executar os comandos que estão no 'Else' (para imprimir o comprovante) eu substitui a linha de teste 'if not RespostaTEF.Sucesso then' por 'if 1=0 then'. Então quando executou o 'FTEF.ImprimirTodosComprovantes' eu vi que la dentro do procedimento a propriedade 'FTEFAPI.RespostasTEF.Count' está 'Zero' (dessa forma não imprime nada). Ou seja, tem no sistema a parte da reimpressão implementada porém pelo que entendi o componente não devolve a imagem a ser impressa. OBS: No que se refere a propriedade 'RespostaTEF.TextoEspecialOperador' ela ta vindo como 'REIMPRESSAO'.

Sobre a reimpressão, é simples, não reimprime, não funciona. É isso.

Olá amigos, tudo bom? @Juliomar Marchetti, @Italo Giurizzato Junior alguma novidade sobre a correção desses bugs do TEF Elgin, no que se refere ao cancelamento (este pos) e no que se refere a reimpressão (outro post) ?