Diego Foliene

Olá pessoal! Foi publicado no dia 30/07/2024, no portal SPED, comunicado informando sobre a versão 10.0.13 do programa ECF utilizado para transmitir arquivo do ano-calendário 2023 e situações especiais de 2024(item 10). A nova versão trás as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7494

Boa tarde! Conferindo aqui, a tarefa encontra se em nosso backlog para ser desenvolvida de acordo com a disponibilidade da equipe de consultores. A mesma ainda não foi desenvolvida devido a outras demandas. Vou anotar uma observação na mesma informando que fez uma solicitação de andamento e pedindo uma posição mais definitiva.

Bom dia! Criada a #TK-5799 para análise do caso e parecer por parte da equipe de consultores.

Foi publicada a versão 24.2.A das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/07/2024 até 31/08/2024 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto" não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Vamos realizar um teste em nosso ambiente e retornamos assim que descobrirmos algo. Por favor, confirme qual é o arquivo .fr3 que esta utilizando.

Boa tarde! Vamos analisar a modificação que sugeriu na ACBrGNReWebServices. Para este caso, no caminho Pagina principal > Gerar XML de Lote, eu adicionei uma guia usando os mesmos dados de "lote AL com IE.xml" e depois usei a opção Gerar XML. O resultado foi o arquivo em anexo. Veja a diferença entre o grupo contribuinteDestinatario do seu arquivo "lote AL com IE.xml": <contribuinteDestinatario> <identificacao> <IE>242070817</IE> </identificacao> <razaoSocial>A D M REPRESENTACOES LTDA</razaoSocial> <municipio>04302</municipio> </contribuinteDestinatario> E do grupo em meu arquivo: <contribuinteDestinatario> <identificacao> <IE>242070817</IE> </identificacao> </contribuinteDestinatario> No meu caso, quando selecionei a opção SIM, ele só me pediu a inscrição estadual. Por favor, faça um teste desta forma e veja se ainda vai apresentar problemas. (Apenas gerei o XML, mas não processei o lote para ver o resultado). Lote_2024_07_29_17_51.xml

Boa tarde! Por favor, quando foi a última vez que atualizou seus fontes e reinstalou o ACBr? No dia 25/07/2024 às 08h50 foi enviado ao SVN na Revision 34568 uma nessas units visando corrigir problema relacionado. Caso sua última atualização e reinstalação tenha sido anterior a esta data, por favor, atualize e reinstale para realizar novos testes.

Antes de mais nada é preciso entender o que é LCR. Como todos sabem, quando enviamos um documento fiscal para o web service da Sefaz, o mesmo deve ter sido assinado por um certificado digital que também é utilizado na comunicação propriamente dita para garantir a segurança e a veracidade dessa troca de informações entre o emissor e o servidor de destino. Este certificado digital usado pelo emissor, possui uma data de início e fim de validade, então você pode ter um certificado que ainda não está valido ou com validade expirada, tornando o certificado inválido. No entanto, as vezes, por algum outro fator, como por exemplo, extravio do certificado digital ou alteração do contrato social, pode ser que o certificado deixe de ser válido mesmo ainda estando dentro do período de validade vigente. Quando isso acontece o certificado é adicionada na Lista de Certificados Revogados (LCR) para dizer a todos que a consultarem que ele não é mais válido. Entendendo a rejeição. Agora que entendemos o que é LCR, vamos voltar a rejeição: Vejam que coloquei a palavra "acesso" em destaque. Isso porque quem a faz a consulta na LCR é o servidor que está recebendo a comunicação, ou seja, é o servidor de destino quem consulta a LCR, o que significa que a rejeição 296 está nos dizendo que o servidor da Sefaz não conseguiu acessar a LCR para consultar se o certificado que está comunicando é válido. E como eu resolvo? Infelizmente, este é um erro em que não se pode fazer muita coisa do lado da software house, pois é um erro que ocorreu do lado do web service da Sefaz ou do lado da própria certificadora digital. Portanto, se você está recebendo esta rejeição, o curso de ação mais indicado é: Orientar seu cliente para que ele possa entender que o problema é na Sefaz ou na certificadora digital, sendo assim, um problema externo. Abrir um Fale Conosco junto a Sefaz respectiva para deixá-los cientes do problema. Realizar novo teste após aguardar um período de tempo.

