Diego Foliene

Bom dia! Primeiro de tudo, muito obrigado pela contribuição. Toda colaboração sempre será mais do que bem vinda. Sobre está questão, buscando no histórico, não encontrei um motivo específico, mas conforme você mesmo já destacou. Se conferirmos no Layout CNAB240 da Febraban, o Segmento E é utilizado somente no retorno do serviço de Extrato de Conciliação Bancária e não nos serviços de pagamentos que é a proposta inicial do componente. Criada a #TK-4459 para análise da contribuição e possível inclusão no SVN.

Bom dia! A impressão ocorreu sem erros. Quando aos erros do print. Você os recebe ao preencher a classe de alto nível para emitir NF-e? Qual é a mensagem de erro completa? (Não deu para ver no print).

Bom dia! Por favor, escolha as Dlls deste LINK, escolhendo de acordo com a arquitetura que você compila a sua aplicação e não a do SO. Coloque elas na mesma pasta do seu EXE e faça um novo teste.

Quando você emite a NFS-e pelo portal da prefeitura, está emitindo direto a NFS-e. Desse modo, não existe o RPS no processo e por isso, não tem informação do mesmo para ser impressa. Já quando você faz a emissão de uma NFS-e através de aplicação própria, ou seja, via web service, você não envia o XML da NFS-e. Você envia um Recibo Provisório de Serviço (RPS) para o provedor, que posteriormente o converte para uma NFS-e. Dito isso, as informações do RPS são uma parte importante e necessária quando o envio é feito via web service. Elas servem para identificação, rastreabilidade e podem ser utilizadas por outros processos (a NFSE_ConsultarLoteRps é um exemplo). Por isso, não será possível remover a informação do impresso.

Boa tarde! Criada #TK-4456 para análise da solicitação e parecer da equipe.

Boa tarde! Foi enviado ao SVN na Rev-30661 alteração visando corrigir este problema. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde! Por favor, pode fornecer mais informações? Disponibilize um print do erro que recebe ao configurar o telefone e receber o ApplicationException. Disponibilize também o XML que está usando para testes. Se julgar que o mesmo tenha informações sensíveis e não possa ser disponibilizado diretamente aqui, envie para [email protected] com o link do tópico do fórum no corpo do texto para posterior identificação.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-4455

Boa tarde. O recomendado para Cupom Fiscal é que se use o PosPrinter, mas existe a opção de usar o impresso do Fortes Report. No entanto, isso acarreta na dependência de uma interface gráfica. Estamos trabalhando no FPDF para eliminar esta dependência. Fique de olho na Página de Notícias do Fórum e em nossa Comunidade no Discord para novidades a respeito. Você também pode conferir os exemplos disponíveis no SVN AQUI. O tópico é muito antigo e por isso vou fechar. Para novas dúvidas, por favor, criar novos tópicos.

Bom dia! No seu arquivo de log temos: Fazendo um teste em meu ACBrMonitor, somente do comando SetModeloDF, a entrada do mesmo no log ficou da seguinte maneira. Você está enviando dois comandos de uma vez só. Por favor, envie apenas um comando por vez no Ent.txt e faça um novo teste.

Bom dia! Na Consulta de Recibo, também é considerado a informação da versão do XML carregado.

Bom dia! Recebemos relatos de que a Sefaz de Pernambuco estaria apresentando problemas. Ao consultar em Portal da NFe > Disponibilidade, é possível observar que todos os serviços indicam estar indisponíveis: Consultando no painel Situação-SVC também é possível observar que o problema já foi observado e a contingência foi ativada às 08h05 com previsão de encerramento as 10h00 do dia 19/09/2023. Para usar o ACBr em contingência durante este período siga as orientações do tópico a seguir:

Situação sendo analisada na #TK-4445.

Boa tarde pessoal! Foi divulgada uma notícia informando que, conforme cronograma, a previsão de importação da versão S-1.2 no ambiente de produção restrita está prevista para ocorrer no dia 18/09/2023. Um destaque desta nova versão é a adição de informações adicionais necessárias para permitir a substituição da prestação de informações para DIRF pelo eSocial. Qualquer um pode testar transmitir eventos para o ambiente de testes, definindo tpAmb como 2 que equivale a "Produção Restrita". E o ACBr? A implementação da versão S-1.2 está em andamento por parte da equipe de consultores e contribuições da comunidade também são sempre mais do que bem vindas.

