Heckler Milas

Correção: o XML saiu com IE vazia. Achei que havia conseguido fazer o XML sair sem a IE. Nesse caso o problema é que o Schema não aceita vazio (procedimento Validar que mencionei). Ao mesmo tempo que, no mínimo, algumas UF não aceitam ISENTO. Estou ciente das exigências do manual. Mas considerando esse duplo bloqueio estou sem ideias quanto ao procedimento correto que funcione para qualquer UF

Eu testei ISENTO e nem toda UF aceita. Por isso tive que modificar e abrir esse tópico. Sem IE a SEFAZ acatou o XML

Bom dia. Estou tendo problema ao gerar MDFe com proprietário do veículo de tração sendo PF. Nesse post um colega pediu que o componente gerasse o IE do proprietário do veiculo de tração mesmo que vazio. Porém agora, pelo menos em PR e SP, os schemas estão disparando erro durante a validação se a IE estiver vazia. E o componente não permite não informar. Se eu simplesmente ignorar a tag ele insere sozinho. Mesmo se eu usar o LoadFromString() sem a tag o componente insere novamente e dispara erro durante o procedimento de validação contido dentro de AcbrMdfe1.Enviar; Não tentei preencher apenas com zeros pois imaginei que o Schemas poderia não aceitar. Além de que se não há, meu entendimento é que o melhor é não informar se a SEFAZ permite que assim o seja. Resolvi modificando o XML manualmente e pulando a validação. Mas estou relatando para que possa ser analisado se não é melhor remover essa inserção forçada para que o dev tenha mais liberdade e transparência no montagem do XML. Abaixo exemplo de rejeição retornada sem o meu ajuste (meu código. Não alterei os fontes do projeto).

Boa noite. Sim, resolveram. Segue arquivo em anexo. Só ressaltando que fiz dessa forma apenas para demonstração e dessa exata forma servirá apenas para Windows. Para poder implementar ao projeto precisaria adaptar para as demais plataformas ACBrNFeDANFeRLRetrato.pas

Pelos meus testes, sei que algo equivalente ao "MulDiv" nos componentes com posicionamento ajustado resolveria. (Digo equivalente pois sei que a função MulDiv é exclusiva do Windows) Algo assim: Ou então, mudar o "AjustarEscala" para algum momento após o reposicionamento dos componetes. Ou reposicionar os componentes em algum momento antes de chamar o "AjustarEscala". Pois o que causa essa sobreposição é o fato do relatório ser escalado e em seguida suas posições serem ajustadas antes da impressão.

Conforme eu informei no começo do post, já faço uso das opções que você destacou e as colunas permancem sobrepostas.

No caso, eu não mexi no código fonte, por hora tenho apenas reduzido a resolução nas máquina que dão o erro. Pois senão a cada atualização eu teria que alterar novamente, ficaria inviável. Apenas destaquei os trechos que identifiquei serem a fonte para facilitar a resolução. Não encontrei essa opção no Delphi que utilizo. Mas isso não resolveria o problema de posicionamento ao escalar. Simplesmente desativaria a escala.

A primeira foto acabou indo para o final do tópico. Tentei ajustar na edição mas não deu certo.

Bom dia. Faço uso do ACBR com FortesReport para emissão e impressão de NFe e DANFE, assim como CTe e DACTE. Em máquinas que utilizam o zoom do windows é necessário usar as propriedades "ACBRNFE1.Danfe.AlterarEscalaPadrao := True;" e "ACBRNFE1.Danfe.NovaEscala := Screen.PixelsPerInch;" para ajustar o relatório para a máquina. Porém, ao fazer isso, o DANFE imprime com sobreposição de colunas conforme exemplo:NFeTeste125Zoom.pdfNFeTesteSemZoom.pdf. Primeiro anexo, Zoom, mostra como fica em máquinas com o zoom. E o segundo como fica sem zoom. Eu creio que isso ocorra pois nesse momento é feito o ajuste de escala: Porém, nos eventos beforePrint do retrato, e demais formatos, as posições das colunas são ajustadas: Dentro inicializar dados: Destaquei essa rotina "ControlaExibicaoColunaDesconto" pois é a que mais me afeta, mas todos esses ajustes, feitos nos eventos BeforePrint do relatório, causam erros de posicionamento nas máquinas com zoom nos respectivos componentes que eles . E isso ocorre nos demais relatórios também, não só na DANFE. Se for possível elaborarem uma solução, esse já é um problema de vários anos. Desde já, agradeço.

A princípio, não consigo realizar testes no D7. Mas se conseguir passar uma listagem das tais ocorrências eu poderia verificar para ajudar no processo

Não. Apenas no Delphi 10.3. Quando foi relatado que foi subido ao SVN as modificações, não deram detalhes.

Bom dia, @Alexandre de Paula. Não obtive mais nenhum retorno desde a última réplica do @Italo Giurizzato Junior. Sabe me informar se tenho que realizar algum outro procedimento para dar sequência nessa questão? Desde já agradeço

Boa tarde, @Italo Giurizzato Junior. Algum retorno sobre as contribuições?

