Ir para conteúdo
  • Cadastre-se

italo.giurizzato.junior

Consultores
  • Total de ítens

    42.831
  • Registro em

  • Última visita

  • Days Won

    1.244

Tudo que italo.giurizzato.junior postou

  1. Boa tarde dpbraz, A mensagem esta incompleta, mas tudo indica que o numero do protocolo não esta sendo informado por completo ou não foi informado.
  2. Boa tarde Josemar, O problema é a chave do CT-e que não esta completa. Ela é usada para compor o conteúdo do atributo ID como a chave esta incompleta o tamanho desse atributo que tem que ter 52 caracteres esta fincando com menos dai a mensagem de erro ao validar o XML de solicitação de cancelamento.
  3. O único problema que vejo, ao atribuir o valor False a essa propriedade é: 1. Ocorre o envio do CT-e. 2. Por algum problema qualquer o CT-e fica sem o protocolo de autorização. 3. O usuário esquece de realizar a consulta para corrigir o problema. 4. Ocorre o canelamento do CT-e por desacordo comercial (por exemplo). 5. O cliente reclama da ausência do protocolo. 6. O usuário realiza a consulta para corrigir o XML. É justamente no item 6 que se a propriedade atualizarxmlcancelado estiver com o valor False, ao realizar a consulta vai ser retornado que o CT-e esta cancelado e consequentemente não será atualizado, continuando assim sem nenhum protocolo de autorização ou de cancelamento.
  4. Boa tarde Robinho, No caso do encerramento temos que informar a UF e a Cidade de descarregamento da carga. Não sei se seria o correto, mas uma alternativa seria efetuar o encerramento informado (segundo o seu exemplo) a UF = ES e a cidade a última do itinerário do caminhão. Uma outra alternativa seria emitir um MDF-e para cada cidade de descarregamento e consequentemente efetuar o encerramento individual. O ideal seria neste caso a cada partida do caminhão para a próxima cidade, o motorista informa para que a empresa realiza-se o encerramento do MDF-e correspondente a cidade cuja parte da carga foi descarregada.
  5. Boa tarde DocFabio, Após alimentar o componente com os dados do destinatário você esta fazendo isso? // TpcnDestinoOperacao = (doInterna, doInterestadual, doExterior); if Dest.EnderDest.UF = 'EX' then ide.idDest := doExterior else if Dest.EnderDest.UF = Emit.EnderEmit.UF then ide.idDest := doInterna else ide.idDest := doInterestadual;
  6. Boa tarde Edulamy, O correto é o Remetente da mercadoria emite Cupom Fiscal, se ele é o tomador do serviço ou não é outra história. Acredito que neste caso a alternativa seria informar esse Cupom Fiscal como sendo "Outros". Um CT-e pode ter como documento originário ou seja o documento emitido pelo Remetente da mercadoria um dos 3 tipos abaixo: 1. NF-e - Nota Fiscal Eletrônica 2. NF - Nota Fiscal comum de papel 3. Outros - por exemplo uma declaração
  7. Boa tarde Mauricio, Exclua a pasta: ...\Exemplos\ACBrCTe\Delphi e atualize tudo novamente, depois tente abrir o programa exemplo.
  8. Boa tarde Maiko, Você chegou a estudar a estrutura do XML (CT-e versão 2.00)? Esta disponível no Portal Nacional do CT-e o Manual versão 2.00a do CT-e.
  9. Boa tarde Reij, Por favor leia a NT 2012/002 (página 3) item 4.9 existe um paragrafo que se refere ao certificado digital.
  10. Boa tarde dfdixini, Por outro lado veja este: 28140117957142000144570170000000171480288025-sit.xml Note que a SEFAZ Virtual RS retorna que o CT-e esta cancelado, mas apresenta o protocolo de autorização em seguida a solicitação de cancelamento e por fim o protocolo de cancelamento. Que no meu entendimento é o mais correto. Já a SEFAZ-SP esta retornando que o CT-e esta cancelado, depois o protocolo de cancelamento em seguida a solicitação de cancelamento e por fim novamente o procolo de cancelamento. Porque ao realizar a consulta o XML do CT-e esta ficando com o protocolo de cancelamento em fez do de autorização, conforme eu tinha dito? Simples o componente esta extraindo desse retorno os dados do grupo <infProt>. Como da SEFAZ-SP temos os dados do protocolo de cancelamento o XML do CT-e fica com o protocolo de cancelamento.
  11. Boa tarde Eduardo, Quando você baixa o XML do site da SEFAZ, a mesma alem de retornar o XML do CT-e acrescenta ao seu final os eventos vinculados ao mesmo. O componente ACBrCTe já possui esse recurso. Ao consultar a situação atual de um CT-e, caso este possua eventos: CC-e, Cancelamento, etc é salvo (caso configurado) o arquivo: <chave>-CTeDFe.xml Cuja estrutura é idêntica a do XML baixado da SEFAZ.
  12. Bom dia, Você tem o arquivo *-sit.xml da consulta e o *-procEventoCTe.xml do cancelamento? Se sim, seria possível posta-los como anexo?
  13. Bom dia a todos, Se não me falha a memória para algumas versões do Quick Report há necessidade de comentar alguns .Free para eliminar esse problema. Esses Free estão no ACBrCTeDACTeQR.
  14. Boa noite Junior, Se não me falha a memória esse provedor não segue o padrão ABRASF esse é um dos motivos pelo qual até agora ninguém implementou esse provedor no componente.
  15. Boa noite, E os schemas, são da versão 2.00? Antes de executar o Valida, execute o Assinar, desta forma vamos ter o XML salvo em disco. Com o XML fica mais fácil analisar o problema.
  16. Boa noite Fernando, Exclua os fontes referentes ao DACTE e baixe novamente, depois procede o passo a passo novamente. Um dos fontes deve estar desatualizado em relação aos demais.
  17. Boa tarde Lucas, A propriedade MunicipioIncidencia é destinado a versão 2 da NFS-e, no caso do Ginfes que ainda se utiliza da versão 1.0 você deve alimentar somente a propriedade CodigoMunicipio. Acredito eu que você deve informar o código do município onde o serviço foi prestado.
  18. Boa tarde Jefferson, Se você se refere a NFS-e e o DANFSE feito em Quick Report a resposta é não.
  19. Boa tarde a todos, O remetente (emitente do documento originário) pode muito bem acabar emitindo 2 ou mais notas para o mesmo cliente no mesmo dia ou no dia seguinte por exemplo. A transportadora por sua vez pode incluir todas essas notas em um único CT-e desde que o remetente e o destinatário seja o mesmo. Uma prova disso é que o grupo <infNFe> pode possuir uma lista com até 2000 notas. Todos a de concordar, se essa possibilidade fosse ilegal, primeiro a SEFAZ iria rejeitar, mas não o fez, portanto o XML assinado e com o protocolo de autorização de uso, temos portanto um documento fiscal válido juridicamente. Sendo assim, como a nossa amiga Jeanny eu também acredito que o fiscal ou esta muito mau informado e orientado ou quer tirar proveito da situação. A autuação pode ser derrubada com esse pequeno trecho do Ajuste Sinief numero 9 de 25 de outubro de 2007: (...) Cláusula quinta O CT-e deverá ser emitido com base em leiaute estabelecido no MOC, por meio de software desenvolvido ou adquirido pelo contribuinte ou disponibilizado pela administração tributária. § 1º O arquivo digital do CT-e deverá: I - conter os dados dos documentos fiscais relativos à carga transportada; II - ser identificado por chave de acesso composta por código numérico gerado pelo emitente, CNPJ do emitente, número e série do CT-e; III - ser elaborado no padrão XML (Extended Markup Language); IV - possuir numeração seqüencial de 1 a 999.999.999, por estabelecimento e por série, devendo ser reiniciada quando atingido esse limite; V - ser assinado digitalmente pelo emitente. (...) Os negritos em vermelho é por minha conta. A clausula quita deixa clara que o XML será gerado segundo o Layout estabelecido no MOC - Manual de Orientações do Contribuinte e nele diz que podemos ter até 2000 notas. Note que o inciso I do primeiro paragrafo faz referencia ao documento originário no plural, mas uma prova que podemos ter no mesmo CT-e mais de uma nota. Espero ter ajudado.
  20. Boa tarde Adir, Muito obrigado pelo alerta, já efetuei a correção e disponibilizei.
  21. Bom dia Adir, Muito obrigado pela colaboração, já esta disponível.
  22. Bom dia Caetano, Qual lista você se refere? É aquela lista disponível dentro da pasta: ...\Exemplos\ACBrNFSe? Se sim, esquece pois ela esta desatualizada. A cidade de João Pessoa/PB não é mais atendida pelo provedor Ginfes e sim pelo SisPMJP. Para saber qual é o provedor de uma determinada cidade basta executar o programa exemplo, nele temos um botão para realizar essa consulta. Você deve informar o código IBGE da cidade, que no caso de João Pessoa é 2507507.
  23. Bom dia Anselmo, Eu utilizava a versão 3 e ao passar para a 5 esse problema não tive. Somente um detalhe na versão 3 a visualização é em tela cheia por padrão e no 5 não, é preciso configurar cada um dos relatórios.
  24. Bom dia cspimenta, Muito obrigado pela colaboração, já esta disponível.
  25. Bom dia a todos, Gustavo o procedimento continua o mesmo que você descreveu. Só lembrando que tem o Enviar o Evento por E-mail e gerar o PDF do mesmo. Todas esses procedimentos podem ser vistos no programa exemplo.
×
×
  • 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.