Painel de líderes

Bom dia Arce, Não, o SAT não ficará incapacitado nem será perdido, o SAT trabalha off-line e não tem vinculo com as datas, é o usuário que tem que ficar atento. O que aconteceu é que os SATs com versões antigas (produzidos em 2015) tem um certificado que vale até 31/07/2016, e portanto se não forem ativados até esta data a retaguarda automaticamente recusa a comunicação pelo fato do certificado estar vencido. Uma vez ativado o SAT recebe novos certificados. Se você tiver um SAT antigo e não ativado basta entrar em contato com o fabricante para ele zerar e reprogramar o equipamento. Com relação as datas que aparecem no link que o Sérgio colocou, conforme ele explicou elas se referem a validade da versão do SW Básico perante o Fisco, ou seja, o contribuinte deve atualizar o equipamento para que ele gere cupons que não serão recusados pela retaguarda da Sefaz. E sendo assim verifique seu modelo e versão para saber até quando se deve atualizar. Att Cristiano Abbud

Tem certeza que você fez a atualização do certificado no SGR-SAT ?

Toda contribuição é sempre bem vinda ao projeto, mas é claro que todas elas também são analisadas pelos responsáveis do projeto, ache a solução para seu problema e se conseguir mantenha-a no padrão ACBr, o que levará a ter grandes possibilidades de ser adicionada ao projeto principal. Ficamos no aguardo.

O tópico está sem movimentação a algum tempo, mas vou relatar aqui minha situação. Dentre as várias limitações que podem ser aplicadas a um servidor de e-mail para evitar o consumo indevido, uma delas é a quantidade de vezes que um ip/usuário pode se logar ao servidor durante um tempo X (normalmente 1 minuto). Exemplificando: preciso enviar 100 e-mails, porém o servidor está configurado para permitir que eu me logue apenas 20 vezes no servidor no prazo de 1 minuto, e que o tempo estimado para o envio de 100 emails fosse de 20 segundos. Acontece que para cada e-mail que o ACBrMail envia, ele abre uma conexão, envia, e fecha a conexão ao final do processo. Para resolver o problema de forma bem simples (gambiarra), eu poderia aplicar um intervalo no envio de cada email, porém ao invés de enviar os 100 e-mails em 20 segundos, eu precisaria de pelo menos 5 minutos. Essa restrição existe, mas pode ser resolvida facilmente enviando todos os e-emails em uma única conexão, claro que usando thread muda um pouco, mas também é possível. Estou desenvolvendo um Gerenciador para NF-e/CT-e onde o usuário pretende enviar muitos e-mails de uma única vez, e da forma como está funcionando o ACBrMail não consigo utiliza-lo, e terei que desenvolver uma solução própria para tal, mas estou disposto a faze-la no próprio ACBrMail para que possa ser utilizada por outros que tiverem a mesma necessidade.

Bom dia Leootoni, Em virtude do refactoring feito no componente essa função começou a apresentar problemas e ela foi desativada. Mas você pode simplesmente abrir o arquivo Cidades.INI procurar pela cidade desejada. Se encontrar vai saber que o componente atende essa cidade e por tabela saberá qual é o provedor, caso não encontre, saberá que o componente ainda não atende ela. Dica, procure pelo código IBGE e não pelo nome da mesma.

Boa tarde a todos, O numero do protocolo é retornado logo após o envio no caso do método Enviar. Sendo assim para obter o numero do protocolo basta: sProtocolo := ACBrNFSe1.WebServices.EnviarLoteRPS.Protocolo;