bsoft

Segue em anexo a unit modificada para compilar no Delphi 7. ACBrConsultaCPF.pas

Boa tarde, pessoal! Identificamos um ajuste necessário no CT-e Aéreo, para preencher as tags xLAgEmi e IdT apenas se a versão estiver setada como 2, para evitar os erros de "elemento inesperado". Também temos uma alteração que gostaríamos de sugerir, que é exibir o CST como "90" para o Simples Nacional (ao invés de "SN"), para ficar de acordo com a nova versão 3.0. Segue em anexo as duas units modificadas, pcteCTeW.pas e pcnConversao.pas. pcteCTeW.pas pcnConversao.pas

Consultamos a ANTT há algumas semanas com esta dúvida, e recebemos a seguinte explicação: Em atenção à mensagem de V. Sª., registrada sob o protocolo nº. 4042396, informamos que esta Ouvidoria obteve os seguintes esclarecimentos da Gerência de Transporte de Passageiros Autorizados - GETAU. Para as prestações de serviços de transporte interestadual ou intermunicipal de passageiros (sujeitos ao ICMS), é necessário que a empresa de transporte tenha Termo de Autorização de Fretamento da ANTT (transporte interestadual: TAF) ou autorização da Agência ou órgão responsável no Estado (transporte intermunicipal: NroRegEstadual); a empresa deve informar um dos campos para a emissão do documento. Traduzindo: o Número de Registro Estadual (NroRegEstadual) deve ser usado para transportes dentro do Estado da Transportadora, e o TAF para transportes fora do Estado.

Boa tarde, Realizamos algumas correções para o CT-e OS ter suporte aos modais Aéreo e Aquaviário. No caso, mantivemos a escrita e a validação do grupo infModal para o modelo 67 (CT-e OS) apenas quando for modal Rodoviário ou o tipo de serviço for diferente de Transporte de Valores. Seguem os arquivos modificados. ACBrCTeConhecimentos.pas pcteCTeW.pas

@Luiz Carlos de Lima, basicamente não houve mudança nesta validação N28 da Nota Técnica, exceto que não será mais obrigado informar esta Tag quando for Excesso de Bagagem, mas continuará sendo obrigatório para Transporte de Pessoas. Outro detalhe importante: não há nenhuma restrição que o Valor precise ser positivo; se é 0, ele pode ser informado - e deve ser informado quando atender a situação descrita na regra.

Bom dia, luisclaudio_jr Sim, também detectamos este problema e abrimos ontem um chamado na SEFAZ de SP sobre este problema (protocolo 7467978), mas infelizmente até agora não tivemos um retorno. O problema acontece tanto nos ambientes de Homologação quanto Produção, e é para qualquer Evento, não apenas para Cancelamento (Carta de Correção, por exemplo) Na SEFAZ do RS (e provavelmente nas outras, já que não recebemos reclamações) está tudo funcionando 100%. A solução paliativa é aguardar 1 hora após a emissão para realizar o envio do evento (para não receber a rejeição "A data do evento não pode ser menor que a data de emissão do CT-e"), e ainda diminuir em 1 hora o valor que está sendo enviado para a SEFAZ

Sim, Ítalo, fique tranquilo, estávamos apenas atualizando a situação do protocolo que abrimos na SEFAZ de MS sobre eles usarem um retorno fora do padrão. Tínhamos esperança que eles poderiam padronizariam isto com o alerta que enviamos, mas o retorno confirmou que precisamos manter as alterações da revisão 13961 do ACBr.

Apenas para compartilhar com todos o retorno da SEFAZ do MS sobre esta questão: Prezados, Boa tarde! O MOC-Manual de Orientação do Contribuinte não traz a especificação/padronização das tags da mensagem SOAP, assim permitindo implementações diferentes pelas UF's. O nome da tag no MS é "cteOSRecepcaoResult" se necessário favor adequar sua aplicação. Qualquer dúvida estamos a disposição. Att. Equipe CT-e Resumindo: cada UF inventa o que quer, e os desenvolvedores que se apurem para se certificar que cada Estado está funcionando..

