Italo Giurizzato Junior

Bom dia Claudemir, Muito obrigado pela colaboração, já esta disponível.

Bom dia Marco, O valor do vTotTrib não é calculado com base no valor do ICSM da respectiva prestação de serviço e sim com base no valor da prestação (frete). Supondo que pela tabela do IBPT o percentual é de 5% e o valor da prestação (frete) é de R$ 100,00 o vTotTrib será R$ 5,00, ou seja, 5% de R$ 100,00.

Bom dia, Quem gera o numero da NFS-e é o Web Services. Se ao enviar um RPS de numero 1 em ambiente de homologação e o WS retornou uma NFS-e com numero 135 significa que alguém já tinha feito testes antes.

Boa tarde Rogério, Primeiro é preciso saber qual é o provedor (empresa) que foi contratado pela prefeitura da cidade deseja. Segundo verificar se o respectivo provedor já esta implementado no componente, se sim, abrir a unit correspondente e ver como foi implementado outra cidade deste provedor e adicionar a nova cidade de forma semelhante. Se o provedor não esta implementado ai a coisa fica mais complicada, é preciso entrar em contato com o provedor e obter o maximo de informações possíveis, como schemas, xml de exemplos, URLs de homologação e produção se segue o padrão ABRASF ou não.

Bom dia a todos, Por favor atualizem os fontes e testem novamente.

Bom dia a todos, Mandei para o SVN algumas alterações visando deixar o XML do RPS segundo o exemplo. Favor atualizar os fontes e testar novamente.

Boa noite Paulo, O erro que você postou se refere a validação do XML antes do mesmo ser enviado para SEFAZ. Qual evento você se refere? Já o SeparaDados de qual Unit? de qual função ou procedimento?

Boa noite Paulo, O que você descreveu é absolutamente normal. Toda ação (emissão, cancelamento,...) ocorre na SEFAZ-Autorizadora. Se você consultar via site da SEFAZ-Autorizadora é para estar atualizado. Por outro lado se consultar via site da SEFAZ-Ambiente Nacional pode ocorrer de não estar atualizado, uma vez que a SEFAZ-Autorizadora tem que replicar as ações e isso pode levar de minutos a horas.

Boa tarde a todos, As rejeições de denegação são: 110, 301 e 302. Seria interessante também ao salvar uma NF-e denegada, o nome do arquivo ser: <chave>-den.xml, conforme o item 5.2 Padrão de Nomes para os Arquivos, página 90 e 91 do Manual versão 5.0 da NF-e.

Boa tarde Dércio, Esta estranho isso, como lhe disse fiz um teste e esse erro não foi reportado. Por favor desinstale os componente, remova todos os fontes DCU e BPL que se refere ao ACBr, baixe novamente e instale, por fim compile a sua aplicação com o Build e teste novamente.

Boa tarde Jakson, Não importa se o RPS é assinado ou não, ou se o Lote de RPS é assinado ou não, para se utilizar do Web Service há necessidade do certificado. Pode sim, utilizar o mesmo certificado usado para emitir NF-e.

Bom dia Luis, Não sei como foi feito a sua aplicação, vai uma dica, a UF a ser configurada como sendo a UF da SEFAZ autorizadora, tem que ser a UF do Emitente do Documento Fiscal Eletrônico. Se o Emitente é de SP devemos utilizar a SEFAZ-SP se for de RO devemos utilizar a SEFAZ-RO e assim por diante. Não permita que o usuário possa selecionar essa UF antes da emissão.

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.