Régys Silveira

Erro 999 - não catalogado geralmente é erro de implementação no webservice, esse código de erro serve para qualquer coisa não tratada pelo webservice.

A segunda opção foi feita especificamente para o menu fiscal, gerando ou imprimindo as informações como o menu LMFC pede.

Você utiliza a versão openssl, se sim, o João colocou um tipo basico modificado para openssl no diretorio, basta renomear.

Em contato com a sweda eles não conseguirão responder se o comando para o contador existe ou não, no manual não existe, então fiz uma implementação genérica para ler ele da Leitura X que vai funcionar com outras impressoras que também não possuem o retorno, peço que testem e retornem o feedback. Para Daruma, Bematech e protocolo FiscNET está 100% utilizando o comando próprio. Para Sweda e outras está lendo da leitura X e em meus testes os valores retornados bateram. Qualquer coisa diferente postem.

A sim, correto, ta vendo são coisas que eles vão acertando, devagarinho mas vão

Colocar o MD5 do aplicativo no campo reservado ao fisco é somente para o fisco saber qual aplicativo emitiu aquela NF-e, veja, no futuro eles vão cruzar diversas informações, o SPED está ai para mostrar isso, ano que vem começa o SPED Social (Folha de pagamento), eles vão amarrar tudo, logo logo, até 2015 eu imagino que vai ser bem complicado sonegar, ou ao menos vai ficar muito difícil fazer isso.

Existem ferramentas na internet para isso, aprendi a conhecê-las em minha pós-graduação em segurança da informação. Uma busca rápida no google lhe ajuda. Quanto aos requisitos e roteiros, concordo plenamente que existem coisas estranhas a nós programadores que eles pedem no roteiro, mas se estão lá tem um motivo, e julgar se é certo ou errado não vai fazê-los mudar de ideia, cabe a nós somente implementar e fazer funcionar como pedem, mas levantar as questões é bom, porque assim se gera a discussão e gerando a discussão pontos são levantados, e eles vão vendo isso e acertando, devagarinho mas vão .

Agora eu volto a pergunta a você, tem certeza mesmo que o seu banco de dados é inviolável? eu conheço forma de obter acesso administrador a praticamente todos os BDs do mercado hoje, comercial ou não comercial. Como você tem certeza que está barrado? e se não estiver, não seria o caso de evidenciar isso?

Igor, segue a mesma lógica do que havíamos conversado no outro post, o que o estado quer é poder validar, veja no componente ACBrAAC, se você mecher no arquivo ele acusa ele como inválido, esse é o ponto, invalidar a ação do usuário, não bloquear isso. O que o estado considera é que qualquer coisa feita dentro do banco de dados é mais simples de ser manipulada, só isso.

Não, você precisa ter o cadastro na UF, aqui nos fizemos a inscrição no estado e nos cadastramos como emissores voluntários, assim podemos utilizar o ambiente de homologação, não mudou nada em termos fiscais.

O diretório ACBr\Fontes\Synalist está no library path?

Ele vai tentar acessar e procurar formas de fazer isso, eles já tem uma ideia de quais podem e quais não podem, o postgress por exemplo é um banco que possui gerenciador de acesso e senha então não vão aceitar isso, mas uma aplicação que possua banco de dados próprio inacessível de qualquer forma que não seja a aplicação que a utiliza, essa sim vai ter uma observação no laudo e os testes serão pulados. Eu já vi isso acontecer com aplicativos cobol usando bases de dados próprias e até em delphi mesmo, mas o programador criou toda a estrutura de dados em formato próprio inacessível por fora da aplicação.

Por enquanto o correto é somente o Paf-ECF, aceito na grande maioria das UFs, saber se o NFC-e ou o SAT vão ser o padrão ainda é cedo.

