EMBarbosa

Embora eu tenho certeza que outros usuários aqui do fórum podem te responder, sugiro você procurar outro caminho. Quando os próprios fiscais não se entendem, eu sugiro você fazer uma pergunta formal a SEF e a qualquer outro órgão competente. Você pode até mencionar que fiscais diferentes exigiram procedimentos diferentes o que deixou então uma dúvida sobre qual o procedimento correto. Junte essas informações e compartilhe com os responsáveis. Isso inclui os funcionários e os contadores da empresa de transporte. Daí, se continuar acontecendo dos fiscais implicarem, você pode orientar os motoristas e responsáveis pela carga a apresentar a resposta da SEF (e qualquer outro documento recebido). Isso evita dor de cabeça.

Veja também o comando EMAIL.TextoAlternativo https://acbr.sourceforge.io/ACBrMonitor/EMAILTextoAlternativo.html

Você precisa analisar mais do que uma coluna. Veja bem, a princípio, a coluna que explica se um grupo ou campo é obrigatório é a coluna ocorrência. Mas ela deve ser analisada no contexto de sua hierarquia. Isso porque um campo pode ser obrigatório mas estar num grupo opcional. Por exemplo, esse é o caso dos campos do ICMS Efetivo. O grupo N33 é opcional (ocorrência = "0-1"), mas os campos estão marcados como obrigatórios (ocorrência ="1-1"). Mas além disso, você deve verificar também as possíveis rejeições que ficam no ponto "4 Regras de validação" da NT. Nesse sentido, veja como exemplo lá no ponto 4.3, a regra de validação do Campo-Seq N12.81 que diz que para algumas UF e em certas circunstâncias o campo vICMSSubstituto deve ser informado. Como cada UF tem uma legislação, precisamos verificar se a Regra de Validação é adotada na UF ou não.

Acho que o que o Italo quis dizer é sobre os campos do grupo de local de retirada e entrega. Os outros campos dessa NT (2018.005) devem ser analisados caso a caso. Eles podem ser opcionais no layout, mas exigidos pelas regras de validação de uma UF. Esse é o caso dos campos que, se não informados, geram a rejeição 938.

Por favor, continue no seguinte tópico:

Analisando a área de documentos da NF-e/NFC-e temos o MOC (Manual de Orientação do Contribuinte) que possui o Anexo III (um documento à parte) e fala especificamente sobre o DANFE. Temos o seguinte parágrafo na página 9 (grifo é meu): Essa frase grifada passa a impressão de que não pode ser reduzido o campo porque, neste caso, ele não vai mais representar o conteúdo da respectiva TAG XML da NF-e.

Olá muito obrigado pelas várias contribuições. Está na nossa fila de análise.

Muito obrigado pela sugestão. Fiz uma implementação baseada nela. Subi as alterações para o SVN na Revisão 17110. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema.

Olá, Em primeiro lugar, muito obrigado pela iniciativa e pela intenção de contribuir com o projeto. Ficamos felizes com as contribuições. Obrigado por ter apontado também ao outro tópico, de modo que podemos relacionar os dois. Hmmm... acho que precisamos fazer um artigo na base de conhecimento sobre contribuições em forma de código ou componentes... Mas vamos lá! Nós pedimos que os novos componentes: funcionem em Lazarus e Delphi preferencialmente usem apenas bibliotecas de terceiros que já estão no nosso SVN se esforcem em seguir a formatação dos componentes já implementados possuam um aplicativo simples de demonstração Sobre o componente específico, depende mais do que for necessário. Se for comunicação com WebServices, é provável que se você basear num componente da paleta ACBrDFe poupará trabalho. Mas se for apenas comunicação TCP, então veja os componentes da paleta ACBrTCP. Acho que eu não entendi exatamente como você quer que ajudemos. Se você tiver uma dúvida mais específica, talvez fique mais fácil opinar. Caso contrário, você pode enviar o código, explicar suas dúvidas e pedir sugestões.

Enviei as alterações ao SVN na revisão 17103. Creio que está tudo ok. Queira por favor atualizar, testar e reportar qualquer problema. Muito obrigado pela contribuição.

