Painel de líderes

Bom dia, Quando uma nota é enviada e ocorre algum erro, a primeira providencia a ser tomada é realizar uma consulta, pois não sabemos se o erro ocorreu no envio ou no retorno da SEFAZ. Se o erro ocorreu no retorno, a consulta vai nos informar o resultado do processamento, se a nota estava correta, será retornado o protocolo de autorização. É interessante ao realizar essa consulta, estarmos com o XML da nota carregado no componente, pois se for retornado o protocolo de autorização o XML será atualizado automaticamente, com isso podemos imprimir o DANFE. Por outro lado se o erro ocorreu no envio, a consulta vai nos retornar que a nota não consta na base de dados. O que fazer neste caso? Podemos tentar novamente o envio ou inutilizar o numero da nota cujo envio não ocorreu por falha na SEFAZ e por fim enviar a nota pelo SAT (contingência da NFC-e) no Estado de São Paulo.

Por favor veja esse tópico:

Boa tarde Giovani, O seu código deve ficar da seguinte forma: infRespTec.CNPJ := CNPJ da empresa de software infRespTec.xContato := meu nome infRespTec.email := meu email infRespTec.fone := meu telefone Lembre-se configurar o componente é uma coisa, alimentar com os dados da venda é outra. As 4 linhas acimas devem ser incluídas na rotina que alimenta o componente. Já as linhas abaixo devem ser incluídas na rotina que configura o componente. // Enquanto o desenvolvedor não tiver o seu CSRT deverá configurar // as propriedades IdCSRT e CSRT conforme exemplo abaixo. ACBrNFe1.Configuracoes.RespTec.IdCSRT := 0; ACBrNFe1.Configuracoes.RespTec.CSRT := '';

Pessoal boa tarde, Acabei de receber uma mensagem da SEFAZ que o cancelamento de NFC-e foi normalizado. Tentei efetuar um cancelamento aqui em ambiente de Homologação e foi normalmente.

Pessoal, aqui voltou a funcionar. abraço.

Boa tarde, Tairone. Qual a Sefaz? Qual o sistema operacional e a versão? Todas as atualizações do windows estão instaladas? Tente com a configuração abaixo: SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsLibXml2; SSLType := LT_TLSv1_2;

Prezado @BigWings, Concordamos com a sua colocação que o valor deste campo não deveria ser zerado, mas nenhum fornecedor informa este valor para que possa ser armazenado e posteriormente emitido e temos várias situações, como mercadorias em estoque que não possuem essa informação e não haverá informação até que exista uma entrada ou que o contador se responsabilize pela definição. (Inclusive há várias entidades discutindo com as SEFAZ sobre este campo) Então para atender a RV, da forma como a mesma está hoje na NT 2018.005 v1.20 será necessário gerar da mesma forma como o colega @GustavoCamargo fez.

Obrigado por ajudar, vou esperar o horário q voltar a dar time out e vou por essas configurações, ai breve dou um feedback.

O gerenciador gpTefDial funciona diferente do gpCliDTEF. O gerenciador gpTefDial funciona por troca de arquivos como era comum há alguns anos quando a maioria dos comércios usavam TEF discado. Talvez eles tenham atualizado a aplicação TEF e alterado o modo do gerenciador trabalhar e por isso parou de funcionar. Independentemente disso, quaisquer um desses eventos são demonstrados nos aplicativos de exemplo. Você pode verificar a implementação neles. Mas aqui vai uma explicação rápida: OnObtemInformacao é um evento que trata as situações onde o Gerenciador do TEF está obtendo as informações do usuário. Então você deve criar uma tela para obter essa informação do usuário e retornar ao gerenciador TEF. Por exemplo: Qual a senha do Administrador? Em quantas vezes vai dividir? Qual o valor da taxa de embarque? Etc... ExibeMenu é um evento que gera para o usuário um menu com várias opções para que ele escolha uma. Assim você deve criar uma tela que mostre as opções e permita ele escolher uma. Por exemplo: É Crédito, Débito, Alimentação? É parcelado ou a vista? Dá uma olhada no aplicativo de exemplo que deve ficar claro como é simples fazer uma implementação dessas.