Bom dia @Italo Giurizzato Junior, novamente. Acabo de baixar o SVN para verificar minhas contribuições e percebi que, com exceção da marca d'água no CTe, todas minhas contribuições foram eliminadas. Segue DANFE, novamente desconfigurada, nos fontes atualizados NotaTeste.pdf

Bom dia @Italo Giurizzato Junior. Acredito que não há nenhuma restrição nesse sentido para os DA's. Mas sem problemas. Meu foco era a correção da impressão com zoom e código de produto. Grato por mesclar as contribuições ao SVN e pelo retorno.

Bom dia, @Italo Giurizzato Junior Segue ACBrCTeDACTeRLRetrato.dfm, com a inclusão da Marca d'água novamente.

Boa tarde, @Italo Giurizzato Junior. Meus fontes foram atualizados por último em dezembro de 2024, salvo engano. Farei o download do ACBrCTeDACTeRLRetrato.dfm mais recente e refarei as implementações. Volto a responder este post quando finalizar

Boa noite. Reparei que um dos campos seguia desconfigurado e necessitei fazer mais um ajuste. Segue conjunto de arquivos compactados. FontesModificados.7z

Boa tarde, pessoal. Por conta de alguns problemas já antigos no uso do DANFE resolvi fazer algumas alterações para sanar esses problemas. São eles(os problemas): ACBr + Fortes(4.0.1.3) impressão do DANFE com zoom de 125% ou maior desconfigurada. Códigos de produto muito longos não quebram a linha, por não possuírem espaços ou outro delimitador de quebra, ultrapassando o espaço destinado à ele e sobrepondo o campo ao lado. Quanto ao zoom tentei usar a propriedade AlterarEscalaPadrao, mas não obtive o resultado desejado. (o arquivo NFeTesteAlterarEscalaComZoom mostra o resultado obtido, juntamente do problema do código do produto) Para tanto, criei algumas funções no ACBrUtil.Math e ACBrUtil.Strings. Procurando manter a compatibilidade com todas as versões de IDE que o ACBr se propõe a ter compatibilidade. Junto disso, aproveitando o embalo alterei mais alguns detalhes: removi a propriedade MarcadAgua do DANFE e movi ela ao ACBrDFeReport para que a propriedade ficasse disponível à todos os DA's(documentos auxiliares). Em seguida implementei a marca d'água para o DACTE retrato, retrato A5 e EventoRLRetrato. Todas as implementações nas DA's se referem ao Fortes Report e foram implementadas nos Forms Delphi. Os .lfm não foram modificados. Abaixo segue alguns exemplos dos problemas que tive e os arquivos modificados para mesclar ao fonte principal. Qualquer problema fico no aguardo, à disposição, para ajudar na resolução no que puder. NFeTeste125Zoom.pdf NFeTesteAlterarEscalaComZoom.pdf NFeTesteSemZoom.pdf FontesModificados.7z

Acabo de finalizar os testes e apenas o ACBrCTe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML traz o XML. O ACBrCTe1.WebServices.EnvEvento.EventoRetorno.XML realmente não retorna nada. Devo ter me confundido achando que ambos não estavam salvando.

Fazendo uns testes verifiquei que o ACBrCTe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML está retornando o xml, mas por algum motivo não está salvando no meu banco. Vou verificar novamente esse aqui ACBrCTe1.WebServices.EnvEvento.EventoRetorno.XML e volto a falar assim que descobrir também o que ocorreu para não salvar em banco

Eu faço o envio com ACBrCTe1.EnviarEvento(NumLote); E a rotina só envia um evento por vez. Então acredito que sim

Essa tag não retorna nada. Apenas um conteúdo vazio Tentei também com a ACBrCTe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML, mas a mesma coisa

Boa tarde. Gostaria de armazenar em banco o XML do procEventoCTe, logo após o envio do evento, conforme imagem abaixo: Queria saber se tem alguma propriedade ou algo do tipo que armazene esse XML. Consegui obter a parte do retEventoCTe com o AcbrCTe1.WebServices.EnvEvento.RetornoWS, salvo engano. Porém gostaria de obter o procEventoCTe inteiro para armazená-lo em banco. Se puderem me indicar o caminho, agradeço. Ou ao menos o caminho do eventoCTe, para que eu possa somar os dois e montar o arquivo 'completo' já ajudaria. Fico no aguardo.

Boa tarde. Consegui solucionar a questão com a sua sugestão. Através do CST da para saber sim o grupo. Obrigado pela ajuda. A quem interessar, descobri um outro método que pode solucionar e possivelmente ser um pouco mais amplo. Usando ACBrCTE1.Conhecimentos.Items[0].CTe.XML.Contains('<NomeDaTagXML>') é possível verificar se existe, ou não, uma tag no XML carregado. O único problema é quando houverem tags com o mesmo nome, que daí pode ocasionar algum erro. Mas para as tags únicas ajuda identificar se existe ou não. Implementei esse método na mesma rotina de importação para verificar se existia toma3 ou toma4 e funcionou de acordo com o esperado