Italo Giurizzato Junior

Bom dia Márcio, Como a SEFAZ esta implementando um novo Web Service para realizar a consulta e consequentemente a manifestação, pode ser que alteraram o que não deviam. Certifique-se que a chave da NF-e que você esta realizando a manifestação esta correta, ou seja é exatamente igual a da NF-e emitida contra o seu CNPJ. Caso esteja tudo correto, o problema pode estar na SEFAZ do Ambiente Nacional, uma vez que a consulta é feita nela. Para ela realizar o registro do evento e acusar que o mesmo não foi vinculado, isso significa que as SEFAZ-Autorizadoras não estão disponibilizando em tempo hábil as respectivas notas.

Bom dia Alexandre, A cidade Duartina/SP se utiliza do provedor Fiorilli, com relação ao usuário e senha, verifique se não há necessidade de se ter um usuário e senha especifico para utilizar o Web Services. Com relação a cidade São Paulo/SP a mesma não é atendida pelo componente ACBrNFSe pelo simples fato do provedor não seguir o padrão ABRASF.

Bom dia a todos, Alterei várias units a fim de resolver o problema do Valor Liquido Zerado. Favor atualizar os fontes e testar novamente. A primeira alteração visava somente se o XML da NFS-e fosse carregado para o componente com essa alteração acredita-se que o problema esteja resolvido sem a necessidade de realizar um LoadFromFile do XML.

Márcio, Ao realizar a manifestação o vCNPJ contem o CNPJ do destinatário e não do emitente da NF-e, correto?

Boa tarde Marcio, Para você consultar NF-e Destinadas bem como realizar a sua manifestação no ambiente de homologação é necessário que existe alguma nota emitida em homologação contra o seu CNPJ. Se você tentar manifestar em ambiente de homologação se utilizando de uma chave de NF-e emitida em produção a resposta é exatamente essa: Evento registrado mas não vinculado. Isso já é um indicio que a NF-e não existe naquele ambiente. E consequentemente não será possível realizar o seu download. Sugiro que realize esses testes em ambiente de produção, ou peça para alguém emitir uma NF-e contra o seu CNPJ em ambiente de homologação.

Bom dia Márcio, Primeiramente, não post como texto fragmento de código, por favor coloque-o em um arquivo TXT (bloco de notas) e anexe ao post, desta forma ele fica mais curto. Você misturou tudo na sua rotina. Primeiro você tem que realizar uma consulta das NF-e destinadas para obter a relação das mesmas (rotina 1). Segundo é preciso se manifestar sobre cada NF-e retornada (rotina 2). Terceiro solicitar o download da NF-e desejada (rotina 3). Leia atentamente a Nota Técnica 2012/002 versão 1.02 que trata sobre o assunto.

Bom dia Arnaldo, Só vejo um problema nesse cenário: Servidor: Numero da ultima NFC-e emitida = 10 PDV 1: ao consultar o servidor para gravar pega o valor 10 e grava o novo registro como sendo 11 PDV 2: se consultar o servidor antes do PDV 1 ter gravado, também terá como resposta o valor 10. Ainda acho que a melhor solução é adotar um numero de série para cada PDV.

Bom dia Nicolas, Muito obrigado pela colaboração, já esta disponível.

Acredito que desta forma fica claro que existem 2 fardos, um com 560 e outro com 496 unidades.

Boa tarde ncc, No meu entendimento sim, apresentar no DACTE cada <infQ>.

Bom dia, Estamos em busca de uma rotina que descompacte os dados. Quanto mais pessoas estiverem envolvidas mais rápido chegaremos a uma solução.

Bom dia cmonteiro, Por favor post como anexo somente as unit que você fez alteração, para que possamos avaliar e se estiver tudo de acordo, enviaremos para o repositório. Desde já muito obrigado pela colaboração.

