Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.471
  • Registro em

  • Última visita

  • Days Won

    1.056

Tudo que Italo Giurizzato Junior postou

  1. Boa tarde, Eu não utilizo o ACBrNFeMonitor, logo não tenho nenhum exemplo de arquivo TXT, vou ficar lhe devendo.
  2. Boa tarde Buzz, Essa versão 3.3 se refere ao manual técnico do DANFE NFC-e, por favor tome muito cuidado ao postar, pois alguns podem acharem que agora teremos uma nova versão da NFC-e. Eu baixei esse manual e as imagens estão todas visíveis.
  3. Boa tarde Romerio, Se a chave de acesso não existe, só tem 2 explicações: 1. o XML não foi enviado e se foi a chave era outra. 2. o XML foi enviado para o ambiente de homologação.
  4. Bom dia José, Primeiramente desculpe pela demora na resposta. O método EnviarEmail foi escrito para atender a legislação, ou seja, assim que você obtêm o protocolo de autorização da SEFAZ o XML previamente assinado é atualizado para se tornar um documento fiscal valido e desta forma podemos enviar o mesmo por e-mail para o tomador do serviço. Exemplo: ACBrCTe1.Conhecimentos.Items[X].EnviarEmail(Para, Assunto, Mensagem , True //Enviar PDF junto , nil //Lista com emails que serão enviado cópias - TStrings , nil // Lista de anexos - TStrings ); Onde [X] varia de 0 até a quantidade -1 de CT-e carregados no componente. Por outro lado temos o seguinte comando: ACBrCTe1.EnviarEmail(Para, Assunto, Mensagem, CC {lista com emails}, Anexos {lista de anexos}); Com este comando é possível anexar vários arquivos para serem enviados por e-mail, não importa o tipo de arquivo que deseja enviar, basta anexar. Espero ter ajudado.
  5. Boa tarde a todos, Paulo, a propriedade Arquivos.Salvar se você atribuir o valor False não vai gravar nenhum documento fiscal, autorizado ou não. Isso é útil para aqueles que desejam salvar os arquivos no banco de dados e não em disco. Por outro lado temos a propriedade SalvarApenasNFeProcessadas se receber o valor False vai salvar as processadas, ou seja, receberam o procolo de autorização e as que não receberam. Agora se você esta tendo problemas com duplicidade de numeração, isso é falha na sua aplicação, deixando o usuário enviar novamente uma nota que já foi enviada ou permitir que o mesmo escolha o numero da nota. Se ao enviar uma nota ocorre um erro na aplicação, temos que primeiro acreditar que o envio foi realizado, neste caso devemos carregar o componente com o XML assinado da nota e realizar uma consulta. Se a SEFAZ retornar a mensagem acusando que a nota não existe no banco de dados ai sim podemos envia-la novamente. Por outro lado se problema ocorreu no retorno ao realizar a consulta a SEFAZ vai retornar o protocolo de autorização, o XML assinado será atualizado, ou seja, receberá o protocolo de autorização..
  6. Boa tarde Icozeira, Detectamos um problema no componente ACBrNFSe. No caso da NF-e geramos os XML de cada nota, assinamos validamos por fim montamos um lote contendo todos os XMLs assinados para ser enviado para SEFAZ. No caso da NFS-e o processo é diferente e tem muito "se necessário", veja: Geramos os XML de cada RPS, assinamos se necessário (depende do provedor), montamos o lote com todos os XML de RPS (assinados ou não), assinamos o lote se necessário (depende do provedor), validamos o lote e por fim o mesmo é enviado para o provedor. Se o lote contem um ou mais RPS e tanto os RPS quanto o lote não é assinado, ótimo não existe nenhum problema. Se o lote contem um ou mais RPS assinado e o lote não é assinado, também não existe nenhum problema, o lote é gerado da forma correta. Se o lote contem um ou mais RPS sem assinatura, mas o lote é assinado, também não existe nenhum problema, o lote é gerado de forma correta. Agora se tanto os RPS quanto o lote devem ser assinados o componente não esta conseguindo assinar o lote, logo o lote é gerado de forma errada. Tudo depende do provedor o que foi especificado por ele o que deve ser assinado. O componente precisa contemplar todas as possibilidades e esta faltando a última, ou seja, tanto o RPS quanto o lote assinado. Enquanto não resolvermos esse problema fica difícil da continuidade, pois estaríamos deixando algo importante para traz. Se não me falha a memória o provedor Saatri é um dos provedores que devemos assinar os RPS e depois o lote.
  7. Bom dia Dangelo, O método consultar tem dois objetivos: 1. simplesmente realizar uma consulta e retornar a situação atual de uma NF-e. 2. atualizar o XML que esteja assinado mas não possui o protocolo de autorização, ou seja, no final o XML vai estar assinado e protocolado. Agora se a sua intenção é fazer com que ele troque o protocolo de autorização pelo de cancelamento, esquece. Isso o componente não faz mais, estamos seguindo a risca o que consta nos manuais e notas técnicas.
  8. Bom dia Dangelo, Sugestão de leitura: Nota Técnica 2012/002 v1.02 Incrível, o Download foi implementado no componente ACBrNFe em 2012.
  9. Bom dia Apóstolo, Se você atualizou os seus fontes do Trunk depois do dia 01/05/2015, lhe garanto que estão com as novas URLs. Caso você queira confirmar, abra a Unit ACBrNFeUtil procure pela function GetURLRS e compare as URLs com o documento publicado pela SEFAZ-RS.
  10. Bom dia Walney, O ACBrNFeMonitor não vai ter mais suporte, aconselho você migrar o mais rápido possível para o ACBrMonitor Plus. O ACBrMonitor Plus esta substituindo o ACBrNFeMonitor com inúmeras vantagens. A partir de agora a equipe ACBr só vai dar suporte ao ACBrMonitor Plus e com certeza este vai atender não só a NT 2015/002 quando a NT 2015/003 e as demais que serão publicadas.
  11. Bom dia Gumercino, Você esta dizendo que a SEFAZ-ES vai deixar de usar a SEFAZ-Virtual do RS e passar a usar a SEFAZ-Virtual do Ambiente Nacional? E outros Estados também? Quais? Qual é o documento que foi divulgado essa alteração?
  12. Bom dia Caio, Você postou nesta quarta feira que foi comunicado sobre a alteração das URLs. O documento emitido pela SEFAZ-RS que trata sobre essas novas URLs foi publicado no final de Abri/2015 e no dia 01/05/2015 tanto o repositório trunk quanto o trunk2 já estavam com as novas URLs. Quem fez essa alteração foi eu e não tenho ninguém dentro da SEFAZ que me envia essas documentações em primeira mão, apenas visito diariamente os portais nacionais da NF-e, CT-e e MDF-e em busca de alguma novidade. E também diariamente verifico se tem atualização de fontes através do Tortoise. Essa é a dica que deixo.
  13. Bom dia Leão, Não se deve atribuir nada a: infMDFe.Versao caso contrario vai ocorrer erros. Essa linha não deve existir na sua aplicação.
  14. Bom dia a todos, No caso da NFS-e em nenhum provedor existe um Web Service que retorna o Status de Serviço, a solução é o que o Juliomar escreveu, ou seja, Enviar e tratar o retorno.
  15. Bom dia Paulo, Favor atualiza os fontes, esse erro foi corrigido e enviado para o repositório.
  16. Bom dia Robinho, Se o erro só aparece no ambiente de produção, conclui-se que o problema encontra-se na SEFAZ e não no componente ou sua aplicação.
  17. Boa tarde, Esse assunto já foi trata em dezenas de postagens, por favor realize uma pesquisa.
  18. Luiz, Como dito o canelamento é um evento e este não tem nada haver com o XML do CT-e. Explique melhor o que esta ocorrendo. Após o cancelamento você realiza alguma consulta a SEFAZ?
  19. Boa tarde Ricardo, Essa alteração eu fiz no dia 01/05/2015 tanto nos fontes do Trunk quanto no Trunk2.
  20. Boa tarde Luiz, Lembre-se que o cancelamento é um evento vinculado ao CT-e. Por via de regra o XML assinado e com o protocolo de autorização caso venha ser cancelado não deverá ser alterado, ou seja, o protocolo de autorização não deve ser subsistido pelo de cancelamento. Repito, se você esta cancelando um CT-e, isso significa que o XML do mesmo foi gerado, assinado, validado, enviado para SEFAZ e esta retornou o protocolo de autorização. Portanto é obrigação legal do emitente possuir esse XML. Se por algum erro ou desacordo comercial esse CT-e vier a ser cancelado teremos um segundo documento de validade jurídica que é um XML chamado: *-procEventoCTe.xml Esse arquivo contem o pedido de cancelamento e o retorno da SEFAZ acusando que o mesmo foi vinculado ao CT-e, bem como o numero do protocolo de cancelamento. Resumindo: Sempre teremos para cada CT-e emitido um XML assinado e protocolado chamado: *-cte.xml que deve ser disponibilizado o mais rápido possível ao tomador do serviço. Caso algum CT-e venha ser cancelado, teremos um XML chamado: *-procEventoCTe.xml (processamento do Evento para CT-e) que também deve ser disponibilizado o mais rápido possível ao tomador do serviço.
  21. Boa tarde Leonardo, Entendo perfeitamente o seu problema, devemos usar o que a empresa adquiriu ou queremos usar por termos um conhecimento maior sobre um Report em relação a outro. Eu me incluo nesse dilema, tenho um ERP com 80 módulos e todos os relatórios foram feitos em Quick Report. O Quick Report pode não ser o melhor do mundo, mas é o que eu tenho um certo domínio. No momento eu optei por continuar a usar o Quick Report, sendo assim tive que colocar a mão na massa e fazer todas as alterações necessárias, inclusive no pacote de instalação para fazer com que o DANFE, DACTE e DAMDFE feitos em Quick Report funcionassem com o Trunk2. Mas lembre-se oficialmente o ACBr só terá suporte para o Fast e Fortes Report. Se você deseja usar o Rave por preferencia ou por obrigação faça como eu, coloque a mão na massa para compatibiliza-lo com o Trunk2.
  22. O componente ao montar o nome do XSD, no que diz respeito ao modal e no que se refere a versão, ele se baseia na versão atribuída a propriedade infMDFe.Versao. Se na sua aplicação não existe essa linha, então algo esta de errado com os seus fontes do componente. Favor atualizar todos os fontes de todas as pastas.
  23. Por favor configure o componente para salvar os arquivos de envio/retorno envelopados, ou seja: Configuracoes.WebServices.Salvar := True; E anexo o arquivo de envio do lote para o provedor.
  24. Boa tarde Alexandre, Os arquivos INI estão sendo criados aos poucos, não criamos todos, pois ainda não conseguimos fazer funcionar alguns métodos. Queremos fazer o componente funcionar para os provedores cujos INI já foram criados, para que possamos depois começar a criar para os demais. Mas nada impede que você estude os já criados e crie um para o Betha. Dica, muitas das informações contidas no arquivo INI do provedor são extraídas da Unit do respectivo provedor, que no seu caso seria o ACBrProvedorBetha.pas
  25. Boa tarde Leao, Na sua aplicação, mais precisamente na rotina onde o componente é alimentado.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.