Italo Giurizzato Junior

Boa noite Medeiros, Ao realizar a inutilização temos que informar os seguintes dados: CNPJ do emitente Justificativa da inutilização Ano da solicitação da inutilização Modelo, se tratando da NF-e é 55 Serie do numero ou faixa a ser inutilizado Numero Inicial da faixa Numero Final da faixa caso você já esteja na série 002, mas pretende inutilizar o numero 5000 da série 001 as últimas informações são: série = 1 Inicial = 5000 Final = 5000 Será que o problema não é esse? A série esta sendo informada de forma errada.

Boa noite, Assim que possível vou avaliar as suas alterações e estando tudo OK, vamos disponibilizar. Desde já muito obrigado pela colaboração.

Boa noite Glenio, Esta correto, uma vez que o problema não é uma rejeição referente a algum dado do RPS e sim o usuário que não esta cadastrado para usar o Web Services.

Bom dia Medeiros, Não existe Inutilização de NF-e e sim inutilização de numero ou faixa de números. Se a nota foi emitida de forma errada você deve cancelar. Se o sistema pula um numero de nota da sequencia, por exemplo, por algum erro não exite a nota de numero 500, para que a SEFAZ não fique eternamente esperando você emitir a nota de numero 500, se deve solicitar a SEFAZ a inutilização desse numero.

Bom dia Cesar, Post como anexo o XML do envio do evento EPEC.

Bom dia Walter, O erro esta no conteúdo da TAG dhSaiEnt, veja: <dhSaiEnt>2015-04-14T38:22:00-04:00</dhSaiEnt> Se o XML não foi editado após a sua autorização, com certeza a SEFAZ não esta validando o conteúdo dessa TAG. A solução vai ser, editar o XML para poder ser lido. Alterar 38:22:00 para 15:38:22

Bom dia Glenio, Após a execução do método Gerar, você pode: sProtocolo := ACBrNFSe.WebServices.GerarNfse.Protocolo; for i := 0 to (ACBrNFSe.NotasFiscais.Count -1) do begin sNotaFiscal := ACBrNFSe.NotasFiscais.Items.NFSe.Numero; sDataHora := DateTimeToStr(ACBrNFSe.NotasFiscais.Items.NFSe.DataEmissao); sProtocolo := ACBrNFSe.NotasFiscais.Items.NFSe.CodigoVerificacao; if ACBrNFSe.WebServices.GerarNfse.NFSeRetorno.ListaNfse.MsgRetorno.Count > 0 then begin sStat := ACBrNFSe.WebServices.GerarNfse.NFSeRetorno.ListaNfse.MsgRetorno.Items[0].Codigo; sMotivo := ACBrNFSe.WebServices.GerarNfse.NFSeRetorno.ListaNfse.MsgRetorno.Items[0].Mensagem; end else begin sStat := ''; sMotivo := ''; end; end; Se a nota foi rejeitada o código e o motivo da rejeição estarão armazenados nas variáveis: sStat e sMotivo.

Boa tarde Ariel, Você deve parar as consultas quando o código de cStat retornado na última consulta for igual 137. Por favor leia a Nota Técnica 201/002 versão 1.01 (página 7) item 2.5

Boa tarde a todos, O método Download apenas salva em disco o XML da NF-e retornada pela SEFAZ, não faz nenhum tratamento nele. Nada Impede que você escreva uma rotina que lê o XML como uma string e remova da mesma o que esta provocando erro ao tentar validar e depois salve-o novamente.

Boa tarde a todos, Segundo a Nota Técnica 2014/002 versão 1.01 página 4, logo após o quadro com a relação de documentos e que tem direito de recebe-los, temos a seguinte observação: Os documentos fiscais e resumos de eventos estarão disponíveis somente se o destinatário se manifestar dando "Ciência da Operação", “Operação não Realizada” ou "Confirmação de Operação" para a NF-e. Antes da manifestação do destinatário fica disponível unicamente a estrutura XML de “Resumo de NF-e”. Sendo assim, o resumo do evento de cancelamento só será disponibilizado para o destinatário caso este se manifestar.

