Painel de líderes

Interesso, sim, em contribuir com o projeto, realizando os testes e validação do mesmo. como devo proceder?

Boa tarde Por algum motivo, o componente estava vindo com alguma sujeira. Coloquei o ACBRNFe.NotasFiscais.Clear e o problema foi sanado.

Bom dia Ângelo, Muito obrigado pela colaboração, assim que possível vou enviar para o repositório. Observação, lembre-se que quando incluir um novo campo devido a uma alteração no layout do evento, além de incluir a linha que vai gerar esse campo no XML, devemos também incluir a leitura desse campo na função: LerArqIni. Essa função é utilizada pelo ACBrMonitor (aplicativo utilizado por desenvolvedores que não utilizam Delphi e Lazarus) para ler o arquivo INI de um evento.

Terá problemas (rejeição)... Já que o estado ainda não está preparado para receber essa informação.

Bom dia Sergio, o interessante é você consultar um analista contábil pra te ajudar nesse quesito, ele saberá (ou ao menos deveria) responder todos seus questionamentos acerca do assunto com maior exatidão. Há várias regras e situações diferentes para cada empresa, então fica complicado lhe passar como são feitos os cálculos sendo que pode resultar em problemas futuros, ao menos em minha opinião, não é mesmo? Abraço

Boa noite Italo, obrigado pela resposta..na verdade minha dúvida era se a UF estava realmente validando o conteúdo, aparentemente sim..obrigado mais uma vez.

No teu XML falta a versão do evento. with ACBrCTe1.EventoCTe.Evento.New do begin infEvento.cOrgao := 41; infEvento.versaoEvento := '1.00'; Tanto cOrgao quando a configuração ACBrNFe1.Configuracoes.WebServices.UF deve ser a UF do emitente do CTe, no caso, o PR.

O evento de cancelamento vem sem a manifestação do destinatário. Então supondo do exemplo que o destinatário recebe o resumo hoje com a situação da nota autorizada e no outro dia o emitente cancela essa NFe. Será gerado um novo NSU com o evento de cancelamento e o mesmo será disponibilizado para o destinatário mesmo que ele ainda não realizado nenhum evento de manifestação. Como pode ver nesse exemplo: Abaixo vou deixar um trecho de como conseguir capturar o evento de cancelamento no momento que estiver processando os NSU's. for i := 0 to Pred(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count) do begin LDocZip := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[i] if (LDocZip.schema = schprocEventoNFe) then begin if LDocZip.procEvento.RetinfEvento.tpEvento = teCancelamento then begin Justificativa := LDocZip.procEvento.detEvento.xJust; Data := LDocZip.procEvento.RetinfEvento.dhRegEvento; Protocolo := LDocZip.procEvento.RetinfEvento.nProt; end; end; end;

Mas se ele é consumidor final, e você informou a inscrição estadual IEDest, e na tag IndIEDest= 9 ( Não contribuinte). <indIEDest>9</indIEDest> --> Esta definido como não contribuinte <IE>407069960117</IE> --> Porém foi informada a Inscrição Estadual Dercide.

Para saber mais como tratar a contingência, na NFCe, vejam essas dicas abaixo... Nessas palestras que fizemos em conjunto com a Elgin, existe uma apresentação, com Download Livre... (baixe o arquivo Apresentação - ACBr - Elgin - ACBrNFe.pdf) Na 2a Edicao do Dia do ACBr, nosso Consultor @José M. S. Junior, ministrou uma excelente palestra sobre o assunto... Veja o vídeo no nosso Canal do YouTube No Curso Completo do ACBrMonitPlus, @José M. S. Junior, também tem aulas específicas sobre a Contingência Off-line https://www.projetoacbr.com.br/forum/video/browse/39-aula-26-contingencia-da-nfe-e-nfce/ Se você é usuário do SAC do ACBr, creio que esse vídeo de um Webinar, ministrado por @André Ferreira de Moraes, responderá todas as suas dúvidas...

Há uns 6 anos atrás achei isso: tão verdade...

Boa tarde, Essa configuração é sugerida para que utiliza certificado A3, se você utiliza A1 aconselho configurar com libOpenSSL, desta forma você fica livre de qualquer configuração e atualização do Windows.

Meu Deus... que vergonha..... deu certo, muito obrigado Italo.

Além da configuração indicada pelo Italo, veja também o seu arquivo ACBrNFeServicos.ini, se contém as URL para a versão 4.00 da NFCe.

Resolvido conforme exemplo abaixo, passando o campo DT_FIN_OP apenas quando houver conteúdo: If (DataFinalizacao <> '') then DT_FIN_OP := StrToDate(DataFinalizacao ) ; Obrigado!

