Painel de líderes

Olá pessoal, Alguns de vocês chegaram aqui por conta do OpenDelivery e outros por já serem membros da comunidade ACBr. Neste artigo vamos esclarecer: o que é o OpenDelivery, o que é o Projeto ACBr e como fazer para integrar sua aplicação para Bares/Restaurante com vários Marketplaces que usam o padrão do Open Delivery, através do nosso componente , o ACBrOpenDelivery de forma rápida e fácil. Antes de ir aos detalhes, vejam um breve vídeo ilustrando o funcionando do ACBrOpenDelivery e como oferecer este recurso aos seus clientes pode ser rápido e fácil. Sobre o OpenDelivery https://www.opendelivery.com.br/ Trata-se de um padrão de comunicação visando simplificar o processo de integração das aplicações as plataformas de delivery existentes no mercado, para saber mais sobre o Open Delivery clique aqui. Sobre o Projeto ACBr https://projetoacbr.com.br/ O Projeto ACBr possui mais de 100 componentes de código aberto que facilitam diariamente as Software Houses (SHs) que atuam no segmento de Automação Comercial. São componentes/bibliotecas/soluções para emissão de Documentos Fiscais Eletrônicos, Comunicação com Equipamentos de Automação Comercial, Escrita Fiscal e muito mais. Além do mencionado acima, o Projeto ACBr ainda oferece produtos pagos que agregam ainda mais agilidade as SHs (estejam vocês trabalhando com Delphi ou qualquer outra tecnologia existente no mercado). Para saber mais sobre o Projeto ACBr e nossas soluções, acesse nosso portal clicando aqui. Sobre o ACBrOpenDelivery Visando trazer mais facilidade aos desenvolvedores, foi lançado primeiramente o componente para Delpjhi/Lazarus chamado ACBrOpenDelivery, com ele o processo de integração com Open Delivery se torna mais simples e fácil, afinal esta é exatamente uma das premissas das soluções ACBr. Recomendamos também ouvir a gravação da edição do nosso podcast "Papo Pro ACBr", onde falamos mais sobre o OpenDelivery: Se você ainda não utiliza os componentes ACBr segue um checklist do que fazer para iniciar. Para baixar os fontes do ACBr, basta seguir as instruções do link a seguir: https://projetoacbr.com.br/fontes/ Caso ainda não utilize o SVN, siga as instruções do nosso vídeo sobre a instalação do ACBr indicado a seguir. Efetue o download dos fontes do ACBr, que inclui além do ACBrOpenDelivery, os demais componentes, exemplos de uso e outros arquivos importantes Com o componente instalado, é hora de analisar o demo do componente para entender melhor como integrar. Lembrando que o exemplo se encontra no SVN junto com os demais fontes (http://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrOpenDelivery/) Para as dúvidas*, acesse nossa comunidade aqui no fórum ou via discord. *Se sua SH tem urgência na implementação e quer o atendimento dos Consultores ACBr para ter ainda mais agilidade recomendamos analisar a adesão ao ACBr Pro.

