Painel de líderes
Conteúdo popular
Showing content with the highest reputation on 29-03-2023 em todas as áreas
-
Boa tarde a todos. Pra quem usa o componente antigo ACBrNFSe, alterei a linha abaixo no ISSNet.ini e a emissão normalizou para a prefeitura de Ribeirão Preto, SP. De: [URL_P] RecepcaoLoteRPS=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx Para: [URL_P] RecepcaoLoteRPS=http://abrasf.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx3 pontos
-
Bom dia... estou conseguindo transmitir normalmente, o provedor é o ISSNet com a versão 2.04, estou usando o wincrypt, fontes atualizados, shemas atualizados, delphi 10.23 pontos
-
Boa tarde. Essa questão está sendo debatida pela equipe ACBr e moderadores, assim que houver novidades, vamos comentar neste tópico.2 pontos
-
se ajudar meu arquivo está ACBrNFSeXServicos.ini assim: [3543402] ; Atualizado em 27/02/2023 Nome=Ribeirao Preto UF=SP Provedor=ISSNet Versao=2.04 ProRecepcionar=https://nfse.issnetonline.com.br/abrasf204/ribeiraopreto/nfse.asmx HomRecepcionar=https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx2 pontos
-
Boa noite Willian, Criada #TK-3766 para análise se isso não afetará outros municípios. Pode disponibilizar os soaps de envio e retorno deste caso ou encaminhar para [email protected] mencionando a TK, se entender que contém dados sensíveis?2 pontos
-
Boa tarde. Como é possível observar no print abaixo, múltiplas Sefaz estão com contingência agendada para o dia 02/04/2023, com previsão de início as 06:30 e término as 12:00 horas. Fonte: Portal da Nota Fiscal Eletrônica Siga as orientações deste tópico para fazer a transmissão em contingência com os componentes do ACBr:2 pontos
-
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.pdf1 ponto
-
Estou preenchendo os dados da entrega e na impressão do FR3 quando a quantidade de caracteres ultrapassa 50 está cortando o restante do endereço. As Tags da entrega são: "xLgr", "nro", "xBairro" e "xMun". Analisando os Fontes, identifiquei que a causa disso é porque o tamanho do campo "EnderecoEntrega" no ClientDataSet "cdsEntrega"no arquivo ACBrSATExtratoFR.pas está com o tamanho 50. Esses são os tamanhos dos campos de acordo com o manual:1 ponto
-
Problema resolvido com esta atualização, grato pelo ajuda.1 ponto
-
Boa tarde Duque de Caxias passou pela mesma alteração, migrei o componente para o TACBrNFSeX, ajustei algumas propriedades que a versao 2.04 pede e tudo voltou a funcionar.1 ponto
-
Boa tarde, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-37771 ponto
-
A cidade de Itauna-MG que usa o mesmo provedor das cidades acima, também alterou a URL: - Itauna-MG: https://abrasf.issnetonline.com.br/webserviceabrasf/itauna/servicos.asmx Apenas a URL foi alterada, a versão e schemas continua a mesma.1 ponto
-
1 ponto
-
Descobri o motivo. Simplesmente o campo ACBrNFSeX1.Configuracoes.Geral.Emitente.CNPJ não estava sendo preenchido. Eu copiei todos os campos do demo, mas por algum motivo justamente esse pelo jeito eu esqueci. É sempre assim, quando trava em alguma coisa é sempre por uma bobeira rsrs. Obrigado a todos que responderam.1 ponto
-
Boa tarde Iago, Vamos ver se eu entendi, mudou a URL mas o XML continua na versão 1 do layout da ABRASF, correto?1 ponto
-
@cdsistemas Boa tarde ! Observei que o sr. esta enviando: "na remessa, os valores de vencimento (17/03/2023) e emissão (15/02/2023) estão corretos. " Mas a data do arquivo arquivo anexado é 27/03/23, eles não vão emitir com data retroativa (15/05/2023). Por favor faça um teste com um datas futuras Exemplo: Data hoje é a data do arquivo q esta gerando vencimento 15/04/2023 emissão a mesma data q esta enviando: 29/03/2023 se for enviar hoje. Pois como hoje é 29/03/2023, no arquivo exemplo do sr.. ja até venceu. 17/03 Aguardo um feedback1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
1 ponto
-
Boa tarde Fiz o teste em ambiente de homologação e deu certo. Somente teremos notas em produção lá pelo dia 10, então se alguém puder fazer o teste e postar aqui o feedback... Mas ficou tudo OK em homologação.1 ponto
-
1 ponto
-
Estava escrevendo, mas ja outro usuario ja postou que deu certo. Vou testar tambem.1 ponto
-
#TK-3770 favor aguardar ir pra fila pra analisar1 ponto
-
Qual a configuração está para a versão do QrCode no seu monitor?1 ponto
-
nota de serviço para Goiânia todos usuários então automaticamente em Homologação, para entrar em produção tem que solicitar para prefeitura, coloque a Serie com TESTE Mesmo em modo PRODUÇÃO é possível efetuar testes. Preencha a tag <serie> do XML com o valor "TESTE" ao consumir o serviço de geração de notas. Assim, o sistema se comportará como se o Prestador estivesse em modo TESTE para esta solicitação em específico.1 ponto
-
Bom dia a todos, Varias cidades atendidas pelo provedor ISSNet migraram da versão 1.00 para a versão 2.04, a titulo de exemplo a cidade de Ribeirão Preto/SP. Favor verificar se nas cidades que vocês estão tendo problemas a questão não é essa (mudança de versão). No site da prefeitura deve conter um manual informando essa mudança com as respectivas URLs de homologação e de produção para a nova versão.1 ponto
-
Bom dia, Somente com a opção Build, vou realizar os outros passos e dou retorno.1 ponto
-
Primeiro de tudo, muito obrigado pela contribuição. Toda contribuição é e sempre será mais do que bem vinda. Sua contribuição foi: Como você percebeu, a "xsMsXml" é a responsável pelo problema. A correção de identificar o NameSpaceURI deve ser implementada nela. Por isso não podemos aceitar essa contribuição no momento. Mas com certeza esse tópico e sua contribuição vão ajudar outros que possam vir a passar pelo mesmo problema, por isso vamos manter aqui.1 ponto
-
sem contar que o SPED tem várias ramificações (ecd, ecf, reinf, contribuições...)1 ponto
-
Bom dia. O seguinte erro acontece ao Emitir nota: "servico_enviar_lote_rps_envio.xsd#/schema The 'http://www.abrasf.org.br/ABRASF/arquivos/nfse.xsd' namespace provided differs from the schema's 'http://www.issnetonline.com.br/webserviceabrasf/vsd/servico_enviar_lote_rps_envio.xsd' targetNamespace". Estava usando a seguinte configuração: NFSe.Configuracoes.Geral.SSLXmlSignLib := xsMsXml Fiz o teste agora mudando para xsLibXml2 e funcionou.1 ponto
-
1 ponto
-
Bom dia pessoal, Agradecemos as informações aqui reunidas até o momento, recentemente houve uma reunião da AFRAC com a SEFAZdo RS a qual visava compreender melhor diversos aspectos desta legislação. Como estamos no meio da AutoCOM ainda não será possível levar estes aspectos a eles, mas nos próximos dias deve ser mais tranquilo. At.1 ponto
-
Bom dia, as alterações necessárias já foram realizadas no componente. Veja: Caso não tenha atualizado seus componentes, oriento realizar atualização e proceder com a recompilação.1 ponto
-
Bom dia, em princípio deu tudo certo, valeu pessoal pela colaboração, atualizamos ontem os fontes e o evento foi testado com "quase" sucesso Ainda deu uma ocorrência na validação dos schemas, mas no código que foi selecionado no tpCR não estava certo no IRRF, até verificamos que no portal do e-social pelo que entendi tem schemas novos disponíveis. Fechando o tópico. Att Ricardo1 ponto
-
Bom dia Renato !!! Obrigado pela dica ... Eu estou usando a Lib... não mudou... mas testei no AcBrMonitorPlus ... e Vc esta certo ... quando coloco 1-nunca imrimir na sai a coluna e fica como o cliente pediu... só não faz na LIb!!!!1 ponto
-
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.1 ponto
-
é no Titulo que tu informa no TipoPagamento conforme a imagem que ele mostrou1 ponto
-
1 ponto
-
Ok. Enviado por Email o Login e Senha para Autenticação do Validador. Obrigado sempre pelo excelente gama de componentes do Projeto ACBr.1 ponto
-
1 ponto
-
Certo. Este primeiro erro, era um erro gerado pelo componente, como foi explicado, ele levanta essa exceção para você porque o método que estava tentando não foi implementado por esse provedor e você foi orientado a usar outro outro método. Este segundo erro era no programa exemplo, conforme deu para ver, era uma questão de Dll. Em ambos os casos, o erro ainda era na sua ponta, o RPS nem chegava ser transmitido para o Webservice. Agora este erro que você recebeu é um erro que lhe foi devolvido pelo Webservice. Ou seja, ele criou o arquivo com o RPS, transmitiu ele para o Webservice, o Webservice devolveu uma crítica desse arquivo com o este erro. Nesse caso, você precisa seguir a orientação da correção e questionar a prefeitura para obter mais informações.1 ponto
-
Bom dia João, São serviços distintos, você pode executar o DistribuicaoDFe da NF-e e logo em seguida o do CT-e. O Consumo Indevido ocorre quando você utiliza o mesmo serviço de forma indiscriminada. Não existe um serviço que retorne o XML da NF-e e o do CT-e. Lembrando que se tratando da NF-e, são 3 passos: 1. Executar o DistribuicaoDFe para obter os resumos das notas; 2. Enviar os eventos de Manifestação do Destinatário mais adequado para cada nota; 3. Executar o DistribucaoDFe para obter o XML completo das notas previamente manifestadas. Por outro lado no caso do CT-e, só existe um passo que é executar o DistribuicaoDFe para obter o XML do conhecimento.1 ponto
-
Você usa o ACBrNFe para consultar NFe modelo 55, e ACBrCTe para consultar CTe, CTe-OS, GTVe, ainda o ACBrMDFe para consultar MDFe. Cada componente usa um serviço DistribuicaoDFe diferente, não é o mesmo endpoint.1 ponto
-
Boa noite, Segue opção. https://github.com/viniciussanchez/dataset-serialize1 ponto
-
Contribuição enviada ao SVN na Rev-28836. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.1 ponto
-
Essa configuração só afeta o DANFE, e só existe para o valor unitário, que pode ter até 10 casas decimais no XML, e quantidade (até 4 casas). A geração do XML pelo ACBr sempre vai usar o máximo de casas decimais permitido para o campo.1 ponto
-
Boa tarde, cheque esses pontos aqui: - Requisição de permissões - Adicionar a linha android:usesCleartextTraffic="true" no AndroidManifest - Nas opções do projeto > Application > Entitlement List > marcar a opção Secure File Sharing. - Aplicar Revert System Files no Libraries1 ponto
-
@cefantacini @Compusofts pelo que andei vendo na nota técnica 2016.002 pag 47: Grupo ICMS60 (id:N08) informado indevidamente nas operações com os produtos combustíveis sujeitos a repasse interestadual (tag:cProdANP) igual a 210203001, 320101001, 320101002, 320102002, 320102001, 320102003, 320102005, 320201001, 320103001, 220102001, 320301001, 320103002, 820101032,820101026, 820101027, 820101004, 820101005, 820101022, 820101031, 820101030, 820101014, 820101006, 820101016, 820101015, 820101025, 820101017, 820101018, 820101019, 820101020, 820101021, 420105001, 420101005, 420101004, 420102005, 420102004, 420104001, 820101033, 820101034, 420106001, 820101011, 820101003, 820101013, 820101012, 420106002, 830101001, 420301004, 420202001, 420301001, 420301002, 410103001, 410101001, 410102001, 430101004, 510101001, 510101002, 510102001, 510102002, 510201001, 510201003, 510301003, 510103001, 510301001 Obs.: Para CST 60 obrigatório o preenchimento do Grupo Repasse de ICMS ST (id:N10b) com o Campo Tributação do ICMS (id:N12) igual a 60 No modelo 55 ( NFe ) fiz alguns testes e vai normal se o ANP não estiver nessa listagem, mais quando se trata da NFCe ( 65 ) mesmo o ANP não estando na listagem ele retorna o mesmo erro: Rejeição: Grupo de Tributação informado indevidamente. Se alguém souber de alguma dica para ajudar como informar essa parte.1 ponto
-
Mudou muita coisa @RicardoVoigt, dá uma olhada na NT.0 pontos