Painel de líderes

Enviamos um commit para ajuste da propriedade - Revision: 28954 Logo será compilada uma nova versão e em breve disponível para download.

Olá pessoal, Lá vamos nós mais uma vez, só que agora é a vez de algumas melhorias no CT-e. E quais são as novidades da versão 4.00 do CT-e? Eliminação do SOAP Header dos Webservices Não precisamos se preocupar pois o componente vai se encarregar de não gerar o grupo <Header> ao montar o Envelope a ser enviado para o WebService da SEFAZ. Eliminação da Denegação e do CTe de Anulação Com essa nova versão não teremos mais como emitir um CT-e de Anulação, somente CT-e Normal, CT-e Complementar e CT-e de Substituição. O Manual não diz o porque, mas acredito que essa alteração vem de encontro com o DC-e (Declaração de Conteúdo Eletrônico). Quanto a Denegação o que tudo indica nenhum CT-e vai ser Denegado, ou seja, ou ele vai ser autorizado ou rejeitado. Eliminação do Serviço de Autorização Assíncrono O envio do CT-e passa a ser no modo síncrono e unitário, ou seja, somente um CT-e por vez será enviado para o WebService e já teremos como resposta o protocolo de autorização ou a rejeição. Ampliação do Nro Seq dos Eventos Antes um tipo de evento que poderia ser enviado mais de uma vez (por exemplo Carta de Correção) estava limitado a 20, agora o limite é 999. Eliminação do serviço de inutilização Com a versão 4.00 não teremos mais como inutilizar um numero de um CT-e que não foi enviado para a SEFAZ, acredito que caso ocorra um pulo, por exemplo, foi enviado o CT-e de numero 500 e por algum problema foi enviado o CT-e de numero 505, vai ser possível em seguida enviar os CT-e de números 501, 502, 503 e 504 para depois voltar a sequencia normal ou seja emitir o CT-e de numero 506 em diante. Sobre os prazos A versão 4.00 vai estar disponível a partir de 04/2023 em ambiente de Homologação e a partir de 06/2023 em Produção. Quanto as Soluções ACBr Haverão ajustes no componente ACBrCTe para atender a versão 4.00, oque naturalmente se refletirá nas versões posteriores da ACBrLibCTe e do ACBrMonitor. Fiquem atentos as atualizações dos fontes do ACBr e não percam o bonde. Quanto a minha Aplicação? Com certeza a sua aplicação deve ter uma opção para emitir CT-e de Anulação e Inutilização de Números, pois bem essas opção não poderão mais poder ser utilizadas com a nova versão. Sugerimos que apresente uma mensagem ao usuário informando que essa opção não esta mais disponível na versão 4.00 do CT-e. Se a sua aplicação permitia o envio de um lote de CT-e, agora só será possível enviar um de cada vez, logo você vai ter que mudar isso. Com certeza a sua aplicação envia eventos, fique atento a esta questão: para os tipos de eventos que permite enviar mais do que 1 para o mesmo CT-e, lembre-se que agora o limite passou de 20 para 999. Leitura recomendada: Temos os manuais (que são 3) da versão 4.00 em nossas biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/

Boa tarde. Como muitos sabem, a falta de padronização é uma questão que assola a Nota Fiscal de Serviço Eletrônica. Um exemplo disso é o provedor ISSGoiania que é utilizado pela prefeitura de Goiania/GO. Conforme explicado na documentação do provedor disponível aqui: Ou seja, a tag CodigoMunicipio no XML da NFSe para esse provedor vem com um código próprio. No que diz respeito ao envio. Para aqueles que utilizam o ACBrNFSeX (Componente, Lib, Monitor), é importante observar que a Prefeitura de Goiânia espera que a aplicação já informe esse código no campo CodigoMunicipio para sua utilização adequada. Portanto é importante se atentar a esta informação no momento de realizar o preenchimento para emissão da nota. No que diz respeito a leitura do retorno. Como o componente ACBrNFSeX espera receber na tag CodigoMunicipio um código IBGE, a função de conversão que busca o nome da cidade através do código, falha e por isso a informação do município fica em branco na impressão. Para resolver essa questão, foi criada na unit ISSGoiania.LerXML uma função que usa o arquivo disponibilizado pelo provedor para buscar a informação da cidade. (Disponibilizada na Rev-28957) Portanto, basta adicionar o arquivo CidadesISSGoiania.txt(o nome do arquivo deve ser este) dentro da pasta do seu executável para que a busca pelo nome da cidade passe a usar o arquivo e não fique mais em branco no impresso.

