italo.giurizzato.junior

Boa tarde maikews, Segundo a legislação, a Nota Fiscal hoje é um arquivo eletrônico no formato XML, assinado digitalmente pelo emitente e protocolado pela SEFAZ autorizadora do mesmo. Portanto o XML nas condições acima é um Documento Fiscal válido Juridicamente, logo não se trata de um arquivo XML qualquer. Na legislação consta também que o Emitente é obrigado a disponibilizar o XML assinado e protocolado de forma imediata ao destinatário da mercadoria assim que ele obter o protocolo de autorização da SEFAZ. E se uma transportadora for envolvida no transporte dessa mercadoria, ela também tem o direito de receber o XML da NF-e. No meu entendimento a maneira mais simples de disponibilizar um arquivo de computador a outra pessoa, é simplismente envia-lo por e-mail. O Destinatário e a transportadora no caso tem a obrigação de solicitar o arquivo junto ao emitente, principalmente o Destinatário, pelo simples fato de que ambos, emitente e destinatário devem possuir e guardar pelo tempo legal (5 anos) o XML da NF-e para fins de fiscalização. Caso o emitente se recuse a disponibilizar, o destinatário pode e deve no meu entendimento denunciar junto ao Fisco a atitude do mesmo. A SEFAZ não pode e não vai disponibilizar o XML de um transação comercial para Deus e todo mundo. Veja bem não estamos falando de um XML qualquer, trata-se de um documento fiscal. Não estou criticando ninguem apenas interpretando a legislação.

Joel, Relaxa. A alteração que fiz foi drastica, como não tenho XML de exemplo de todos os provedores, eu tinha e tenho a conciencia de ter esquecido de algo. É por isso que quando alguem diz que a impressão esta incompleta eu pesso o XML para testar e efetuar as correções. Procure checar diariamente se existem atualizações, pois a qualquer momento eu posso enviar uma correção ou melhoria do ACBrNFSe ou de outro componente. E falando nisso, mandei mais uma atualização para o SVN, agora de pouco.

Joel, Por favor não post em duplicidade. Já lhe respondi no outro post. Post Trancado por duplicidade.

Boa tarde Joel, Acabei de fazer um teste usando o seu XML com o programa exemplo. Todos os dados foram impressos no DANFSE. Por favor atualize todos os fontes de todas as pastas. Inclusive hoje mesmo enviei para o SVN atualizações referente ao componente ACBrNFSe. Não esqueça de compilar com a opção Build a sua aplicação.

Boa tarde Rômulo, Muito obrigado pela colaboração, já esta disponivel a sua alteração.

Igor, Da mesma forma que a sua aplicação defini qual será o numero do CT-e ( TAG nCT ) ela deve também definir o código aleatório ( TAG cCT ). Ambos, numero e código devem ser armazenados no registro juntamente com os demais dados do CT-e no banco de dados. Por outro lado o LoadFromFile que utilizamos para carregar para o componente o conteudo de um XML, possui dois parametros. Sendo que o segundo é um valor booleano, cujo padrão é True, isso diz ao componente para que ele gere novamente o XML. Se você executar desta forma: LoadFormFile( sArquivo, False ); O XML vai ser lido e nada vai ser gerado, portanto a chave do CT-e lido não corre o risco de ser alterada.

Boa tarde dalpiaze, Acredito que você esta equivocado. Toda a implementação para o envio sincrono foi feita inicialmente para a NFC-e, mas esta disponivel para a nova versão da NF-e. Note que a linha 1620 que você se refere as condições impostas é para determinar se a consulta usando o numero do recibo vai ser realizada ou não. Se o ModeloDF for moNFCe não realiza a consulta uma vez que o envio é sincrono, por outro lado se for enviado uma NF-e no modo Sincrono a consulta também não é realizada.

Boa tarde Jairo, Por favor o XML e não o PDF do DANFSE. Com o XML tenho como testar e fazer as devidas correções.

Boa tarde Rigotti, Muito obrigado pela colaboração, já esta disponivel a correção.

Boa tarde Elvis, E os schemas, estão atualizados? Você esta usando os schemas do pacote PL_CTe_200a_NT2013_013.zip que esta dentro da pasta: ...\Exemplos\ACBrCTe\Delphi\Schemas\V200 ?

