Italo Giurizzato Junior

Bom dia Mario, O problema então esta relacionado com a versão do Delphi. Vou passar o problema para o pessoal que escreveu a classe Json.

Bom dia Edes, Você sabe que existe 3 formas de usar o serviço DistribuicaoDFe? Pois bem a que você esta usando não é a mais recomendada. Por favor leia o tópico:

Boa tarde Marcos, Já esta no SVN. Favor atualizar todos os fontes, reinstale o ACBr e faça os testes.

Boa tarde Bruno, Como assim sai zerado? Você esta carregando o XML da NFS-e ou do DPS? Em anexo o PDF do DANFSE com base no XML que você anexou acima. 35269022226498282000192000000000000923092275073279-nfse.pdf Quando você configura pela primeira vez o programa exemplo, realmente não aparecem todas as cidades. Neste caso você deve configurar ele com qualquer uma que esteja aparecendo, salvar a configuração, encerrar a execução do programa, executar ele novamente, ai sim vai ser mostrado a lista completa com as mais de 5.500 cidades. Não importa se no arquivo ACBrNFSeXServicos a cidade desejada não consta que o provedor é PadraoNacional, pois o componente possui uma propriedade de configuração onde determinamos se desejamos que o XML seja gerado segundo o layout do provedor ou segundo o layout do Padrão Nacional. Alterando a configuração para gerar segundo o Padrão Nacional o componente vai gerar nesse layout e vai enviar para a API do NFS-e Padrão Nacional.

Boa tarde Edson, O componente faz isso automaticamente. Todos os métodos do componente ACBrNFSeX tem o seguinte fluxo: 1. Gerar o XML; 2. Assinar se necessário; 3. Validar; 4. Enviar para o WebService e aguardar o retorno.

Boa tarde Anderson, Faça o seguinte teste: Abra o arquivo ACBrNFSeXServicos.ini e altere a linha abaixo: ProRecepcionar=http://pmsertaozinho.smarapd.com.br:80/tb/services/Abrasf23 para: ProRecepcionar=http://pmsertaozinho.smarapd.com.br/tb/services/Abrasf23 Execute o Compila_RES Reinstale o ACBr Recompile a aplicação com a opção Build e faça novos testes.

Boa tarde Diego, Como o próprio nome diz é um numero sequencia atribuído para cada pessoal informada no XML da nota. Em uma nota fiscal de serviço temos: o prestador, o tomador e o intermediário do serviço. Logo teremos um NSU para o Prestador, outro para o Tomador e outro para o Intermediário. Lembre-se que o Prestador vai emitir notas para "N" Tomadores e um Tomador poderá ter "N" prestadores de serviço. Esse é o motivo do Numero Sequencial ser Único, ou seja, ele é Único para cada pessoal informada no XML.

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

Boa tarde Douglas, Como assim a tag opSimpNac não esta sendo lida? Abaixo a procedure que faz a leitura da tag: procedure TNFSeR_PadraoNacional.LerRegimeTributacaoPrestador( const ANode: TACBrXmlNode); var AuxNode: TACBrXmlNode; Ok: Boolean; begin AuxNode := ANode.Childrens.FindAnyNs('regTrib'); if AuxNode <> nil then begin NFSe.OptanteSN := StrToOptanteSN(Ok, ObterConteudo(AuxNode.Childrens.FindAnyNs('opSimpNac'), tcStr)); NFSe.RegimeApuracaoSN := StrToRegimeApuracaoSN(Ok, ObterConteudo(AuxNode.Childrens.FindAnyNs('regApTribSN'), tcStr)); NFSe.RegimeEspecialTributacao := FpAOwner.StrToRegimeEspecialTributacao(Ok, ObterConteudo(AuxNode.Childrens.FindAnyNs('regEspTrib'), tcStr)); end; end;

Bom dia Fabiano, Vamos fazer a seguinte alteração: Abra a unit PadraoNacional.Provider; Procure pela procedure: TratarRetornoConsultarDFe; Nessa procedure procure pela linha abaixo: ANota := TACBrNFSeX(FAOwner).NotasFiscais.FindByRps(NumRps); deve ser a linha 1024. Altere ela deixando da seguinte forma: ANota := TACBrNFSeX(FAOwner).NotasFiscais.FindByRps('-1'); O que esta ocorrendo, na variável NumRps temos o numero do DPS, caso ele já tenha carregado outra nota com o mesmo numero essa segunda vai se sobrepor, ou seja, você perde os dados da primeira lida. Por outro lado passando um valor fixo "-1" para o numero do DPS ele nunca vai encontra, logo ele sempre vai adicionar a nota retornado. Assim eu espero. Faça a alteração, reinstale o ACBr e faça um novo teste.

Bom dia Edson, Estranho, pois o conteúdo retornado pela função GerarXML é justamente da propriedade XmlRps que também pode ser lida da forma que mostrei acima.

