CONCEPT AUTOMACAO

Testei e deu certo.

Ao realizar uma consulta de NFSe por Número (ConsultarNFSeGenerico) no provedor ISSDSF – Uberlandia, o componente ao tentar ler o retorno da um erro na função ”TACBrNFSeXWebservice.ExtrairRetorno” que tem a chamada do Método “Document.LoadFromXml(xRetorno)”. Esse método “LoadFromXml”, é chamada em todos as leituras de retornos porem esse erro só acontece quando no retorno da consulta “ConsultarNFSeGenerico” contem notas, caso não tenha notas no retorno não da o erro. Ao consulta “NFSe por RPS” é passado pelo mesmo método e não retorna erro. Os arquivo com os dados já foram enviado por e-mail anteriormente. Caso necessário posso enviar novamente.

Boa tarde a todos Consegui falar no 34 3239-2746 e me foi passada a informação de que a troca de provedor foi adiada para 01/04/2024. @Italo Giurizzato Junior

Boa tarde @FelipeMitt O e-mail é [email protected], porém, não tive resposta do email que enviei. Alguém ai sabe se vai haver a troca mesmo no dia 01/03/2024?

Boa tarde, pessoal. Consegui o telefone 34 3239-2746 sobre a NFS-e de Uberlandia. O rapaz que me atendeu nao tem muita informação, mas ele confirmou (sem muita certeza) que haverá a troca de provedor para PRODAUB que, até onde eles têm informação, será no dia 01/03/24 e será tombo (vão derrubar o atual e subir o novo. Não vão trabalhar com 2 provedores ao mesmo tempo). Ele me passou o email de uma moça que tem contato direto com o setor do desenvolvimento para confirmar essas informações. Eu enviei um email para ela solicitando informações e se precisarem, posso encaminhar para vcs o email dela.

@antonio.carlos @Daniel InfoCotidiano Parece que meu problema era em instanciar e chamar os métodos do componente consecutivamente ele sobrecarregava, ainda mais por estar em Thread e no mesmo momento pode ter várias comunicações simultâneas, ao coloca o sleep no Thread atual, ele parou de me apresentar esse problema. private void imprimirPrinter(Impressora imp,String conteudo,ACBrPosPrinter posPrinter) throws Exception { posPrinter.imprimir(conteudo); try { Thread.currentThread().sleep(500); } catch (InterruptedException ex) { log.error("Erro no Sleep: "+ex.getMessage(),ex); } } private void desativarPrinter(Impressora imp,ACBrPosPrinter posPrinter) { log.info(String.format("Desativando Printer: '%s'",imp.getNome())); try { posPrinter.desativar(); } catch (Exception ex) { log.error("Erro ao desativar: " + ex.getMessage(), ex); } try { Thread.currentThread().sleep(500); } catch (InterruptedException ex) { log.error("Erro no Sleep: "+ex.getMessage(),ex); } } Minhas consultas está demorando 1s a mais porem parou o erro com a comunicação.

Eu fiz uma alteração para teste que parece ter resolvido. Ao colocar um Sleep após a impressão e desativação da impressora, ele reduziou a quantidade de vezes que dava erro, fiz 700 solicitações e só me retornou 2 erros.

No projeto em Java utilizo o posPrinter MT - Cdecl. Meu projeto é uma API feita utilizando o SpringBoot. Nela há um método de Post que imprime o Consumo. Quando há somente um Thread imprimindo não da erro, o problema começa quando há vários thread imprimindo ao mesmo tempo. O problema parece estar relacionada a quantidade de thread, pois ao aumentar o numero de thread o problema se torna mais frequente. Em um teste que eu fiz utilizando o Postman, durante 1 min e 4 usuario deu 123 solitacoes e 5 erros. Fiz o teste de ping com a impressora durante 30s e não teve perda de pacote. Ao ativar o LogNivel e LogPath as consultas ficaram mais lentas. Os arquivos e logs em anexo são referente ao ultimo teste feito, com 5 usuário em 1 minuto. Tanto da minha applicacao quanto do componente da ACBR.codigo.txt ACBrLibPosPrinter-20230818.log logimp.log ComandaServer.log