Até o momento sabemos que a exigência da vinculação do pagamento ao documento fiscal somente será aplicada nas operações presenciais, ou seja, quando se tratar de uma tele entrega, aonde o pagamento será realizado posteriormente a emissão do documento fiscal, não seria obrigatório. - "29.5.1 -A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFC-e emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal". Também consta no anexo PFV-226770-L0G3H, que o item "29.5.1.2 - Na hipótese de impressão do DANFE da NFC-e, deve ser utilizado o mesmo equipamento para a impressão do comprovante referido subitem 29.5.1.", está sendo analisado e deverá ser removido da legislação, porém, não há detalhamento de como ou quando isso iria ocorrer. Entrando na parte da solicitação de vinculação do pagamento ao documento fiscal, precisamos primeiramente analisar o Grupo YA. Informações de Pagamento, conforme MOC 7.0 - Anexo I - Leiaute da NF-e/NFC-e (https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J I v4eN00E=). Atualmente, existe o grupo card, composto pelas tags: YA04a - tpIntegra(Tipo de Integração para pagamento) YA05 - CNPJ(CNPJ da instituição de pagamento) YA06 - tBand(Bandeira da operadora de cartão de crédito e/ou débito) YA07 - cAut(Número de autorização da operação cartão de crédito e/ou débito). Gostaria que atentassem a essa tag principalmente. Lembrando que o tamanho é 1-20. Como o item 29.5.1 do decreto nos diz que praticamente todo tipo de pagamento deva estar ligado a NFC-e, questionamos então a receita sobre de que forma deveria ser feita essa interligação, visto que nosso MOC atual não prevê campos para transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo ou demais instrumentos de pagamento eletrônico e sim campos específicos para operações com cartões de crédito ou débito. Recebemos então a resposta que já imaginávamos, aonde os campos não existem ainda na NFC-e e que em um futuro próximo eles devem ser criados, porém novamente, sem nenhuma previsão. Conforme as outras respostas recebidas, a orientação por parte de receita é de que utilizemos a tag cAut para vincular o pagamento junto da NFC-e, o que nos traz algumas dúvidas: É correto utilizar um campo que está detalhado no layout da NFC-e como uso em operações com cartão de crédito/débito para vincular um pagamento como pix ou transferência bancária? Supondo que informemos o código da autorização da transação na tag cAut, muitas vezes esses códigos ultrapassam o limite de 20 caracteres. Como proceder? Foi comentado sobre a aplicação do cliente gerar um código interno, inserindo esse código gerado na NFC-e e armazenando os detalhes da transação no banco de dados. Como é que a receita iria cruzar essas informações? O sistema do lado do emissor poderia gerar qualquer bobagem lá, apenas respeitando o limite de 20 caracteres... Como isso seria fiscalizado? Nesse primeiro momento, o correto não seria então somente vincular as operações com cartões, desconsiderando PIX e transferências? No caso aonde devêssemos informar os dados de uma transação para o vínculo que ainda não possui campo próprio no layout, não seria mais correto utilizarmos algum outro campo, como exemplo o infAdFisco(campo texto livre de 2000 posições)? Em um caso aonde a NFC-e esteja sendo digitada, a transação é efetuada por uma maquininha POS, vinculada ao CNPJ do emissor, conforme item 1.1 da INSTRUÇÃO NORMATIVA RE Nº 108/22(http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=108) e o sistema do emissor abre o campo para digitação, aonde o emissor irá informar o código da autorização recebido pela POS e esse código informado é anexado nas tags próprias da NFC-e, esta operação não estaria correta e não seria muito mais simples cruzar os dados em caso de fiscalização? Supondo que o estabelecimento tenha algum problema com energia elétrica, impossibilitando o uso de um computador, por exemplo, e trabalhando durante um determinado período com uma máquina POS, como seria realizado o vínculo do pagamento com a NFC-e? Visto que o pagamento já tenha ocorrido antes da emissão. Enfim, as informações especificadas na documentação e nas indicações não estão claras e sinceramente, essa história de que o sistema do emissor deva gerar um código e anexar na tag de cartão, não faz sentido. O mais preocupante é que o decreto já entra em vigor daqui 5 dias...