Boa tarde Pessoal, Segundo a Nota Técnica inicia hoje (03/04/2023) em ambiente de produção a alteração no layout da nota que agora passa a ter a opção de referenciar a chave de uma nota mas de forma sigilosa. As alterações foram enviadas para o SVN no dia 27/01/2023 conforme consta no Change Log do componente. 27/01/2023 -- Diversos -- [*] Alterações visando atender a NT 2022/003 onde foi alterado a quantidade de ocorrências de 500 para 999 do grupo NFref e a inclusão da tag refNFeSig que poderá conter a chave da nota referenciada, mas com o código numérico zerado. Observação: Essas alterações só vão ser validadas no ambiente de homologação a partir de 07/02/2023 e no de produção: 03/04/2023. por: Italo Giurizzato Junior Quem ainda não atualizou os fontes, favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e façam os testes.

Ola;

Boa tarde. Fonte: https://www.gov.br/esocial/pt-br/noticias/prorrogada-a-entrada-em-producao-dos-eventos-de-processo-trabalhista-1

Olá pessoal, novo componente na área. O ACBrSIN foi feito para se comunicar com sinalizadores ou sinaleiras de Self-Checkout. Ele foi contribuído pelo colega @Warquia Pereira, no seguinte tópico: Nesse tópico tem até um vídeo de algo que pode se fazer num Self-Chekout. Valeu Warquia! A princípio está implementado a comunicação com a marca Laurenti. Mas facilmente pode ser feito para outras marcas e modelos já que a comunicação é serial. Fiquem a vontade para usar o fórum para feedbacks ou quem sabe até continuar ajudando no desenvolvimento. Bom trabalho por aí!

O Comitê Gestor do Simples Nacional (CGSN) decidiu prorrogar para 1º de setembro de 2023 o início do prazo da obrigatoriedade da emissão da Nota Fiscal de Serviços eletrônica (NFS-e) que estava prevista para o próximo dia 3 de abril. Segue abaixo link com a informação completa: https://www.gov.br/receitafederal/pt-br/assuntos/noticias/2023/marco/comite-gestor-do-simples-nacional-prorroga-inicio-da-obrigacao-da-emissao-da-nfs-e-para-microempreendedores-individuais Agradecemos ao @Arimateia Jr pela contribuição com a informação!

Alo pessoal, é com muito orgulho que trago o primeiro esboço do exemplo de Flutter com ACBrLIB NFE! billbarsch/flutteracbrlib: Exemplo de uso das DLL's do projeto ACBR no Flutter (github.com) Todas as funções da dll de NFE foram implementadas, ainda nao testei tudo mas ja é 99% do caminho andado! Acredito que em breve com ajuda de outros possamos ter aplicações flutter emitindo notas, conectando com balanças, abrindo gavetas registradoras, o céu é o limite! Meus agradecimentos ao ACBr pelo magnífico trabalho sempre. Agora vou testar emissao, leitura de certificados etc e os proximos passos serão rodar no linux e talvez porque nao android??? e implementar mais dll's do projeto

Boa tarde. Foi divulgado no dia 24/03/2023 a NT2023/002 tratando do detalhamento do evento de insucesso na entrega. Resumo da Nota Técnica. Esta Nota Técnica disponibiliza novos eventos de Insucesso da Entrega e seu cancelamento conforme disposto no Ajuste SINIEF 50/2022 de 09 de dezembro de 2022. IMPORTANTE: Os novos eventos serão disponibilizados somente para a versão 4.00 do CTe. Data para Implantação Implantação para Homologação: 05/2023. Implantação para Produção: 07/2023. Evento de Insucesso na Entrega do CTe. Evento EXCLUSIVO da Versão 4.00 do CTe Função: Evento para indicar o insucesso na entrega da carga pelo transportador. Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe. Modelo: CT-e de Transporte de Cargas (modelo 57) Código do Tipo de Evento: 110190 (Este evento exige CT-e autorizado). Schema XML: evIECTe_v9.99.xsd Final do processamento Se o evento de Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat = 135. Este evento futuramente será propagado nas notas fiscais eletrônicas relacionadas de forma automática. Evento de Cancelamento do Insucesso na Entrega do CTe. Evento EXCLUSIVO da Versão 4.00 do CTe Função: Evento para indicar o cancelamento de um evento de insucesso da entrega da carga pelo transportador nas ocasiões em que ocorrer erro na geração do evento. Autor do Evento: O autor do evento é o emissor do CT-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CT-e. Modelo: CT-e de Transporte de Cargas (modelo 57) Código do Tipo de Evento: 110181 (Este evento exige CT-e autorizado) Schema XML: evCancIECTe_v9.99.xsd Final do Processamento Se o evento de Cancelamento do Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat=135. Este evento futuramente será propagado nas notas fiscais eletrônicas informadas no evento Insucesso de Entrega cancelado. Alterações no ACBr. Visto que se trata da criação de um novo evento, será necessário realizar a implementação do mesmo nos fontes, disponibilizando tais alterações dentro do prazo estipulado pela NT. Consequentemente, nova versão do ACBrMonitorPLUS e da Lib deverão ser geradas. Essa e outras Notas Técnicas disponíveis AQUI. Você pode ler esta Nota Técnica na íntegra AQUI.

