luisArruda

Obrigado Italo, entrei em contato com o contador e identificamos que o cliente estava utilizando o CNPJ da loja errada, como é inicio de implantação ele nem emitiu nenhuma nota ainda, então menos mal, o CNPJ correto dele é RPA então vai utilizar CST e não CSOSN, problema resolvido. Peço desculpas pela dúvida besta,e novamente obrigado.

Italo, bom dia. 1. Agora estou indicando o indFinal. 2. Quanto ao IPI era um problema de validação do meu sistema, já corrigi. 3. Nesse caso o contador do meu cliente solicitou para utlizar o CSOSN 102, o eu que achei estranho é que mesmo utilizando CSOSN a mensagem é de CST incompatível, mas eu não envio CST no XML. mesmo indicando o indFinal o retorno prossegue "Rejeição: CST incompatível na operação com Não Contribuinte", tem alguma ideia do que mais possa ser? Estou utilizando Delphi 2010 na revisão 10489 do trunk2, aqui o xml teste2.xml novo, com as alterações.

Boa tarde. Estou tentando emitir uma nf-e para um cliente com CPF, e obtenho a seguinte mensagem: "Rejeição: CST incompatível na operação com Não Contribuinte [nItem:Object reference not set to an instance of an object.]" No caso, meu cliente é simples nacional e estou utilizando o CSOSN 102. Alguém tem ideia do que estou fazendo de errado? Em anexo o xml da nota que estou tentando gerar teste.xml Desde já agradeço. []'s

Daniel, você tem razão, acabei de testar o em um Elgin i9 o code128c (ela consegue imprimir os 44 caracteres sem quebrar a linha), então o código correto é como você implementou mesmo: ChaveEmUmaLinha := (ImprimeChaveEmUmaLinha = rSim) or ((ImprimeChaveEmUmaLinha = rAuto) and Suporta128c); É alguma coisa da t81 o fato de não conseguir, vou implementar uma configuração no meu sistema mesmo para contornar essa impressora, em todo caso voltei como estava, deixei somente a implementação do segundo qrCode no cancelamento. ACBrSATExtratoESCPOS.pas

Minha ideia foi só manter em uma linha caso a impressora não suporte 128c, IF linear com false é um problema mesmo... ou assim para forçar a divisão da linha com 128c, porque ele realmente não conseguiu imprimir esse código de barras. ChaveEmUmaLinha := (ImprimeChaveEmUmaLinha = rSim) or (ImprimeChaveEmUmaLinha = rAuto); if (Suporta128c = False) then ChaveEmUmaLinha := False

Segue a unit alterada. ACBrSATExtratoESCPOS.pas

Daniel, atualizei o código e verifiquei a alteração que você fez, esta é a imagem do resultado: http://imgur.com/kEu5Ukr Solicitei um manual técnico ao suporte da Epson, mas infelizmente eles me informaram não possuir tal documento. Tomei a liberdade de alterar o ACBrSATExtratoESCPOS.pas, fiz a quebra das linhas e implementei no segundo código de barras do cancelamento a mesma lógica que você utilizou para passar o code128, o resultado http://imgur.com/6oa4oz7 Não estou conseguindo fazer o upload do .pas para você verificar (Você só tem permissão para fazer o uploade de 2mb.) vou tentar na próxima publicação.

Daniel, atualizei os componentes, pelo demo do ACBrPosPrinter sem precisar configurar nada mais, ele imprimiu correto, imprimiu o 128B (apenas 20 caracteres, mas sem problemas quanto a isso, pois a impressora suporta o 128b mesmo) Agora no ACBrSATExtratoESCPOS como pode ser visto no log ( log_ImprimeChaveEmUmaLinha_rAuto.txt), ele enviou o 128c, mas não quebrou a linha de forma automática, por isso não imprimiu (só cabem 22 caracteres no 128c e o código tem 44) Configurando a propriedade ImprimeChaveEmUmaLinha para rNao percebi que ele consegue dividir a linha, mas nesse caso é usado o 128b (que só aceita 20 caracteres, ele envia 22 - meio código de barra - log_ImprimeChaveEmUmaLinha_rNao.txt) Se precisar de mais algum teste, só pedir. []'s