Procure por JSONDataObjects_ACBr.dcu no caminho \ACBr\trunk2\Lib\Delphi Veja se o .dcu não está faltando. O erro aponta para a linha 6, mas a linha propriamente dita não possui a declaração da unit, o que indica que ela está declarada em uma das units do ACBr que estão declaradas na unit da linha 6 e não está conseguindo compilar com ela. Tente também: Procurar por qualquer .dcu do ACBr na pasta C:\Users\Public\Documents\Embarcadero\Studio\VersaoDoSeuDelphi e se encontrar algum, excluir. Após o passo acima, reinstalar com a opção de "Apagar arquivos antigos" marcada e verificar se vai apresentar erro na instalação.

Bom dia! Por favor, o erro ocorre na instalação dos fontes ou quando tenta realizar um build de sua aplicação? Qual é a mensagem de erro na integra? Se você clicar nela ele chega a mostrar mais informações do porquê não foi possível compilar? Conforme mencionou a esocialr_envio_retorno é uma unit do seu projeto, mas a JsonDataObjects_ACBr está em ACBr\trunk2\Fontes\Terceiros\JsonDataObjects\Source Se ela estiver com algum problema, precisamos entender qual é.

Você tem uma IE válida? Se tiver, faça um teste marcando que o contribuinte destinatário está inscrito na UF e use a mesma. Criada a #TK-5791 para analise das modificações da versão 2.11

Boa tarde! A princípio, o conferindo nos schemas, essa tag possue apenas um valor válido, que é o valor 1. Por isso, ela só é gerada quando for informado tiSim. if (VersaoDF >= ve300) and (CTe.infCTeNorm.infCteSub.indAlteraToma = tiSim) then Gerador.wCampo(tcStr, '#385', 'indAlteraToma', 01, 01, 0, TindicadorToStr(CTe.infCTeNorm.infCteSub.indAlteraToma), DSC_INDALTERATOMA); Também é válido mencionar que se você pesquisar pelo campo no Manual CTe Anexo I Leiaute e Regras de Validacao v4.00 e subir até o início, vai ver que ele está na parte do Conhecimento de Transporte de Carga Modelo 57 apenas.

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

Realmente, é uma mensagem no mínimo estranha. Eu fiz alguns testes gerando no portal de testes. Com o CTe também deu o mesmo erro de que a receita não exige o tipo de documento informado. O mais próximo que consegui foi com este XML em anexo. Nele todos os dados são fictícios. Usei a UF favorecida como sendo de AL, informei o estado do emitente como RS colocando Porto Alegre como a cidade, para o destinatário, informei que era inscrito na UF favorecida e usei um IE fictícia do AL criada pelo gerador de IE. Só apresentou um erro no processamento: Lote_2024_07_26_17_27.xml

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

No arquivo Teste Alagoas - sem ID.xml ainda está sendo usado o 22: <documentoOrigem tipo="22">43231147531706000143550010000000851000000997</documentoOrigem> Isso foi no site ou no web service? Se você só informar estes dois campos ele aprova?

Boa tarde! Sim, com a Lib da NFe você consegue executar a consulta de Distribuição DFe por UltNSU e com isso fazer o download dos resumos e notas completas emitidas contra o seu CNPJ. Para isso, você vai utilizar o comando NFE_DistribuicaoDFePorUltNSU. Por ser membro PRO, você tem acesso liberado aos cursos disponibilizados pelo ACBr. Esta é uma AULA que demonstra o uso da Lib para executar a Distribuição DFe. É em Java, mas o conceito pode lhe ser útil.

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

Pela rejeição que recebeu, me parece ser um problema com o documentoOrigem utilizado. O ambiente do GNRe é no mínimo, "confuso" no aspecto das informações. Se conferirmos em Consultar Tabelas > Documentos Origem nos ambientes de homologação e de produção, vamos ter valores diferentes para o mesmo estado. No seu XML, a tag tpAmb está com o valor de homologação, você está com homologação configurada em ACBrGNRe.Configuracoes.WebService.Ambiente ? Comparando as duas tabelas, os valores que coincidem em ambos os ambientes para o código de receita que usou são: 1 - Nota fiscal avulsa 7 - Conhecimento de Transporte Rodoviário. 8 - Conhecimento de Transporte Aéreo 10 - Nota Fiscal O valor 22 só existe no ambiente de homologação. Tente fazer um teste usando um valor diferente dele e veja se recebe retorno diferente.