É necessário incluir a alteração que sugerimos na semana passada no ACBr para possibilitar o envio desta tag zerada.

Boa tarde, pessoal! Tivemos que fazer uma alteração no ACBr para possibilitar que seja enviado o Valor do INSS como 0 nas tags de Tributos Federais (infTribFed). Como sabemos pela validação N28, esta informação é obrigatória quando o Tomador for Pessoa Jurídica e o serviço for Transporte de Pessoas ou Excesso de Bagagem, mas de fato não há nenhuma restrição que impeça que o Valor seja 0. Recebemos a confirmação por e-mail do fiscal Sergio Luiz Cintra, da SEFA do Paraná, e nos nossos testes recebemos a Autorização de Uso preenchendo assim. A alteração é no arquivo pcteCTeW.pas, e estamos enviando em anexo o arquivo. Obs: incluímos também uma alteração bem pertinente, apontada pelo @Maurício Sareto em outro tópico, sobre o Renavam não ser obrigatório, mas que foi enviada em um fonte desatualizado no tópico original. Favor dar os créditos a ele. pcteCTeW.pas

Tivemos que realizar algumas alterações no ACBr para adicionar suporte a emissão de CT-e OS nos Estados do Mato Grosso do Sul e do Mato Grosso. Infelizmente, a SEFAZ destes dois Estados não seguem o padrão das demais UF's e retornam um elemento diferente de cteRecepcaoOSResult ao consumir o webservice CteRecepcaoOS, fazendo com que o retorno não seja lido pelo ACBr. MS retorna cteOSRecepcaoResult, e o MT retorna cteRecepcaoOSCTResult ... por isso adicionamos estas duas strings na função TratarResposta da unit ACBrCTeWebServices. Para o Mato Grosso, além da alteração acima, foi necessário adicionar o endereço que estava faltando no ACBrCTeServicos.ini. Segue em anexo os 3 arquivos modificados. Obs: identificamos esta diferença primeiro na SEFAZ de MS, e criamos um atendimento lá (Protocolo 2017-043-016.918) para que avaliem deixar padronizado com os demais Estados, então há esperanças de que eles arrumem isso um dia. Obs 2: conferimos os webservices dos demais Estados (RS, SP, PR e MG), e o retorno deles está de acordo com o padrão. ACBrCTeServicos.ini ACBrCTeServicos.res ACBrCTeWebServices.pas

Prezado @Italo Jurisato Junior Humildemente voltaremos a pedir que reconsidere a sugestão que enviamos. Por motivos inerentes ao nosso sistema, nós precisamos carregar as informações do XML no componente ACBr no momento da abertura do lançamento. E até gostaríamos de estender a discussão e questionar o código atual do ACBr: qual a vantagem de sobrescrever a versão definida no componente com a versão carregada do XML? Já existiu alguma vez uma situação em que a SEFAZ orientou que "XML's de uma determinada versão sejam consultados em um endereço, e de outras versões em outro"? Nem quando houve a conversão do cancelamento de método próprio para evento foi assim - era possível cancelar documentos antigos por evento. Como já havíamos mencionado, o suporte a versão 3.0 do MDF-e está em vigor no nosso sistema há mais de 2 meses, mas não havia como detectar este problema que ocorreu no momento da virada da versão 3.0, porque não tínhamos como saber que o ACBr iria desconsiderar a versão definida no componente e considerar a versão lida a partir do carregamento do XML. Enquanto a SEFAZ manteve o WebService aceitando a versão 1.0, o ACBr funcionou. Tivemos um transtorno considerável nesta virada do MDF-e 3.0 - e repito, não tínhamos como saber que isso aconteceria. Acreditamos que revendo estes conceitos, podemos evitar problemas nas futuras viradas de versão da SEFAZ. Não tem problema de não aceitar a nossa sugestão, continuaremos amigos E até mesmo se houver um motivo que não conseguimos visualizar para fazer a versão ser sobrescrita no carregamento, ficaremos gratos em conhecer.

