Painel de líderes

Olá pessoal! Muitos dos nosso membros que fazem uso do ACBrMonitor para emissão de NFS-e trabalham com múltiplas empresas. Para isso, existem duas maneiras de se trabalhar. Uma delas é criando múltiplas instâncias e instalações do Monitor, uma para cada empresa. A segunda é ir alterando os dados na configuração do monitor em tempo de execução de acordo com a empresa. No entanto, não haviam comandos que alterassem essas informações nas configurações especificas da NFSe, dificultando a segunda abordagem fazendo com precisem alterar direto no INI e até mesmo reiniciar o monitor para que as alterações surtam efeito. Visando auxiliar a comunidade e facilitar esse processo, foram adicionados na última compilação do Monitor os seguintes comandos: NFSe.SetCertificado NFSe.SetLayoutNFSe NFSe.SetCodigoMunicipio NFSe.Emitente NFSe.AutenticacaoNFSe Permitindo que agora a alteração seja feita dentro do próprio Monitor, diretamente via comando.

@Desenv. AT Info Sistemas, Maravilha, notei que a questão principal de configuração do componente foi sanada. Complementando o que o @Juliomar Marchetti lhe passou: Se não me falha a memória o componente envia o GNRE, obtém um retorno e nesse retorno costa o Numero do Recibo que é utilizado em uma consulta. Pode ser que no retorno do envio não consta o numero do recibo. Precisamos ver o XML de retorno do envio do GNRE, nele deve constar o problema do porque o numero do recibo não foi gerado.

Boa tarde, Conversei com minha colega e ela se informou e é preciso fazer cadastro para fazer testes no ambiente de homologação. Vamos fazer o cadastro e volto a testar. Muito Obrigado.

Kaikson, Verifique na sua aplicação se você não tem nenhuma linha alterando as propriedades da classe ConfigAssinar. Tanto a assinatura bem como a validação do XML antes do seu envio ocorre de forma automática, portanto não se faz necessário incluir nenhuma linha na sua aplicação para que a assinatura ou validação ocorra. O componente ACBrNFSeX tem esse comportamento, pois temos provedores que exige que somente o RPS seja assinado, outros exige que somente o Lote de RPS seja assinado, outros exige que tanto o RPS quanto ao Lote seja assinados e tem provedores que não devemos assinar nada. A procedure Configuracao que existe na unit Provider de cada provedor define o deve ser assinado.

Bom dia @Kaikson, Você chegou a comparar o XML *-env-lot-sinc.xml gerado pelo programa exemplo e pela sua aplicação? A cidade de Rolim de Moura/RO se utiliza do provedor WebISS (versão 2.02 do layout da ABRASF). Na unit WebISS.Provider temos: procedure TACBrNFSeProviderWebISS202.Configuracao; begin inherited Configuracao; with ConfigAssinar do begin Rps := True; LoteRps := True; CancelarNFSe := True; RpsGerarNFSe := True; RpsSubstituirNFSe := True; SubstituirNFSe := True; end; with ConfigWebServices do begin VersaoDados := '2.02'; VersaoAtrib := '2.02'; end; ConfigMsgDados.DadosCabecalho := GetCabecalho(''); end; Como você pode ver tanto o RPS quanto ao Lote de RPS devem ser assinados. O XML de envio de lote de RPS gerado ao usar o programa exemplo do componente ACBrNFSeX esta realizando as duas assinaturas. Não sei o que você fez na sua aplicação que o XML de envio de lote de RPS gerado por ela somente o RPS esta sendo assinado. Verifique: Você tem fontes do ACBr 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. Por fim repita os testes.

Olá pessoal. No dia 22/12/2023, foi publicado o ATO DECLARATÓRIO EXECUTIVO COFIS Nº 57, DE 20 DE DEZEMBRO DE 2023 cujo texto declara: Na página de download do novo manual, consta um aviso informando que não houve alteração de leiaute. O novo manual também pode ser encontrado AQUI. E como fica o ACBr? Conforme aviso do próprio Sped, não houve alteração no layout, portanto, não serão necessárias alterações no componente ACBrSPEDContabil.

