BigWings

Parece ser o padrão... #$A ou decimal #10 ou LF (line feed). O sLineBreak no Windows é um CRLF ou #$D$A ou #13#10. Qual a impressora?

O Buffer é um TStringList, pra cada linha dele já é adicionado uma quebra no método TACBrPosPrinter.Imprimir: if (FBuffer.Count > 0) then begin For i := 0 to FBuffer.Count-1 do begin StrToPrint := StrToPrint + FBuffer[i]; if (i < FBuffer.Count-1) then StrToPrint := StrToPrint + FPosPrinterClass.Cmd.PuloDeLinha; end; end; E o telefone está numa linha própria. Talvez tenha alguma configuração errada aí.

O telefone já não sai na linha abaixo? Ou você quer uma linha em branco entre o endereço e o telefone? Você pode manter a alteração local sem problema, ao atualizar só se tiver alguma alteração nessa mesma linha que vai ter conflito e você vai precisar intervir pra resolver. Pra enviar alteração pro SVN nesse caso creio que não seria aprovado por que parece se tratar de simples preferência estética.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Faça assim: ACBrNFe1.Configuracoes.RespTec.IdCSRT := 1; ACBrNFe1.Configuracoes.RespTec.CSRT := '123456789...'; E na geração da nota: ACBrNFe1.NotasFiscais[0].NFe.infRespTec.CNPJ := 1234001010200; ... Já será calculado o hash e gerado no XML.

O código atual está correto e funcionando. Você não precisa informar o hashCSRT ao alimentar o componente, o componente calcula o hashCSRT com base no CSRT e IdCSRT informados.

Você está usando o modo de envio assíncrono, precisa alterar para o modo síncrono.

Basicamente: - Baixar um client Git Oficial https://git-scm.com/downloads Tortoise Git https://tortoisegit.org/ - Pra baixar, fazer um git clone - Pra atualizar, fazer um git pull

O github não tem mais suporte a SVN, então precisa baixar direto via git.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Por causa do try..except no método Execute, como dito. procedure TCustomRESTRequest.Execute; [...] begin [...] try [...] except // any kind of server/protocol error on E: EHTTPProtocolException do begin FExecutionPerformance.ExecutionDone; // we keep measuring only for protocal errors, i.e. where // the server actually answered, not for other exceptions. LContent := E.ErrorMessage; // Full error description // Fill RESTResponse with actual response data - error handler might want to access it ProcessResponse(LURL, LResponseStream, LContent); if (E.ErrorCode >= 500) and Client.RaiseExceptionOn500 then Exception.RaiseOuterException(ERESTException.Create(E.Message)); HandleEvent(DoHTTPProtocolError); end; // Unknown error, might even be on the client side. raise it! on E: Exception do begin // If Execute raises an Exception, then the developer should have look into the actual BaseException Exception.RaiseOuterException(ERESTException.CreateFmt(sRESTRequestFailed, [E.Message])); end; end; Sendo uma exceção do tipo EHTTPProtocolException ele faz os tratamentos, mas ignora a exceção em runtime exceto no caso da propriedade RaiseExceptionOn500 estiver ativada e o status de retorno for maior 500 ou maior. Ele também chama o evento OnHttpProtocolError que você pode querer implementar (para logs por exemplo).

O try..except está no código do próprio RestClient. Veja o comentário do método Execute: /// Execute does NOT raise HTTP protocol exceptions, instead TCustomRESTClient.Response.StatusCode should be checked /// for desired values. In many cases a 2xx StatusCode signals "succes" - other status codes don't need to be /// errors though. It depends on the actual REST API. /// </remarks> procedure Execute; Ou seja você tem que verificar o código http de retorno e tratar na sua aplicação.

Essa exceção está no método de envio do componente: Chame ACBrNFe1.Notasfiscais.Clear antes do ACBrNFe1.NotasFiscais.Add na sua rotina de preenchimento. Assim não vai ter mais de 1 nota carregada no componente ao transmitir.

Correção no SVN, rev. 36607. Obrigado pela contribuição.

Precisa instalar o gerenciador da balança que comunica com ela, geralmente via rede. O ACBrCargaBal gera um TXT que é importado nesse gerenciador e este envia os dados para a memória da balança. A balança emite a etiqueta e a sua aplicação faz a leitura (ACBrLCB) e decodificação (ACBrInStore) do código de barras gerado por ela. Existem também as balanças mais simples, sem memória, que são conectadas ao PC via cabo serial, o ACBrBAL faz a leitura do peso diretamente pela serial.

Tem a opção no instalador, ele ajusta o ACBr.inc de acordo com o que for selecionado.

Tente configurar para TLS 1.1. Ou seguir as orientações do tópico abaixo:

Provavelmente teve conflitos com alterações locais quando atualizou: Use o Resolve do SVN pra ajustar manualmente e decidir o que manter, ou o Revert pra descartar as alterações locais e substituir pelo arquivo do repositório.

Fiz teste aqui, se alterar a configuração do componente para a versão 3.10, a comunicação é feita, só não chegou a autorizar um porque não tenho certificado de SP. Acho que nunca atualizaram esse webservice para o padrão da NFe 4.00.

Consegue descobrir a partir de qual revisão do SVN do ACBr que o problema passou a acontecer?

Sim. Mas novamente, é o meu entendimento. A sugestão é validar o cálculo com um contador de sua confiança, ou o contador responsável pela empresa em questão.

No meu entendimento ambas estão erradas, por estarem usando base dupla de ICMS. O DIFAL na venda interestadual para não contribuinte é sempre por fora. A exigência do DIFAL "por dentro" é para operações de entrada por contribuinte do ICMS. Veja o vídeo abaixo:

O que falta é o elemento <adi> com os dados da adição, em pelo menos um dos itens da nota.

Já está implementado sim.