Painel de líderes

Bom dia pessoal! Foi publicado hoje no site do e-Social notícia informando sobre a publicação da Nota de Documentação Evolutiva 01/2023. A mesma da publicidade aos leiautes da versão Simplificada 1.2 do e-Social, informando que os mesmos já podem ser considerados para integração. Liberação do ambiente de Produção Restrita(homologação): 18/09/2023 Liberação do ambiente de Produção: 20/11/2023 A notícia pode ser lida na íntegra AQUI. A NDE 01/2023 pode ser lida AQUI. Já foi incluído em nosso planejamento adequação do componente ACBreSocial(e consequentemente Monitor e Lib) para a nova versão.

Olá pessoal, É com grande satisfação que informamos que temos um novo PSP disponível para o componente ACBrPIXCD, o ACBrPIXPSPAilos! Com esse novo componente, todos agora têm acesso às funcionalidades da API Pix do Banco Ailos para a realização de recebimentos através do PIX. Gostaríamos de destacar a importante ajuda da comunidade através do usuário @MaagraowaR que enviou a contribuição nesse post aqui. Os aplicativos de demonstração (Delphi e Lazarus) ainda não estão atualizados mas assim que ficarem prontos atualizamos aqui mesmo! Mas isso não impede que você atualize os fontes, reinstale o componente e já comece a fazer os testes! Até o momento deste post, o PSP Ailos não possui ambiente sandbox (homologação), e nós do Projeto ACBr não possuímos credenciais de produção. Portanto, convidamos todos os usuários que possuem essas credenciais a atualizarem seus fontes e ajudarem-nos a testá-lo. Caso encontrem algum problema, dúvida e/ou sugestão, por favor reportem através do fórum ou discord. Agradecemos a todos usuários que fazem contribuições e esperamos que esse novo PSP seja útil para todos os desenvolvedores que utilizam o componente ACBrPIXCD em seus projetos. Caso esteja com dúvidas sobre como conseguir as credenciais desse, ou de outros PSPs, acesse esse post: Use a força, Leia os fontes!!!

Olá Pessoal, Foi publicada em 01/06/2023 a NT 2023.003 a qual tem por objetivo permitir que na emissão de NFC-e seja possível a utilização do CFOP 5949 com o CST 90 ou CSOSN 900 para casos específicos e a critério da UF. Conforme informações recebidas durante o dia de hoje, trata-se de uma solicitação da SEFAZ-RS, a qual viabiliza a informação de Recarga de Celular, Recebimento de Contas e outras transações de pagamento sejam registradas em NFCe sem gerar oneração ao contribuinte. Veja as duas regras que sofreram alteração por conta dessa NT. Sobre a Vigência 05/06/2023 em ambiente de Homologação 03/07/2023 em ambiente de Produção Sobre o Impacto nas Soluções ACBr Por ser uma alteração nas regras de validação na SEFAZ, não se faz necessário nenhuma alteração no Componente, Lib ou Monitor. Sobre o Impacto nas Aplicações Comerciais Podem ser necessárias adequações afim de atender a demanda da SEFAZ-RS.

Ótimos argumentos @Alexandre de Paula, muito obrigado pela sua opinião! Acho que vou usar campos separados mesmo, principalmente porque espaço hoje em dia não é mais um problema!

Bom dia, o Nosso Número ele é montado com 7 dígitos, se o ultimo digito é DV ele é descartado. mas atualmente com base nesses 7 dígitos você consegue o DV que está no titulo //LTitulo : TACBrTitulo; ACBrBoleto.Banco.CalcularDigitoVerificador(LTitulo);

Então... esse CST 061 é para operação com combustíveis... acredito que o seu produto (água de coco) não se enquadre nessa situação. Seria interessante confirmar com a contabilidade responsável qual o CST deve ser utilizado na operação.

Mas não seria uma boa prática enviar todos os dados? Se você enviar uma instrução de protesto não vai ser rejeitado a instrução por falta de dados? Como vão notificar o protesto sem os dados ?

O chat-gpt recomendou Converter de UTF8 para ANSI retirar o acentos e Converter novamente para UTF8. validei com o https://codebeautify.org/xmlvalidator Resolveu. O Problema realmente eram os acentos.

