Italo Giurizzato Junior

Bom dia a todos, Encontra-se no Portal Nacional do MDF-e um link para baixar a Cartilha Nacional do MDF-e, trata-se de um PDF de 21 páginas. Quem implementou ou vai implementar o MDF-e, por favor baixe essa cartilha, pois ela traz informações que vão ajudar na implementação bem como orientar o emitente em diversas situações de emissão. Não se trata de um documento técnico destinado ao desenvolvedor mas contem informações que ajuda tanto o desenvolvedor como o emitente. Fica ai a dica.

Bom dia Ornei, Dependendo do DANFE (Quick Report, Rave, etc) possui uma propriedade chamada NFeCancelada, se esta estiver com o valor True a Tarja será impressa.

Bom dia Jakson, Se a cidade for Petrolina/PE, ela é atendida pelo provedor SpeedGov, tanto o RPS quanto o Lote de RPS não se faz a necessidade de estarem assinados. Mas para realizar a emissão via Web Services, há necessidade do Certificado Digital. Por outro lado se a sua intenção é gerar o XML e importa-lo pelo site, o programa exemplo tem um botão chamado [Gerar Lote RPS]. A ideia é alimentar o componente com 1 ou mais RPS e depois gerar e salvar em disco o XML referente ao lote, para depois ser importado pelo site. Neste caso não há necessidade do Certificado Digital.

Bom dia Joel, Muito obrigado pela colaboração, em breve estarei disponibilizando a alteração.

Bom dia Joemil, Muito obrigado pela informação, já fiz a alteração, mas ainda não vou disponibilizar.