Boa tarde! Mais uma vez, muito obrigado pela contribuição! Fiz alguns testes com a mesma e não vi problemas. Enviada ao SVN na Rev-30648

Boa tarde! Por favor, se você utilizar o método NFe_ObterCertificado ele lista apenas um certificado ou dois? Um exemplo para implementar usando as classes de alto nível: var ret = ACBrNFe.ObterCertificados(); rtbRespostas.AppendText(string.Join(Environment.NewLine, ret.Select(x => x.ToString()).ToArray()));

A situação foi normalizada por volta das 12h30.

Foi divulgado um boletim informando que o serviço autorizador irá passar por uma manutenção programada no dia 16/09/2023 entre as 14h00 e as 17h10, justificando a contingência.

Bom dia a todos! Como muitos sabem, os desenvolvedores do ACBr mantêm seus repositórios no SourceForge e utilizam o SVN como ferramenta para realizar os commits com as alterações nos códigos-fonte. No dia 14 de setembro de 2023, por volta das 14h50, os membros com permissão de committer nos códigos-fonte do ACBr começaram a enfrentar problemas ao tentar realizar novos commits. Ao tentar efetuar um commit, o SVN solicita novamente as credenciais. No entanto, mesmo inserindo as credenciais corretas - que funcionam normalmente para acessar o site do SourceForge - o SVN não realiza a autenticação. Um ticket já foi criado para notificar os responsáveis, e também observamos que outros projetos estão enfrentando problemas semelhantes, o que sugere que o problema pode ser generalizado. Estamos aguardando um posicionamento. Infelizmente, enquanto esse problema não for resolvido, as alterações nos códigos-fonte do ACBr precisarão ser temporariamente pausadas, devido à impossibilidade de realizar novos commits. IMPORTANTE RESSALTAR que o UPDATE para download dos fontes está funcionando normalmente.

Bom dia! Quanto a questão de ser possível alterar, se conferirmos o XML de uma NFSe, temos a tag verAplic no grupo DPS e no grupo NFSe. A do grupo DPS é que foi enviada por você e corresponde a versão do aplicativo que gerou o DPS, no caso, a sua aplicação. Já o verAplic do grupo NFSe, corresponde a versão do aplicativo que gerou a NFSe. Este dado é preenchido pela API do Padrão Nacional. Acredito que não haja forma de alterar a não ser aguardar eles mudarem.

Boa tarde! Conferindo no painel Situação-SVC, é possível observar que a Sefaz do Paraná está com contingência agendada para o dia 16/09/2023, com previsão de inicio ás 13h00 e encerramento ás 19h00. Para usar o ACBr em contingência durante este período, siga as orientações deste tópico:

Boa tarde! Por favor, pode fornecer mais informações sobre está afirmação? Conferindo no fonte das classes, a lógica seria ocorrer o inverso do que você descreveu, pois a validação é: if FConhecimentos.Count > 0 then // Tem CTe ? Se SIM, use as informações do XML FVersaoDF := DblToVersaoCTe(ok, FConhecimentos.Items[0].CTe.infCTe.Versao) else FVersaoDF := FPConfiguracoesCTe.Geral.VersaoDF; Desta forma, se você configura VersaoDF como 3.00 e atribui infCTe.versao como 4.00, o componente vai considerar a versão como sendo 4.00 e fazer o envio nesta versão. Por favor, qual foi a mensagem de erro que você recebeu? Se ela foi: Isso pode estar relacionado ao parâmetro do modo de envio passado para o componente. A versão 4.0 não tem envio assíncrono. Na Rev-30463 foi feita uma alteração visando deixar isso automático quando configurado na versão 4.0. Por favor, verifique se seus fontes estão atualizados, em dia com o SVN e sem alterações locais. As duas configurações parecem ser semelhantes, mas atendem a propósitos diferentes. InfCte.versao define a versão do arquivo XML VersaoDF define a versão do web service que vai ser enviado o XML. Conforme citado anteriormente, no demo VersaoDF é usada para preencher infCTe.versao, mas isso é apenas uma questão de comodidade. Isso não ocorre atualmente, mas da forma como está com essas duas configurações, você tem liberdade para que, por exemplo, se a Sefaz resolver criar um web service único que possa receber XMLs de todas as versões anteriores, não precise de alteração.