Painel de líderes

Prezados, O que meu xará Cristiano citou está correto, o SAT tem que mudar para horário de verão independente de ter acesso ao NTP, pois pode estar sem rede no momento. Estes dados de mudança vem no arquivo de parametrização de fábrica e este mesmo arquivo de parametrização de fábrica vai sendo atualizado com o tempo pela própria Sefaz. Desta maneira o SAT estará sempre com os dados anuais de mudança para horário de verão atualizados. Att Cristiano Abbud

Bom dia Werner, Para se obter o XML assinado e protocolado de forma legal existem 3 formas: 1. O emitente da nota deve enviar por e-mail o XML conforme consta na legislação, se ele não faz isso você esta recebendo a mercadoria sem nota, pois o DANFE para o Fisco não tem validade jurídica a não ser que o destinatário seja pessoa física. 2. Pelo site da SEFAZ; 3. Usando o método DistribuicaoDFe; Vamos então a esse método: 1. Na pasta Doctos\Manuais você encontra o PDF: Manual ACBrNFe versão 1.04 caso você já esteja usando os fontes do Trunk2 com certeza alguns métodos estão diferentes, mas o DistribuicaoDFe não mudou nada e na página 15 você encontra uma breve explicação bem como o significado de cada parâmetro dele. 2. No Portal Nacional da NF-e em Notas Técnicas você encontra a NT 2014/002 versão 1.01 que trata sobre o Distribuição DFe são apenas 13 páginas, considero a sua leitura muito importante. 3. A sua utilização é bem simples mas para poder obter o tão desejado XML assinado e protocolado é necessários alguns passos a mais. Devemos inicialmente executar o método DistribuicaoDFe para obter os resumos das NF-e, em seguida devemos realizar a manifestação do destinatário em cada uma delas (lembrando que a manifestação é um evento, vide NT 2012/002 versão 1.02) ao executar pela segunda vez o DistribuicaoDFe, dependendo do tipo de manifestação teremos como resposta o XML completo da NF-e. Não é preguiça ou não querer explicar o que é e como faz, eu sempre peço para que as pessoas leem os manuais e notas técnicas, pois estarão lendo um documento que foi publicado pelo ENCAT e disponibilizado no Portal Nacional da NF-e da SEFAZ, pressupõe que as informações contidas sejam corretas. Ocorrem alguns erros sim, ninguém é perfeito. Estamos aqui para esclarecer algumas duvidas.

Boa noite pessoal, Recentemente precisamos fazer algumas adaptações nas nossas soluções para poder suportar o nono dígito e gostaria de compartilhar com vocês uma em especial que usa um recurso muito bacana do Firebird de casamento de padrão por expressão regular. Antes de passar o trecho de código vale apenas ressaltar que esta alteração não procede para telefones fixos. Em 25 de Agosto de 2013 passou a valer o nono dígito para os números móveis dos DDDs 11, 12, 13, 14, 15, 16, 17, 18, 19 Em 27 de Outubro de 2013 os números dos DDDs 21, 22, 24, 27, 28 Até 31 de dezembro de 2014 para os Códigos Nacionais 91, 92, 93, 94, 95, 96, 97, 98, 99 Em 31 de maio de 2015 para os Códigos Nacionais 81, 82, 83, 84, 85, 86, 87, 88, 89 Em 11 de outubro de 2015 Códigos Nacionais 31, 32, 33, 34, 35, 37, 38, 71, 73, 74, 75, 77, 79 Até 31 de dezembro de 2016 para os Códigos Nacionais 41, 42, 43, 44, 45, 46, 47, 48, 49, 51, 53, 54, 55, 61,62, 63, 64, 65, 66, 67, 68, 69 Fizemos um tratamento a nível de trigger que verifica se o número de telefone já pode receber o nono dígito caso o usuário esqueça de informar e atualiza os antigos como segue abaixo: IF (NEW.PESSOA_TELEFONE SIMILAR TO '(11|12|13|14|15|16|17|18|19|21|22|24|27|28|91|92|93|94|95|96|97|98|99|81|82|83|84|85|86|87|88|89|31|32|33|34|35|37|38|71|73|74|75|77|79)[6-9]{1}[0-9]{7}') THEN BEGIN NEW.PESSOA_TELEFONE = SUBSTRING(NEW.PESSOA_TELEFONE FROM 1 FOR 2) || '9' || SUBSTRING(NEW.PESSOA_TELEFONE FROM 3 FOR 8); END Com uma única expressão conseguimos verificar se o número de telefone pode receber o nono dígito como segue: 1) (11|12|13|14|15|16|17|18|19|21|22|24|27|28|91|92|93|94|95|96|97|98|99|81|82|83|84|85|86|87|88|89|31|32|33|34|35|37|38|71|73|74|75|77|79) verifica os dois primeiros digitos são DDDs que já estão valendo o nono dígito 2) [6-9]{1} verifica somente números de telefones não fixos 3) [0-9]{7} verifica se o resto do numero de telefone e digito Esperamos que seja útil.