Olá pessoal! No dia 20/12/2023 foi divulgada a Nota Técnica 2023/005 que institui o evento de Insucesso da Entrega para NF-e (não confundir com o Insucesso na entrega para o CT-e que é descrito AQUI) Resumo da Nota Técnica. Esta nota técnica discorre sobre os eventos de Insucesso de Entrega da NF-e(tpEvento=110192) e Cancelamento do Insucesso na Entrega da NF-e(tpEvento=110193), ambos acobertados pelo Ajuste SINIEF 58/2022 de 09 de dezembro de 2022. A implementação dos novos eventos permitem ao emissor da NF-e, quando a entrega da mercadoria não envolver um CT-e, registrar por meio de um evento fiscal na respectiva NF-e os motivos que impediram a entrega. O objetivo dessa implementação é substituir a ressalva que atualmente é aposta no verso do DANFe seguindo o § 3º da cláusula décima do Ajuste SINIEF 07/05 que obriga o emitente do documento fiscal a armazenar o DANFe impresso contendo no verso justificativa Insucesso da Entrega. Com a criação desses eventos, o emissor vai poder vincular o evento eletronicamente na NF-e e não mais precisará armazenar o DANFe em papel. Datas para Implantação. Implantação para Homologação: 13/05/2024. Implantação para Produção: 24/06/2024. Webservice de Evento e Obrigatoriedade. Assim como os demais eventos já existentes, os novos eventos de Insucesso na Entrega e Cancelamento do Insucesso na Entrega serão recepcionados pelo Ambiente Nacional e não pela Sefaz respectiva do estado. A implementação desta NT é facultativa, portanto, os interessados podem praticar os prazos que julgarem conveniente posterior as datas de implantação descritas nos respectivos ambientes. Evento "Insucesso na Entrega da NF-e". Função: Evento para indicar o insucesso na entrega da carga pelo emitente da NF-e. Autor do Evento: O autor do evento é o emissor da NF-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor da NF-e. Modelo: Nota Fiscal eletrônica – NF-e (modelo 55) Código do Tipo de Evento: 110192 (Este evento exige NF-e autorizada) Leiaute Mensagem Entrada Os campos que valem destaque no leiaute da mensagem de entrada são: tpEvento: Código do evento, 110192 - "Insucesso na Entrega da NF-e". nSeqEvento: Sequencial do evento para o mesmo tipo de evento, pode ter valores entre 1 a 99. Para informar um novo evento de "Insucesso na Entrega da NF-e" para uma mesma NF-e, o evento anterior deverá estar cancelado. dhTentativaEntrega: Data e hora da tentativa de entrega. nTentativa: Número da tentativa de entrega que não teve sucesso. tpMotivo: Motivo do Insucesso. Pode ter os valores 1 - Recebedor não encontrado, 2 - Recusa do recebedor, 3 - Endereço inexistente ou 4 - Outros. xJustMotivo: Justificativa do motivo do insucesso, usar somente se tpMotivo = 4. latGPS: Latitudade do ponto de entrega.. longGPS: Longitude do ponto de entrega. hashTentativaEntrega: Hash SHA-1, no formato Base64 correspondente a concatenação da chave de acesso da NF-e + Base64 de imagem capturada na tentativa da entrega. dhHashTentativaEntrega: Data e hora da geração do hash da tentativa de entrega. Leiaute da mensagem de retorno Os campos que valem destaque no leiaute da mensagem de retorno são: dhRegEvento: Data e hora de registro do evento. nProt: Número do protocolo do evento. Evento "Cancelamento Insucesso na Entrega da NF-e". Função: Evento para indicar o cancelamento do evento de insucesso na entrega da carga pelo emitente da NF-e. Autor do Evento: O autor do evento é o emissor da NF-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor da NF-e. Modelo: Nota Fiscal eletrônica – NF-e (modelo 55) Código do Tipo de Evento: 110193 (Este evento exige NF-e autorizada) Leiaute da mensagem de entrada Dentre os campos que vale destaque temos: nProtEvento: número do protocolo de autorização do evento de insucesso que será cancelado. Leiaute da mensagem de retorno dhRegEvento: Data e hora de registro do evento. nProt: Número do protocolo do evento. LEIA A NOTA TÉCNICA NA INTEGRA AQUI E como fica o ACBr? Como é possível observar, a nova NT trás adição de dois novos eventos. Dito isso modificações serão necessárias nos fontes do ACBr para implementação dos mesmos. Já foi criada uma TK em nosso backlog e as modificações estarão disponíveis em tempo hábil para que possam realizar a implementação.

