Painel de líderes

COORDENAÇÃO TÉCNICA DO ENCAT 23/03/2020 Adiamento Regras de Validação da NT do MDF-e Integrado - COVID-19 Comunicamos que as regras de validação restritivas da NT 2020.001 MDF-e integrado foram adiadas para 06 de julho de 2020 devido as dificuldades adicionais impostas pela pandemia do COVID-19. O evento de pagamento e as demais alterações de schema da NT, como são opcionais, terão sua data mantida em 06 de abril de 2020. FONTE: https://dfe-portal.svrs.rs.gov.br/Mdfe/Avisos/1075

Bom dia Pessoal, Foi publicado a versão 1.04 da Nota Técnica 2020/001 - MDF-e Integrado. A única alteração se refere a duas regras de validação que tiveram as suas datas de ativação postergadas. Abaixo as regras: Resumo: v1.04 - Adiamento para 06/07/2020 das RV´s 725 e 726 em produção em virtude do COVID-19. Schema e evento de pagamento (opcionais) entram na data original da NT 06/04/2020

Olá Pessoal, Foi publicado ontem (23/03/2020) a resolução 5.876 em anexo: RESOLUCAƒO N. 5.876, DE 20 DE MARC‡O DE 2020.pdf Resumo: 1. Prorrogar, até 31 de julho de 2020, a validade dos certificados do Registro Nacional de Transportadores Rodoviários de Cargas - RNTRC; 2. Suspender, até 31 de julho de 2020, a aplicação da alínea "d" do inciso I do artigo 6º (relação de veículos, devidamente cadastrados na frota da ETC junto ao RNTRC, acompanhada dos respectivos Certificados de Inspeção Técnica Veicular Periódica - CITV); da alínea "e" do inciso II do artigo 6º (relação de veículos, devidamente cadastrados na frota da ETC junto o RNTRC, acompanhada dos respectivos Certificados de Inspeção Técnica Veicular Periódica - CITV); do inciso V do §2º do artigo 16 ( cópia do Certificado de Inspeção Técnica Veicular Periódica - CITV); do inciso IV do §2º do artigo 19 ( cópias do CITV´s); e a exigência de Certificado de Inspeção Técnica Veicular - CITV; 3. Suspender, até ulterior Deliberação da ANTT, as obrigações e penalidades relacionadas ao cadastramento da Operação de Transporte, com a consequente geração do CIOT, para as contratações que não envolverem TAC e TAC-Equiparado.

Ok Daniel. Obrigado pelo rápido retorno. Estou me esforçando para concluir essa transição sem muito transtorno. Grato pelo suporte.

Bom dia Ítalo, Verificando aqui, na unit ACBrMDFe e as que são chamadas através dela estão como nos fontes do ACBr mesmo. Mas vou verificar a possibilidade de compartilhar nossas alterações. Quanto ao prolema, consegui resolver, estava informando incorretamente a tpComp e vComp e passei a informar: compCollectionItem := detEvento.infPag.Items[0].Comp.New; compCollectionItem.tpComp := StrToTComp(ok, 'valor'); compCollectionItem.vComp := valor; Obrigado

não devemos fazer isso... ele fica, por motivo de retrocompatibilidade...

Olá pessoal, Conforme Decreto 384/2020 o valor da regra abaixo para MT passará para R$ 1.000,00, a partir de 01/04/2020: W16-40 (NT 2015.002) Valor Limite (Teto) do total da NFC-e sem identificação do destinatário Obs: informamos que é necessário o preenchimento de todos os dados do contribuinte.

Boa tarde Eduardo, Não, somente aqueles que se referem ao manual. Eu faço da seguinte forma: // (AC,AL,AP,AM,BA,CE,DF,ES,GO,MA,MT,MS,MG,PA,PB,PR,PE,PI,RJ,RN,RS,RO,RR,SC,SP,SE,TO); // (12,27,16,13,29,23,53,32,52,21,51,50,31,15,25,41,26,22,33,24,43,11,14,42,35,28,17); case rgTipoEmissao.ItemIndex of 0: ACBrCTe.Configuracoes.Geral.FormaEmissao := teNormal; 1: ACBrCTe.Configuracoes.Geral.FormaEmissao := teFSDA; // Contingencia FSDA 2: if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCRS else ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCSP; end; No caso do EPEC devemos utilizar o teDEPC pois ele gera o valor 4 na tag <tpEmis>

Opa bom dia. O provedor CENTI tem o campo de IssRetido diferente dos demais padrão, Segue em anexo dois rps enviado para o provedor, no caso o usuário não sabia que o seu cliente tinha que reter iss então envio tudo como normal, ai o CENTI retornou as nfs xml com a informação porém o padrão é outro, ajustei nos fontes aqui no meu aparentemente deu certo. Segue em anexo os 2 xml enviados e 2 xml recebidos e os dois fontes alterados. NFS-cliente-com-retencao-rps-enviado.xml NFS-cliente-com-retencao-xml-recebido.xml NFS-cliente-sem-retencao-rps-enviado.xml NFS-cliente-sem-retencao-xml-recebido.xml pnfsNFSeR.pas pnfsConversao.pas

