Painel de líderes

Link: https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CDIQFjAC&url=http%3A%2F%2Fwww.fazenda.rj.gov.br%2Fsefaz%2Ffaces%2FowResource.jspx%3Fz%3Doracle.webcenter.doclib!!UCMServer%252523dDocName%25253AWCC226501&ei=JeY-VerpOorvtQXVioH4Bw&usg=AFQjCNHIw3ehkW680PriCb7PK5VDtnczkA

Sim durante a semana irei subir quase todo componente e um exemplo simples de como usar ! depois será necessário gerarem os vários casos para corrigir caso tenha algo mas se for será minimo! desde já agradecemos a ajuda!

Bom dia, Sim, isso já esta sendo feito, será através de um arquivo INI. Se desejar testar no repositório alem do Trunk e Branches temos agora o Trunk2 com a nova versão dos códigos dos componentes, uma das mudanças é exatamente essa, as URLs em um arquivo INI.

Obrigado pela sugestão, esse recurso já foi implementado no Trunk2 que está em faze de testes para substituir a pasta Trunk.

Bom dia a todos! As perguntas que eu mais escuto no dia a dia sobre o assunto e que eu julgo mais interessante de serem comentadas são: - Qual é a melhor opção a ser utilizada, SAT ou NFC-e? - Como faço para utilizar o SAT em rede 1 para N? E eu sempre dou a maior atenção nas explicações para que fique claro a quem me perguntou e sempre me coloco a disposição para debater caso a caso. Normalmente eu começo pela segunda pergunta "- Como faço para utilizar o SAT em rede 1 para N?" E sendo assim eu explico a dificuldade de fazer um Sistema Gerenciador (Software + Hardware com contingência) que seja economicamente viável. Eu comentei isso no post quem quiser entender meu ponto de vista. Após isso boa parte das pessoas conseguem identificar que é melhor ter um SAT por ponto de venda. Mas é claro isso não é pra todos. E então eu converso sobre a primeira pergunta que e o assunto deste tópico "- Qual é a melhor opção a ser utilizada, SAT ou NFC-e?" Utilizar a NFC-e é uma bela opção. Eu diria que seria o mundo ideal, a perfeição. Porém estamos diante de máquinas, sistemas e meios de comunicação que não são perfeitos nem tem 100% de disponibilidade. Sendo assim para utilizar a NFC-e temos que ter em mente que teremos alguns momentos de indisponibilidade, sejam eles causados pela Sefaz, pela rede interna, pela internet, por uma lentidão no trafego de dados, etc. Sejam eles curtos ou duradouros. E nestes momentos os estabelecimentos deverão ter um meio de gerar cupons de maneira off line para poder continuar operando, seja EPEC ou SAT. Nenhum contribuinte vai querer ficar parado aguardando estabilidade nm sistema on-line onde quer que o problema esteja. Como o melhor meio para emitir cupons off-line no estado de São Paulo é através do SAT o Aplicativo Comercial terá que gerar um novo XML e enviar para o SAT. E assim ter uma resposta instantânea. Você até pode usar EPEC, mas cai nas mesmas possibilidades de disponibilidade de rede, internet e sefaz. Vamos pensar como desenvolvedor em duas maneiras: 1 - Pra quem usa definitivamente o SAT: - Eu já tenho um SAT por PDV. (fui convencido pelo outro post) - Eu desenvolvo um Software que utiliza somente o SAT. - Eu emito as notas de maneira instantânea. 2 - Pra quem usa NFC-e e em contingência usa o SAT. - Eu já tenho um SAT por PDV. - Eu desenvolvi um Software mais complexo que utiliza NFC-e e em contingência utlizar o SAT. - Eu não tenho certeza da disponibilidade da Sefaz, a Sefaz também fica "fora do ar". - Eu não tenho certeza da disponibilidade da minha rede interna, pois pode um dia falhar. - Eu não tenho certeza da disponibilidade da minha internet, pois posso ficar dias sem internet. - Eu não tenho certeza da velocidade da minha internet, pois ela pode ficar lenta, ficar rápida, lenta, rápida, etc. - Quando isso acontecer meu sistema tem que identificar por um "timeout", gerar outro xml e enviar pro SAT. - E então eu emito as notas de maneira instantânea pelo SAT. Ou seja, eu tenho a possibilidade de ter um sistema instantâneo (SAT) e coloco um sistema que eu não tenho certeza por conta da disponibilidade da infraestrutura e quando eu perceber isso eu volto pro sistema instantâneo que eu já tinha disponível??? Até hoje eu ainda não encontrei um Sistema Gerenciador que seja economicamente viável e por isso eu defendo um SAT por PDV e quando tratamos a duvida entre SAT e NFC-e fico ainda mais convencido que utilizar o SAT definitivamente é a melhor opção. Em resumo, pra que trocar o Certo pelo Duvidoso?

