Painel de líderes

A legislação atual de MG (RICMS) deixa claro que, mesmo que se informe conforme o layout apresentado na NT 2015/002, deve ser informado no grupo de observações do contribuinte a partir da data especificada. O objetivo disso é que saia no DANFe (ou DANFCe). O artigo 36-M da Parte 1 do Anexo V do RICMS, citado no decreto trata-se, do "Documento Auxiliar da NFC-e - DANFE NFC-e". MG está exigindo que as informações sejam impressas no DANFe NFC-e. Teoricamente não seria necessário usar os outros campos, mas pode ser que o objetivo seja deixar bem claro que deve ser impresso no DANFe essas informações.

Obrigado pela dica @BigWings, vc acertou em cheio. Tenho um outro componente que utiliza a smtpsend, e pelo fato dele estar desatualizado e o meu library path também estar apontando para esse outro componente, estava dando conflito. Peço desculpas a todos, e que fechem esse tópico.

diretamente no site das IPEFs www.efrete.com.br www.repom.com.br www.rodocred.com.br www.nddcargo.com.br www.policard.com.br Fazer cadastro , aguardar aprovação e acessar o ambiente gratuito deles.

Creio eu que sim veja:

Bom dia. no caso o escritório contábil não importa os eventos de cancelamento que tu manda? tem uma propriedade no ACBrNFe em Geral.AtualizarXMLCancelado para modificar o xml válido e fazer como antigamente. veja se resolve sua situação.

no caso do post do Sergio é sobre cancelamento. no cancelamento temos um evento atrelado e o xml da NF-e já não tem validade e se modificar o mesmo não tem mais, mas é possível contornar isso com a propriedade no componente que altera o xml válido e adiciona como cancelado. já no seu caso sugiro fazer uma consulta de protocolo após emitir com o xml ainda no componente que assim senão existir a autorização ele vai adicionar a mesma .

Da uma olhada em: https://www.projetoacbr.com.br/forum/topic/55664-acbrciot/?page=3&tab=comments#comment-366962

Suspensão da obrigatoriedade da geração do código CIOT até o julgamento, em fevereiro, pelo Supremo Tribunal Federal. Leiam arquivo anexo. Suspensão Obrigaação CIOT.pdf

Apenas esclarecendo... Não é a opção "Validar digestValue" que causou esse erro. Essa NFe 3684 foi transmitida com os dados que conta na SEFAZ, pode ser que por algum motivo essa NFe foi alterada na sua aplicação ou gerada novamente com outros dados, mas manteve a chave que já havia sido transmitida... A opção de "Não validar digestValue" apenas vai permitir atualizar o protocolo desta NFe que está na sua máquina (com a mesma chave que está na SEFAZ) mesmo que tenha ocorrido alguma alteração no XML. É justamente por isso que existe essa opção, voce pode desejar alterar algum detalhe no XML da NFe mesmo depois de transmitida, e essa opção apenas vai te alertar que houve alteração no XML, no momento de atualizar o protocolo. O indicado é não desabilitar essa opção, mas independente disso, não impede sua aplicação de gerar um novo XML com os mesmos dados da Chave já transmitida. Neste caso deve Cancelar a NFe se estivesse no prazo e não houvesse manifestação, mas neste caso como não é possível cancelar precisa seguir as orientações do Contador, conforme o Kiko Fernandes orientou.

Veja se após inutilizar ele retornar o nome do arquivo nessa propriedade ACBrNFe1.InutNFe.ObterNomeArquivo tem todas as informações nesse objeto abaixo ACBrNFe1.InutNFe

Exato usado para manifestar. joia o download é somente para o caso daquela que foi perdida ou não enviada

Encontrei a solução para windows 10. Pra arrumar tive que criar outro usuário administrador, deslogar do atual.. logar no segundo usuário, colocar o anterior como usuario comum.. logar como usuário comum.. depois deslogar novamente alterar de volta para administrador e logar de novo.. trabalheira, mas funcionou.. lembrando que tem que deslogar (sair), não apenas alterar o usuário, para o windows atualizar as permissões.

