Italo Giurizzato Junior

Bom dia Mauricio, Já tentou realizar testes com uma maquina 32 bits? Outro teste é: incluir proBHISS na lista: if not (FProvedor in [proGovBr, proSimplISS, proAbaco, proISSNet, pro4R, proFiorilli, proProdata, proThema, proVirtual, proPVH, proBHISS]) Fonte: ACBrNFSeWebServices.pas Procedure: OnBeforePost

Bom dia Graça, Enviei para o SVN algumas alterações no componente ACBrMDFe. Favor atualizar todos os fontes, inclusive da pasta PCN2. É bem provavel que seja necessário recompilar o pacote do PCN2 e depois o pacote do ACBrMDFe. Pois foram incluidas novas propriedades ao componente.

Bom dia Tallys, O XML e o mecanismo de comunicação com o WebService é totalmente diferente do padrão ABRASF. A minha sugestão é desenvolver um componente para esse provedor e não realizar alterações no ACBrNFSe afim de atender esse provedor.

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.

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.

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

Boa noite Datilas, Estamos estudando uma forma diferente de resolver esse problema sem a necessidade de incluir uma propriedade nova no componente.

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?