Boa tarde Rodrigo, Quais são as TAGs desnecessárias no XML que você anexou? Outra coisa, em vez de você utilizar o método Download, porque não utiliza o DistribuicaoDFe? Ele também retorna o XML completo de uma nota quando esta já tenha sido manifestada, com uma vantagem, ser você manifestou 5 notas o DistribuicaoDFe retorna todas elas.

Boa tarde Joemil, Você esta atribuindo um valor diferente de zero para vDesc (item)?

Boa tarde Fernando, Na chave de um documento fiscal eletrônico como NF-e, CT-e, NFC-e e MDF-e consta apenas o ano e mês de emissão do mesmo. O que você quer dizer com emitir CT-e com datas antigas? Para mim, emitir significa: gerar o XML , assinar, validar e enviar para SEFAZ. Agora, imprimir significa: ler o XML de um CT-e (não importa a data de sua emissão) e imprimir o DACTE. O componente possui uma propriedade chamada ID que contem o literal CTe mais a chave (44 dígitos). Antes era possível, você gerar a chave e atribuir a propriedade ID, mas isso estava provocando erros, pois muitos não geravam a chave corretamente. Sendo assim, a propriedade continua a existir, você até pode atribuir algo a ela, mas será descartado no momento que o componente gerar a chave correta.

Boa tarde Luciano, O ACBrNFeMonitor não estava conseguindo identificar o comando para imprimir eventos. Fiz a correção e já esta disponível, favor aguardar a nova compilação do ACBrNFeMonitor.

Boa noite Sérgio, Acredito que você não leu com atenção o item 3 do manual. Na sua postagem você diz que não encontrou no manual como informar os dados do emitente, destinatário e produtos, pois muito bem, no item 3 temos um paragrafo que diz: O programa exemplo: ACBrNFe_demo que encontra-se na pasta: ...\Exemplos\ACBrNFe2\Delphi possui uma procedure chamada GerarNFe que exemplifica a alimentação dessas propriedades com os dados pertinentes a venda. Quando me refiro "dados pertinentes a venda" estou me referindo ao emitente, destinatário e produtos. Convido a você a estudar o programa exemplo e ler os Manuais e Notas Técnicas que Juliomar mencionou em sua postagem.

Boa noite a todos, A principio devemos utilizar a série = 1 até que a numeração atinja 999.999.999, ai devemos incrementar a série ou seja passamos para a série = 2 e a numeração volta para 1. Não entendi o motivo de utilizar séries diferentes para modais diferentes, a questão é a nível de relatório? se sim basta colocar no mesmo uma coluna referente ao modal. Não há necessidade de pedir permissão a SEFAZ para utilizar uma nova série e também não vejo necessidade de se utilizar uma série diferente para cada "ponta", é possível gerenciar isso de outras formas, como por exemplo pelo CNPJ do emitente, caso cada "ponta" possua um CNPJ diferente, se possuir o mesmo, pode-se ter um campo no banco de dados que defini o local de emissão e esta informação pode ser incluída nos relatórios operacionais e gerenciais.

Boa noite Gustavo, Post como anexo o lote que contem mais de um CT-e e que um deles (não pode ser o primeiro) tenha sido rejeitado. E post como anexo também o retorno do envio do respectivo lote,

Boa noite Thiago, Um problema parecido ocorreu também com o CT-e e MDF-e, fiz uma alteração nos componentes desses documentos fiscais. Amanhã fazei a mesma alteração no componente da NF-e e depois é só aguardar a liberação da nova compilação do ACBrNFeMonitor.

Bom dia Gustavo, Infelizmente a SEFAZ não retorna o na mesma sequencia que você envia. Se todos os CT-e do lote forem autorizados no retorno vai estar na mesma sequencia do envio. Mas se um deles for rejeitado, este será colocado em primeiro lugar. exemplo envio dos CT-e: 1, 2 e 3 (nesta sequencia) se o 2 for rejeitado temos no retorno a seguinte sequencia: 2, 1 e 3 Você deve estar lendo o retorno e atualizando o banco de dados sem checar exatamente quem você esta lendo, acreditando que o retorno encontra-se na mesma sequencia do envio.