Boa tarde ! Seus fontes estão atualizados?

Bom dia, Obrigado a todos, principalmente ao Gerson Luiz Furtado, Pela explicação do passo a passo, me ajudo muito.

Olá @MaagraowaR, Acabei de enviar ao SVN o novo PSP Ailos. Se puder efetuar testes por favor para verificar se está tudo ok. Caso haja alguma credencial para ambiente de homologação que poderia ser passada para nós testarmos seria legal. ...alterações disponíveis na rev. 29660. -- ACBrPIXPSPAilos -- [+] Inclusão do novo PSP Ailos Por: MaagraowaR

Bom dia! A Sefaz de Pernambuco está com contingência agendada, com previsão de inicio no dia 04/06/2023 as 07:30 e término no dia 05/06/2023 as 10:00. Fonte: Consulta Situação SVC-RS Para transmitir em contingência usando o ACBr, siga as orientações do tópico a seguir:

Bom dia! A Sefaz de São Paulo está com contingência agendada para o dia 04/06/2023, com previsão de inicio as 06:00 e término as 19:00. Fonte: Portal da Nota Fiscal Eletrônica Para transmitir em contingência durante este período, siga as orientações do tópico a seguir:

Bom dia Diego. Claro, vou alterar e fazer testes de importação. Depois reposto o resultado.

Bom dia @rlind. Em primeiro lugar agradecemos a contribuição. Porém para um melhor controle e registro das alterações e de nossas atividades pedimos que você anexe o arquivo alterado aqui no fórum, ao invés de colocar o código sem indicar a posição que foi alterado, assim fica mais fácil de avaliar e analisar seus impactos. Obrigado!

Boa noite, Debugue os fontes para analisar o que está ou deveria estar sendo preenchido. ../trunk2/Fontes/ACBrBoleto/ACBrBancoSicredi.pas CalcularDigitoVerificador() GerarRegistroTransacao240()

Boa noite, Foram enviadas ao SVN as implementações no componente ACBrReinf referentes à versão 2.1.2 na Rev-29656. Lembramos que, até o momento desta notícia, a Receita ainda não havia ativado a nova versão para os testes na Produção Restrita. Foram feitas validações dos xmls gerados pelo componente, na versão 2.1.2, com os novos schemas disponibilizados e não foram encontradas inconsistências. Foi inserida uma trava/alerta na consulta de protocolo, caso o retorno ainda esteja trazendo a rejeição ( conforme destacado no posta anterior ) devido à versão não implementada na API. Quando o serviço estiver no ar esse alerta não será mais exibido no retorno da consulta.

Boa tarde! Você pode usar a LibBoleto MultiThread, usando o método Boleto_Inicializar para gerar um Handle para cada instância. Esse Handle deve ser passado como um parâmetro nos métodos da Lib. Mais informações a respeito em ACBrLib e MultiThread

Pessoal, achei o problema o Cod. Cedente é oque esta sendo enviado como Convenio no JSON no Banco do Brasil ! Como estava preenchendo o campo Convenio com as informações de Teste ocasionou o erro pois no banco do Brasil, essa informação no Demo deve ser preenchida no Cod.Cedente!

Boa tarde! Foi publicado no dia 02/06/2023 a versão 3.0.5 do Programa Validador da Escrituração Digital EFD ICMS IPI com as seguintes implementações: Fonte: http://sped.rfb.gov.br/pagina/show/7225

Iniciei testes para o CTe 4.0, e ao transmitir tive a rejeição abaixo: <?xml version="1.0" encoding="UTF-8"?> <retCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="4.00"> <tpAmb>2</tpAmb> <cUF>50</cUF> <verAplic>MS_0.0.126</verAplic> <cStat>649</cStat> <xMotivo>Rejeicao: CTe emitido em ambiente de homologacao com Razao Social do destinatario diferente de CTE EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xMotivo> </retCTe> Conferindo no anexo I do MOC4.0, realmente está diferente, sem o hífen no "CTE": No MOC da versão 3.0 já é com o hífen: Para conseguir prosseguir com os testes eu alterei a constante "xRazao" lá na unit "pcteConsts", deixando conforme o layout do 4.0 espera: Eu não fiz alteração para anexar aqui, pois nesse caso deve ser pensado em relação à versão 3.0, pois ela também deve ser mantida para compatibilidade. Então deve ser pensada uma maneira melhor para implementação, aqui nessa unit não há acesso à versão do componente que está sendo utilizada para chavear isso, então seria melhor criar outra constante, algo como "XRazao_3" e "xRazao_4"? Implementar direto na escrita do XML e conferir lá a versão?

