Painel de líderes

Já abre 2 chamados na sefaz, no primeiro, não prestaram atenção onde eu havia passado que a data estava correta ( estava presente e era maior que a data de emissão), e disseram que existia a validação. Depois passei outro email, contestando a resposta, e me pediram pra passar, xml de envio, xml de retorno, data e hora do ocorrido, etc... Eu respondi, apenas dizendo a eles para testarem o próprio ambiente, pois nenhuma empresa se de Software de SP esta conseguindo emitir nfe em homologação. Ta tenso isso, da impressão que uma hora o ambiente de produção vai nos deixar na mão, e ai vai sobrar pra quem ?. Caraca, acabei de postar e veio resposta da sefaz: Prezado contribuinte, Inicialmente agradecemos as informações fornecidas. Trata-se de um erro na execução da regra de validação Y09-20 que ocorre exclusivamente no ambiente de homologação externa da NF-e da SEFAZ-SP, gerando o indevido retorno de rejeição "900 - Data de vencimento da parcela não informada ou menor que Data de Emissão" em algumas situações. A previsão para solução do problema é até o final do dia 17/8/2018. Atenciosamente,

900-Rejeição: Data de vencimento da parcela não informada ou menor que Data de Emissão [nOcor: 2] Bom dia! Hoje dia 17/Agosto (Ainda sem solução da SEFAZ) Continuamos a receber a Mensagem de Rejeição acima na SEFAZ ambiente Homologação, verificamos que é apenas para o Estado de SP. Clientes operando normalmente no ambiente de Produção em todo Brasil. Ninguém merece!