Amigos favor desconsiderar o post acima, porque a sefaz somente autoriza a NF-e com o tamanho do campo xNome limitado em 60 Caracteres. obrigado!

De forma educada, pergunte a ele de o porquê de ele pensar ser necessário fazer esse tipo de teste. Tente descobrir de onde ele tirou isso...

O momento é de apoio. Eu apoio e confio, afinal, já demonstraram inúmeras vezes serem competentes no que fazem. Estou tranquilo e certo de que tudo se resolverá. Que bom que vocês existem. Que bom que o ACBr existe. Já estou assinando o SAC pois este é o nosso retorno mínimo a vocês todos. E a mim também, pois uso o ACBr! Abraços e obrigado!

Não. Os projetos ACBrMonitor e ACBrNFeMonitor é que serão unificados no ACBrMonitorPlus.

Assim que a DLL assume o comando a operação está com ela... Por favor consulte o fabricante a respeito do tempo de processamento

Bom dia Guto, Você esta fazendo errado, o correto é: with Ide.NFref.add do begin RefECF.modelo:=ECFModRef2D; RefECF.nECF:=cdIdentificacao.FieldByName('NFE_ECF').AsString; RefECF.nCOO:=cdIdentificacao.FieldByName('NFE_COO').AsString; end;

Ola Ítalo. Suspeitei dede o princípio ehehehe... Na verdade eu criei um form onde inseri várias funções tanto de nfe como de nfse, pois não sabia desse detalhe de não poder usar os dois no mesmo form. É possível sim separar as funções da nfe da nfse em dois forms diferentes. Vai dar um pouco de trabalho, mas nada impossível. NFSe é uma coisa que vai começar a ficar mais "popular" daqui pra frente, pois as prefeituras estão se mobilizando nesse respeito. Sendo assim, fica a dica aos demais colegas que forem implementar nfe e NFSe nos seus sistemas, que não usem os dois no mesmo formulário. Obrigado.

Boa noite, Como faz falta uma pesquisa. Esse problema já foi respondido em outros tópicos. O seu erro é que não esta iniciando o numero do DI com o dígito "2".

Boa noite Suziane, Até onde sei, não existe Carta de Correção para NFC-e.

uma dica. segundo legislação do paf-ecf, no inicio do dia o paf deve verficar se existe redução pendente e, caso tenha, emitir automaticamente. Sendo assim, não deve ter intervenção do usuário.

https://github.com/mantisbt-plugins/source-integration

DATAC, você é um Guerreiro, quando for possivel disponibilizar o executavel agradeço, continuo na coruja. HASA

Bom dia, Informe 91 como sendo o órgão autorizador.

Olhou o branches do svn?

