Cleber Ferreira

Bom dia,
 
Eu acho que deve estar acontecendo com voce o mesmo que acontecia comigo. Eu não utilizo ACBrMonitorPlus, mas sim o componente ACBrECF. Ao enviar comando da X, a ECF já inicia sua emissão, mas o ACBrECF não aguarda retorno, até pq não caberia aguardar retorno mesmo na minha opiniao. Como o componente não aguardar o termino da X, o comando de suprimento já era enviado logo em seguida, ainda com a X sendo impressa o que ocasionava erro.
No meu caso coloquei, já que uso componente, coloquei sleep de alguns segundos para garantir o termino da impressão da X.
Pra voce, creio que poderia fazer algo parecido antes de enviar o comando de suprimento para o ACBrMonitorPLUS.
 
Espero ter ajudado.

Boa noite,
Existe o componente ACBrConvenio115 que gera as notas modelo 6, 21 e 22. Baixe os fontes e irá ver que existe um aplicativo de exemplo incluindo impressão das notas.

Bom dia,
Eu estava tendo esse problema com o provedor WebISS. O xml era enviado, mas como o time do componente estava baixo não dava tempo do webservice retornar a autorização. Tinha que disparar a consulta depois. Aí fui nas propriedades do ACBrNFSe e aumentei o numero de tentativas e o intervalo entre cada consulta. Depois disso, passou a funcionar perfeitamente.

Bom dia!
 
Eu utilizo Zeos em todos os meus projetos em Delphi. Nunca tive problemas com o componente em si. É simples utilizar e possui compatibilidade com diversos DB's do mercado. O que você precisa fazer é analisar quais recursos vc utiliza no IBX e simular no Zeos.
Eu particularmente acho o Zeos mais objetivo. O FireDAC é ótimo também, inquestionável (ainda mais pra trabalhar com Rest e JSON), mas tem que carregar outros componentes junto além de declarar certa quantidade de classes também.

Bom dia!
 
O Homologador disse que esse teste é para realmente verificar o máximo de linhas que a ECF consegue imprimir e que, portanto não tem problemas se não tiver alcançado as 500 linhas na impressao.

Bom dia Regys
 
Então, acabei de ligar na SEFAZ e a atendente tentou me ajudar ao máximo. Mas segundo o que lemos, a obrigatoriedade de NFC-e já está valendo, com ressalva de casos específicos. Já para comercialização, não encontramos nada a respeito (cadastro da softwarehouse ou do aplicativo em si).
Você já teve experiencia de comercialização no MT?

Bom dia!
 
1º passo: instale o driver compativel no windows server
2º passo: instale o driver compativel no pc local onde será feito o acesso
3º passo: nas configurações da Conexão de Área de Trabalho Remota, na aba Recursos Locais, clique no botão Mais... e em seguida marque a opção para Cartões Inteligentes.
4º passo: realize o acesso remoto e verifique se o certificado aparece no repositório.
 
LEMBRANDO: não adianta conectar o token no servidor com o objetivo de todos os usuários utilizarem. Isso não funciona. O correto é o token estar conectado no pc local que fará acesso TS ao servidor.
 
Espero ter ajudado.

Esquece galera!
 
Manota minha. É que o exemplo do ACBrCTe tava setado A4_2vias como padrão no momento de ler a configuração. E quando eu mudava a propriedade no componente, nada acontecia.

me adiciona que posso lhe ajudar...

acho que nem pra consultas posteriores deixaram o endereço disponível. 

Bom dia!

Não se altera nada. Mas para geração de SPED e Sintegra, apenas algumas informações devem constar. O resto das informações vem zeradas ou em branco. Isso vale para notas denegadas e inutilizadas também.

No SPED até que não é problema no caso de notas emitidas, já que no mesmo apenas é informada a chave de acesso e o status praticamente.
No Sintegra, quase todos os campos deverão vir zerados.

Leia o manual de cada um, pois isso é bem explicado por lá. O que deve ou informar.
Agora, se você gera relatórios, poderá também tratar se os dados serão exibidos ou não durante a impressão.

Lembrando que vale tanto para o cancelamento dentro do prazo legal (24hrs) como fora do prazo.

Espero ter ajudado.

Já consegui em outro lugar aqui. Obrigado

Na pasta de exemplo do ACBrCT-e tem alguns arquivos txt com exemplo das rotinas. Dê uma olhada

Você já atualizou seus fontes? Creio que isso já foi corrigido pois saíram muitas atualizações por esses dias na unit ACBrBancoob.pas. Abri o ACBrBancoob.pas para dar uma analisada e aparentemente essa questão já foi tratada. Não tem como eu testar pois estou sem os fontes da minha aplicação aqui.
 
Atualize os fontes, gere um novo arquivo de remessa e veja se a posição 106 foi preenchido com 1 ou 2

Creio que envolve tudo isso aqui que você citou. Lembrando que notas canceladas nem todas as informações são obrigatórias. Recomendo ler o manual da EFD. lá cita essas informações.

O que a Juliana falou tem mais sentido. Dá-se um for nos arquivos selecionados, abrindo, lendo, gravando, fechando e assim sucessivamente.

Acho que consegui Elton! Segue os fontes:
ACBrECF.pas
ACBrECFClass.pas

1 - Não é obrigatório, mas como PV é requisito de PAF então o seu retaguarda tem que constar na lista de homologação. E seu frente de caixa deverá ser capaz de buscar essas PV no retaguarda para transforma-las em cupom
 
2 - Você pode fazer PV em ambos os lados, mas foi como eu disse na resposta anterior, todos que realizem algum requisito vão ser conferidos e homologados.
 
3 - Sim, sem problemas, a resposta 2 confirma isso.
 
