Painel de líderes

Elton, é por isso que o Daniel nivelou antes o sLineBreak para somente F: function AjustarQuebrasLinhas(const ATexto: String; NovaQuebraDeLinha: String = ';'): String; begin Result := Trim(ATexto); if Result <> '' then begin // aqui se a quebra de linha for diferente de #10(F) o #13#10(sLineBreak) e transformado somente em #10 if sLineBreak <> LF then Result := StringReplace(Result, sLineBreak, LF, [rfReplaceAll]); // aqui a nova quebra de linha e alterada para o que o usuário deseja Result := StringReplace(Result, LF, NovaQuebraDeLinha, [rfReplaceAll]); end end;

Cara, eu entrei em contato com a homologadora da Universidade Federal de Goiás (UFG), onde moro, e o que eles disseram é que a SEFAZ de Santa Catarina mandou um oficio "desobrigando" a utilização do Bloco X da ER 02.03, por enquanto. Segundo eles não está totalmente completo os requisitos do Bloco X, pois para enviar os arquivos dos itens 20, 21 e 22 do Requisito VII, é preciso de um servidor do estado ou nacional, não sei, para recepcionar os arquivos. Estou no aguardo para ver o que mais sai. Esse site https://www.legisweb.com.br/ passa informações diariamente de alterações nacionais e estaduais importantes. Nele achei a nova ER, e estou acompanhando também. Tem esse documento https://www.confaz.fazenda.gov.br/legislacao/atos/atos_cotepe/2015/ato-cotepe-icms-23-15 , oficial da CONFAZ, no fim dele tem uma sitação... “§3º Em relação a versão 02.03 da ER-PAF-ECF, poderá ser publicado, excepcionalmente em 2015, mais de um Ato COTEPE para sua complementação, exclusivamente em relação a requisitos do Bloco X ou por ele afetados, e ainda de PAF-ECF ou Sistema de Gestão utilizados para controles das empresas de transportes de passageiros.” Art. 3º Este ato entra em vigor na data de sua publicação no Diário Oficial da União, produzindo efeitos a partir do primeiro dia do segundo mês subsequente ao da publicação. Vamos ver o que vai dar...

É a última. Parece que hoje ou amanhã já volta ao normal pelo que está no twitter.

Boa noite Welkson, Quanto a compilação não posso te ajudar pois sempre pego as DLL's já compiladas que ficam no repositório. Os Interops são gerados com base no fonte em C#, através do projeto CBrFramework\ACBrFramework.Net\ACBrDefExporter. Com base neles são construidas as cascas para acesso ao componente. Obs.: Há um projeto engatilhado com a parte de arquivos: AAC, EAD, PAF, Sped Fiscal, Contribuições, Contábil e Sintegra, que será nativo, sem a necessidade de acessar via JNI. Att.,

Tiago, Não entendi: "Esse webservice não tem lógica". Você leu a Nota Técnica que trata sobre esse Web Service? O NFeConsDest só serve para o Destinatário, por outro lado o NFeDistribuicaoDFe pode ser usado tanto pelo destinatário quanto pelo emitente da nota. Se o destinatário se manifestar sobre uma nota, o emitente da mesma quando realizar uma consulta usando esse web service terá como retorno a manifestação feita pelo destinatário. Se a manifestação for do tipo Operação concluída, isso significa que o destinatário já recebeu a mercadoria. Temos ai o Canhoto eletrônico. Desculpe, mas quem diz que esse web service não tem lógica, realmente não conhece nada sobre ele.

Boa tarde a todos, Tiago, Cantu esta coberto de razão, não se deve automatizar isso. Desta forma você esta informando a SEFAZ que comprou da empresa XYZ sendo que na verdade essa empresa esta dando um golpe. Melhor você repensar sobre o assunto.

Hasa, Só lembrando que o SDK-1000 da Tanca não necessita de ativação e associação, ele ja sai ativado e associado de fabrica com dados pré configurados (vide Quick Guide SDK-1000).

Do Jeito que você falou deu certo Fernando, Muitíssimo obrigado

Bom dia ! conforme nosso amigo falou acima e conforme conversa com o órgão técnico da UnoChapeco segue na integra: sim, conforme orientação não iremos cobrar neste instante porque a qual não está totalmente finalizada

Bom dia Tiago, Sim o NFeConsDest vai ser desativado, e sempre peço para utilizarem o DistribuicaoDFe. Lembre-se se trata de uma minuta não é a versão final do manual e com certeza contem erros ou algo que não deveria ser mais colocado, pois não existe mais.

Acredito que seja igual a NFe, devemos enviar os XMLs....

Olá, sobre esse deslocamento do cabeçalho fizemos uma alteração que contornou o problema, a alteração foi simples, basta retirar o "AutoSize" dos componentes "TRLImage" na unit TACBrSATExtratoFortesFr e ajustar a propriedade "Width" do "TRLImage" diretamente no fonte em "runtime" quando existe uma imagem. Contornamos um bug que o componente "TRLImage" apresentou porque não era esperado que se deslocasse. Anexei os fontes alterados mas eles tem mais alterações do que somente isso, porque estamos trabalhando com o trunk e fizemos merge de alguns pontos do trunk2, basta se concentrar nas alterações relacionadas ao logo o restante pode ser ignorado. ACBrSATExtratoFortes.zip

