Italo Giurizzato Junior

Boa tarde Fábio, Alem de alterar o INI será necessário alterar o XSD do provedor também?

Boa noite Graça, Pelo método DistribuicaoDFe sendo executado pelo emitente da NF-e não é retornado os eventos referentes a emissão do CT-e e MDF-e? E nesses eventos não é retornado a chaves desses documentos? Analisando o retorno do método, se tratando do CT-e é retornado a chave e o numero de protocolo do mesmo.

Boa noite Thiago, Imagina a seguinte situação: A carga será transportada do Remetente X até o Destinatário Y, mas o tomador, ou seja, quem vai pagar o frete é Z empresa matriz cuja filial é a empresa Y. Neste caso devemos informar que o tomador é Outros e com isso informar todos os dados desse tomador.

Boa noite Murilo, Dentro da pasta: ...\Exemplos\ACBrDFe\ACBrMDFe tem um arquivo chamado: AlimentarComponente.txt Procure por: // ======== Dados do Percurso ===========================================

Boa tarde Mateus, Qual é a Cidade / Provedor?

Boa tarde, Os provedores que seguem a versão 1 do ABRASF só tem implementado em seus Web Services o Serviço Enviar, logo os outros 2 não tem como usar. Por outro lado os provedores que seguem a versão 2 do ABRASF costuma ter os 3 métodos. Já os provedores que não seguem a ABRASF, é preciso abrir o arquivo INI do mesmo para saber o que esta disponível. Qual é a diferença entre eles? Enviar -> permite enviar um lote com até 50 RPS e o modo de envio é assíncrono. EnviarSincrono -> permite enviar um lote com até 50 RPS e o mode de envio é síncrono Gerar -> permite enviar somente UM RPS, tem uns 2 ou 3 provedores que permitem o envio de até 3 RPS através desse método.

Boa tarde Billarsch, Você esta usando os fontes do repositório Trunk2? Se sim, todos os fontes de todas as pastas estão atualizados? Se sim, dentro da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI você vai encontrar os arquivos: Cidades.ini e SP.ini necessários para que o componente ACBrNFSe seja capaz de emitir a NFS-e para a cidade de São Paulo. E dentro da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\SP temos os arquivos XSD (Schemas) usados pelo componente para validar o XML do RPS antes do envio para o Web Services.

Bom dia ALA, Até onde sei a cidade de Montes Claro se utiliza do provedor EReceita que segue a versão 2 do layout da ABRASF e portanto já se encontra implementado no componente. Não tenho nenhum retorno com a informação se o mesmo esta funcionando 100%. Caso você tenha condições de realizar testes e reportar os resultados com esse provedor lhe agradeço

Bom dia Thiago, Segundo o Manual versão 2.00a do CT-e - página 150 campo: 43 <moto> podemos ter "N", mas só devemos informar o(s) motorista(s) quando se tratar de um CT-e Rodoviário e Lotação, ou seja, a carga não pode ser fracionada. Dica, como já foi liberado para teste a versão 3.00 do CT-e aconselho você desenvolver a sua aplicação baseado nesse manual. Na versão 3.00 não será mais informado o motorista, pois este será informado no MDF-e que deverá ser emitido também.

Boa noite Vanderlei, Esse XML não é o envelopado,simplesmente é um exemplo do XML de envio do Lote, sem o envelopamento.

Boa noite, O numero do protocolo no caso da NFS-e tem o mesmo significado do numero do recibo ao enviar uma NF-e. Ou seja só serve para lhe informar que o web service recebeu o lote. Sendo assim o numero do protocolo da NFS-e só é retorno ao enviar o lote.

Boa noite Michel, Lhe peço que preste mais atenção antes de postar, pois esse fórum se referem ao componente ACBrNFSe e não o ACBrNFe. Pela imagem do erro nem chega realizar o envio.

Boa noite Mateus, Já tentou alterar o valor da propriedade SSLLib de libCapicom para libCapicomDelphiSoap ou vice versao.

Boa noite Alexandre, Muito obrigado pela colaboração, assim que possível estarei enviando para o repositório.

Boa noite, Favor anexar o arquivo completo para que possamos realizar testes.

Boa noite Jedhaias, Você esta usando o componente ACBrNFSe?

Boa noite Veríssimo, Ao consultar a situação de um CT-e se não me falha a memória o componente só trata o retorno referente a situação do mesmo, os eventos que por ventura existam o componente os ignora. Por outro lado se antes de realizar a consulta você carregar o componente com o XML do CT-e será gerado um XML chamado *-DFeCTe.xml Este arquivo ele contem o XML do CT-e, a assinatura, o protocolo de autorização, mais os eventos vinculados ao mesmo.

Boa tarde Veríssimo, Você notou que no XML hora aparece que a versão é 2.00 e hora aparece a versão 3.00? Pois bem, acredito que a SEFAZ esteja com algum bug no ambiente de homologação que esta misturando as bolas.

Boa noite Thiago, Não, o primeiro sempre tem que ser tração.

Boa noite Veríssimo, Você esta fazendo testes com a versão 3.00 do CT-e? Se não esta, então é a SEFAZ-SP que esta bagunçando o coreto.

Boa noite Augusto, Muito obrigado pela colaboração, já enviei para o repositório.

Boa noite Veríssimo, Favor anexar o XML e não posta-lo como texto. Da forma que esta não temos como analisar o problema.

Boa noite Eliezer, Muito obrigado pela colaboração, já esta no repositório.

Boa noite Roberto, Sim, mas o componente já os utiliza automaticamente.

Boa noite Marcio, Em vez de enviar novamente, porque você não carrega o XML do CT-e através do LoadFromFile, em seguida executa o método Consultar? Se o CT-e realmente foi enviado, ao executar o método Consultar, o XML do CT-e será atualizado com o protocolo de autorização. Por outro lado se o problema foi logo no envio, retornara que o CT-e não existe no banco de dados, ai sim você envia ele novamente.