Giquieu

Olá, Segue contribuição com ajustes nas mensagens da Exception dos métodos StrToCodAjBaseCalcContrib e StrToIndicadorApropAjuste do ACBrEPCBlocos. Revision: 33930 ACBrEPCBlocos.pas

Tbm é possível consultar as NFSe por período: Esse método retorna apenas as NFSe já processadas. ACBrNFSeX.ConsultarNFSeServicoTomadoPorPeriodo

Olá, Estou emitindo/consultando/cancelando para Barueri / SP com sucesso. O Provedor de Barueri, funciona de maneira assíncrona. Após enviar o provedor retorna o protocolo de recebimento. Esse protocolo vc deve armazena-lo para realizar as posteriores consultas. Depois de executar o ACBrNFSeX.Emitir(); Para pegar o protocolo gerado pelo provedor: ACBrNFSeX.WebService.Emite.Protocolo; Após o envio, vc precisa consultar a situação do RPS, pra validar se o provedor processou ou não o RPS. Para consultar use: ProtocoloEnvio := ACBrNFSeX.WebService.Emite.Protocolo; ACBrNFSeX.ConsultarSituacao(ProtocoloEnvio); Essa consulta retorna se o provedor processou ou não o RPS enviado, vc pode pegar o resultado em: ACBrNFSeX.WebService.ConsultaSituacao Veja tbm o ACBrNFSeX.WebService.ConsultaSituacao.Situacao 0 = Arquivo Validado 1 = Arquivo Importado 2 = Arquivo com Erros -1 = Em Processamento -2 = Aguardando Processamento Após essa Consulta o provedor retorna o protocolo atualizado, se ocorrer erro no processamento o provedor adicionar .ERR no protocolo. ProtocoloConsulta := ACBrNFSeX.WebService.ConsultaSituacao.Protocolo Esse novo protocolo vc vai usar como entrada para o metodo ConsultarLoteRps, que vai retornar o XML ou os detalhes dos erros. Então, com o protocolo resultante do ConsultarSituacao, utilize pra consultar o lote: ACBrNFSeX.ConsultarLoteRps(ProtocoloConsulta); Nessa consulta o provedor retorna o XML ou os erros. Pegue o resultado em: ACBrNFSeX.WebService.ConsultaLoteRps ACBrNFSeX.WebService.ConsultaLoteRps.Erros

@Vanderlei Soares Sim, estou enviando, consultando e cancelando com sucesso pra Barueri-SP.

Olá, para adicionar ao post. Estou recebendo o mesmo retorno. Quando o ACBrNFSeX tenta ler o Retorno de um envio pro Provedor SigISS, município de Londrina. O erro retorna quando executa o método LoadFromXml do TACBrXmlDocument. TACBrXmlDocument.LoadFromXml(AXmlDocument: string); Utilizando Lazarus e Linux. Retorno tratado pelo ACBrNFSeX: 2-lista-nfse-ger.xml

Por email, me enviaram que é necessário ser 099-X. Solicitei a nova documentação. Assim que pegar coloco aqui junto a alteração pra usar X.

Olá, Interessante! Não existe um "setter" pra propriedade digito e o GetDigito, pega do BancoClass, que aqui está retornando 4.

Olá, Estou realizando a homologação com Uniprime. Tive a mesma critica do Digito X na impressão do Boleto. Usando Lazarus. Utilizando o Fortes pra impressão existe um tratamento para imprimir X quando o digito do banco for maior ou igual a 10. Como mostra a imagem: Fiz um teste com o demo forçando um o valor 10 no digito do banco, conforme sugerido. Porém o boleto ainda está sendo impresso com o digito 4, que é atribuído ao informar o tipo Uniprime. ACBrBoleto1.Banco.Digito := 10; ACBrBoleto1.Imprimir; Fui olhar a property e a mesma tem um Setter "fake" , usado apenas pra mostrar o ObjectInspector: Então indiferente do que informar no Digito do Banco o Fortes não vai considerar. Sugiro implementarmos um Set pra property e no Get tratar se existe algo nela, caso contrario podemos retornar o Digito que está na propria classe do Banco. TACBrBanco = class(TComponent) private fDigitoManual: Integer; .... procedure TACBrBanco.SetDigito(const AValue: Integer); begin fDigitoManual := AValue; end; function TACBrBanco.GetDigito: Integer; begin Result := fBancoClass.Digito; if (fDigitoManual > 0) then Result := fDigitoManual; end;

Olá, Apenas retornando a atual situação. Ajustei a rotina pra configurar o Report, conforme a sugestão. No primeiro momento não teve efeito. Então, criei uma VM para executar o teste, pra validar o ambiente do SO, nessa caso deu tudo certo. Por mais que a alteração sugerida funcionou nos casos acima e que tbm foi implementada aqui, tive que concluir que alguma coisa no SO também estava interferindo.... Por enquanto o código de barras com a alteração + novo SO (Linux Ubuntu 16.04.6 LTS) esta imprimindo corretamente. Muito obrigado @Juliomar Marchetti.

Isso @Juliomar Marchetti. Ubuntu 16.04 x86_64. Executei pelo Demo e também mostra colorido. Tem possibilidade de ser alguma lib externa?

Olá, Estou passando a mesma situação. O código de barras está colorido. Alterei o código com a implementação sugerida acima, tanto no relatório quanto no próprio Fortes, mesmo assim o problema continuou. Alguma outra solução?

