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. Bom dia sesistemas, Com base no seu XML e na mensagem, veja: Mensagem: Rejeicao: Data de entrada em contingencia posterior a data de emissao. XML: (...) <dhEmi>2013-11-22T00:00:00</dhEmi> (...) <dhCont>2013-11-22T17:02:06</dhCont> (...) A mensagem é clara e mostra o que você esta fazendo de errado. Note Data e Hora de Emissão: 22/11/2013 as 00:00:00, Data e Hora de Contingência: 22/11/2013 as 17:02:06 Se o inicio da contingência foi as 17 horas e você esta emitindo as 00 horas, concorda que esta errado. A Data e Hora de Contingência sempre tem que ser anterior a Data e Hora de Emissão. Manual do CT-e versão 1.04c, página 35, Regra de validação G004c.
  2. Bom dia Datilas, A principio não existe problema nenhum em criar uma nova propriedade. Inclusive já propus varias vezes a criação de novas propriedades. O problema que eu vejo é que quando se cria uma nova propriedade ela só aparece no Object Inspector depois que você reinstala o componente novamente ou abra o pacote de instalação do mesmo e o compile novamente. Uma solução, o Grupo IPI não deve ser gerado no XML quando o documento fiscal for a NFC-e, correto? Sendo assim, em vez de você criar uma nova propriedade que diz se é ou não para gerar o grupo IPI, porque não checar o modelo de documento fiscal? Se o modelo for 65, ou seja, NFC-e não gera, caso contrario gera.
  3. Boa noite Adilson, Se a versão do seu Quick Report não for a 5, favor abrir o pacote de instalação e remover: QR5RunD7 deixando a linha da seguinte forma: {$IFDEF VER150} vcljpg, visualclx; {$ENDIF} // D7
  4. Boa noite Datilas, Estamos estudando uma forma diferente de resolver esse problema sem a necessidade de incluir uma propriedade nova no componente.
  5. Boa tarde Elaine, Como você fez o Download do XML através do site, isso explica algumas coisas, como por exemplo as TAGs que mencionei no post anterior. Dentro do grupo <CTeDFe> temos o grupo <procCTe> onde vou chamar a atenção de 3 coisas: 1. Você informou o local de entrega, lembre-se só devemos informar esses dados quando o local de entrega for diferente do endereço do destinatário, e no seu caso são iguais. 2. A SEFAZ esta retornando a versão errada no grupo <protCTe> esta aparecendo versão 1.00 sendo que o correto é 2.00, logo isso é um erro da SEFAZ. 3. A versão do aplicativo da SEFAZ é SP-CTe-14-11-2013, isso mostra que tem muita coisa para ser corrigida, pois hoje é 22/11/2013, ou seja, faz uma semana que eles alteraram as aplicações deles. Depois temos o grupo <procEventoCTe> note que a versão também esta errada o correto é 2.00 e não 1.00 Dentro deste grupo temos o grupo <retEventoCTe> que também esta com a versão errada e não esta retornando o código do Orgão esta aparecendo apenas: <cOrgao /> E as NOVE cartas de correções que você enviou para esse CT-e estão todas relacionadas nesse retorno. Sugestão: Entrar em contato com a SEFAZ relatando esses problemas, de numero de versões erradas e a falta do código do Orgão no grupo de retorno do evento e não esquecer de mencionar que ao realizar uma consulta no site aparece o evento de EPEC em vez de CC-e e outra coisa só esta aparecendo o primeiro evento, ou seja a primeira CC-e, sendo que você enviou 9 esta faltando mostrar as outras 8.
  6. Idez, Não, o que eu quiz dizer é quando o CTe é do tipo normal apenas informamos que é o Remente e o Destinatário. Quando se trata de Redespacho ou Redespacho Intermediario não há necessidade de informar quem é o Remente e ou Destinatário, mas por outro lado informamos o Expedidor e ou Recebedor.
  7. Boa tarde Elaine, Acredito que deve ser as mudanças que a SEFAZ esta realizando. Inclusive tem mais coisas estranhas: <retCTeConsultaDFe ???? <CTeDFe> ???? Essas TAGs não existem no manual.
  8. Boa tarde Idez, Se o CT-e for do tipo Normal, não há necessidade de informar o Expedidor ou Recebedor, apenas o Remetente e o Destinatário. Normalmente informamos o Expedidor e/ou Recebedor quando se trata de Redespacho ou Redespacho Intermediário.
  9. Boa tarde Vinícius, Realize todas as alterações necessárias para que o componente funcione 100% com esse provedor. Depois você posta como anexo aqui no fórum somente os fontes que você alterou.
  10. Boa tarde a todos, Quero informa-los que as alterações necessárias ( espero não ter esquecido de nada ) já foram realizadas. Não esta disponivel ainda pois os meus fontes também contem as alterações para a versão 3.10 tanto da NF-e quanto da NFC-e. Assim que eu receber o aval, vou disponibilizar.
  11. Boa tarde Rogercon, Lembre-se duvida nova, tópico novo. Mas, antes de postar favor pesquisar no fórum, talvez a sua duvida já esteja respondida, desta forma você não fica esperando alguem responder ou levar uma bronca, pois já existem tópicos com o mesmo assunto. Outra coisa, baixe o manual e imprima ele, se desejar imprima somente as folhas que contem a estrutura do XML do CTe, desta forma você vai conhecer todas as TAGs, se são obrigatórias ou não, seus tipos e para que serve. Vai ai uma dica, na pasta ...\Exemplos\ACBrCTe existem vários arquivos TXT com fragmentos de códigos, imprima e estude-os. Lhe garanto que as duvidas que estão hoje povoando a sua cabeça vão ser respondidas pelo manual e por esses arquivos. Mas fique a vontade em postar, mas lembre-se de pesquisar antes.
  12. Boa tarde Laiza, Eu não tenho esse arquivo.
  13. Bom dia Rogercon, Note que na imagem consta que a aprece a mensagem: Credenciado mas não obrigatório. Mas a data de entrada no ambiente de homologação esta em branco idem no de produção. Isso me leva a crer que algo esta errado. Eu nunca participei do processo de credenciamento de uma empresa para que a mesma pudesse emitir CT-e. Mas acredito que não foi solicitado a liberação do ambiente de homologação e produção para esta empresa. O contador dessa empresa esta comendo bronha.
  14. Boa noite asbalexandre, Se o certificado fosse A1, você poderia instala-lo em todas as maquinas que vão emitir o CT-e. Mas como se trata de um certificado A3 (token = pen drive) a saída é: 1. Todos os usuários lançam os conhecimentos e apenas um fica incumbido de enviar, por ter o certificado instalado. 2. Todos os usuários lançam os conhecimentos e a maquina que possui o certificado instalado, teria um segundo programa que de tempo em tempo checa os conhecimentos lançados no banco de dados e não enviados e realiza o envio e a atualização do banco de dados.
  15. Boa noite rogercon, Estou notando que você esta alimentando o componente sem muito conhecimentos, principalmente, no que diz respeito ao documento originário. Aconselho você baixar do Portal Nacional do CT-e o manual e ler com muita atenção as paginas que diz respeito a estrutura do XML.
  16. Vinícius, Se você esta com todos os fontes atualizados, inclusive os do programa exemplo, note que ele não tem nenhum botão chamado Validar. Temos o botão Gerar RPS, mas este é só para você ver como é que fica o XML do mesmo. Dependendo do provedor devemos utilizar: [Gerar e Enviar Lote] envia um lote com até 50 RPS ou [Gerar e Enviar NFSe] na verdade envia um lote com apenas 1 RPS ou [Gerar e Enviar Lote - Sincrono] envia um lote com até 50 RPS mas no modo sincrono. Já o [Gerar Lote RPS] apenas gera o XML do lote e salva em disco, pois existe um provedor que não disponibilizou o webservice ainda. Neste caso é gerado o XML do lote e ao acessar o site desse provedor temos a opção para importar o XML. As demais funcionalidades estão implementadas dentro das outras. Ou seja o Enviar realiza as seguites tarefas: Gera o XML do RPS; Assina se necessario o RPS; Gera o Lote; Assina se necessario o Lote; Valida o Lote; Envia; Consulta a Situação do Lote; Consulta o Lote; Imprimie o DANFSE.
  17. Boa tarde rogercon, Respondendo a sua pergunta se todo CTe precisa ter uma NFe referenciada, a resposta é depende. Primeiramente estou levando em consideração quando você diz NF-e referenciada, como sendo o documento originário que acoberda a comercialização da mercadoria que foi comercializada. A minha resposta é depende pois o documento originário pode ser uma NF-e ou uma NF comum (papel) ou outro tipo de documento por exemplo uma declaração. Verifique realmente se você esta informando corretamente o ambiente, pois algumas pessoas se queixaram do ambiente de homologação que recusava a NF-e informada como documento originário.
  18. Boa tarde Oneide, É complicado realizarmos alterações nos schemas, porque: 1. Alterando o schema vamos conseguir validar o XML; 2. O webservice ao receber o XML vai também submete-lo ao seu próprio validador que por sua vez pode recusar pois a IM tem "-". 3. Se não alterar o schema não podemos colocar a IM com o "-", caso contrario não é validado pelo componente. 4. O webservice recebe o XML ao validar o mesmo entre outras coisas checa que a IM sem "-" não consta no cadastro do provedor, consequentemente é rejeitado. Resumindo tudo tem que estar em conformidade. O validador do provedor trata a IM como sendo um numero ou como sendo uma string? Se trata como numero não deveria deixar cadastrar uma empresa informado a IM com "-". O provedor tem que fornecer os schemas oficiais.
  19. Boa tarde Professor, Para muitos provedores o acesso ao site é uma coisa, já o acesso ao webservice é outra. Verifique junto ao provedor se há necessidade de efetuar um novo cadastro para utilizar o webservice.
  20. Boa tarde Roberto, Já esta disponivel, muito obrigado pela colaboração.
  21. Boa tarde Vinícius, Tudo o que você sabe sobre NF-e e CT-e esqueçe, não funciona para a NFS-e. Uma delas o Valida. Que na NF-e, validamos cada NF-e. Já na NFS-e o que é validado é o lote e não o RPS, logo não adianta querer gerar o XML do RPS e posteriormente validar. A validação ocorre automaticamente logo após a montagem do lote que vai ser enviado.
  22. Rogercon, Você esta utilizando um certificado digital para assinar o CT-e e enviar para SEFAZ, correto? Esse certificado é de uma pessoa juridica? Se sim, trata-se de uma transportadora? Se sim, foi feito o credenciamento junto a SEFAZ da UF que ela é contribuinte?
  23. Tallys, Isso não os schemas de validação e muito menos o XML de um RPS ou Lote de RPS. O que lhe passaram é o WSDL do webservice deles e pelo que pude ver esta muito estranho é totalmente diferente dos que já vi. Esse pessoal estão entendendo que se trata de NFS-e e não outra coisa? Eles sabem o que vem a ser schemas - XSD, RPS, XML, certificado digital, etc?
  24. Bom dia Oneide, Acredito que o problema é simples de tudo. Primeiro entre em contato com o provedor Betha e solicite a eles os schemas oficiais, ou seja, o que deve ser utilizado para validar o lote quando for enviar para eles. Se com esses schemas o problema persistir, então você deve solicitar a eles que removam o "-" do numero da IM no cadastro deles. Se os schemas que hoje é disponibilizado estiver errado, por favor, post como anexo os novos que você consegui com o provedor. Por outro lado se o problema não é os schemas, você tem que resolver com eles alterando essa informação no cadastro deles.
  25. Bom dia Luiza, Não entendi da necessidade do XSLT. Você não vai utilizar o componente ACBrCTe?
×
×
  • 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.