@Italo Jurisato Junior, chegou a avaliar a sugestão que enviamos acima? Com ela se resolve esta situação de usar a versão do XML e mantém o uso da versão do componente, como já acontece no envio dos Eventos.

Sim, foi testado em produção e em praticamente todos os Estados. Mas veja, a finalidade desta alteração que enviamos é para possibilitar a consulta de MDF-e's emitidos na versão 1.0. Além da nossa alteração, é mandatório que o componente esteja setado com a versão 3.0 (VersaoDF := ve300), assim a consulta será realizada no WebService atual.

Continuando o post anterior, gostaríamos de sugerir uma modificação para solucionar este problema: No ACBrMDFeWebServices.pas, procedure TMDFeConsulta.DefinirURL, remover a atribuição da VerServ com a versão lida no Manifesto carregado, deixando apenas a versão setada no próprio componente. procedure TMDFeConsulta.DefinirURL; var VerServ: Double; Modelo: String; begin FPVersaoServico := ''; FPURL := ''; Modelo := 'MDFe'; FcUF := ExtrairUFChaveAcesso(FMDFeChave); if FManifestos.Count > 0 then begin FTpAmb := FManifestos.Items[0].MDFe.Ide.tpAmb; //VerServ := FManifestos.Items[0].MDFe.infMDFe.Versao; end else begin FTpAmb := FPConfiguracoesMDFe.WebServices.Ambiente; //VerServ := VersaoMDFeToDbl(FPConfiguracoesMDFe.Geral.VersaoDF); end; VerServ := VersaoMDFeToDbl(FPConfiguracoesMDFe.Geral.VersaoDF); //atribuição única O problema não é no Encerramento, mas na Consulta, por isso só está acontecendo para alguns - aqueles que fazem a consulta antes do encerramento, que é o nosso caso. Segue em anexo a unit em anexo com as modificações sugeridas. Por favor avalie a nossa sugestão, @Italo Jurisato Junior ACBrMDFeWebServices.pas

Boa tarde, Também estamos com este problema ao tentar consultar MDF-e's emitidos na versão 1.00 - e faz tempo que a propriedade VersaoDF está setada como ve300 no ACBrMDFe. Pelo que verificamos até o momento, o problema está na função TMDFeR.LerXml da unit pmdfeMDFeR.pas, quando é lida a versão armazenada no XML que está carregado. MDFe.infMDFe.versao := StringToFloatDef(Leitor.rAtributo('versao=', 'infMDFe'), -1); No nosso sistema, nós carregamos o ACBr com os dados do XML que foi aberto usando LoadFromStream, e logo em seguida chamamos a função Consultar, e devido a versão estar sendo sobrescrita na leitura do XML, a tentativa de consulta acaba acontecendo nesta versão também. Estamos verificando a melhor alternativa para contornar isso, postaremos aqui quando encontrarmos algo.

Agradecemos a rápida resposta, BigWings. Vamos seguir a sua sugestão e colocar a verificação com a data hard coded no nosso código mesmo. Como usamos a mesma unit para preenchimento do CT-e e do CT-e OS no nosso sistema, as informações do Financeiro integrado ao Conhecimento acabaram sendo preenchidas também para o CT-e OS.

Na revisão 13826 foi adicionado um código para gerar o grupo <cobr> no CT-e OS, de acordo com a Nota Técnica 2017.002. Porém esse grupo preenchido no XML gerou o erro de retorno "raised exception class EACBrDFeException with message 'Rejeição: Falha no Schema XML do CT-e'". Os schemas estão atualizados com a NT, então acredito que esse erro se deve à data em que a NT começará a validar essa mudança, pois basta remover o grupo <cobr> que o XML é validado. Dia 02/10/2017 Homologação e 01/11/2017 em Produção. Sugerimos uma alteração para que o grupo seja enviado somente após essas datas. Na unit pcteCTeW, função TCTeW.GerarInfCTeNorm: if CTe.ide.modelo = 67 then begin // ... if ((CTe.Ide.tpAmb = taHomologacao) and (Date >= EncodeDate(2017, 10, 02))) or ((CTe.Ide.tpAmb = taProducao) and (Date >= EncodeDate(2017, 11, 01))) then GerarCobr; end Obrigado. pcteCTeW.pas