Bom dia. minha primeira sugestão é tirar o ACBr de dentro de Program Files(x86) . coloque em uma pasta na raiz do o windows é meio as avessas usar essas pastas. o problema é que tem em algum lugar com essa mesma unit compilada roda a o apagaracbr.bat e depois que trocar de local a pasta refaça a instalação dele

mas tu baixa todos os xml? lembre-se de ler as NT onde ela diz que só pode ser feito download de 30% das notas emitidas e recebidas, pois é para eventualidades e não para regra

O apagarACBr.bat não apaga alguns dcu, geralmente os de terceiros. Então mesmo executando o apagaracbr ainda pode haver algum arquivo smtpsend.dcu ou smtpsend.pas desatualizado em algum lugar que o Delphi está encontrando na compilação. Então você precisa fazer uma varredura em todos os discos por estes arquivos e se for o caso removê-los ou atualizá-los.

eu já, a nota ta na sefaz manifestada e nem sempre é disponibilizada na hora, infelizmente não tem solução pra isso, pelo menos nao achei, e todos tem esse delay, as vezes eu manifesto a nota e o ws libera instantaneamente, outras so depois de minutos ou horas.

Bom dia, em BH se estiver em homologação é assim mesmo...

Bom dia! Sim, mas com a linguagem Pascal e Lazarus, tem quase 1 ano. O problema foi resolvi, precisei mudar no componente TMedit de 00/00/0000 para 99/99/9999. Mas obrigado pela informação.

Bom dia! Para quem usa o ACBrMonitor verifique se a opção "[ V ] Atualizar XML Cancelado" em DFe / Diretórios está marcada.

Bom dia. Na revisão 18946 foi commitada pelo @BigWings uma possível correção. Att.

Olá pessoal, No dia 20/12/2019 foi publicado o Decreto de numero 47.799 que trata sobre a venda de combustíveis a consumidor final em estabelecimento comercial varejista de combustíveis automotivo. O decreto possui dois artigos, o primeiro se refere a obtenção das informações referente ao encerrante e o segundo diz onde as informações do mesmo deve ser informadas no XML. Para ler na integra o decreto clique aqui. Minhas considerações: 1. Esse decreto só serve para informar que se tratando de venda de combustível para consumidor final devemos informar no XML da NFC-e os dados referente ao encerrante, visto que essas informações ficou a critério de cada UF exigir ou não. 2. O decreto é de 19/12/2019, mas na Nota Técnica 2015/002 já estava previsto que a obtenção dos dados referente ao encerrante deveria ser via hardware, logo não deve ser digitados. Final da página 4 da referida NT: C. Grupo de Combustível: Informação de “Encerrante” Dentro do grupo de informações relacionado com as operações de combustíveis, foi incluído o subgrupo de “encerrante” que permite o controle sobre as operações de venda de combustíveis, de forma semelhante à atualmente em vigor. Observação do grupo <encerrante>: Informações do grupo de “encerrante” disponibilizado por hardware específico acoplado à bomba de combustível, definido no controle da venda do Posto Revendedor de Combustível. 3. No segundo artigo do decreto diz que temos que informar os seguintes dados: nBico, nBomba, nTanque, vEncIni e vEncFin no grupo de informações do contribuinte, ou seja, no campo xCampo devemos colocar o nome do campo, por exemplo nBico e no campo xTexto o numero do bico propriamente dito. Mas acontece que na NT que eu me referi na mesma página temos os campos que compõe o grupo <encerrante>, são eles: nBico, nBomba, nTanque, vEncIni e vEncFin. Duvida cruel: Se tratando de Minas Gerais as informações referente ao encerrante devemos informar no grupo <encerrante> conforme layout apresentado na Nota Técnica 2015/002 ou devemos colocar essas informações no grupo de observações do contribuinte? Se no layout da NF-e/NFC-e já existe um grupo especifico para tais informações pra que informar em outro lugar? Desenvolvedores, que possuem clientes que comercializa combustível no varejo, favor ficar a tento a isso. Não sei se cabe a uma consulta ao órgão competente. Data de inicio da exigência dessas informações no XML: 01/04/2020 Pela data deve ser tudo mentira. Não se faz necessário alterações no componente ACBrNFe.

