Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.502
  • Registro em

  • Última visita

  • Days Won

    1.056

Tudo que Italo Giurizzato Junior postou

  1. Boa tarde Maiko, Se a cidade utiliza a versão 2 tem que adicionar a URL no arquivo Pronimv2.ini e não no Pronim.ini
  2. Boa tarde ALA, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr? Se sim, chegou a fazer testes usando o programa exemplo?
  3. Boa tarde Marcelo, O componente não realiza cálculos, portanto se faz necessário informar a Base de Calculo de cada item e a somatória conforme exemplo abaixo: Total.ICMSTot.vBC := vTotalBC;
  4. Boa tarde Wesley, O envio do documento no formato zipado esta previsto sim, mas não sei lhe informar se todas as SEFAZ-Autorizadoras implementaram a recepção desse formato. Portanto o jeito é testar.
  5. Bom dia, Se você utiliza o componente te aconselho a ter em mãos o manual que contem o layout do XML, assim é possível você descobrir o que esta faltando informar. Agora se você utiliza o ACBrMonitor, no help dele possui um modelo do arquivo INI para você comparar com o seu e ver o que esta faltando.
  6. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  7. Bom dia, Se você não nos contar qual é o problema como iremos lhe ajudar? Anexa o XML da NFC-e e a mensagem de erro / rejeição.
  8. Bom dia, Favor entrar em contato com o provedor e verificar se a URL de homologação e de produção não foram alteradas.
  9. Bom dia Carlos, As 4 rejeições são do mesmo lote que foi enviado? Se sim, procure saber qual foi o numero do último lote enviado com sucesso e a incremente o numero do lote, ou seja, se o numero do ultimo enviado com sucesso foi 250, tente enviar esse com o numero 251 (por exemplo). Pelo jeito esse provedor controla a numeração do lote, logo esse numero tem que ser sequencial e controlado pela sua aplicação.
  10. Bom dia Roberto, Os XMLs abaixo foram gerados pelo componente ACBrNFSe. RPS: 4120011876054000013956000000000000001-rps.xml Envio do Lote: 1-env-lot-soap.xml Retorno do Envio: 1-rec-soap.xml Espero ter ajudado.
  11. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  12. Bom dia Jair, O ambiente de homologação do provedor Infisc não funciona, em vez de retornar o resultado do envio, retorna o WSDL do webservice, por outro lado o ambiente de produção retorna o resultado do envio. Para esse provedor a única solução é enviar a nota para o ambiente de produção e depois cancelar pois trata-se de um teste.
  13. Bom dia, Muito obrigado pela colaboração, fiz mais algumas alterações e enviei para o repositório. Nos meus testes também recebo a mensagem de erro acusando erro na assinatura. Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr. Note que fiz uma alteração no arquivo INI do provedor. Favor entrar em contato com o provedor e solicitar um arquivo XML de envio para que possamos comparar e dessa forma tentar descobrir onde esta o erro.
  14. Bom dia Diego, O provedor Giap já foi implementado. Favor abrir o arquivo Cidades.ini e ver como esta definido as cidades que usam esse provedor e fazer o mesmo para a cidade em questão. Faça os testes usando o programa exemplo do componente, estando tudo OK, anexa o arquivo Cidades.ini alterado no tópico que foi criado exclusivamente para isso. Desde já muito obrigado pela colaboração.
  15. Bom dia Thiago, Eu não trabalho com o Fast, logo não sou a pessoa mais indicada para lhe ajudar. Vamos aguardar alguém que conhece o Fast e possa lhe ajudar.
  16. Robinho, Pode ter mais coisas que precisam ser alteradas no componente por conta das mudanças que o eFrete realizou.
  17. Liberação do ambiente de produção para o envio do novo evento e do MDF-e com os novos grupos e campos incluídos pela respectiva NT. Para mais informações, por favor leia o artigo sobre a NT 2020/001 MDF-e. Adiado para o dia 06/07/2020 as regras de validação: 725 e 726 o resto segue normal.
  18. Liberação do ambiente de homologação para os testes do novo evento e dos novos grupos e campos incluídos pela respectiva NT. Para mais informações, por favor leia o artigo sobre a NT 2020/001 MDF-e.
  19. Olá pessoal, Foi publica a NT 2020/001 do MDF-e e ela já se encontra em nossa biblioteca. Resumo: O projeto MDF-e Integrado tem como objetivo a disponibilização, pelas Secretarias de Fazenda, de uma infraestrutura digital de documentos, legislações e processos voltados para a simplificação da emissão de documentos fiscais eletrônicos de transporte e integração, dentro de um ecossistema digital, que permite às Empresas Transportadoras de Cargas (ETC), Transportadores Autônomos de Cargas (TAC), ANTT, Administradores de Meios de Pagamentos e as próprias Secretarias de Fazenda, o aperfeiçoamento dos seus processos e compartilhamento de informações entre todos estes atores, a partir de um único documento e infraestrutura já consolidada e em uso por todos os envolvidos. Diante desse desafio, as Secretarias de Fazenda e o ENCAT, vêm nos últimos meses e em parceria com os diversos atores intervenientes, adotando uma série de ações estruturantes voltadas para superação das dificuldades atuais enfrentadas pelos órgãos de controle e geração de um ambiente operacional mais eficiente e competitivo, a exemplo das ações descritas abaixo: Aprovação de legislação nacional que normatizou o compartilhamento dos MDF-e dos 27 estados com os órgãos reguladores de transportes; Aprovação de legislação nacional que normatizou a obrigatoriedade de emissão do MDF-e em todas as operações de transporte, sejam elas intermunicipais ou interestaduais; Implantação da plataforma digital e registro de eventos eletrônicos que permitem ao transportador confirmar a entrega da mercadoria ao destinatário, possibilitando assim, a redução do prazo para o recebimento do frete por parte do caminhoneiro; Aprovação de legislação criando a Nota Fiscal Fácil (NFF), que permitirá aos contribuintes que operam com vendas de mercadorias e transportadores autônomos emitirem seus respectivos documentos fiscais de forma simplificada e a partir do seu próprio smartphone, conforme legislação publicada no D.O.U. do dia 19/12/2019 (Ajuste SINIEF No. 37 de 13 de dezembro de 2019); Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TAC-Independente como TAC-Agregado; Automação do processo de fiscalização do Piso Mínimo do Frete (Tabela do Frete), nos termos da Resolução ANTT nº 5.849 de 16 de julho de 2019. Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. Com essa NT temos: - Alterações de schema e regras de validação do MDF-e - Alterações no schema do modal rodoviário no grupo infANTT - Criação do evento de Pagamento da operação de transporte Portanto teremos um evento novo, criação do grupo Produto Predominante <prodPred> na parte geral do MDF-e, alteração no grupo informações do contratante, inclusão dos campos <xNome> e do <idEstrangeiro>, no modal rodoviário foi criado o grupo informações do pagamento do frete <infPag>. Novas Regras de Validação: Se modal rodoviário e indicador de pagamento for a prazo (tag:indPag=1): O grupo de informações a prazo deve ser informado (grupo:infPrazo). Implementação Obrigatória. Gera a Rejeição: 724. Se modal rodoviário, o grupo produto predominante deve estar informado (grupo: prodPred). Implementação Obrigatória. Gera a Rejeição: 725. Se modal rodoviário e MDF-e possuir apenas um DF-e transportado no grupo infDoc: O grupo de informações da carga lotação (infLotacao) deve estar informado. Implementação Facultativa. Gera a Rejeição: 726. Se modal rodoviário e informado grupo de pagamento, rejeitar se CNPJ/CPF do responsável pelo pagamento estiver inválido. Implementação Obrigatória. Gera a Rejeição: 727. Se moda rodoviário e informado grupo de pagamento, rejeitar se CNPJ do IPEF estiver inválido. Implementação Obrigatória. Gera a Rejeição: 728. Vai ocorrer alterações no componente? Sim Vai ocorrer alterações nos schemas? Sim Vou ter que adequar a minha aplicação? Sim Prazos: Ambiente de Homologação: 09/03/2020 Ambiente de Produção: 06/04/2020
  20. Bom dia Ale, Essa cidade não mudou de provedor? Na outra postagem lhe disse que o provedor SIAT não foi implementado.
  21. Bom dia Maiko, Basta acrescentar a cidade no arquivo Cidades.ini aos moldes de outras que usam o provedor Pronimv2. Despois faça os testes usando o programa exemplo. Se tudo der certo favor anexar o arquivo Cidades.ini no tópico que criei especifico para essas atualizações. Desde já muito obrigado pela colaboração.
  22. Bom dia a todos, Tópico muito antigo, vou fechar.
  23. Bom dia Ale, No arquivo Cidades.ini ainda consta que o provedor é IssDSF, se mudou para SIAT você não vai conseguir mesmo enviar, uma vez que esse provedor nem sequer foi implementado no componente.
×
×
  • 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.