Daniel, deu certo o 128c, ele conseguiu imprimir até 24 caracteres. Agora, acha possível essa implementação no ACBrSATExtratoEscPos, de uma forma que não atrapalhe as outras impressoras? talvez uma propriedade para informar o tipo do código de barras?

Como <code128c> ele consegue imprimir se o texto tiver até 12 caracteres (em anexo o log, um item com 12 e outro com 13), mas com o código abaixo ele imprime até 22 caracteres Write(impressora, #29#107#73#13'{C'#35#15#07#61#09#90#08#00#01#41#59); log_correto.txt

Daniel, segue o arquivo de log log.txt

Boa tarde a todos. Sei da existência de zilhões de outros posts do assunto, mas nenhum relacionado a TM-T81 (ela se comporta de uma forma um pouco diferente da T20 da EPSON - pelo visto). Utilizo: Delphi 2010 + trunk2 (commit 10280) | Epson TM-T81 (USB) Utilizando o componente ACBrSATExtratoESCPOS (ligado a um ACBrPosPrinter) para fazer a impressão pelo compartilhamento (\\localhost\epson), ele não imprime o código de barras no extrado do SAT, fica um espaço em branco mesmo. Já testei em outra impressora i9- ELGIN e em uma TM-T20 - Epson configurada com o modelo ppEscPosEpson e o código de barras saiu normalmente. Verifiquei com o pessoal da Epson o que poderia estar incorreto para esta impressora, e me foi passado um exemplo básico, no qual o código de barras é impresso: procedure TForm1.Button1Click(Sender: TObject); var impressora : TextFile; begin Assignfile(impressora, '\\dev01\EPSON_USB'); Rewrite(impressora); Writeln(impressora, #29#119#2); //Seta o tamanho do código de barras Writeln(impressora, #29#72#1); //Seta o tamanho do código de barras Writeln(impressora, 'CODE128C'); Write(impressora, #29#107#73#13'{C'#35#15#07#61#09#90#08#00#01#41#59); //CODE128C Write(impressora, #10); //Line Feed - Imprime texto Write(impressora, #29#107#73#13'{C'#90#00#00#83#00#00#44#24#22#64#50); //CODE128C Write(impressora, #10); //Line Feed - CloseFile(impressora); end; Enquanto código da função ComandoCodBarras da unit ACBrEscPosEpson.pas: 1a Linha: #$1D'w'#2#$1D'h('#$1D'H'#0#$1D'kI'#$18'{B3515076109900800014159' 2a Linha: #$1D'w'#2#$1D'h('#$1D'H'#0#$1D'kI'#$18'{B9000008300004424226450' Fora o código de barras os outros comandos estão funcionando perfeitamente (inclusive fiz os testes no exemplo do ACBrPosPrinter, fora o code128, ficou tudo bonito - Parabéns o/) Agradeço desde já o auxilio []'s

Foi isso mesmo, obrigado Juliomar.

Boa tarde, Desinstalei o ACBr antigo do meu Lazarus, atualizei o repositório (trunk2) e quando vou tentar instalar novamente obtenho este erro: "ACBrUtil.pas(52,43) Fatal: Cannot find synautil used by ACBrUtil, incompatible ppu=C:\lazarus\components\acbrtrunk2\Lib\Lazarus\synalist\i386-win32\synautil.ppu, package laz_synapse" Tenho também na mesma máquina o ACBr com o delphi 2010, mas cada instalação fica em um diretório distinto, um ACBr pro delphi e um pro Lazarus. Alguém sabe me dizer como sanar este problema?

Boa noite. Consegui chegar até essa parte, dai pra frente creio que seja necessário estar logado no portal. http://www.sped.fazenda.pr.gov.br/modules/conteudo/conteudo.php?conteudo=103

Daniel, você já ouviu falar do Tapatalk? Eu sei que o IPB 3 tinha o plug-in dele, agora o 4 não tenho certeza. http://forum.sosinvision.com.br/index.php?/topic/40847-download-tapatalk/ Por favor veja se é possível habilita lo, ele é uma mão na roda, facilita muito a vida dos fóruns. []'s

Boa noite galera. Na geração da URL do qrCode da NFC-e (uf=SP em homologação com Lazarus e trunk2 em esc/pos) a função LerServicoChaveDeParams (ACBrDFe.pas) adiciona um "_" no final do NomeServico 'URL-QRCode', impossibilitando assim que sejá encontrado o servico no ACBrNFeServicos.ini. alterei o meu INI para testes e adicionei o "_" nele, feito isso na mesma função ele não passa por esse if (linha 342) if Versao > 0 then URL := FPIniParams.ReadString(NomeSessao, Chave, '') então fiz a seguinte alteração if (Versao > 0) or (Chave = 'URL-QRCode_') then URL := FPIniParams.ReadString(NomeSessao, Chave, '') Feito isso o qrCode se tornou "acessavel", estou anexando caso seja necessário o XML que gerei: cfenfce.xml Apenas lembrando que não consegui verificar se o mesmo já foi corrigido, pois o S.F. ainda está fora do ar. []'s

o Invision 4 ficou realmente bonito, mas essa pesquisa dele com "like or like" atrapalha demais

Italo, muito obrigado, era isso mesmo. Vou até dormir feliz agora..rsrs []'s

Olá (boa noite). Antes de tudo, encontrei várias posts com esse assunto, mas mesmo assim não consegui solucionar tal problema. Estou tentando pelo demo em Delphi 2010 no "trunk"(commit 9540) emitir uma nfc-e (moNFCe, ve300) e obtenho essa mensagem "URL não disponível para o estado solicitado." Meu certificado é de um cliente de SP (35). Verifiquei fazendo um debug que na função GetURLSP o valor da variável ALayOut está definido como LayNfeRecepcao, teoricamente isso não deveria acontecer (entendo eu), pois não existe esta opção no case da função, alguém sabe me dizer o que não configurei? Estou anexando meu arquivo de configuração do demo. Desde já agradeço. ACBrNFe_demo.ini

Opinião totalmente pessoal, tenho aqui um da DIMEP e um da URANO, o da DIMEP me pareceu bem mais comodo de se trabalhar, o da URANO perdia a comunicação com o computador do nada, era necessário reiniciar o equipamento com frequência, mas também devido a correria, não entrei em contato com o fabricante para tentar solucionar o ocorrido.

Armando, boa tarde, ainda não estou com clientes rodando, mas encontrei esse gerador da TANCA http://www.tanca.com.br/assets/conteudo/drivers/TS-1000/Gerador_Código_Vinculação_TS-1000.zip aparentemente a geração está correta.

Obrigado Daniel, debugando percebi que provavelmente estou gerando o arquivo errado mesmo, amanhã vou verificar quando estiver com o sat em mãos. Obrigado novamente. []`s

Daniel boa noite. Ao executar o comando e mandar imprimir obtenho a mensagem: "Nenhum CFe carregado na memória." Normalmente utilizo o delphi, mas como precisei do código do trunk2 pra impressão ESC/POS instalei e estou o Lazarus (que offtopic nunca tinha mexido, mas já achei o máximo, fiquei fascinado). Resumindo: * Com trunk no delphi 2010 gero a venda e capturo o valor do xml com "sat.CFe.AsXMLString" (salvo em banco e não em pasta - optei por um gerenciador/servidor de vendas para o sat) * Com trunk2 no Lazarus busco essa informação no banco, crio um arquivo xml local e leio com o comando abaixo: ACBrSAT1.CFe.LoadFromFile('D:\projetos\executaveis\xml\sat\CFe9999999.xml'); ACBrSAT1.ImprimirExtrato; Estou certo em utilizar o AsXMLString dessa forma? fiquei na dúvida por esse tópico: Tentei fazer o carregamento do xml tanto pelo demo no lazarus (trunk2) como pelo demo no delphi(trunk) como por uma aplicação vazia apenas com os componentes na tela em ambos e também obtive a mesma mensagem. Estou anexando o xml que tenho gerado aqui.CFe9999999.xml []'s

Não sei o motivo, mas meu delphi não recriar o arquivo "ACBr_Comum.res" quando abro o dpk, ele avisa que vai criar, mas não cria. Fiz uma alternativa que com certeza não deveria fazer, mas pra teste tudo é válido... Peguei o arquivo ACBrComum.res do trunk e renomeei para "ACBr_Comum.res" a instalação pelo dpk funcionou, e os outros pacotes que utilizo também não geraram erros, exceto o danfe em fast, (parece ser algo da refatoração que está em andamento) Em todo caso vou voltar para o trunk por hora, obrigado pela ajuda Isaque e Daniel. []'s