Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.475
  • Registro em

  • Última visita

  • Days Won

    1.056

Tudo que Italo Giurizzato Junior postou

  1. Bom dia Anderson, Favor atualizar os fontes e fazer um novo testes.
  2. Bom dia Daniel, Fiz os ajustes no LFM, não sei se esta 100%, já enviei para o repositório.
  3. Tiago, Então podemos concluir que: quando o emitente for uma pessoa física com inscrição estadual (produtor rural) a série a ser utilizada tem que estar na faixa de 920 à 969 conforme consta na Nota Técnica 2018/002 versão 1.02 Se mesmo informando a serie correta o MDF-e esta sendo rejeitado é porque alguma coisa esta errada na SEFAZ-RS. Tudo era para estar funcionando 100% desde do dia 15/10/2018 quando foi liberado para o ambiente de produção a possibilidade de emissão de um MDF-e cujo emitente é uma pessoa física com inscrição estadual. Favor entrar em contato com a SEFAZ e relatar o problema.
  4. Tiago, Isso eu já entendi. Quero saber qual era a rejeição ao enviar com a serie 1?
  5. Tiago, No inicio você anexou um MDF-e cuja série é 1 e disse "não consigo emitir a mdfe". Se não consegue é porque a SEFAZ estava rejeitando esse MDF-e cuja serie era 1, pois bem qual era a rejeição apontada pela SEFAZ?
  6. Boa tarde Giovane, Muito obrigado pela colaboração, já enviei para o repositório.
  7. Boa tarde Tiago, Qual foi a série usada na emissão da NF-e? Não foi 920? Se não me falha a memória a série do MDF-e também segue a mesma regra da NF-e quando se trata de produtor rural.
  8. Luciano, Veja se a sua aplicação esta seguindo o modelo apresentado nesse documento: Especificações Técnicas 2016_12_16 da Contingencia Offline versao 2.0.pdf Veja o que pode acontecer caso seja detectado que a sua aplicação esta extrapolando o consumo dos webservices: NFe_NT2018_002 v1.00 Consumo Indevido.pdf E tem mais coisas por vir o ano que vem.
  9. Boa tarde Cleonir, Muito obrigado pela colaboração, já enviei para o repositório.
  10. Boa tarde Clederson, A solução é muito simples. 1. alimente o componente com os dados da venda; 2. execute o método Assinar (isso faz com que o XML seja gerado e assinado). 3. execute o método Consultar (se a nota foi enviada e autorizada o XML será atualizado com o protocolo de autorização). Pronto esta ai a solução. Um detalhe importante para que isso funcione o valor de cNF e dhEmi tem que ser exatamente os mesmos da nota original.
  11. Boa tarde Luciano, Como assim, consultar antes de enviar? Isso não faz nenhum sentido. Cuidado, com as novas regras que estão por vir a sua aplicação vai acabar indo para a lista negra da SEFAZ.
  12. Boa tarde a todos, Foi publicado no Portal Nacional da NF-e a Nota Técnica 2018/004 versão 1.00 que trata sobre um novo tipo de evento que é o de Cancelamento por Substituição. A liberação do ambiente de homologação para iniciarmos os testes esta prevista para 25/02/2019. A principio esse evento só poderá ser utilizado com a NFC-e. Para mais detalhes favor baixar a NT do Portal e boa leitura (são apenas 12 paginas). Estamos finalizando as alterações no componente ACBrNFe para ser enviando para o repositório.
  13. Joceandro, Muito obrigado, vou baixar e verificar um por um.
  14. Bom dia Werner, Será que a sua aplicação não esta se utilizando de um arquivo INI do provedor antigo?
  15. Gean, Fiz alguns ajustes e enviei para o repositório. Estava faltando incluir algumas linhas para configurar algumas propriedades que você mencionou, mas tem algumas que você não configurou corretamente. Com relação ao componente para imprimir a guia, o problema é que o programa exemplo vem com o componente feito em Fortes Report e você deve estar usando o que foi feito em Fast. Sendo assim, se faz necessário a inclusão dele no programa exemplo. Favor atualizar todos os fontes de todas as pastas, reinstalar os componentes e faça novos testes.
  16. Bom dia Giovane, Favor atualizar os fontes e faça novos testes.
  17. Joceandro, É preciso então comparar o Schema desse evento que esta nas pastas do ACBr com o que foi disponibilizado pelo eSocial. Quem sabe ele corrigiram o problema.
  18. Bom dia Joceandro, Favor atualizar os fontes, foi necessário incluir um campo novo (tpInscAnt) para se adequar a nova versão 2.5 Com relação ao erro de validação, verifique se não é o campo de informar AAAA-MM em vez de somente AAAA para o perApur, pode ser mensal ou anual.
  19. Bom dia Davidson, Achei esse comando no Manual do ACBrMonitor: NFe.SetTipoImpressao(nTipoImpressão) Parâmetros: nTipoImpressão - Muda o tipo de Impressão. Aceita os valores 1: Retrato 2: Paisagem
  20. Bom dia Gean, Quais alterações você fez e qual é o componente que estava faltando no programa exemplo?
  21. Bom dia, Até onde sei, para poder imprimir a guia você deve carregar o arquivo *-gnre.txt (o arquivo texto e não o XML). Qual é o comando que você esta usando para poder imprimir a guia?
  22. Bom dia, No caso de ambiente de homologação o componente sempre vai atribuir esse texto para a tag xNome. Mas no ambiente de produção o que vai para a tag xNome é o que você informar. Se não informar nada a tag não será gerada.
  23. 1 - Com relação ao tamanho: 0, 5-20 significa que o tamanho pode ser zero ou seja não informar nada, mas se informar tem que ter no mínimo 5 e no máximo 20. 2 - Se não me falha a memória você só pode emitir uma NFC-e para destinatário não contribuinte, logo se faz necessário atribuir o valor inNaoContribuinte ao campo indIEDest. 3- Quanto a uma pré validação do conteúdo de idEstrangeiro não sei é possível de ser feita.
  24. Boa tarde Cesar, Se a UF é Bahia, já existem outros relatos sobre esse problema. Favor entrar em contato com a SEFAZ.
×
×
  • 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.