Italo Giurizzato Junior

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.

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.

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.

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.

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.

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.

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.

Boa tarde Laiza, Eu não tenho esse arquivo.

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.

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.

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.

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.

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.

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.

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.

Boa tarde Roberto, Já esta disponivel, muito obrigado pela colaboração.

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.

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?

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?

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.

Bom dia Luiza, Não entendi da necessidade do XSLT. Você não vai utilizar o componente ACBrCTe?

Bom dia Maciel, Dentro da pasta que contem os fontes do componente ACBrCTe, temos um arquivo TXT com um passo a passo para resolver esse problema.

Bom dia Jek, Alteração feita e disponibilizada, vamos aguardar se para as demais UF o problema se resolva desta forma também.

Bom dia Luighi, Esqueci de lhe dizer que alguns provedores não aceita o ( . ) ou seja o código do item formatado.

Bom dia Rogercon, Uma coisa não tem nada haver com outra. A propriedade tpMed se refere ao tipo de medida como por exemplo "Peso Bruto" ou "Peso Liquido", etc. logo temos que alimentar essa propriedade, caso contrario ocorre erro ao validar o XML do CT-e. O erro informando que não é possível se conectar com a SEFAZ ai já é outra história, você tem que checar se esse erro não esta sendo causado por Firewall, antivirus, proxy, ou até mesmo a falta de acesso a internet.