Amigo isso não é problema do ACBR. O Banco SICREDI exige uma sequencia númerica para os números da remessas (você deverá controlar isso no seu sistema). Veja que ele diz: "No dia: 2 - No HEADER de arquivo: 1". Ou seja, ele espera a remessa 2 e você enviou a remessa 1. O Comando GerarRemessa já tem esse parametro BOLETO.GerarRemessa("c:\remessa\",1); // onde 1 é o número da remessa, aqui você deve passar o numero sequencial. Lembrando que quem controla essa numeração é o banco, exemplo, imagina que no seu sistema você controla isso, e seu cliente gera o arquivo de remessa e você irá fazer a sequencia 2, porém, seu cliente não envia esse arquivo para o banco. Depois esse mesmo cliente gera outra remessa e você faz a sequencia 3 e o cliente envia esse arquivo para o banco, ou seja, o banco espera o 2 e não 3. Mas é isso.

Boa tarde a todos, Teremos mudanças no layout do MDF-e, basicamente são quatro, a primeira é que agora será possível uma pessoa física desde de tenha Inscrição estadual emitir o MDF-e, sendo assim a propriedade CNPJ do emitente vai passar a se chamar CNPJCPF, a segunda se refere a consulta a Manifestos não encerrados que também vai aceitar o CPF sendo assim o campo passa a ser CNPJCPF, a terceira se refere ao modal aéreo que passa a ter um novo grupo <infEntregaParcial> e a quarta é o novo grupo chamado <infEmpresaSoft>. Este último grupo em um primeiro momento é opcional, ou seja, ele não precisa constar no XML, mas futuramente vai ficar a cargo de cada UF determinar a sua obrigatoriedade. Nesse grupo deveremos informar o CNPJ ou CPF do desenvolvedor, bem como o nome da empresa ou desenvolvedor, e-mail e telefone. O componente ACBrMDFe já foi alterado visando a geração desses grupos, estou apenas aguardando a liberação do ambiente de homologação para enviar para o repositório. Favor baixar e ler com atenção a Nota Técnica 2018/002 que se encontra no Portal Nacional do MDF-e. O Ambiente de Homologação vai ser liberado em 10/09/2018 e o de Produção em 15/10/2018.

Olá Pessoal, Eu e @André Ferreira de Moraes, estaremos a convite da Elgin, palestrando no Espírito Santo, sobre NFe/NFCe, Contingência off-line, QRCode, etc... Participe e conheça as novas soluções que o Projeto ACBr e a Elgin estão criando para tornar ainda mais simples, a implementação dessas novas funcionalidades no seu sistema... O Evento é gratuito, mas as vagas são limitadas... Faça já a sua inscrição... Data: 22 de agosto Horário: 8h30 às 13h Local: Hotel Golden Tulip Av. Nossa Senhora dos Navegantes, 635 Vitória - ES Clique na Imagem abaixo para fazer sua inscrição

Provavelmente sim, testei com o demo e ocorreu o mesmo erro, e aparentemente está tudo correto nas configurações e URL.

Veja que no demo tem a opção de você setar o caminho da pasta Schemas. with ACBrNFe1.Configuracoes.Arquivos do begin ... PathSchemas := edtPathSchemas.Text; ... end;

Oi Italo, funcionou. Muito obrigado.

Essa URL não está no formato do QRCode 2.00. Nesse formato o nVersao deve ser sempre 1. Aqui tem o manual da geração do novo formato do QRCode: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=/xyXbAFZ71k=

Bom dia Pedro, Clica no botão [Yes] para remover a referencia do método.

Provavelmente um problema com o cliente svn (Tortoise?). Experimente baixar novamente em uma nova pasta. Favor seguir as regras do fórum, para novo assunto abra novo tópico.

obrigado Sérgio, transmitiu de boa, vou usar desta forma, só um problema de "Falha ao localizar o nó de Assinatura", mas só em depuração, já vi no fórum para ignorar. Valeu pela ajuda!

Bom dia Obrigado, será corrigido... Se encontrar outras divergências, por favor poste aqui os fontes alterados, assim podemos atualizar no SVN...

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum. @Arthur Luz A sua dúvida não esta relacionada com o contexto desse tópico !

Opa, @Sérgio Assunção acredito que já descobri o problema, este cliente trocou de SAT e a numeração iniciou novamente, aí ao fazer o cancelamento, o SAT que está sendo enviado é o primeiro encontrado na lista, já vamos ajustar e passou detalhes.

Boa tarde Italo, realmente estava seguindo o manual e passado o campo nrInsc com 8, ao passar o campo nrInsc completo com 14 ou 11 vi que o ACBR identificou os 14 dígitos e foi corretamente. Obrigada!

Bom dia. Não compreendi o que precisa... Se é o banco que gera o boleto, por que necessita gerar novamente? Outro detalhe é que o componente também utiliza Modulo 11 para calcular o dígito (conforme especificação do manual) se tratando do mesmo número o dígito deveria ser o mesmo...

Bom dia Windel, Eu utilizo os componentes ACBr desde 2009, mais precisamente o ACBrNFe. Como foi eu que peguei o componente ACBrCTe (protótipo) e finalizei a ponto de deixa-lo funcional, estudei muito os fontes do ACBrNFe e não encontrei nada, nenhum comando que por ventura pudesse realizar uma operação de exclusão de certificado. Depois de muitos anos e vários relatos um membro do fórum descobriu que o responsável por essa exclusão na verdade é uma DLL do Windows (vide o link que o Daniel postou acima). Por favor peça para essa pessoal que constatou que o problema é em aplicações que se utilizam do ACBr, escrever um laudo sobre essa constatação e é claro assinar.

Bom dia, estamos passando por essa mesma situação. Data de emissão da NF: 16-08-2018 Data de vencimento da Dup.: 03-09-2018 Rejeição: 900 Acredito que isso está acontecendo somente em ambiente de homologação devido à algum erro de validação da Sefaz. Vamos aguardar...

O mesmo problema acontece aqui, já mudei o vencimento para o final do ano e o erro persiste apenas no ambiente de homologação. 900-Rejeição: Data de vencimento da parcela não informada ou menor que Data de Emissão [nOcor: 2]

Estou passando pelo menos problema, somente em ambiente de homologação. pelo manual a Rejeição se dá quando a data de vencimento da parcela é menor que a data de Emissão e/ou a data de autorização e/ou a data da parcela anterior, mas no meu caso eu só tenho uma parcela, com data de emissão/autorização hoje e o vencimento da parcela para o dia 30/08, não vejo outra situação a não ser problema na validação da Sefaz. ficarei no aguardo.

Boa tarde a todos, Foi realizado testes e existe usuários com o mesmo erro. No meu intendimento, existe uma falha na Sefaz, somente para ambiente de homologação. Sugiro que entre em contato com a mesma para obter mais detalhes ou solução do problema.

Boa tarde, Ontem estava testando o envio de uma NFe, e tive o mesmo problema. A data da duplicata era 13/09/2018 e deu rejeição, em homologação. Não dei continuidade, mas achei muito estranho. Verifiquei os dados no XML, e estavam todos corretos : Emissão 14/08 e duplicata 13/09. Não dei continuidade, acho que é algum problema do SEFAZ. Dercide.

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

No svn

Boa tarde! Depois de muitas tentativas, consegui validar a nota com as alterações da nt 2016.002 v1.5! Em relação as duplicatas, agora informei as parcelas, porém tive que alterar para 3 caracteres a nDup, pois estava causando rejeição! Obs: Atualizado schemas!

Quando valido, assino, envio, imprimo, mando e-mail, busco o retorno no arquivo de saída, no meu caso SAINFE.TXT porquê sempre gero os comandos no arquivo ENTNFE.TXT - Verifico se existe o arquivo SAINFE.TXT - Leio o arquivo SAINFE.TXT até a última linha - Vou verificando o conteúdo das linhas que me interessam(linha a linha), por exemplo: if CStat=100 ** recebo os campos para atualizar meus arquivos ** NRec= ChNFe= NProt= etc.... else Mostro na tela o erro ou advertência se for advertência como "Duplicidade de NFe" faço um consulta a NFe para prosseguir Mais ou mesno assim, entendeu? Sds, Ricardo.