Valdir Dill
-
Total de ítens
935 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Valdir Dill
-
-
11 horas atrás, Juliomar Marchetti disse:
Boa noite Valdir.
está falando em como alimentar cada registro? se for isso ele segue o mesmo padrão em todos.
agora se está falando que não sabe quais os dados que deve levar dai creio que deveria ser um contador.
Bom dia @Juliomar Marchetti,
Acho que consegui me encontrar, rs...
Não estava me achando porque estava tentando criar o registro 1300 no bloco 0. O correto é no bloco 1, certo? Por isso pensei que talvez não houvesse suporte ao registro 1300, mas consegui dar o tranco aqui, rs e agora vai.
Obrigado.
-
2
-
-
Boa noite,
Estamos precisando implementar a geração do SPED Fiscal para registros 1300, 1310, 1320, ...ou seja, são registros específicos para postos de combustíveis.
No demo do Acbr e mesmo fuçando no componente não encontrei muita coisa sobre isso. Só encontrei uma referência do registro 0206.
Gostaria de saber se algum colega poderia me auxiliar com algum exemplo. Um pontapé inicial já ajudaria.
Obrigado.
-
Perfeito. Esclarecido.
Obrigado.
-
1
-
-
28 minutos atrás, Daniel Simoes disse:
Você diz que a Impressão está ocorrendo mesmo que você não chame o método "Imprimir" ?
Em que momento que ocorre a Impressão ?
As linhas adicionadas no Buffer serão Impressas assim que algum dos métodos de Impressão, sejam chamados..
Você diz que a Impressão está ocorrendo mesmo que você não chame o método "Imprimir" ?
Exato. A impressão acontece assim que primeiro ACBrPosPrinter1.Buffer.Add('... é executado.Mas analisando melhor meu código, notei que estava com ACBrPosPrinter1.LinhasBuffer = 1
Se mudar para ACBrPosPrinter1.LinhasBuffer = 0, aí não imprime se não executar ACBrPosPrinter1.Imprimir(....É isso mesmo então? Ou seja, se ACBrPosPrinter1.LinhasBuffer = 1, então ACBrPosPrinter1.Buffer.Add(' inicia a impressão e, nesse caso, dispensa-se ACBrPosPrinter1.Imprimir(...?
Obrigado.
-
Bom dia,
Com base no demo do posPrinter utilizamos esse componente da seguinte forma.
ConfiguraACBrPosPrinter; //alimenta dados da porta, impressora, etc.
ACBrPosPrinter1.Ativar;
ACBrPosPrinter1.Buffer.Add('</zera>');
ACBrPosPrinter1.Buffer.Add('<n></ce>Título</n>');
ACBrPosPrinter1.Buffer.Add('</ae></linha_simples>')
ACBrPosPrinter1.Buffer.Add('Linha 1');
ACBrPosPrinter1.Buffer.Add('Linha 2');
ACBrPosPrinter1.Buffer.Add('Linha 3');ACBrPosPrinter1.Imprimir('', True, True, True, 1);
Está funcionando tudo ok.
A questão é que esta última linha ACBrPosPrinter1.Imprimir('', True, True, True, 1), se ela for executada ou não, não faz diferença, ou seja, a impressão ocorre de toda forma, mesmo que eu tirar/comentar essa linha.Pergunto:
- É isso mesmo ou estou fazendo algo errado?
- Se a impressão acontece, mesmo sem essa linha, então qual seria a função desse método ACBrPosPrinter1.Imprimir?Obrigado!
-
Bom dia,
Não foi com esse modelo de impressora, mas também passamos por isso.
Nosso problema foi corrigido acertando o modelo da impressora (ACBrPosPrinter1.Modelo). Estávamos setando ppTexto e mudamos para ppEscPosStar.
Veja se não é o caso também aí.
Abraços!
-
1
-
-
Boa tarde,
Só para dar um feedback aqui...
Conversei com o suporte Gertec e me informaram que o pareamento celular/G800 realmente não é possível.
Mas impressão direta, ou seja, com o aplicativo rodando no G800 é show. Nosso app já está funcionando 100%.
Obrigado.
-
2
-
-
12 minutos atrás, Juliomar Marchetti disse:
Valdir tenta entrar em contato direto com o Claudenir 011 9 8137 0262
Beleza @Juliomar Marchetti vou tentar isso.
Obrigado.
-
11 horas atrás, Daniel Simoes disse:
Ahh.. também verifique se foi corretamente fornecida as permissões de acesso ao BlueTooth, no Android...
HUmm.. acho que esse é o problema... a conexão BTH do Celular com o G800, não atua como se fosse uma impressora BlueTooth (nunca testei)...
Me parece que pode ser isso mesmo @Daniel. Percebi aqui que ao tentar parear um celular com o G800, ele (o Android) entende que é para fazer uma ancoragem, ou seja, para compartilhar o Wifi do aparelho. Tentei contato com o pessoal da Gertec, mas é bem complicado o suporte deles. To quase devolvendo o aparelho, rs..imagina indicar para nossos clientes isso, nem pensar.
Obrigado pelas dicas.
-
44 minutos atrás, Juliomar Marchetti disse:
Valdir é um Gertec isso?
Sim, isso mesmo @Juliomar Marchetti
E pior que instalando o app diretamente no TSG800, aí funciona. Mas seu eu executar o app no celular e tentar imprimir via bluetooth, aí dá esse erro que relatei.
Obrigado.
-
Boa noite,
Estou testando o AcbrPosprinter em Android e está ocorrendo um erro (print anexo).
Uso o demo do svn.
Erro: java.io.ioexception read failed socket might closed or timeout, read ret: -1
Ocorre no momento que que se clica no botão "Ativar" do app.
Obs.: no demo não fiz nenhuma alteração no código. A única coisa que faço no app em execução é selecionar a impressora bluetooth, que é um TSG800.
Alguma sugestão?
-
Boa tarde,
Não seria interessante que a "function IsWorkingDay(ADate: TDateTime): Boolean" da acbrUtil.pas considerasse também os feriados?
Anexo a função já pronta para apreciação e, se for o caso, implementação oficial.
Obrigado.
-
2
-
-
41 minutos atrás, Daniel Simoes disse:
Será que isso não é uma configuração no Driver do Fabricante do A3 ?
Eu também acredito que seja isso...alguma coisa no gerenciador do certificado talvez...
Mas não tivemos acesso à máquina do usuário para uma análise mais detalhada. Como foi um caso beeeem isolado, deixamos para lá e orientamos o usuário a comprar um A1 na próxima renovação de certificado, hehe!
-
1
-
1
-
-
Boa tarde,
Também temos um usuário onde isso acontece.
Num universo de centenas de usuários, apenas um único ocorre isso. Certificado A3.
A senha é alimentada tudo certinho no componente. Tanto é que em todos os demais usuários que usam o mesmo sistema, o processo de assinatura de XMLs ocorrem normalmente, ou seja, sem pedir a senha. Mas nesse único usuário, assim que o procedimento de assinar é acionado, abre-se a telinha do certificado para informar a senha. É como se não tivesse sido informada a senha no componente.
Obriagdo
-
1
-
-
23 horas atrás, Italo Jurisato Junior disse:
Bom dia Valdir,
Com certeza o problema é esse, em homologação a regra esta sendo executada pela SEFAZ, já em produção só a partir do dia 06/07/2020.
Experimente gerar os grupos faltantes e enviar em homologação.
Bom dia,
De fato, informei os dados e foi autorizado.
Obrigado.
-
1
-
-
Boa tarde,
Estamos testando (envio em homologação) a emissão de MDFe de CTe de lotação (apenas um documento) e estamos recebendo a rejeição: "726 - O grupo de informações da carga lotação deve ser informado"...
Pelas análises, constatamos que é pela falta das informações prodPred.infLocalCarrega.CEP e prodPred.infLocalDescarrega.CEP, as quais de fato não estão sendo alimentadas. Porém, segundo a NT 2020.001 versão 1.04, essa regra só vai ser aplicada a partir de 06 de julho próximo...
Porque será então que está acontecendo a rejeição?
Na NT diz que será aplicada em produção. Será que estamos tendo a rejeição porque estamos enviando em homologação?Em anexo arquivos de envio/retorno.
Obrigado.
289000007608599-pro-rec.xml 289000007608599-pro-rec-soap.xml 28200427818048000168580010000000511356219011-mdfe.xml
-
28 minutos atrás, Daniel Simoes disse:
Você deve distribuir as DLLs da pasta MinGW, apenas se usa em ACBr.inc as diretivas de compilação XMLSec e MinGW ligadas... O Padrão (no SVN) é ter elas desligadas..
Não precisamos mais da XMLSec, pois conseguimos reescrever em Pascal, os procedimentos que ela fazia... É com isso usamos apenas a LibXml2 (A XMLSec também usava a LibXml2)
Usando o padrão do ACBr.inc, copie apenas as DLLs das pastas:
http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.4/x86/
http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x86/
Ficou bem esclarecido.
Obrigado!
-
1
-
-
18 minutos atrás, valdirdill disse:
Bom dia,
...Hoje em dia eles não são mais necessários...
Não sabia disso, rs...Meu acbr.Inc está assim:
//{$DEFINE USE_MINGW}Então, pelo que entendi, desse jeito que estou fazendo, ou seja, com essa diretiva acima inativa, a distribuir ou não as .dll da pasta ...\DLLs\XMLSec\MinGW\32\ não nada. É isso?
Obrigado.
O texto anterior com a dúvida ficou truncado. Repito-o para melhor entendimento.
Então, pelo que entendi, desse jeito que estou fazendo, ou seja, com essa diretiva acima inativa, eu distribuir ou não as .dll da pasta ...\DLLs\XMLSec\MinGW\32\ não muda nada. É isso?
-
11 horas atrás, Daniel Simoes disse:
Você compila com suporte XMLSec e MinGW, no ACBr.inc ?
Hoje em dia eles não são mais necessários, e remove-los da compilação, pode simplificar muito a distribuição do seu sistemaBom dia,
...Hoje em dia eles não são mais necessários...
Não sabia disso, rs...Meu acbr.Inc está assim:
//{$DEFINE USE_MINGW}Então, pelo que entendi, desse jeito que estou fazendo, ou seja, com essa diretiva acima inativa, a distribuir ou não as .dll da pasta ...\DLLs\XMLSec\MinGW\32\ não nada. É isso?
Obrigado.
-
Boa noite,
Gostaria de entender melhor essa questão das .dll que estão disponíveis no svn. Gostaria de entender melhor para que eu possa também distribuir os arquivos corretos e apenas eles.
Me refiro mais especificamente às .dll openSSl.Vamos lá:
Na pasta ..\DLLs\OpenSSL\1.0.2.21\x86\ temos duas bibliotecas:
- ssleay32.dll - versão 1.0.2.21
- libeay32.dll - versão 1.0.2.21Já na pasta ..\DLLs\XMLSec\MinGW\32\, temos as mesmas bibliotecas, porém em outra versão:
- ssleay32.dll - versão 1.0.2.5
- libeay32.dll - versão 1.0.2.5As dúvidas são:
1) Como esses dois arquivos estão duplicados (em duas pastas do repositório), quais desses arquivos devo utilizar no meu binário e também distribuir com a aplicação?2) Neste tópico - https://www.projetoacbr.com.br/forum/topic/55737-fontes-do-acbr-já-suportam-openssl-111/?tab=comments#comment-365585 - recomenda a atualização dessas .dll e nele menciona que os arquivos ssleay32.dll e libeay32.dll mudaram para libssl-1_1.dll e libcrypto-1_1.dll, respectivamente.
No caso de eu passar a utilizar os novos arquivos versão, não devo mais usar/distribuir os ssleay32.dll e libeay32.dll, é isso?Obrigado
-
12 minutos atrás, Juliana Tamizou disse:
Bom dia.
Creio que seja algo que foi discutido no chat dos assinantes do SAC Anual, onde as 3 primeiras posições não eram de fato livres e se fosse enviado 8 dígitos os 3 primeiros acabavam sendo ignorados.
Relativo aos problemas que vc está tendo, por favor seja mais especifico, quais seriam?
Att.
Bom dia
24 minutos atrás, Juliana Tamizou disse:Bom dia @Juliana Tamizou
Vou me intrometer no post, pois tive problemas também nessa alteração nas rotinas do Acbr Sicredi. Eu acabei nem abrindo um tópico porque contornei a situação, a qual explico abaixo.É o seguinte: não sei é o mesmo problema/situação que o colega @marcianobandeira está enfrentando, mas nós aqui fazíamos assim:
Tomemos com exemplo o boleto número 57
Antes dessa atualização, enviávamos para o campo nossonumero do componente o número já formatado no padrão Sicredi. Desta forma: 20 2 00057 (sem os espaços, é claro).
Esse valor 20200057 também era gravado no BD local para controle depois da leitura das baixas e localização à qual conta a receber pertence cada boleto.
Porque é feito essa gravação com o número completo no padrão Sicredi? Porque a orientação do Sicredi é que a cada ano o usuários reinicie esse sequencial do boleto.
Então, no futuro, teremos o boleto 20200057 e 21200057. Se gravarmos apenas o sequencia do boleto, ficariam DOIS títulos com o mesmo número 00057, o que logicamente, daria problemas lá na frente.Até antes desta atualização do Acbr, o nossonumero era alimentado nesse padrão de 8 dígios e tudo certo. Porém, como agora o tamanhomaximo ficou igual a 5, ao gerar o boleto, dá o erro.
Aqui contornamos isso da seguinte forma:
- Ao alimentar o componente, nossonumero := 00057
- No BD gravamos 20200057
- Quando vamos tratar as baixas, fazemos um copy dos 5 últimos digitos do campo do BD e tudo certo.Espero ter sido claro na minha esplanação.
Obrigado.
-
1
-
-
Bom dia,
A NT 2016.002 v140 excluiu a tag/campo IPI.clEnq da NFe.
Não seria o caso de excluir também essa property no Acbr para evitar dúvidas?
Obrigado.
-
2
-
-
Boa tarde,
Estou com uma dúvida sobre valores de pagamentos/duplicatas em NFe.
Exemplo: em uma venda de R$ 90,00:
- R$ 30,00 recebidos em dinheiro no ato da venda;
- R$ 60,00 em 3 parcelas de R$ 20,00 com vencimentos futuros.A duvida é como informar o grupo duplicatas na NFe.
Deve ser informado 4 parcelas (uma de 30,00 e outras 3 de R$ 20,00) e o valor da fatura (vLiq) no total da nota (R$ 90)?
Ou deve-se informar 3 parcelas de R$ 20,00 e valor da fatura (vLiq) no valor de R$ 60,00?Há uma forma correta ou ideal para se informar esses dados?
Obrigado
-
1 hora atrás, Italo Jurisato Junior disse:
Bom dia Valdir,
O problema é que esse provedor não retorna o XML da NFS-e, se você abrir o XML de retorno vai notar que existe uma tag chamada: link_nfse.
O conteúdo dessa tag é um link que ao meu ver você deve encaminhar para o tomador do serviço por e-mail.
Ele ao abrir esse link através de um navegador vai ver o DANFSE e poderá imprimir.
Infelizmente não tem muito o que fazer.
Bom dia,
Ok, obrigado @Italo Jurisato Junior
-
2
-
NFSe - Nome de Arquivo ini fora do Padrão
em DFe - Documentos Fiscais Eletrônicos
Postado
Boa tarde,
Se eu fizer ProvedorToStr(proFISSLEX), vai retornar FISSLEX.
Porém, o arquivo .ini desse provedor na pasta dos arquivos está assim FISSLex.ini.
No nosso sistema fazemos assim: hospedamos os .ini todos no nosso servidor. Aí, no sistema, temos a rotina que define o nome do arquivo para download, conforme for a cidade/provedor do usuário. Porém, se tentar baixar o arquivo FISSLEX.ini, não vai existir, já que a url para donwload é case sensitive.
Reparei que os demais provedores estão no padrão correto, ou seja, se o nome do provedor é BHISS, por exemplo, tudo maiúsculo, o arquivo .ini também será BHISS.ini. Se for parte minúsculo, essa parte também será minúsculo no nome do arquivo.
Sugiro que essa função ProvedorToStr da pnfsConversao.pas tenha o texto FISSLEX alterado para FISSLex ou então mudar o nome do ini para FISSLEX.ini.
Obrigado.