Conforme tópico citado abaixo, criado anteriormente pelo Daniel, eis que nos deparamos com um novo decreto no estado do Rio Grande do Sul, aonde os principais objetivos seriam: A vinculação da emissão do documento fiscal em operações que envolvam instrumentos de pagamento eletrônico; A emissão do comprovante de transação ou intermediação de vendas ou serviços efetuada com cartões de débito, crédito, de loja (private label), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo, e demais instrumentos de pagamento eletrônico devem estar vinculados ao documento fiscal emitido na operação ou prestação respectiva, conforme disposto na legislação pertinente. Inicialmente, estaria vedada a utilização de equipamentos de pagamentos não integrados ao emissor de NFC-e. Já na INSTRUÇÃO NORMATIVA RE Nº 108/22 (http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=108), os equipamentos POS são citados e podem ser utilizados, desde que estejam vinculados ao CNPJ do estabelecimento em que estiver sendo utilizado. Diante da análise do decreto, bem como as diversas instruções normativas que foram adicionadas posteriormente, nos deparamos com algumas dúvidas, que foram direcionadas ao NAVi - Núcleo de Atendimento Virtual Receita Estadual – RS. Como as respostas não foram claras até o momento e ainda restam muitas dúvidas a respeito de como proceder para estar de acordo com essa nova legislação, que entra em vigor na data de 01/04/23, para determinados estabelecimentos, irei anexar os principais questionamentos e respostas obtidas até agora, para que todos possamos analisar. Caso alguém também tenha enviado questionamentos e recebido respostas, considere válido adicionar junto ao tópico. 1ª Pergunta, enviada em 09/03/23, respondida em 15/03/23 por Eduardo S. Benazzi (Auditor Fiscal da Receita Estadual) Pergunta: Conforme o DECRETO Nº 56.670, DE 26 DE SETEMBRO DE 2022, ficou vedada a utilização de maquininhas POS no RS, trazendo a obrigatoriedade da utilização do TEF para recebimento via cartões, pix, etc. Na INSTRUÇÃO NORMATIVA RE Nº 108/22, já é citado o equipamento POS, com algumas restrições de uso, porém, torna possível a utilização, que no decreto anterior dizia ser proibido. A minha dúvida é, caso o cliente utilizar equipamento POS, ou até mesmo um recebimento via PIX, aonde o qrcode é gerado diretamente pelo seu software emissor e não pelo equipamento do TEF, se o software emissor pode vincular as informações do pagamento, transação, etc, diretamente nas tags de XML da NFC-e. No caso, nós com software house, geraríamos um qrcode para recebimento via pix, o consumidor irá efetuar o pagamento e esse pagamento será vinculado na nfc-e, em suas tags específicas. Esse processo corresponderia com a legislação? Resposta: A respeito dessa questão, precisamos esclarecer que o Decreto 56,670 não veda a utilização de máquinas POS, e também não torna obrigatória a utilização do sistema TEF> Isso é um engano. O que o Decreto 56,670 determina, isso sim, é a obrigatoriedade de integração da NFC-e com o meio de pagamento eletrônico. A empresa pode utilizar qualquer sistema que forneça as informações necessárias, e não precisa necessariamente ser um sistema TEF. A idéia básica é que certas informações devem ser preenchidas no comprovante de pagamento e também na nota fiscal. Em particular, o sistema da empresa deve gerar um código de identificação da operação. Esse código deve ser impresso no comprovante de pagamento, e deve também ser informado em campo específico da nota fiscal (tag "cAit", no arquivo XML). Orientações sobre o assunto estão no arquivo em anexo. Pergunta² (enviada em 16/03/23, respondida em 18/03/23): Então, ainda fico na dúvida referente a um ponto: "29.5.1 - A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFC-e emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal, a partir de:" - INSTRUÇÃO NORMATIVA RE Nº 108/22 Com a sua explicação e a informação da instrução normativa, entendo que os pagamentos eletrônicos, sendo PIX ou transferência bancária, também devemos informar na tag cAut o código da transação. Porém, se analisarmos o manual da NF-e, a tag cAut se refere ao número de autorizaçção da operação cartão de crédito e/ou débito. Desta forma, não estaria correto informar na cAut o código de autorização destes pagamentos, correto? Então o decreto está exigindo o vínculo de todos pagamentos listados, porém no layout da nota somente temos campos para cartões. Neste caso então transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico não tem como ser vinculados no documento, correto? Resposta²: A NFC-e ainda não possui campos específicos para outras formas de pagamento eletrônico, como o PIX. Esses campos específicos deverão ser criados no futuro próximo. Até que esses campos específicos sejam criados, a orientação é que sejam preenchidos os campos referentes a cartão (grupo "card", no arquivo XML). Esses campos podem ser preenchidos mesmo que seja usada outra forma de pagamento eletrônico, ao invés de cartão. Anexo recebido da 1ª pergunta: anexo PFV-223235-H3D2X.pdf 2ª Pergunta, enviada em 13/03/23, respondida em 15/03/23 por Eduardo S. Benazzi (Auditor Fiscal da Receita Estadual) Pergunta: No estado do RS, surgiu uma normativa (Imagem em anexo) que é necessário enviar as informações da transferência de recursos nas tags da nfce. Precisaria saber qual a informação que devo enviar quando realizo o envio de um pagamento pix, por exemplo. Sei que é necessário informar nas tags do xml a informação do tipo do pagamento pix. Existe mais alguma informação a ser enviada além do tipo de pagamento 17? Por exemplo, número da transação do pix? Obrigado! Resposta: Para essa integração, algumas informações deverão ser inseridas na NFC-e e no comprovante de pagamento. A empresa pode utilizar qualquer sistema que forneça essas informações, e não precisa necessariamente ser um sistema TEF. Orientações a respeito desse assunto estão no arquivo em anexo. Pergunta²: Tenho apenas uma duvida: quando for o tipo de pagamento PIX (tpag = 17), será necessário informar na tag caut com o código de autorização da transação pix? E é necessário informar também o CNPJ de quem está emitindo o pagamento do pix? Fiz um teste para envio de uma nfce em homologação enviando dessa forma e foi aprovado? Essa é a forma correta de envio para o PIX? <pag> <detPag> <tPag>17</tPag> <vPag>9.00</vPag> <card> <tpIntegra>1</tpIntegra> <CNPJ>04430502000103</CNPJ> <cAut>49f3ea19-2a89-428b-a</cAut> </card> </detPag> </pag> Obrigado! Resposta²: Ainda sem resposta por parte da receita. Anexo recebido da 2ª pergunta: anexo PFV-224302-M3Y0Y.pdf 3ª Pergunta, enviada em 14/03/23, respondida em 15/03/23 por Eduardo S. Benazzi (Auditor Fiscal da Receita Estadual) Pergunta: Tenho uma dúvida referente a exigência do TEF, sobre a nova legislação envolvida que irá entrar em vigor em Abril de 2023. Como funcionaria o caso de tele-entrega, aonde o pagamento é efetuado no momento da entrega e a NFC-e já foi emitida? Podemos utilizar o exemplo abaixo: O estabelecimento recebe o pedido do cliente, emite a NFC-e, envia a mercadoria pelo motoboy e o cliente vai realizar o pagamento no momento da entrega da mercadoria. Este processo foi inviabilizado devido a esta nova legislação ou tem alguma maneira de procedermos? Resposta: Em primeiro lugar, precisamos esclarecer que nenhuma empresa está obrigada a utilizar o sistema TEF a partir de 01/04. Trata-se de um engano. Se alguém lhe passou a informação de que o sistema TEF será obrigatório a partir de 01/04. então devo dizer que lhe passaram uma informação incorreta. O que existe a partir de 01/04, isso sim, é a obrigatoriedade de integração entre a NFC-e e os meios de pagamento eletrônicos. Para essa integração, algumas informações deverão ser inseridas na NFC-e e no comprovante de pagamento. A empresa pode utilizar qualquer sistema que forneça essas informações, e não precisa necessariamente ser um sistema TEF. Orientações a respeito desse assunto estão no arquivo em anexo. Essa obrigatoriedade será aplicada nas operações de venda realizadas de forma presencial. Essa obrigatoriedade não se aplica nas operações de tele-entrega. Anexo recebido da 3ª pergunta: anexo PFV-224504-P4P2M.pdf 4ª Pergunta, enviada em 14/03/23, respondida em 15/03/23 por Eduardo S. Benazzi (Auditor Fiscal da Receita Estadual) Pergunta: Gostaria de retirar uma dúvida, sobre a emissão de NFCe com a obrigação de utilizar o TEF aqui no estado do RS. Exemplo: O cliente emitiu uma NFCe com venda a prazo, só que o pagamento desse documento vai ser pago em 3 vezes, é necessário vincular os pagamentos futuros com a NFCe aprovada? Ou apenas enviamos que é uma venda a prazo com tal forma de pagamento com as faturas como já é enviado atualmente. Qual opção devemos utilizar no TEF nesses casos? Exemplo-2: Está sendo exigido o vínculo do pagamento com a NFCe, exemplo de uma venda no PIX, para realizarmos esse vínculo, o correto é apenas informar na tag Tpag = 17 ou é necessário informar o código da transação aprovada em outra Tag, e se precisar informar qual Tag seria a correta? Poderia nos fornecer um exemplo? Obrigado Resposta: Em primeiro lugar, precisamos esclarecer que nenhuma empresa está obrigada a utilizar o sistema TEF a partir de 01/04. Trata-se de um engano. Se alguém lhe passou a informação de que o sistema TEF será obrigatório a partir de 01/04. então devo dizer que lhe passaram uma informação incorreta. O que existe a partir de 01/04, isso sim, é a obrigatoriedade de integração entre a NFC-e e os meios de pagamento eletrônicos. Para essa integração, algumas informações deverão ser inseridas na NFC-e e no comprovante de pagamento. A empresa pode utilizar qualquer sistema que forneça essas informações, e não precisa necessariamente ser um sistema TEF. Orientações a respeito desse assunto estão no arquivo em anexo. Para haver a integração, o sistema da empresa deve gerar um código de identificação da operação. Esse código deve ser informado em um campo específico da nota fiscal (campo "cAut", no arquivo XML), e também deve ser impresso no comprovante de pagamento. Na situação que foi descrita,, o sistema da empresa vai emitir uma nota fiscal. O sistema deve gerar esse código de identificação da operação, e informar o código no campo específico da nota fiscal. Esse código poderá ficar registrado no sistema, para consulta posterior. Posteriormente, o cliente realiza o pagamento. A fatura vai ser referente a uma nota fiscal, e assim o sistema da empresa vai saber qual é a nota fiscal que está sendo paga. O sistema da empresa pode verificar qual é o código que ficou registrado para essa nota, e informar esse mesmo código no comprovante de pagamento. 5ª Pergunta, enviada em 14/03/23, respondida em 15/03/23 por Eduardo S. Benazzi (Auditor Fiscal da Receita Estadual) Pergunta: Com a nova lei que está para entrar em vigor em 01/04 a qual é obrigatório a utilização de TEF na emissão de NFCe quando forma de pagamento for cartão, precisamos saber qual o procedimento seguir para caso de entregas. Somos supermercado e fizemos entrega de ranchos na casa do cliente, atualmente na entrega é levado a máquina de cartão POS junto até o Local. Com a regra a qual ao sair a NFCe tem que ser vinculado o pagamento Cartão e impressão do comprovante, como faremos? Resposta: Em primeiro lugar, precisamos esclarecer que nenhuma empresa está obrigada a utilizar o sistema TEF a partir de 01/04. Trata-se de um engano. Se alguém lhe passou a informação de que o sistema TEF será obrigatório a partir de 01/04. então devo dizer que lhe passaram uma informação incorreta. O que existe a partir de 01/04, isso sim, é a obrigatoriedade de integração entre a NFC-e e os meios de pagamento eletrônicos. Para essa integração, algumas informações deverão ser inseridas na NFC-e e no comprovante de pagamento. A empresa pode utilizar qualquer sistema que forneça essas informações, e não precisa necessariamente ser um sistema TEF. Orientações a respeito desse assunto estão no arquivo em anexo. Essa obrigatoriedade será aplicada nas operações de venda realizadas de forma presencial. essa obrigatoriedade não se aplica nas operações de tele-entrega 6ª Pergunta, enviada em 14/03/23, respondida em 15/03/23 por Raquel Priscilla Presotto (Técnica Tributária da Receita Estadual) Pergunta: Boa tarde. Estamos com duvida referente ao processo correto a seguir devido as alterações que estão para entrar em vigor em 04/2023 na IN 81/2022 e Decreto 56.670/2022. Entendemos que na emissão da NFCe o comprovante de pagamento(quando via cartão e PIX) deve ser impresso no mesmo equipamento que imprime a NFCe com seus devidos dados(dados da transação de cartão utilizado na venda). No caso de vendas a prazo/crediário(exemplo mercado que vai vendendo durante o mês e é feito o acerto ao inicio do mês subsequente), quando esse pagamento do crediário é feito via cartão ou PIX, como funciona, pode ser utilizado a máquina POS para recebimento? Nesse caso a venda já ocorreu e seria o acerto via Cartão/Pix de uma venda crediário. Resposta: Prezado(a) contribuinte: A ideia básica da integração é que certas informações devem ser preenchidas no comprovante de pagamento e também na nota fiscal. Em particular, o sistema da empresa deve gerar um código de identificação da operação. Esse código deve ser impresso no comprovante de pagamento, e deve também ser informado em campo específico da nota fiscal (tag "cAut", no arquivo XML). A empresa pode utilizar qualquer sistema que forneça essas informações, e não precisa necessariamente ser um sistema TEF. Orientações sobre o assunto estão no arquivo em anexo. Vocês perguntaram a respeito dos casos em que o documento fiscal é emitido, 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. As empresas fornecedoras de sistemas devem estar adaptando os seus sistemas, para se ajustarem à nova regulamentação. Sugerimos que contatem o responsável pelo sistema de sua empresa, para perguntar sobre esse ajuste. Anexo recebido da 6ª pergunta: anexo PFV-226770-L0G3H.pdf anexo PFV-224504-P4P2M.pdf