Bom dia. Na revisão 18946 foi commitada pelo @BigWings uma possível correção. Att.

Bom dia. Na revisão 18946 foi commitada pelo @BigWings uma possível correção. Att.

XML do evento de cancelamento? deve carregar no componente o XML original e efetuar uma consulta de protocolo que vai vir todos os eventos daquela nota. inclusive o de cancelamento

Bom dia. Esta implementação seria do lado do provedor e não do ACBr. Att.

Veja... todos aqui são voluntários... Portanto respondem quando querem, quando podem e quando sabem a resposta... A resposta pode não ser exatamente como você esperava... mas já lhe dá uma direção de como prosseguir suas pesquisas... Você ficaria ainda mais decepcionado... se a sua pergunta ficasse sem resposta nenhuma... Você pode encontrar os manuais do SAT, em nosso repositório: http://svn.code.sf.net/p/acbr/code/tools/SAT/ Boa leitura e pesquisa...

De uma olhada no demo em fast

Boa tarde, A TLP-400 agora é compatível com os protocolos ZPL, PPLA e PPLB. Em breve enviaremos para homologação do ACBR.

Hum interessante mas é algo do windows ou dll faltando por isso não rodou

Não temo fontes oficial mantidos no GIT o que está correto é o do SVN

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

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

Por enquanto está funcionando sem problemas. Eu tinha que reinstalar este pacote umas 5 vezes por dia Obrigado.

Maiquel, Favor atualizar os fontes, reinstale a suíte ACBr e faça novos testes.

Bom dia Estou tendo problemas com a atualização do ACBr, mas para não fugir do assunto do tópico irei criar um novo.

bom dia. no exemplo do svn da NFS-e tu consegue ver com calma como fazer a questão do certificado. Creio que o erro no seu cliente seja por falta de alguma atualização do windows. quando se usa openssl não consegue selecionar o certificado e sim deve de abrir um opendialog para buscar o arquivo pfx, por isso da msg

Bom dia Na revisão 18946 foi commitada pelo @BigWings uma possível correção. Att.

@Hubel Solis Bonifacio, desculpe-me pela demora na resposta... prometo que analisarei seus arquivos e considerações ainda essa semana...

Bom dia Brito, Estamos estudando a implementação desse provedor, mas como lhe disse vai ser demorado.

Tópico fechado por falta de retorno do usuário

Ambas as chaves foram transmitidas e autorizadas na SEFAZ, porém a chave 33190931856735000145550010000036841001814898 foi Atualizada com protocolo errado, justamente por não validar o digestValue Ou seja, o XML que está na sua máquina com essa chave não é o mesmo que foi enviado para SEFAZ, note que são diferente os valores da tag "digestValue" na NFe e Protocolo.

Essas linhas do log: -- 29/01 15:28:37:950 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 7 Buffer = Tam.Min = 0 Tam.Max = 0 -- 29/01 15:28:37:975 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 29/01 15:28:39:179 - ContinuaFuncaoSiTefInterativo, Retornos: STS = -41 ProximoComando = 0 TipoCampo = 7 Buffer = Tam.Min = 0 Tam.Max = 0 -- 29/01 15:28:39:189 - *** ContinuaFuncaoSiTefInterativo, Finalizando: STS = -41 -- 29/01 15:28:39:198 - BloquearMouseTeclado: NAO O retorno -41 é Dados inválidos. Acredito que isso indica que o Sitef estava esperando um tratamento para o TipoCampo 7 que parece ser um menu de pagamento Carteira Digital. Tem que verificar a documentação que você anexou para efetuar os ajustes. Isso não é tão difícil quanto parece. Se você estiver disposto, sugiro que tente verificar.

Obrigado amigos! Vou trabalhar um pouco e assim que tiver uma posição, aviso vocês. Abraço!

