Italo Giurizzato Junior

Boa tarde Thiago, Esse problema esta ocorrendo com a sua aplicação ou com o programa exemplo?

Boa tarde Diego, Já inclui na minha lista de tarefas.

Boa tarde Djean, Todos os fontes de todas as pastas foram atualizados e a suíte ACBr foi reinstalada? Não tem nenhuma unit do ACBr perdida em alguma pasta que o Delphi tem acesso?

Boa tarde Valdir, Estamos canalizando todos os nossos esforços no novo componente, portanto não estamos mais dando manutenção no antigo. Se não me falha a memória ontem enviei alguns ajustes no novo componente referente ao provedor IPM. Por favor atualize os fontes e faça novos testes com o novo componente. Me parece que esse provedor andou alterando algumas coisas em seu webservice, isso explica de antes funcionar e agora não funciona.

Boa tarde Jorge, Enviado para o SVN uma possível correção, favor atualizar os fontes e faça novos testes.

Boa tarde, Se a descrição de algum serviço não for impressa no DANFSE o problema pode ser que o código do serviço não consta da tabela interna do componente. No XML em anexo me parece que o código do serviço é 2919, na unit ACBrNFSeXConversao - função CodItemServToDesc não temos esse código, veja: 2801: r := 'Servicos de avaliacao de bens e servicos de qualquer natureza.'; 2901: r := 'Servicos de biblioteconomia.'; 3001: r := 'Servicos de biologia, biotecnologia e quimica.'; Dentro da pasta que contem o programa exemplo temos o arquivo TabServicos.txt Que também não tem, veja: 2801 Servicos de avaliacao de bens e servicos de qualquer natureza. 2901 Servicos de biblioteconomia. 3001 Servicos de biologia, biotecnologia e quimica. Mas nada impede de você incluir o código e a descrição do mesmo no arquivo TXT e salvar ele na mesma pasta do executável. Se desejar usar a tabela externa não esqueça de configurar a propriedade TabServicosExt com o valor True.

Boa tarde Guto, Primeiro vamos conceituar essas coisas. 6.1. Conceito de operação com intermediador da transação Os Ajustes SINIEF 21/2020 e 22/2020 introduziram a exigência da identificação do intermediador da transação comercial na NF-e e NFC-e. Sendo assim, foram criados 4 campos na NF-e/NFC-e, sendo eles: indIntermed (B25c), infIntermed (YB01), CNPJ (YB02) e idCadIntTran (YB03). O campo Indicador de intermediador/marketplace (indIntermed) é uma “flag” utilizada para o emitente da NF-e/NFC-e declarar quando a operação/venda ocorreu em site/marketplace ou plataforma de terceiro. Quando declarado que a operação for intermediada (indIntermed=1) será necessário informar os campos do grupo infIntermed (YB01): CNPJ (YB02) e idCadIntTran (YB03). Caracteriza-se venda com intermediador (indIntermed=1), quando o vendedor/emitente da NF-e/NFC-e (CNPJ14) for diferente do CNPJ14 do site/marketplace ou plataforma que realizou a venda. Em algumas situações, a venda/operação pode ocorrer com mais de um marketplace/intermediador, por exemplo quando o “Vendedor A” anuncia no “Marketplace M1” e este anuncia no “Marketplace M2”. Nesse caso, na hipótese do “Marketplace M1” ter enviado a informação para o “Vendedor A”, na NFe deve ser informado o CNPJ do “Marketplace M1”. Em resumo, independente da cadeia de plataformas envolvidas, deve-se informar o CNPJ do intermediador (campo YB02) de quem que enviou a informação da venda para o vendedor/emitente da NF-e/NFC-e. 6.2. Diferença entre CNPJ do Intermediador e CNPJ da instituição de pagamento Não se deve confundir o CNPJ do intermediador da transação (YB02), com o CNPJ da instituição de pagamento (YA05). Porém, em algumas situações poderá ser o mesmo CNPJ. Por exemplo: caso o intermediador da transação seja o responsável por fazer o pagamento ao vendedor (emitente da NF-e), deve ser informado no campo CNPJ da instituição de pagamento o CNPJ do intermediador. Portanto, para efeitos do CNPJ da instituição de pagamento, deve ser informada a instituição/empresa que fez o repasse de pagamento para o vendedor/remetente. Em outras palavras, o CNPJ do adquirente, subadquirente, intermediador ou instituição similar que efetuou o pagamento ao vendedor. Respondendo a sua pergunta: No meu entendimento o CNPJ do Magazine Luiza deve constar na tag CNPJ do grupo <infIntermed> pois é ele que é o intermediador. E o CNPJ do Magalu Pagamentos deve constar na tag CNPJ do grupo <card> pois é ele que responsável pelo pagamento. Todo caso você pode confirmar com o pessoal do Magazine Luiza/Magalu que eles estão por dentro do assunto, uma vez que toda reunião que ocorre entre Fisco e Empresas eles estão presentes.

