giulianon

Bom dia pessoal! Ontem 23/08/2016, aconteceu em Florianópolis uma reunião entre empresas desenvolvedoras, gerentes de TI das grandes redes de supermercados de SC, e os fiscais da SEF/SC para tratar basicamente sobre o bloco X. Resumo do encontro: Bloco X teve alterações/correções no layout do arquivo que serão disponibilizadas em breve. Previsão para o início do envio dos arquivos do bloco X é julho/2017. Não lembro a data, mas novos credenciamentos não poderão mais constar não conformidades relativas ao bloco X. Se tiverem não serão credenciados. O bloco X vai funcionar exatamente como está no seu ATO COTEPE. (Em outra reunião os fiscais tinham ficado de definir se ia realmente haver o bloqueio do PAF, em caso de falha de envio do arquivo do bloco X após a 10a tentativa). Após o cadastro de um novo laudo os desenvolvedores terão 180 dias para atualizar todos os clientes com a nova versão. Não lembro a data também, mas a partir dessa data todos os PAFs deverão estar no mínimo na versão da ER 02.03. Em reunião no CONFAZ, foi encaminhada uma alteração por parte da SEF/SC, que visa desobrigar apenas no CUPOM FISCAL a impressão do CEST/NCM, já que isso acabou gerando um custo a mais para os clientes, em virtude da impressão em 2 linhas de cada item vendido. Essa é a mais importante de todas \o/ . Já está em estudo a compatibilização das impressoras do convênio 09/09 (Blindadas) para trabalharem com NFC-e. Segundos os fiscais, somente será adotada a NFC-e em SC se for através da impressora, já que isso garante a contingência e a responsabilidade do desenvolvedor. Dessa forma, o processo atual de homologação vai continuar existindo, e caso a NFC-e seja adotada, os fabricantes farão uma atualização no SB da impressora para compatibilizar a mesma a NFC-e. É isso! Qualquer novidade atualizo aqui. Att.

Não cheguei a perguntar sobre a documentação EMBarbosa, mas acredito que já tenha sim, pois o que o pessoal passou foi que, se desde a última homologação que eu fiz, se houve só troca de versão, basta entrar em contato com o suporte e fazer a pré-homologação que já é o suficiente. Caso tenha sido alterada versão e a aplicação, ai teria que fazer essa mesma pré-homologação e posteriormente a homologação. Nesse caso pré-homologação e homologação são feitas com o roteiro de testes, então acredito que já deva estar na documentação.

Boa tarde colegas! Estive fazendo o treinamento na Software Express, e de todo o conteúdo, 3 pontos eu achei bem relevantes destacar e informar aqui, pois pelo menos pra mim são novidades. 1 - A confirmação da transação pode ser feita já no momento que a aplicação receber as duas vias do comprovante. Antes era só após a impressão de todas as vias do CCD. Dessa forma caso ocorra qualquer problema basta reimprimir os comprovantes. OBS: Requer uma nova homologação para trabalhar dessa maneira. 2 - Caso ocorra algum problema de falta de energia, desligamento do equipamento, etc, passa a ser opcional o tratamento dado pela aplicação, ou seja, você escolhe se cancela ou se confirma o que tiver pendente. OBS: Requer uma nova homologação para trabalhar dessa maneira. 3 - Cobrança maior por parte das adquirentes por ambientes certificação PCI.

Se o seu modem for o da daruma, existe um comando para informar qual chip você quer usar, ou seja, você consegue fazer isso fácil.

http://aplicacoes.unisul.br/PAF/docs/ATO-COTEPE-02.04.pdf

Por acaso você ou seu cliente não utilizou algum programa da própria sweda ou a dll para gerar algum arquivo fiscal, fita detalhe, etc? Pergunto pq já aconteceu comigo de fazer isso, e o programa da sweda alterar a velocidade da impressora para gerar a informação. Tente conectar utilizando outras velocidades que deve funcionar, ou utilize o lacrador da sweda para verificar a velocidade atual, e ajustar para velocidade que você já utilizava.

Só complementando, algumas balanças possuem opções de protocolos e cada um deles trabalha de uma forma. Normalmente existem protocolos que só "liberam" a leitura do peso quando a balança estiver estável. Nesse post fala um pouco a respeito.

Ao depurar para tentar detectar problema encontrei o seguinte comentário no método TACBrECFEpson.LinhaRelatorioGerencial: ou seja, não só o #18 deve ser filtrado. Já fiz a alteração e amanhã vou testar novamente no cliente. Obrigado Daniel!