Boa tarde. Foi divulgado no dia 24/03/2023 a NT2023/001 tratando de alterações de regras de validação para CTe, CTeOS e GTVe. Resumo da Nota Técnica: Esta Nota Técnica promove ajustes nas regras de validação do CTe, CTeOS e GTVe visando adequar o sistema à legislação aprovada no AJUSTE SINIEF. Data para Implantação: Implantação Homologação: 04/2023 Implantação Produção: 06/2023 Sobre as alterações: Eliminação da Denegação Interestadual As hipóteses da Denegação no processo de autorização dos documentos deixam de existir. A validação do CTe poderá resultar em: Rejeição – o CTe será descartado, não sendo armazenada no Banco de Dados podendo ser corrigido e novamente transmitido; Autorização de uso – o CTe será armazenado no Banco de Dados; Regras de Validação de CTe, CTeOS e GTVe No geral, a redação da NT remove das regras G036, G068, G074, G096 e N064 a palavra denegado. Além disso, adiciona a seguinte observação na regra G110: E também remove as regras abaixo: Regras de Validação G133, N089 e Q026: cStat - 301/ cStat - 205. Emitente em situação irregular perante o Fisco (tratar duplicidade na inserção do CT-e, evitando a inserção de mais de um CT-e denegado). Uso Denegado: Irregularidade fiscal do emitente. Regra de Validação G183 e N106: cStat - 205. - Verificar se CT-e está denegado Retornar Protocolo e data de denegação. [nProt:999999999999999][dhDeneg: AAAA-MMDDTHH:MM:SS TZD]. Rejeição: CT-e está denegado na base de dados da SEFAZ. Eliminar o Serviço de Inutilização O Webservice de Inutilização deixa de existir nas datas de implantação desta NT conforme o ambiente. O acesso ao Serviço será bloqueado pela SEFAZ Autorizadora, podendo retornar um erro http 404 (Not found) ou a rejeição 998 – Serviço Desativado. Revogação dos Eventos de Marcação Os seguintes eventos de marcação deixam de ser gerados pelas SEFAZ Autorizadoras: 440130| 57| Autorizado Redespacho 440140| 57| Autorizado Redespacho intermediário 440150| 57| Autorizado Subcontratação 240150| 57 e 67| CTe de Anulação CTe de Anulação e Substituição na Versão 3.00 O CTe com tipo anulação e substituição deixam de existir na versão 3.00. A nova sistemática de substituição passa a ser possível apenas na versão 4.00. As seguintes Regras de Validação devem ser executadas no início das validações de CTe, CTeOS e GTVe: Se Tipo do CT-e= 2 (Anulação) ou 3 (Substituição), rejeitar o CTe cStat - 990: Rej. Rejeição: Vedado a utilização do CTe de anulação ou substituição na versão 3.00 O grupo de dado do CTe de substituição não pode ser informado (grupo: infCteSub) cStat - 991: Rej. Rejeição: Dados do CTe de substituição não são permitidos na versão 3.00 Todas as regras de validação associadas aos CTe de anulação e substituição perdem o sentido porque o ambiente de autorização não passará por elas. Revogação do Evento de Informações da GTV no CTeOS e suas implicações Revoga-se o evento de Informações da GTV (em papel) no CTeOS de Transporte de valores para as versões 3.00 e 4.00. Tipo de evento revogado: 110170. Em relação as Regras de Validação do CTeOS as seguintes alterações serão aplicadas a versão 3.00 (até sua total desativação) e na versão 4.00: Regra de Validação Revogada Se tipo de serviço = Transporte de Valores - Verificar se existe CTe OS autorizado há mais de 45 dias para o mesmo CNPJ do emitente sem que exista pelo menos um evento de Informações da GTV vinculado Observação: Retornar a chave de acesso do CTe OS mais antigo que causou o bloqueio Observação 2: Essa validação não deve ser aplicada no ambiente de homologação. Observação 3: A validação não deve ser aplicada a CTe OS de transporte de valores que relacionam GTVe. Rejeição: Existe CTe OS de Transporte de Valores autorizado há mais de 45 dias sem informar as GTV [chCTe: 99999999999999999999999999999999999999999 999]. Nova Regra de Validação para Transporte de Valores H045a: cStat - 927. Se tipo de serviço for igual a Transporte de Valores - O grupo de informações infGTVe DEVE estar informado. Rejeição: Informações da GTVe devem ser preenchidas para CTe OS de transporte de valores. Retificação de informação do MOC 4.00 O valor de preenchimento da tag CST do grupo ICMSSN deve ser conforme está no schema da versão 4.00 com o valor 90 – Simples Nacional e não 01 – Simples Nacional como saiu no MOC. A tag correta deverá aceitar apenas o valor 90 – Simples Nacional. Modificações no ACBr. De maneira bem resumida, a Nota Técnica discorre sobre algumas regras de validação e o fim do evento de inutilização. Por isso, modificações no ACBr não se fazem necessárias. Dito isso será preciso que validem em suas aplicações para remover a possibilidade de enviar este evento. Esta e outras Notas Técnicas disponíveis AQUI. Você pode ler esta Nota Técnica na íntegra AQUI.