Bom dia, Se você esta enviando um lote contendo 600 eventos, conforme consta no Schema de Lotes a quantidade máxima é de 100, veja: <xs:element name="loteEventos"> <xs:annotation> <xs:documentation>Contém a relação de eventos que compõe o lote.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="1" maxOccurs="100"> <xs:element name="evento" type="TArquivoeReinf"/> </xs:sequence> </xs:complexType> </xs:element> Isso explica o erro. Quando você envia um lote com até 50 evento o erro não ocorre pois a quantidade esta dentro da faixa de 1 até 100.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Thiago, Você atualizou todos os fontes de todas as pastas? Não tem nenhuma unit com uma bolinha vermelha em seu ícone? Se sim, deleta essas unit e atualize novamente. Depois reinstale a suíte ACBr. Verifica também se não existe cópia de units em outras pastas que o Delphi tem acesso.

Boa tarde Italo, Por favor utilize o novo componente, não estamos mais dando suporte ao componente antigo.

Boa tarde a todos, O ENCAT / SEFAZ tem essa mania de estipular um tamanho para os campos e esquecem do DANFE e suas limitações físicas. No meu entendimento a impressão do valor deveria estar alinhada a direita, desta forma deixando o maior espaço possível a esquerda. Mas essa alteração talvez não seja suficiente para resolver o problema.

Boa tarde Jorge, Mas esse XML de retorno só contem uma mensagem de erro se referindo a alíquota que esta errada. Não entendi o que esse retorno tem haver com o NotasFiscais.Items.

Boa tarde, Acabei de fazer o seguinte teste: 1. Reinstalei a suíte ACBr no Delphi 7; 2. Compilei o programa exemplo com a opção Build; 3. Fiz um teste de envio de Rps. Não ocorreu esse erro de UTF-8. Como esse tópico esta com assuntos misturados, vou fechar ele. Lembre-se que sempre criar um novo tópico para um assunto novo, mas antes pesquise, pois pode ser que já exista uma tópico tratando do mesmo assunto do mesmo provedor.

Boa tarde, Favor atualizar os fontes e faça novos testes.

Boa tarde Djean, Favor atualizar os fontes e faça novos testes.

Boa tarde a todos, Favor atualizar os fones e façam novos testes.

Boa tarde Italo, Procure sempre anexar os XMLs de envio e de retorno, principalmente quando ocorrer algum erro, assim fica mais fácil analisar.

Boa tarde, O componente não se utiliza dos schemas para validar os XMLs retornados, apenas para os XMLs a serem enviados. O que vem a ser "um lote grande" ?

Boa tarde Gil Já esta no SVN.

Bom dia Paulo, Favor atualizar os fontes e faça novos testes.

Bom dia, Você chegou a atualizar todos os fontes de todas as pastas e reinstalou o ACBr com a opção de apagar arquivos antigos marcada? Foram feitas algumas alterações em diversos fontes visando a leitura e gravação correta dos XMLs quando estes possuem vogais acentuadas e cedilha (principalmente nos retornos).

Bom dia Thiago, Favor fazer uma cópia da sua alteração, apague a unit alterada e faça a atualização dos fontes. Por fim faça novos testes.

Bom dia Jorge, Favor anexar o XML de retorno para que eu possa analisar essa questão dos Items.

Bom dia Clóvis, O provedor Sudoeste já esta implementado no novo componente: ACBrNFSeX. Agora basta realizar os testes.