-
Total de ítens
103 -
Registro em
-
Última visita
-
Days Won
4
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por bsoft
-
-
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.
- 1
-
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.- 2
Rejeição: Assinatura Difere Do Calculado 297
em ACBrCTe
Postado
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á...