Ir para conteúdo
  • Cadastre-se

bsoft

Membros
  • Total de ítens

    103
  • Registro em

  • Última visita

  • Days Won

    4

Tudo que bsoft postou

  1. 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á...
  2. 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.
  3. 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
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.