Boa tarde, sobre as maquinas POS. Referente a maquininha POS eu fiz o seguinte questionamento ao Fisco do RS: se o cliente realizar uma venda no sistema(ERP) e o sistema ter a opção de incluir manualmente as informações do cartão da transação realizada em maquina POS e imprimir o DANFE e o comprovante da transação de cartão conforme solicitado, atenderia esta regra nova? E obtive a seguinte resposta: "A regulamentação é que as informações necessárias sejam incluídas no comprovante de pagamento e nos campos específicos do documento fiscal. A forma específica de incluir essas informações não está determinada na legislação, e assim a empresa pode optar pelo mecanismo que mais lhe convém. Se a empresa preferir incluir essas informações de forma manual, pode fazê-lo. Se preferir ajustar os seus sistemas para que as informações sejam incluídas de forma automática, pode fazê-lo também." E ainda sobre o PIX: A NFC-e ainda não possui campos específicos para outras formas de pagamento eletrônico, como o PIX. Esses campos específicos deverão ser criados no futuro próximo. Até que esses campos específicos sejam criados, a orientação é que sejam preenchidos os campos referentes a cartão (grupo "card", no arquivo XML). Esses campos podem ser preenchidos mesmo que seja usada outra forma de pagamento eletrônico, ao invés de cartão. Minha conclusão: Se informar manualmente a Administradora, bandeira de cartão e numero de autorização da POS pode-se usar a mesma, desde que imprima o DANFE e o sistema gere o comprovante do cartão novamente pelo sistema, e sai tudo na mesma impressora.