Removi a pasta fonte e pacotes e puxei tudo novamente no SVN. Rodei o instalador e gerou o problema, anexei o arquivo para que possa ser olhado caso necessite. log_Delphi_XE5_Win32.txt

Boa tarde Marcos, Muito estranho. Você esta usando o componente ACBrMDFe, correto? Esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Esta enviando para o ambiente de homologação, correto?

Eduardo, Se refere a UF do emitente. Você configura o componente com a UF do emitente e nunca com a UF do destinatário. Se a transportadora é do Estado de São Paulo, ela deve enviar os seus CT-e para a SEFAZ-SP, não importa para onde vai a carga se é Minas Gerais ou Rio de Janeiro (por exemplo). Sendo assim ao configurar o componente devemos informar a UF do emitente que no exemplo acima tem que ser SP.

Boa tarde Eduardo, Com relação a UF é outra coisa? Se sim, por favor vamos seguir as regras do fórum. Criar uma postagem nova para uma questão nova. Mas lembre-se sempre de pesquisar, pois a sua duvida pode já ter sido respondida.

Não temos mais o Delph XE5, para testes.. estamos verificando com a Embarcadero, se conseguiremos uma ISO e licença dele, para testes...

Boa tarde Robinho, Muito obrigado pela informação, já incluímos em nosso fórum de noticias.

Unit Frm_ACBrCIOT; procedure TfrmACBrCIOT.btnCriarEnviarClick(Sender: TObject); linha 1095 {$if CompilerVersion < 23} MemoDados.Lines.Add(IntToStr(TipoCarga.Codigo) + ' - '+ TipoCargaToStr(TipoCarga.Descricao)); {$else} MemoDados.Lines.Add(TipoCarga.Codigo.ToString + ' - '+ TipoCargaToStr(TipoCarga.Descricao)); {$IfEnd} para adequar a Delphis mais antigos

Boa tarde Antônio, Favor atualizar os fontes, pois fiz a alteração para compatibilizar com versões antigas do Delphi no dia 18/03/2020 18/03/2020 Compatibilização do programa exemplos com versões mais antigas do Delphi. Por: Italo Jurisato Junior

