Italo Giurizzato Junior

Boa tarde Will, O provedor Ginfes já esta implementado, você não tem que alterar INI nenhum. Basta usar o programa exemplo para iniciar os testes. Caso a cidade em questão não conste no combobox, basta incluir da mesma forma que foram incluídas as outras.

Boa tarde, Por favor vamos seguir as regras do fórum? Assunto novo, post novo.

Boa tarde Brunetto, A correção é bem simples, basta não usar o método ConsultarSituacaoLote, pelo simples fato que esse provedor não possui o Web Service destinado a consultar a situação do Lote. É exatamente por isso que no arquivo INI a direita do "=" esta em branco.

Boa tarde Hamilton, Pela mensagem de erro, você configurou o componente para gerar o MDF-e segundo a versão 3.00, correto? Se sim, você esta ciente que essa versão só esta disponível o ambiente de homologação. Outra coisa, ao configurar a propriedade PathSchemas, o caminho contem todos os Schemas que estão disponível na pasta: ...\Exemplos\ACBrDFe\Schemas\MDFe ?

Bom dia Felippi, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia, Muito obrigado pelo retorno, já fiz a alteração e enviei para o repositório.

Bom dia Quartarollo, Você fez as melhorias para que essa alteração não gere efeitos colaterais em provedores que não possuem uma lista de itens de serviços?

Bom dia Ricardo, Por favor anexe o arquivo INI que você alterou, para que eu possa avaliar e se estiver tudo OK vou enviar para o repositório.

Bom dia a todos, Segundo a Especificações Técnicas do DANFE NFC-e QRCode Versão 4.0, temos um exemplo de DANFE impresso em contingência ( página 17 ), tanto a via do consumidor quanto a via do estabelecimento contem a relação dos itens. No meu entendimento se um documento seja qual ele for se existir uma segunda via do mesmo, esta tem que ter o mesmo teor da primeira.

Bom dia, Se o XML da NFC-e contem o protocolo de autorização, podemos afirmar que sim, pois somente a SEFAZ gera o numero do protocolo e para que isso ocorra ela necessita do XML. Você pode também comparar o DigestValue do XML gerado pelo emitente da nota com o DigestValue retornado juntamente com o protocolo, ambos tem que ser iguais. Não existe uma consulta por período e ao realizar uma consulta se utiliza a chave e não o numero do protocolo.

Boa noite Luiz, Aumente o valor da propriedade Timeout.

Boa noite Ricardo, Abra o arquivo INI do provedor e altere a linha das URLs de homologação e de produção da mesma forma que foi alterado para a cidade de código IBGE: 2910800. Com relação a padrão diferente, até onde sei o provedor WebISS se utiliza da versão 1.0 do layout da ABRASF. Favor solicitar ao provedor um XML exemplo.

Boa noite, No momento não existe nenhuma propriedade que retorna o caminho + nome do RPS somente da Nota.

Boa noite Hamilton, A mensagem "Versão do arquivo XML não suportada" é apresentada antes do envio ou após o envio? A mensagem se trata de um erro de validação ou uma rejeição?

Boa noite Dinarte, Muito obrigado pela colaboração, vou fazer a alteração e enviar para o repositório.

Luiz, Execute a opção: Opões de Internet no Internet Explorer, depois selecione a aba Avançadas, temos uma lista de opções, vá até o final para encontrar as de revogação de certificado, desmarque elas.

Bom dia Samuel, Você leu o que eu escrevi? No PDV 1 ao alimentar o componente com os dados da venda você atribui o valor 1 ao campo série. Ide.serie := aSerie; // onde o valor de aSerie é 1 No PDV 2 ao alimentar o componente com os dados da venda você atribui o valor 2 ao campo série. Ide.serie := aSerie; // onde o valor de aSerie é 2 Entendeu agora?

Bom dia Luiz, O certificado não esta vencido? Verificou as configurações do Internet Explorer, no que diz respeito a revogação de certificados? Tentou desativar antivirus e ou firewall?

Boa noite Samuel, Você utiliza o componente ACBrNFe ou o aplicativo ACBrMonitor Plus? Se utiliza o componente basta informar o valor 2 a propriedade serie na rotina que alimenta o componente com os dados da venda.

Boa noite Rogério, Todo CT-e emitido tem que possuir pelo menos um documento originário, que na maioria dos casos é uma NF-e. Antes era possível informar uma NF-e ou NF (papel) ou Outros (Declaração). Acredito que hoje nenhum empresa emiti NF (papel), logo devemos informar uma NF-e ou Outros. Cuidado, não informe o documento originário como sendo Outros de forma indiscriminada, pois o CT-e poderá ser rejeitado pela SEFAZ. Se o Remente da carga for uma empresa obrigada a emitir NF-e, ao emitir o CT-e será obrigatório informar a chave da NF-e, sobe pena do CT-e ser rejeitado.

Dércio, Quem passou essa informação deve ser algum estagiário que deve estar confundindo emissão via Site com via Web Services. Nessas horas que temos que ter paciência.

Dércio, Então podemos concluir que há necessidade do certificado digital e que o Lote deva ser assinado, caso contrário o Lote será rejeitado. Quanto ao numero da série não esta sendo retornado no XML gerado pelo provedor é um problema que tem que ser sanado pela equipe do provedor.

Boa tarde, A questão não é o Enviar e sim o tratamento feito no XML de retorno seja qual ele for. No caso do componente ACBrNFSe, todos os métodos possui uma função chamada TratarResposta e todas chamam a função ExtrairRetorno. E como já dito na função ExtrairRetorno é verificado o valor da propriedade RetirarAcentos, caso seja True é trocado as vogais acentuadas por não acentuadas e o cedilha pela letra "c".

Dércio, A mesma mensagem de retorno que recebi ao realizar um teste de envio sem utilização de certificado. Por outro lado se deixarmos: [Assinar]RPS=0Lote=1URI=1 O componente vai assinar o lote, mas para que isso ocorra a necessidade do certificado digital. Nestas condições o Lote é enviado e processado com sucesso?

Boa tarde Dércio, Faça uma alteração no arquivo DbSeller.ini: [Assinar] RPS=0 Lote=0 URI=1 Tente enviar desta forma.