Painel de líderes

@Diego Foliene só agora que me apareceu o passo a passo que voce postou. vou segui-lo e retorno

Bom dia, Criada a TK-4290 para avaliação! Obrigado pela contribuição!

Bom dia Diego, obrigado, acredito que irá ajudar vários assinantes do ACBR.

Bom dia, Vou pegar as credenciais do cliente para começar os testes. Obrigado Julioomar e Daniel.

Boa noite @Microsys Sistemas Não desenvolvo na sua linguagem, mas aqui tem alguns videos que possa te ajudar. Não é sobre ACBRLibETQ, mas da p vc abstrair com exemplo SAT (é uma sugestão apenas) Como vc é usuario pró, tem acesso a todos os nossos cursos. https://acbr.nutror.com/curso/e4f38b5c7398e4ccca8731c2d305952d389ac693 Outro é Dominando ACBrLibNFe em java, acredito que possa te ajudar muito https://acbr.nutror.com/curso/59fa9f9962ed0e88ca5d25ffe138c121dc5b88e7

Nas últimas semanas foi publicada a versão 2.1.2 do layout do REINF, a qual trouxe ajustes para os eventos R4010, R4020, R4040, R9001, R9005 e R9011. Resumo das Mudanças R4010 e R4020 Campo ideEvtAdic teve a exclusão da regra de validação onde era permitido somente se o campo cpfBenef fosse informado Campo percSCP teve a validação alterada para exigir a informação se além do campo indFciScp for igual a 2, o campo natRend for 12001 R9001 Excluído o campo cnpjAssocDesp da coluna "Chave" em Resumo de Registros. Ajustada a ocorrência para 0-1 quanto ao campo cnpjAssocDesp Incluído campo nmEmprExt para informar nome da empresa que repassou recurso e não é sujeita a inscrição no CNPJ por estar domiciliada no exterior. Ajuste na informação esperada no campo vlrTotalRep onde a origem deve ser a seguinte: R2030 (campo vlrTotalRec) e R2040 (campo vlrTotalRep) R9005 Ajuste na informação esperada no campo vlrCRDecInf onde a origem deve ser a seguinte: R4010 (campo vlrIR), R4020 (campo vlrIR) e R4040 (campo vlrIR) Ajuste na informação esperada no campo vlrCRDecSusoInf onde a origem deve ser a seguinte: R4010 - Soma de vlrNRetido, vlrDepjud, vlrCmpAnoCal e vlrCmpAnoAnt, R4020 - Soma de vlrNIR e vlrDepIR e R4040 -Soma de vlrNIR e vlrDepIR As alterações mais detalhadas podem ser vistas na página do SPED. Sobre os prazos A versão 2.1.2 do REINF será exigida somente a partir das competências de setembro/2023, ou seja, partir de 21/09/2023. Dado o fato que nesta data já estava previsto em produção a versão 2.1.1, entendemos que a versão 2.1.2 apenas substitui a anterior. Na data desta publicação estamos confirmando se apesar das exigência ser somente para setembro, quem desejar já pode enviar neste layout, fiquem atentos ao tópico para novidades. Sobre as Mudanças no ACBr Como foram incluídos campos e também feitos ajustes nos valores esperados, naturalmente se faz necessário adequar também o componente, oque automaticamente se refletirá no ACBrMonitorPlus. Assim que os ajustes forem feitos divulgaremos aqui. Fonte http://sped.rfb.gov.br/pagina/show/7194 http://normas.receita.fazenda.gov.br/sijut2consulta/link.action?idAto=129523

Boa tarde! Estou disponibilizando ajuste de novos Tipo de Contrato para o Evento S2500 que constam no leiaute da versão 1.2 do eSocial. Obrigado Anderson pcesConversaoeSocial.pas

Boa tarde! Enviei ao SVN na Rev-30261 alterações visando resolver o problema. Por favor, queira atualizar, testar e reportar qualquer problema.

@rpaulogio Boa tarde ! No Keyuser utilizar o conteudo gerado no Workspace conforme manual. (confere se o workspace criado foi este: "cf254108-0a8c-4e55-b912-6f881758a871" ) Ao invés de usar o arquivo PFX do cliente. use somente os 2 arquivos CRT, KEY Pq se vc utilizar somente o pfx no postman ele vai funcionar. Entao para simular como no componente, nao informe o PFX Caso precise exportar novas keys, utilize:

Boa tarde, Todo ambiente é homologação/sandbox? R: Sim Vc disse que está com o certificado do cliente, as credenciais são cadastradas tbm no nome do cliente? R: Foram geradas usando o certificado do cliente O certificado é A1? R: Sim A senha está correta? R: Sim O terminal / prompt de comando executando como administrador? R: Sim Obs: Usando os arquivos .crt e .key no postman eu consigo gerar o token:

Sim, e acabei de descobrir o que está acontecendo!!!! Rodando a IDE como administrador, os componentes ACBr aparecem. Rodando com meu usuário local, dá o erro abaixo e não aparece nenhum componente! Há alguma maneira de instalar para o usuário local?

Estou organizando meu tempo para poder ajudar. Obrigado pelo feedback Abraço

Incoerente... Se ele não reconheceu a sua IDE não tem nada relacionado aos recursos android ou OSX. Não é usado isso para reconhecer IDE.

Boa tarde! Muito obrigado pela contribuição! Criada #TK-4293 para análise e posterior inclusão no SVN.

O que você fez?

Ajuste SINIEF 07/05 https://www.confaz.fazenda.gov.br/legislacao/ajustes/2005/AJ007_05 Cláusula terceira A NF-e deverá ser emitida com base em leiaute estabelecido no MOC, por meio de software desenvolvido ou adquirido pelo contribuinte, observadas as seguintes formalidades: II - a numeração da NF-e será seqüencial de 1 a 999.999.999, por estabelecimento e por série, devendo ser reiniciada quando atingido esse limite;

Anexa o log do instalador assim já podemos dizer o problema

isso é orientação a objeto, encapsulamento, reutilização de código. então sim ele vai trabalhar com as heranças que existem

Boa tarde, Já esta no SVN.

Eu solicitei ao cliente, assim que ele mandar eu aviso.

Também abri um chamado no Fórum do BB informando sobre essa divergência, aparentemente eles irão corrigir: forum.developers.bb.com.br/t/resultcode-incorreto-ao-solicitar-uma-devolucao

Ótimo! que bom que deu certo!!! Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia! Muito obrigado pela contribuição, foi criada a #TK-4289 para análise e posterior envio ao SVN.

Olá Itallo, Alterei o processo e deu certo. Fiz a consulta carregando o XML sem protocolo e obtive o XML posteriormente completo. Obrigado @Italo Giurizzato Junior e @Alexandre de Paula!

Bom dia Milton, Primeiramente, se ocorre algum erro de internet, já mais devemos enviar novamente a nota, pelo simples fato de não sabermos em que momento ocorreu o erro. Uma vez que esse erro pode ter ocorrido no envio ou no retorno. A lógica é bem simples, ocorreu erro de internet, carrega o componente com o XML da nota e execute o método Consultar. Se o erro ocorreu no retorno teremos como resposta o resultado do processamento da nota que pode ser autorizada ou rejeitada. Se retornar autorizada, automaticamente o XML vai ser atualizado com o protocolo de autorização, passo seguinte é imprimir o DANFE. Se retornar rejeitada, ai devemos fazer as devidas correções e enviar a nota novamente. Agora se o erro ocorreu no envio, ao realizar a consulta teremos a rejeição: 217 - NF-e não consta na base de dados da SEFAZ. Com essa rejeição temos a certeza que a nota não consta na SEFAZ e que o erro ocorreu no envio, o passo seguinte é enviar novamente. Desta forma você não vai ter mais a rejeição de nota em duplicidade. Detalhe importante: O procedimento acima pode ser adotado por quem usa o Componente ou a Lib ou o Monitor.

Eduardo, Tenho um cenário que estou precisando de ajuda. Nossos clientes tem um esquema de pagamento "antecipado" que chamamos de cartão cashless. Onde os clientes do bar/evento incluem um saldo neste cartão (ou sejam pagam neste momento) e no decorrer da noite eles vão consumindo os produtos e debitando o saldo de cartão. Exemplo: Colocam um valor de R$500,00 e vão consumindo. Como devemos proceder neste caso, emitimos nfc-e ao colocar saldo no cartão ou apenas no ato de solicitar o produto para o consumo? Atualmente colocamos ao pedir o produto, mas ai como ficaria a forma de pagamento, devemos enviar como "cartão loja"? Lembrando que ao colocar o saldo no cartão ele pode ter usado, pix, dinheiro ou cartão de débito/crédito.

Olá @Alexandre de Paula, agradeço o retorno. Essa preocupação é somente com a NFC-e. O processo da contingência é feito sim de forma off-line, se uma NFC-e é enviada e o servidor da SEFAZ está indisponível ele envia essa nota para o limbo (Inutilização ou Cancelamento por substituição) e emite a mesma nota em contingência e mantêm o sistema no modo contingencia off-line por 20 minutos, logo todas as notas nesse intervalo serão emitidas em modo contingencia off-line e o processo se repete dessa forma, esse processo está claro e funciona bem. O problema não está na emissão, está em algumas situações na autorização posterior: O sistema automaticamente com intervalo de 15 minutos verifica se existe alguma NFC-e em contingência, se houver ele envia para autorização, se é retornado um erro, o processo é parado e retornado 15 minutos depois. O que acontece é que às vezes, principalmente após um grande período de indisponibilidade da SEFAZ, quando o servidor volta ele parece ficar sobrecarregado, então quando a NFC-e é enviada para autorização o sistema não recebe retorno, porém ela foi autorizada. Como o sistema parou de enviar, como dito acima, depois dos 15 minutos ele tenta enviar novamente e é retornado um erro de duplicidade, pois a autorização, apesar de não ter sido recebida como resposta, foi realizada. Com o ACBR Plus essa nota era consultada e na consulta o XML completo era retornado, pela LIB o XML completo não é retornado, então gostaria de uma sugestão de uma maneira de "completar" o XML com o protocolo de autorização.