Então seria razoável retirar do parâmetro e só voltar a ativar quando disponível , porque muita gente procura falando que esta marcado , mas não esta imprimindo.

Bom Dia à Todos, Para auxiliar alguns clientes, desenvolvi um aplicativo simples (versão desktop, separado do meu sistema) para consultar de CF-e, informa-se a chave dele e o captcha, não é para "baixar" o cupom, apenas para consultar em caso de alguma dúvida, divergência que o cliente dele alegue, algo do tipo. Mas pode-se pensar em implementar para ter mais rotinas futuramente, me orientei nos projetos Recuperar XML e Consulta CNPJ/CPF, entendo que possa não ser de interesse do ACBr em si adotar algo do tipo, porém se a comunidade mostrar interesse disponibilizo aqui a ferramenta para todos. É uma contribuição pequena perto do tanto que a comunidade já me ajudou! Se for o caso criemos até um SVN online, para fazer a manutenção do projeto. Observação: Seguem anexos do aplicativo em funcionamento. Aguardo opiniões Atenciosamente, Mateus Penha

rode novamente o ACBrinstall... tudo indica que seus DCU ou BPL estão desatualizados

Os fontes do Trunk estão desatualizados... Tente com o ECFTeste já compilado com o Trunk2, e disponível para Download aqui no Fórum

Nunca misture os fontes dos Trunks... Isso pode causar sérios problemas

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum. Perdão, ao meu ver achei que em se tratando de comunicação com a ecf 09/09 mesmo sendo bematech lá o início do tópico foi tratado sobre a comunicação de modo geral, vou abrir outros dois tópicos. Obrigado.

Modificações enviadas para o SVN... mais uma vez, muito obrigado... Apliquei uma pequena modificação, para não imprimir a banda de Fatura e Duplicata (ao mesmo tempo) quando for A VISTA

Já me intrometendo na conversa, Daniel, creio que isso seria o ideal, mas a parametrização deve ser feita (ao menos periodicamente) para atender os casos em que nos dias de entrada ou saída do horário de verão o SAT esteja sem comunicação com a internet (e consequentemente sem acesso aos servidores NTP)

No RS tem CSC diferente para produção e homologação. Mas alguns estados parece que não tem, só entrando lá no site da sefaz do estado e verificar. E tem mais informação aqui: http://www.projetoacbr.com.br/forum/topic/24921-rejeição-nota-fiscal-sem-a-informação-do-qr-code/?page=4#comment-162981

Já consegui fazer o download e por enquanto na minha aplicação o problema foi resolvido.

Já gerei várias vezes o ato COTEPE aqui utilizando a nossa MP4200 e de clientes, sempre sem problemas. Tem que estar com a Bemafi32.dll na versão 7 e aquele parâmetro "protocolounico=1". Os erros que você relatou aqui são exatamente os mesmos que aconteciam conosco quando uma dessas duas condições acima não eram atendidas. Abraço

No svn

Se não estou enganado agora não é possível configurar essa opção pois estamos utilizando o Fortes Report no monitor. Teríamos que verificar a possibilidade de implementar essa opção, antes de tudo verificar se o Fortes permitiria montarmos isso em tempo de execução, vai demorar um tempo para verificar isso.

Bom dia irmao daniel, Houve algum consenso sobre a propriedade que permita determinar se o ACBrNFe deve atualizar o XML no caso de cancelamento. Muito obrigado.