XML do teu primeiro item: Fórmula: vICMSUFDest = ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) * pICMSInterPart Ficaria então no primeiro item:

Boa noite! Outro detalhe importante a observar são os textos/caracteres dentro de aspas ("caracteres"). Email.AdicionaPara("xxxxxxxx") Email.Assunto("xxxxxxxxx xxxxx xxx") Email.TextoMensagem("xxxxx xxxx xxxx") [...]

Segunda-feira no primeiro horario ja vou fazer os testes!!

pICMSInterPart não pode ser zerado, está é a condição para gerar o grupo. Condição está que está de acordo com o layout:

Mas você está passando o CST 061?

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Boa tarde! Não sei se entendi bem o problema, mas vamos lá. Você colocou no título do tópico "Erro 959". Se conferirmos na NT sobre a tributação monofásica, essa é uma rejeição texto é como segue: No corpo do texto, colocou: Meu entendimento é que você recebeu a rejeição 959 e achou que é porque foi informação de Tributação Monofásica no grupo do CST61 e que não deveria ir. Conferindo na mesma NT, podemos observar que o CST 61 é um dos Monofásicos. Então não é essa a questão. Acredito que você esteja enviando um valor de cProdANP que não está presente na tabela ou esteja usando o CST incorreto para este produto e por isso esteja recebendo está rejeição.

Ok. vou testar no exemplo do acbr

Pois é.. a função para não estar funcionando como deveria... e a documentação que recebemos não está ajudando muito...

Eu li, mas no campo pRedAdRem em especifico, não demonstram como deve ser calculado. Só explica que tem o campo, creio que devem fazer isto mais pra frente.

Uma retificação, no caso o "ExibeCampoDePagamento" não é o booleano, ele utiliza 3 paramêtros para selecionar. Define se exibe ou não os campos de pagamentos: 0 = eipNunca 1 = eipAdicionais 2 = eipQuadro Assim que testarmos em produção vou marcar solucionado.

Bom dia! Atualmente o ACBrGNRe não está preparado para gerar Guia com Múltiplos Documentos de Origem. Já estamos trabalhando para adequar o componente, fique de olho em nossa área de notícias para novidades a respeito.

Atualizei para a versão 1.4.0.175 e funcionou!

Muitissimo obrigado @Alexandre de Paula eu vou experimentar e assim que me certificar que deu certo marco como solução.

lembre-se que tu tem que configurar o componente com o provedor e cidade antes de carregar

segue o tópico sobre os bancos

@Douglas Conceição Após usar o componente, caso tenha algum outro banco que precise e não tenhamos implementado você pode nos ajudar muito! Toda contribuição é bem vinda! Sucesso aí nas implementações!

Parece que estão trabalhando nisso...

Sempre a resposta do sênior..... Depende.... Pessoalmente acho que você tem que avaliar o impacto da alteração no seu sistema. Se usar um campo já existente, o correto seria avaliar todas as rotinas que já usam o campo e verificar como ele seria tratado na parametrização (lembrando que talvez já vá fazer isso por outros motivos, não especificamente pelo campo). Usar o mesmo campo pode ser uma economia de espaço (será?), principalmente se vc tem certeza que as informações são excludentes, ou seja, NUNCA terá que usar as duas juntas. Se usar um campo novo específico para a operação pode implementar apenar onde ele será usado.. Eu prefiro campos separados, principalmente pelo fato de que muitas vezes quando fizer consultas na base de dados pode ser que não se lembre que o campo X tem função/valor diferentes para situação Y e Z. Espero ter ajudado mais que complicado!

Boa noite, Qual o município? Não são todos os provedores que retornam o XML da NFSe completo após a emissão. Veja no XML (*-lista-nfse*.xml) se constam as tags que você espera. Se não houverem, não tem o que fazer. Se houverem e o componente não esteja alimentando as respectivas propriedades, favor anexar ou enviar o XML para análise.