Delphi 10.1 Berlin 1). O governo do Peru, solicita a codificação ISO-8859-1, Seria possível mudar para ISO-8859-1, revi a unidade ACBrDFeSSL e em todos os lugares que ele usa utf-8. 2). Mude para utf-8 e agora recebo o erro de que o documento foi alterado, usando FormatXMLData y nao usando. "El documento electrónico ingresado ha sido alterado - Detalle: Incorrect reference digest value" 3). Analisei a assinatura que gera TDFeSSL e a tag está ausente <X509SubjectName>SERIALNUMBER=RUC:25988430712 C=PE</X509SubjectName> 4). Essa é a ligação. {$IFDEF USAR_NETFRAMEWORK} function zfirmaxml(xmlsinfirmar,xmlfirmado,pathcertificado,clavecertificado:WideString):Integer; stdcall; external 'firmaxml509.dll'; {$ELSE NO USAR_NETFRAMEWORK } function ACBrfirmaXML(xmlsinfirmar,xmlfirmado,pathcertificado,clavecertificado:WideString; conformato : integer):Integer; var xmltmp : TXMLDocument; XMLAnsi : AnsiString; ssl : TDFeSSL; begin if (not FileExists(xmlsinfirmar) ) or (not FileExists(pathcertificado) ) then begin Result:=0; exit; end; xmltmp:= TXMLDocument.Create(FrmGenCPE); xmltmp.Active:=True; xmltmp.Encoding :='utf-8'; xmltmp.StandAlone:='no'; xmltmp.XML.LoadFromFile(xmlsinfirmar); ssl:=TDFeSSL.create; ssl.SSLCryptLib := cryWinCrypt; //(cryNone, cryOpenSSL, cryCapicom, cryWinCrypt); ssl.SSLXMlsignLib:=xsLibXml2; //(xsNone , xsXmlSec , xsMsXml , xsMsXmlCapicom, xsLibXml2); ssl.ArquivoPFX:=pathcertificado; ssl.Senha:=clavecertificado; ssl.CarregarCertificado; XMLAnsi:=ACBrAnsiToUTF8(xmltmp.XML.Text); //CenteudoXML, docElement, infElement, SignatureNode, SelectionNamespaces, IdSignature, IdAttr if (conformato=1) then xmltmp.XML.Text:=FormatXMLData(ssl.Assinar( XMLAnsi ,'ExtensionContent','','','ext','','')) else xmltmp.XML.Text:=ssl.Assinar( XMLAnsi ,'ExtensionContent','','','ext','',''); xmltmp.XML.SaveToFile(xmlfirmado); xmltmp.Active:=False; ssl.Free; xmltmp.Free; Result:=1; end; {$ENDIF USAR_NETFRAMEWORK} 5) Resultados em anexo. DLL_NetFM_ISO8859_formatXML_20489430712-01-FE82-00000201_OK.xml ACBr_ISO8859_formatXML_20489430712-01-FE82-00000201_error_alterado.xml ACBr_utf8_formatXML_20489430712-01-FE82-00000201_error_alterado.xml ACBr_utf8_naoFormat_20489430712-01-FE82-00000201_error_alterado.xml Obrigado por suas respostas

Estava informado como 02 realmente, apos a sua resposta localizei o meu erro. Fico muito agradecido. Agora antes de fechar o topico mim diz uma coisa para todos os bancos posso estar mandando a ocorrenciaoriginal o tipo como "01"

AC = Aplicativo Comercial Essa Luz só irá acender, quando a Aplicação (programa), estiver comunicando com o SAT

