Ir para conteúdo
  • Cadastre-se
Seja bem-vindo
Regras e orientações da nossa comunidade Participe do Discord do ACBr

Juliano Do Amaral Chaves

Membros
 Perfil  Explorar Conteúdo

  • Total de ítens

    65

  • Registro em

  • Última visita

 Tipo de Conteúdo 

Posts postados por Juliano Do Amaral Chaves

    Como informar o "codigo_item_lista_servico" na NFS-e

    em ACBrNFSe

    Postado

    13 minutos atrás, Juliano Do Amaral Chaves disse:

    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 221 kB · 0 downloads pnfsNFSeW_IPM.pas 13 kB · 0 downloads

    Talvez o mais correto seria criar a property "ItemListaServico" na classe "TItemServicoCollectionItem" e usar ela ao gerar o XML

    image.thumb.png.4a9157e53cabf3b32b16097d7811b8da.png

    Como informar o "codigo_item_lista_servico" na NFS-e

    em ACBrNFSe

    Postado · Editado por Juliano Do Amaral Chaves

    Em 05/11/2019 at 15:45, Italo Jurisato Junior disse:

    Boa tarde Juliano,

    Você já chegou a ver na unit que gera o XML de qual campo ele pega essa informação?

     

    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

     

    image.thumb.png.e70d537371e0d25e6a7b41cb296708e1.png

     

    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"

    Logos no DANFSe estão ficando deformadas

    em ACBrNFSe

    Postado

    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

    • Curtir 1

    Como informar o "codigo_item_lista_servico" na NFS-e

    em ACBrNFSe

    Postado

    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?

    image.thumb.png.80f7bd1203e1943f9763befd6e3637c5.png

     

    Inconsistência de dados no retorno da consulta do MDF-e

    em ACBrMDFe

    Postado

    2 horas atrás, Italo Jurisato Junior disse:

    Boa tarde Juliano,

    Favor atualizar os fontes, fiz um tratamento para os MDF-e que foram encerrados.

    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

    • Curtir 1

    Inconsistência de dados no retorno da consulta do MDF-e

    em ACBrMDFe

    Postado

    9 horas atrás, Italo Jurisato Junior disse:

    Bom dia Juliano,

    A rotina de tratamento de resposta da consulta que você alterou no ACBrMDFeWebServices é a mesma na NF-e e CT-e.

    Note que podemos dividir o XML de retorno a consulta em 3 partes.

    Na primeira temos a situação atual do documento que segundo o seu exemplo acusa que o mesmo esta cancelado.

    Na segunda temos o grupo <protMDFe> que contem as informações referente ao protocolo de autorização.

    A terceira parte só vai constar se o MDF-e possuir eventos vinculados a ele, logo podemos ter uma lista, ou seja, o grupo <procEventoMDFe> pode aparecer diversas vezes.

    No seu exemplo como o MDF-e foi cancelado temos apenas um evento que é o de cancelamento e suas informações estão dentro do grupo mencionando acima.

    Pela rotina atual temos o seguinte: 

    
// Na linha abaixo temos o protocolo da situação atual do MDFe,
// esse protocolo pode ser de autorização ou de cancelamento ou de encerramento
numProtAtual := ACBrMDFe1.WebServices.Consulta.Protocolo;

// Na linha abaixo temos o protocolo de autorização
numProtAutor := ACBrMDFe1.WebServices.Consulta.protMDFe.nProt;

// Abaixo temos um loop onde temos o numero do protocolo dos eventos vinculados ao MDFe
  for i := 0 to ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count -1 do
    numProtEvento[ i ] := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items[ i ].RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt;

    No meu entendimento ao realizar a consulta, dependendo do que deseja você vai ter que escolher uma das 3 formas acima para obter o numero do protocolo (por exemplo).

    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

    Inconsistência de dados no retorno da consulta do MDF-e

    em ACBrMDFe

    Postado

    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

     

     

    Cancelado Corrigido.png

    MDF-e Consulta Protocolo de Autorização.patch

    Inconsistência de dados no retorno da consulta do MDF-e

    em ACBrMDFe

    Postado · Editado por Juliano Do Amaral Chaves
    Melhor visualização

    Encerrado.png

    Cancelado.png

    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

    Inconsistência de dados no retorno da consulta do MDF-e

    em ACBrMDFe

    Postado

    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

        

     

    878-Rejeicao no Paraná

    em ACBrNFe

    Postado

    11 minutos atrás, Juliano Do Amaral Chaves disse:

    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?

    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

    878-Rejeicao no Paraná

    em ACBrNFe

    Postado

    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?

    Informações obrigatórias NFCe 4.00 em cartões

    em Legislação Fiscal e Tributária

    Postado

    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>

×
×
  • 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...