Não tem problema algum. As telas, claro tem que ser diferentes, mas na tela de PV pode colocar algum botão tipo "EMITIR CUPOM". A partir daí vc abre a tela de cupom e registra a PV.
 
Espero ter ajudado!!!

Eu pensei em algo Isaque que talvez sirva para o resto do pessoal.
 
O meu PAF-ECF possui um servidor onde o mesmo vai centrar todas as movimentações de todas as ECF's do estabelecimento. E no servidor também vou ter gravado algumas informações sobre a movimentação da ECF durante o dia.
Então eu fiz o seguinte, ao fechar o dia, eu dou uma busca no servidor e verifico se há outras ECF's ainda em movimentação. Se retornar apenas uma ECF e que seja a que está varrendo o servidor, então eu realizo a emissão e posterior cancelamento das pre-vendas.

A chave pública serve para criar um xml com os dados da empresa e a própria chave pública vai dentro desse xml. Enquanto a chave privada serve para assinar os arquivos eletrônicos, a chave publica serve como um contra-chave que é utilizada para verificar a autenticidade de tais arquivos. O Regys criou um validador de arquivos eletrônicos. E existe também um próprio que os homologadores utilizam para validar os arquivos. Ambos necessitam desse xml com a chave publica para validar os arquivos.
 
Espero ter ajudado.

Bom dia Tati!
 
A questão do MD5 é gravar o mesmo em cada tabela necessária para a criação dos arquivos txt que pede na ER. Quando vende um item por exemplo, registra ele no banco correto? Após é preciso ter um campo para armazenar o MD5 desse registro gravado. Eu me fiz algumas perguntas para sanar essa dúvida:
 
1 - Como é composto o MD5?
 
Simples. Cria-se uma string com todas as informações do registro (campo1 + campo2 + campo3, etc...). E no final recomendo colocar uma chave privada, assim ninguém conseguirá descobrir a composição do MD5 gerado.
 
2 - Como gera-lo?
 
Tenho uma rotina onde passo uma query de consulta que possui somente o registro que está sendo trabalhado. A rotina vai passando por todos os campos somando-os e no final acrescento a minha chave privada, criptografo ele para MD5 e pronto! Depois é só gravar o código no respectivo campo do registro trabalhado. Eu optei por query, mas pode-se também passar os valores dos campos diretos.
 
3 - Para que serve esse MD5?
 
Ao gerar os arquivos eletrônicos (txt) exigidos pela ER, pede-se para informar se o registro é válido ou não.
 
4 - Como informar se o registro é válido?
 
No momento da geração dos arquivos, deverá ser gerado o MD5 novamente do registro no banco e comparar com o MD5 que já havia sido gravado anteriormente. Se forem iguais, registro válido. Caso contrário, registro inválido.
 
5 - De quais tabelas preciso ter o MD5?
 
Veja na ER que em cada anexo é discriminado o tipo de informação necessária para gerar os arquivos. Por exemplo: tem arquivo onde é informado o cadastro de produtos do PAF. Outro pede para informar os DAV emitidos. Então já é sabido que estas respectivas tabelas no seu banco devem possuir o MD5 em cada registro.
 
6 - Preciso criar o MD5 somente dos campos exigidos na geração dos arquivos constantes na ER?
 
Não. Sempre vamos precisar de um campo a mais nas nossas tabelas. Obrigatoriamente tem que se criar o MD5 pelos menos dos campos exigidos, mas para facilitar a vida e evitar confusões já cria de todos os campos de uma vez.
 
7 - Afinal de contas, qual o objetivo de se ter o MD5 e informar se o registro é válido ou não nos arquivos eletrônicos?
 
Simples. Na homologação, são realizados testes onde vão ser alteradas informações na base de dados e posterior geração dos arquivos eletrônicos. Tem como objetivo destacar caso o usuário entre em uma tabela e altere o registro manualmente, fora do programa aplicativo fiscal.
 
Espero ter lhe ajudado a esclarece não somente sua dúvida, mas também a de muitos colegas. São informações que colhi durante várias buscas no fórum. Me desculpe se esqueci de alguma coisa a respeito ou algo que não ficou muito claro.
 
Abraço

try ACBrCTe.Valida; except on E : Exception do begin lugar_que_voce_quer := E.Message; end; end;

Sim, testei. Aparentemente ele gera da forma correta. Mas já encontrei o problema na query. Era um coalesce indevidamente usado.

Segue em anexo...
 
Só destacando que é necessário fazer uma intervenção nela, assim como nas físicas. Configuar aliquotas, relatorios, formas de pagamento, cliches, proprietario, etc, etc. Para isso tem um exemplo que vem junto para tal função.
 
Espero ter ajudado.
Emulador FiscNET.zip
Emulador FiscNET.zip

Galera, para quem precisar de tal procedimento. Achei através de algumas pesquisas pelo google. Aqui vai a codificação:
 
 
Para ocultar a Trigger: UPDATE RDB$TRIGGERS SET RDB$SYSTEM_FLAG = 1 WHERE RDB$TRIGGER_NAME = 'Nome da Trigger';   Para ocultar o Generator:
UPDATE RDB$GENERATORS SET RDB$SYSTEM_FLAG = 1 WHERE RDB$GENERATOR_NAME = 'Nome do Generator';    
Para ocultar a tabela: UPDATE RDB$RELATIONS SET RDB$SYSTEM_FLAG = 1 WHERE RDB$RELATION_NAME = 'Nome da Tabela';    
Pode montar e depois ocultar. Essa foi minha solução para gravar o log de exclusão indevida de registros, me facilitando na hora de indicar nos arquivos eletronicos.
 
Obrigado a todos!