@Italo Giurizzato Junior Acho que encontrei o problema, era o "Ç" no cadastro do prestador. Vou fazer mais testes.

Bom dia Mario, Por padrão conforme consta nos manuais e schemas das ABRASF o campo OutrasInformacoes pertence a NFS-e e não ao RPS. Sendo assim não adianta alimentar esse campo que o componente não vai gerar a tag no XML do RPS e caso altere o calor da propriedade que instrui o componente a gerar vai ocorrer erro de validação. Existe essa propriedade porque alguns provedores mudaram os schemas. É preciso entrar em contato com o provedor e questionar sobre esse campo. Se eles aceitam ele no XML do RPS, necessitados de um novo schema do provedor com essa alteração.

Email respondido no dia 23 PFV-228141-G5N8G.pdf E-mail respondido dia 24: O código serve para qualquer tipo de pagamento por meio eletrônico. Criem um novo código. Esse novo código é impresso no comprovante de pagamento e também informado na tag "cAut" da NF-e. Eduardo S. Benazzi Auditor Fiscal da Receita Estadual NAVi - Núcleo de Atendimento Virtual Receita Estadual – RS

Boa tarde. No dia 23/03/2023, foi divulgada a Nota Técnica 2023/001 para MDFe. Resumo da NT. Esta Nota Técnica modifica a regra de validação do evento de encerramento do MDFe para permitir que filiais possam encerrar os MDFe mesmo que em situação cadastral diferente de ativo no CCC. O serviço de eventos já garante que o autor e o CNPJ do certificado de transmissão sejam do mesmo CNPJ base, portanto, impedir que um MDFe seja encerrado por filiais que deixaram de operar gera apenas dificuldade operacional e necessidade de atendimento especializado do fisco para resolver o problema de forma manual. A NT também permite que os emitentes possam consultar MDFe não encerrados sem considerar a situação cadastral da filial. Datas de Implantação. Implantação em Homologação: 03/2023 Implantação em Produção: 04/2023 Sobre as Alterações. Desativação da rejeição da Situação do Emitente no encerramento. K05: Emitente deve estar habilitado na base de dados para emissão do MDFe Exceção: Esta regra não será aplicada quando a forma de emissão do MDFe (tpEmis) for Regime Especial da Nota Fiscal Fácil (3) Observação: Se evento gerado por PAA (grupo: infPAA) verificar se o CNPJ do emitente está em situação ativa no cadastro do CNPJ MEI da RFB. 203: Rej. Rejeição: Emissor não habilitado para emissão do MDFe. Desativação da rejeição da Situação do Emitente no serviço de consulta MDFe não encerrados H06: Emitente não credenciado a emissão de MDFe Exceção: Esta regra não se aplica a CNPJ Emitente que possui vínculo ativo no cadastro de PAA da SVRS. 203: Rej. Rejeição: Emissor não habilitado para emissão do MDFe. Correção da Observação do MOC Anexo I em relação ao tamanho do campo placa no modal rodoviário para o tamanho de 7 caracteres. O MOC Anexo I pode ser encontrado aqui. Já a NT2023/001 pode ser encontrada aqui.

