Italo Giurizzato Junior

Bom dia Walter, Temos o seguinte erro, ou melhor falha na validação: Element '{http://www.portalfiscal.inf.br/cte}vTotTrib' is unexpected according to content model of parent element '{http://www.portalfiscal.inf.br/cte}imp'. Expecting: {http://www.portalfiscal.inf.br/cte}infAdFisco. Vamos remover o desnecessário: Element 'vTotTrib' is unexpected according to content model of parent element 'imp'. Expecting: infAdFisco. Vamos traduzir: Elemento 'vTotTrib' é inesperado de acordo com o conteúdo do modelo do elemento pai 'imp'. Esperando: infAdFisco. Quando isso ocorre, pode ser 3 coisas: 1. o componente esta gerando o nome da tag de forma errada. 2. o componente esta gerando a tag em lugar errado. 3. o schema esta desatualizado. Foi eu que implementei essa tag no componente e realizei testes inclusive enviando para o ambiente de homologação, portanto o XML foi validado e aceito pela SEFAZ. Portanto descarto o 1 e o 2, isso me leva a crer que o schema que você tem esta desatualizado. Dentro da pasta ...\Exemplos\ACBrCTe\Delphi\Schemas temos varios arquivos XSD, vamos pegar um em especial: cteTiposBasico_v1.04 Abra ele com o bloco de notas e procure por vTotTrib. você vai encontrar a seguinte linha: <xs:element name="vTotTrib" type="TDec_1302" minOccurs="0"> ela vem logo depois da definição do elemento ICMS e antes do elemento infAdFisco, todos são elementos de um outro chamado imp. Você configurou o componente corretamente? Existe uma propriedade onde você informa o Path onde estão os arquivos XSD (schemas) Verifique se o arquivo schema citado acima que a sua aplicação esta utilizando possui o elemento vTotTrib, com certeza não tem, dai a falha na validação. Portanto utilize os XSD que estão na pasta acima citada.

Walter, o Valor de vTotTrib tem que ter no máximo 2 casas decimais.

Eduardo, E essa alteração foi com o intuito de resolver o que? Sem essas alterações qual era o erro? Da forma que estava antes, estava em conformaidade com o WSDL do provedor.

Boa tarde Walter, Post como anexo o XML dessa NFS-e que você tentou imprimir o DANFSE.

Diego, O componente esta gerando as TAGs segundo o schema. Como você pode notar, o XML foi gerado validado e enviado. Mas foi rejeitado. Portanto o schema que esta disponivel e consequentemente é o que você esta utilizando, esta errado. Por favor entre em contato com o pessoal do GovBR e solicite o schema usado por eles. Com o schema correto, vamos montar o XML e ele vai ser aceito pelo webservice.

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.