Fiz um teste e gerou com 10k de registros. mas é claro não tenho certificado para assinar o arquivo. tu consegue fazer a geração e no deploy tu pular a assinatura? basta ao chamar o evento procedure TACBrBlocoX_Estoque.SaveToFile( nele tem um outro método GerarXML(AAssinar); em debug altere o AAssinar para False veja se gera

Arquivos enviados ao svn.

Realmente Lucas, agora que tu falou, percebi que vi errado... estranho que a SEFAZ ta obrigando a inserção destes campos...

vou colocar isso que você me passou, obrigado! a UF de destino é a UF do destinatário?

Boa tarde! Em teste! Logo comunico o resultado. Desde já agradeço.

Obrigado BigWings, vou mandar pro cliente e ver com a chave correta..obrigado pela observacao ta...

Por favor Daniel, não faça isso. Não remova este componente, ele ajuda muito!

Bom dia Walison, Desculpe pela demora, favor atualizar os fontes e faça novos testes. Criei os seguintes campos para serem usados na versão 2: ValorFECP, TotalFECP, MultaICMS, MultaFECP, JurosICMS, JurosFECP, AtualMonetICMS e AtualMonetFECP.

Bom dia a todos, Através das URLs que o Renato postou acima, cheguei a conclusão que a cidade de Ponta Porâ/MS não utiliza mais o provedor ISSNet e sim um outro provedor que vamos chamar de PortalInteg2. O provedor ISSNet segue a versão 1 do layout da ABRASF, já analisando os serviços disponibilizados no webservice do PortalInteg2 se referem a versão 2 do layout da ABRASF. Sendo assim vai ser necessário implementar um novo provedor que podemos chamar de PortalInteg2 ou PortalIntegv2, criar um arquivo INI para ele, e alterar o arquivo Cidades.ini, mais precisamente o provedor que atende a cidade de Ponta Porâ/MS.

Essa chave não é válida: [idDocAntEle001001] chCTe=35352003439985090005015700200001749319742438 Verifique e informe a chave correta.

Bom dia Flávio, Pra que facilitar se pode complicar. Essas adaptações são melhorias no código? Se sim, porque não anexa a unit que foi alterada para que possamos analisar e quem sabe envia-la para o repositório, assim todos saem ganhando. Observação: o XML que você anexou se refere ao MDF-e e não ao evento que ocorreu erro de validação. Pela mensagem de erro me recordo que o componente possuía um bug, mas já deve ter sido corrigido.

Obrigado @Juliana Tamizou. Vou ficar aguardando.

Bom dia Gustavo, Já chegou a conversar com algum contador?

Bom dia! Consegui resolver o problema. Deu certo! Obrigado!

Bom dia Pessoal, Quanto a informação acima a SEFAZ-RS acrescentou uma observação. OBSERVAÇÃO: O serviço está disponível nessa etapa para CT-e das UF´s autorizadas pela SVRS.

Responde não a todos. e depois refaz a instalação do ACBr. garanto que vai funcionar

Favor anexar o log do instalador

Ótimo... tinha visto a documentação, mas coloquei as propriedades na chave errada..100% funcionando.. obrigado... sds,

Olá pessoal, Foi feito uma alteração nas units que geram os XMLs dos RPS de todos os provedores. Essa alteração visa simplificar o código, antes era usado os métodos wGrupoNFSe e wCampoNFSe em vez de wGrupo e wCampo. O problema é que os métodos padrões não eram capazes de gerar as tags com prefixo como é o caso de alguns provedores, como exemplo o Ginfes. Foi feita uma alteração nos métodos wGrupo e wCampo visando a geração da tag com prefixo quando for o caso. Caso ocorra algum problema, favor criar um tópico referente ao componente ACBrNFSe informando qual é o provedor e não esqueça de anexar o XML gerado anteriormente a mudança e agora, para que possamos realizar as devidas correções. Muito obrigado e agradeço desde já a colaboração e compreensão de todos. Estamos trabalhando em um Refactoring do componente ACBrNFSe que vai simplificar ainda mais as units que geram o XML, a intenção é eliminar todos os IF e CASE que se referem aos provedores, deixando o código muito mais limpo.

Achei esse Bug... https://bugs.freepascal.org/view.php?id=18354 deve ter relação com o DecimalSeparator... e por isso "os gringos", ainda não tiveram interesse em investigar... em todo caso... realmente usar ",0.00" na mascara, é melhor, pois se ajusta de acordo com o valor... Enviei um ajuste para o SVN, nesse sentido, ajustando todas as Units que estavam debaixo do diretório DFe... Commit [r19481] Pode ser, que algum Label, apareça alinhado a Esquerda e não a direita... nesses casos precisaremos ajustar o Aligment desses Labels com: Aligment = taRightJustify

Bom dia! Estou tendo problemas com a Versão do Qrcode no AcbrLibNFe não está ficando na versão 2, gostaria de saber como posso alterar a versão do qrcode? ACBrLib.ini

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Boa tarde. Observe no manual que o correto para a versão 2 do QRCode é setar VersaoQRCode com 2, note que em seu ini está 0. https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html Att.

Olá Pessoal, A SEFAZ-RS resolveu antecipar a liberação do ambiente de homologação. 02/03/2020 Implantada NT 2020.001 em Homologação Informamos que a NT 2020.001 que trata do MDF-e Integrado, encontra-se implantada no ambiente de homologação da SVRS. As regras de validação restritivas 725 e 726 deverão ser ativadas na próxima semana. Quero lembra-los que o componente ACBrMDFe já contempla todas as alterações publicadas na NT 2020/001, o programa exemplo foi alterado para exemplificar os novos campos, grupos bem como o novo evento. Os novos Schemas já estão disponíveis a um bom tempo. Na próxima versão do ACBrMonitor já vai estar disponível a atualização do manual do mesmo que mostra como gerar o arquivo INI do MDF-e com os novos campos e grupos, bem como gerar o arquivo INI do novo evento.

Olá Pessoal, Foi publicado a versão 1.02 da NT 2020/001 referente as alterações no layout do MDF-e. O que mudou da versão anterior para esta? Apenas a redação das Regras de Validação do MDF-e, veja quadro abaixo a nova redação. Com relação ao resto, nada foi alterado e as datas para ativação continuam as mesmas.

As respostas do terminal no print do demo do acbr é a falta de trocar uns eventos pra ansi string.....

Desculpe, se não for o lugar correto, mas segue as dúvidas de iniciante. 1 - A obrigação é do contratante, então o Emissor de NFe que gerará o CIOT? (embora exista possibilidade de passar a obrigação para a Transportadora) 2 - É só um informativo, que vai por XML, obrigatoriamente por webservice, não tem um site que o cliente possa fazer "manual", certo? 3 - Não tem a ver com pagamento (se quiser pagar em conta corrente pode fazer normal)? (é que comentaram sobre o eFrete e fala algumas vezes sobre instituições habilitadas para PEF, então fiquei em dúvida) 4 - No exemplo do ACBR, não vi nada de impressão, é isso mesmo? 5 - Vocês estão fazendo o módulo de geração do CIOT separado, ou estão linkando com MDF-e? (sei que é um controle separado, mas dá a impressão que os dados são bem próximos) Desculpe a ignorância, é que li as resoluções, mas não entendi muito a finalidade, ou necessidade, para mim poderiam somente incluir as informações de pagamento no MDF-e e já estaria tudo certo. Como estou montando o módulo agora, queria uma idéia de para onde ir, li a documentação, pesquisei no fórum, mas estou confuso. Obrigado!

Bom dia CLverson, Em breve o MDF-e vai passar a ter campos novos no XML que vão contemplar o CIOT. Por favor leia a noticia: Nota Técnica 2020/001 - MDF-e

Boa tarde Eliomar, O retorno acusando Situação = 4 se não me falha a memória significa que o provedor recebeu o RPS e processou com sucesso. Execute o Consultar NFS-e por RPS, informando o numero e serie do RPS.