Bom dia, Geová. Sugiro que não utilize Capicom pois a mesma já está obsoleta, tente a configuração abaixo: SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsLibXml2; SSLType := LT_TLSv1_2;

Bom dia Giovani, Não, a propriedade é CSRT. Temos duas propriedades de configuração: idCSRT e CSRT. Dentro do grupo <infRespTec> temos dois campos: idCSRT e hashCSRT. O campo idCSRT recebe o mesmo valor da propriedade de configuração idCSRT. Já o campo hashCSRT é gerado da seguinte forma: O hashCSRT é o resultado da função hash (SHA-1 – Base64) do CSRT fornecido pelo fisco mais a Chave de Acesso da NFe. Abaixo temos a procedure que gera o grupo <infRespTec> da NF-e: procedure TNFeW.GerarinfRespTec; begin if (nfe.infRespTec.CNPJ <> '') then begin Gerador.wGrupo('infRespTec', '#081'); Gerador.wCampoCNPJ('#82', nfe.infRespTec.CNPJ, CODIGO_BRASIL, True); Gerador.wCampo(tcStr, '#083', 'xContato', 02, 60, 1, nfe.infRespTec.xContato, DSC_XCONTATO); Gerador.wCampo(tcStr, '#084', 'email ', 06, 60, 1, nfe.infRespTec.email, DSC_EMAIL); Gerador.wCampo(tcStr, '#085', 'fone ', 07, 12, 1, nfe.infRespTec.fone, DSC_FONE); if (idCSRT <> 0) and (CSRT <> '') then begin Gerador.wCampo(tcInt, '#086', 'idCSRT ', 02, 02, 1, idCSRT, DSC_IDCSRT); Gerador.wCampo(tcStr, '#087', 'hashCSRT', 28, 28, 1, CalcularHashCSRT(CSRT, FChaveNFe), DSC_HASHCSRT); end; Gerador.wGrupo('/infRespTec'); end; end; Note que o valor do campo hashCSRT é o resultado retornado pela função CalcularHashCSRT que recebe como parâmetros a propriedade CSRT e a chave da NF-e.

Bom dia, Acredito que esteja ocorrendo uma confusão. O método Enviar do Monitor não se utiliza do Consultar, isso se explica o envio ocorrer sem nenhum problema. Por outro lado o método Cancelar se utiliza do Consultar para saber se a nota foi enviada e autorizada antes de solicitar o seu cancelamento. Se a SEFAZ esta com algum problema no serviço de consulta o método Cancelar do Monitor vai falhar. Para tirar essa duvida é simples, basta enviar uma nota e depois tentar consultar, se ocorrer erro concluímos que o serviço de consulta esta com problemas.

Obrigado

Que isso. Agradecemos o retorno. Bom trabalho por aí.

Boa tarde. Talvez este video possa lhe ajudar. Att.

Olá, Esse código não parece ser do componente de SAT. Poderia verificar onde está definida essa variável 'AliqICMS' e qual o tipo dela? Pois ela parece estar definida como Integer.

Adicionei duas novas informações na classe ACBrTEFDClass. TipoDeCartao Voucher Unit anexo, se for possivel adicionar ao repositório. ACBrTEFDClass.pas

Olá, Acho que não tem uma regra sobre isso. Na verdade o roteiro para NFC-e, até onde me lembro, é exatamente o mesmo para impressoras não fiscais. Contudo, eu sugiro você confirmar a transação TEF primeiro. Assim, caso o pagamento TEF não seja confirmado você não precisará alterar/cancelar a NFC-e que já transmitiu. Imagine que o cartão não passe e você já transmitiu a NFC-e com a forma de pagamento tipo TEF? Ainda tem que você precisa preencher alguns dados da NFC-e com detalhes da transação que só vão estar disponíveis depois. Além disso, caso tenha que fazer algum tratamento de contingência, a parte do TEF já foi confirmada. Acho que você poderia usar o evento onDepoisConfirmarTransacoes pra esse objetivo. A lista de respostas pendentes é adicionada na ordem que são feitas as chamadas. Então a última da lista é a última que foi feita... Você pode dar uma olhada nos seguinte tópico e no tópico que ele menciona: Se não estiver usando o SiTef tem outros tópicos sobre o assunto como: e também esse: https://www.projetoacbr.com.br/forum/topic/37672-como-capturar-os-dados-do-acbrtefd/

