Painel de líderes

Olá Pessoal Foi publicado a NT 2020/001 versão 1.10 que traz uma tabela com os prazos para o envio dos eventos da Manifestação do Destinatário. A manifestação está prevista na cláusula décima-quinta-A do Ajuste SINIEF 7/05, a qual estabelece que o destinatário da Nota Fiscal eletrônica confirme a sua participação na operação acobertada pela Nota Fiscal eletrônica emitida para o seu CNPJ/CPF, através dos eventos tratados logo a seguir. A versão 1.10 dessa NT apresenta a tabela abaixo com os prazos para o registro dos eventos conforme estabelecido no Ajuste SINIEF 44/2020. O envio dos eventos fora dos prazos estabelecido vai ocorrer a Rejeição 596: Evento apresentado fora do prazo: [prazo vigente] Essa regra de validação entra em vigor no ambiente de produção a partir de 04/04/2022 Evento Prazo legal (Ajuste SINIEF 44/2020) Ciência da Emissão 10 dias contados a partir da data de autorização da NF-e Confirmação da Operação 180 dias contados a partir da data de autorização da NF-e Desconhecimento da Operação 180 dias contados a partir da data de autorização da NF-e Operação Não Realizada 180 dias contados a partir da data de autorização da NF-e Observação: note que a contagem de dias é sempre baseado na data de autorização da NF-e e não na data de recebimento da mercadoria. Quem é obrigado a enviar os eventos da Manifestação do Destinatário? A cláusula décima-quinta-B do Ajuste SINIEF 7/2005 prevê a obrigatoriedade do registro pelo destinatário da NF-e dos eventos de confirmação da operação, operação não realizada e desconhecimento da operação nos prazos especificados naquele Ajuste. Também está obrigado a realizar a manifestação, de acordo com o Anexo II do Ajuste SINIEF 7/2005, o destinatário de toda NF-e que: I – seja exigido o preenchimento do Grupo Detalhamento específico de Combustíveis, como nos casos de mercadoria destinada a: a) estabelecimentos distribuidores de combustíveis, a partir de 1º de março de 2013; b) postos de combustíveis e transportadores revendedores retalhistas, a partir de 1º de julho de 2013; II - acoberte operações com álcool para fins não-combustíveis, transportado a granel, a partir de 1º de julho de 2014; III – acoberte, nos casos em que o destinatário for um estabelecimento distribuidor ou atacadista, a partir de 1º de agosto de 2015, a circulação de: a) cigarros; b) bebidas alcoólicas, inclusive cervejas e chopes; c) refrigerantes e água mineral. Observação: • a NT 2012/003 (item 03.1), publicada em agosto/2012, define quais são os CFOP que obrigam a informação do Grupo de Combustível na NF-e. Os CFOP citados estão relacionados com as operações que envolvem “Combustível derivado ou não de Petróleo e Lubrificantes”. • Como as operações com lubrificantes são exceção à obrigatoriedade de manifestação do destinatário, consta no Anexo II a tabela de Códigos de Produto da ANP relativa a lubrificantes e que não estão obrigados à Manifestação do Destinatário. Como realizar o envio dos eventos da Manifestação do Destinatário? O destinatário caso não tenha uma aplicação que lhe permite a realizar o envio dos eventos, poderá utilizar o serviço que consta no Portal Nacional da NF-e: No menu “Serviços”, “Manifestação Destinatário” do Portal Nacional da NF-e (https://www.nfe.fazenda.gov.br) é disponibilizada a opção de realizar a manifestação por chave de acesso ou por NSU (Número Sequencial Único), sendo obrigatório o uso de Certificado Digital do destinatário. No Portal Nacional da NF-e tem também um aplicativo que o destinatário poderá baixar: No menu “Downloads”, “Manifestador de NF-e” do Portal Nacional da NF-e (https://www.nfe.fazenda.gov.br) foi disponibilizado software desenvolvido pela SEFAZ-SP que viabiliza exclusivamente a manifestação do destinatário pessoa jurídica, sendo obrigatório o uso de Certificado Digital do destinatário. Para o desenvolvedor que queira implementar essa funcionalidade em sua aplicação o Projeto ACBr disponibiliza: O componente ACBrNFe para os desenvolvedores que se utilizam das ferramentas Delphi ou Lazarus para desenvolverem as suas aplicações utilizando a linguagem Object Pascal. O ACBrMonitor Plus, uma aplicação feita em Lazarus destinada aos desenvolvedores que trabalham com outras linguagens de programação. O ACBrLibNFe, uma DLL que também pode ser utilizada pelos desenvolvedores de outras linguagens caso não desejem usar o ACBrMonitor Plus.

Conforme informação compartilhada conosco pelo nosso colega explorerSilva, a SEFAZ-PE enviou comunicado aos seus contribuintes informando que os seguintes protocolos terão seu suporte removido de suas sessões de conexão segura dos web services do Portal GNRe. SSL2 SSL3 TLS 1.0 TLS 1.1 Importante: A partir de 13/07/2021 somente o protocolo TLS 1.2 será aceito para as conexões com o os web services do GNRe. A seguir a transcrição do comunicado. "Com objetivo de manter a segurança dos serviços da Secretaria da Fazenda de Pernambuco - SEFAZ/PE, comunicamos a todos os usuários do serviço GNRE que serão tomadas medidas técnicas para proteger a confidencialidade e integridade da comunicação https, no sentido de remover o suporte aos protocolos obsoletos SSL2, SSL3, TLS 1.0 e TLS 1.1 em sessões seguras dos web services do Portal GNRE (https://www.gnre.pe.gov.br/gnreWS/services). A partir de 13/07/2021, disponibilizaremos, apenas o protocolo TLS 1.2 para sustentar as sessões seguras do GNRE, com os seguintes requisitos obrigatórios: 1) Utilizaremos apenas as cifras AES 256 ou 384 bits, com modo de cifragem GCM. Não haverá suporte às cifras DES, RC2, RC4, 3DES. 2) Utilizaremos apenas o protocolo ECDH para troca inicial de chaves da sessão https. Não haverá suporte ao protocolo RSA para essa finalidade. 3) Os hashes para assinatura dos blocos de cifragem serão de no mínimo 256 bits. Em síntese, a SEFAZ disponibilizará o serviço GNRE com protocolo TLS 1.2 nas seguintes configurações: a) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Atualmente, o conjunto de cifras acima representa a forma mais segura para proteger a confidencialidade e integridade da sessão https. Diante do exposto, solicitamos aos usuários que adequem os serviços consumidores do GNRE, a fim de prover suporte ao protocolo TLS 1.2, na configuração supracitada. A partir de 13/07/2021, os protocolos obsoletos não serão mais admitidos, e as conexões que as utilizem serão negadas no ambiente de Produção. O ambiente de testes do Portal GNRE (https://www.testegnre.pe.gov.br/gnreWS/services) passará por esta atualização, deixando de suportar os protocolos obsoletos mencionados, em 02/07/2021. Sugerimos à equipe técnica responsável pela sustentação do serviço consumidor do GNRE a diagnosticá-lo por meio da página do SSLLabas (https://www.ssllabs.com/ssltest/), ou por meio de utilitários específicos para essa necessidade. O resultado revelará quais protocolos estão sendo utilizados, obsoletos ou não. Finalmente, esclarecemos que o suporte às cifras seguras é provido pelo sistema operacional que sustenta a aplicação consumidora do GNRE, e que, em regra, sistemas operacionais obsoletos ou sem suporte do fabricante não dispõem do protocolo TLS 1.2 na configuração informada, sendo necessário muitas vezes atualizar o sistema operacional para dispor da configuração adequada. Em caso de dúvidas tratar EXCLUSIVAMENTE com o TELESEFAZ, através dos canais de atendimento abaixo: (81) 31835913 - Whatsapp @Sefz_pe_bot – Telegram www.sefaz.pe.gov.br – Chat 08002851244: para ligações feitas em Pernambuco através de telefone fixo (81) 3183 6401: para as demais ligações (celular, outros Estados, etc). Horário de atendimento do Telesefaz: 8:00h às 18:00h - de segunda a sexta Atenciosamente, Gestor Nacional do Sistema GNRE Secretaria da Fazenda do Estado de Pernambuco"

Olá, Recentemente diversas empresas estão emitindo boletos com QrCode para pagamento via PIX (Boleto Híbrido), ficando a critério do pagador escolher a forma de pagamento através da ficha de compensação "Código de Barras / Linha Digitável' ou com o PIX "QRCode". Mas até então isso não estava formalizado pelo Banco em si, ou seja, o controle de Baixa do título caso seja pago por PIX ficaria a cargo da própria empresa, como ocorre no fluxo de várias API hoje disponíveis no mercado... Porém, o Banco do Brasil foi o pioneiro em disponibilizar esse tipo de integração em sua própria API, assim ao registrar um Título pode ser definido se será gerado também uma chave PIX dinâmica referente aquele título, com isso o controle da forma de pagamento fica com o Banco, independente se for pago via PIX ou Boleto. Isso facilita muito o controle por parte da empresa beneficiária e viabilizou a implementação desse tipo de integração via API também no componente ACBrBoleto. No componente ACBrBoleto já existia a possibilidade de Registro Online de Boletos para alguns Bancos, inclusive o Banco do Brasil via WebService, mas essa API se trata de um novo Serviço, portanto são configurações e funcionalidades distintas no componente ACBrBoleto. Neste tópico vamos descrever como realizar a homologação e utilizar a API do Banco do Brasil através do componente ACBrBoleto. 1- Primeiro passo é realizar o Cadastro do seu Aplicativo no ambiente Sandbox BB, com isso será fornecido as credenciais para autenticação da API em ambiente de homologação. Utilize o Serviço API Cobrança: https://developers.bb.com.br/home Documentação da API e como utilizar o ambiente Sandbox para cadastrar a aplicação: https://apoio.developers.bb.com.br/referency/post/5ffc477c3b02bd0012ecaa1a 2- Após o Cadastro poderá obter o ClientID e ClientSecret que precisará configurar no componente ACBrBoleto, cada emitente terá seu próprio ClientID e ClientSecret. No componente ACBrBoleto configure em: Banco / TipoCobranca=cobBancoBrasilAPI No componente ACBrBoleto configure em: Cedente / CedenteWS ClientID=Informe o ClientID gerado no Ambiente Sandbox BB ClientSecret=Informe o ClientSecret gerado no Ambiente Sandbox BB Scope=cobrancas.boletos-info cobrancas.boletos-requisicao KeyUser=developer_application_key IndicadorPix=True //Para utilização do PIX pela API - Banco do Brasil é necessário que o emitente tenha chave PIX cadastrada no BB, caso for utilizar somente a emissão tradicional pela API enviar False nesse parâmetro. Em Configurações / WebService - Configure da seguinte Forma: Na opção de Ambiente escolher de acordo com a operação que esteja fazendo (Homologação ou Produção) necessário coerência com as chaves contratuais junto ao BB. As operações homologadas para a API BB são de Inclusão e Consulta [tpInclui, tpConsulta, tpBaixa, tpAltera] SSLHttpLib utilizar cryOpenSSL SSLType utilizar LT_TLSv1_2 3 - Com essas configurações já é possível realizar o registro de um título no BB via API. O Título deve ser incluso normalmente como no processo tradicional do componente, mas ao invés de gerar uma remessa, utiliza-se o o método "EnviarBoleto" - (botão no Aplicativo ACBrBoleto Demo: [Registrar Boleto On-Line]) . Este botão possui exemplos de como obter o Retorno da API. Se o título foi registrado sem nenhuma rejeição, automaticamente será atualizado a chave PIX junto ao Título. Atenção usuários do Inter : Uma das informações que deve ser armazenada do retorno da inclusão é a propriedade “NossoNumeroCorrespondente” pois toda operação de alteração, baixa e consulta você vai precisar informar esta propriedade. (é um código UUID de identificação do boleto) Particularidades BB via API: obs: API possui envio Síncrono Carteira=17 EspecieDoc=DM Modalidade=35 CodigoCedente=Informar Código Cedente Convenio=Informar o Convenio 4- Para imprimir o Boleto: Obs: Quando utilizado PIX, é necessário que além das informações tradicionais, sejam informadas no título o retorno do registro "QrCode" na propriedade "EMV", esse campo corresponde a String de geração do QRCode PIX gerada pelo Banco. ex: Titulo.qrcode.emv := FRetornoConteudoEMV; Impressão em FortesReport: Utilize o Layout "PadraoPIX" Impressão em FastReport: Selecione o arquivo "BoletoPIX.fr3" no diretório "Report" junto ao ACBrBoleto Demo. Segue o Modelo de Boleto Híbrido Impresso: 5- Consulta de Títulos via API Na aplicação ACBrBoletoDemo temos o botão "Consultar Boleto" com código exemplo de como passar os parâmetros para realizar uma consulta na API, o retorno será gerado em uma lista para posterior validação de cada Título. Obs: A homologação deve ser feita também junto ao Banco, inclusive enviando os modelos das Fichas de Compensação emitidas para validação. Todos os testes foram realizados em ambiente de homologação, então é importante a validação completa antes de emitir em ambiente de produção. Atenção usuários do Inter : Uma das informações que deve ser armazenada do retorno da inclusão é a propriedade “NossoNumeroCorrespondente” pois toda operação de alteração, baixa e consulta você vai precisar informar esta propriedade. (é um código UUID de identificação do boleto)

Olá Pessoal, Foi publicado a NT 2020/005 que contem alterações no layout do XML da NF-e e alterações de regras de validação. O prazo previsto para a implementação das mudanças é: 01/07/2021 - Ambiente de Homologação 01/09/2021 - Ambiente de Produção No que se refere ao layout do XML vão ser acrescentados os campos: cBarra e cBarraTrib para informar o código de barra que são diferentes do GTIN. O campo tpViaTransp vai passar a ter novos valores; No detalhamento do ICMS vamos passar a ter novos campos: vICMSSTDeson e motDesICMSST. Com relação ao Fundo de Combate a Pobreza teremos os novos campos: pFCPDif, vFCPDif e vFCPefet. Consta também de forma errônea que a placa do veículo vai passar a ser opcional, mas o correto é a UF por conta da placa Mercosul. Essas são algumas das novidades, para mais informações convido a todos a lerem a NT que se encontra disponível em nossa biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/NFeNFCe/NT/2020/ Observação: Como vai ocorrer alteração no layout do XML da NF-e vai ser necessário atualizar os fontes do componente ACBrNFe bem como os Schemas independente se você vai usar esses campos na sua aplicação.

Não.. com essa propriedade de avanço.. ela "avança" as etiquetas para destaque, quando for iniciar a próxima impressão, ela puxa de volta...

Oi @RicardoVoigt eu fiz uns testes em cima do que falou mas não deu certo aqui, talvez por inexperiência. Fiz uma postagem no Issues do Fortes Adição de Nova Propriedade #284 para o Juliomar com as duas units alteradas. Com a propriedade InitialDir no RLPreviewSetup basta acrescentar ele no mesmo form de onde esta a DANFERL, sem nenhuma mudança no ACBr. Alimentando a propriedade ao se aperta o botão de selecionar o savedialog vinculado já fica setado e no edit já aparece esse caminho para que o usuario possa colocar o nome que quiser no arquivo. Para não atrapalhar eu mantive a mesma logica anterior se não tiver setado InitialDir o edit recebe apenas o nome do arquivo. Valeu a ajuda.

Há um comando que pode ser enviado para a impressora avançar o Papel... mas isso depende da sua impressora e do programa que utiliza... Em nosso componente ACBrETQ essa propriedade se chama "Avanco"

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

Obrigado Italo, era isso mesmo. Deu certo. Na 1.0 sempre coloquei o numero da nota no campo documentoOrigem e a chave nas informações complementares. Grato Pela ajuda!

Olá pessoal... Atualizamos o programa do nosso Fórum, para o Invision Power Board 4.6.2 Nesse link, é possível ver todas as modificações, introduzidas nessa nova versão: https://invisioncommunity.com/news/product-updates/ O Invision, vem se tornando uma plataforma fantástica, para criação de comunidades... Estamos muito contentes com as melhorias.. Em destaque, para esse novo Update, o novo sistema de Rankings e Insígnias...

Muito bacana... que bom que conseguiu... Creio que há um Bug nesse Botão do MonitorPlus que deveria considerar. SO quando no Linux é não DLL.. O @José M. S. Junior pode verificar isso...

Manual de migração para o novo componente de NFS-e. 1. Introdução Foi realizado um refactoring no componente de emissão de NFS-e Nota Fiscal de Serviço Eletrônica, que acabou resultando em um novo componente chamado ACBrNFSeX e consequentemente um novo para impressão do DANFSE (ACBrNFSeXDANFSERL – Fortes Report). O motivo de realizar esse refactoring foi devido a uma grande quantidade de IF e CASE em diversas units para sanar a falta de padronização entre os provedores. O componente também tinha algumas propriedades de configuração repetidas com nomes diferentes e até campos na classe da NFS-e que na verdade deveriam ser propriedades de configuração, ou seja, propriedades de configuração foram implementadas como sendo campos de uma NFS-e. Portanto ao realizar a troca do componente atual (ACBrNFSe) pelo novo (ACBrNFSeX) vai ocorrer quebra de código. Esse manual tem como objetivo apresentar um roteiro de migração e apresentar o que mudou de um componente para o outro. 2. Propriedades de configuração excluídas Foram excluídas as propriedades: SenhaWeb, UserWeb, PathIniCidades, PathIniProvedor e DadosSenhaParams, Key, Auth, RequestId e Resposta. 3. Propriedades de configuração renomeadas As propriedades: WebUser, WebSenha, WebFraseSecr e WebChaveAcesso agora se chamam: WSUser, WSSenha, WSFraseServ e WSChaveAcesso. Essas propriedade se encontram em: Configuracoes.Geral.Emitente 4. Propriedades de configuração novas Foi incluída as propriedades: WSChaveAutoriz (string) em Configuracoes.Geral.Emitente e ConsultaAposCancelar (Boolean) em Configuracoes.Geral. 5. Campos excluídos Foram excluídos da classe IdentificacaoPrestador os campos: Senha, FraseSecreta, cUF, ChaveAcesso, Usuario, CNPJ_Prefeitura, ValorReceitaBruta, DataInicioAtividade, RazaoSocial, Fantasia, Endereco, Telefone, Email, crc e crc_estado. Alguns desses campos que foram excluídos possuem uma propriedade de configuração, logo o componente vai se utilizar da informação que se encontra na configuração do mesmo. Outros campos migraram para uma outra classe. Excluído o campo PrestadorServico da classe NFSe, para informar os dados do prestador devemos utilizar o campo Prestador que já existia na classe NFSe. Os campos CNPJ e InscricaoMunicipal agora estão dentro da classe IdentificacaoPrestador, exemplo: Prestador.IdentificacaoPrestador.CNPJ Prestador.IdentificacaoPrestador. InscricaoMunicipal Excluído os campos Discriminacao, ValorServicos e Codigo da classe ItemServico, usar no lugar os campos Descricao, ValorTotal e CodServ. A classe ItemServico é utilizada pelos provedores que permitem incluir mais de um item de serviço no RPS. 6. Campos renomeados O campo ChaveNFSe da classe NFSe que é utilizado pelo provedor Infisc foi renomeado para refNF para compatibilizar com a nomenclatura da tag no XML, o seu conteúdo é gerado automaticamente, logo não se faz necessário atribuir nada a ele. 7. Campos novos Na classe DadosPrestador passou a ter os campos: cUF (Integer), crc (string), crc_estado (string), DataInicioAtividade (TDateTime) e ValorReceitaBruta (Currency). Na classe NFSe foi incluído o campo SituacaoTrib (TSituacaoTrib) pois estava sendo utilizado um outro campo chamado Situacao, sendo que este contem a situação do processamento do RPS. 8. Campos cujo tipo foi alterado Alterado o tipo de string para TTipoPessoa do campo Tipo que se encontra na classe IdentificacaoTomador. 9. Métodos excluídos Foi excluído o método Enviar, EnviarSincrono e Gerar. 10. Métodos renomeados O método SetConfigMunicipio agora se chama LerParamsMunicipio. 11. Métodos novos Foi implementado o método Emitir que detecta o modo de envio correto para cada provedor. O método Emitir possui 3 parâmetros: aLote do tipo Integer ou String que contém o número do lote de RPS que está sendo enviado para o WebService; aModoEnvio do tipo TmodoEnvio cujos valores aceitos são (meAutomatico é o valor padrão): meAutomatico = o componente vai utilizar o serviço mais adequado ou implementado pelo provedor; meLoteAssincrono = o componente vai utilizar o serviço que recepciona o lote de RPS no modo assíncrono, se o provedor não tem esse serviço será apresentado uma mensagem de erro acusando que o serviço não foi implementado pelo provedor; meLoteSincrono = o componente vai utilizar o serviço que recepciona o lote de RPS no modo síncrono, se o provedor não tem esse serviço será apresentado uma mensagem de erro acusando que o serviço não foi implementado pelo provedor; meUnitario = o componente vai utilizar o serviço que recepciona um RPS por vez, se o provedor não tem esse serviço será apresentado uma mensagem de erro acusando que o serviço não foi implementado pelo provedor; meTeste = alguns provedores possuem um serviço exclusivo para realização de teste de envio de lote de RPS, para esses casos devemos usar esse modo de envio. aImprimir do tipo Boolean (True é o valor padrão), se for True imprimir automaticamente o DANFSE. Foi acrescentado os métodos GravarINI e LerINI, visando gravar e ler o arquivo INI de configuração do componente, esse arquivo INI de configuração será utilizado pelo ACBrMonitor e ACBrLibNFSe. Foi implementado o método LerArqIni visando a leitura de um arquivo INI com os dados do serviço prestado. Esse método também será utilizado pelo ACBrMonitor e ACBrLibNFSe. 12. Métodos que sofreram alteração em seus parâmetros No método ConsultarLoteRps a ordem dos parâmetros foi alterada, agora é: Protocolo e depois Número do lote, uma vez que o número do lote só é utilizado por alguns provedores e não por todos. Definição do método na unit ACBrNFSeX: function ConsultarLoteRps(const AProtocolo: String; const ANumLote: String = ''): Boolean; No método ConsultarNFSePorRps foi removido o último parâmetro: ACodMunicipioTOM em seu lugar foi incluído: ACodVerificacao, o motivo dessa troca é que nenhum provedor está utilizando o código do município do tomador na consulta e por outro lado temos provedores que se utilizam do código de verificação. Definição do método na unit ACBrNFSeX: function ConsultarNFSeporRps(const ANumRPS, ASerie, ATipo: String; const ANumLote: String = ''; const ACodVerificacao: string = ''): Boolean; No método ConsultarNFSe foram removidos todos os parâmetros e no lugar foi colocado o aInfConsultaNFSe que é do tipo TInfConsultaNFSe. Para entender como devemos informar os dados para efetuar a consulta de uma nota vide o programa exemplo do novo componente. Foram criados vários métodos de Consulta de NFSe: Usado pelos provedores que seguem a versão 1 do layout da ABRASF. function ConsultarNFSePorNumero(const aNumero: string; aPagina: Integer = 1): Boolean; Usados pelos provedores que seguem a versão 2 do layout da ABRASF. Realiza uma consulta por faixa de números de notas: function ConsultarNFSePorFaixa(const aNumeroInicial, aNumeroFinal: string; aPagina: Integer = 1): Boolean; Realiza uma consulta por período: function ConsultarNFSePorPeriodo(aDataInicial, aDataFinal: TDateTime; aPagina: Integer = 1; aNumeroLote: string = ''): Boolean; Realiza uma consulta por numero de uma nota – serviço prestado: function ConsultarNFSeServicoPrestadoPorNumero(const aNumero: string; aPagina: Integer = 1): Boolean; Realiza uma consulta por período – serviço prestado: function ConsultarNFSeServicoPrestadoPorPeriodo(aDataInicial, aDataFinal: TDateTime; aPagina: Integer = 1): Boolean; Realiza uma consulta por tomador – serviço prestado: function ConsultarNFSeServicoPrestadoPorTomador(const aCNPJ, aInscMun: string; aPagina: Integer = 1): Boolean; Realiza uma consulta por intermediário – serviço prestado: function ConsultarNFSeServicoPrestadoPorIntermediario(const aCNPJ, aInscMun: string; aPagina: Integer = 1): Boolean; O autor das consultas acima é o prestador de serviço. Realiza uma consulta por numero de uma nota – serviço tomado: function ConsultarNFSeServicoTomadoPorNumero(const aNumero: string; aPagina: Integer = 1): Boolean; Realiza uma consulta por período – serviço tomado: function ConsultarNFSeServicoTomadoPorPeriodo(aDataInicial, aDataFinal: TDateTime; aPagina: Integer = 1): Boolean; Realiza uma consulta por prestador – serviço tomado: function ConsultarNFSeServicoTomadoPorPrestador(const aCNPJ, aInscMun: string; aPagina: Integer = 1): Boolean; Realiza uma consulta por tomador – serviço tomado: function ConsultarNFSeServicoTomadoPorTomador(const aCNPJ, aInscMun: string; aPagina: Integer = 1): Boolean; Realiza uma consulta por intermediário – serviço tomado: function ConsultarNFSeServicoTomadoPorIntermediario(const aCNPJ, aInscMun: string; aPagina: Integer = 1): Boolean; O autor das consultas acima é o consulente, que pode ser o tomador do serviço ou outra pessoa como por exemplo o contador. Caso o provedor não tenha disponibilizado esses serviços de consultas em seu WebService, uma mensagem de erro será apresentada acusando que o serviço não foi implementado pelo provedor. No método CancelarNFSe foram removidos todos os parâmetros e no lugar foi colocado o aInfCancelamento que é do tipo TInfCancelamento. Para entender como devemos informar os dados para efetuar o cancelamento de uma nota vide o programa exemplo do novo componente. O primeiro parâmetro do método LinkNFSe no novo componente obrigatoriamente tem que ser uma string. 13. Arquivos INI O novo componente não se utiliza mais dos arquivos INI dos provedores e nem do Cidades.ini Agora temos uma unit para cada provedor e o conteúdo do arquivo Cidades.ini migrou para o arquivo ACBrNFSeXServicos.ini que é convertido em um arquivo RES através do BAT chamado Compila_RES. O arquivo ACBrNFSeXServicos.res é incorporado ao executável ao compilar a aplicação, desta forma não se faz necessário disponibilizar junto com o executável nenhum arquivo INI. Layout de uma seção no arquivo ACBrNFSeXServicos.ini [9999999] Código IBGE da cidade. Nome= Nome da cidade de preferência sem cedilha e vogal acentuada. UF= Sigla da UF da referida cidade. Provedor= Nome do provedor, deve-se respeitar a grafia levando em consideração letras maiúsculas e minúsculas. Os 2 campos abaixo são utilizados pelo provedor Governa Params1= Informar a versão do layout do Arquivo que é usado no elemento: tsVrsArq Params2= Informar a versão do layout de Impressão que é usado no elemento: tsVrsImp Os 2 campos abaixo são utilizados pelo provedor DataSmart Params1= O provedor defini uma abreviação do nome da cidade, por exemplo B_SJOSE é utilizado para a cidade de São Jose do Ouro. Params2= Por padrão o valor BANCO_DEMOSTRACAO. O campo abaixo defini o código da Entidade definida pelo provedor Equiplano para cada cidade. Params1= Informar o código da Entidade que usado no elemento: IdEntidade. Os 2 campos abaixo são utilizados para definir a URL do Link para se ter acesso ao DANFSE via navegador. ProLinkURL= Informar a URL do ambiente de Produção. HomLinkURL= Informar a URL do ambiente de Homologação. Os 2 campos abaixo são utilizados para definir a URL do NameSpace, o provedor ISSDSF tem um NameSpace diferente para cada cidade. ProNameSpace= Informar a URL do NameSpace para o ambiente de Produção. HomNameSpace= Informar a URL do NameSpace para o ambiente de Homologação Os 2 campos abaixo são utilizados para definir a URL do NameSpace do XML, o provedor Actcon tem um NameSpace do XML diferente para cada cidade. ProXMLNameSpace= Informar a URL do NameSpace do XML para o ambiente de Produção. HomXMLNameSpace= Informar a URL do NameSpace do XML para o ambiente de Homologação Os 2 campos abaixo são utilizados para definir a URL do SoapAction, o provedor Actcon tem um SoapAction diferente para cada cidade. ProSoapAction= Informar a URL do SoapAction para o ambiente de Produção. HomSoapAction= Informar a URL do SoapAction para o ambiente de Homologação Se o provedor não tem uma URL de serviço padronizada de produção, ou seja, uma para cada cidade devemos utilizar os campos abaixo: ProRecepcaoLoteRPS= Informar a URL para o ambiente de Produção. Os campos abaixo só devem ser incluídos caso a URL seja diferente para cada serviço. ProConsultaSitLoteRPS= ProConsultaLoteRPS= ProConsultaNFSeRPS= ProConsultaNFSe= ProCancelaNFSe= ProGerarNFSe= ProRecepcaoSincrono= ProSubstituiNFSe= ProAbrirSessao= ProFecharSessao= Se o provedor não tem uma URL de serviço padronizada de homologação, ou seja, uma para cada cidade devemos utilizar os campos abaixo: HomRecepcaoLoteRPS= Informar a URL para o ambiente de Homologação. Os campos abaixo só devem ser incluídos caso a URL seja diferente para cada serviço. HomConsultaSitLoteRPS= HomConsultaLoteRPS= HomConsultaNFSeRPS= HomConsultaNFSe= HomCancelaNFSe= HomGerarNFSe= HomRecepcaoSincrono= HomSubstituiNFSe= HomAbrirSessao= HomFecharSessao= 14. Roteiro para migrar do componente atual ACBrNFSe para o novo ACBrNFSeX 1. Fazer uma cópia dos fontes do projeto; 2. Carregar o Delphi; 3. Abrir o projeto; 4. Remover os componentes (ACBrNFSe e ACBrNFSeDANFSeRL); 5. Remover do uses as units: ACBrNFSeDANFSeClass, ACBrNFSeDANFSeRLClass e ACBrNFSe; 6. Remover do uses (implementação) as units: ACBrNFSeNotasFiscais, ACBrNFSeConfiguracoes, pnfsConversao e pnfsNFSe; 7. Comentar as procedures: ACBrNFSe1GerarLote e ACBrNFSe1StatusChange tanto a sua declaração quanto a sua implementação; 8. Salvar o projeto; 9. Incluir os novos componentes: ACBrNFSeX e ACBrNFSeXDANFSeRL; 10. Salvar novamente o projeto; 11. Relacionar o ACBrNFSeX com o ACBrNFSeXDANFSeRL e com o ACBrMail; 12. Criar novamente os eventos GerarLote e StatusChange do componente ACBrNFSeX e inserir o seu código (tome como base o que está comentado); 13. Executar o Replace (ACBrNFSe1 para ACBrNFSeX1); 14. Trocar o NotasFiscais.Add.NFSe por NotasFiscais.New.NFSe; 15. Incluir no uses (implementação) a unit: ACBrNFSeXConversao; 16. Remover as linhas referentes as propriedades de configuração que não existe mais, conforme mencionado no início deste Manual; 17. Alterar o nome de algumas propriedades de configuração conforme mencionado no início deste Manual. 18. Alterar o conteúdo da procedure AtualizarCidades conforme apresentado neste Manual; 19. Alterar a ordem dos parâmetros do Consultar Lote; 20. Alterar o método Enviar(vNumLote) para Emitir(vNumLote, meLoteAssincrono); 21. Alterar o método Gerar(StrToint(vNumRPS)) para Emitir(vNumRPS, meUnitario); 22. Alterar o método EnviarSincrono(vNumLote) para Emitir(vNumLote, meLoteSincrono); 23. Alterar conforme acima os métodos CancelarNFSe e ConsultarNFSe e LinkNFSe; 24. Alterar conforme o programa exemplo do componente ACBrNFSeX a forma de realizar a Consulta a NFSe e o Cancelamento de NFSe; 25. Salvar, compilar (Build) e executar o projeto. 15. Alterar o código da procedure AtualizarCidades Como o novo componente não busca mais no arquivo Cidades.ini as cidades, se faz necessário alterar o código. Como o código deve ficar: procedure TfrmACBrNFSe.AtualizarCidades; var IniCidades: TMemIniFile; Cidades: TStringList; I: Integer; sNome, sCod, sUF: String; begin IniCidades := TMemIniFile.Create(''); Cidades := TStringList.Create; ACBrNFSeX1.LerCidades; IniCidades.SetStrings(ACBrNFSeX1.Configuracoes.WebServices.Params); try IniCidades.ReadSections(Cidades); cbCidades.Items.Clear; for I := 0 to Pred(Cidades.Count) do begin if (StrToIntdef(Cidades[I], 0) > 0) then begin //Exemplo: Alfenas/3101607/MG sCod := Cidades[I]; sNome := IniCidades.ReadString(sCod, 'Nome', ''); sUF := IniCidades.ReadString(sCod, 'UF', ''); cbCidades.Items.Add(Format('%s/%s/%s', [sNome, sCod, sUF])); end; end; //Sort cbCidades.Sorted := false; cbCidades.Sorted := true; edtTotalCidades.Text := IntToStr(cbCidades.Items.Count); finally FreeAndNil(Cidades); IniCidades.Free; end; end; 16. Tabela de mensagens geradas pelo componente Código Descrição X001 Serviço não implementado pelo Provedor. X002 Nenhum RPS adicionado ao componente. X003 Conjunto de RPS transmitidos (máximo de xxx RPS) excedido. Quantidade atual: yyy X101 Número do Protocolo não informado. X102 Número do RPS não informado. X103 Série do Rps não informado. X104 Tipo do Rps não informado. X105 Número Inicial da NFSe não informado. X106 Número Final da NFSe não informado. X107 Pedido de Cancelamento não informado. X108 Número da NFSe não informado. X109 Código de cancelamento não informado. X110 Motivo do Cancelamento não informado. X111 Número do Lote não informado. X112 Série da NFSe não informada. X113 Valor da NFSe não informado. X114 Tipo da NFSe não informado. X115 Data Inicial não informada. X116 Data Final não informada. X117 Código de Verificação/Validação não informado. X118 Chave da NFSe não informada. X201 WebService retornou um XML vazio. X202 Lista de NFSe não encontrada! (ListaNfse) X203 Não foi retornado nenhuma NFSe. X204 Confirmação do cancelamento não encontrada. X205 Retorno da Substituição não encontrada. X206 NFSe Substituída não encontrada. X207 NFSe Substituidora não encontrada. X208 Não foi retornado nenhum Rps. X999 E.Message