bsoft

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

Bom dia, Ao atualizar os fontes, parou de compilar no Delphi 7, ocorrendo o erro "Invalid typecast". Acho que é o caso de colocar uma diretiva nesse código que foi modificado.

Boa tarde, @Italo Jurisato Junior, realizamos a inclusão dos endereços do layout CTeRecepcaoOS_3.00 para os servidores SVC-RS e SVC-SP, tanto homologação quanto produção. Segue em anexo o fonte modificado (arquivos ACBrCTeServicos.ini) ACBrCTeServicos.ini

Leonardo Quinino, não existe Recibo neste processo porque ele é síncrono, diferente do CT-e normal que é assíncrono, onde primeiro é enviado para a SEFAZ, recebendo o recibo de volta, e depois é consultado o resultado do processamento em cima deste recibo. Mais detalhes no item 4.2 do manual do CT-e versão 3.0.

Boa tarde, Realizamos algumas correções referente ao CT-e OS: Tratamento do envio como síncrono; Remoção da verificação no status 104 (Lote processado); Preenchimento das tags nAver e vCarga do grupo seg somente quando for modelo 57 e versão 2.00; Leitura do XML pelo método LoadFromString(); Ler o subgrupo infQ somente quando houver o grupo infCarga. Segue em anexo o fonte modificado (arquivos ACBrCTe.pas, ACBrCTeWebServices.pas, pcteCTeW.pas, ACBrCTeConhecimentos.pas e pcteCTeR.pas). ACBrCTe.pas ACBrCTeWebServices.pas pcteCTeW.pas ACBrCTeConhecimentos.pas pcteCTeR.pas

Bom dia, Realizamos uma correção referente ao CT-e OS, para as tags serie, subserie e vDoc do grupo infDocRef, e para o subgrupo veic do grupo rodoOS, que não são obrigatórios conforme consta no manual. Segue em anexo o fonte modificado (arquivo pcteCTeW.pas). pcteCTeW.pas

Boa tarde. Verificamos um erro ao emitir MDF-e aquaviário devido a algumas tags obrigatórias no 3.00 estarem sendo preenchidas no XML da versão 1.00. Incluímos a verificação da versão 3.00 nas tags irin, prtTrans, tpNav, xBalsa e no grupo infUnidTranspVazia conforme os respectivos manuais. Além disso, mudamos as verificações de "VersaoDF = ve300" para "VersaoDF >= ve300", semelhante às verificações de versão do CT-e 3.00. O envio do MDF-e aquaviário 1.00 foi testado e aprovado com essas modificações. Segue o arquivo "Fontes\ACBrDFe\ACBrMDFe\PCNMDFe\pmdfeMDFeW.pas" para verificação. pmdfeMDFeW.pas

Boa tarde. Estamos enviando uma correção nessa impressão que verificamos ao tentar fazer a impressão dos eventos do MDF-e. A correção consiste em remover a linha "cdsEventos.EmptyDataSet;" da procedure "TACBrMDFeDAMDFEFR.LimpaDados". Esse código não é necessário porque o dataset já é limpo na "CarregaDadosEventos", e quando a "CarregaDados" é chamada posteriormente acabava limpando o dataset depois de ele ter sido preenchido. ACBrMDFeDAMDFEFR.pas