Realmente Ítalo, eu tava "mosquiando nessa". Mais uma vez obrigado pela atenção.

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

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

Boa tarde. Alteração já está no svn. Att.

Boa tarde, Muito obrigado pela correção, já enviei para o repositório.

Boa tarde, O que de fato você esta tentando fazer? O XML que você anexou se refere ao XML de uma NFS-e. Já a tag </Pedido> que você informou na sua primeira postagem (que diga-se de passagem no lugar errado: lugar postado ACBrCTe, lugar correto ACBrNFSe) aparece no pedido de cancelamento. Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção para apagar os arquivos antigos marcada? Se sim, esta fazendo testes com o programa exemplo? Esta usando os arquivos INI que se encontra na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

Boa tarde. Observe o anexo único na legislação indicada por você, lá você observará que este ultimo arquivo é gerado pelo programa validador. 8.1. Para cada volume, o Programa Validador de Arquivos criará um arquivo de controle e identificação, que será composto por um único registro, com as seguintes informações: Att.

Boa tarde Juliana, Vou verificar esses dois eventos. Costa, você trabalha com qual linguagem? O ACBrMonitor é destinado aos desenvolvedores que não utilizam o Delphi ou Lazarus.

Por favor, anexe o log.txt do ACBrMonitor para que possamos analisar o erro. Pode ser erro específico da SEFAZ do Estado, pois em testes esse erro não ocorre...

Boa tarde. @Italo Jurisato Junior pode por favor verificar se os eventos 2221 e 2245 falta apenas implementar no ACBrMonitor? Att.

Boa tarde, jfscosta. Veja abaixo os eventos já implementados: https://acbr.sourceforge.io/ACBrMonitor/eSocialCriarEventoeSocial.html

Eu preciso resgatar essas informações pra armazenamento e posteriormente fazer conferencia/conciliação dos cartão.

Boa tarde. Qual foi a necessidade destas alterações? Att.

Boa tarde. Por favor anexe seu xml. Att.

Bom dia. Por favor descreva seu problema ou sugestão...somente anexar os arquivos dificulta nossa análise. Att.

Bom dia Márcio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório. Apenas um detalhe os seus fontes estão desatualizados.

Ok, vou tentar aqui, obrigado pelo retorno.

Bom dia, É que na verdade, no arquivo do sistema antigo do meu cliente vai essa informação... e no manual do bradesco diz o seguinte: 094 a 094 – Condições de Registro para Débito Automático  Quando igual a “N” e os dados do débito estiverem incorretos, rejeita o registro na cobrança e não emite Boleto de cobrança;  Quando diferente de “N” e os dados do débito estiverem incorretos, registra na cobrança e emite Boleto de cobrança. Nesta condição, não ocorrerá o agendamento do debito. Como no arquivo atual dele está indo N eu achei que tivesse a opção de configurar para mandar de acordo com a situação do momento... mas vou verificar se realmente precisa manter o N ou posso mandar em branco. obrigado Anselmo

Verifica no portal do e-Social, pesquisa pelo CPF e verifica se o vínculo já consta na base do governo

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

Acabei de atualizar o ACBr e funcionou !! Estranho é que tinha atualizado dia 18/03... Acho que vou passar a atualizar todos os dias ehehhehe

Veja bem, o seu log diz que a compilação do ACBr_Comum foi "um sucesso". Veja o log apenas a parte relevante: 29921 lines, 0.30 seconds, 121624 bytes code, 14861 bytes data. Compilation success Pacote "ACBr_Comum.dpk" compilado com sucesso. Então, pelo menos em teoria, o arquivo BPL deveria estar sendo criado. Mas se isso não está acontecendo, então você não vai conseguir compilar os outros pacotes pois eles dependem do ACBr_Comum. Talvez tenha que começar a avaliar se seu Delphi está instalado corretamente, se não está com algum conflito com o sistema operacional, se algum antivírus ou antimalware não está entrando em conflito. Em último caso, tente compilar e instalar os pacotes manualmente.

