Diego Foliene

Olá pessoal! Como muitos sabem, no dia 01/04/2023 terá início a obrigatoriedade da vinculação dos meios de pagamento ao documento fiscal eletrônico no Mato Grosso. O objetivo deste tópico é reforçar pontos de importância e esclarecer dúvidas a respeito desse processo. Legislação O estabelecimento desta obrigatoriedade veio com o Decreto Nº 599-2023 que trouxe os incisos 11-A, 11-B, 15-A e 15-B que de forma resumida em uma transcrição livre estabelecem que: § 11-A: O comprovante de pagamento deve ser vinculado a NFe mediante integração com o sistema emissor quando o pagamento for por meio de cartão de crédito, débito, pix ou outra maneira de pagamento eletrônica. § 11-B: Fica vedado o uso de equipamento que para processar as operações de pagamento de NFe que não permitam vinculação do comprovante de pagamento mediante integração com sistema emissor. § 15-A: O comprovante de pagamento deve ser vinculado a NFCe mediante integração com o sistema emissor quando o pagamento for por meio de cartão de crédito, débito, pix ou outra maneira de pagamento eletrônica. § 15-B: Fica vedado o uso de equipamento que para processar as operações de pagamento de NFCe que não permitam vinculação do comprovante de pagamento mediante integração com sistema emissor. Na prática o que isso quer dizer? A partir de 01/04/2024, as NFes/NFCes emitidas deverão conter no arquivo a informação que identifique o pagamento, vinculando o mesmo ao respectivo DFe esse processo deverá ser feito de forma integrada na aplicação emissora, ou seja, caso o documento fiscal se encaixe nas categorias que passa a ser obrigatório, não será mais permitido, por exemplo, processar a venda no sistema, pagar na maquininha do cartão e colocar a via no famoso espeto de papel para conferir e contabilizar no sistema no final do dia depois. Agora quando for feita a venda, o software emissor deve enviar o comando de recebimento para o equipamento que vai ser usado para processar o pagamento e deve receber o retorno do mesmo, tratando a informação e vinculando a mesma no documento fiscal. Ou resumindo esse processo em uma palavra TEF. Atividades Obrigadas A princípio, estarão obrigados a realizar a vinculação do meio de pagamento ao documento fiscal eletrônico os estabelecimentos que possuam um dos CNAEs apresentados na lista abaixo, seja ele primário ou secundário: SUBCLASSE CNAE DENOMINAÇÃO DATA INÍCIO OBRIGATORIEDADE 1091-1/02 Fabricação de produtos de padaria e confeitaria com predominância de produção própria (padarias tradicionais) 1°/04/2024 4721-1/02 Padaria e confeitaria com predominância de revenda 1°/04/2024 4752-1/00 Comercio varejista especializado de equipamentos de telefonia e comunicação 1°/04/2024 4755-5/02 Comércio varejista de artigos de armarinho 1°/04/2024 4755-5/03 Comércio varejista de artigos de cama, mesa e banho 1°/04/2024 4763-6/01 Comércio varejista de brinquedos e artigos recreativos 1°/04/2024 4763-6/02 Comércio varejista de artigos esportivos 1°/04/2024 4774-1/00 Comércio varejista de artigos de óptica 1°/04/2024 4781-4/00 Comércio varejista de artigos do vestuário e acessórios 1°/04/2024 4782-2/01 Comércio varejista de calçados 1°/04/2024 5611-2/01 Restaurantes e similares 1°/04/2024 5611-2/02 Bares e outros estabelecimentos especializados em servir bebidas 1°/04/2024 5611-2/03 Lanchonetes, casas de chá, de sucos e similares 1°/04/2024 5611-2/04 Bares e outros estabelecimentos especializados em servir bebidas, sem entretenimento 1°/04/2024 5611-2/05 Bares e outros estabelecimentos especializados em servir bebidas, com entretenimento 1°/04/2024 5620-1/01 Fornecimento de alimentos preparados preponderantemente para empresas 1°/04/2024 5620-1/04 Fornecimento de alimentos preparados preponderantemente para consumo domiciliar 1°/04/2024 A lista pode ser atualizada adicionando novos CNAEs a critério da Sefaz. FAQ - Perguntas e Respostas Algumas das perguntas do FAQ já foram respondidas em explicação acima. Portanto, abaixo segue o reforço de algumas dúvidas pertinentes. Caso ainda haja dúvidas, consulte o material original citado no final. Com a identificação do meio de pagamento, necessária a informação do CPF do consumidor? A legislação da vinculação de pagamentos ao programa emissor não trouxe modificações relacionadas, portanto, no estado, vendas cujo valor seja igual ou maior a R$1.000,00 com entrega em domicílio deverão deverão ter a identificação do consumidor. Um varejista que possua um dos CNAEs listados como obrigados a vinculação dos meios de pagamento ao DFe como atividade secundária deverá adotar a vinculação por integração via software emissor para ambas atividades ou somente as do CNAE secundário? A vinculação dos meios de pagamento com a NFe/NFCe está restrita ao CNAE correspondente da lista, seja ela a atividade primária ou secundária. No entanto, a para esses casos, a adesão do processo de vinculação para ambas atividades é recomendada, visto que a Sefaz MT pode adicionar novos CNAEs na lista a qualquer momento. Em quais operações será obrigatória a observância da vinculação dos pagamentos? Operações de venda ou revenda, cujo pagamento seja feito através de cartão de crédito, débito, PIX ou outro meio eletrônico. Operações realizadas em site ou plataforma digital própria e teleatendimento também devem observar a obrigatoriedade legal. Em ambos os casos, o comprovante da transação, seja impresso ou digital, deve conter: CNPJ e Nome do estabelecimento que está sendo usado o equipamento. Código de autorização ou identificação do pedido. Data, hora e valor da operação. Identificador do terminal que ocorreu a operação nos casos que se aplica. Em quais operações não será obrigatória a observância da vinculação dos pagamentos? Como a legislação trás uma lista de CNAEs em que se dará a obrigação, entende-se que os CNAEs que não se encontram na lista, não precisam adotar esse novo processo(embora como já citado, recomenda-se a movimentação para adequação, visto que a Sefaz MT pode ampliar a lista). Além disso, a determinação legal não se aplica para: operações com a emissão da NFC-e através do Regime Especial da Nota Fiscal Fácil – NFF. operações de venda não presencial intermediada em site ou plataforma de terceiros;(Lembrando que quando for site ou plataforma próprios, a obrigação é observada). Delivery com pagamento no domicílio do consumidor.(Ainda assim, o nome e o endereço do estabelecimento devem ser impressos no comprovante). Contribuintes enquadrados como MEI. Como deverá ser observada a legislação nos casos de pagamentos de venda a prazo ou pagamentos que não estão atrelados à circulação de mercadorias (recarga de celular, vale-presente, pagamento de energia elétrica, pagamentos de carnê/crediário, dentre outros)? A referida legislação se aplica a operações de venda e revenda de mercadorias, portanto operações que não se enquadrem nesta categoria, como por exemplo, o pagamento de uma conta de energia ou uma recarga de celular não se aplicam a legislação em questão. O ECONF deverá ser usado nos casos da pergunta anterior? O ECONF ainda se encontra em análise e deve ser tratado em NT com previsão de lançamento futura. Na venda a crediário/carnê o cliente recebe a NFC-e no momento da compra. Quando ele paga, nos próximos meses, as parcelas com cartão de débito, como proceder? Pois a NFC-e já foi emitida meses antes. Ele pode pagar no cartão de débito, sem emissão da NFC-e, uma vez que ela já foi emitida anteriormente? Caso a parcela seja paga via cartão ou PIX, quando for disponibilizado, deverá ser usado o ECONF para o caso citado. Como ficam os pagamentos realizados através de nota fiscal de serviço que são geradas no site da prefeitura? A legislação citada se aplica a Nota Fiscal Eletrônica(NFe) e a Nota Fiscal de Consumidor Eletrônica(NFCe), não tendo efeito sobre a Nota Fiscal de Serviço Eletrônica(NFSe). Caso seja possível que o "POS" gerar um QrCode e o sistema faça a leitura para inserção das informações no XML da NF-e/NFC-e? A interligação via leitura de QrCode será admitida como interligação tecnológica? O QrCode com as informações do pagamento eletrônico efetuado, desde que devidamente capturado pelo sistema de automação e preenchido no XML é sim considerado uma interligação válida. É obrigatória a impressão do comprovante de pagamento eletrônico no mesmo dispositivo que irá imprimir o DANFE da NF-e/NFC-e? A legislação do MT não prevê isso, portanto, não. Como proceder em casos que o pagamento no ato, mas dividido. Por exemplo, quando amigos dividem a conta em um restaurante? O documento fiscal eletrônico permite a vinculação de até 99 pagamentos, portanto, caso opte-se por emitir apenas uma nota, ambos pagamentos deverão ser vinculados. Mas não há nada que impeça a emissão de uma nota para cada pagamento também. Como proceder nos casos em que o documento fiscal for emitido em contingência devido a problemas locais como falta de internet? O equipamento que vai recepcionar as operações de pagamento eletrônico deve estar vinculado ao programa emissor do documento fiscal. Sendo assim em caso de falhas de integração, existe possibilidade técnica de interligação sistêmica através de bluetooth, wi-fi ou link de internet alternativo para o correto fluxo da operação. Na prática, quais campos devem ser preenchidos nas operações? Pagamento com cartão de débito ou crédito. Meio de pagamento (tPag) correspondente ao cartão utilizado campo . Valor do pagamento (vPag) preenchido com o valor da operação. Tipo da Integração (tpIntegra) preenchido com o valor 1 que corresponde a "Pagamento Integrado com o Sistema de Automação". No campo CNPJ informar o valor homônimo da Instituição de Pagamento, seja adquirente ou subadiquirente. No Número de autorização da operação com cartões, PIX, boletos e outros pagamentos eletrônicos (cAut) deve ser informado o Código de Autorização da Transação. No campo CNPJReceb informar o CNPJ do estabelecimento beneficiário. No campo idTemPag informar o Id do terminal em que foi feito o pagamento. Pagamento com PIX. Meio de pagamento (tPag) correspondente ao PIX. Valor do pagamento (vPag) preenchido com o valor da operação. Tipo da Integração (tpIntegra) preenchido com o valor 1 que corresponde a "Pagamento Integrado com o Sistema de Automação". No Número de autorização da operação com cartões, PIX, boletos e outros pagamentos eletrônicos (cAut) deve ser informado o Código de Identificação do PIX, ou seja, o endToEndId. No campo CNPJReceb informar o CNPJ do estabelecimento beneficiário. No campo idTemPag informar o Id do terminal em que foi feito o pagamento. Nas operações não presenciais, em site ou plataforma de terceiros. No campo Indicador de Presença do Comprador (indPres) informar o valor equivalente a operação em questão, podendo ser 2 para operação não presencial pela internet, 3 para operação não presencial teleatendimento ou 4 para NFCe com entrega em domicílio. Em CNPJ, informar o do intermediador da transação. Em idCadIntTran informar o identificador cadastrado oo intermediador da transação. Como o ACBr pode me ajudar? Clique AQUI para entender as vantagens e benefícios de se tornar um parceiro ACBr TEF x PayGo. Disclaimer Este tópico foi construído se baseando nas informações do Portal do Conhecimento Sobre a Integração entre NFC-e e Meios de Pagamento Eletrônicos que foi construído em uma parceria entre a Sefaz MT e a AFRAC. Recomendamos também a leitura das informações no Portal para um entendimento mais amplo da situação.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico. Aqui tem o Modelo PIXCD.INI - Criar Cobrança Imediata para que possa se basear.

