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 Castro, Talvez eles querem que você simplesmente, cancele a NFS-e que esta errada e emita uma nova sem a necessidade de informar que esta última esta substituindo uma outra anterior.
  2. Boa tarde Roger, CTe Versão 2.00 os campos de complementação não existem mais. Simplesmente você emiti um novo CT-e cujo tpCTe é 1-CT-e de Complementação de Valores, lança os valores nos campos normalmente usados e informa a chave do CT-e que esta sendo complementado em: infCteComp.chave Não entendi o xNome?
  3. Boa tarde Jander, Veja este link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-subcontratacao/
  4. Boa tarde Idez, Esse campo (nome correto: Outras Informações), normalmente faz parte da estrutura da NFS-e e não do RPS (segundo padrão ABRASF). Checando o Schema do provedor Thema o campo: OutrasInformacoes faz parte do tipo complexo tcInfNfse. Portanto nem adianta alimentar esse campo, pois o componente não vai incluir ele no RPS e se altera-lo para que o faça, o XML não será validado.
  5. Boa tarde a todos, Encontra-se disponível a implementação da Impressão da Inutilização de Numeração. No programa exemplo temos 2 novos botões que exemplificam a impressão bem como a geração do PDF. Atenção: a implementação foi feita em Quick Report.
  6. Bom dia Matheus, Desculpe, mas não estou entendendo o motivo dessa consulta. Com essa consulta você quer saber se um determinado motorista consta em algum MDF-e ainda não encerrado? Se é essa a sua intensão, a resposta é não. Como lhe disse você vai ter que tratar isso na sua aplicação, se for o caso fazer alterações no banco de dados para armazenar tudo o que é informado em um MDF-e bem como se o mesmo esta encerrado ou não.
  7. Bom dia Nilson, Por que não utilizar uma série diferente para cada PDV? PDV1: Série: 1 Numero da NFC-e: 1, 2, 3, .... PDV2: Série: 2 Numero da NFC-e: 1, 2, 3, .... (...)
  8. Bom dia, Já inclui as URLs de homologação do Ceará, por favor atualize todos os fontes de todas as pastas e realize os testes.
  9. Boa tarde Matheus, Via Web Services, não, você tem que tratar isso na sua aplicação.
  10. Boa tarde Mauricio, Apenas uma correção, não existe nota fiscal inutilizada e sim nota fiscal cancelada. O que inutilizamos não é a nota e sim um número ou uma faixa de números. Ao inutilizar um número estamos informando a SEFAZ que não existe nenhuma nota com esse número.
  11. Boa tarde Oneide, Tente realizar esses 2 testes: Como você emitindo em ambiente de testes, altere as URLs da function GetSoapAction que esta na unit ACBrProvedorBetha.pas Inclua nas URLs a palavra test: ..../e-nota-contribuinte-test-ws/.... Se não funcionar deixe as URLs em branco: Result := ''; Fazer essas alterações para todas as ações.
  12. Boa tarde Ailton, O componente ACBrNFSe, sofreu varias alterações visando atender esse provedor. Lhe pergunto todos os fontes de todas as pastas estão atualizados?
  13. Boa tarde, Você utiliza o componente ou o ACBrNFeMonitor? Se for o componente você deve repetir o trecho abaixo, um para cada correção (limite de 20 correções): with ACBrCTe.EventoCTe.Evento.Items[0].InfEvento.detEvento.infCorrecao.Add do begin grupoAlterado := sGrupo; campoAlterado := sCampo; valorAlterado := sValor; nroItemAlterado := iNumItem; end;
  14. Boa tarde, Segundo a mensagem de erro, foi encontrado um carácter inválido no conteúdo do texto, o texto neste caso acredito ser no arquivo: leiauteConfRecebto_v1.00.xsd ou no arquivo apontando pelo include ou seja, tiposBasico_v1.03.xsd
  15. Boa tarde Carlos, Maravilha, precisamos de mais colaboradores como você. Assim que você concluir as alterações/correções, por favor post como anexo somente as units que sofreram alterações. Desde já muito obrigado.
  16. Boa tarde Rodrigo, Com certeza o DAMDFE feito em Fortes Report esta com problemas. Você testou com a versão feita em Quick Report? Outra coisa importante, porque você esta alimentando a TAG: SegCodBarra? Essa TAG só é alimentada quando o CT-e ou NF-e foram emitidos em contingência FS-DA neste caso o DACTE ou DANFE possuem 2 códigos de barras.
  17. Boa tarde Rigotti, Favor atualizar os fontes e testar novamente.
  18. Bom dia Daniel, É o procedimento GerarXML que gera o conteúdo de ArquivoFormatoXML; Veja: LocCTeW.GerarXML; aCTe := LocCTeW.Gerador.ArquivoFormatoXML;
  19. Bom dia Dionatan, A partir do momento que o cancelamento se tornou um evento, não se atualiza mais o XML que foi assinado e autorizado pela SEFAZ. Estou me referindo a NF-e, CT-e, NFC-e e MDF-e. Temos agora 2 XMLs: Um é o XML do MDF-e assinado e Autorizado, o outro é o processamento do evento (*-procEventoMDFe.xml) que contem a solicitação do cancelamento e a homologação do mesmo com o numero do protocolo e tudo mais. Já existe uma especie de Documento Auxiliar para imprimir o evento, bastando carregar os 2 XMLs mencionados acima e executar o comando ImprimirEvento. É possível ainda gerar esse DA em PDF. Por favor estude o programa exemplo do MDF-e que nele você encontrar botões relacionados a Eventos. Da para imprimir não somente o evento de cancelamento como também o de Encerramento.
  20. Boa tarde Carlos, Por favor, poste o arquivo como anexo aqui mesmo no fórum.
  21. Daniel, Ao realizar a consulta, você esta carregando o componente com o conteúdo do CT-e? Se não estiver carregando o componente procura pelo XML do mesmo salvo em disco, bem como o *-sit.xml Se não encontrar o *-cte.xml ele não gerar o CTeDFe consequentemente a propriedade RetCTeDFe fica vazia.
  22. Boa tarde Dangelo, O componente ACBrNFSe gera o XML de envio e o submete a um validador próprio. O problema é que o componente esta gerando o XML esta validando-o segundo os schemas (arquivos XSD), para o componente o XML gerado esta em conformidade com os schemas, mas o provedor o recusa acusando que esta errado. Isso nos leva a crer que os schemas que estamos utilizando não condiz com o que o provedor esta utilizando. Se conseguíssemos os schemas corretos, teríamos condições de efetuar as correções na rotina que gera o XML e assim enviar ele corretamente. Resumindo a resposta do provedor: Se vira.
  23. Boa tarde Dorivan Sousa, Segundo o manual que você postou esse provedor não segue o padrão de estrutura e nomenclatura da ABRASF.
  24. Boa tarde Julio, O problema é que esse provedor não implementou o Web Service de Envio somente o Gerar.
  25. Boa tarde Daniel, Por favor atualize os fontes e teste novamente.
×
×
  • 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.