Funcionou Italo! Seguindo essa abordagem, achas necessário criar um param extra no provedor (ex.: Param=SoapDadosMsgCdata:), para setar somente para POA/RS? Ou faço a alteração para todos os provedores? Verifiquei no arquivo INI, e esse provedor é usado por Porto Alegre/RS e Belo Horizonte/MG.

Boa tarde Tiago, Você poderia anexar o XML da nota para que possamos fazer uma analise?

Boa tarde. Foi enviado ao SVN uma alteração visando sanar essa questão. Por favor, atualize seus fontes, reinstale o ACBr, siga o que é pedido no tópico abaixo para fazer novos testes e reporte qualquer problema.

Confirmando, você está usando a versão atual do programa de exemplo, consequentemente do componente também? ../trunk2/Exemplos/ACBrDFe/ACBrNFSeX/Delphi/

O arquivo de retorno foi enviado no email.

Ola; Com Acbrlib, Acbrmonitorplus e o componente tem essa opção mais precisa do certificado digital instalado na maquina, sem certificado só conheço pago https://acbr.sourceforge.io/ACBrLib/NFE_ConsultaCadastro.html

Alexandre, Se esta aparecendo versão 1.00 isso significa que os seus fontes não estão atualizados ou existe uma cópia do arquivo ACBrNFSeXServicos.ini na pasta do executável. Verifique se tem, caso afirmativo dele o arquivo. Outra coisa verifica se não tem nenhum arquivo do ACBr com uma bolinha vermelha em se ícone, caso afirmativo, delete, atualize novamente os fontes, reinstale o ACBr, compile a aplicação com a opção build e por fim faça novos testes.

@Jean Peixoto Boa tarde , coloquei na mesma tarefa da sua outra contribuição para análise TK-3798

Boa tarde Pessoal, Quinta feira (30/03/2023) enviei para o SVN uma atualização dos fontes do ACBrCT-e visando atender a versão 4.00 do CT-e. Já esta tudo no SVN, os novos schemas bem como os fontes atualizados do componente. Por favor atualizem todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes. Lembre-se que agora devemos configurar o componente para a versão 4.00, sendo assim devemos atribuir o valor ve400 a propriedade VersaoDF. Não sei se todas as UF já estão com os seus ambientes de homologação preparados para a versão 4.00, uma vez que nos manuais consta somente 04/2023, conforme postagem anterior. Mas não custa nada tentar. Qualquer problema, favor criar um tópico no fórum para que possamos fazer as devidas correções. Desde já muito obrigado pela colaboração nos testes.