Alexandre, O que precisa ficar claro é que temos interesse em fazer com que o componente atenda o maior numero possível de cidades no que diz respeito a emissão da NFS-e. Mas precisamos da compreensão e colaboração de todos. Compreensão, pois não temos condições de desenvolver a toque de caixa e o que foi desenvolvido não vai funcionar de primeira. Colaboração, pois sem as informações e os arquivos que listei, não temos como dar inicio ao desenvolvimento e quanto mais pessoas estiverem envolvidas, escrevendo códigos, testando, fazendo as correções fica mais fácil.

Bom dia Igor, Não se deve mudar o nome do título do quadro no DACTE uma vez que ele segue o manual. Para que a informação seja impressa no local correto devemos informar: tpMed = "PESO BRUTO" ou tpMed = "PESO BC"

Bom dia, Por favor faça uma nova atualização dos fontes e teste novamente.

Bom dia Luciano, Você tem certeza que o nome que você informou como sendo do evento é exatamente esse? <chave> + <tipo evento> + -procEventoMDFe.xml que eu saiba é: <ID do evento> + -procEventoMDFe.xml onde <ID do evento> = <tipo evento> + <chave> + <numero seq. evento>

Bom dia Alexandre, Desculpe, mas você não mandou o schema no inicio do tópico e sim as URLs de homologação e de produção. É preciso muito mais: 1. schema (arquivo XSD) usado para validar o lote de RPS gerado antes do envio para o Web Services. 2. NameSpace (é uma URL que informada no XML). 3. Arquivos XML de exemplos de envio, cancelamento e consulta. 4. Arquivos soap de exemplos, esses arquivos também são XML mas eles contem toda a estrutura de envelopamento do XML a ser enviado para o Web Services. 5. Esse Web Services atende somente a cidade de São Pedro da Aldeira? De posse de todos esses arquivos e informações, se você programa em Delphi e tiver curiosidade em aprender como o componente funciona basta você analisar como foi implementado os demais provedores e tentar implementar para a cidade desejada. O ACBr não é uma empresa que desenvolve e disponibiliza soluções e sim um grupo de centenas e milhares de pessoas que compartilham informações, conhecimento e códigos.

Bom dia Luis, Primeiramente, não entendi, você gera as notas de entrada? Essas notas são de compra de mercadoria ou de entrada por devolução? Se for de compra, é o seu fornecedor que deve disponibilizar os XMLs das mesmas. Você diz que gera o XML das notas que não são eletrônicas? Esta errado isso, pois o seu fornecedor emitiu uma nota segundo um modelo e você gera o Sped em outro modelo, no caso 55 ou 65. O componente esta em conformidade com a Nota Técnica 2013/005 versão 1.22 Até a versão 2.00 tínhamos duas TAGs: dSaiEnt e hSaiEnt para informar a data e hora de saída ou entrada da mercadoria, a partir da versão 3.10 essas duas TAGs se transformaram em apenas uma: dhSaiEnt que contem tanto a data quanto a hora (veja a formatação na página 17) da NT. No componente para manter a compatibilidade com a versão 2.00 o nome da propriedade ainda é dSaiEnt. Se a versão do XML for 2.00 devemos atribuir a essa propriedade a data e será gerado a TAG: dSaiEnt, por outro lado se a versão for 3.10 devemos atribuir a essa mesma propriedade a data e hora e será gerado a TAG dhSaiEnt. Quanto a linha que você esta questionando é que a TAG: dhSaiEnt só esta presente no modelo 55, ela não deve ser gerada se o modelo for 65. Na página 46 da NT mencionada acima temos uma observação referente a TAG dhSaiEnt, onde diz que: não devemos informar este campo para a NFC-e, ou seja modelo 65. Na página 100 temos a regra B10-10 referente ao modelo 65 que diz que a NFC-e será rejeitada caso esta tenha a TAG que contem a data e hora de saída/entrada. Por que o modelo 65 não tem essa TAG, simples, esse modelo se refere a NFC-e ou seja Nota Fiscal do Consumidor Eletrônica, sendo assim fica subentendido que a data e hora da saída da mercadoria é a mesma da emissão da nota. Se o seu parceiro acompanhasse a evolução dos documentos fiscais eletrônicos com base nos manuais e notas técnicas publicados pelo ENCAT e disponibilizados no Portal Nacional da NF-e, você não precisaria ficar argumentando com ele.