Painel de líderes

Entendi essa parte. Acho legal vocês terem uma inteligência para blindar o sistema e o usuário... mas uma coisa é validar o xml, outra é alterar/modificar. Se alterássemos o xml isso poderia ser considerado uma adulteração do documento. Esse é um cuidado que estamos tendo cada vez mais com nossas rotinas e incentivamos a todos a terem também. Não tenho certeza do que se trata. Mas se é um XML de um DF-e, ele tem que ser válido. Você não precisa e nem deveria (minha opinião pessoal) modificar um xml para que seu sistema aceite... pode ser muito perigoso. Por outro lado, se ele foi aceito pelo webservice e não aceito pelo componente, então realmente precisamos validar. Nesse caso, é mais interessante criar um novo tópico para podermos tratar isso de forma específica e não misturar o assunto com esse tópico aqui. Por favor, se for o caso crie um novo tópico e anexe o XML para que possamos validar. Sim. E estamos interessadíssimos em entender o que está acontecendo. É como você disse no final, preocupamos com a comunidade e não queremos nenhuma dor de cabeça pra ninguém. Mas mantenha a mente aberta... pode ser que o método anterior estava aceitando um XML que ele deveria na verdade recusar. E agora está recusando. O que eu pensei, seria apenas alterar essa linha: para algo assim: DM_NFE.ACBrNFe1.NotasFiscais.LoadFromString(arquivo); Mas foi só uma ideia para resolver seu problema enquanto validamos a situação. Acho que não conseguimos reproduzir o problema ainda... Então, voltando ao que você postou antes... Assim que você atualizar e refazer os testes, nos avise por favor. Se tiver alguma outra informação que julgar importante, fique a vontade de compartilhar. Muito obrigado até o momento.

Boa tarde, Demorei para voltar aqui, mais isso foi por conta do Bradesco ter demorado para me dar uma solução! Antes, do dia de hoje, já havia enviado a eles, novamente a exportação do certificado no formato .cer, e estava aguardando a resposta. Acabei de ver o e-mail enviado por eles, onde pediram para eu realizar novamente o teste. Consegui gerar o QRCode, vou continuar os testes e volto para reportar mais!

Olá Pessoal, É com muita satisfação que venho informar a todos que o componente ACBrNFe ganhou novas units para Consultar a Situação de uma nota, solicitar a inutilização de um numero ou faixa de números, enviar eventos e para administrar o CSC (Código de Segurança do Contribuinte) usado na NFC-e, este ultimo não sei informa-los quais UF possuem um webservice para esse serviço. Foram criadas novas units para gerar o XML de pedido de consulta, de inutilização de envio de eventos, bem como as units que fazem a leitura do retorno foram reescritas. Elas se encontram em uma nova pasta: ...\Fontes\ACBrDFe\ACBrNFe\Base\Servicos O que muda na minha aplicação? Nada, pois essas units são utilizadas pelo próprio componente. Porque foram criadas essas novas units? As units antigas se utilizam das units pcnGerador e pcnLeitor para geração e leitura do XML respectivamente. As novas units se utilizam das units ACBrXmlWriter e ACBrXmlReader que tem a mesma função de geração e leitura. Não chegamos a realizar testes de velocidade nessas novas units criadas para o ACBrNFe, mas a um tempo atrás a unit responsável por ler o XML de um CT-e contendo aproximadamente 1.800 (mil e oitocentos) notas vinculadas demorava cerca de 6 minutos para realizar a leitura. Foi criada uma nova unit se utilizando o ACBrXmlReader para realizar a leitura do XML do CT-e, foi realizado um teste com o XML contendo 1.800 notas vinculadas e o mesmo foi lido em aproximadamente 6 segundos. Veja o ganho em velocidade na leitura do XML, de 6 minutos para 6 segundos. Por conta dessa performance resolvemos reescrever todas as units que utilizam as units pcnGerador e pcnLeitor visando a passar a utilizar as units ACBrXmlWriter e ACBrXmlReader. Não é um trabalho fácil e rápido. As novas units foram escritas, foi criado os testes unitários para cada uma delas, depois de testadas fizemos a migração, um trabalho que consumiu varias semanas. Em breve as units antigas vão ser removidas do SVN. Esse trabalho vai ser realizado em outros componentes? Sim, o próximo é o ACBrCTe, depois o ACBrMDFe. Estamos trabalhando para deixar os componentes mais velozes.

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

Catrini, Já esta no SVN.

Boa tarde Marcelo, Já esta no SVN.

Vi o video, estou começando uma maquina do zero seguindo as instruções la do video. Acho que vai resolver. Muito obrigado.