Pessoal, sendo tratado aqui: Podem encerrar este tópico por favor.

Boa tarde! Quero agradecer enormemente ao Italo e ao Big Wings pela atenção e ajuda dispensado ao meu problema. Consegui emitir o manifesto. Obrigado a todos.

realmente era esse problema

Bom dia Chagas, Notei que o XML esta sendo gerado segundo a versão 4.00, mas pelo XML de retorno a versão do aplicativo da SEFAZ responsável pela recepção da nota é da versão 3.10, muito estranho. Verifique a configuração do componente, o atributo VersaoDF tem que ter o valor ve400. Outra coisa, futuramente as suas notas vão ser rejeitadas, motivo: você esta atribuindo o numero da nota ( nNF ) ao código da nota ( cNF ). Leia a Nota Técnica 2019/001.

Bom dia, Pela mensagem de erro diz que o grupo Endereço esta incompleto, segundo a mensagem esta faltando a UF, e o e-mail esta invalido.

Curioso né? Bom Italo, vou seguir por aqui então tentando viabilizar o serviço. Obrigado pelo retorno.

Fernando, Com certeza deve ser uma exceção, inclusive existem nesse Webservice serviços que eu nunca tinha visto.

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.

Bom dia. Seus fontes estão atualizados? Não tivemos relatos recentes deste problema. Att.

Bom dia. Você deve verificar se estas UFs permitem este tipo de documento, eu tenho conhecimento somente de Manaus e do DF. Att.

Bom dia Julio, Muito obrigado pela colaboração, assim que possível vou enviar para o repositório.

Validações a critério da UF significa que o estado pode ou não aderir aquela regra/validação. Nesse caso a forma mais correta é entrando em contato com a SEFAZ do estado e verificando com eles o que vão implementar. Pode ainda verificar se há algum boletim informativo no site da SEFAZ de cada estado com essa informação. O grupo do responsável técnico (uma das novas implementações da nota técnica) foi muito discutido aqui no grupo e com isso foi criado uma "aba" no mapa fiscal do ACBr. De uma olhada lá e você verá quais serão os estados que irão implementar. Sobre as demais validações, recomendo também dar uma pesquisada aqui no fórum. Pois em alguns casos alguém já fez esse contato com a SEFAZ do estado e já obteve a resposta se a validação X será implementada para aquele estado. Uma dica é: deixe seu software inteiramente compatível com a Nota Técnica em questão. E nas validações que são a critério da UF, você cria parâmetros, por exemplo: "Enviar grupo responsável técnico" (Sim ou não) dessa forma se amanhã ou depois algum estado aderir, basta você marcar essa opção no seu sistema.

Olá, Eu acabei de enviar ao SVN (revisão 17083) uma correção para os ECF de modelos que utilizam o protocolo ESCECF, FiscNet e Epson. Você pode atualizar o seu código e testar novamente. Queira, por favor, reportar qualquer problema.

Bom dia. O correto é informar 17 na propriedade carteira e 019 em Modalidade. Att.

Bom dia Você chegou a testar no demo? Att.

Bom dia, Veja neste tópico que já foi enviada uma contribuição para este caso, porém precisava uma análise mais detalhada, de modo a ser funcional para todos os geradores. Att.

O código atual faz o esperado, caso seja configurado a versão do componente como veqr000 e usada versão 4.00 do XML, ele será ajustado para veqr100. Para usar o QrCode 2.00, basta configurar a propriedade ACBrNFe1.Configuracoes.Geral.VersaoQrCode = veqr200. Com a sua alteração fica impossibilitado o uso do QrCode 1.00 (que não é mais usado, mas mantido por compatibilidade, para recriar um XML antigo, por exemplo).

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

Boa noite Carlos, Primeiramente MDF-e não é uma nota. Segundo, pela chave o numero dele é zero e não 278.

Boa tarde Moroni, Estou anexando uma nova versão do Manual do DAMDFE que inclusive vai ter QR-Code. Manual MDFe Anexo II DAMDFE v3.00a.pdf Note que no DAMDFE para transporte rodoviário (normal) não é impresso a lista de CT-e/NF-e e muito menos os dados referente ao Seguro. Só no DAMDFE em contingência que é impresso a lista de CT-e/NF-e. Não sei porque existem pessoas que ainda ficam focadas no papel, sendo que o XML tem todas as informações necessárias.

A configuração do ACBrMonitorPlus não só se resume na parametrização dos arquivos de entrada e saída. Requer assinatura, código de ativação, etc. Entre em contato com o fornecedor desse software: https://www.bling.com.br/contato

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