Boa tarde Fernando, Algumas considerações: 1. O arquivo que você se refere: 1-rec-c.xml é gerado pelo componente ACBrNFSe ( Nota Fiscal de Serviço Eletrônica) e você postou o seu problema no fórum destinado ao componente ACBrCTe (Conhecimento de Transporte Eletrônico), portanto tome cuidado ao postar. 2. Você diz que o problema não é a SEFAZ pois não se trata de uma nota de serviço mas o arquivo que você faz referencia no seu último post é o retorno do numero do protocolo informando que o lote de RPS foi recebido pelo webservice da prefeitura. 3. Ao postar o conteudo de um arquivo, seja ele TXT ou XML post sempre como anexo e não da forma que você fez, postando como um texto.

Boa tarde Igor, O que você quer dizer com "o valor da chave"? É a chave completa com os seus 44 digitos ou é o código aleatório que compõe a chave? Se é o código aleatório isso eu já faço a mais de 3 anos. Ao salvar os dados pertinentes ao transporte da carga no banco de dados, é gerado um código aletório e salvo em um dos campos que compõe o registro. Quando for executado a emissão do CT-e, a rotina que alimenta o componente, lê as informações do banco de dados, e é nesse momento que eu atribu-o ao campo cCT o código aleatório alteriormente gerado e salvo no banco de dados. Como a chave é gerada usando os seguintes dados: Código da UF do Emitente; Data de Emissão do CT-e; CNPJ do Emitente; Modelo do Documento Fiscal; Série; Numero; Tipo de Emissão; Código Aleatório e Digito Verificador Note que de todos os componentes somente o código aleatório e o DV poderiam ser diferentes se por acaso o XML fosse gerado novamente, visto que os demais dados são "fixos". Se você atribuir zero a cCT toda vez que você gerar o XML do mesmo CT-e uma nova chave será gerada, pois o componente se encarrega de gerar automaticamente o código aleatório. Por outro lado se você atribuir qualquer valor diferente de zero a cCT a chave gerada sempre vai ser a mesma. Espero ter ajudado.

Boa tade Rafael, Tentou usar o Gerar( nlote ) ?

Boa tarde Adriano, Se sem alterar uma virgula, a sua aplicação enviou para o ambiente de produção e o XML foi autorizado e por outro lado em homolação não vai, fica claro que o ambiente de homologação contem algum erro. Assim que foi liberado o ambiente de homolação da SEFAZ Virtual do RS realizei testes e funcionou 100%. Portanto o problema é a SEFAZ para qual você esta enviando.

Boa noite Jairo, Post como anexo o XML da NFS-e cuja impressão esta com problemas.

Boa noite Fabricio, Se o lote contem apenas uma NF-e o envio é sincrono, sendo assim não há necessidade de realizar a consulta após o envio. Por outro lado se o lote tipor duas ou mais NF-e o envio é assincrono, com retorno do recibo e há necessidade de realizar a consulta.

Boa tarde Emerson, Favor atualizar os fontes e testar novamente.

Boa tarde Cesar, Atualizar todos os fontes de todas as pastas. E compilar a sua aplicação usando a opção Build.

Boa tarde Rosemir, Muito obrigado pela colaboração. Já esta disponivel a alteração.

Boa tarde Jairo, Favor atualizar os fontes e testar novamente.

Boa tarde a todos, Favor atualizar os fontes. Fiz um merge usando as units postadas pelo Paulo Henrique. Fico no aguardo de um retorno.

Boa tarde Rafael, Você esta com todos os fontes de todas as pastas atualizados? Pois foi disponibilizado por mim os schemas do provedor Actcon. Ele esta dentro da pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas\Actcon Quanto ao resto dos seus questionamentos o Leandro deve estar mais por dentro do que eu, pois é ele que esta implementando.

Bom dia Emerson, Você esta usando o componente ACBrMDFe para gerar o XML? Eu acredito que não, pois tem coisa estranha no XML que você postou, veja: <infEvento d2p1:Id="" xmlns:d2p1="ID1101113514030959288100015158000000000025145415896801"> Esse d2p1 não existe no componente. E o erro esta nesta linha: <Reference URI=""> Você esta informado o conteudo da URI como vazio, sendo que devemos informar o valor de Id

Correto, mas onde você fez a alteração ? O componente já atende as duas situações veja: 25300, // Goiânia/GO 5208707 // Goiania/GO : Provedor := 'Goiania'; Se utilizarmos o código IBGE ou o código definido pela cidade ao configurar o componente o mesmo vai funcionar sem nenhum problema.

Bom dia Oneide, Lendo um dos links, diz que tanto o RPS quanto o Lote tem que estar assinado. Mas se você observar a unit ACBrProvedorBetha consta que ambas as propriedades AssinarRPS e AssinarLote estão com o valor True, sendo assim o componente vai assinar o RPS e o Lote.