Meu Deus. me perdoe, realmente é uma variável minha. Muito obrigado mesmo, já não estava visualizando mais nada. Obrigado e poderia fechar o topico.

Boa tarde. Você se refere a qual gerador de relatórios? e Qual DFe? Att.

Boa tarde. Veja este tópico Att.

Boa tarde. Este erro aparenta haver mais de 240 colunas em seu arquivo, por favor anexe seu arquivo ou faça um teste no demo e anexe o mesmo (caso o erro persista). Att.

Boa tarde Robson, esse erro indica que o arquivo está com tamanho inválido... foi alterado manualmente? Se persistir anexe o arquivo para verificação. Referente ao nosso número, todos os usuários do transmitem o arquivo dessa forma, por isso precisamos saber se há alguma rejeição no validador do banco (site) para podermos alterar...

Informe as suas configurações da propriedade TDFeSSL.

Bom dia. MG está com problemas para emissão de qualquer DF-e. Na parte da manhã, ainda se conseguia emissão por SVCAN, mas não está funcionando mais. O portal Estadual de MG e o SIARE também se encontram fora do ar. Não há absolutamente nada a fazer por parte do ACBr. Temos que aguardar que os serviços sejam disponibilizados. Infelizmente podemos perceber que no portal da NFe todos os serviços de MG estão em verde o que não representa a realidade.

Atualizado em: 05/11/2019 - Revisado em: 11/11/2021 Documentos Aceitos Atualmente NFCe ECF 85 NF de Venda ao Consumidor(Mod. 2) Detalhamento da Situação por Tipo de Documento NF de Venda ao Consumidor (Mod. 2): Em vigor, com uso após adesão voluntária ou ou por obrigatoriedade terminando em 28/02/2020 quando utilizada exclusivamente para acobertar as operações fora do estabelecimento e 31/07/2021 para os demais contribuintes, considerando-se o último grupo de obrigatoriedade da NFCe. ECF 85: Em vigor (inclusive realizando lacração e autorização de uso). Uso após adesão voluntária ou por obrigatoriedade da NFCe é vedado. Veja abaixo sobre NFC-e. O uso de ECF deve terminando em 30/04/2022, considerando-se o último grupo de obrigatoriedade da NFCe (9 meses de uso após início da obrigatoriedade). ECF 09/09: Não aceito. NFCe: Calendário de obrigatoriedade se inicia em 01/03/2019 para novas empresas, com último grupo entrando em 01/08/2021. Adesão voluntária permitida a partir de 01/03/2019. Veja também: RESOLUÇÃO Nº 5.234 DE 5 DE FEVEREIRO DE 2019 SAT: Signatário, porém SEM legislação regulamento sua implantação. MFE: Não aceito Situação Responsável Técnico Conforme resposta obtida por meio do Fale Conosco da SEFAZ-MG e compartilhada conosco pelo usuário @pablozamba, a SEFAZ-MG não exigirá as informações relativas ao responsável técnico. Situação PAF-ECF: UF não exige laudo de homologação, porém determina que a solução seja compatível a legislação própria da UF, a qual gerou documentos de compatibilidade de requisitos entre as ERs do PAF-ECF e a legislação mineira (PORTARIA SRE Nº 132, DE 24 DE ABRIL DE 2014). Para uma visão geral dos documentos fiscais em todas as Unidades da Federação acesse nossos Mapas Fiscais. Para obter o guia de cadastro/credenciamento de sua Aplicação Fiscal junto ao SEFAZ, acesse nossa sessão de Downloads, os Requisitos Fiscais por UF.

Não sei o que você está tentado fazer. Mas vamos por partes: 1 - Para SIMPLES NACIONAL CRT=1 não há destaque de ICMS como vc informou no teu arquivo. Base de cálculo de ICMS. 2 - Para casos específicos de operação que tenha o destaque (regulamento por lei), usar o CSOSN 900. (Estude sobre ele) 3 - O caso que vc comenta sobre IPI eu suspeito que vc está falando de nota de devolução para o fornecedor. Estude o manual da versao 4.00 do XML pois foi incluído um campo vlIPIDevol para controle da devolução do IPI por empresas não contribuinte do IPI.