A chance de um hash bater com outro existe sim, mas é muito remota, por isso ele é utilizado para esse tipo de situação, sendo utilizado inclusive por grandes empresas para diversos fins que exigem a validação de um texto ou arquivo, concordo que não é o mais seguro mas é o mais rápido é util. Quanto a fazer o que quiser no banco de dados, o usuário sim vai fazer, mas o que o SEFAZ quer é que isso fique evidenciado, não é para barrar e para validar. Tem como o usuário burlar, com certeza tem, afinal de contas estamos falando de informática, onde o impossível não existe, mas tomando as devidas precauções o requisito vai ser atendido e a validação esperada para o arquivo também. A forma apresentada pelos colegas é uma das diversas formas possíveis, não quer dizer que é infalível nem tão pouco inquebrável, mas como dito, a idéia é validar e não barrar. Você pode utilizar uma solução onde o seu banco de dados seja criptografado e inacessível ao usuário, sendo passível de consulta e atualização somente pela sua aplicação, isso vai constar no seu laudo e os testes do bloco VII não serão realizados.

O menu Vendas no Período é obrigatório para o menu fiscal e corresponde a geração dos arquivos Sintegra e SPED refente a um período, conforme descrevi acima.

Olha, só preciso do comando, enviei um e-mail ao pessoal da Sweda e ainda não obtive resposta, no manual de comandos SweedaSTX não existe comando para tal, estou achando que esse comando não existe na Sweeda, eles devem fazer usando algum artifício, não sei. Se quiser tentar entrar em contato com eles e postar o retorno, talvez você consiga um retorno mais rápido.

Na ER não existe, mas nela fala que o arquivo deve: Se você consultar os layouts definidos e suas respectivas legislações, encontrará a parte da lei que diz que os mesmos devem ser validados pelos seus programas validadores, ou seja, a validação é implícita na legislação que rege a geração do arquivo. Quanto a geração não bater é estranho, pois todas as softwarehouses são obrigadas a validar o arquivo e validam, portanto, algo está errado ai com o seu aplicativo, veja que os dados para a geração do arquivo devem vir do banco de dados e não de arquivos gerados pela impressora fiscal, inclusive é uma prática comum desligar a impressora fiscal durante a geração dos arquivos do menu fiscal "Vendas do período".

Uma boa idéia, não tive casos desse tipo ainda, mas é algo que realmente pode acontecer.

Que mal lhe pergunte para o que você precisa dessa informação?

Segue exemplo de como enviar, retirado do demo do ACBrNFe2: ACBrNFe1.CartaCorrecao.CCe.Evento.Clear; ACBrNFe1.CartaCorrecao.CCe.idLote := StrToInt(idLote) ; with ACBrNFe1.CartaCorrecao.CCe.Evento.Add do begin infEvento.chNFe := Chave; infEvento.cOrgao := StrToInt(codOrgao); infEvento.CNPJ := CNPJ; infEvento.dhEvento := now; infEvento.tpEvento := 110110; infEvento.nSeqEvento := StrToInt(nSeqEvento); infEvento.versaoEvento := '1.00'; infEvento.detEvento.descEvento := 'Carta de Correção'; infEvento.detEvento.xCorrecao := TextoCorrecao; infEvento.detEvento.xCondUso := ''; //Informar vazio, o componente vai colocar o texto correto end; ACBrNFe1.EnviarCartaCorrecao(StrToInt(idLote)); [/code]

Atualize o seu ACBr, agora o ACBrECF possui a propriedade "NumReducoesZRestantes" que retorna esse contador, já está implementado e testado para Daruma, FiscNET e Bematech, para a Sweda ainda não consegui o comando direto pois não possuo impressora fiscal e o emulador bloqueia o log da porta, estou aguardando um retorno do suporte da Sweda informando o comando.

Ao emitir a Z basta pegar NumCOO - 1, assim terá o COOFinal.

Quais são os comandos das dlls, se existem nelas, então pode ser passível de fazer no ACBr via comando direto.

Isso já foi devidamente explicado alguns posts atrás.

Fiz testes aqui é está funcionando corretamente para MG.