Boa tarde Michel, A NFC-e nada mais é uma NF-e com uma pequena alteração, em vez do código do modelo ser 55 é 65. Resumindo: NF-e => Modelo = 55 NFC-e => Modelo = 65 Sendo assim o XML são exatamente iguais e em ambos os casos o XML é considerado documento fiscal válido juridicamente se o mesmo for assinado com um certificado digital tipo A1 ou A3 (cartão ou token) mais o protocolo de autorização retornado pela SEFAZ-Autorizadora do Emitente da nota. Atenção o token que eu fiz referencia acima se refere ao certificado digital tipo A3 vendido em formato pen-drive (token). O DANFE da NF-e é impresso em papel A4, por outro lado o DANFE da NFC-e é impresso em bobina - impressora não fiscal. O DANFE da NF-e possui um código de barras que representa a chave de 44 dígitos. Por outro lado o DANFE da NFC-e não possui esse código de barras e sim um outro tipo de imagem chamado QR-Code. O QR-Code impresso no DANFE da NFC-e não representa a chave e sim uma URL (um endereço de internet) que nos retorna na tela do computador ou celular o DANFE completo da NFC-e. A URL do QR-Code é composta por uma dezena de informações, sendo que uma delas é o CSC - Codigo de Segurança do Contribuinte que no componente é chamado de Token. Por que no componente esta Token em vez de CSC, só para confundir os desenvolvedores, não. Nas primeiras documentações referentes ao QR-Code do DANFE da NFC-e o termo usado era Token, mas agora a documentação mais recente já faz referencia a CSC em vez de Token. Inclusive em breve será disponibilizado a todos os usuários do ACBr uma nova versão dos componentes e uma das alterações é justamente a palavra Token que foi substituída por CSC. Portanto se você ler algo sobre Token relacionado a QR-Code não se trata do certificado e sim o CSC que nada mais é do que um código alfa numérico. Espero ter ajudado.

Bom dia a todos, Um esclarecimento sobre a sua postagem Rubens. 1. No inicio, ou seja, no projeto piloto da NFC-e a SEFAZ chamava esse código de segurança de Token, depois resolveram mudar o nome para CSC - Código de Segurança do Contribuinte, pois algumas empresas e desenvolvedores do projeto estavam confundindo com o certificado digital no formado Token, portanto o que foi alterado é apenas o nome dado ao código. 2. Para emitir uma NFC-e, ou seja, gerar o XML, assinar, validar, enviar para SEFAZ, etc. não há necessidade do CSC, uma vez que esse código não esta presente no XML, não é utilizado para realizar a assinatura, logo se o XML for válido pela SEFAZ, será retornado o protocolo de autorização. 3. O CSC só é utilizado para compor a URL usada para gerar o QR-Code, que por sua vez é impresso no DANFE, se o consumidor não possui um leitor de QR-Code, ele pode se utilizar da chave para consultar a nota na SEFAZ. Ao ler o QR-Code que contem um CSC de homologação a SEFAZ vai buscar a nota no ambiente de homologação, como a nota foi emitida no ambiente de produção, será retornado a mensagem de que a nota não existe. Espero ter ajudado.

Bom dia Pessoal Estive na Polimig/SP semana passada realizando a homologação da versão 0202. Segue algumas observações sobre minha homologação: - DAV e Pré-Venda: Tudo tranquilo nos testes, de acordo com o roteiro, só um detalhe: ao mesclar nn pré-vendas, e imprimir o cupom fiscal da nova pré-venda gerada, antes da emissão deste cupom fiscal, deve ser emitido cupom e cancelamento das pré-vendas de origem. Talvez tenha sido falha minha não implementar, mas passou despercebido pois não estava claro no roteiro que deveria ser assim. Mas implementei na hora e tudo deu certo. - Menu Fiscal: - Para gerar os arquivos da MF e MFD, deve-se gerar o EAD do binário e colar em um novo arquivo txt (que contém somente o EAD). Abrir o binário, pressionar Ctrl + end e colar o EAD. A assinatura então é validada no cECFc. - Me pediram para retirar a emissão da redução Z do menu fiscal, na minha primeira homologação este recurso ficava neste menu e não me questionaram, mas agora não permitiram. Dica: deixar no menu fiscal exclusivamente os recursos requeridos no requisito. - Registros do PAF: - Sangria e Suprimento não devem sair em nenhuma linha do arquivo. - R06 - ficar atento aos campos GNF E GRG. Não dei muita atenção aos dois (falha minha), mas o homologador verificou se estava correto em todas as linhas. - Cupom fiscal eletrônico: Utilizei o ambiente de teste do Amazonas para emitir, e somente no perfil Y imprimi o danfe via relatório gerencial, gerando ainda um DAV no banco de dados (que deverá aparecer no D2 e D3). Como a impressora fiscal não imprime QRCode, imprime via texto, o site para consulta e a chave de acesso, entrei na página, informei a chave e o homologador verificou se os dados estavam corretos. Teste finalizado. No Sintegra, coloquei o cupom eletrônico no 61 e 61R. Foi solicitado para emitir NFC-e com 5 tributações diferentes (no mesmo cupom). - O requisito X (LFD - Distrito Federal) não é validado, basta que no arquivo tenha os registros solicitados no requisito. - Requisito XVI - troco no cartão em SC e doação. O troco pode ser destinado para doação a alguma instituição. Se foi concedido troco, deverá ser aberta uma tela onde o usuário poderá digitar o CNPJ e Razão Social da entidade beneficiária, o sistema então, após a emissão do cupom e comprovante do TEF deverá imprimir um Rel. Gerencial contendo CNPJ + Razão Social + Valor Doado. - Nota Fiscal Eletrônica: emissão, transmissão e validação no site da SEFAZ. Teste então, concluído. Foi solicitado para emitir NFe com 5 tributações diferentes (na mesma nota). - Testes do restaurante foram bem tranquilos: abertura de mesas, transferências, impressão de conferência, geração do cupom fiscal, validação do S2 e S3 no Registros do PAF. E os mesmos testes para Conta de Clientes. Testamos ainda a integração com a balança (que não é obrigatória). - Todos os MD5 devem ser gerados em caixa alta. - Testes do bloco 7: sem dúvida, o teste mais demorado, ficamos 1 dia inteiro somente para isto. São validadas as alterações de todos os campos de cada registro do arquivo + razão social da empresa em caso de inclusão/exclusão em algum registro. - Minha homologação demorou 3 dias e meio e contemplou os seguintes itens: -DAV e Pré-Venda - Troco no Cartão (SC) - LFD - Distrito Federal - Cupom Fiscal Eletrônico - Restaurante - Minas Legal, Cupom Mania, Nota Legal e Paraíba Legal. Espero ter ajudado! Estou à disposição para qualquer dúvida. Segue meu contato: [email protected]