Boa tarde colegas! Estou enfrentando um problema com a impressão do comprovante de tef de um cartão chamado CALCARD. A impressão do comprovante desse cartão nas impressoras EPSON (Somente nessa marca) apresenta um erro conforme log em anexo. Estou com a última versão do ACBr e fiz o teste tanto pelo meu sistema quando pelo TEFDemo. Capturei também o conteúdo do comprovante no arquivo temporário do tef que também segue anexo. Alguém com o mesmo problema? Att. ACBr_CliSiTef_001.tef ecf_21062016153040.txt

Não existe uma mkse.dll de testes pois a mesma é feita para cada cliente. Eu não utilizo o ACBrTEFD por isso criei uma função paralela. Estou migrando do componente atual para o ACBrTEFD. Pelo que eu li em algum post o Daniel ia implementar algo para coletar qualquer informação via pinpad. Chegou a atualizar o componente de TEF e verificar se isso foi feito? Por último recebi esse email da software express, que trata da alteração na forma de coleta dessas informações através do pinpad.

Hum entendi Daniel. Vou estudar um pouco mais a documentação do Clisitef pois não sabia dessas outras possibilidades. Teria que filtrar realmente quando é uma recarga. De qualquer forma o problema que deixa as transações pendentes é esse.

Descobri o "problema" e efetuei um ajuste na classe. Resumindo, o "problema" é que componente normalmente cria um arquivo ao concluir o processo de coleta, e iniciar o processo de impressão de comprovantes. Esse arquivo pelo que constatei depurando, é o arquivo utilizado pelos métodos de confirmação ou cancelamento de transação. No caso da recarga de pré-pago com troco, é apresentada uma mensagem ao usuário, e essa mensagem para o processo que em seguida criaria o arquivo. Se o sistema for finalizado nesse momento que a mensagem está aguardando o OK do usuário, o arquivo não existe (ainda não foi criado) e os métodos de confirmação ou cancelamento (ao inicializar) não efetuam nada deixando a transação pendente. Como falei no post anterior não conheço muito bem o componente mas apliquei a correção e funcionou perfeitamente. Em anexo segue a unit alterada. ACBrTEFDCliSiTef.pas

É o que estou fazendo Daniel. Fiz o post pois não tenho muita afinidade com esse componente(é a primeira vez que estou usando), e de repente pelos logs ou pela sequência que estou seguindo poderia ter feito algo errado. Mas obrigado. Descobrindo algo já informo aqui.

Boa tarde pessoal! Estou com uma situação na qual a transação está ficando pendente, e como fiz o teste tanto no meu sistema como no TEFDemo, acredito que tenha um probleminha mesmo. O problema ocorre na recarga de celular. Estou usando Sitef + Clisitef + GWCel para recarga. Os passos são os seguintes. 1 - Com impressora e sitef ok, abrir o menu gerencial e executar uma recarga. 2 - Proceder com a recarga informando o pagamento da mesma em dinheiro de forma que gere um troco. 3 - Quando aparecer a mensagem Troco: R$ xxxx reais fechar a aplicação. 4 - Desligar a impressora e abrir aplicação ativando o tef. Nesse momento pelo que está programado no evento InfoECF RetornoECF := 'O'; // Executará CancelarTransacoesPendentes; RetornoECF := 'R'; // Executará ConfirmarESolicitarImpressaoTransacoesPendentes; E ai que ocorre o problema pois tanto faz passar 'O', 'R', 'L' ou qualquer retorno, que mesmo assim a transação fica pendente. Segue anexo o log. acbrteflog.txt

Bom dia! Eu tenho essas rotinas funcionando. O detalhe eh que para coletar esses dados, voce precisa entrar em contato com a SE e solicitar uma dll feita (na teoria para o seu cliente e na pratica funciona para todos) para isso. A dll se chama mkse.dll. Tendo essa dll a coleta em si eh tranquilo. So com as dlls do clisitef normal nao da pra coletar. Vou separar aqui as rotinas e ja posto. Segue anexo a rotina para a coleta. Eu nao uso ACBrTEFD e o componente que eu uso não tenho os fontes. Por isso fiz separado. Devo migrar em breve para o ACBrTED e ai posso incluir nos fontes. Qualquer duvida estou a disposição. coleta.txt

Acho que tem um equivoco ai. Se o COMPROVANTE não foi totalmente impresso e a impressora está inativa, ou seja, retornando "OUTROS", então a transação tem que ser cancelada mesmo. O componente está se comportando da forma correta. Pergunte ao homologador se um comprovante impresso pela metade é válido, já que ele está solicitando que a transação seja confirmada nessa situação.

