Ir para conteúdo
  • Cadastre-se

Clipeus

Membros Pro
  • Total de ítens

    59
  • Registro em

  • Última visita

Tudo que Clipeus postou

  1. Sim, Daniel, do que eu eu pude ler a respeito foi o que entendi, que é decisão do estabelecimento participar ou não. Também que entendi que esse desconto é "aleatório". Minha dúvida é se gravando na requisição do TEF o 706-000 sempre como '3' (saque+sorteio), como está hoje, não irá criar uma possibilidade de algum cupom aparecer com o desconto "sorteado", sendo que o estabelecimento não tem o cielo premia? Por isso que questionei se não é o caso desse campo (706-000) ter o seu valor definido através de uma propriedade. Pois assim, criamos uma forma de configurar para cada cliente se ele quer ou não que na requisição do TEF fique "habilitado" a possibilidade de desconto.
  2. Pessoal, pelo que entendi, um dos beneficios do Cielo Premia é que pode dar um prêmio instantaneo ao comprador na forma de desconto, e nesse caso, a loja irá "arcar" também com esse desconto ( ou seja, ela irá receber da operadora o valor liquido ), certo? Se for isso mesmo, alguem sabe me dizer se todas as lojas são "obrigadas" a participarem do Cielo Premia ou é opcional ? Pergunto isso, pois se for opcional, acredito que o controle do campo 706-000 gerado na requisição do TEF deveria ficar em uma propriedade do componente, e não dentro do código como está atualmente, pois poderemos ter como clientes lojas que estão participando e lojas que não estão participando, e atualmente sempre ficará gravado o valor '3' ( sujeitando assim a loja a ter um desconto ) Obs : já teve essa sugestão de deixar como propriedade no tópico viewtopic.php?f=16&t=6677&p=38583&hilit=706#p38583, mas como esse tópico era sobre o cliSiTef, achei melhor abrir outro.
  3. Realmente o componente não está gerando arquivo para validação de movimentação com data a partir de 01/01/2012, pois para esse período, a versão que deve aparecer no header é 005. As alterações que precisam ser feitas são muito simples : No arquivo : ACBrEFDBloco_0_Class.pas, no case que tem +/- na linha 320 fica assim : case COD_VER of vlVersao100: strCOD_VER := '001'; vlVersao101: strCOD_VER := '002'; vlVersao102: strCOD_VER := '003'; vlVersao103: strCOD_VER := '004'; vlVersao104: strCOD_VER := '005'; end; e no arquivo : ACBrEFDBlocos.pas, +/- na linha 102, que define o tipo enumerado TACBrVersaoLeiaute, fica assim : /// Versão do Leiaute do arquivo - TRegistro0000 TACBrVersaoLeiaute = (vlVersao100, // Código 001 - Versão 100 Ato COTEPE 01/01/2008 vlVersao101, // Código 002 - Versão 101 Ato COTEPE 01/01/2009 vlVersao102, // Código 003 - Versão 102 Ato COTEPE 01/01/2010 vlVersao103, // Código 004 - Versão 103 Ato COTEPE 01/01/2011 vlVersao104 // Código 005 - Versão 104 Ato COTEPE 01/01/2012 ); Homologuei no dia 11/01/2012, usando tanto o perfil A quanto o perfil B e os dois validaram normalmente depois dessa modificação. Abraços, Luís
  4. Olá pessoal, para aumentar um pouco a lista não tão movimentada : SIAG Desenvolvimento de Sistemas Ltda Software : SIAGPAF 5.11 Especificação de Requisitos : 1.10 Laudo : POL0062012 Componentes usados : ACBrECF, ACBrAAC, ACBrPAF, ACBrNFe, ACBrSINTEGRA, ACBrSpedFiscal, ACBrTEFD, ACBrEAD []'s Luís Henrique
  5. Sobre o "Menu Fiscal - Estoque" surgiu uma dúvida e não encontrei nada parecido no forum : Essa opção do menu fiscal deverá gerar SEMPRE a posição de estoque referente à ultima "abertura de dia" que foi feita, ou precisa ter um parametro para que seja informada a data do estoque desejada ? Pelo que entendi seria sempre a última, mas alguem poderia confirmar por favor ? Grato, Luis Henrique
  6. Após vários testes, entrei em contato diretamente com a receita e em conversa com um analista lá, a informação que eu tive é que iriam efetuar uma alteração no servidor, e após isso voltou a funcionar normalmente. Grato
  7. Mesmo no ambiente 2.0 acontece o mesmo, praticamente em todas as vezes que faço um consultar status, independente se pelo meu aplicativo ou pelo demo, da erro. ( abaixo o log gerado pelo demo ), mas, se consultar ANTES no ambiente de homologacao, e sem fechar o demo, colocar novamente em producao, funciona... - Inativo ou Inoperante tente novamente. - An error occurred in the secure channel support - URL:https://nfe.sefaz.go.gov.br/nfe/services/NfeStatusServico - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico/nfeStatusServicoNF Ambiente : 1 Versão Aplicativo : GO2.0 Status Código : 107
  8. Sim, já reinstalei e continua.. ora funciona o status e ora não... o que esta me chamando a atencao é a mensagem de aguardar 3 minutos para nova consulta, via de regra, meu aplicativo antes de enviar a nota executa o webservices de status para ver se esta normal, e acredito, que internamente o componente tambem deve verificar. Detalhe : NFe 1.10 ainda... vou tentar colocar como 2.0 para testar...
  9. Clipeus

    NFe em Produção para Goias

    Pessoal, desde o dia 24/11, passei a ter problemas com um cliente que estava com um micro infectado por virus. O micro ja foi formatado e continua o problema. O que acontece é o seguinte : Ao tentar enviar uma NFe, retorna a mensagem "generica" de Inativo ou Inoperante, porem, se mudo para o modo de homologacao funciona normalmente. Pelo demo do ACBR acontece a mesma coisa, mesmo um simples consultar status ja da o erro ( somente no ambiente producao ). Uma observacao que vi, é que de vez em quando o consultar status funciona, mas nos retornos dele, a ultima linha de observacoes, menciona algo como "Efetuar nova consulta apos 3 minutos", ja no ambiente de homologacao nao retorna isso. Alguem mais esta passando por esse problema ?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.