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

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

Obrigado pela resposta, @BigWings, não havíamos visto este outro tópico. Na verdade, agora o código está igual ao do Validar da NF-e, com certeza o Ítalo copiou de lá.

Boa noite, pessoal Atualizamos os fontes do ACBr, mas detectamos um problema na emissão de CT-e, CT-e OS e MDF-e, e ele ocorreu devido as alterações da revisão 13350. Ao utilizar a função Validar com um XML que não está assinado, não está mais acontecendo a tentativa de assinatura utilizando o XML original. Porém, na sequência do procedimento, na validação do Schema (SSL.Validar), está dando o seguinte erro: De acordo com o DTD ou o esquema, o conteúdo do elemento '{http://www.portalfiscal.inf.br/cte}CTeOS' está incompleto. Esperado: {http://www.w3.org/2000/09/xmldsig#}Signature. Antes da revisão 13350, o código era este: AXML := XMLAssinado; Onde XMLAssinado é uma property, que na leitura chama a função GetXMLAssinado e ocorria a assinatura. @Italo Jurisato Junior, não conseguimos entender a ideia da alteração, poderia nos explicar para tentarmos achar uma solução que não gere mais esse erro?

Boa tarde, Identificamos uma situação não muito parecida com esta (nosso caso é a importação de um XML de NF-e emitido por outro sistema), mas onde o problema em si é que a função UTF8ToNativeString está retornando o XML vazio, e gostaríamos de compartilhar a solução: uma simples verificação em cima do resultado, que pelo menos retorna o próprio XML ao invés de não ter nenhum conteúdo caso não sobreviva aos métodos de conversão Utf8ToAnsi / UTF8Decode / UTF8ToString. function UTF8ToNativeString(AUTF8String: AnsiString): String; begin {$IfDef FPC} Result := AUTF8String; // FPC usa UTF8 de forma nativa {$Else} {$IfDef UNICODE} {$IfDef DELPHI12_UP} // delphi 2009 em diante Result := UTF8ToString(AUTF8String); {$Else} Result := UTF8Decode(AUTF8String); {$EndIf} {$Else} Result := Utf8ToAnsi(AUTF8String) ; {$EndIf} if Result = '' then Result := AUTF8String; {$EndIf} end; Como o @Italo Jurisato Junior falou, de fato a SEFAZ sempre recomendou que não sejam utilizados caracteres especiais, mas ela não proíbe, então entendemos que esta alteração, além de não afetar o funcionamento, pode ser que ajude em determinados casos. Segue em anexo o arquivo ACBrUtil.pas modificado, e também o XML de NF-e que motivou esta alteração (notem que apesar do encoding="UTF-8", o arquivo é ANSI e consegue ser lido normalmente pelo Delphi). ACBrUtil.pas NFe41170577595395000490550050014156431090627603.xml

Boa tarde, @Italo Jurisato Junior, realizamos uma nova correção na leitura das informações de contingência. Estas informações não estavam sendo lidas devido a inclusão da leitura do grupo "infPercurso" antes delas. Segue em anexo o fonte modificado (pcteCTeR.pas) pcteCTeR.pas

Não precisa chutar o balde e tirar a compatibilidade a partir de agora, podemos resolver esta questão simplesmente incluindo um tipo substituto apenas para as versões inferiores ao Delphi XE2 que não possuem o tipo NativeUInt. Sugerimos adicioná-lo ao ACBrUtil.pas (em anexo), para que possa ser usado em vários outros lugares do projeto. Testado no Delphi 7 e no Delphi 10.1 Berlin. ACBrUtil.pas