Bom Dia amigos... estou finalizando a implementação das novas CSTs ref aos monofasicos para combustiveis, porem ao gerar o DANFE (FastReports) o campo CSOSN esta saind sempre com valor = 0 segue um XML de exemplo e um print do DANFE Lembrando que os fontes estao atualziados 31230311914502000144550010000101206006101207-procNfe.xml

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-3760

Segue o link de produção da Itabaiana: https://itabaianase.webiss.com.br/ws/nfse.asmx?WSDL

Revise suas configurações de ssl e tls, deve ter relação com elas. Se estiver usando Openssl, confirme se está com as dlls da versão 1.1.1, que são distribuídas com os fontes do componente, salvas na pasta da aplicação, o mesmo para a LibXml2. Com winCrypt, faça todas as atualizações do Windows.

Deu certo, obrigado.

Você pode criar uma função aonde você passe a sua bandeira como string e a função te retorna TpcnBandeiraCartao. Exemplo: if (pos('visa',pBandeira) = 1) then Result := bcVisa As bandeiras estão na unit pcnConversao

eu que peço desculpas, não pontuei correto para que pudesse contar

Sim, fiz uma função para tratar a acentuação, no caso converte de "ç" para "c"

Boa tarde! Deu certo! Obrigada!

Bom dia Júnior, Complementado o que o Luis Claudio lhe passou. Tanto o ACBrMonitor quanto o ACBrLibCTe (no caso) é para quem não trabalha com o Delphi ou Lazarus, ou seja, programa em outra linguagem que não é Objeto Pascal. Se você desenvolve usando o Delphi o melhor caminho é baixar e instalar os componentes ACBr no Delphi, estudar o programa exemplo do componente que você vai usar no caso o ACBrCTe e por fim desenvolver a sua própria aplicação. Lembre-se que o programa exemplo é para lhe mostrar como configurar o componente, como alimentar ele e quais os métodos que foram implementados, tais como enviar, consultar, entre outros. O programa exemplo não é um emissor de CT-e.