Boa noite, O IssNet utiliza o Leiaute ABRASF 2.04 para este município. Analise a função a seguir para verificar as propriedades preenchidas. TratarRetornoConsultaNFSeServicoPrestado() ../trunk2/Fontes/ACBrDFe/ACBrNFSeX/Base/Provedores/ACBrNFSeXProviderABRASFv2.pas

A mensagem padrão ela é gerada na propriedade DataLimitePagto

https://www.projetoacbr.com.br/forum/topic/59073-lançamento-da-acbrlib-com-suporte-a-multithread/ Aqui também tem uma notícia sobre o assunto. Como usuário PRO também tem acesso aos cursos do ACBr. Verifique o curso da Lib.

Boa tarde! Por favor, seus fontes estão atualizados? Conferindo nos fontes, o valor de NrOcorrCodigoPaisTomador já é zero tornando a tag opcional. Verifique se não está atribuindo um valor para a propriedade NFSe.Tomador.Endereco.CodigoPais

A seção infoPgto tem identificação de quantidade de repetição com 3 casas (1-999) No seu INI vc está informando [infoPgto01], substitua para [infoPgto001].

Olá, ACBrNFeDANFeRL1.ExibeCampoFatura := True; ACBrNFeDANFeRL1.ExibeCampoDePagamento := True; Acredito que seriam essas propriedades a alterar.

Será de grande valia que o PIX chegue a lib e ao monitor assim como NFSe chegou !!!!

Foram realizadas as atualizações nos fontes do SVN referentes a: Revisão 29575: Leitura dos INI dos eventos S2416, S2418, S2500, S2501, S3000 e S3500 Revisões 29576 e 29577: Documentação com exemplos de arquivos INI dos modelos acima para ACBrLib e ACBrMonitor. Portanto nas ultimas versões disponíveis da ACBrLibeSocial e do ACBrMonitor já é possível trabalhar com esses eventos! Atualize seus arquivos e faça os testes antes de julho/2023 para não ter surpresas de última hora!

Bom dia! Os dados de veiculo e condutores, é obrigatório estar correto APENAS , no MDFE, CT-e foi descontinuado na versão 3.0 os dados de motorista e condutor, então se for apenas pro seu cliente, sugira uma carta de correção alterando a OBS (que deve ter sido la que foi informado..) Sobre o contrato/ciot, esse sim precisa estar correto, pra evitar problemas com antt.