Nesse caminho ..\Exemplos\ACBrSerial\ACBrBAL\Delphi

Essa impressora é a Bematech 4200 do convênio 09/09 (Blindada)? Se sim, você deve baixar o driver da Bematech que cria uma porta COM virtual. Feito isso basta configurar o sistema para utilizar essa porta.

Conforme o Daniel citou: "Você precisa baixar o ACBr todo, usando um cliente de SVN Leia as instruções nesse link: http://acbr.sourceforge.net/drupal/?q=node/37 " Feito isso estude o demo que se encontra na pasta \Exemplos\ACBrSMS, conforme o Régys falou. Leia sempre o post por completo pois a respostas normalmente estão nele.

Bom dia Régys! Concordo com você e o Juliomar, e fiz esses questionamentos, mas o homologador falou que o Sefaz de SC cobrou isso dele e ele automaticamente vai cobrar na homologação. Os links "extra oficiais" estão no site da Unisul http://aplicacoes.unisul.br/PAF/?q=links Nesses links tem os xsds, webservice, validação, schemas, documentação, etc. Bom, só queria deixar essas informações que foram me passadas, para que, quem for homologar fique ciente. Bom trabalho a todos!

Boa tarde pessoal! Homologação concluída. Para encerrar o tópico deixo duas informações: 1 - Foi cobrado na minha homologação apenas a geração dos arquivos do fisco após o Z, e através do menu (não precisa ser o fiscal). A alteração exigida foi no formato da data e a validação foi feita no link https://sathomologa.sef.sc.gov.br/tax.NET/sat.siv.web/validacao.aspx 2 - Segundo o homologador a empresa que for homologar semana que vem já foi avisada e será cobrado a geração, validação e envio dos arquivos. Sendo assim sugiro que quem estiver pra homologar já se prepare. Homologuei na Unisul em Tubarão - SC. Fico a disposição para quem tiver alguma dúvida.

Boa noite! Iniciei a pré-homologação hoje, e apesar de questionar o homologador sobre as coisas que o Juliomar me passou, ainda assim ele me solicitou que pelo menos o formato da data no arquivo do ESTOQUE fosse corrigido. Alterei as linhas: // FGerador.wCampo(tcStr, '', 'DataReferenciaInicial', 0, 0, 1, FormatDateBr(DataReferenciaInicial)); // FGerador.wCampo(tcStr, '', 'DataReferenciaFinal', 0, 0, 1, FormatDateBr(DataReferenciaFinal)); FGerador.wCampo(tcStr, '', 'DataReferenciaInicial', 0, 0, 1, FormatDateTime('yyyy-mm-dd',DataReferenciaInicial)); FGerador.wCampo(tcStr, '', 'DataReferenciaFinal', 0, 0, 1, FormatDateTime('yyyy-mm-dd',DataReferenciaFinal)); Vou homologar assim pra satisfazer a exigência dele, e aguardar para atualizar o componente quando algo oficial for disponibilizado. Outra coisa que ele me informou, é que esses arquivos de ESTOQUE e REDUÇÃO Z vão ser enviados para o fisco para serem cruzados com os arquivo enviados pela ECF 09/09. Segundo ele o que a impressora envia é de conhecimento somente do fisco. Amanhã caso tudo ocorra bem na geração e validação dos arquivos eu informo aqui.

Vou questioná-lo sobre isso, até pq me passou isso ontem no final da tarde e a homologação é 3a feira. Obrigado Juliomar!

Ele passou o link da documentação também e o endereço do WebService de testes. https://docs.google.com/document/d/1yez14gry9Mi4rTpwDRDf--bR-SLzijD81OPeJzh9FqE/edit http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx Me informou que o envio ainda não vai ser cobrado mas a validação sim. O primeiro erro que apresenta na validação já é de uma data no formato inválido. Pelo que vi na documentação mudou mesmo. Formato atual é dd/mm/yyyy e mudou para yyyy-mm-yy

Bom dia colegas! O homologador da Unisul me passou o link para o Validador dos arquivos do Bloco X. https://sathomologa.sef.sc.gov.br/tax.NET/sat.siv.web/validacao.aspx Fiz um teste inicial com um arquivo gerado pelo componente ACBrBlocoX e o validador gerou um monte de erros. Não sei se mais alguém já usou o validador e teve os mesmo problemas. Começo a homologar na 3a feira então vou tentar ver se descubro o problema. Se alguém já estiver validando e obteve sucesso por favor dê um alô hehehe.