Italo Giurizzato Junior

Boa tarde Wesley, Você poderia anexar o PDF de um DANFE ou somente a imagem da informação em questão?

Boa tarde Gleryston, A sua alteração esta correta, muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde, Na unit ACBrMDFe, temos o seguinte método: function ConsultarMDFeNaoEnc(const ACNPJCPF: String): Boolean; ACBrMDFe1.ConsultarMDFeNapEnc(xCNPJCPF); Você notou que o programa exemplo possui um botão que exemplifica esse tipo de consulta? De uma forma diferente a de cima, mas tem.

Boa tarde Gustavo, Primeiramente quem envia o evento de comprovante de entrega é a própria transportadora, portanto o emitente do CT-e. No XML do pedido do evento a chave do CT-e os 2 primeiros dígitos é o código IBGE da UF cujo CT-e foi emitido, e consta 24, logo a UF é RN e não MG. Olhando o seu XML, notei algumas coisas erradas: 1. O código da UF que aparece no cabeçalho é 35 = SP, portanto esta errado, deveria ser 24. 2. Data/Hora de entrega, só consta a data, a hora esta toda zerada, isso pode fazer com que ocorra outros tipos de rejeição. dhEvento >= dhhashEntrega > dhEntrega

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, O Encerramento é um evento, vide o programa exemplo. Nele é solicitado o XML para poder extrair do mesmo as informações necessárias. Mas se você tem essas informações no banco de dados, em vez de carregar o XML para ter acesso as informações, basta ler elas do banco de dados e passar para o componente. Não entendi qual é a dificuldade.

Bom dia Roberto, Você esta usando o DAMDFE feito em Fast ou Fortes? Anexa o PDF de como esta sendo impresso e o XML do mesmo.

Bom dia Walter, Tente da seguinte forma: infCTeNorm.infCTeSub.chCte := <chave do CT-e Normal>; infCTeNorm.infCTeSub.refCteAnu := <chave do CT-e de Anulação>; caso o tomador não seja contribuinte do ICMS e foi emitido antes o CT-e de Anulação. ou infCTeNorm.infCTeSub.chCte := <chave do CT-e Normal>; infCTeNorm.infCTeSub.tomaICMS.refNFe := <chave da NF-e de Anulação>; caso o tomador seja contribuinte e emitiu a NF-e de Anulação.

Bom dia a todos, O consultar status só serve para saber se o webservice do status esta funcionando, se ele retornasse a situação de todos os serviços (recepção, consulta, evento, inutilização, ...) seria uma maravilha, mas infelizmente não é assim que a coisa funciona. E outro detalhe importante, o DistribuicaoDFe é um serviço disponibilizado pelo Ambiente Nacional e não pela SEFAZ-Autorizadora. Logo não adianta absolutamente nada, executar o consultar status de serviço.

Boa tarde João, Todos os fontes de todas as pastas estão atualizados? A suíte ACBr foi reinstalada após a atualização?

Boa tarde Elias, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Silva, É bem provável que a propriedade de configuração Encerrado do componente DAMDFE esteja com o valor True.

Boa tarde a todos, Alguém poderia anexar a unit alterada que resolveu o problema, para que possamos analisar.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Julio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde, Esse XML esta sendo gerado pelo componente ACBrMDFe ou pela aplicação diretamente?

Boa tarde, O titulo da sua postagem se refere a Encerrar o MDF-e sem o XML, isso é possível, basta você ter a chave e o protocolo de autorização do mesmo. Como não esta mais gravando o XML de retorno que tem o protocolo de autorização? O componente possui 3 propriedades Salvar quais são os valores delas?

Boa tarde Eric, Que eu saiba se o XML possui a string do QR-Code o mesmo será impresso no DAMDFE. Quem usa o Fortes Report posso garantir que sim, pois fiz testes com ele, já não posso dizer a mesma coisa para quem usa o Fast Report. Eu não vejo problema nenhum a impressão do QR-Code antes da data prevista. Entendo que antes de outubro/2019 a impressão é facultativa depois de outubro será obrigatória.

Bom dia Denys, Abra o XML que você anexou através de um navegador e veja no final dele que as tags: username e password estão vazias. Sem essas informações o provedor não vai aceitar.

Bom dia Gilson, A alíquota que você esta informando esta errada para essa empresa, caso ela esteja correta é preciso realizar o cadastro da mesma, acredito eu via site, pois pelo componente isso não é possível ser feito.

Bom dia Nilton, Acredito que neste caso devemos informar que a série é UNICA. IdentificacaoRps.Serie := 'UNICA';

Bom dia Juliano, Acredito que o problema é o provedor que formata os valores no XML. Abra esse XML que você anexou usando um navegador, vai notar que o valor da tag <ValorServicos> é 1.035,00 em vez de 1035,00 Notou a diferença? Tem o ponto "." de milhar. Se remover esse ponto tenho certeza que o erro não vai mais ocorrer. Deve ser removido também o ponto de milhar das tags: BaseCalculo e ValorLiquidoNFSe.

Bom dia a todos, Pessoal o correto é com duas barras, conforme consta no arquivo INI do provedor. Se não for com duas // o namespace ao utilizar o libWinCrypt ocorre erro ao tentar assinar o lote. Foi necessário alterar o schema para que ocorresse a validação. Como o WSDL do provedor esta errado, ou seja, com apenas uma barra, se fez necessário incluir uma gambiarra na unit ACBrNFSeWebServices, que realiza a troca das duas barras por apenas uma, desta forma quando o XML chegar no provedor ele consegue processar com sucesso. Essa gambiarra tinha sido feita apenas para o método Enviar para fim de testes, agora foi estendida para os demais métodos. Favor atualizar os fontes e façam novos testes. Por favor utilizem o arquivo INI que esta no repositório bem com o schema, não façam nenhuma alteração, do tipo trocar as duas barras por uma.

Bom dia Sérgio, Com relação ao DIFAL favor entrar em contato com o contador do seu cliente para saber como deve proceder. No que diz respeito a versão, não existe ve300a e sim ve300 que atende tanto a versão 3.00 quanto a 3.00a.