Bom dia Walter, Você procurou no Manual por essa TAG? Pois bem, no Manual versão 2.00a do CT-e página 135 - campo 264 tempos a TAG: nPed - Numero do Pedido da NF. Vamos primeiramente a descrição dessa TAG, "Numero do Pedido da NF", veja, "NF" e não "NF-e", portanto esta se referindo a Nota Fiscal comum de papel e não a Nota Fiscal Eletrônica. Segundo, o nível dessa TAG é 4 portanto ela é filha do grupo infNF que é de nível 3 (página 134) esse grupo se refere a informações das NF e a observação diz: "Este grupo deve ser informado quando o documento originário for NF". Entenda, documento originário, como sendo o documento emitido pelo remetente da carga. Por outro lado na página 137 temos no mesmo nível 3 o grupo infNFe, destinado as Informações das NF-e que por sinal tem como TAG fila a chave (campo #298). Outra coisa importante note que tanto o infNF quanto o infNFe são do tipo CG, isso significa que para aparecer o nPed no XML deve-se ser gerado o grupo infNF sendo assim o infNFe não será e neste caso a chave da NF-e não vai aparecer e vice versa. Se você informar os dados da NF-e como sendo uma NF o seu CT-e vai ser rejeitado, uma vez que o emitente do documento originário já esta obrigado a emitir NF-e e você informando como NF estaria dizendo para a SEFAZ que ele emitiu uma Nota Fiscal Comum de Papel e não uma Nota Fiscal Eletrônica. Resumindo não tem como. A unica solução é informar o numero do pedido no campo observação e não na TAG: nPed. O Seu cliente não tem o que querer, você precisa mostrar a ele com o manual em mãos o que pode e o que não pode.

Bom dia Diogo, Uma coisa é certa, o XML a ser enviado tem que estar em conformidade com o schema disponibilizado por eles. Mas será que eles não perceberam que estão remando contra a maré? O XML da NF-e, NFC-e, CT-e e MDF-e que são documentos fiscais a nível nacional o ID é: "Id", ou seja, a letra "I" em maiúsculo. E a grande maioria dos provedores de NFS-e utilizam o ID: "Id". Será que fazer essa troca no Schema e no Web Services deles é tão complicado a ponto de não querem fazer? Ou querem ser os diferentes? Ou será que não sabem fazer essa alteração, uma vez que não foram eles que desenvolveram os Web Services?

Boa tarde Dércio, Que eu saiba o A3 só funciona com o CAPICOM.

Boa tarde José, Primeiramente, por favor não poste como texto no post fragmentos de código, principalmente se eles foram grandes como o seu. Segundo, você sabe o que o ADD faz? O Add é utilizado para adicionar um elemento em uma lista. Vamos a um pequeno fragmento do seu código: ACBrNFe.EventoNFe.Evento.Add.InfEvento.tpAmb := ACBrNFe.NotasFiscais.Items[0].NFe.Ide.tpAmb; ACBrNFe.EventoNFe.Evento.Add.InfEvento.CNPJ := ACBrNFe.NotasFiscais.Items[0].NFe.Emit.CNPJCPF; ACBrNFe.EventoNFe.Evento.Add.InfEvento.cOrgao := ACBrNFe.NotasFiscais.Items[0].NFe.Ide.cUF; Só nesse fragmento você adicionou 3 eventos e não um só. Na primeira linha temos um evento só com o tipo de ambiente, na segunda linha você adiciona um segundo evento só com o CNPJ na terceira linha você adiciona mais um evento só com o código do órgão. Entendeu onde você esta errando?

Boa tarde Otair, Sim, já foram feitos alguns testes.

Entendi, o ULTIMO não é um campo e sim uma variável que recebe o valor do campo NUMERORPS_NOT. Sendo assim o que pode estar ocorrendo: Como você tem a consulta e a atualização da tabela dentro do loop, pode estar ocorrendo um atraso na atualização da tabela e consequentemente ao fazer a nova consulta pega o mesmo valor de NUMERORPS_NOT. Dai você tem o erro de retorno do Web Service acusando que já existe um RPS com aquele numero.

Boa tarde, Mas acontece que IdentificacaoRps.Numero recebe o valor da variável RPS. E está recebe o valor segundo o IF abaixo: If ADOQConsulta.FieldByName('ULTIMO').AsInteger >= DMBase.ADOQParametroNUMERONOTAINICIAL_PAR.AsInteger then RPS := ADOQConsulta.FieldByName('ULTIMO').AsInteger + 1 Else RPS := DMBase.ADOQParametroNUMERONOTAINICIAL_PAR.AsInteger; Em que momento o campo ULTIMO ou NUMERONOTAINICIAL_PAR são atualizados?

Bom dia, Para imprimir a CC-e completa é necessário: 1. Carregar o XML da NF-e 2. Carregar o XML do evento de CC-e 3. Imprimir o Evento.

Notei segundo o seu código, que você envia os RPS de forma individual, ou seja, cada lote possui apenas um RPS, vem vez de enviar todos os RPS no mesmo lote. Mas até tudo bem. Notei que a variável RPS por receber o seu valor do campo ULTIMO somado de 1 da tabela NFSE_NOTA ou do campo NUMERONOTAINICIAL_PAR de uma tabela acredito eu chamada Parametro. Até ai perfeito. Mas em que momento os campos ULTIMO e ou NUMERONOTAINICIAL_PAR são atualizados em suas respectivas tabelas?

Bom dia Valdir, Tentou informar como vazio, ou seja, atribuir uma string vazia a esse campo?

Bom dia Marcelo, Primeiramente a versão correta é 3.10 e não 3.0 Segundo, no Portal Nacional da NF-e você encontra a Nota Técnica que traz a nova estrutura do XML na versão 3.10 que contempla tanto a NF-e quanto a NFC-e. Alguns Estados brasileiros já existe um calendário de obrigatoriedade da NFC-e - Nota Fiscal ao Consumidor Eletrônica, no que diz respeito a São Paulo não tem nada definido, somente algumas empresas estão emitindo em ambiente de homologação como projeto piloto.

Bom dia, Por favor, não post fragmentos de código como texto no post e sim como arquivo em anexo, principalmente se o fragmento for grande como o seu. É simples, basta clicar no botão [Mais Opções] que você vai encontrar um outro botão para anexar arquivos. Edit o seu post anexando o fragmento como um arquivo TXT (bloco de notas).

Bom dia João, A explicação é bem simples. Para o "nobre contador" solicitar um XML cujas as casas decimais sejam 2 por exemplo, com certeza o software que ele utiliza para ler os dados do mesmo é incapaz de tratar de forma correta valores reais com mais de 2 casas decimais. Outra coisa que precisa ficar clara é o que consta no manual ou nota técnica, vamos a dois exemplos: qBCProd Tamanho: 12v0-4 (neste caso a quantidade poderá ter nenhuma casa decimal ou até 4 casas decimais) vAliqProd Tamanho: 11v4 (neste caso o valor tem que ter 4 casas decimais) Como exposto acima até poderíamos criar um tipo de campo por exemplo: tcDe04. Hoje temos o tcDe4 que gera valores com 4 casas decimais e seria utilizado para o vAliqProd e para o qBCProd usaríamos o tcDe04 que seria capaz de gerar valores com zero até 4 casas decimais.