Bom dia !!! Ja estou verificando, muito obrigado !

Ok, vou atualizar, obrigado.

Bom dia @C4Dev, Ao montar o XML dessa consulta temos apenas as seguintes informações: CNPJ e IM do emitente, numero série e tipo do Rps. Como você pode ver não tem nenhuma informação do tipo texto que poderia ter uma vogal acentuada que viesse a gerar esse erro de UTF-8. Com certeza o problema esta ocorrendo na tentativa de ler o XML retornado dessa consulta. Ele com certeza possui vogais acentuadas ou cedilha e não esta no formato UTF-8. Você esta usando o Delphi ou Lazarus?

E-mail respondido agora 27/03/23 09:56: Está em discussão no CONFAZ a criação de um campo específico para o PIX, ou de um campo genérico para qualquer forma de pagamento eletrônico. Até que essa alteração seja feita, a orientação é utilizar esse campo também para as demais formas de pagamento eletrônico, e não apenas para pagamento com cartão. Eduardo S. Benazzi Auditor Fiscal da Receita Estadual NAVi - Núcleo de Atendimento Virtual Receita Estadual – RS

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

Bom dia Daniel, já enviei, enviei na sexta.

Isso explica os problemas que estava tendo, a cidade trocou de provedor. Como não temos como testar a emissão para todas as cidades por falta de dados válidos, nesses casos, nós realmente dependemos de contribuição por parte dos usuários para manter o componente atualizado. Muito obrigado pela contribuição, foi criada a #TK-3756 para análise e inclusão no SVN.