Programa exemplo do ACBrNFSe - Trunk2 Visulizar Arquivo Na pasta onde for descompactado o executável, deve-se colocar junto os arquivos INI que são baixados junto com os fontes do repositório Trunk2. Autor Italo Jurisato Junior Enviado 09-10-2015 Categoria Utilitários ACBr

OK Daniel Obrigado

Boa tarde Pessoal, sei que ja são posts antigos porem percebi que ninguem se manifestou, se servir pra alguem la vai. Sou técnico credenciado de impressoras fiscais Elgin, Bematech e Daruma e vou passar uma dica, espero que ajude pois essas Elgin K estao dando bastante dor de cabeça. O problema ocorrido é que as memoria MFD dessa impressoa sao extremamente frageis e ficam depreciadas facilmente. Porem, nem todas precisam ser trocadas, existe uma forma de recuperar os dados MFD sem que a impressora entre em modo de intervenção tecnica: 1- *vire a impressora de costas e repare que no canto inferior direito existem 2 botoes e um led central; 2- *desligue o cabo de energia e ligue novamente com o botão da direita (SEL) pressionado por cerca de 40 segundos: 3- *repare que o led central ira piscar cerca de 2 vezes por segundo, passando o tempo acima, solte o botão, em seguida clicke novamente no botão SEL seguido com um click no botão da esquerda (CON) até que a impressora solte um cupom escrito "leitura via teclado"; 4- *desligue a impressora e ligue novamente segurando o botão da direita (SEL). Caso o led central comece a piscar mais rapido que antes, solte o botão e espere o led se estabilizar que a impressora volta a operar. 5- *caso pisque na mesma velocidade que antes (2 piscadas por segundo), repita a ação 2, 3 e 4. Chegam todos os dias impressoras Elgin K aqui pra eu recuperar, cerca de 90% delas voltam com esta ação, porem tenho que tentar varias vezes até dar certo. Se nao der certo nao tem jeito, é intervenção tecnica e troca de MFD. espero ter ajudado.

Realmente o adenilton está de parabéns pela iniciativa, espero que toda a comunidade possa contribuir para que esse projeto de nf-e em C# não desanime. Aguardando!

Aqui na empresa, utilizamos o delphi para desenvolver nosso principal produto, um ERP, no entanto, neste ano fizemos uma análise do futuro do mercado de software e temos visto que o visual studio tem agregado uma série de tecnologias até então indisponíveis no delphi, e que, com exceção do Brasil e Russia, o delphi tem perdido força no mundo inteiro, fazendo com que em agumas regiões já não se encontre mão de obra especializada. Por isso vamos desenvolver a solução para NFCe em visual studio e C#. Quando decidimos isto, fizemos uma pesquisa por bibliotecas que já estivessem prontas para tal, e analisamos a UniNfe da Unimake Software, o ACBRNFeMonitor e o projeto Open NFe. No caso da UniNfe, vimos que ela implementa o consumo dos webservices para NF-e, NFC-e, CT-e, MDF-e e NFS-e e faz a Integração ao ERP via arquivos, mas infelizmente não gera o XML e não possui classes para tal. Outro ponto negativo é o fato de ter que persistir arquivos em disco para poder consumir os serviços, o que diminui a eficiência. O ACBRNFeMonitor possui integração via troca de arquivos, como no caso da UniNfe, e via telnet, mas o retorno de alguns serviços deixa a desejar pelo fato de devolver uma resposta em formato diferente dos manuais para aquele serviço. Outro fator é a integração com o C#. Por último o OpenNFe tem um acoplamento forte com o Sql Server, e ainda a forma como foram implementadas as classes não facilita o uso. Basicamente o autor pegou os schemas e importou-os no c#, sem muito tratamento. No meu caso, estou tendo o cuidado de escrever as classes seguindo rigorosamente os manuais disponíveis, inclusive quanto a forma como os serviços são consumidos. Até mesmo os comentários para cada campo disponíveis nos manuais foram adicionados em cada campo de cada classe. Uma coisa que percebi analisando o código do componente do ACBR para NFe é que por conta das limitações do Delphi, o estilo de programação utilizado apresenta risco considerável e dificuldade de manutenibilidade do código. Por exemplo, existe muita, mas muita magic string no código, enquanto no C# o tratamento de XML é nativo via serialização. Em breve postarei mais informações sobre a biblioteca, saudações.