Daniel Simoes

Apliquei correções no Demo do ACBr para configurar corretamente a propriedade "RetirarAcentos" Notei que o XML enviado está sendo criado com os acentos... isso pode ser comprovado no arquivo de Log "1-env-lot-soap.xml" apliquei pequenas correções na rotina que gravava esses arquivos de Log, onde havia uma dupla conversão parea UTF8, bagunçando os caracteres acentuados...

Experimente com a Unit em anexo... ACBrECFVirtualNFCe.pas

Use o ACBrinstall... vc precisará reconstruir os BPLs

Mas se mudarmos isso, irá quebrar o funcionamento do ECFVirtualNaoFiscal... Acho que uma possível solução, seria implementar o Desconto/Acréscimo ao Item no método: procedure TACBrECFVirtualNFCeClass.DescontoAcrescimoItemAnteriorVirtual( ItemCupom: TACBrECFVirtualClassItemCupom; PorcDesc: Double); override

Sua informação não é condizente com a informação do WebService, os campos são "decimal" e não "int" (veja tópico anterior)

Quais são exatamente os passos ? Qual é o XML de testes ?

Não sei se é uma boa ideia, pois é exigido a digitação do Captcha

Sua alteração propõem retornar o uso do FormatFloat... justamente ele que tem problemas por usar a virgula no caso de S.O. com o padrão brasileiro... Segundo a especificação do WebService, todos os campos que você citou são Decimais... ou seja, os fontes atuais, aprecem estar corretos: http://ws.correios.com.br/calculador/CalcPrecoPrazo.asmx?op=CalcPrecoPrazo <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <CalcPrecoPrazo xmlns="http://tempuri.org/"> <nCdEmpresa>string</nCdEmpresa> <sDsSenha>string</sDsSenha> <nCdServico>string</nCdServico> <sCepOrigem>string</sCepOrigem> <sCepDestino>string</sCepDestino> <nVlPeso>string</nVlPeso> <nCdFormato>int</nCdFormato> <nVlComprimento>decimal</nVlComprimento> <nVlAltura>decimal</nVlAltura> <nVlLargura>decimal</nVlLargura> <nVlDiametro>decimal</nVlDiametro> <sCdMaoPropria>string</sCdMaoPropria> <nVlValorDeclarado>decimal</nVlValorDeclarado> <sCdAvisoRecebimento>string</sCdAvisoRecebimento> </CalcPrecoPrazo> </soap:Body> </soap:Envelope>

O SAT, não faz o controle de duplicidade... Ate porque não existem no XML de envio, campos que poderiam ser usados como uma chave primária

a Largura da bobina deve ser algo em torno de 300... a unidade é DPI e não mm

Por favor pare de "fazer terrorismo"... Seu tópico é grosseiro, e despreza o imenso trabalho realizado por programadores como eu e outros da comunidade do ACBr... Se você consegue fazer melhor do que está.. então faça... Há vários tópicos sobre isso aqui no fórum... Isso é problema no Driver da sua impressora... Centenas de usuários usam a NFCe em Fortes sem problema algum...

Por favor ajuste para o valor correto... por motivos já explicados.. não vou modificar o funcionamento dessa propriedade...

Ainda está muito confuso... Onde podemos ler a documentação desse WebService ? Baseado nas informações do site: https://www.w3.org/TR/2000/NOTE-SOAP-20000508/ notei que os decimais de um Webservice podem conter um numero variado de casas decimais... Mas o separador de Decimal DEVE ser o Ponto... Apliquei modificações nos fontes do SVN que devem resolver o problema

O que é um relatório correto ? (favor anexar uma imagem) 72 parece ser um tamanho muito pequeno para uma bobina... já tentou aumentar esse valor ? Se mudarmos isso agora, podemos quebrar o funcionamento de muitas aplicações...

leia a lei toda... o uso da NFCe só é autorizado em SP, se o contribuinte tiver um SAT ativado, para a contingência... SP não aceita contingência off-line da NFCe

Leia a respeito do EAN13... Código interno (In store) deve sempre iniciar com '2'

Use outro formato que não seja EAN13... EAN13 segue normas... se você tentar imprimir um código que viola essas normas, terá problemas...

para sugerir modificações nos fontes, favor anexar as Units modificadas...

Não consigo compreender o problema... Por favor anexe imagens que demonstre o mesmo... Não podemos aplicar a modificação nos fontes, de fixar um novo valor de paperWidth.. isso irá afetar as aplicações que não usam esse tamanho...

Endrigo, Em ACBrECFVirtual.pas, Notei que você sugere mover o bloco de envio do desconto (abaixo), para antes da chamada de "VendeItemVirtual( ItemCupom );" { Se o desconto é maior que zero envia o comando de desconto/acrescimo de item anterior } if ValorDescontoAcrescimo > 0 then DescontoAcrescimoItemAnterior( ValorDescontoAcrescimo, DescontoAcrescimo, TipoDescontoAcrescimo); Isso causará problemas... o Desconto do Item será impresso antes da Venda do Item... Qual o motivo dessa modificação ? Em relação a ACBrECFVirtualNFCe.pas, já enviei para o SVN, com pequenos ajustes de endentação... Muito obrigado pela implementação...

O modelo sempre dependerá da linguagem que o equipamento aceita... no caso da Bematech... "ppEscBematech" O ACBrDevice tem suporte para portas TCP... portanto basta usar na Porta, uma String como: "TCP:ip_maquina:NumPorta" Exemplo: "TCP:192.168.0.10:9100"

A qual componente você se referindo ?? Já tentou ajustar em: ACBrSATExtratoFortes1.LarguraBobina ?

Por favor faça testes com a aplicação Demo do ACBrPosPrinter (PosPrinterTeste) Informe um passo a passo de como reproduzir o problema, usando essa aplicação.. Para impressão do Logotipo, você precisa "subir" o mesmo para a memória da Impressora, usando um aplicativo do fabricante

Como reproduzir o problema usando o Demo do ACBrNFe ?