Realizamos uma modificação para que, durante a exportação do DACTE e do DANFE para PDF, não seja disparada a mensagem do FastReport: "Exportando página 1" seguida de um botão "Cancelar". Ver o print abaixo. O que motivou essa alteração é o fato dessa janela ficar sendo exibida (piscando) ao ser feita a exportação em lote de vários arquivos para PDF. Seguem os arquivos ACBrCTeDACTEFR.pas e ACBrNFeDANFEFRDM.pas com as modificações. No DAMDFE já está desabilitado. ACBrCTeDACTEFR.pas ACBrNFeDANFEFRDM.pas

Tivemos que alterar as classes "ACBrEFDBloco_C_Class" e "ACBrEFDBloco_D_Class" para seguir o GUIA PRATICO EFD ICMS/IPI 2.0.20, deixando vazios os campos relativos ao PIS e COFINS para os contribuintes que não são obrigados a prestar a informação. Estamos anexando as alterações para análise. Essas mesmas alterações já foram feitas com os registros C100 e C170 (http://www.projetoacbr.com.br/forum/topic/23803-deixar-vazio-pis-e-cofins-c100-e-c170), foram feitas as mesmas alterações nas classes, utilizando os parâmetros do LFill para retornar '|'. Referências ao Guia prático da Escrituração Fiscal Digital - EFD ICMS/IPI versão: 2.0.20: Registro C500 - Campo 24 (VL_PIS) - Os contribuintes que entregarem a EFD-Contribuições relativa ao mesmo período de apuração do registro 0000 estão dispensados do preenchimento deste campo. Apresentar conteúdo VAZIO “||”. (Página 83) - Campo 25 (VL_COFINS) - Os contribuintes que entregarem a EFD-Contribuições relativa ao mesmo período de apuração do registro 0000 estão dispensados do preenchimento deste campo. Apresentar conteúdo VAZIO “||”. (Página 83) Registro D500 - Campo 21 (VL_PIS) - Os contribuintes que entregarem a EFD-Contribuições relativa ao mesmo período de apuração do registro 0000 estão dispensados do preenchimento deste campo. Apresentar conteúdo VAZIO “||”. (Página 123) - Campo 22 (VL_COFINS) - Os contribuintes que entregarem a EFD-Contribuições relativa ao mesmo período de apuração do registro 0000 estão dispensados do preenchimento deste campo. Apresentar conteúdo VAZIO “||”. (Página 123) ACBrEFDBloco_C_Class.pas ACBrEFDBloco_D_Class.pas

Durante gerações sucessivas do arquivo SEF II alguns totalizadores do registro 9900 referentes ao bloco 0 não estão sendo zerados. Essa situação faz com que o totalizador seja somado a cada geração do arquivo. Ex.: |9900|0200|100| -> |9900|0200|200| -> |9900|0200|300| Segue o arquivo ACBrSEF2_Bloco0_1.pas com a correção para verificação. Somente o FRegistro0005Count era zerado. procedure TBloco_0.CriaRegistros; begin FRegistro0000 := TRegistroSEF0000.Create; FRegistro0001 := TRegistroSEF0001.Create; FRegistro0990 := TRegistroSEF0990.Create; FRegistro0005Count := 0; FRegistro0025Count := 0; FRegistro0030Count := 0; FRegistro0100Count := 0; FRegistro0150Count := 0; FRegistro0200Count := 0; FRegistro0205Count := 0; FRegistro0215Count := 0; FRegistro0400Count := 0; FRegistro0450Count := 0; FRegistro0460Count := 0; FRegistro0465Count := 0; FRegistro0470Count := 0; FRegistro0990.QTD_LIN_0 := 0; end; ACBrSEF2_Bloco0_1.pas

Boa tarde. Em nossos testes de envio de MDF-e v3.00, não estamos conseguindo enviar a tag <tpTransp> como ETC ou CTC no caso em que o veículo é próprio. Vimos que, de acordo com o tópico abaixo, nas revisões 13005 e 13006 foi feita a alteração na unit pmdfeMDFeW.pas para não enviar a tag caso o documento do proprietário seja CPF. Como consequência, se o CNPJ do proprietário não é preenchido (o que indica veículo do emitente) a tag <tpTransp> não será enviada. Código atual: if (VersaoDF >= ve300) and (Length(MDFe.Rodo.veicTracao.Prop.CNPJCPF) > 11) and (MDFe.Ide.tpTransp <> ttNenhum) and not ( (MDFe.Ide.tpEmit = teTranspCargaPropria) and (MDFe.Ide.modal = moRodoviario) and ((MDFe.Rodo.veicTracao.Prop.CNPJCPF = '') or (MDFe.Rodo.veicTracao.Prop.CNPJCPF = MDFe.emit.CNPJ)) ) then Gerador.wCampo(tcStr, '#007', 'tpTransp', 01, 01, 0, TTransportadorToStr(MDFe.Ide.tpTransp), DSC_TPTRANSP); Sugestão de correção: if (VersaoDF >= ve300) and ((MDFe.Rodo.veicTracao.Prop.CNPJCPF = '') or (Length(MDFe.Rodo.veicTracao.Prop.CNPJCPF) > 11)) and (MDFe.Ide.tpTransp <> ttNenhum) and not ( (MDFe.Ide.tpEmit = teTranspCargaPropria) and (MDFe.Ide.modal = moRodoviario) and ((MDFe.Rodo.veicTracao.Prop.CNPJCPF = '') or (MDFe.Rodo.veicTracao.Prop.CNPJCPF = MDFe.emit.CNPJ)) ) then Gerador.wCampo(tcStr, '#007', 'tpTransp', 01, 01, 0, TTransportadorToStr(MDFe.Ide.tpTransp), DSC_TPTRANSP); Segue em anexo a unit pmdfeMDFeW.pas para avaliação. pmdfeMDFeW.pas

Humildemente discordamos de sua opinião. Na sequência do código do ACBr, no resultado desta função é aplicada a função RemoverDeclaracaoXML, que simplesmente removerá o cabeçalho incorreto "<?xml version="1.0" encoding="UTF-8"?>" deste exemplo, e o conteúdo será lido sem nenhum problema. Podemos até ir mais a fundo no problema e analisar modificações na função XmlEhUTF8 - que tem como defeito simplesmente "acreditar" no que está sendo informado no encoding, mas não verifica se o conteúdo é realmente codificado em UTF8 - mas nossa sugestão envolve apenas a adição de uma linha para evitar um retorno vazio (que não possui vantagem nenhuma em ser desta forma). Pedimos pela última vez que reavalie a sugestão, ela pode ser útil para muita gente, inclusive para você e seus clientes. Se não aceitar, sem problemas, temos diversas alterações específicas para nossa empresa, e continuaremos amigos

@Daniel Simoes, esta NF-e não foi emitida pelo nosso sistema, foi um cliente nosso (transportador) que recebeu esta NF-e da Frimesa. Sabemos que é esta a falha, porém você também deve saber o quanto é difícil para um cliente pequeno argumentar com uma grande empresa que eles estão emitindo errado as NF-e's e que eles devem corrigir o problema. Eles preferem trocar o transportador! Agradecemos o retorno, mas pedimos que reavalie a sugestão, afinal, ela não será prejudicial à função UTF8ToNativeString.

Boa noite, @Italo Jurisato Junior, identificamos uma falha na geração da chave de contingência (funcção GerarChaveContingencia) para o CT-e OS, na qual estava tentando utilizar as informações do tomador do CT-e Modelo 57 (toma4 e toma3). Não achamos nenhuma informação disponibilizada pela SEFAZ sobre como proceder no caso do DACTE OS, mas seguindo a mesma lógica do CT-e "normal", alteramos para considerar os dados do tomador na geração desta chave. Sem estas alterações, atualmente está dando o erro "bar code inválido" em vermelho na impressão pelo FastReport. Segue em anexo o arquivo ACBrCTe.pas com as modificações realizadas para avaliação. ACBrCTe.pas