Italo Giurizzato Junior

Ricardo, De uma lida no item 4.9.9, página 9, da NT 2012/002. Trata do final do processamento do lote, ou seja o envio da manifestação do destinatário para SEFAZ. Temos 3 situações em uma delas temos como retorno o status 135, o que vem a ser o status 135?

Boa tarde Hugo, Atualize os seus fontes e teste novamente.

Boa tarde João, Ao aparecer o erro, não apareceu um botão do tipo [ADD]? Se sim porque você não adicionou ? Com certeza você vai ter problemas.

Boa tarde Ricardo, Cuidado para não confundir as coisas: O Emitente ao consultar a nota que emitiu obtem o status dela, ou seja autorizada, denegada, rejeitada e os eventos associados a ela, cancelamento, carta de correção etc. O Destinatário apenas realiza uma consulta de notas destinadas a ele e realiza a manifestação. Se você configurou o componente para salvar os arquivos de envio e de retorno, você tem essa informação salva nele. Pegando o retorno após o envio: DM_VEN.IncAltDel.Params[1].AsDateTime := DMNFe.NFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.dhRegEvento; DM_VEN.IncAltDel.Params[2].AsString := DMNFe.NFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt; (...)

Boa tarde Graça, Remova o QR5RunD7 da lista de Requisitos do pacote de instalação do componente, compile ele novamente.

Eduardo, Atualize os fontes e teste novamente, por favor.

Atualize os fontes e teste novamente, por favor.

Diego, Para que não altere algo que não tem nada haver. Confirma para mim: O RPS esta sendo enviado para o webservice de qual cidade? Você esta usando os schemas do provedor dessa cidade?

Diego, Atualiza mais uma vez os fontes.

Diego, O XML do RPS que você postou não tem a data de emissão, você esta alimentando essa propriedade do componente? E no arquivo NFSE.zip não tem nenhum arquivo XML de NFS-e apenas os arquivos que são gerados antes e depois de assinar o lote, a ser enviado para o webservice.

Boa tarde Eduardo, Porque você incluiu "proProdata" na linha 110? Sendo que eu removi para que não ocorre-se mais o erro: "Falha na validação do lote ... Required attribute 'versao' is missing" Estude o código que você alterou, ele remove o atributo versao e coloca no lugar uma string vazia, e a mensagem de erro diz que esta faltando o atributo versao. Fiz mais uma alteração, atualize os fontes e testa novamente. Antes retire o "proProdata" da linha 110.

Boa tarde Graça, No ACBr.inc foi incluido a diretiva de compilação para a versão 2.00 veja: // Definições para o compomente ACBrCTe // Define o Pacote de Liberação / Descomente o pacote a ser utilizado // Atenção: descomente apenas uma das definições //------------------------------------------------------------------------------ //{$DEFINE PL_103} {$DEFINE PL_104} //{$DEFINE PL_200} No programa exemplo não tem nada a respeito disso. Você pode sim realizar testes, mas somente gerar, assinar e validar, uma vez que o ambiente de homologação ainda não esta disponivel. Esta faltando agora a questão das URLs dos WebServices se vão mudar ou não, do resto já esta tudo implementado, inclusive o novo grupo <autXML> onde você pode informar o CNPJ ou CPF da pessoa autorizada a realizar o Download do XML. Veja a última NT publicada. Detalhe importante, até a versão 1.04 os documentos originários ficavam dentro do grupo <rem> agora eles estão fora, sendo assim foi necessario fazer uma reformulações, veja este exemplo: {$IFDEF PL_200} with infCTeNorm.infDoc.infNF.Add do {$ELSE} with Rem.InfNF.Add do {$ENDIF} begin nRoma := DM_CNT.NotasRomaneioNF.AsString; nPed := DM_CNT.NotasPedidoNF.AsString; (...) end; Este fragmento de código é da minha aplicação, que já esta preparada para a nova versão.

Boa tarde Diego, Por favor post o XML do RPS e o da NFSe correspondente.