Boa tarde! Separei sua nova dúvida em um novo tópico para não confundir os assuntos.

Boa tarde! Conferindo no código, realmente a rotina só é usada na leitura. Criada #TK-5789 para análise da solicitação e parecer por parte da equipe de consultores.

Boa tarde! Por favor: Você está utilizando componente nativo para Delphi/Lazarus, Monitor ou Lib? Ele corta o final somente no preview ou se imprimir no A4 também fica cortado? Seu cliente está utilizando o copia e cola ao invés do QrCode? Existe zoom aplicado no monitor?(Isso pode interferir em como o preview é exibido).

Boa tarde! O ACBrMonitor fecha quando executa alguma ação em específica? Qual é a versão do ACBrMonitor que está utilizando? O problema ocorre somente em uma máquina específica? O executável é assinado para evitar problemas com o anti-vírus, mas apenas por precaução, foi adicionado o Monitor na lista de exceções?

Olá pessoal! Foi enviado ao SVN na Rev-34583 a adição do novo comando SAT.ObterIniCFe. Este novo comando vai receber como parâmetro o caminho completo de um arquivo XML de um cupom fiscal ou o conteúdo do arquivo propriamente dito e devolver as informações que foram lidas pelo Monitor em um formato INI. Vejam um exemplo da estrutura de retorno: [infCFe] ID=35240600000000000000000000208790000741625864 VersaoDadosEnt=0,07 versao=0,07 versaoSB=40016 [Identificacao] cUF=35 cNF=123456 mod=59 nserieSAT=123456789 nCFe=74 dhEmi=26/07/2024 cDV=4 tpAmb=2 CNPJ=11111111111111 signAC=SGR-SAT SISTEMA DE GESTAO E RETAGUARDA DO SAT assinaturaQRCODE=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxx== numeroCaixa=1 [Emitente] CNPJ=11111111111111 xNome=Nome do Emitente xFant= xLgr=Logradouro do Emitente nro=1 xCpl= xBairro=Bairro do Emitente xMun=Municipio do Emitente CEP=12345678 IE=111111111111 IM=111111 cRegTrib=3 cRegTribISSQN=1 indRatISSQN=S [Destinatario] CNPJCPF=22222222222222 xNome=Nome do Destinatario [Entrega] xLgr=Endereço de Entrega nro=1 xCpl= xBairro=Bairro de Entrega xMun=Municipio de Entrega UF=SP [Produto001] cProd=1189 cEAN= xProd=OVO VERMELHO NCM=04072100 CEST= CFOP=5102 uCom=DZ qCom=510 vUnCom=2,7 vProd=1377 indRegra=A vDesc=0 vOutro=0 vItem=1370 vRatDesc=7 vRatAcr=0 cANP=0 vItem12741=137 infAdProd=Teste de Produto [ObsFisco001] xCampoDet= xTextoDet= xCampo=04.04.05.04 xTexto=Comete crime quem sonega [ICMS001] orig=0 CST= CSOSN=500 pICMS=0 vICMS=0 [PIS001] CST=01 vBC=0 pPIS=0 vPIS=0 qBCProd=0 vAliqProd=0 [PISST001] vBc=0 pPis=0 qBCProd=0 vAliqProd=0 vPIS=0 [COFINS001] CST=01 vBC=0 pCOFINS=0 vCOFINS=0 vAliqProd=0 qBCProd=0 [COFINSST001] vBC=0 pCOFINS=0 qBCProd=0 vAliqProd=0 vCOFINS=0 [ISSQN001] vDeducISSQN=0 vBC=0 vAliq=0 vISSQN=0 cMunFG=0 cListServ= cServTribMun= cNatOp=0 indIncFisc=2 [Total] vICMS=0 vProd=1377 vDesc=0 vPIS=0 vCOFINS=0 vPISST=0 vCOFINSST=0 vOutro=0 vCFe=1370 [DescAcrEntr] vDescSubtot=7 vAcresSubtot=0 vCFeLei12741=137 [ISSQNtot] vBC=0 vISS=0 vPIS=0 vCOFINS=0 vPISST=0 vCOFINSST=0 [pag001] cMP=01 vMP=1400 cAdmC=0 cAut= vTroco=30 [DadosAdicionais] infCpl=Teste emissao CFe/SAT

Foi gerada uma nova compilação do ACBrMonitor, por favor, queira atualizar e realizar novo teste.