Bom dia Tiago, Tentou realizar o procedimento realizado pelo Tony? (postagem #3) deste tópico.

Bom dia, Ai que esta, no XML não existe nenhuma TAG que indique o ambiente. Dependendo do provedor, é utilizado NameSpace diferente para cada ambiente, desta forma é possível saber, caso contrario não.

Boa tarde lulaviana, Não informe o Expedidor e o Recebedor quando o CT-e for normal, essas pessoas só informamos quando se tratar de Redespacho ou Redespacho Intermediário. Outra coisa, você esta informando os veículos e diz que eles são de SP mas o proprietario dos mesmos são de RO, esta correto isso?

Boa tarde Rogério, Você já estudou a procedure GerarNFCe ? É nela que os dados pertinentes a venda são passados para o componente. Outra coisa, acesse o Portal Nacional da NF-e e baixe a Nota Técnica 2013/005 versão 1.21, nesta NT você vai encontrar toda a estrutura do XML e consequentemente quais são os campos obrigatórios.

Boa tarde Carlos, Em vez de: 1º Carrego o componente com as informações; Atribuindo os valores ao atributos; 2º Gerado o XML; 3º Carrego o componente através da leitura do XML; 4º Solicito a validação; Porque não: 1º Carrego o componente com as informações; Atribuindo os valores ao atributos; 2º Enviar; Lembre-se que o Enviar: Gera o XML, Assina, Valida, se OK Envia.

Bom dia Renato, Sim, o arquivo *-rec.xml é o retorno do provedor. O componente envia o lote de RPS para o provedor e este deve retornar o numero do protocolo (semelhante ao recibo da NF-e) acusando o recebimento do lote. Portanto o arquivo *-rec.xml deveria conter o numero do protocolo, mas o web services não esta aceitando a assinatura do xml e esta retornando essa rejeição. Como já existe outros casos e o provedor esta tomando algumas providencias, sendo assim você deve entrar em contato com eles para procurar saber o que eles estão fazendo e qual é a alteração que você terá que fazer.

Bom dia Paulo, A mensagem de erro acusando que a chave é inválida já foi corrigida, bastando agora o pessoal disponibilizar uma nova compilação do ACBrNFeMonitor. Quanto ao erro de falha de parse, notei que na composição do Id esta faltando os 4 primeiros dígitos da chave: Esta assim: "ID110111120259.... o correto é: "ID1101113514120259... Como esse erro apareceu sendo que o monitor para se a chave for inválida.

Bom dia Márcio, Podemos dizer que o XML de um documento fiscal eletrônico para ter validade jurídica tem que possui 3 seções: 1. conteúdo do documento fiscal; 2. assinatura digital; 3. informações sobre o protocolo; As TAGs: DigestValue e SignatureValue estão contidas no grupo <Signature>, ou seja a seção "2", não podemos comparar o conteúdo dessas duas TAGs elas sempre serão diferentes, uma vez que a SignatureValue traz a assinatura e a DigestValue traz uma especie de checksum da seção "1". Se você observar na seção "3", mais precisamente o grupo <infProt> possui uma TAG chamada digVal esta sim deve ser comparada com a TAG DigestValue, elas devem possui e mesmo conteúdo. Se digVal for igual a DigestValue e cStat = 100 (Autorizado o uso) podemos dizer que o XML em questão é um Documento Fiscal Eletrônico com validade jurídica.

Jeff, Ou os seus fontes estão desatualizados, ou você não reinstalou o componente.

Boa tarde Moacir, Você esta com todos os fontes de todas as pastas atualizados? Se sim, você compilou a sua aplicação com o Build? Tentou compilar o pacote ACBrComum antes do pacote ACBrSerial?

Boa tarde André, Estou trabalhando nas alterações espero terminar amanhã.

Boa tarde Jeff, Não tem como efetuar o encerramento manualmente. Somente via Web Services. O componente possui uma configuração: Configuracao.WebServices.Salvar Atribua o valor True a essa propriedade e tente novamente. Será gerado os seguintes arquivos: *-ped-eve-soap.xml (solicitação) *-eve-soap.xml (retorno) Post como anexos esses arquivos.

Boa tarde Renato, Tenta debugar para encontrar o ponto onde o erro ocorre, pois não consegui localizar essa mensagem dentro dos fontes do componente.

Boa tarde, Uma coisa é a versão do XML da NF-e e outra coisa é a versão do XML do evento de cancelamento.

Boa tarde Guto, O valor dessa propriedade é definida no fonte de cada provedor. Abra o ACBrProvedorxxxxx onde xxxxx é o provedor em questão e altere o valor da propriedade QuebraDeLinhas. Depois compile a sua aplicação com a opção Build.

Depois do envio tente: sXML := UTF8Encode(ACBrNFe1.WebServices.EnvioWebService.XMLEnvio);

Bom dia, Como você faz para obter o XML de envio de um Cancelamento? É exatamente igual.

Bom dia, Esse é o primeiro passo, saber se o componente já atende a cidade ou não. O segundo passo agora é procurar saber qual é o provedor (empresa) que atende a cidade em questão. Na pasta: ...\Fontes\ACBrNFSe temos várias Units com o seguinte nome: ACBrProvedorxxxxx onde xxxxx é o nome do provedor. Se existir uma Unit para o provedor da cidade em questão, maravilha, o próximo passo é abrir essa Unit e verificar se existe ou não uma URL especifica para cada cidade. Se existir você deverá entrar em contato com o provedor para saber quais são as URLs de homologação e de produção. Alem de alterar essa Unit incluindo as URLs devemos também incluir o nome da cidade na lista de cidades referente ao provedor na Unit pnfsConversao. Agora se o provedor não existe ainda é preciso saber se o mesmo segue o padrão ABRASF.

Jeff, O XML que você postou se refere ao retorno a consulta. Eu pedi o retorno após a solicitação de encerramento. Lembrando que o encerramento é um evento, sendo assim temos os arquivos: *-ped-eve.xml (solicitação) *-eve.xml (retorno)

Boa tarde, O programa exemplo possui um botão onde você informa o código IBGE da cidade e ele te retorna o nome do provedor, caso retorno a palavra Nenhum significa que não tem nenhum provedor vinculado a cidade informada.