Mailson, acabamos enviando esta modificação em outro tópico (http://www.projetoacbr.com.br/forum/topic/36567-alteração-damdfe-em-fastreport/) seguindo o padrão do nosso sistema, mas de fato esta linha é desnecessária, então basta excluí-la para ser aplicado o padrão 100%. Ou poderia ser avaliadado de usar o ZoomMode como zmPageWidth, para se ajustar ao tamanho da página. PreviewOptions.ZoomMode := zmPageWidth; Obrigado por avisar.

Ítalo, vimos que você enviou a correção no repositório (revisão 13277), porém apenas parcialmente (só para o bloco do CT-e 3.00), mas esta correção se aplica também para as versões 1.04 e 2.00. Apenas no 1.03 estas tags não eram obrigatórias, com certeza vem desde lá este código.

Boa noite! Temos uma pequena correção no preenchimento de duas tags do modal Aéreo, CL e vTar do grupo tarifa, para ficarem de acordo com o manual da SEFAZ (ambos são campos obrigatórios). Segue em anexo o fonte modificado (arquivo pcteCTeW.pas) pcteCTeW.pas

Bom dia. Fizemos algumas alterações na unit ACBrMDFeDAMDFEFR.pas. A principal é a criação dos objetos em tempo de execução, não sendo mais necessário o Data Module ACBrMDFeDAMDFEFRDM, semelhante ao DACTeFR. Outra alteração feita foi a possibilidade de utilizar a propriedade FastFile e FastFileEvento para carregar o relatório a partir do conteúdo do arquivo FR3. O DPK também foi alterado, retirando o DataModule. Estamos enviando também uma atualização do aplicativo de Exemplo do ACBrMDFe, para que seja realizado o teste das alterações acima. Como não usamos o Fortes Report, foi apenas trocado o componente pelo Fast Report. Testado no Delphi 10.1 Berlin e Delphi 7. ACBrMDFeDAMDFEFR.pas ACBr_MDFeDamdfeFR.dpk DemoMDFe.zip

Segue em anexo conforme solicitado. Se achar mais fácil, incluímos um arquivo Patch, que deve ser colocado na raiz da pasta Fontes para que o SVN encontre os arquivos. Não temos os Delphi's intermediários (2009, por exemplo), mas estas modificações compilaram no Delphi 7 e no Delphi 10.1 Berlin. Apenas para o arquivo do SEF2 é que foi incluída uma diretiva, por causa do TDate ser declarado no Controls no Delphi 7. limpeza_uses.patch ACBrCTeDACTEFR.pas ACBrMDFeDAMDFEFR.pas ACBrMDFeDAMDFEFRDM.pas ACBrNFeDANFEFR.pas ACBrNFeDANFEFRDM.pas ACBrSEF2_BlocoE.pas

Adicione também o path ACBr\Fontes\Terceiros\Ole lá no Library, e reinstale o ACBr_DFeComum.

Olá. Gostaríamos de sugerir a limpeza dos uses das units abaixo, para evitar de precisar definir o Unit Scope com "VCL" para compilar no Delphi 10.1 Berlin. Segue abaixo a relação de cada unit e quais units podem ser removidas sem nenhum impacto: ACBrCTeDACTEFR.pas = Graphics ACBrMDFeDAMDFEFR.pas = Forms, Graphics, Dialogs ACBrMDFeDAMDFEFRDM.pas = Dialogs ACBrNFeDANFEFR.pas = Forms, Graphics, Dialogs ACBrNFeDANFEFRDM.pas = Dialogs ACBrSEF2_BlocoE.pas = Controls Assim apenas o pacote ACBr_NFeDanfeFR precisa ter esta definição devido ao uses da unit Graphics no arquivo ACBrNFeDANFEFRDM.pas, necessário para o procedimento PintarQRCode.

Basta adicionar ao Library Path o diretório: ACBr\Fontes\Terceiros\CodeGear

Voltou mesmo, finalmente está tudo ok! E agora estamos recebendo a mesma mensagem de e-mail para cada protocolo que foi aberto... "Prezado contribuinte, Foram alteradas configurações nos servidores web da SEFAZ-SP e o problema foi resolvido. Solicitamos que efetuem nova tentativa e caso verifiquem ainda algum problema, que nos reportem novamente."

Pessoal, este problema é lá na SEFAZ de SP, e é apenas no ambiente de Homologação e nas operações que envolvem Eventos (Cancelamento, CC-e) tanto de NF-e quanto de CT-e. Estamos com um tópico aberto no fórum de CT-e referente a isso, acho que seria interessante que as informações ficassem centralizadas em apenas um lugar. http://www.projetoacbr.com.br/forum/topic/32411-erro-no-cancelamento-cce-nfe-valor-assinatura-signaturevalue/ E apesar de já termos registrado alguns protocolos de reclamação lá, o problema persiste (fizemos um teste há poucos minutos). Nossa única alternativa é continuar reclamando para a SEFAZ de SP, até eles tomarem vergonha na cara e resolver este problema que já dura 4 dias.

Ontem foi feriado aqui na nossa cidade e não tivemos expediente, mas de fato voltou a dar problema para qualquer operação envolvendo envio de Eventos. O protocolo de sua mensagem é 7099393. Acabamos de registrar mais um chamado lá na SEFAZ de SP. Marcelo de Paula_15245, não se preocupe, você não precisa cancelar cada NF-e ou CT-e emitido no ambiente de Homologação, pode deixá-los assim que a SEFAZ não irá atrás cobrar os impostos devidos ^^

Apenas registrando que a SEFAZ de SP já normalizou tudo.

medeiros.sunsystem, sim. E fizemos um teste há 5 minutos, o problema ainda continua. Italo, sim, registramos um atendimento lá hoje de manhã e já obtivemos uma resposta... infelizmente, naquele velho padrão conhecido por nós (resposta automática, sem nem ler o que foi escrito) Registraremos aqui neste tópico quando recebermos uma nova resposta deles ou se o problema for solucionado.