Veja o cometário:

@Daniel Simoes Acabei de atualizar o ACBr e notei que vc commitou um biblioteca de Terceiro para trabalhar com JSON. Revision: 14751 Author: dopi Date: segunda-feira, 26 de fevereiro de 2018 18:51:58 Queria te mostrar a PasJSON desenvolvida pelo Benjamin (BeRo1985), totalmente compatível com Delphi/FPC. https://github.com/BeRo1985/pasjson Achei o Parser do PasJSON muito mais otimizado do que a Json4Delphi. Estou testando ela no Lazarus/FPC e não tive nenhum problema. Poderia considerar um estudo, pra que ela se torne a Lib de JSON do projeto ACBr?

Da uma olhada nesse comentário:

@Juliomar Marchetti, não, está tudo certo. Fiquei interessado em conhecer essa integração via DLL com a NTK. Solicitei o manual pra eles, mas ainda não responderam... será que é compatível com alguma implementação do ACBrTEFD? Assim que me enviarem o manual, vou dar uma olhada no nível de compatibilidade. Qualquer coisa te aviso daí. O que vc acha?

Interessante a DLL da NTK, não precisa da VPN. @Juliomar Marchetti Existe algum planejamento para implementação via DLL da NTK?

Não. Pra resolver deixo o certificado em cada PC que vai emitir algum tipo de DFe...

Olá, Provavelmente seu ResponseCosmos está NIL. Faça o seguinte: ResponseCosmos := RESTResponse2.JSONValue; ou RESTResponse2.JSONValue.GetValue<TJSONString>('description').Value; Tome cuidado ao acessar variáveis não instanciadas...

Não tenho o Tokyo para verificar, mas provavelmente é o uses que não está correto... Adicione a REST.Types no uses do seu fonte e tente novamente... Pode dar uma olhada aqui: http://docwiki.embarcadero.com/Libraries/Tokyo/en/REST.Types.TRESTRequestMethod

Diz para o servidor que você está enviando na requisição um XML: IdHTTP.Request.ContentType := 'text/xml'; IdHTTP.Request.ContentEncoding := 'utf-8'; Diz para o servidor que você quer receber a resposta em XML: IdHTTP.Request.Accept := 'text/xml';

É so seguir o fluxo do processo que esta no demo. Não tem segredo, é só implementar os eventos e pronto. @Poliany, seja mais especifica com o seu problema. De preferencia em um novo tópico.

Visto que eles disponibilizam uma API RESTFull respondendo JSON, o passo inicial seria definir/criar uma biblioteca de JSON pro ACBr. Veja a discussão:

Realmente uma biblioteca de JSON é muito abrangente e demandaria um bom esforço inicial pra criar uma. No meu ver, o melhor dos mundos seria usar as bibliotecas nativas, porém será necessário um bom trabalho pra criar uma Fachada que encapsule as bibliotecas do Delphi e do Lazarus. Pelo menos a maioria das classes entre Delphi/Lazarus tem o mesmo nome... (TJSONObject, TJSONString, TJSONNumber, etc). Mas diante do que o Elton disse, sobre estabilidade, erros, no final fica melhor usar uma de Terceiro mesmo. xD Já usei a LkJSON, tanto no Delphi quanto no Lazarus. Apesar do repositório dela esta parada, ela está estável. Achei interessante a: https://github.com/hgourvest/superobject - Para Delphi e Lazarus. Eu não intendo muito bem essa questão de licença... qual licença que a biblioteca deve estar registrada pra podermos usar e modificar se necessário?

Pessoal, Inevitavelmente, cada vez mais JSON vem se tornando o protocolo de comunicação mais utilizados entre as aplicações. Sabemos que existem bibliotecas de conversão nativas tanto para o Delphi quanto para o Lazarus. E tantas outras de terceiros, de código fechado e de código aberto. Creio que cedo ou tarde, o projeto ACBr terá que fazer uso de alguma biblioteca JSON, então gostaria de propor aqui uma discussão pra validar/decidir o uso de JSON dentro do projeto ACBr. Poderia-se iniciar com algumas questões: Criar uma biblioteca própria? Criada do zero, ou se basear em alguma já existente? Usar uma existente e colocar dentro de /Terceiros/? Qual biblioteca existente utilizar? Usar nativo? IFDEF pra Lazarus e Delphi/XE? Estou levantando essa questão, pois estou criando um componente pra realizar a comunicação com o COSMOS da Bluesoft fazendo uso da TACBrHTTP, onde o retorno é JSON. Na qual, quem sabe após a definição de uma biblioteca JSON, esse componente poderá fazer parte do projeto ACBr... claro se o mesmo for aprovado. Aguardo uma discussão []'s

Vc não, necessariamente, precisa usar TClientDataSet, quando vc trabalha com Zeos, a TZQuery, consegue trabalhar off-line. O seu problema está em: TZAbstractConnection.StartTransaction; Aqui é chamado a verificação do contador de transação. Veja aqui: Unit: ZAbstractConnection Classe: TZAbstractConnection Metodo: CheckAutoCommitMode procedure TZAbstractConnection.CheckAutoCommitMode; begin if not FAutoCommit and (FExplicitTransactionCounter = 0) then raise EZDatabaseError.Create(SInvalidOpInNonAutoCommit); end; Em anexo estou deixando um pdf que irá te ajudar. Tutorial_Zeos_Especial_Em_Portugues_BR.rar