Boa tarde Italo, Agora passou. O problema estava mesmo no CNPJ. Muito obrigado pela ajuda.

Está confundindo causa/efeito. O XML com a tag nfeProc é montado pelo ACBrNFe após o recebimento do protocolo de autorização, ele não é o XML enviado para o webservice. Configure o componente para gravar os arquivos de envio e retorno e anexe aqui os arquivos *-env-lot.xml e *-env-lot-soap.xml onde houve a rejeição.

Sim vou postar obrigado pela atenção e dica! Solução que encontrei foi bem simples, minha variável fDataProtesto eu tinha criado ela como String, bastou eu alterar ela para TDate, que funcionou tudo certo. Obrigado ACBR.

Bom dia, joao.becker. Mas qual a mensagem de erro?

Bom dia Volmir, Foram feitos algumas alterações nos arquivos INI de diversos provedores. Verifique se no seu cliente o arquivo Betha.ini esta atualizado.

Bom dia, de acordo com as informações que temos, MG por hora não irá validar as informações. https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico

Resolvido com a dica do amigo @BigWings Obrigado. Charles

É um problema conhecido. Quando você não define o espaçamento entre linhas o PosPrinter usa o espaçamento padrão da impressora, mas o componente não conhece esse valor. Então na impressão do QRCode lateral e informação do consumidor, é usado a altura do QRCode como altura máxima dessa região. Como o QRCode agora está reduzido acaba cortando as informações do consumidor + NFCe. Para resolver você só precisa informar um espaçamento entre linhas: ACBrNFeDANFeEscPos1.PosPrinter.EspacoEntreLinhas := <xxx>; Alterar a disposição das informações do consumidor e identificação da NFCe vai contra o manual de especificações do DANFe NFCe e QrCode.

Opa! Então, para cada rubrica com incidência de IRRF 51, 52, 53, 54 ou 55 o grupo <penAlim> deve ser informado, nas demais o grupo deve ser omitido. Geralmente temos somente uma rubrica de pensão para cada demonstrativo do empregado. Se você tiver mais de uma talvez seja interessante junta-las. Assumindo que você é o desenvolvedor do programa e de todo modo precisa ter várias rubricas de pensão, o beneficiário deve ser informado para cada uma rubrica no xml, mas no seu programa você pode realizar esse vinculo somente uma vez e quando for gerar o evento busca esse vinculo e repete para cada uma. Como são dados cadastrais não vejo como poderia interferir em algum totalizador. É interessante que os valores do campo <vlrPensao> corresponda aos valores das rubricas, no meu caso o valor da rubrica e o valor da pensão foi sempre o mesmo. As rubricas de pensão alimentícia devem ser informadas porque interferem na formação da base de calculo do IRRF, então se você esta se referindo a totalizações que o sistema do e-Social faz, acho que o valor das rubricas que são importantes. Acredito que esses dados estão sendo solicitados mais para fazerem algum tipo de cruzamento de informação com a declaração do IR ou algo do tipo, para efeito de cálculo e fechamento da folha, o que vale é o valor da rubrica.

Boa tarde Adilson, A mensagem é clara, o RPS não foi aceito por já existir outro com o mesmo numero, serie e tipo. É preciso descobrir qual foi o ultimo RPS enviado para dar continuidade na numeração.

Responsável Técnico - Como fica o XML na prática? Com tantas alterações, ficou um pouco confuso entender quando e quais tags do grupo Responsável Técnico deverão ser enviadas. Segue então um resumo. Até 02/06/2019 Os XMLs deverão ser enviados sem este grupo, como tem sido feito até então. A partir de 03/06/2019 Para as UFs do AM, MS, PE, PR, SC e TO deverá ser incluído o grupo Responsável Técnico, porém sem as tags relativas ao idCSRT. Veja imagem a seguir. Após definição de data para exigência do idCSRT Quando as SEFAZ publicarem as datas para exigência destas tags, as mesmas passarão a ser exigidas no XML, caso contrário os mesmos passaram a ser rejeitados. A seguir, exemplo de XML com o grupo Responsável Técnico completo. Importante Até o presente momento nenhuma SEFAZ disponibilizou os mecanismos para geração do idCSRT, logo mesmo em homologação não é possível enviar estas tags. A partir de 07/05/2019 as UFs que optaram pela exigência do Grupo do Responsável Técnico ( AM, MS, PE, PR, SC e TO ), já aceitaram as tags de identificação também em ambiente de produção, porém rejeitarão os XMLs sem estas tags somente em 03/06/2019.

Boa tarde. Seria importante citar também qual foi a resolução do seu problema, de forma a auxiliar os demais usuários no futuro. Att.