Bom dia André, Essa alteração eu até tinha feito, mas depois foi removida e feita de uma outra forma. Assim que normalizar o SVN por favor atualize os seus fontes novamente.

Ainda não. Quando o SAT é ativado estes campos de observação ainda são enviados pela Sefaz com este conteúdo de xCampo1 e xTexto1. Lembrando que estes dados são enviados pela Sefaz no arquivo de "Parametrização de Uso", quando o SAT é ativado. A Sefaz pode atualizar este arquivo de parametrização a qualquer momento e mudar este conteúdo para uma string de até 255 caracteres. Sugestão: deixem prevista esta área de 255 caracteres. Att Cristiano Abbud

Você não tem que alterar os fontes, tem é que configurar corretamente o componente para usar em produção. ACBrNFe1.Configuracoes.WebServices.Ambiente := taProducao ACBrNFe1.Configuracoes.WebServices.Ambiente := taHomologacao;

Não lembro de ver nada na ER e não encontrei nada lendo que obrigue a gravação disso em formato binário. Existe sim quais dados devem ser gerados nos arquivos, mas nada falando sobre salvá-los em um formato específico.

O meu problema é que minha aplicação é um Serviço do Windows, mais precisamente um servidor datasnap como serviço do windows, ele possui um EXE que foi instalado como serviço, esse serviço datasnap é acionado pela minha aplicação, executável que fica local em cada terminal da loja, no entanto ja tentei colocar o bemasat.xml em todos os locais possível, coloquei na System32, na SystemWow64, no diretório do EXE do meu Serviço Datasnap, no diretório do exe da minha aplicação e nenhum deles surtiu resultado utilizando o serviço, então por hora até eu encontrar uma outra solução o RB-1000 só vai rodar na minha aplicação localmente 1x1... mais não vou desistir nunca!!! Se eu encontrar uma solução posto aqui. Boa tarde a todos. Eu também desenvolvi um serviço de comunicação com equipamentos SAT. Já fiz para SWEDA e BEMATECH. No SWEDA foi mais tranquilo, tudo funcionou praticamente de primeira. Já com a Bematech, tive vários problemas, tanto para ativar quanto para comunicar com o equipamento através de serviço. Só consegui suporte da Bematech após abrir uma reclamação no ReclameAqui, pois o SAT não ativava de jeito nenhum, igual aos posts anteriores deste mesmo tópico. Praticamente o que resolveu foi colocar o SAT diretamente na conexão da internet, ou seja, sem nenhum proxy ou firewall (mesmo desativado), e principalmente setar um IP fixo para o equipamento, no caso, o mesmo que o DHCP atribuía. Quanto a comunicação com o SAT Bematech, em aplicativo funciona sem problemas, porém via serviço o erro mera sempre o mesmo: "Erro na abertura da porta de comunicacao com o S@T". Consegui resolver quando coloquei tanto a DLL quanto o XML na pasta SysWOW64 do windows (8 - 64 bits) e EXCLUIR essa DLL de todos os outros lugares, "obrigando" o serviço a utilizar a DLL do sistema, pois se mantenho a DLL no diretório do exe serviço instalado, ele ainda dá esse erro. Espero ter ajudado! Abraços, Júnior Áli ALITEC Soluções Inteligentes www.alitecsolucoes.com.br Vou fazer o teste aqui... tentei colocar na Syswow64 mais não removi dos outros lugares.

Boa tarde, Vi que o tanto o trunk1 quanto o trunk2 trazem um método para identificar erro correto durante a validação do XML na operação de venda. Fiz algumas adições de códigos nesse método que estavam faltando, baseando-se na versão do trunk2. Pela minha conferência agora o método contempla todos os códigos da ER do SAT. Se for interessante, atualizem no código fonte do ACBr. MotivoInvalidoVenda.pas

Concordo Daniel, eu fiz pensando somente em windows, falha minha. Vou acertar aqui e gerar novo patch. Novo patch com a sugestão do Daniel. quebradelinhadfe.patch