A SEFAZ MG valida a combinação série, número e ano. Há outros relatos semelhantes aqui no fórum.

A sugestão atual no RS é o uso de cupom com o CFP 5949. No tópico abaixo tem toda uma discussão sobre o assunto.

Correção enviada ao SVN, rev: 30252 -- ACBrPIXPSPBancoDoBrasil -- [*] Alteração do ResultCode recebido ao solicitar uma devolução de Pix (Método PUT ao endpoint /pix) Muito obrigado por reportar @Ábacus TI

Se eu não me engano uma das das chaves da nota é o código da nota, no caso o código é diferente. Já aconteceu esta mesma situação comigo em 2015 ou 2016 e na época o contador fez uma denúncia espontânea. Mesmo sendo erro da receita por aceitar, eles deram uma multa de R$18.000,00 para o meu cliente. Veja com seu contador para ele fazer a denúncia espontânea e esperar.

Eu creio que deveria emitir a NFCe no momento que ele compra o produto e não no momento que ele paga pelo cartão, até por que a NFCe é para venda de produtos ao consumidor final e quando ele paga o cartão, ele não está consumindo o produto. Agora se há alguma brecha na legislação que permite emitir NFCe da compra de créditos e não do produto, ai é um caso a ser visto.

Obrigado mais uma vez pela contribuição. O ambiente de "produção restrita" como eles chamam a homologação, está previsto para 18/09/2023. Assim que as atualizaçõe estiverem disponíveis no SVN informamos aqui.

Bom dia! Estou enviando como sugestão de alteração, uma versão atualizada do Eventos S-2500, no ambiente 1.2 do eSocial. Onde foram feitos ajustes e criado objetos. Foram feitos ajustes nos arquivos de configuração do ACBR para que seja possível selecionar o ambiente na versão 1.2 e os schemas. Agora estamos aguardando a liberação do ambiente no eSocial para testes. Obrigado Anderson pcesConversaoeSocial.pas pcesS2500.pas ACBreSocialConfiguracoes.pasv_S_01_02_00.zip

Nós aqui trabalhamos com um cartão de cantina escolar neste formato. Realizamos a recarga e emitimos apenas um comprovante não-fiscal. No momento da compra dos produtos pelo cliente, emitimos a NFCe com a forma de pagamento "Cartão Loja". Abs. Gilson S.

No caso a recarga desse tipo de cartão não está condicionado a produtos. ou sim? se sim tem que lançar com o produto em questão senão é passar somente ao final enão pode ser outros tem que ser cartão

há tá. use o componente ACBrNFSeX ele funciona

Sim está ocorrendo sim lá. tem que verificar com eles. não tem o que nós fazer. tem que olhar o que pode ser que esteja ocorrendo

Boa tarde, Complementando:

Boa tarde! A versão mínima necessária é a 10.3.3

Boa tarde! Foi enviado ao SVN na Rev-30250 alterações visando sanar esta questão. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde, Foi publicada nova documentação do Reinf, conforme avisado pelo colega@Edson Costa. Esquemas XSD R-4010, R-4020, R-9011 e R-9015 da versão 2.1.2 da EFD-Reinf republicados Manual de Orientação ao Desenvolvedor da EFD-Reinf – Versão 2.3 Acompanhem este tópico, pois assim que os devidos ajustes forem implementados e enviados ao SVN, será reportado aqui.

Bom dia! Conferindo nos arquivos que disponibilizou, você informou 5 campos extras. No entanto, apesar de permitir mais de uma ocorrência, o limite de acordo com os schemas é de 3.

Boa tarde, Criada a TK-4267 para avaliação. Obrigado pela contribuição.

Boa tarde, Criada a TK-4266 para verificação. Obrigado

Boa tarde, Criada a TK-4261 para avaliação. Obrigado

Bom dia, Criada a TK-4258 para avaliação. Obrigado!

Bom dia Lindomar, Já fiz as devidas correções na geração do arquivo INI no componente. Agora é preciso aguardar o pessoal liberar uma nova versão da Lib.

Bom dia. Informe 101 em Modalidade dentro da chave Cedente. Att.

Boa tarde Walter, A partir da versão 4.00 do CT-e não existe mais o serviço para inutilizar numero ou faixa de números. Estive em São Paulo mês passado em uma reunião com o Fisco e essa questão foi exposta, mas o Fisco não deu uma resposta de como proceder. Estamos aguardando alguma Nota Técnica contendo o procedimento a ser adotado pelas empresas.