Bom dia Mario, O Json retornado que você anexou é: {"tipoAmbiente":1, "versaoAplicativo":"SefinNacional_1.0.0", "dataHoraProcessamento":"2023-09-28T08:15:13.4054257-03:00", "idDPS":"DPS421380720948876900017500900000000000000015", "erros":[ {"Parametros":null, "Codigo":"E0160", "Descricao":"No mês de competência da NFS-e, a opção de situação perante o Simples Nacional, do prestador, informada na DPS não está de acordo com o cadastro Simples Nacional." } ] } No teste que fiz é: {"tipoAmbiente":2, "versaoAplicativo":"Testes_0.1.0", "dataHoraProcessamento":"2023-09-28T10:00:16.0126611-03:00", "idDPS":"DPS350320822940647500016400900000000000000001", "erros":[ {"Parametros":null, "Codigo":"E0034", "Descricao":"A situação do convênio do município emissor informado na DPS deve ser \"ATIVO\" no cadastro de convênio municipal do sistema nacional." } ] } Vamos levar em consideração somente aos nomes dos objetos e não o seu conteúdo. Note que a estrutura dos Json é exatamente igual. Resultado: Como você pode ver não ocorreu erro de AV. Para mim, existe no HD da sua maquina copias antigas dos fontes que o Delphi esta tendo acesso, logo ele esta usando os fontes antigos em vez dos atualizados, ou copias de DCU antigas na pasta do programa exemplo ou em outra pasta que o Delphi esta tendo acesso.

Bom dia Wesley, Se tratando de NF-e e NFC-e, a linha referente ao cst45 deve ser removida, pois não existe esse CST para os documentos mencionados.

Bom dia Heronim, Entre em contato com a prefeitura ou com o provedor, pela mensagem de erro na imagem que você anexou, me leva a crer que essas duas cidades continuam com o mesmo provedor, mas passaram a usar o layout da ABRASF e não mais o layout próprio do provedor EL.

Olá Pessoal, Recentemente foi publicado a Nota Técnica 2023/002 que trata sobre a alteração do retorno da Consulta a Situação do MDF-e. No retorno passamos a ter o grupo <procInfraSA> com os campos: nProtDTe e dhProt. O que vem a ser? Trata-se do grupo de informações do compartilhamento do MDF-e com InfraSA para a geração do DTe. Para quem não sabe houve uma tentativa de se criar um novo documento fiscal chamado DTe - Documento Eletrônico de Transporte criado pelo Ministério da Infraestrutura através da Medida Provisória numero 1051 de 18/05/2021. Que segundo o Ministério se tratava de uma conquista dos caminhoneiros e que iria revolucionar o setor de Transporte de Carga no Brasil. Mas na verdade o DT-e nada mais era do que o nosso velho conhecido e consolidado MDF-e e tem mais, o DT-e teria um custo para as transportadoras sendo que o MDF-e é gratuito. Depois de muita briga a SEFAZ, mais precisamente a do Rio Grande do Sul uma vez que é ela que recepciona todos os MDF-e de todas as UF, entrou em um acordo com o Ministério da Infraestrutura. Esse acordo visa o compartilhamento de dados do MDF-e com a InfraSA, desta forma o DTe passa a ser apenas um portal e não mais um documento. Como é que a coisa vai funcionar? A Transportadora envia o MDF-e para a SEFAZ Virtual do RS (responsável pela recepção), se todas informações estiverem corretas será retornado o numero do protocolo de autorização do MDF-e. Em seguida a SEFAZ Virtual do RS compartilha os dados do MDF-e com a InfraSA e esta retornará o numero do protocolo bem como a data e hora da geração do protocolo acusando que o DT-e foi gerado com sucesso pela InfraSA. Na Nota Técnica não fica claro se o compartilhamento é imediato ou não, mas deixa claro que essas duas informações (protocolo e data/hora) só vão estar disponíveis após o compartilhamento e para os modais ferroviário e rodoviário. Portanto se logo após obter o protocolo de autorização do MDF-e, se você consultar a situação do mesmo não constar essas informações isso significa que o MDF-e ainda não foi compartilhado com a InfraSA, neste caso devemos aguardar um tempo e tentar novamente. E qual a finalidade para nós desenvolvedores? Na Nota Técnica não deixa claro se devemos armazenar essas informações ou não, e se elas vão ser necessárias para uma consulta posterior via portal ou webservice. Caso você decida em guardar, lembre-se que são dois campos: o Numero do Protocolo de Geração do DTe e a Data e Hora de Geração do Protocolo. Vincule essas duas informações ao MDF-e, uma vez que para cada MDF-e emitido teremos o protocolo e a data/hora de geração do DTe. Espero ter esclarecido o que vem a ser e o que fazer com essas duas novas informações.

Fabiano, O componente só leva em consideração o numero do DPS. Podemos ter 2 situações neste caso: 1. Mesmo Prestador, numero de DPS igual com série diferente. 2. Prestadores diferentes com numero de DPS iguais. A checagem vai ter que levar em consideração o CNPJ do Prestador, o numero do DPS e a série quando for executado o método ConsultarDFe.

Boa tarde Bruno, Usando o XML que você anexou com o programa exemplo não tive esse erro. Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Boa tarde Edson, Após gerar o XML do RPS ele fica disponível na propriedade: ACBrNFSeX1.NotasFiscais.Items[ x ].XmlRps

Boa tarde Marcos, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4509

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

Boa tarde Wesley, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou o ACBr? Ocorreu uma alteração referente a Sertãozinho/SP no dia 26/09/2023

Boa tarde Mario, Pelo amor de Deus, vamos configurar o componente da forma correta?

Jéter, Já esta no SVN.

Boa tarde, Já esta no SVN.