Victor H. Gonzales - Panda

Com o intuito de manter a segurança do ambiente de Autorização das Notas Fiscais Eletrônicas de Pernambuco, assim como já feito com outros sistemas da SEFAZ-PE e de outros estados, desativaremos acessos com protocolos de comunicação não seguros (TLS 1.0 e 1.1). Os contribuintes deverão verificar se suas aplicações, navegadores de internet e sistemas operacionais estão atualizados e utilizando o protocolo TLS 1.2. Caso estejam desatualizados, não será possível estabelecer conexão entre a aplicação cliente e a aplicação servidora do ambiente de autorização de notas fiscais. Quando será efetivado o bloqueio de protocolos obsoletos e inseguros? - 09/05/2022 - ambiente NF-e Homologação. - 04/07/2022 - ambiente NF-e Produção. Como exemplo, para habilitar o protocolo atual em uma estação Windows (antiga) o usuário deve: acessar o Painel de controle >> Rede e Internet >> Opções da Internet >> selecionar a aba Avançado, marcar a opção "Usar TLS 1.2" e Aplicar. Caso a empresa utilize servidores para comunicação com a SEFAZ-PE, será necessário acionar o suporte técnico da empresa. Assinado por: Secretaria da Fazenda de Pernambuco Fonte : Portal da Nota Fiscal Eletrônica (fazenda.gov.br)

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Publicado em 24/06/2022 Foi publicada a nova versão 3.1.0 do Guia Prático e a Nota Técnica 2022.001 v1.1 com vigência a partir de janeiro/2023, com as seguintes alterações: 1. Descontinuação dos códigos 04 e 05 da tabela 4.1.2 – Tabela Situação de Documentos a partir de 31/12/2022 2. Inclusão dos registros 0221, C855, C857, C895, C897, D700, D730, D731, D735, D737, D750, D760 e D761 3. Inclusão da exceção nº 2 na validação do registro C800 4. Alteração da regra de validação do campo 06 do registro C170 5. Alteração da regra de validação do campo 09 do registro C800 6. Alteração da regra de validação do campo 02 dos registros C181, C330, C380, C430, C480, C815 e C880 7. Alteração da regra de validação do campo 06 do registro C185 8. Alteração do tamanho do campo 02 (15 para 60 caracteres) do registro C111 9. Alteração do tamanho do campo 03 (15 para 60 caracteres) dos registros E112, E230, E312 e 1922 10. Alteração do tamanho do campo 06 (15 para 60 caracteres) dos registros E116, E250, E316 e 1926 11. Inclusão de uma nova opção de indicador para o campo 02 do registro K010 Clique aqui para acessar a documentação Fonte : Nova Versão do Guia Prático da EFD ICMS IPI (rfb.gov.br)

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Bom dia, Obrigado pela contribuição. Como o arquivo faz a leitura / escrita diretamente seguindo o layout, ele não está utilizando o valor da fpTamanhoNumeroDocumento. para ter impactos, teríamos que alterar todos os demais métodos, tanto no cnab240 e 400, leitura e escrita, mas acaba tornando desnecessário. Abraços

Boa tarde Fábio Obrigado pela a ajuda, eu não sou correntista, e a documentação deles é muito sucinta. Como eu já disse algumas vezes no tópico, o componente ele não imprimi o código que é utilizado na geração do campo livre (Número da Operação 0618618), e sim o número da conta bancária que é utilizada na remessa. Por favor, se possível me faça esse favor, faça o revert em todos os componentes e arquivos do ACBr, atualize o componente e instale o componente, depois faça o seu teste por favor. o Numero que sairá impresso nesse campo, é o número que está informado na propriedade de conta. Obrigado

Boa tarde, o que vocês estão dizendo, é que esse banco, tem um "código" que é impresso no boleto, mas esse código não está informado em nenhuma parte do manual, e vocês só estão confrontando isso pela a impressão via sistema dela e chegaram a essa conclusão? Porque como eu já disse acima, o código de operação ela não é impressa mais no boleto, e sim o número da conta bancária, que é informação que é utilizada para envio da remessa, pelo o que vocês estão falando, existe agora uma terceira informação, essa que só é "vista" se a pessoa imprimir um boleto pelo sistema deles e que não consta nenhuma instrução desse campo no manual deles, é isso?

Bom dia, não existe especificações técnicas de consumo indevido na Nota Técnica, só que "eles estão de olho", se não usar com parcimônia, eles vão retornar consumo indevido. referente a GS1, sugiro entrar em contato com eles, pois se não estou enganado, existe casos que sai até gratuito.

Pelo zebradesigner imprime certo?

Bom dia, No manual que você anexou não existe nenhuma parte onde diz como deve ser montado a ficha de compensação, por isso eu disse para você anexar o manual de confecção da ficha de compensação, geralmente as instituição bancárias tem esse manual, dizendo o que cada campo da ficha de compensação, tamanhos mínimos, papeis, etc. Esse manual que você mandou basicamente é para gerar a remessa / retorno (cnab) não trata em si da ficha de pagamento/compensação. Referente a essa propriedade que existe no manual que é referente ao campo livre, que no manual na página 21 refere-se a "Seu número da Operação", essa propriedade para composição do campo livre ela é mapeada no componente como lhe passei acima no item 3.14 das peculiaridades, isso não gerando problemas para compensação/pagamento da ficha. Alterar essa propriedade que esta em produção isso irá gerar um impacto negativo, isso será declinado, pois isso irá impactar em todas as linhas digitáveis de quem já utiliza, e só resolver o seu caso e os próximos. Como eu disse na sexta feira as 15horas, a propriedade foi removida da ficha de compensação, ficando apenas na linha digitavel, no lugar foi impresso o número da conta bancária, esse que é utilizado na geração da remessa.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

a propriedade Conta foi impressa no valor e suprimido o código de integração

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, não me recordo disso no ESCPOS, o que eu faço é uma flag ao abrir o sistema, e marcar que a gravação já foi enviada, para não ficar tentando gravar continuamente.

Bom dia, ok. a questão de remover da impressão do boleto o código interno que é do controle do campo livre esse não é o problema, só que a sua solicitação isso tem impacto negativos, e esse campo ele é mapeado, e esse campo informado não tem impactos como a linha digitável. referente a esse novo código que está sendo solicitado, por favor anexe o manual da ficha de compensação para verificar, pois isso geralmente é enviado na remessa, se essas informações não estão na remessa, é estranho o banco enviar uma terceira informação no retorno, sendo uma informação da remessa é só ajustar a impressão. lembrando que esse banco já está em produção a pelo menos 6 meses.

Boa tarde, Primeiramente obrigado pela contribuição conforme o item 3.14 de particularidades do ACBrBoleto, essa propriedade está mapeada. No caso cada banco pode ter uma variação de nomenclatura, ainda há uma previsão de várias dessas nomenclaturas do componente serem extintas. Portanto, solicito que faça o revert no seu arquivo e utilize o do SVN, onde não existe problema na linha digitavel como informado no inicio do tópico, basta informar na propriedade mapeada conforme o componente aguarda. Obrigado.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo Boa tarde, poderia fazer os testes por favor

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Boa tarde, Obrigado pela contribuição... na documentação consta o campo como SeuNumero mesmo, portanto estaria correto a forma que está