Bom dia, segue um pontapé inicial para você estudar para o Lazarus. - Biblioteca Horse: GitHub - HashLoad/horse: Fast, opinionated, minimalist web framework for Delphi - Requisições HTTP/Rest

Bom dia é um falso positivo. mas como esta a msg ai, execute um cleanUp é para resolver

Bom dia @marcelosantos Pelo que vimos aqui no fórum, existem mais pessoas trabalhando com o mesmo banco. Como usuários da comunidade que estão contribuindo não tem acesso a área pro, vamos deixar somente um tópico ativo para acesso de todos que estão colaborando com o projeto deste banco. Tópico que vai ficar ativo:

Olá Diego, Desculpe a demora. Tentei enviar o comando eSocial.DownloadEventos em horários e dias aleatórios e sempre retornava sem erros (OK: [Consulta] Codigo=0 Mensagem= ) porém ao abrir o XML retornado , o erro sempre era o mesmo: <cdResposta>307</cdResposta> <descResposta>Erro ao validar solicitante da informação. Não foi possível estabelecer conexão com o Sistema do CNPJ / CPF. A falha pode ser temporária, tente novamente mais tarde.</descResposta> Como agora no comando eSocial.DownloadEventos tenho que passar pelo menos 2 parâmetros, sendo que eu tenho apenas o IDE do Empregador e normalmente eu nao terei um dos dois outros (ID Evento ou NrRecibo), não vou conseguir usar o comando da forma como imaginei. Desta forma, vou encerrar o chamado, pois vou ter que ver uma outra forma de buscar (ou não) as informações que preciso. Agradeço pelo empenho e profundidade nas respostas, demonstrando mais uma vez a seriedade do trabalho de vocês! Muito obrigado! Sergio

Infelizmente tive que formatar o PC, e ao reinstalar tudo aqui, fiz os teste e já esta funcionando. Acredito que era alguma coisa com a pasta de schema mesmo, mas não consigo dizer o que era. Obrigado a todos pela ajuda.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn, TK-3752. Você pode anexar o manual disponibilizado para este município pelo provedor?

Ola, Veja esse link que pode lhe ajudar

olá colega, se ele está pedindo nrRecibo antes do indAuracao é por tratar-se de Alteração. Caso não seja alteração, veja indRetif se não foi criado erroneamente, mas a mensagem diz respeito a Alteração onde deve informar o nrRecibo. att

Conforme programação prévia, no dia 19/03/2023, ocorrerá o fim do período de convivência das versões S-1.0 e S-1.1 do leiaute do eSocial. A partir do dia 20/03, todos os empregadores deverão adotar a versão mais recente do leiaute, que já está disponível desde 16/01/2023. A versão anterior, S-1.0, será desativada e não poderá mais ser utilizada para o envio das informações. Os empregadores que ainda não atualizaram seu sistema para a nova versão do leiaute do eSocial devem fazê-lo o mais breve possível, para evitar problemas com o envio das informações. Fonte: Fim da convivência das versões do leiaute do eSocial E como fica o ACBr? O componente ACBreSocial e consequentemente o ACBrMonitor e a Lib já estão com as alterações para funcionar com essa nova versão de acordo com os manuais e informações disponibilizadas. Para utilizar é preciso configurar a propriedade VersaoDF como segue: ACBreSocial.Configuracoes.Geral.VersaoDF := veS01_01_00; No ACBrMonitor: Usando ACBrLibeSocial: Utilize o método eSocial_SetVersaoDF passando no parâmetro sVersao a string "S01_01_00"

Alteração enviada a o SVN na Rev-28841. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde a todos, Foi reportado no tópico a seguir que foi homologado com zeros após acionamento do suporte do banco. Podem fazer uma nova homologação com zeros e reportar se o problema foi resolvido?

Boa tarde. tudo bem!? O acbrMonitor é usado pra empresas que não querem desenvolver, ele basicamente faz todo processo, tu só teria que alimentar.. Mas tu tem também todos os fontes disponiveis (o acbr é opensource) e pode utilizar os componentes pra desenvolver o que quiser, ao baixar os fontes, instalar, tu vai ver que tem pasta de exemplos que tu pode se basear pra ir fazendo tudo que precisa... veja mais: https://projetoacbr.com.br/fontes/