Boa tarde Willian, A alteração pode afetar outros municípios que utilizam o mesmo provedor. Está em análise, assim que subir será avisado neste tópico.

Show de bola, vlw pessoal!

Vai precisar esperar a Lib ou o monitor para usar com sua linguagem. os componentes são somente para Delphi e Lazarus

Recebi agora as seguintes respostas por parte da SEFAZ: Bom dia, Respondo seus questionamentos abaixo. 1 - Nos casos em que o comprovante for impresso no POS, como devo proceder o preenchimento dos dados da transação nas tags do xml da NFCe? Devo solicitar que o usuário digite o número do NSU (código de autorização) gerado pelo autorizador e impresso no comprovante do POS e preencher a tag Caut do xml com esse código ? é obrigatório somente o NSU ? ou será obrigatório também o preenchimento do código do autorizador, código da bandeira e tipo de transação (Crédito, débito ou voucher) ? A Normativa determina que um código da operação deve ser gerado, e que esse código seja informado no comprovante de pagamento e na nota fiscal. O objetivo é que seja possível relacionar especificamente qual pagamento corresponde a qual nota fiscal. Porém, a Normativa não determina nenhum método específico elo qual o código deva ser gerado e informado. a empresa pode usar o método que achar mais conveniente. Se a empresa utiliza sistemas de pagamento e de emissão de nota fiscal que se conectem, então o sistema da empresa provavelmente vai gerar um código da operação e informar nos 2 documentos de forma automática,, sem necessidade de interação com o usuário. E no caso de pequenos comércios nos quais o sistema de pagamento e de emissão de nota fiscal não sejam integrados, então o código provavelmente seria gerado por um sistema e digitado no outro. Temos recebemos alguns questionamentos se isso não iria inviabilizar o pequeno comércio. Não, não iria. Atualmente, quando o pequeno comercio recebe um pagamento em cartão, ele já tem que digitar o valor da operação no equipamento. Com essa operação, ele teria que digitar o valor da operação e mas um número. Trata-se no máximo de uma inconveniência, mas não de algo que vá impactar no negócio. Quanto à gestão sobre ter que informar tipo de transação (crédito, débito ou voucher), isso não é nenhuma novidade. Isso já estava sendo feito antes da Normativa. Na NFC-e, existe o campo "Meio de pagamento" (tag "tPag", no arquivo XML. Esse campo informa se o pagamento está sendo feito om cartão de crédito, cartão de débito, ou outra forma diferente. Trata-se de um campo de preenchimento obrigatório na NFC-e. Esse campo já existia antes, e não foi criado agora. Terei que imprimir outro comprovante após a impressão da DANFe NFCe, já que o texto da lei diz que o comprovante deverá ser impresso no mesmo equipamento da DANFE ?. Se sim, o que devo imprimir nesse comprovante ? tem que ser um duas vias ? o Cliente vai sair da loja com dois comprovantes nesses casos ? Novamente, não se trata de uma novidade. Muitas empresas já estão fazendo isso antes da Normativa. Se você for em um restaurante e fizer o pagamento com catão, então o restaurante provavelmente vai lhe dar 2 documentos, uma NFC-e e um comprovante de pagamento. O item da lei que diz que a impressão deve ser feita no mesmo equipamento está em revisão e provavelmente deverá ser removido. 2 - Como existe um número grande de autorizadores no mercado e um número maior ainda de bandeiras e o número do NSU/código de autorização normalmente contém vários dígitos, existe uma possibilidade enorme de erro de digitação por partes dos usuários durante o processo de digitação. De quem será a responsabilidade caso as informações sejam inseridas de forma errada ? Como regra geral, para qualquer campo que tenha sido preenchido de forma incorreta na NFC-e, a responsabilidade é da empresa emitente. Da mesma forma que, por exemplo, se a empresa cometer um erro de digitação ao informar o valor da operação. A responsabilidade será da empresa emitente. Existem procedimentos previstos na legislação para tratar erros de preenchimento na nota fiscal. O procedimento exato a ser seguido pode variar, de acordo com a natureza específica do erro. Se a empresa cometer um erro da digitação na nota fiscal e não souber qual é o procedimento para corrigir, então a empresa pode entrar em contato conosco e daremos a orientação. 3 -As transações PIX podem gerar um código de autorização com mais de 20 caracteres. Como preencher a tag Caut nesses casos, já que o tamanho máximo previsto dessa tag é 20 ? Vocês estão supondo que esse código gerado pela transação PIX é necessariamente o mesmo código que deve ser informado na nota fiscal. Trata-se de um engano. Conforme mencionado abaixo, a Normativa não define um método específico para gerar o código. A empresa pode gerar o código da forma que achar mais conveniente. O código da operação não precisa ser esse que foi gerado pela transação PIX, pode ser outro código. O importante é que um código seja gerado e informado nos 2 documentos. Além disso, há casos em que as empresas PRIMEIRO emitem a nota fiscal, e DEPOIS recebe o pagamento. Nesses casos, o código gerado pelo PIX não poderia ser usado de qualquer forma, independente do número de dígitos. Ele não poderia ser usado porque ele somente vai ser gerado depois da emissão de nota fiscal. Assim, esqueçam esse código gerado pelo PIX. Não é esse código que deve ser informado. Ao invés disso, gerem um novo código no sistema da empresa, e informem esse código nos 2 documentos. 4 - Quando um cliente quiser pagar um título de crediário com cartão de crédito/débito ou pix. Como proceder nesses casos, já que não haverá NFCe envolvida nessa transação ? Na verdade, há sim uma NFC-e envolvida na transação. A NFC-e é emitida no momento da venda. O que vocês querem dizer é que o pagamento é feito posteriormente, e não há emissão de NFC-e no momento do pagamento. O código da operação deve ser gerado no momento da transação do pagamento eletrônico, ou então no momento de emissão da nota fiscal, o que vier antes. Uma regra simples que várias empresas estão adotando, é que o código de integração seja gerado pelo sistema que for usado antes. Depois, o mesmo código é informado no outro documento. Ou seja: Se a empresa PRIMEIRO receber o pagamento, e DEPOIS emitir a nota fiscal, então o código de integração é gerado pelo sistema de pagamento, no momento da transação do pagamento. Depois, o mesmo código é informado na nota fiscal. Por outro lado, se a empresa PRIMEIRO emitir a nota fiscal, e DEPOIS receber o pagamento, então o código de integração é gerado pelo sistema emissor da nota, no momento da emissão. Depois, o mesmo código é informado no comprovante de pagamento. A respeito dos casos em que a empresa faz a venda, e o pagamento é feito posteriormente. Nesse caso, quando o documento fiscal for emitido, então o sistema da empresa deverá gerar o código de identificação da operação, e informar esse código no campo específico da nota fiscal (tag "cAut", no arquivo XML). Esse código ficaria registrado no sistema da empresa, para consulta posterior. Mais tarde, quando o cliente realizar o pagamento, o sistema poderia verificar qual é a nota fiscal que está sendo paga, consultar qual é o código de identificação correspondente, e informar esse mesmo código no comprovante de pagamento. Pelo que entendi, nos casos de equipamentos POS, o tal do "código de integração" deverá ser gerado no sistema que fizer a operação primeiro, ou seja.. Se fizer o pagamento no POS e depois fizer a NFCe, então digita-se o NSU gerado pelo POS na NFCe e informa na tag Caut. Se a NFCe for feita primeiro, o Sistema de automação comercial deverá gera um código de integração qualquer(aleatório), informar esse código na tag Caut da NFCe e posteriormente INFORMAR ESSE CÓDIGO NO POS QUANDO FOR FAZER A TRANSAÇÃO DO PAGAMENTO. Até onde eu sei, não existe nenhum campo atualmente no Software básico da NFCe onde se possa informar alguma coisa durante a transação.. Para isso os fabricantes de POS vão ter que altera seus Softwares básicos para atender o decreto ? Fiz esse questionamento ao auditor e estou aguardando resposta. No caso de pagamento de título de crediário, acho que ele ainda não entendeu do que se trata.. No momento da emissão da NFCe a forma de pagamento é CRÉDITO LOJA, isso gera um título no contas a receber da empresa que posteriormente poderá ser pago com cartão de débito. Nesse caso, não vai ser possível informar o código de integração no momento da emissão da NFCe, pois ainda não se sabe se o cliente vai ou não pagar com cartão posteriormente. Sinceramente, acho que deveriam repensar esse Decreto e na confusão que estão causando no comércio do RS atualmente. Fica claro que não sabem como as transações de pagamento funciona atualmente. Vamos aguardar cenas dos próximos capítulos !

Bom dia Dercide, Tem sim, veja: Provedor=ISSNet Params=NaoDividir100: Basta alterar o arquivo ACBrNFSeXServicos.ini, compilar ele com o Compila_RES, reinstalar o ACBr e por fim compilar a aplicação com a opção Build.

Bom dia Italo. Agora sim. Pelo menos até que o Município atualize o sistema, contornamos o problema de emissão. Obrigado

Bom dia Italo, Já estamos fazendo-o assim que tivermos alguma resposta coerente sobre o problema eu retorno aqui. Att. Gabriel Bobello

Bom dia Antonio Carlos !!! ja enviei no e-mail ...

Boa noite. Enviei os seguintes questionamentos para a SEFAZ-RS.. Acredito que minhas dúvidas são as mesmas de muita gente. Procurei ser o mais resumido e claro possível, na esperança que as respostas também sejam: Boa noite. Sou desenvolvedor de Sistema de automação comercial e tenho alguma dúvidas com relação a nova lei que obriga a vinculação de NFCe ao pagamento com cartões de crédito ou qualquer outro meio eletrônico de pagamento. Recentemente li algumas respostas desse canal a outras pessoas e nelas me chamou a atenção o fato de que as transações eletrônicas poderão continuar sendo autorizadas com POS(maquininha de cartões). Nesse ponto gostaria de alguns esclarecimentos: 1 - Nos casos em que o comprovante for impresso no POS, como devo proceder o preenchimento dos dados da transação nas tags do xml da NFCe? Devo solicitar que o usuário digite o número do NSU (código de autorização) gerado pelo autorizador e impresso no comprovante do POS e preencher a tag Caut do xml com esse código ? é obrigatório somente o NSU ? ou será obrigatório também o preenchimento do código do autorizador, código da bandeira e tipo de transação (Crédito, débito ou voucher) ? Terei que imprimir outro comprovante após a impressão da DANFe NFCe, já que o texto da lei diz que o comprovante deverá ser impresso no mesmo equipamento da DANFE ?. Se sim, o que devo imprimir nesse comprovante ? tem que ser um duas vias ? o Cliente vai sair da loja com dois comprovantes nesses casos ? 2 - Como existe um número grande de autorizadores no mercado e um número maior ainda de bandeiras e o número do NSU/código de autorização normalmente contém vários dígitos, existe uma possibilidade enorme de erro de digitação por partes dos usuários durante o processo de digitação. De quem será a responsabilidade caso as informações sejam inseridas de forma errada ? 3 -As transações PIX podem gerar um código de autorização com mais de 20 caracteres. Como preencher a tag Caut nesses casos, já que o tamanho máximo previsto dessa tag é 20 ? 4 - Quando um cliente quiser pagar um título de crediário com cartão de crédito/débito ou pix. Como proceder nesses casos, já que não haverá NFCe envolvida nessa transação ? Sem mais, aguardo retorno de minhas dúvidas para que possamos orientar nossos clientes e atender a lei de forma clara e correta. Muito obrigado. Assim que receber alguma resposta, posto aqui.. abraços..

Deve ter uma cópia do ini desatualizada na pasta da aplicação.

Ola; Não seria uma NF-e de ajuste? FinNFe=3 no XML

Guilherme, Para quem usa certificado A3 no formato cartão ou token, configure: WinCrypt + LibXml2.

Guilherme, Experimenta trocar o XmlToStr que se encontra nas funções que montam o conteúdo do grupo Body por IncluirCDATA.

Mario, Você consegue o link da seguinte forma: ACBrNFSeX1.WebService.Emite.Link

Acesso o site: https://www.nfe.fazenda.gov.br/portal/principal.aspx Acesse a guia Manuais: Seleciona o Anexo I: O arquivo .pdf será baixado em sua máquina. Abra o arquivo e com a ferramenta de procura digite a tag desejada e verifique qual se refere a tabela desejada. Fiquei pensando qual seria o motivo pelo qual a SEFAZ não libere esta informação de maneira "consultável" (Via WebService, json, etc). A única resposta que me veio em mente seria que sendo possível consultar situações assim automaticamente, essa prática poderia acostumar as Software Houses a deixar erros acontecer no cliente para tomar alguma providência. Neste caso melhor seria se a responsabilidade de verificação ficasse por parte das Software Houses para que eventuais problemas fossem corrigidos antes de algum problema ocorrer no cliente. Como a quantidade de Software Houses é muito grande, seria uma tratativa plausível para evitar problemas. Posso estar errado também mas foi o que me veio em mente.

Foi publicada a versão 23.1.D 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/03/2023 até 30/04/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. Em 29/03/2023, foi publicada a versão 10.1.2 do programa validador do SPED ECD - Escrituração Contábil Digital, trazendo as seguintes mudanças: Fonte: http://sped.rfb.gov.br/pagina/show/7190

Isso funciona até reiniciar o computador, o correto é fazer a troca do driver para trabalhar como modo USB. Através do Elgin Utility Após fazer o procedimento, desligue e ligue a impressora, o windows instalará o driver da impressora nova como Elgin i9(USB) no spooler.

Olá, desenvolvi a geração do arquivo AEJ, baseado nas informações contidas em: https://www.gov.br/trabalho-e-previdencia/pt-br/composicao/orgaos-especificos/secretaria-de-trabalho/inspecao/fiscalizacao-do-trabalho/leiaute-do-arquivo-eletronico-de-jornada-aej.pdf A parte da assinatura digital .p7s, consegui desenvolver também, porém utilizando uma dll não gratuita por isso não incluí no projeto a parte da assinatura digital, mesmo assim creio que já será de grande ajuda todo o resto. ACBR\Fontes\ACBrTXT\ACBrPonto ACBrPonto.rar ACBR\Exemplos\ACBrTXT\ACBrPonto\Delphi Exemplo.rar

Olá Pessoal, O ENCAT publicou uma nova versão da NT 2022/003 (versão 1.10), e já de inicio destacamos que os prazos permanecem os mesmos da versão 1.00 da NT, ou seja 07/02/2023 para homologação e 03/04/2023 para produção. Vamos as mudanças desta versão da NT... Novas Regras de Validação Regras de Validação relativas as tags refNFE e refNFeSig (BA02-60 e BA02a-110 ) Estas regras visam garantir que quando houver uma Chave referenciada (tag: refNFe) ou uma Chave Referenciada com código numérico zerado (tag: refNFeSig), o tipo de emissão da chave referenciada seja válido. Regra validando o conteúdo da tag refNFeSig (BA02a-74) Esta regra visa garantir que, quando houver uma Chave Referenciada com código numérico zerado (tag: refNFeSig), o código numérico seja efetivamente zerado. Regra validando a informação de valor na tag refNFeSig quanto a adesão da UF (BA02a-120) Esta regra visa evitar que seja utilizado o campo de Nota Referenciada com código numérico zerado (tag: refNFeSig) em UF que não permite tal referência. Ajustes em regras existentes Ajuste na definição de quais modelos de DFe a regra se aplica (BA02a-90) A coluna de modelo desta regra havia sido deixada em branco equivocadamente, alterada para constar sua aplicabilidade somente para o modelo 55. Alteração da descrição quanto a aplicabilidade da regra, que no momento é somente para o CE (N17c-30) Alterada a descrição da RV N17c-30 para que fique claro que ela somente se aplica, neste momento, para o Ceará. O Estado do Ceará realiza o controle do FCP de forma diferente das demais UF, o que acarreta na necessidade de implementação desta regra. Exclusão de regra incluída na versão 1.0 Exclusão da Regra para validação de informação de Cupom Fiscal como Doc Referenciado (I08-186) Esta regra foi removida pois a UF que assim desejar pode bloquear Cupom Fiscal referenciado através da ativação da Regra BA20-30 (NT 2019.001). Como a Regra I08-196 sequer chegou a ser implementada, o código de Rejeição inicialmente alocado a ela foi reaproveitado nesta mesma NT. Novas Regras de Validação com Implementação Futura Regras de validação quanto ao modelo de documento referenciado (BA02-70 e BA02-80) Estas regras visam evitar que sejam referenciados documentos eletrônicos diferentes do modelo 55 em devoluções internas de mercadoria e também em devoluções envolvendo consumidor final. Regras com implementação futura.

Com o certificado que possuo não consigo fazer consulta de cadastro no servidor do RS, pois recebo o seguinte retorno: Rejeicao: Solicitante nao habilitado para emissao da NF-e Mas, o campo IE é do tipo STRING, então provavelmente o WebService que está retornando a IE sem o 0 a esquerda. Para contornar este problema, vc pode usar o componente ACBrValidador deixando a propriedade AjustarTamanho = True. Veja o exemplo disponível na pasta Exemplos\ACBrValidador