O ACBr suporta impressoras USB ? Durante muito tempo, a resposta a essa pergunta foi: NÃO, você precisa usar a Porta COM, Spool do Windows (RAW), Compartilhamento de Rede ou algum outro método... Porém agora isso mudou... Agora componentes que usam o ACBrDevice, como por exemplo o ACBrPosPrinter (para Impressoras Não Fiscais) e o ACBrETQ (para Impressoras de Etiquetas), possuem suporte a portas USB de maneira nativo do Windows... Ou seja, sem a necessidade de DLLs externas... Isso significa que caso o seu equipamento esteja conectado ao PC, por uma Porta USB... Você poderá conectar os componentes do ACBr, simplesmente definindo na Propriedade Porta algo como "USB" Exemplos de uso: ACBrPosPrinter1.Porta := 'USB' - Tenta descobrir qual é a Primeira Impressora de Bobinas plugada na USB e faz uso dela, se encontrar.. ACBrPosPrinter1.Porta := 'USB:Elgin' - Tenta conexão em alguma Impressora USB, listada como sendo do Fabricante 'Elgin' ACBrPosPrinter1.Porta := 'USB:Sweda, SI-300S' - Tenta conexão na Impressora USB, do Fabricante "Sweda" e do Modelo "SI-300S". ACBrETQ1.Porta := 'USB' - Tenta descobrir qual é a Primeira Impressora de Etiquetas plugada na USB e faz uso dela, se encontrar.. ACBrETQ1.Porta := 'USB:Zebra, GC420t' - Tenta conexão com a Impressora USB do Fabricante "Zebra", e modelo "GC420t" Observe que essa nova implementação é totalmente diferente do método de Hook, onde usávamos a DLL do Fabricante, como túnel USB... Nesse novo cenário a comunicação USB é feita diretamente usando a API do Windows, ou seja, sem necessidade de DLLs externas. Para compreender um pouco mais, sobre esse método veja esse artigo O método de Hook ainda está disponível, usando o prefixo de porta, 'DLL:' Como os Equipamentos são identificados ? Todo Equipamento USB, possui um código de identificação do Fabricante, chamado de Vendor ID (VID), e também do Produto chamado de Product ID (PID). Essa numeração é controlada pela USB.ORG, e você pode encontras uma lista de Todos os "Vendors ID", nesse link A classe TACBrUSBIDDataBase, mantêm um Banco de Dados interno, chamado ACBrUSBID.ini, com o mapeamento dos principais Equipamentos do Mercado Brasileiro.. Esse Banco de Dados é um simples Arquivo do tipo INI, que é compilado como resource e adicionado ao componente... Clique aqui para ver o layout do Banco de Dados no Formato INI, observe os comentários no inicio do arquivo, com algumas instruções de como inserir novos equipamentos nele. Se você distribuir o arquivo ACBrUSBID.ini, na mesma pasta do Executável da sua aplicação, a classe TACBrUSBIDDataBase fará uso desse arquivo, ao invéz de usar o resource interno... Isso pode ser muito útil para atualizar a lista de Dispositivos conhecidos, sem necessitar compilar uma nova versão do programa, apenas atualizando o ACBrUSBID.ini Como posso listar os equipamentos identificados pelo ACBr ? Use a Força, leia os fontes... Vamos ver trechos de código, do Demo PosPrinterTeste {$IfDef MSWINDOWS} // Os métodos abaixo, somente estão disponíveis para compilação em Windows // Carrega a lista de Impressoras detectadas em: ACBrPosPrinter1.Device.WinUSB.DeviceList ACBrPosPrinter1.Device.WinUSB.FindUSBPrinters(); // Varre a lista de Impressoras USB detectadas, e adiciona as mesmas, nas opções de Porta for K := 0 to ACBrPosPrinter1.Device.WinUSB.DeviceList.Count-1 do cbxPorta.Items.Add('USB:'+ACBrPosPrinter1.Device.WinUSB.DeviceList.Items[K].DeviceName); {$EndIf} Como o ACBr nomeia os dispositivos ? O "DeviceName" será calculado, de acordo com as informações disponíveis no banco de Dados... Primeiro o ACBr usa a API do Windows para captura informações do VID (Vendor ID ou Fabricante) e o PID (Product ID ou Modelo), dos Equipamentos listados... Se o ACBr falhar nessa tarefa, o equipamento será ignorado (não será listado) Se for capturado com sucesso a descrição em FriendlyName, então ela será usada.. Caso contrário, o ACBr tentará compor o nome, baseado no VID e PID Se o VID do Fabricante for encontrado na sessão [Vendors] de ACBrUSBID.ini, então o VID será substituído pela Descrição do Fabricante... Observe que na sessão [Vendors], temos vários fabricantes que não são conhecidos no mercado Brasileiro, mas são de equipamentos OEM, de Empresas nacionais... Nós procuramos manter o nome Original do Fabricante, de acordo com a tabelas de VID da OSB.ORG Se o VID não tiver equivalência na relação de [Vendors] de ACBrUSBID.ini, então ele será listado com o próprio número VID, que são 4 algarismos em Hexadecimal... Exemplo: "0b1b" Procuramos pelo PID do Equipamento, na sessão específica do Fabricante. Se não houver uma chave com o PID, então o ACBr usará o próprio número PID, para Nomear o Modelo. O PID também é composto do 4 algarismos em Hexadecimal... Exemplo: "0001" Se encontrar uma entrada com o PID, dentro da sessão do Fabricante, então o ACBr usará a Descrição do Modelo, e poderá desprezar a descrição do Fabricante, se a Descrição do modelo possuir uma vírgula, Exemplo: 7008=Elgin, I9;1;1... Nesse caso será desprezada a descrição do Fabricante "20d1-Dascom" e será usada apenas a descrição do Modelo, "Elgin, I9". Detecção automática de Porta e Protocolo Como agora temos um Banco de Dados, que informa além da Descrição do equipamento, qual é o Tipo do mesmo e qual o protocolo que ele usa, então os componentes ACBrPosPrinter e ACBrETQ, podem fazer uso dessas informações... Ou seja, se o equipamento for detectado com sucesso, no momento da Ativação da Porta (durante a chamada ao método "Ativar"), será usado o Protocolo Definido no Banco de Dados. Se for detectado que o equipamento USB é na verdade uma porta COM virtual, então o ACBr irá preferir fazer uso da Porta COM virtual, chaveando para mesma, de forma transparente... Pois dessa forma ele tem um melhor suporte a leitura de informações do equipamento. Se for detectado que a porta USB possui um equipamento incompatível com o componente em questão, isso também será alertado... Exemplo, você tentar conectar em uma porta 'USB:Zebra, GC420t' no componente TACBrPosPrinter, então um erro será emitido, pois esse equipamento não é uma impressora de Bobinas Como a mágica funciona ? Reparem que foi adicionado ao repositório a Unit ACBrWinUSBDevice.pas, essa Unit implementa chamadas a SetupAPI do Windows, para detectar os Dispositivos USB que estão listados em uma determinada Classe de Equipamentos (Class GUID)... O estudo desse artigo, foi fundamental, para a criação dessa Unit. Uma vez capturada o nome da Interface do Equipamento USB (em TACBrUSBWinDevice.DeviceInterface), podemos acessá-lo usando funções de manipulação Arquivos da API do Windows, como: CreateFile, WriteFile, ReadFile. Nem todos os dispositivos USB implementam suporte aos métodos ReadFile ou WriteFile... ou seja, pode não funcionar em alguns dispositivos.. Se você souber qual é o nome da Interface USB do equipamento, poderá informar ela diretamente na propriedade "Porta" dos componentes... Exemplo: ACBrPosPrinter1.Porta := '\\?\usb#vid_1c8a&pid_3002#0000000000022#{28d78fad-5a12-11d1-ae5b-0000f803a8c2}'; Para dúvidas, suporte ou correções, por favor crie um novo tópico, clicando aqui Para testar, baixe uma nova versão do PosPrinterTeste.exe

Bom dia. Em entrevista para o Campo Grande News, o secretário do Estado de Fazenda, Felipe Mattos, informou mais detalhes sobre a implementação do programa Nota MS Premiada. Veja um trecho relativo ao prazo de implementação O decreto também dará prazo de até 30 dias para empresas adequarem seus sistemas de emissão de notas para que o cupom saia com CPF (Cadastro de Pessoa Física) do contribuinte e dezenas para sorteio. “O sistema da Sefaz já está adequado, mas temos de dar um prazo. Só que quem já fez a mudança emitirá a partir de 1º de janeiro notas que entrarão no sorteio”. Fonte: https://www.campograndenews.com.br/economia/1o-sorteio-de-premio-para-consumidor-que-exigir-nota-fiscal-sera-em-fevereiro

ola, tem colocar o cnpj do responsavel pela o RNTC.