Prezados, hoje tive retorno de um dos chamados abertos pelo portal de MG dizendo apenas que o problema havia sido resolvido e finalmente consegui registrar o CTe em homologação. Não sei exatamente oq eles corrigiram. Demorou, mas aconteceu. Obrigada pelo auxilio.

Olá. Claudemir! Obrigada pelo auxilio! Enviei um e-mail para a contabilidade do cliente verificar o cadastro junto à SEFIN, mas não entendi a segunda parte do seu texto. Procurei alguma pagina de credenciamento de DFes de MG, mas nao encontrei.

Olá, caros colegas Estamos desenvolvendo a emissão de CTe e sempre que tentamos registrar um CTe para um determinado contribuinte de MG, que já emite em produção normalmente, temos como retorno a rejeição 585 - IE Emitente nao autorizada a emitir CT-e para o modal informado. Abrimos chamado pelo portal de Minas e tivemos a resposta de que o cadastro da empresa está correto tanto para homologação quanto produção, mas o erro persiste. Insistimos com eles para nos auxiliarem e eles apenas respondem que o cadastro está correto. Estamos há um mês tentando validar um CTe e não conseguimos. E só temos essa empresa habilitada para emitir CTe para podermos utilizar. Já lançamos uma cópia exata de um CTe emitido em produção para testar (vai que o erro retornado era errado, né)... Estamos aceitando qualquer sugestão! Tenso, viu... 1-env-lot-soap (2).xml 311000131713900-pro-rec-soap.xml

sim, pois neste caso, o emitente é RPA. Temos um parametro no sistema se gera ou nao DIFAL para Simples Nacional, pois nao é obrigatorio. Imagino eu que nenhum cliente SN está calculando atualmente.

Boa tarde a todos. Diante deste mesmo erro (em produção), recebemos a informação de uma contadora de cliente que venda a consumidor final não presencial de outro estado não poderia ser CST 60 mesmo que o produto seja sujeito à ST no estado de origem. Segundo ela, sempre deverá ser 00 com CFOP 6108. Passamos esta informação para o contador do outro cliente que estava com problemas para registrar a NFe. Após um tempo ele nos retornou dizendo que instruiu o cliente dele a alterar a tributaçao para 00 (calculando DIFAL normal). O que é estranho é que apenas um cliente entrou em contato conosco com esta rejeição. Consultamos vendas na mesma situação de outros clientes do mesmo ramo de atividade e todos utilizam a CST 000. Entao, por enquanto, nao fizemos nenhuma alteração em sistema. Acreditamos que realmente é uma trava nova sim, mas o cliente estava emitindo nota com tributação errada.

Boa tarde a todos. Diante deste mesmo erro, recebemos a informação de uma contadora de cliente que venda a consumidor final não presencial de outro estado não poderia ser CST 60 mesmo que o produto seja sujeito à ST no estado de origem. Segundo ela, sempre deverá ser 00 com CFOP 6108. Passamos esta informação para o contador do outro cliente que estava com problemas para registrar a NFe. Após um tempo ele nos retornou dizendo que instruiu o cliente dele a alterar a tributaçao para 00 (calculando DIFAL normal). O que é estranho é que apenas um cliente entrou em contato conosco com esta rejeição. Consultamos vendas na mesma situação de outros clientes do mesmo ramo de atividade e todos utilizam a CST 000. Entao, por enquanto, nao fizemos nenhuma alteração em sistema. Acreditamos que realmente é uma trava nova sim, mas o cliente estava emitindo nota com tributação errada.

Putz, verdade!!! Eu nem lembrei da validação local de schemas!! Vou atz aqui pra ver e volto pra falar se deu certo.