Esse erro tem relação com o tempo de resposta pelo webservice, o componente ao enviar uma nota recebe o protocolo com o tempo que será processada nota, ele aguarda esse tempo e tenta novamente, dependendo das suas configurações ele vai retornar esse erro porque excedeu esse tempo. Você pode tentar configurar o componente da seguinte forma, e verificar se o problema para de ocorrer: ACBrNFe1.Configuracoes.WebServices.AguardarConsultaRet := 30000; <----- Tempo que o componente irá aguardar pelo retorno da consulta ao protocolo de recebimento ACBrNFe1.Configuracoes.WebServices.AjustaAguardaConsultaRet := True; <----- se true acerta a propriedade anterior para o valor retornado pelo webservice no protocolo de envio ACBrNFe1.Configuracoes.WebServices.IntervaloTentativas := 10000; <------ intervalo que o componente irá aguardar antes de tentar novamente ACBrNFe1.Configuracoes.WebServices.Tentativas := 5; <------ numero de tentativas que o componente irá fazer antes de emitir o erro Esse erro é ligado geralmente a problemas de conexão ou erro no webservice, o que o componente faz é tentar novamente até conseguir conforme as configurações que você fizer.

Boa tarde, É o seguinte zumbi, este erro e comum em clientes com internet muito ruim, eu mesmo ja passei por isso. Há varias maneiras de vc identificar e corrigir a situação: - se ocorreu erro 105 (mais comum por lentidão no ws). você só tem que armazenar o recibo e então consultar a situação da NFe mais tarde. - se por algum motivo não receber o retorno, voce pode consultar a situação da nota quando estiver efetuando o reenvio. - quando você efetuar o envio da e retornar duplicidade, dois tipos de retorno você poderá receber. 1 - Duplicidade de NF-e: quando foi efetuado o envio da NF-e mas esta com a mesma chave. 1 - Duplicidade de NF-e com chave diferente: neste caso, houve envio da nf-e duas vezes mas gerou o cNF diferente para cada uma, neste caso, na mesma msg de resposta você receberá a chave de acesso numero do recibo que foi utilizado na primeira emissão. Você só tem que pegar esse recibo e chave, atualizar seus arquivos com eles e efetuar o BuscaProc utilizando estas informações. Ou seja, seu primeiro envio esta correto, o segundo envio esta incorreto e vai ser ignorado e a primeira nota vai estar autorizada. Basta você analisar a situação e preparar teu aplicativo pra se comportar de acordo com a situação.