Ir para conteúdo
  • Cadastre-se

Juliano Do Amaral Chaves

Membros
  • Total de ítens

    65
  • Registro em

  • Última visita

Tudo que Juliano Do Amaral Chaves postou

  1. Fiz a alteração já criando propriedade, nos meus testes funcionou, segue todos os arquivos alterados em anexo pnfsNFSe.pas pnfsNFSeR.pas pnfsNFSeW_IPM.pas
  2. Talvez o mais correto seria criar a property "ItemListaServico" na classe "TItemServicoCollectionItem" e usar ela ao gerar o XML
  3. Boa tarde Segue em anexos os arquivos solicitados, eu atribuir o valor para o campo CodServ, mas talvez não seja o campo mais adequado, no entanto esse campo atende a necessidade ao informar mais de um serviço na mesma nota pnfsNFSeR.pas pnfsNFSeW_IPM.pas
  4. Boa tarde Desculpe por não ter sido mais especifico, sim eu já tinha verificado o fonte, mas não soube me expressar O problema é na unit "pnfsNFSeW_IPM.pas" na linha 190, a informação do código da lista de serviço esta pegando do cabeçalho ao invés de pegar do item Acho que o correto seria pegar de NFSe.Servico.ItemServico.CodigoListaServico, mas essa propriedade não existe na classe "TItemServicoCollectionItem", no entanto existem outras propriedades que talvez pudesse ser usadas como as propriedades "Codigo" e "CodServ" O fato é que pegando de NFSe.Servico.ItemListaServico irá impedir gerar NFS-e com mais de um serviço de códigos diferentes Não sei se soube exemplificar da forma correta, por isso segue a imagem demostrando o problema na unit "pnfsNFSeW_IPM.pas"
  5. Bom dia Na DANFSe do Fortes Report, dependendo do formato da logo, ela fica deformada, e quando não informa a logo, é exibida uma logo personalizada com a logo do ACBr O problema de deformar é por causa da propriedade "Stretch" que esta ativada, o correto é usar a propriedade "Scaled" que escalona a logo sem deforma-la Quanto a logo personalizada, seria mais interessante deixar uma padrão ao invés de uma personaliza Caso tenha interesse eu fiz as alterações que está em anexo ACBrNFSeDANFSeRLRetrato.dfm
  6. Bom dia Como deve ser informado o campo "codigo_item_lista_servico" no XML? Vi que posso informa-lo através da propriedade "ACBrNFSe.NotasFiscais.Add.NFSe.Servico.ItemListaServico" no entanto essa informação é especifica dos itens da NFS-e, portanto desta forma não é possível informar mais de um serviço com códigos diferentes, acredito que o correto seria entrar com essa informação através da classe "TItemServicoCollectionItem" a não ser que não seja permitido uma NFS-e com mais de um serviço com códigos diferentes, caso eu tenha entendio errado, como faço para informar dois serviços com códigos diferentes?
  7. Boa tarde Vi a alteração que você fez, desta forma não vai mais ter inconsistência e propriedade "ACBrMDFe1.WebServices.Consulta.Protocolo" sempre vai retornar o protocolo atual considerando o evento atual ou no caso de não haver evento retorna o protocolo de autorização. Ainda não testei, mas acredito que vai funcionar Por mim pode fechar o tópico Muito Obrigado
  8. Boa noite Entendi, mas neste caso então no caso do MDF-e encerrado está retornando errado, pois esta retornando o protocolo de autorização e não do encerramento, veja as imagens do debug que postei quando abrir o tópico Foi por isso que achei que a propriedade ACBrMDFe1.WebServices.Consulta.Protocolo teria que retornar o protocolo de autorização, achei inconsistente MDF-e Encerrado : numProtAutor := ACBrMDFe1.WebServices.Consulta.Protocolo; MDF-e Cancelado: numProtAtual := ACBrMDFe1.WebServices.Consulta.Protocolo; Da forma que você falou o correto seria: MDF-e Encerrado : numProtAtual := ACBrMDFe1.WebServices.Consulta.Protocolo; MDF-e Cancelado: numProtAtual := ACBrMDFe1.WebServices.Consulta.Protocolo ; De qualquer forma obrigado pela explicação, pois acredito que muito devem se confundir com o esse retorno
  9. Para efeito de confirmação da alteração feita, segue em anexo os dados do XML de retorno da consulta do MDF-e Cancelado
  10. Para corrigir o problema fiz as seguintes alterações no ACBr: 1) No arquivo "pmdfeRetConsSitMDFe.pas" na função "TRetConsSitMDFe.LerXml" alterei a condição: de: if FcStat in [100, 132] then para: if FcStat in [100, 101, 132] then Ou seja, se o MDF-e estiver cancelado, carrega os do protocolo de autorização para o objeto "protMDFe", isso porque acredito que para cancelar um MDF-e ele precisa estar autorizado. 2) No arquivo "ACBrMDFeWebServices.pas" na função "TMDFeConsulta.TratarResposta" fiz a seguintes alterações Removi a variavel: "MDFCancelado" Removi a linha: "MDFCancelado := False;" Removi o bloco: if retEvento.Items[J].RetInfEvento.tpEvento = teCancelamento then begin MDFCancelado := True; FProtocolo := retEvento.Items[J].RetInfEvento.nProt; FDhRecbto := retEvento.Items[J].RetInfEvento.dhRegEvento; FPMsg := retEvento.Items[J].RetInfEvento.xMotivo; end; Alterei a condição: De: if (not MDFCancelado) and (NaoEstaVazio(MDFeRetorno.protMDFe.nProt)) then Para: if (NaoEstaVazio(MDFeRetorno.protMDFe.nProt)) then Essas alterações faz com que o retorno das propriedades "ACBrMDFe.WebServices.Consulta.Protocolo" e "ACBrMDFe.WebServices.Consulta.DhRecbto" retorne os dados do protocolo de autorização e não do protocolo do evento de cancelamento Vou anexar o patch MDF-e Consulta Protocolo de Autorização.patch
  11. Observação, o fórum poderia ter um botão para visualizar o tópico antes de salvar, ou aumentar o tempo para alteração, pois tentei melhorar a apresentação do texto e incluir as imagens e não consegui, se tivesse um botão de excluir eu teria excluído e feito novamente, pois como ninguém tinha respondido ainda, não vi motivos para colocar tantas restrições
  12. Olá Estou implementando a consulta do MDF-e através da chaveMDF-e, no entanto percebi um inconsistência nos dados retornado quando o MDF-e está cancelado, caso o MDF-e esteja autorizado ou encerrado o retorno esta correto, mas quando esta cancelado está havendo inconsistência, segue abaixo exemplificação do problema: Estou pegado os dados da seguinte forma: // DADOS DE AUTORIZAÇÃO DE ENVIO DO MDFE // Aqui é que está o problema, pois quando a consulta é de um MDF-e autorizado ou encerrado, os dados retornando é da Autorização, porem se a consulta é de uma MDF-e cancelado o retorno é do evento de cancelamento e não da autorização de envio Protocolo := ACBrMDFe.WebServices.Consulta.Protocolo; DtAutorizacao := ACBrMDFe.WebServices.Consulta.DhRecbto; // DADOS DE AUTORIZAÇÃO DO EVENTO DO MDFE QUE PODE SER DE ENCERRAMENTO OU CANCELAMENTO DEPENDO DO STATUS // Aqui retorna perfeitamente tanto para MDF-e encerrado quanto para cancelado ProtocoloEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; DtAutorizacaoEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.retEvento.Items[0].RetInfEvento.dhRegEvento;Cancelado) Justificativa := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.InfEvento.DetEvento.xJust; // Acredito que ficaria mais legível se as propriedades básicas do retorno do evento fossem encapsulados diretamente na consulta, por exemplo "ACBrMDFe.WebServices.Consulta.RetEvento.nProt", caso seja necessário pegar outras informações do evento poderia ser feito por "ACBrMDFe.WebServices.Consulta.DetEvento", porem é só uma sugestão
  13. Fiz o teste inverso, como o "ACBrNFeServicos.ini" já estava com o "http" e no XML estava indo sem, eu coloquei o arquivo "ACBrNFeServicos.ini" sem altera-lo desta forma transmitiu a nota, vou recompilar o "ACBrNFeServicos.res" e testar, acredito que ele esteja sem o http
  14. Bom dia Estou com um cliente no estado do paraná reclamando de rejeição 878 na transmissão da NFC-e Já verifiquei alguns tópicos tratando do assunto no mês passado, no entanto eu já conferi o link com o arquivo "ACBrNFeServicos.ini" o ACBr esta atualizado, cheguei a fazer um teste colocando o arquivo "ACBrNFeServicos.ini" junto com o executável do sistema removendo https e não resolveu, então reparei que no XML a url esta indo sem o https e no site da SEFAZ está com https O que posso fazer para resolver?
  15. Bom dia Atualizei o cliente recentemente e no envio de NFC-e passou a dar a rejeição: Rejeição: Não informados os dados do cartão de crédito / débito nas Formas de Pagamento da Nota Fiscal esse cliente é o Paraná, um outro cliente de Manaus na mesma versão está funcionando reparei que na versão anterior o grupo do pagamento no XML era gerado da senguinte forma: <pag> <tPag>04</tPag> <vPag>17.90</vPag> <card> <tpIntegra>2</tpIntegra> </card> </pag> e depois da atualização a geração ficou da seguinte forma: <pag> <tPag>04</tPag> <vPag>17.90</vPag> </pag> Nesse cliente do PR, na versão anterior funciona e na versão atualizada não, acredito que seja uma obrigatoriedade do estado de PR informar a tag "tpIntegra", porque os clientes de outro estado não esta dando problema, sendo assim acredito que será necessário fazer uma adequação no ACBr para o Paraná, talvez criar uma propriedade para permitir gerar ou não o grupo <card>
  16. Olá Na impressão da logo na DANFC-e, esta esticando a logo deixo-a deformada, fiz algumas alterações que resolveram o problema, não sei quais são os procedimentos para enviar o patch para o ACBr, sendo assim anexei o arquivo neste tópico, se desejarem aplica-lo, fiquem a vontade Obrigado ACBrDANFCeFortesFr.pas.patch
  17. Sim, windows 10 atualizado com todas as atualizações disponíveis
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...