Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.513
  • Registro em

  • Última visita

  • Days Won

    1.056

Tudo que Italo Giurizzato Junior postou

  1. Boa tarde a todos, Se entendi direito se você utilizar o certificado digital, não precisa usar os métodos Login e Logout? Se sim, tentaram executar os demais métodos?
  2. Boa tarde ALA, Favor atualizar os fontes e reinstale a suíte ACBr, por fim faça novos testes.
  3. Boa tarde Carlos, Favor atualizar os fontes, reinstalar a suíte ACBr e faça novos testes.
  4. Maiquel, Favor atualizar os fontes, reinstale a suíte ACBr e faça novos testes.
  5. Pelo o que eu entendi as informações do encerrante devem ser informadas no grupo <encerrante> e no grupo de observações do contribuinte, correto? Em vez disso não seria mais simples constar no decreto que as informações contidas no grupo <encerrante> devem ser impressas no DANFE da NFC-e.
  6. Bom dia Brito, Estamos estudando a implementação desse provedor, mas como lhe disse vai ser demorado.
  7. Bom dia, Primeiramente tenha uma coisa em mente. O componente gera e envia o XML do RPS, por outro lado o XML da NFS-e é gerado pelo webservice do provedor. Se você passa todas as informações corretas no XML do RPS e o provedor retorna o XML da NFS-e faltando alguma informação, o problema esta no provedor e não no componente. Pois o componente ao obter o retorno, simplesmente extrai o XML da nota e salva separadamente no disco. Se esses XMLs que você anexou são exemplos do provedor, note que no XML de envio consta o valor do ISS que é de 7,84 já o XML de retorno o valor do ISS é de 0,00 Outra coisa estranha é o valor do serviço ser de 0,10 (dez centavos) e o valor do ISS ser de 7,84
  8. Bom dia Matheus, Você vai precisar mudar, deixar de usar o Capicom e passar a utilizar o WinCrypt, pois a SEFAZ esta desativando os protocolos: SSL, TLS 1.0 e TLS 1.1 Só vai aceitar o protocolo TLS 1.2
  9. Bom dia Maiquel, Se não ocorre a impressão do DANFSE das notas enviadas para esse provedor, esta meio estranho essa exigência. Será que essa informação não deve constar no XML? Por exemplo, em vez de informar o nome do tomador, devemos informar essa frase quando se tratar de ambiente de homologação.
  10. Bom dia Maiquel, Desculpe não entendi, ao cancelar uma NFS-e a principio são gerados 2 XML, o do pedido de cancelamento e o seu respectivo retorno. Com que nome esses XMLs são salvos?
  11. Boa noite Robinho, Primeiramente peço que atualize mais uma vez os fontes e reinstale a suíte ACBr, pois foi detectado que alguns métodos estavam com a versão errada. Segundo nos testes que fiz não apresentou esse erro e sim: Integrador não cadastrado.
  12. A partir dessa data em MG se faz necessário informar os dados do encerrante na NFC-e no que se diz respeito a venda de combustível para consumidor final. Para mais informações leia a noticia sobre o referido decreto.
  13. Olá pessoal, No dia 20/12/2019 foi publicado o Decreto de numero 47.799 que trata sobre a venda de combustíveis a consumidor final em estabelecimento comercial varejista de combustíveis automotivo. O decreto possui dois artigos, o primeiro se refere a obtenção das informações referente ao encerrante e o segundo diz onde as informações do mesmo deve ser informadas no XML. Para ler na integra o decreto clique aqui. Minhas considerações: 1. Esse decreto só serve para informar que se tratando de venda de combustível para consumidor final devemos informar no XML da NFC-e os dados referente ao encerrante, visto que essas informações ficou a critério de cada UF exigir ou não. 2. O decreto é de 19/12/2019, mas na Nota Técnica 2015/002 já estava previsto que a obtenção dos dados referente ao encerrante deveria ser via hardware, logo não deve ser digitados. Final da página 4 da referida NT: C. Grupo de Combustível: Informação de “Encerrante” Dentro do grupo de informações relacionado com as operações de combustíveis, foi incluído o subgrupo de “encerrante” que permite o controle sobre as operações de venda de combustíveis, de forma semelhante à atualmente em vigor. Observação do grupo <encerrante>: Informações do grupo de “encerrante” disponibilizado por hardware específico acoplado à bomba de combustível, definido no controle da venda do Posto Revendedor de Combustível. 3. No segundo artigo do decreto diz que temos que informar os seguintes dados: nBico, nBomba, nTanque, vEncIni e vEncFin no grupo de informações do contribuinte, ou seja, no campo xCampo devemos colocar o nome do campo, por exemplo nBico e no campo xTexto o numero do bico propriamente dito. Mas acontece que na NT que eu me referi na mesma página temos os campos que compõe o grupo <encerrante>, são eles: nBico, nBomba, nTanque, vEncIni e vEncFin. Duvida cruel: Se tratando de Minas Gerais as informações referente ao encerrante devemos informar no grupo <encerrante> conforme layout apresentado na Nota Técnica 2015/002 ou devemos colocar essas informações no grupo de observações do contribuinte? Se no layout da NF-e/NFC-e já existe um grupo especifico para tais informações pra que informar em outro lugar? Desenvolvedores, que possuem clientes que comercializa combustível no varejo, favor ficar a tento a isso. Não sei se cabe a uma consulta ao órgão competente. Data de inicio da exigência dessas informações no XML: 01/04/2020 Pela data deve ser tudo mentira. Não se faz necessário alterações no componente ACBrNFe.
  14. Por favor atualize mais uma vez os fones e reinstale a suíte ACBr. Fiz algumas alterações, agora ao obter o retorno o componente vai salvar em disco o xml de cada guia retornada. Fiz uma alteração no programa exemplo, inclui um botão especifico para carregar e imprimir a guia versão 2.00 que é retornada em formato XML.
  15. Boa tarde, Já estou verificando, notei que vou ter que fazer algumas melhorias. Por favor atualize todos os fontes de todas as pastas, reinstale a suíte ACBr e faça um novo teste. Pois não tive o problema mencionando por você.
  16. Bom dia Abel, Será que ao enviar o XML da nota para o Cliente "A" não foi enviado o XML emitida para o Cliente "B" ? Favor anexar os 2 XMLs para que possamos analisar essa situação.
  17. Bom dia, O XML da Guia não é gerado pelo ACBr e sim retornado pelo webservice. Favor anexar o XML da Guia.
  18. Bom dia Elisângela, Sem problemas, essa alteração no arquivo INI do provedor SimplISS foi realizada por mim, pois notei que a maioria das cidades seguiam um padrão na formatação da URL de homologação e produção. Com essa alteração fica muito mais simples acrescentar novas cidades que seguem a mesma formatação, pois basta inclui-las no arquivo Cidades.ini da mesma forma que as demais. Já as que não seguem a formatação, além de ter que incluir no arquivo Cidades.ini se faz necessário incluir as suas URLs no arquivo SimplISS.ini Fique a vontade em perguntar. Como o assunto tratado nesse tópico ficou esclarecido, vou fechar.
  19. Bom dia Rodrigo, É bem provável que o seu sistema antes gerava um arquivo TXT para integrar com o programa da SEFAZ. Com o mesmo arquivo TXT que contem os dados da nota é possível integrar com o ACBrMonitor sem nenhum esforço.
  20. Boa tarde a todos, O arquivo Cidades.ini foi atualizado com o novo provedor e enviado para o repositório.
  21. Boa tarde Vanessa, Existem dados que só o contador do seu cliente vai poder lhe informar. Sendo assim, sugiro que entre em contato com o contador do seu cliente.
  22. Boa tarde a todos, Favor atualizar os fontes, reinstalar a suíte ACBr e façam novos testes.
  23. Bom dia, Muito obrigado pela colaboração, apliquei a mesma alteração para o Lazarus e já enviei para o repositório.
  24. Bom dia Marcio, Você não esta fazendo confusão? O componente ACBrMDFe não tem nada haver com Manifestação do Destinatário. MDF-e se refere ao Manifesto de Documentos Fiscais Eletrônicos que é muito utilizado pelas transportadoras para relacionar os CT-e que foram emitidos referente as mercadorias que compõe a carga do caminhão. Se você deseja baixar o XML de uma NF-e, você tem que usar o método DistribuicaoDFe que se componente ACBrNFe. Peço que leia o meu artigo:
  25. Bom dia Renata, Segundo o arquivo Cidades.ini a cidade de Oliveira/MG se utiliza do provedor GINFES que segue a versão 1 do layout da ABRASF. O XML que você anexou não tem nada haver com o layout da ABRASF. Você sabe me dizer se a cidade em questão mudou de provedor e qual é o atual?
×
×
  • 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.