Boa tarde! Muito obrigado pela contribuição. Nesta linha o @antonio.carlosestá dizendo que as alterações foram enviadas ao SVN. Por favor, queira atualizar seus fontes e realizar novo teste.

Tópico vinculado a TK mencionada.

Olá pessoal! No dia 07/03/2024 foi publicado um comunicado avisando com antecedência sobre a atualização da URL do QrCode presente na NFCe para o estado da Paraíba. Atualmente, a URL nova e antiga estão coexistindo, mas a partir do dia 01/04/2024, somente a URL nova (http://www.sefaz.pb.gov.br/nfce) será considerada. O comunicado informa ainda que um terço das NFCe emitidas ainda estão utilizando a URL antiga. As soluções ACBr já fazem uso da nova URL conforme pode ser visto em ACBrNFeServicos.ini: [NFCe_PB_P] Usar=NFCe_SVRS_P URL-QRCode=http://www.sefaz.pb.gov.br/nfce ;... [NFCe_PB_H] Usar=NFCe_SVRS_H URL-QRCode=http://www.sefaz.pb.gov.br/nfcehom ;... Leia o comunicado na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Fernando Di Pace por compartilhar a informação em nosso Discord.

Obrigado pela análise. Foi criada a #TK-5185 para análise do caso e parecer por parte da equipe de consultores.

Olá pessoal! No dia 07/03/2024 foi publicado o Informe Técnico 2024/001 que divulga atualização na tabela de NCM a partir de 01/04/2024, 01/07/2024 e 01/08/2024. Este informe trás as seguintes alterações na Tabela de NCM divulgada na NT2016/001 - v3.70: O término da vigência do código NCM 02071400 foi alterado para 31/07/2024. O início da vigência dos códigos NCM 02071411, 02071412, 02071413, 02071419, 02071421, 02071422, 02071423, 02071424, 02071429, 02071431, 02071432, 02071433, 02071434 e 02071439 foi alterado para: 01/08/2024. Extingue o código NCM 85045000 a partir de: 30/06/2024. Inclui os códigos de NCM 48119020, 85045010 e 85045090 a partir de: 01/07/2024. As demais alterações impostas na versão 3.70 continuam mantidas, sendo elas: Extinção dos códigos de NCM 27109100, 28201000, 28273998, 29299021, 29299022, 29299029, 29314930, 29398000, 30024993, 39072990, 39172200, 48119010, 74094010, 85059010, 85441910 e 90029000 a partir de: 31/03/2024. Inclusão dos códigos de NCM 27109110, 27109120, 27919190, 28201010, 28201090, 28273931, 28273939, 28439040, 29299031, 29299039, 29299040, 29299050, 29299060, 29314931, 29314932, 29314939, 29315995, 29315996, 29315998, 29333936, 29333941, 29333942, 29398010, 29398090, 38249961, 38249962, 38249969, 39072991, 39072999, 39172210, 39172290, 48119011, 48119019,74094011, 74094019,84502020, 85043193, 85059011, 85059019, 85441911, 85441919, 90029010 e 90029090 a partir de: 01/04/2024. A partir de agora, as alterações de NCM serão divulgadas por meio de Informe Técnico e não mais Nota Técnica. Leia o Informe na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Rafael - ATS Informática por compartilhar a informação em nosso Discord.

Olá pessoal! Foi publicado na página Sobre o SAT aviso informando que no dia 08/03/2024, no período das 14h00 até às 16h00 haverá uma manutenção emergencial que poderá afetar as ativações de equipamentos SAT. A Sefaz indica que ativações de novos equipamentos sejam feitas fora deste período. Um agradecimento ao membro de nossa comunidade @marcopoloviana por compartilhar a informação em nosso Discord.

Por favor, como você fez a chamada no método? O log demonstra que não foram passados para ele os parâmetros correspondentes. O comando PIXCD_GerarQRCodeEstatico tem a estrutura: PIXCD_GerarQRCodeEstatico(Valor, InformacoesAdicionais, TxId);

Olá pessoal! No dia 06/03/2024 foi divulgada a versão 1.50 da Nota Técnica 2020/001. A nova versão visa atender ao que foi disposto no Ajuste Sinief 43/23, mais especificamente o § 2º da cláusula décima quinta-C. Permitindo agora que os eventos de manifestação conclusivos, sejam eles Confirmação da Operação, Desconhecimento da Operação ou Operação Não Realizada possam ser registrados até duas vezes, sendo válido apenas o último registro. Então agora, conforme exemplo dado na própria NT, o destinatário pode confirmar uma operação, depois desconhecê-la e por fim confirmá-la novamente. É importante reforçar que o envio desses eventos devem ocorrer dentro do prazo de 180 dias a partir da data de emissão da NFe. A regra de validação da rejeição 594 foi alterada e passa a vigorar com a seguinte redação: Previsão de Implementação por parte da Sefaz Implantação Teste: 01/07/2024 Implantação Produção: 01/08/2024 Para quem utiliza as soluções ACBr, não precisa se preocupar com alterações, visto que é alteração do lado da SEFAZ/AN 91. Porem um ponto de atenção : Sistemas de monitoramento podem gerar conflitos de eventos, visto que o documento foi confirmado, depois houve o registro de operação não realizada pelo operador do sistema, caso algum sistema passar registrando o evento automático, por exemplo sistema de busca de XML e registrar novamente o evento de confirmação da operação, agora a SEFAZ irá acatar o evento novamente, não retornando duplicidade de registro de evento. E a validade é do ultimo evento conclusivo registrado. Então é importante que verifiquem se não há ferramenta que possa estar consultando em concorrência realizando a manifestação automaticamente antes da consulta. Leia a NT na íntegra AQUI.

As soluções ACBr para emissão de Nota Fiscal de Serviço Eletrônica abstraem ao máximo as diferenças entre as implementações dos diversos provedores. Mesmo fazendo isso, alguns padrões precisam ser determinados. Por exemplo, a solução espera enviar e receber um arquivo no formato XML. Mas existem provedores por exemplo que devolvem simplesmente. <?xml version="1.0" encoding="UTF-8"?>You do not have permission to view this directory or page. Vejam que isso não é um arquivo XML válido. Em casos como esse a solução tenta ler o retorno esperando um XML válido, encontra isso e devolve o erro: Mas então o que eu posso fazer neste caso? A primeira coisa a se fazer ao receber este erro é conferir qual é o conteúdo do arquivo de retorno, pois é alta probabilidade de que o mesmo tenha um conteúdo em formato inválido ou erro não previsto. O mais indicado é que se confira no arquivo -soap, que é o retorno completo devolvido pelo web service. No tópico abaixo tem orientações de como configurar para que seja gerado estes arquivos: Conferindo nesses arquivos, fica mais fácil para você e também para a equipe ACBr entender qual foi o erro e determinar qual é o curso de ação a ser tomado.

Bom dia! Apenas para desencargo, por favor, tente efetuar um teste usando o método de consulta manualmente após usar o método de envio e veja se ele lhe devolve todas as informações.

Temos um exemplo em Node.js em nosso SVN. Por favor, pode realizar um teste com o mesmo?

RPS/DPS O que é RPS e DPS? A sigla RPS significa Recibo Provisório de Serviço. Diferente do processo de emissão de outros DFes, onde é gerado o XML do respectivo DFe e o mesmo é enviado para validação e aceitação do web service, na emissão de Nota Fiscal de Serviço(NFSe), é o web service quem gera o XML da NFSe. Ou seja: No caso do Padrão Nacional, é chamado de "Declaração de Prestação de Serviço" (DPS). E apesar da diferença no nome, sua função e lógica é basicamente a mesma do RPS, ou seja, o prestador gera um XML de DPS, envia o mesmo para a API do Padrão Nacional e em caso de sucesso, o DPS é convertido em NFSe e o XML da mesma é devolvido para o prestador. Por que não existe quando emito direto pela prefeitura? O RPS só faz parte do processo de emissão quando o mesmo é feito através de um web service. Quando a emissão é feita pelo site da prefeitura(quando existe a opção), o RPS é inexistente. É importante entender que o processo de emissão para NFSe é diferente quando feito através do site da prefeitura e quando feito via web service. Muitas vezes, são usuários diferentes para o site e para o web service, existindo casos em que mesmo no web service os usuários dos ambientes de homologação e produção são diferentes. PROVEDORES O que é um provedor? Provedor é nome dado as empresas que fornecem o web service com o serviço de emissão de nota para as administrações municipais. Diferente de outros DFes, a nota de serviço tem sua tributação em nível municipal. Por isso, não há, por exemplo, uma Sefaz para cuidar dos serviços de emissão. Para se ter uma ideia, já passamos da marca de 130 provedores implementados na solução de emissão de nota de serviço do ACBr. Leiaute ABRASF e Leiaute do próprio? Devido ao fato de ser algo a nível municipal, não há uma padronização de leiaute na formação dos arquivos XML de RPS e de NFSe. O leiaute ABRASF foi uma sugestão de padronização feita pela entidade no início do projeto da Nota de Serviço. Alguns provedores implementaram seus web services seguindo tal padrão, no entanto, ainda assim existem provedores que apesar de seguir o leiaute, implementaram particularidades próprias. Há também provedores que não seguiram a sugestão e criaram um leiaute próprio completamente diferente. Temos provedores em que é possível enviar um lote de até 50 RPS e temos provedores em que o envio é unitário. É importante lembrar que apesar desta falta de padronização por parte dos provedores no que diz respeito a implementação da emissão de NFSe, as soluções ACBr procuram abstrair ao máximo essas particularidades, simplificando o processo de emissão da melhor forma possível. HOMOLOGAÇÃO Como saber se minha cidade é atendida? Para verificar se sua cidade é atendida basta buscar pela mesma no arquivo ACBrNFSeXServicos.ini que acompanha todas as soluções de emissão de Nota de Serviço do ACBr. Caso haja informação de provedor atribuída, é possível realizar emissão para a mesma. Vejam um exemplo: [3550308] Nome=Sao Paulo UF=SP Provedor=ISSSaoPaulo ProRecepcionar=https://nfe.prefeitura.sp.gov.br/ws/lotenfe.asmx ProLinkURL=https://nfe.prefeitura.sp.gov.br/nfe.aspx?ccm=%InscMunic%&nf=%NumeroNFSe%&cod=%CodVerif% HomLinkURL=https://nfe.prefeitura.sp.gov.br/nfe.aspx?ccm=%InscMunic%&nf=%NumeroNFSe%&cod=%CodVerif% Se minha cidade não for atendida, o que fazer? Mesmo que não haja informação de provedor atribuída para a sua cidade, a adição da mesma é bem simples. Basta entrar em contato com a prefeitura questionando qual é o provedor que atende a cidade para emissão de notas de serviço, quais são suas URLs e adicionar estas informações no arquivo ACBrNFSeXServicos.ini. Veja o tópico abaixo para uma explicação do procedimento para realizar essa inclusão é explicado em detalhes. Recebi os erros "Não informada a URL de Homologação, entre em contato com a prefeitura" e "Serviço não implementado para este provedor". E agora, o que eu faço? Conforme foi citado anteriormente, não há uma padronização por parte dos provedores na forma como implementam seus web services de emissão de nota de serviço. Isso significa que nem todos os métodos implementados por um provedor estarão disponíveis para outro. Até mesmo a existência do ambiente de homologação não é uma constante. Veja o tópico abaixo para uma explicação mais detalhada sobre ambas as mensagens(e mais algumas outras) com sugestões do que pode ser feito caso se deparem com elas. Quais são as formas de homologar? Por mais estranho que possa parecer, a falta de uma URL de homologação, nem sempre significa que não é possível fazer testes de emissão e que se tenha de partir direto para produção. Alguns provedores usam uma informação enviada no XML do RPS para diferenciar o ambiente, enquanto outros possuem método específicos para teste. Confira o tópico abaixo para uma explicação detalhada das diferentes possíveis formas de se homologar uma nota fiscal de serviço. É importante entender que mesmo que a princípio as soluções ACBr não atendam a uma cidade específica a adição da mesma é um processo simples de ser efetuado. Ainda que não haja ambiente de homologação para testar a emissão de notas, existem outras formas de se testar. FLUXO DE ENVIO O que é o parâmetro do modo de envio e para que ele serve? A emissão de uma nota de serviço via web service pode ser feita de maneira síncrona ou assíncrona dependendo de como foi implementado pelo provedor. O parâmetro modo de envio define para a solução ACBr qual dos dois será utilizado. Uma dica para este caso é fazer uso do parâmetro meAutomatico, para que a própria solução se encarregue de decidir qual é o modo mais apropriado. Qual é o exemplo de um fluxo de emissão? Para o envio de forma síncrona o retorno da tentativa de emissão já é o XML da NFSe em caso de sucesso e os erros caso alguma coisa precise ser corrigida. Para o envio de forma assíncrona, podemos definir em: Emissão No retorno da emissão é devolvido um número de protocolo. Consulta da situação do lote. É devolvido um número representando a situação atual, sendo: 1 - Protocolo consultado inválido, 2 - Lote em processamento, 3- Lote processado com erros e 4 - Lote processado com sucesso. Quando a situação for 3 ou 4 é feita a consulta do lote. Consulta do lote para pegar os erros em caso de falha ou o XML da NFSe em caso de sucesso. O fluxograma abaixo também demonstra o envio de forma assíncrona. E se der TimeOut no meio disso? Em caso de erro de Time Out, antes de fazer novo envio, correndo risco de uma emissão duplicada, é importante realizar consulta pelo RPS para ter certeza de que a nota foi emitida e o Time Out não ocorreu no retorno. Erros começando em E, L e X? Erros iniciados em X são próprios da solução ACBr e geralmente são referentes a validações prévias, alertando sobre informações obrigatórias que não foram preenchidas ou erros internos. Erros iniciados em L ou E são devolvidos pelo web service do provedor. É importante levar em consideração essa diferença de fluxo entre os modos de envio quando for implementar sua rotina de emissão de nota. IMPRESSÃO Tentei imprimir um XML de RPS e não saiu todas as informações, por que? A rotina de leitura e impressão esperam receber um XML de NFSe para o seu correto funcionamento. Como o XML do RPS é posteriormente convertido para o da NFSe algumas das tags lidas coincidem em nome e por isso não ocorre erro na rotina, mas como o XML do RPS não tem todas as informações, o impresso também não vai ter. O leiaute de impressão da solução ACBr é diferente do que vem no site da prefeitura? O impresso da solução ACBr foi idealizado visando atender ao máximo possível as diversas demandas, no entanto, são mais de 5.000 municípios brasileiros e não a nada que impeça que cada um crie um impresso próprio. Por isso é impossível atender a todas as demandas. PADRÃO NACIONAL O que é? Quem deve usar? Quem pode usar? O Padrão Nacional é uma iniciativa que visa trazer ordem a este ambiente caótico de diversos provedores. Nele, o ambiente nacional é o responsável único por fornecer um web service de emissão e os XMLs são criados seguindo leiaute único independente da cidade. Desde o dia 01/09/2023, os prestadores de serviço que são MEI estão obrigados a emitir suas NFSes pelo Padrão Nacional, independente da cidade. Fora isso, para que um prestador possa emitir utilizando o Padrão Nacional, a administração tributária a qual faz parte precisa ter optado pela completa adesão. Na "Lista de Municípios Aderentes" encontram se as cidades que aderiram e qual foi o tipo de adesão. Como emitir nota no Padrão Nacional usando as soluções ACBr? Para emitir NFSe no Padrão Nacional usando as soluções ACBr, basta configurar a cidade, o leiaute para a opção Padrão Nacional e seguir o processo de emissão normalmente. Este tópico tem mais detalhes: Este tópico foi montado baseado a seguinte edição do Papo PRO:

Olá pessoal! Foi divulgada a versão 1.01 desta Nota Técnica 2024/001. A nova versão adiciona no leiaute do evento de encerramento um campo para indicar quando o encerramento for registrado pelo transportador terceiro.(indEncPorTerceiro). O mesmo deve ser preenchido com o valor 1 quando o transportador que estiver emitindo o evento de encerramento for diferente do emitente. As datas de entrada em vigor permaneceram as mesmas (11/03/2024 para homologação e 08/04/2024 para produção). A adição do campo foi enviada ao SVN e portanto, já se encontra disponível nos fontes mais atuais. Um agradecimento ao membro de nossa comunidade @Datacamp por chamar atenção em nosso Discord a respeito da nova versão. Leia a versão 1.01 na íntegra AQUI.

Boa tarde! Por favor, configure SalvarWS como Sim e defina um PathSalvar no seu arquivo ACBrLib.ini; Feito isso, repita o teste. O resultado será o mesmo, mas ele vai gerar para você os arquivos de envelope da processo. Eles são os arquivos que são enviados para o web service e a resposta do mesmo. Todos eles vão ter -soap no nome. Envie-os para [email protected] com o link do tópico no fórum no corpo do e-mail para posterior idenfiticação. A princípio, a Lib já está com a alteração que devolve o XML. Vou analisar os arquivos que disponibilizar e fazer testes com os mesmos.