Italo Giurizzato Junior

Boa tarde Luiz, Se não me falha a memória em ambiente de homologação é possível realizar todos os testes sem a necessidade do certificado digital. Neste caso você não deve informar o numero de serie, senha, caminho ou conteúdo do arquivo PFX ao configurar o componente. Veja no programa exemplo, que existe uma linha que determina se o certificado vai ser utilizado ou não. // Não for informado nenhuma informação a respeito do certificado // o componente será configurado para não carregar o certificado. ACBrCIOT1.SSL.UseCertificateHTTP := (edtCaminho.Text <> '') or (edtSenha.Text <> '') or (edtNumSerie.Text <> '');

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Warley, Você esta usando o componente ACBrCTe para gerar o XML? Até onde sei a string do QR-Code deve ficar dentro do CDATA, sendo assim podemos ter o caractere & sem nenhum problema na string, ou seja, não se faz necessário a sua conversão. Pela mensagem de rejeição não tem nada haver com esse caractere e sim com relação a URL. Você esta enviando o CT-e para a SVCSP - SEFAZ-Virtual de Contingência de São Paulo e não para a SEFAZ-MG. Favor entrar em contato com a SEFAZ-MG e questiona-los sobre qual a URL deve ser utilizada no caso do envio para a SVCSP.

Boa tarde, Me diz uma coisa, você esta incluído o componente ACBrNFe em cada Form que ele é utilizado? Não ficaria muito mais simples colocar o componente ACBrNFe e a rotina de configuração em um DataModule? Pois desta forma você não vai esquecer de corrigir alguma configuração. Ao consultar a nota no site, ele tem alguma opção de você escolher o ambiente (Homologação ou Produção)?

Boa tarde Thiago, Essa consulta foi feita no Portal Nacional do CT-e? Se sim, com certeza é problema deles.

Bom dia Luiz, O eFrete não disponibilizou os Schemas, logo indica a mesma pasta de schemas do CT-e ou da NF-e. A rotina que configura o componente esta sendo executada antes da realização do envio? No programa exemplo ocorre o mesmo erro?

Bom dia Jackeline, Muito obrigado pela colaboração, já enviei para o repositório. Observações: 1. Os seus fontes em particular os arquivos INI estão desatualizados. 2. Se tratando de troca de provedor, inclusão de novas cidades, favor postar no tópico que foi criado exclusivamente para isso.

Bom dia Carlos, Analisando o Schema desse provedor notei que essa terceira assinatura é opcional, logo pelo Schema ela não se faz necessária. Note que a mensagem de rejeição se refere a assinatura do RPS que o webservice acusa que esta invalida e não a ausência da assinatura da substituição.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa noite Luiz, Antes de executar o método Enviar, você esta configurando o componente corretamente? Sugiro você estudar o código do programa exemplo.

Bom dia Eduardo, Você esta com todos os fontes de todas as pastas atualizados? Se sim, notou que o programa exemplo possui dois botões de envio, um para o modo assíncrono e outro para o síncrono? Chegou a estudar o conteúdo desses 2 botões? Notou que o método de envio é exatamente o mesmo para ambos os modos? O que muda são os parâmetros. Como o primeiro parâmetro do método é o numero do lote, mesmo que você vá enviar apenas um CT-e ou vários devemos informar o numero do lote.

Olá pessoal, Existem provedores que possuem uma lista de serviços outros apenas um único campo chamado Discriminação para que possamos informar o(s) serviço(s) executado(s). Para os provedores que possuem uma lista devemos atribuir o valor True a propriedade DetalharServico da seguinte forma: ACBrNFSeDANFSeRL1.DetalharServico := True; Fica ai a dica.

Eduardo, No modo síncrono o envio é unitário, ou seja, só é possível o envio de apenas um CT-e por vez. Já no modo assíncrono o envio é por lote, portanto é possível o envio de até 50 CT-e por vez. O componente ACBrCTe trabalha com 2 modelos de documentos: 1 . CT-e ==> Conhecimento de Transporte Eletrônico, onde todas as SEFAZ tem o serviço de recepção assíncrono, somente as SEFAZ do MS, MT, RS e SVRS que atende as UF ( AC, AL, AM, BA, CE, DF, ES, GO, MA, PA, PB, PI, RJ, RN, RO, SC e TO ) que disponibilizaram a recepção síncrona. 2. CT-e OS ==> Conhecimento de Transporte Eletrônico Outros Serviços, este modelo de documento o envio sempre vai ser unitário e portanto só foi disponibilizado por todas as SEFAZ a recepção síncrona. Resumindo: CT-e o envio é assíncrono e o lote pode ter de 1 até 50 CT-e. CT-e OS o envio é síncrono, portanto só é possível enviar apenas 1 CT-e OS por vez. Lembrando que no modo assíncrono se faz necessário uma consulta depois do envio para poder obter o resultado do processamento. Já no modo síncrono já temos o resultado do processamento no retorno do envio.