só corrigir. a informação conforme a mensagem

Boa tarde Kaikson, Sim, quanto ao erro E232 vai ser necessário entrar em contato com a prefeitura para saber o motivo.

Seus Fontes parecem estar desatualizados, em relação o SVN atual... pela Documentação, existe sim o EndPoint para Refresh https://api-staging.shipay.com.br/docs.html#tag/Pedidos-para-Pagamentos-Instantaneos

o exemplo tem lá como fazer

Bom dia. Atualizei os fontes, e nessa versão o IM foi impresso.

Bom dia! A tarefa foi alocada para o sprint desta semana.

Bom dia Adriano, Já esta no SVN.

Bom dia! Contribuição enviada ao SVN na Rev-31704. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia @lizejr Quando vc fez o download do programa exemplo vc fez o download de todo conteudo demo harbour ou somente do exemplo que vc precisa? Ideal pegar a pasta toda pois o arquivo que vc esta precisando fica dentro da pasta \AcbrLib\Demos\HarbourComum. Talvez este link da comunidade especifica te ajude: http://www.pctoledo.com.br/forum/viewtopic.php?f=39&t=24682&p=160630&hilit=acbrlib#p160630

Olá boa tarde Alexandre tudo bem OkACBrMDFeDAEventoRL.pas

Boa noite comunidade, Como muitos acompanharam ao longo dos últimos meses, por mudanças nos WS utilizados pelos componentes ACBrConsultaCNPJ e ACBrConsultaCPF, e consequentemente o uso via ACBrLib e ACBrMonitorPlus, os mesmos não estavam funcionais. Após muita troca com a comunidade, assim como pesquisas da equipe ACBr chegou-se as conclusões a seguir. Sobre o componente ACBrConsultaCNPJ Foi feita adequação afim de implementar a comunicação com o BrasilAPI e também o ReceitaWS e ssa agora ter 3 novas propriedades visando a integração com os novos WS. Provedor (cwsNenhum, cwsBrasilAPI, cwsReceitaWS) Usuario Senha sendo assim, a partir desse momento o componente de consulta de CNPJ já é possível as buscas nos webservices da BrasilAPI ou ReceitaWS. Lembrando que não trata-se de base de dados oficiais da RFB e sim terceiras. Para utilizar é necessário selecionar o webservices desejado <ACBrConsultaCNPJ>.Provedor := Em relação ao ACBrLib e ACBrMonitorPlus, estão sendo feitas as modificações afim de também viabilizar seu uso, informaremos aqui assim que estiver liberado. Sobre o componente ACBrConsultaCPF Devido a não termos identificado outro serviço de webservice para realizar a migração do componente, foi preciso neste momento descontinuar o mesmo. Naturalmente que se no futuro houver uma nova opção de fonte de dados, o componente poderá ser reativado. At.

Boa noite, devido as desembaraços do componente, foi implementado 2 webservices. cwsBrasilAPI e cwsReceitaWS, ambos utilizam consulta REST e não usam captcha, basta configurar a propriedade provedor do componente. lembrando, que esses webservices são terceirizados, não oficial da RFB, podendo a informação estar defasada. commit 31653 (18/12/2023) válido para componente, sendo migrado para lib em breve.

Theiller, Já esta no SVN.

No TEF Pay&GO quem paga a mensalidade é o Cliente, a fatura do tef vai direto pra ele. Se voce for revenda de TEF (da Bematech, da Daruma, ou da própria NTK), o que voce pode fazer é um overprice e aí as revendas ganham a diferença descontado alguns impostos. É pouco mas o suporte fica na sua mão e não entra os abelhudos que só sabem culpar o teu software por que o cartão não passa forçando a venda do produto deles.