Boa tarde @Light System Software, Vamos fazer um teste: Altere o arquivo ACBrNFSeXServicos.ini deixando a seção da cidade de Guarulhos/SP da seguinte forma: [3518800] Nome=Guarulhos UF=SP Provedor=Ginfes Params=Aliquota2Casas: ProLinkURL=http://guarulhos.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://guarulhos.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Note que foi incluído a linha com o campo Params. Depois segui o procedimento abaixo: Após a alteração salve este arquivo, execute o Compila_RES que se encontra na mesma pasta. Reinstale o ACBr, abra a aplicação e compile ela com a opção Build. Por fim realize os testes de preferencia com o programa exemplo do componente ACBrNFSeX. Fico no aguardo do seu retorno.

Boa tarde @WINDEL, No meu entendimento tanto a mensagem de rejeição quanto a regra G78 deixa claro que para o tipo de faturamento (tpPag) igual a normal o grupo gFat devera constar no XML. A não ser que foi informado o indPrePago ou o IndCessaoMeiosRede O que vem a ser o indPrePago? Indicador de serviço pré-pago: informar a tag somente se a nota for referente a um serviço exclusivamente pré-pago (exemplo: contas de celular pré-pago). O que vem a ser o indCessaoMeiosRede? Indicador de Sessão de Meios de Rede: essa tag dispensa geração do grupo Fatura. Apenas para notas dos tipos Normal e Substituição com tipo de faturamento normal. (infelizmente essa outra tag tanto o manual quanto os schemas deixam a desejar em dar uma explicação mais detalhada do seu objetivo.

experimente chamar o xvfb-run --server-args="-screen 0, 1024x768x24"

Boa tarde @Messias Bittencourt Neste mini curso tem como instalar as dependências, no caso o ambiente é ubuntu Server. entao comandos apt-get se estiver utilizando uma distro q nao foi baseada no Debian, o comando é diferente. Dai vc usa o comando equivalente a sua distro. Alem de mostrar a instalação das dependências, vc vai notar que quando executo minha aplicação tenho o mesmo problema e mostro como utilizar o XFVB. https://acbr.nutror.com/curso/d484b944c7f91eb67c5e395df79d03f1e184fac5/aula/8991922

Informou a tag infEvento.CNPJ com o CNPJ do tomador?

Bom dia. No momento a ACBrLib que você está utilizando precisa de um ambiente gráfico, mesmo que seja simulado. Por isso, instale e/ou verifique a instalação do "xvfb". Ele deve resolver o problema. Veja se esse tópico também pode ajudar: https://www.projetoacbr.com.br/forum/topic/76917-utilizando-o-acbrlib-no-azure-app-service-linux-sem-docker/

OK... vou encaminhar para o time da Lib verificar a questão TK-5645 aberta para analise

Bom dia Victor, estamos fazendo a alteração nos arquivos da versão mais recente novamente e sem formatar vamos te enviar para validação.

Voce estava correto Italo. Fui removendo todas as inforamacoes referentes aos erros e deu certo. Uma observacao somente para a propriedade abaixo que deve ser informada como nenhuma: Servico.ResponsavelRetencao := rtNenhum;

ok.... obrigado removi eles do topico... TK-5644

ok.... obrigado

envie o JSON

Bom dia @Marcelo Toller, Esse não é o primeiro erro nesse schema do Padrão Nacional. Com o passar do tempo é possível que encontramos mais alguns erros. Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5643

Bom dia Italo. Utilizamos o Fast.

Bom dia @fabio.ols, A nova versão do ACBrLibNFSe já se encontra disponível. Favor atualizar e fazer novos testes.

Bom dia, Realizei a atualização da biblioteca e novo teste de emissão. O mesmo foi efetuado com sucesso, solucionando o problema. Obrigado!

Ola, Aqui tenho essa situação que é controlada pelo layout do MFe/Sat que pego ao iniciar o PDV e partir dai controlo se deve emitir com 17 ou 99.

Bom dia @Jose Carlos Barbosa Criado a tarefa tk-5641 para analise do time.

Tem que verificar se o problema esta realmente na abertura do arquivo ou na população da informação. Não achei relatos semelhantes. Envie o arquivo ofx para análise em [email protected] Lembrando, que essa implementação da forma que esta não tem como ser versionada, pois irá quebrar spor exemplo D7

Olá, Enviadas para o SVN implementações no componente, Lib e Monitor para o novo evento S2221. Lembrando as datas em que estarão disponíveis nos respectivos ambientes: * Em produção restrita a partir de 30/06/2024 * Em produção a partir de 01/08/2024 1. Segue retorno ao tentar enviar o evento em Produção Restrita antes da liberação. <processamento> <cdResposta>402</cdResposta> <descResposta>Schema do evento inválido.</descResposta> <ocorrencias> <ocorrencia> <tipo>1</tipo> <codigo>102</codigo> <descricao>O Evento informado não foi reconhecido pelo sistema. Ação Sugerida: Verificar se o evento informado e a versão do leiaute estão de acordo com a Tabela 9 (Tipos de Arquivo do eSocial) do eSocial.</descricao> </ocorrencia> </ocorrencias> </processamento> 2. Documentação do e-Social atualizada em: https://svn.code.sf.net/p/acbr/code/tools/DFe/eSOCIAL/S-1.2__2024_04/ Até mais !!!

Boa noite o arquivo que veio é UTF-8? pois estava olhando aos fontes do ACBr não notei nada que precisa modificar para carregar. no caso poderia ser colocado uma diretiva. mas também fui pesquisar e notei que não houve relatos de problemas precisando modificar, sendo que o componente já faz um tempo

Acredito que seja uma questão de atualizar o modelo na documentação. Conferindo com o manual, boa parte dos campos estão presentes e coincidem, no entanto, notei de fato a ausência de alguns. Foi criada a #TK-5640 para esta finalidade. Enquanto isso não é revisto, preenchendo as informações neste modelo de arquivo INI em anexo, consegui gerar um XML que não acusou erros nos comandos MDFe.ValidarMDFe. Por favor, veja se lhe é útil. Modelo_MDFe.ini

boa tarde, só para avisar que assim que possível farei o teste esta semana e dou um retorno.

Olá Pessoal, Devemos tomar muito cuidado ao gerar o XML, pois temos tag de diversos tipos. Tipos de tags e o que ela pode conter: Numéricas: neste caso só aceitam dígitos e o ponto decimal, exemplo: 250 ou 300.00 Data: neste caso só aceitam dígitos, a barra "/" ou o sinal de menos "-" (o mais comum é o sinal de menos), exemplo: 2024-06-24 Hora: neste caso só aceitam dígitos e o dois ponto ":", exemplo: 10:34:00 Data/Hora: é a combinação dos dois acima, exemplo: 2024-06-24T10:34:00 (temos a letra "T" entre a data e a hora Data/Hora no formato UTC: temos a Data/Hora seguida do Timezone, exemplo: 2024-06-24T10:34:00-03:00 Caracter: neste caso podemos informar uma sequencia de caracteres alfanumérica que pode conter alguns símbolos, exemplo: Rua Nove de Julho, 1250 Agora, justamente a tag do tipo caracter costumamos ver vários problemas. Por que? Existem alguns tipos de caracteres como por exemplo: "&" (e comercial comum em nome de empresas), aspas, apóstrofes e os sinais de "<" e ">" que podem não ser válidos dentros das tags. Em alguns casos o componente até pode os converter para uma sequencia chamada html entities. Mas algumas vezes o webservice (em especial de alguns provedores de NFS-e) pode recusar o seu XML acusando que a assinatura esta inválida. Devemos então evitar ao máximo utiliza-los. Detalhando: Lembre-se que os caracteres "<" e ">" aparecem no XML para indicar o inicio e o fim do nome de uma tag, exemplo: <Endereco>. As aspas são usadas para indicar o inicio e o fim do valor de um atributo, exemplo: <det nItem="1">, nItem é o atributo e o seu valor 1 esta entre aspas. Fica a dica, se você enviar um XML para o webservice da SEFAZ ou para um provedor de NFS-e e o mesmo for recusado pelo fato da assinatura estar invalida, abra o XML com o bloco de notas e procure as tags do tipo caracter e veja o seu conteúdo, pode ser que alguma dessas tags contenha um caracter ou html entities que possa estar invalidando a assinatura. A solução neste caso é os remover.

Olá pessoal! No dia 21/06/2024, foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 12 / 2024 que trás as seguintes alterações nas Tabelas Externas 5.1.1, 5.2 e 5.3 da EFD para o estado de Santa Catarina: O correio eletrônico pode ser baixado e lido na íntegra AQUI. As tabelas já atualizadas podem ser encontradas AQUI.

Olá pessoal! Foi publicada a Nota Técnica 2024/002 que traz alterações no layout da NFCom e em suas regras de validação. Alterações Adição de novo cClass Adiciona na Tabela de Códigos de Itens da NFCom (cClass) o novo item: Alterações no Schema da NFCom Adiciona os seguintes novos campos: Campos referentes a informação da Nota modelo21/22 em papel na hiótese de um Cofaturamento referenciar um documento anterior a implantação eletrônica gNF > CNPJ: CNPJ do emitente do documento fiscal. gNF > mod: Modelo do documento. gNF > serie: Série do documento fiscal. gNF > nNF: Número do documetno fiscal. gNF > CompetEmis: Ano e mês da emissão da NF gNF > hash115: Hash do registro no arquivo convêncio 115 Indicador opcional para indicar que uma nota referenciada na nota de faturamento existe somente em modelo papel indNFComAntPapelFatCentral: Informa que a NFCom Anterior de Faturamento centralizado não é eletrônica Alterações nas regras de validação Dentre as alterações nas regras de validação, vale destacar: Regra G64, Rejeição 255: Altera a regra para que passe a mesma só seja aplicada quando o tipo da NFCom for de Ajuste(finNFCom = 4). Regra G67, Rejeição 515: Altera a mensagem de rejeição para: Adição de regras: Adiciona as regras de validação G76a com a rejeição 697, G76b com a rejeição 699 e G76c com a rejeição 700 para validar os novos campos do grupo gNF Adiciona a regra de validação G91a com a rejeição 698 para validar o novo campo indNFComAntPapelFatCentral. Datas Implantação Homologação: 01/07/2024. Implantação Produção: 15/07/2024. E como fica o ACBr? Como pode ser visto, nota técnica traz a inclusão de novos campos e por isso, alterações nos fontes do ACBr serão necessárias. Foi criada #TK-5624 em nosso backlog para implementação das alterações, quaisquer novidades serão divulgadas neste tópico. Leia a Nota Técnica na íntegra AQUI.

Olá pessoal, Desculpem pela demora na resposta... Baseado nas sugestões do @Arimateia Jr, que detectou que a Macro do OpenSSL não é carregada, e achou o métodos correto... enviei ao SVN, o Commit [r34047] Realmente a rotina de `TDFeOpenSSL.LerPFXInfo` não precisava criar todo o contexto, pois ela só pretende ler o certificado... Ficou bem mais simples..

Olá pessoal! Foi publicada a versão 1.10 desta nota técnica. A nova versão traz alterações em algumas regras de validação e a adição de uma nova rejeição para substituir uma denegação correspondente. Alterações Regra de Validação 1C17-50 Altera a regra de validação transformando ela de uma denegação para uma rejeição. Lembrando que quando uma nota fiscal é rejeitada, você pode realizar a correção do erro que ocasionou a rejeição e tentar emitir novamente a mesma nota, enquanto que quando for denegada, a nota fica armazenada na base de dados da sefaz e por isso o mesmo número não pode ser utilizado novamente. Regra de Validação I08-150 Adiciona na regra de validação o CFOP 5.910: Remessa bonificação, doação ou brinde permitindo o uso do mesmo na NFC-e. Datas Implantação Teste: Até 01/07/2024 Implantação Produção: 02/09/2024 Modificações no ACBr? Como a nova versão traz alterações em regras de validação da Sefaz, alterações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.10 desta Nota Técnica na íntegra AQUI.

@Siagri Sistemas de Gestão, A versão mais recente é 1.4.0.257

O que é a Manifestação do Destinatário? Este conjunto de eventos, como o próprio nome já sugere, permite que o destinatário da NF-e possa se manifestar sobre a sua participação comercial descrita na NF-e, confirmando as informações prestadas pelo seu fornecedor e emissor do respectivo documento fiscal. Este processo é composto de quatro eventos: 1. Ciência da Emissão 2. Confirmação da Operação 3. Registro de Operação não Realizada 4. Desconhecimento da Operação Como funciona o evento Desconhecimento da Operação? Este evento tem como finalidade possibilitar ao destinatário se manifestar quando da utilização indevida de sua Inscrição Estadual, por parte do emitente da NF-e, para acobertar operações fraudulentas de remessas de mercadorias para destinatário diverso. Este evento protege o destinatário de passivos tributários envolvendo o uso indevido de sua Inscrição Estadual/CNPJ. Como funciona o evento Operação não Realizada? Este evento será informado pelo destinatário quando, por algum motivo, a operação legalmente acordada entre as partes não se realizou (devolução sem entrada física da mercadoria no estabelecimento do destinatário, sinistro da carga durante seu transporte, etc.). Como funciona o evento Confirmação da Operação? O evento será registrado após a realização da operação, e significa que a operação ocorreu conforme informado na NF-e. Quando a NF-e trata de uma circulação de mercadorias, o momento de registro do evento deve ser posterior à entrada física da mercadoria no estabelecimento do destinatário. Este evento também deve ser registrado para NF-e onde não existem movimentações de mercadorias, mas foram objeto de ciência por parte do destinatário, por isso é denominado de Confirmação da Operação e não Confirmação de Recebimento. Importante registrar, que após a Confirmação da Operação pelo destinatário, a empresa emitente fica impedida de cancelar a NF-e. Apenas o evento Ciência da Emissão não inibe a autorização para o pedido de cancelamento da NF-e, conforme o prazo definido na legislação vigente. Como funciona o evento Ciência da Emissão? O evento de "Ciência da Emissão" registra na NF-e a solicitação do destinatário para a obtenção do arquivo XML. Após o registro deste evento, é permitido que o destinatário efetue o download do arquivo XML. O Evento da "Ciência da Emissão" não representa a manifestação do destinatário sobre a operação, mas unicamente dá condições para que o destinatário obtenha o arquivo XML; este evento registra na NF-e que o destinatário da operação, constante nesta NF-e, tem conhecimento que o documento foi emitido, mas ainda não expressou uma manifestação conclusiva para a operação. Todas as operações com o evento de solicitação de "Ciência da Emissão" deverão ter na sequência o registro do evento com a manifestação conclusiva do destinatário sobre a operação (eventos descritos nos itens 5.2, ou 5.3, ou 5.4). É possível reconsiderar o registro de um destes eventos? O destinatário poderá enviar uma única mensagem de Confirmação da Operação, Desconhecimento da Operação ou Operação não Realizada, valendo apenas a última mensagem registrada. Exemplo: o destinatário pode desconhecer uma operação que havia confirmado inicialmente ou confirmar uma operação que havia desconhecido inicialmente. O evento de "Ciência da Emissão" não configura a manifestação final do destinatário, portanto não cabe o registro deste evento após a manifestação final do destinatário. O que fazer quando a operação se realizou de forma diferente do descrito na NF-e, porém a mercadoria já foi recebida pelo destinatário? Caso a operação tenha se realizado, mas o conteúdo da NF-e não descreva corretamente da operação, o destinatário deverá se manifestar utilizando o evento "Confirmação da Operação", e adotar os procedimentos fiscais cabíveis de acordo com a legislação da unidade federada onde estiver estabelecido. Os eventos "Registro de Operação não Realizada" e "Desconhecimento da Operação" não devem ser utilizados nesta hipótese. Onde podemos consultar os eventos de Manifestação do Destinatário? A consulta pública na Internet foi alterada para exibir os eventos registrados na NF-e e pode ser realizada diretamente no Portal da NF-e (www.nfe.fazenda.gov.br) ou portais das Secretarias de Fazenda da circunscrição do emitente, a partir da informação da chave de acesso da NF-e. Os arquivos XML dos eventos também serão disponibilizados para os emitentes/destinatários constantes no documento fiscal. Uma vez que o destinatário tomou Ciência da Emissão é obrigatória a sua manifestação? Sim. Toda nota informada ao contribuinte tem que ter registrada a sua respectiva manifestação até um prazo máximo de 180 dias, contados da data da ciência. Este prazo máximo será reduzido gradativamente, conforme o interesse das Administrações Tributárias. O destinatário deve apresentar uma manifestação conclusiva dentro de um prazo máximo definido, contados a partir da data de autorização da NF-e, conforme tabela abaixo: A distribuição ocorrerá para os atores que desempenham papéis de emitente, destinatário, transportador e terceiros (informado na tag autXML), e englobará os documentos que estiverem com “SIM” na linha correspondente, conforme tabela abaixo: A geração de NSU, a partir da versão 1.10 da Nota Técnica 2014.002, irá considerar somente os usuários do serviço nos últimos 60 dias. É importante ressaltar que: a) para os usuários do serviço dos últimos 60 dias, a geração de NSU continuará normalmente; b) no caso de novos usuários desse serviço (distNSU), a geração de NSU ocorrerá a partir do primeiro acesso. Não haverá geração de NSU retroativo; c) qualquer usuário que deixar de utilizar o serviço (distNSU) por mais de 60 dias, terá a geração de NSU interrompida e retomada a partir da próxima consulta com este método. Não haverá geração de NSU retroativo ao período de interrupção. OBS: A partir da versão 1.13 da Nota Técnica 2014.002, os eventos gerados pelo Fisco, que forem passíveis de distribuição conforme a tabela acima, serão distribuídos ao emitente independente de manifestação do destinatário, ainda que emitente e destinatário sejam iguais.

Copie ambas as DLLs do Link abaixo, para a mesma pasta do seu .EXE http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/X86/ Se houver, na mesma pasta, apague demais DLLs do OpenSSL, além dessas acima