Boa noite Eduardo, Solicite ao provedor uma documentação de como utilizar o webservice.

Boa noite Eduardo, A explicação é muito simples, a SEFAZ-SP ainda não disponibilizou o serviço para recepcionar o CT-e em modo Síncrono, somente assíncrono.

Boa tarde Marcel, Na pasta X não tem nenhuma DDL e roda sem nenhum problema, correto? E na pasta Y tem as DLLs? Se sim, esse pode ser o problema, pois essas DLLs estão erradas. Neste caso exclua as DLLs da pasta Y.

Boa tarde Carlos, Pelo que notei esse provedor requer que o pedido de cancelamento que se encontra dentro do SubstituirNFSe esteja assinado bem como o RPS e requer uma terceira assinatura que se refere ao Substituir. Me parece que o componente não esta realizando essa terceira assinatura.

Boa tarde Paulo, Favor atualizar os fontes, já fiz a alteração. Muito obrigado pela correção.

Eduardo, Muitos provedores foram implementados no componente pelos desenvolvedores como você. Se esta aparecendo esse erro, isso significa que na época foi constatado que havia a necessidade de informar um usuário e senha que é acrescentado no XML que é enviado para o webservice do provedor.

Boa tarde Thiago, Pelo que entendi esse CT-e Globalizado contem apenas UM Remente e DIVERSOS Destinatários, correto? Se sim, o tomador do serviço tem que ser o Remetente. Não vejo o porque do Destinatário querer o XML desse CT-e, no meu entendimento ele não vai utilizar ele para nada. O que o Destinatário precisa é do XML ou o DANFE da NF-e para que ele possa dar entrada da mercadoria que ele comprou. Por outro lado o Remente que é o tomador do serviço, esse sim tem o direito de receber o XML e o DACTE do CT-e, uma vez ele vai contabilizar e registrar no consta a pagar a prestação desse serviço realizado pela transportadora.

Boa tarde Eduardo, Na primeira imagem notei que você esta informando o caminho com o nome do arquivo PFX, senha e o numero de serie, não precisa de tudo isso. Se o certificado estiver instalado na maquina, informe somente o numero de serie do mesmo. Agora se não estiver instalado, você pode informar o caminho com o nome do arquivo PFX e a senha do certificado. Pelo jeito a configuração do SSLType correta é o LT_TLSv1_2, pois com essa configuração a conexão com o webservice ocorreu e ele respondeu. Quanto a mensagem de erro apresentado na segunda imagem, indica que o prestador de serviço não esta cadastrado no webservice para emissão de NFS-e. Lembre-se que uma coisa realizar um cadastro para emitir nota via site e outra é emitir via webservice.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Jalmir, Pelo XML de gravar o motorista notei que ele não foi gerado pelo componente ACBrCIOT.

Bom dia Joyce, Você utiliza o componente ACBrNFSe para emitir a NFS-e? Esse XML de consulta não é feito pelo componente, pois essa consulta se refere a consultar NFS-e de serviço tomado, ou seja, trata-se de uma consulta feita pelo tomador e não pelo prestador. Com certeza esse XML não foi gerado pelo componente, pois no final dele contem um comentário, os XMLs gerados pelo componente não contem nenhum comentário.

Olá Pessoal, Já esta disponível o Portal da Nota Fiscal Fácil, vale a pena acessar e conferir. Para acessar o Portal clique aqui. De forma bem resumida, o Fisco vai disponibilizar um App para os dispositivos móveis que tem como objetivo tornar fácil a emissão de NF-e, NFC-e, CT-e e MDF-e. No portal encontramos uma explicação sobre a NFF, uma apresentação em Power Point e o Ajuste SINIEF 37/19, que institui o regime especial de simplificação do processo de emissão de documentos fiscais eletrônicos. Do lado direito da pagina do portal encontramos os links para baixar o App (mas ele ainda não esta disponível) e também o link para o FAQ. Fica ai a dica.