Boa tarde GVacaro, No Manual e nas Notas Técnicas, não consta nada sobre o assunto, nem sequer deixa claro quem vem a ser o Recebedor e o Expedidor. Acredito que, com a obrigatoriedade chegando para a grande maioria das transportadoras essas questões vão ser levantadas e talvez a SEFAZ resolva a publicar um NT sobre a maneira correta de informar os dados quando temos o redespacho. No meu entendimento o seu exemplo esta coerente. Leia essa explicação deste link: http://www.ophos.com.br/publicacoes/detalhe/ct-e-de-redespacho/

Bom dia Carlos, Atualiza os fontes e tenta novamente.

Eduardo, Por favor, atualiza os fontes e tenta novamente.

Bom dia Rodrigo, Você esta com todos os fontes de todas as pastas atualizados? Digo isso, pois acabo de fazer um teste, tanto o CEP do Remetente quanto o do Destinatário estão sendo impressos no DACTE. Outra coisa a propriedade CEP do componente é do tipo Integer, sendo assim como esta armazenado essa informação no banco de dados? Exemplo: 14800350 ou 14.800-350? Se esta armazenado com formatação, ao passar essa informação para o componente você esta removendo deixando apenas os digitos?

Bom dia Eduardo, Qual é o provedor?

Bom dia Walter, Se você pegar os schemas que estão dentro da pasta: ...\Exemplos\ACBrCTe\Delphi\Schemas é para funcionar desde que todos os arquivos de todas as pastas do ACBr estiverem atualizados. No momento a versão em uso do CT-e é 1.04 se você pegou o primeiro da lista, pegou os schemas que vão ser utilizados quando começar a versão 2.00 Outra coisa, note que o primeiro link dos schemas faz referencia a uma NT - Nota Técnica, você baixou essa NT? Leu o que esta escrito na página 2? Por favor, comece a fazer isso, baixar as NT e ler para ficar por dentro do assunto, uma vez que os componentes são criados e alterados com base nas NT e manuais.

Bom dia Welkson, Como eu não trabalho com automação comercial, não sei responder como é feita a implementação dessas aplicações. Mas temos duas questões a ser estudada. 1. conexão do PDV com o servidor on-line ou off-line 2. conexão com a internet ( NFC-e -> SEFAZ ) normal ou contingência. Me corrijam se eu estiver errado, no caso do ECF cada um tem uma numeração própria de documento, mas no caso da NFC-e como ficaria? O servidor deveria fornecer no momento de gerar o XML o numero da nota, neste caso a conexão do PDV com o servidor ja mais poderia ficar off-line. Talvez a saida para este caso seria utilizar um numero de série para cada PDV, desta forma poderiamos ter uma numeração de nota para cada PDV, ou seja quem forneceria o numero da nota seria o PDV e não o servidor, desta maneira ele poderia trabalhar off-line com o servidor. Com relação a segunda questão, conexão com a internet, existe a possibilidade da emissão do DANFE - NFC-e em contingência, mas não podemos tornar isso como sendo rotina e sim algo eventual. Sei perfeitamente bem que para o empresário a venda dos produtos é o negócio dele, mas ele tem que entender que, para que o negócio funcione há necessidade de um conjunto de ferramentas de trabalho funcionando também. E nós sabemos muito bem quais são. O tempo de vender e anotar no caderno, já passou e faz muito tempo.

Bom dia Graça, Por favor atulize novamente os fontes e tente novamente.

Bom dia lvr, Primeiramente muito obrigado pela colaboração e implementação de mais um provedor ao componente. As suas alterações e implementações já encontram-se disponiveis no SVN. Aproveitei para atualizar a lista de cidades que encontra-se salva no arquivo Cidades.rtf dentro da pasta ...\Exemplos\ACBrNFSe. Chegamos a 369 cidades atendidas pelo componente, isso se eu não esqueci de alguma. Muito obrigado a todos que colaboram com implementações, correções e testes.

Boa noite Rodrigo, Você já checou se o campo CL_CEP do destinatário contem o cep do mesmo?

Boa tarde Lucas, Vamos as perguntas classicas: Todos os fontes de todas as pastas estão atualizadas? Todos os schemas estão atualizados?

Ronnei, Entra em contato novamente com o pessoal do provedor e pede um exemplo de envio contendo as TAGs de Envelope ou soap como alguns chamam. Com esse exemplo fica mais fácil fazer as alterações e as chances de funcinar logo de primeira são grandes. Sem exemplos ou um documentação completa por parte deles fica dificil montar o XML de envio.