Muito obrigado pela contribuição. Enviei as sugestões na revisão 1702 com a seguinte diferença: Não é necessário adicionar True no Create, porque o método Create já atribui True para FFreeObjects. Queira por favor atualizar, testar e reportar qualquer problema.

Hmm então parece que você quer uma recomendação pra apresentar o grid na tela. Se for isso, vai depender do que você realmente quer e da sua disposição de pagar algum componente já pronto. Eu sugiro você dar uma olhada nos componentes de grid da TMS e da DevExpress. Existem outros na internet e, se tiver condições, vale a pena investir. Por exemplo, eles costumam já ter embutido no código a conversão do grid para Excel e, em alguns casos, até a impressão. Pense em quanto tempo você economiza de desenvolvimento. Caso não possa adquirir, tente usar os grids da biblioteca Jedi (JCL/JVCL). Por exemplo o UltimateGrid tem alguns recursos que o grid padrão do Delphi não tem.

E qual o problema?

Se você programar em Delphi pode usar o componente ACBrNFSe. Seria necessário verificar se o modelo utilizado pela cidade de Juiz de Fora é compatível.

Olá, Eu acabei de enviar ao SVN (revisão 17083) uma correção para os ECF de modelos que utilizam o protocolo ESCECF, FiscNet e Epson. Você pode atualizar o seu código e testar novamente. Queira, por favor, reportar qualquer problema.

Se for uma ECF MP4200 TH-FI é possível que seja sim. Só que a alteração será no outro arquivo (ACBrECFEscECF.pas).

Acho que no momento o Monitor não tem transferência de arquivos por TCP/IP, mas o @José M. S. Junior pode confirmar.

Obrigado pelo retorno!

Geralmente, o ACBrMonitor tem acesso a impressora pela rede, então bastaria você mandar ele imprimir normalmente. Porque não configuram a impressora para ser compartilhada na rede, de modo que o ACBrMonitor possa acessá-la?

Pode ser um problema do ACBrECF. Para confirmar poderia por favor alterar o arquivo ACBrECFEpson.pas na seguinte procedure, TACBrECFEpson.SubtotalizaCupom: procedure TACBrECFEpson.SubtotalizaCupom(DescontoAcrescimo: Double; MensagemRodape : AnsiString); begin fsTotalPago := 0 ; if DescontoAcrescimo = 0 then exit ; EpsonComando.Comando := '0A04' ; if DescontoAcrescimo < 0 then EpsonComando.Extensao := '0006' else EpsonComando.Extensao := '0007' ; EpsonComando.AddParamDouble( abs(DescontoAcrescimo), 2 ); EnviaComando ; ZeraCache; RespostasComando.AddField( 'SubTotal', EpsonResposta.Params[0] ); fsEmPagamento := True ; end; E depois refazer os testes?

Qual o erro que começou a aparecer?

hmmm então o teste que eu passei não foi suficiente. Poderia manter a alteração que eu pedi e comentar essa verificação? A intenção é que não seja levantado nenhuma exception para que possamos avaliar se há ou não o vazamento.

Acho que o parâmetro nLote é obrigatório. Você verificou o manual? https://acbr.sourceforge.io/ACBrMonitor/NFEEnviarNFe.html

Puxa isso é frustrante. Um vazamento de 0,1 a 1 mega é muita coisa pra vazamento de memória numa função usada tantas vezes. Mas dá pra gente resolver. Vamos lá... Que ótimo! Isso ajuda muito para que juntos, analisemos o problema! Já li aqui e identifiquei um possível problema. Por favor veja essa parte que você escreveu: Poderia alterar a linha para a seguinte? DadosPFX := 'Texto apenas para ter algum valor.'; Daí repita o teste para ver se acontece o mesmo vazamento de memória. A propósito, qual versão do seu Delphi?

Eu que agradeço você ter se disposto a alterar as mensagens de erro e postar aqui para benefício de todos. Obrigado também por tentar compreender com respeito ao que não foi prontamente aplicado. Acreditamos que, quando possível, é melhor envolver a comunidade nas decisões que podem impactar diretamente sobre ela.