Painel de líderes

Olá pessoal, O Governo de Santa Catarina publicou o Ato Diat numero 044/2023 que pode ser lido na integra clicando aqui. Em resumo esse Ato Diat estabelece que Nota Fiscal Fatura de Serviços de Comunicação Eletrônica (NFCom) modelo 62 vai substituir a Nota Fiscal de Serviço de Comunicação, modelo 21, e à Nota Fiscal de Serviço de Telecomunicação, modelo 22. A NFCom será obrigatória a partir de 01/07/2024. Os prestadores de serviços emissores dos documentos fiscais citados acima poderão de forma voluntária solicitar o seu credenciamento durante o período de 01/12/2023 a 31/05/2024. A SEFAZ promoverá a partir de 01/06/2024 o credenciamento por oficio. O Projeto ACBr esta sempre atento as novidades trazidas pelo Fisco e já temos os Manuais: Visão Geral e Layout do XML que foram obtidos do Portal da SEFAZ Virtual do RS, neste link. Já se encontra na nossa lista de tarefas o desenvolvimento do componente ACBrNFCom. Assim que a SEFAZ divulgar as URLs de homologação bem como a data de liberação do ambiente de homologação, vamos iniciar o desenvolvimento do componente. E voltaremos a este tópico para deixar todos informados sobre esse novo componente.

Foi publicada a versão 23.1.F das tabelas de fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/05/2023 até 30/06/2023 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto" foi, não se esqueça de realizar a atualização de seus clientes. Fonte : https://deolhonoimposto.ibpt.org.br/

Boa tarde, durante a homologação do Banco Original usando o ACBrBoleto no meu ERP foram necessários dois ajustes: Mudar local de pagamento de acordo com homologação. Preencher Data Limite de desconto na remessa apenas se o campo DataDesconto for preenchida. Peço a gentileza de analisar as mudanças e se possível integrar ao repositório do ACBr. ACBrBancoOriginal.pas

Humm.. eu acho arriscado deixar transações pendentes por muito tempo... Elas sempre geram confusão e suporte, quando algo não é pago, ou concluído de forma apropriada... Fiz um vídeo sobre isso:

Certo.. Vou tentar conversar com eles a respeito.. Esse recurso de deixar a transação pendente até a finalização da NFCe se torna necessário nas transações com múltiplas formas de pagamento.. Exemplo: O usuário faz uma NFCe de 10,00.. Efetua um pagamento de 6,00 com TEF.. A NFCe vai ficar aberta aguardando o pagamento do saldo restante.. Se o usuário cancelar a NFCe nesse momento, a transação TEF pode ser desfeita, caso ainda não esteja confirmada, porém se estiver confirmada, terá que ser cancelada e o Cancelamento de uma transação no M-Sitef vai exigir que digite um monte de informações, com nsu, valor, etc... Isso o usuário não vai ter acesso, pois nem comprovante a transação tem ainda...

Segue em anexo correções feitas para retornar RespostaTEF.CodigoBandeiraPadrao MSitef e ElginIDH Sobre as Parcelas com retorno do vencimento "RespostaTEF.Parcelas[0].Vencimento" segundo o suporte ainda não retornam essa informação, somente a quantidade de parcelas "RespostaTEF.QtdParcelas" (aconselho abrir um suporte com a Software Express para mais informação sobre o retorno do campo) Ps: Encontrei mais uma inconsistência dentro do MSitef já abrir um novo chamado referente a loop de mensagem (segue video que enviei a eles para entender https://www.youtube.com/watch?v=x70pg58dx_c Att. Correcoes.zip

Ola. Bom dia. Retirando os acentos não gera mais a rejeição e gera o boleto Online tranquilo. Dai não precisa nem preencher o campo Titulo.DataLimitePagto, executando a function GerarMensagemPadraoDataLimitePagamento e registrando o boleto Online sem problemas. Obrigado pelo retorno.

Boa tarde, Fiz mais uns testes e foi necessário fazer mais uma alteração na Unit IPM.Provider foi necessário alterar a procedure "procedure TACBrNFSeProviderIPM.TratarRetornoCancelaNFSe" Como estava: NotaCompleta := (Pos('<nfse>', Response.ArquivoRetorno) > 0) Como ficou: NotaCompleta := (Pos('<nfse>', Response.ArquivoRetorno) > 0) and (ANota.NFSe.NfseSubstituida = ''); A alteração foi necessária pois caso fique como NotaCompleta ele tenta verificar se o ANodeArray está assigned causando erro. no seguinte trecho de código: if NotaCompleta then begin if not Assigned(ANodeArray) and (Response.Sucesso) then begin AErro := Response.Erros.New; AErro.Codigo := Cod203; AErro.Descricao := ACBrStr(Desc203); Exit; end; ...

Olá Pessoal, Abaixo temos informações sobre a convivência das versão 3.00 e 4.00 do CT-e, que vai até 31/01/2024. Colaboração do nosso amigo Alexandre Parabocz.

Nosso componente ACBrBoleto já faz parte do futuro dos boletos, o que significa que além das diversas alterações realizadas para a integração via web-service, agora também já está apto para a emissão dos chamados Boletos Híbridos, ou seja, aqueles que além do Código de Barra, também contam com um QRCode para pagamentos via PIX. Esta alteração vem de encontro a muitos pedidos que temos recebido para incluir o QRCode no boleto, porém vale ressaltar que o Banco do Brasil foi pioneiro em promover uma integração completa com o PIX por meio de sua API, fazendo com que sua aplicação receba a baixa do título junto com as informações de retorno do banco, diferente do que ocorre quando esta integração não existe, tornando este processo manual e passível de uma série de erros. Atualmente os Bancos que suportam este tipo de emissão de boleto híbrido e estão implementados no ACBr são os seguintes (clique no nome do banco para acessar o tópico com a explicação detalhada dele): CNAB - por transferência de arquivos: Santander Sicredi Itau Bradesco (CNAB400) API - on-line: BB Caixa Econômica PenseBem Sicredi V2 Sicoob Inter (veja particularidades para NossoNumeroCorrespondente) Santander Itau (necessita que o banco forneça outra credencial para endpoint PIX) Bradesco Banrisul Para entender melhor como implementar esta solução e modernizar ainda mais sua aplicação, veja este artigo em nossa Base de Conhecimento. Att.