Como essas orientações são sobre o componente ACBrNFSeX, as mesmas também se aplicam para a LibNFSe e posteriormente o ACBrMonitor já que ambos fazem uso do mesmo. Nome da cidade não está associado a nenhum provedor. O por quê da mensagem. Atualmente o ACBrNFSeX atende mais de 1260 cidades com mais de 140 provedores implementados, apesar disso, o Brasil é vasto, contando com 5565 municípios, por causa disso é inevitável que alguma cidade acabe escapando do nosso radar, por isso, se o componente não tiver a informação de integração de uma cidade, será devolvida a mensagem "<NomeCidade> não está associado a nenhum provedor. O que você deve fazer. Veja este tópico em nossa Base de Conhecimento para saber como descobrir se a cidade é aceita pelo componente. Caso precise usar uma cidade que não esteja implementada, o primeiro passo é buscar as informações para poder integrar com o serviço de emissão de NFSe via WebService daquela cidade. Um bom lugar para começar a buscar esta informação é no site da prefeitura e no setor de ISS da mesma. De posse destas informações, você pode criar um tópico no fórum para que a integração possa posteriormente ser adicionada ao componente. Nenhum provedor selecionado. O por quê da mensagem. O ACBrNFSeX foi concebido de forma inteligente, fazendo uso de interfaces. Desta forma, cada provedor pode ter sua própria implementação sem interferir umas com as outras, seguindo a implementação dos métodos da Interface. Isso também quer dizer que a implementação dos métodos em si é feita nas classes do provedor e quando o mesmo não for selecionado será devolvida a mensagem "Nenhum provedor selecionado". O que você deve fazer. O componente define qual é o provedor internamente de acordo com a cidade selecionada, por isso, antes de realizar qualquer operação com o ACBrNFSeX, você deve configurar a cidade do emitente. Não informado a URL de Homologação. O por quê da mensagem. A informação da cidade, provedor que a atende, versão e URL do WebService para todos os municípios que são usados pelo ACBrNFSeX se encontram no arquivo ACBrNFSeXServicos.ini(Para mais informações sobre o arquivo ACBrNFSeXServicos.ini e o que significa cada parâmetro nele, por favor leia nosso Manual de Migração para o ACBrNFSeX). Esta mensagem é exibida quando não tem a informação da URL de homologação para a cidade que está usando. O que você deve fazer. O fato de não ter está informação no arquivo INI é um indício de duas possíveis situações. Quanto foi feita a contribuição com a informação da cidade, não foi passada a informação, por isso não dispomos da mesma. Não tem ambiente de homologação para esta cidade e o teste precisa ser feito em produção. Para ambos os casos, é recomendado entrar em contato com a prefeitura ou o provedor para pedir uma confirmação. Serviço não implementado para este provedor. O por quê da mensagem. Infelizmente, não existe uma padrão estabelecido para NFSe, o mais próximo disso seria o Padrão ABRASF, que apesar de ser chamado de "padrão" é na verdade uma recomendação de como implementar o WebService que pode ou não ser seguida pelos provedores. Dessa forma temos provedores que implementam leiaute próprio e até mesmo aqueles que seguem o padrão ABRASF, podem implementar customizações ou deixar de implementar métodos. Por isso, se você recebeu a mensagem Serviço não implementado para este provedor, significa que está tentando usar um método que não foi implementado por ele. O que você deve fazer. De maneira geral, podemos agrupar o uso da NFSe em três categorias, Emissão, Consulta e Cancelamento/Substituição. Se você tentou usar uma das formas de emissão(síncrona ou assíncrona) e recebeu está mensagem, isso indica que o provedor não implementa a forma como está usando e por isso deve utilizar a outra. Uma dica é deixar o modo de envio automático para que o componente escolha. Caso tenha tentado uma consulta e recebido está mensagem, indica que a mesma não foi implementada pelo provedor e deve optar por alguma outra das consultas disponíveis. Se o cancelamento/substiuição lhe devolver esta mensagem, entre em contato com a prefeitura para confirmar se a mesma permite realizar tal processo via WebService já que em alguns municípios, parte do processo de cancelamento/substituição requer análise de um fiscal. Lista de NFSe não encontrada! (ListaNfse) O por quê da mensagem. Nos casos em que transmite um RPS, mas recebe rejeições no retorno esta é uma das mensagens que vai visualizar. Ela ocorre porque o ACBrNFSeX espera receber dentro da estrutura do retorno uma tag ListaNfse que contém o conteúdo da NFSe em si. Quando o WebService devolve rejeições, ele não devolve esta tag. O que você deve fazer. Quando a transmissão do RPS ocorre sem rejeições e a NFSe é devolvida está mensagem não aparece, portanto, basta resolver as outras rejeições que foram devolvidas pelo WebService. WebService retornou um XML vazio. O por quê da mensagem. Está mensagem é mostrada quando a resposta do WebService a requisição vem vazia. O que você deve fazer. Existe a possibilidade de que o WebService esteja devolvendo uma resposta que não esteja no padrão esperado para ele e por isso o componente não consiga interpretar. Marque a opção para Salvar os Envelopes Soap. Se você usa componente a propriedade é: ACBrNFSeX.Configuracoes.WebServices.Salvar := True; Se você usa Lib é a configuração SalvarWS na seção NFSe das configurações. Ao fazer isso, será salvo para você um arquivo com a resposta devolvida pelo WebService antes de o ACBrNFSeX tentar fazer sua leitura. Verifique o conteúdo deste arquivo e caso o mesmo esteja vazio ou nem ao menos seja gerado, é necessário entrar em contato com o provedor para verificar. Caso haja informação, crie um tópico no fórum anexando os arquivos de envelope para que a equipe ACBr possa analisar se a rotina de leitura do componente deve ser alterada para que leia o conteúdo do retorno.