bsoft

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.

medeiros.sunsystem, apesar da sua mensagem ser referente a NF-e, pudemos constatar que isso é um problema na SEFAZ de SP, tanto para CT-e quanto NF-e, e apenas nas operações que envolvem envio de Eventos (Cancelamento, Carta de Correção) Até mesmo nas UF's que utilizam o SVCSP (Pernambuco, por exemplo) está ocorrendo este problema. E acreditamos que seja apenas no ambiente de Homologação, pois nenhum cliente nosso reclamou até este momento. O negócio é entrar em contato com a SEFAZ de SP e avisá-los do problema, porque fizeram alguma arte lá...

Com certeza a leitura e o armazenamento seriam mais rápidos se fosse usado métodos próprios para manipulação de XML, até com o TXMLDocument nativo seria melhor. Mas será um projeto bem grande realizar esta mudança. Quanto a propriedade Nivel, na verdade nós só tornamos published a variável private FNivel, porque é necessário sincronizar este StringList para a leitura correta das tags filhas infUnidTransp e infUnidCarga. Pensamos até em modularizar a leitura destas duas tags, para não ficar esta repetição tripla de código (InfNF, InfNFE e InfOutros) que existe atualmente.

Há pouco tempo, um novo cliente adquiriu o nosso sistema, e para eles é bastante comum realizar operações de transporte com centenas de notas fiscais embarcadas - eles transportam para uma loja virtual bastante popular. Ao realizar estas operações, foi notado um problema de velocidade muito grande, e descobrimos que o responsável por isso era o ACBr, mais especificamente em uma determinada linha da função LerXml do pcteCTeR.pas. Conseguimos resolver este problema, e gostaríamos de compartilhar a solução com vocês. O "culpado" por este problema de velocidade é a repetição da função Leitor.rExtrai, que é executada a cada documento vinculado. Para documentos pequenos, não há diferença significativa de desempenho, mas à medida que a quantidade de documentos aumenta, mais pesada fica a busca. A solução foi eliminarmos esta repetição - que tinha como objetivo apenas identificar se ainda haviam documentos vinculados - e criar uma função que apenas retorna a quantidade de repetições necessária. Isso fez com que a velocidade de carregamento caísse de vários minutos para apenas poucos segundos. Além da alteração na unit pcteCTeR.pas, foi necessário alterar a unit pcnLeitor.pas, criando uma propriedade para permitir definir o Nivel após a atribuição do Grupo. As duas units modificadas estão em anexo, e correspondem a revisão 11941 do Trunk2. Em anexo também um exemplo de CT-e emitido pelo nosso cliente, com 1994 NF-e's vinculadas (a operação original era composta de 5980 NF-e's, que precisou ser dividido em três devido a limitação da SEFAZ de 2000 documentos). O conteúdo foi modificado para preservar as informações da transportadora e do seu cliente, mas o arquivo carrega normalmente no ACBr. Não utilizamos a regra de indentação do ACBr, mas sintam-se à vontade em padronizar de acordo com seus critérios. Após substituir os dois arquivos, é necessário recompilar os pacotes ACBr_PCNComum e ACBr_CTe. CTeGigante.xml pcnLeitor.pas pcteCTeR.pas