Oi REgys, Apenas uma sugestão... CR (#13) não é sinônimo de quebra de linha (Carriage Return) LF (#10) sim... é a quebra de Linha (Line Feed) No Linux a quebra de linha é apenas LF ou #10 Minha proposta para essa function seria algo mais genérico e que pudesse estar na ACBrUtil function AjustarQuebrasLinhas(const ATexto: String; NovaQuebraDeLinha: String = ';'): String; begin Result := Trim(ATexto); if Result <> '' then begin if sLineBreak <> LF then Result := StringReplace(Result, sLineBreak, LF, [rfReplaceAll]); Result := StringReplace(Result, LF, NovaQuebraDeLinha, [rfReplaceAll]); end end;

Ítalo bom dia obrigado por me dar retorno e desculpe a a demora em retornar tive imprevistos. consegui gerar o qrcode, revisei a função e vi que estava passando parametros errado corrigi e consegui gera-lo no fortesreport so tive um problema: passei o primeiro parâmetro com código do estado 13 que se refere Amazonas que é servidor que uso para testes so que a funçao estava recebendo 31 que é o estado de minha origem - Minas Gerais. notautil.GetURLQRCode('13', ide.tpAmb, procNFe.chNFe, dest.CNPJCPF, Ide.dEmi, total.ICMSTot.vNF, total.ICMSTot.vICMS , procnfe.digVal, DM2.ACBrNFe1.Configuracoes.Geral.IdToken , DM2.ACBrNFe1.Configuracoes.Geral.Token ); consegui gerar o qrcode pois alterei na função o endereço da sefaz de minas que não havia nada preenchido e coloquei da sefaz de amazonas , só para efeito de testes. Irei rever isto também , por enquanto obrigado pela suas ajudas.

Bem, o problema é no Source Forge e nos da equipe ACBr não podemos fazer nada quanto a isso, eles estão trabalhando para repor a infra-estrutura e liberar tudo o mais rápido possível, mas como tudo em tecnologia não é simples. Para minimizar o problema publiquei um artigo no meu blog, nele você encontrará um link para um repositório no google drive com os fontes atualizados. https://regys.com.br/problemas-com-repositorio-acbr/ Bom dia, Régys é verdade, tratando-se de tecnologia não é brincadeira, tem coisas que pensamos que será rápido é fácil. Mais meus parabéns pela iniciativa de criar uma alternativa para baixar os fontes do ACBr, é como eu disse aqui nos estamos indo tudo bem. Mais hoje em dia, não sei os outros programadores, mais o ACBr se tornou fundamental para nós, tanto é que quando o Daniel em um dos seus post disse que não iria mais atualizar o TRUNK ficamos "Doidos" e procuramos logo nos adaptar. Vocês sem demagogia nenhuma estão de parabéns!

Bem, o problema é no Source Forge e nos da equipe ACBr não podemos fazer nada quanto a isso, eles estão trabalhando para repor a infra-estrutura e liberar tudo o mais rápido possível, mas como tudo em tecnologia não é simples. Para minimizar o problema publiquei um artigo no meu blog, nele você encontrará um link para um repositório no google drive com os fontes atualizados. https://regys.com.br/problemas-com-repositorio-acbr/

Bom dia Osmar, Da mesma forma que vocês estão ansiosos e muitos preocupados com essa situação, pois não conseguem baixar atualizações e nós, que queremos atualizar o repositório com as correções e também não podemos. Vai ai um puxão de orelha para todos: se baixassem as atualizações diariamente (manhã e tarde) a posição seria do dia 16/07, mas muitos esperam a água bater na .... para correr atrás. Tem uns que me perguntaram se o método DistribuicaoDFe esta descompactando automaticamente o conteúdo da TAG docZip, sendo que o meu último teste de descompactação utilizado no método acima foi em março/2015. Isso me leva a crer que tem pessoas que faz 3 meses ou mais que não atualiza os fontes e agora com esse problema fica desesperado.

Se o ERP faz parte do PAF-ECF então vai precisar. Se não me falha a memória, a legislação menciona especificamente que se o programa gerencial fizesse qualquer uma das características do PAF-ECF então deveria seguir a legislação. Mas o melhor mesmo é você entrar em contato com quem fez ou vai fazer sua homologação PAF-ECF.

bem aqui resolveu, mas nem lembro pq está da seguinte forma: ecf.addOnMsgPoucoPapel(new ACBrEventListener<EventObject>() { @Override public void notification(EventObject e) { } }); ecf.addOnAguardandoRespostaChange(new ACBrEventListener() { @Override public void notification(EventObject e) { } });

Boa noite Jackeline, Seu jar deve estar desatualizado. Atualizei os fontes em: https://svn.code.sf.net/p/acbr/code/ACBrFramework/jACBrFramework/jACBrFramework/, e gere uma nova lib. Além disso atualize a DLL que é utilizada como wrapper para a biblioteca em: https://svn.code.sf.net/p/acbr/code/ACBrFramework/ACBrFramework/x86/cdecl/ACBrFramework32.dll. José Mauro

Boa tarde Jackeline Santos, Creio que o método que você esteja procurando seja: saveFileTXT_TITP. Verifique por favor a classe em anexo e veja se atende o que você precisa. Att., José Mauro ProgramTestPaf.zip

Você pode utilizar tanto a forma separada quanto agrupada, desde que passe ao componente corretamente a forma de pagamento é o valor. No caso do seu log, você enviou duas vezes a forma de pagamento 03, sendo uma no valor de 1,00 e outra no valor de 1.29, mas ao abrir o vinculado informou forma de pagamento 03 e o valor de 2.29, por isso a impressora não encontra a forma de pagamento para vincular. Ou você envia tudo somado, ou envia um a um os vinculados. O erro ocorre, porque ao tentar abrir o vinculado, ocorre o erro, então o componente entende que houve problemas de impressão no vinculado e inicia a impressão do ticket tef em relatório gerencial como manda o roteiro, mas nesse caso o erro não foi no vinculado, mas sim na forma de enviá-lo.