Painel de líderes

Pessoal segue link da oficialização do leiaute 1.4. http://normas.receita.fazenda.gov.br/sijut2consulta/link.action?visao=anotado&idAto=95254 Ainda não iniciar as alterações, por isso não mexi nada do ACBr. Na próxima semana vou começar a ajustar o sistema e aí inicio. Se alguem for alterar me avisa, para que não façamos o mesmo evento. Assim ganhamos tempo. Abraço

@Dio, Boa noite! Essa balança é versão de check out? Qual o ano de fabricação da Balança? Tem alguns pontos para você testar. 1) O computador é novo e/ou usado, se for usado, faça a instalação de uma placa PCI de portas paralelas. Porta OnBord costuma dar problema. 2) No exemplo do ACbr, escolha apenas Toledo; 3) Velocidade, você configurou nela, ou esta testando? normalmente elas são 4800. 4) Essa versão o cabo de energia é tipo uma fonte de celular, onde você tira o cabo do carregador? Se sim, faça a ligação da balança no computador ao invés do carregador. 5) Caso ligue o cabo da balança na USB do computador, não precisará de fazer ligação via serial, basta fazer a instalação de um driver da própria toledo que faz a emulação de uma porta serial no windows. E nesse caso você fará a comunicação pela porta USB. Espero que consiga te ajudar.

Bom Dia @Felipe E. Resende Mesquita consegui resolver o problema e não consegui apagar o tópico. nomes de atributos iguais ao da classe do acbr dentro de um with. Obrigado

Muito obrigado pelo retorno. Tópico Fechado, para novo assunto favor criar um novo tópico.

Italo muito obrigado... Deu certinho agora..

Bom dia Fernando, Veja que no seu XML, você está passando o código da receita de ICMS ST e o detalhamento da Receita do DIFAL. <c02_receita>100099</c02_receita> <c25_detalhamentoReceita>000005</c25_detalhamentoReceita> Tente passar desta forma e veja se dá certo <c02_receita>100099</c02_receita> <c25_detalhamentoReceita>000003</c25_detalhamentoReceita>

Fabiano foi tiro e queda com o cabo USB pegou de primeira, Muito obrigado pela ajuda vlw!!!!

Vlw, fiz, assim: CST=90 NCM:00000000 VICMS=560,00 UNIDADE: R$ FINALIDADE(FINNFE)=3

Creio que quanto a sua dúvida já foi esclarecida, cumprindo o objetivo da abertura do tópico. Portanto estou fechando ele, se surgir nova dúvida, abra novo tópico.

Boa tarde a todos! Referente ao nº do DI, é necessário ficar atento à quantidade de zeros à esquerda que vem especificado no documento, após o ano e antes do digito final. Um cliente precisou fazer uma nota de importação hoje, na qual o nº do DI no documento recebido da transportadora era no formato: AANNNNNNNNND, onde: AA -> Ano com 2 posições (18) NNNNNNNNN -> nº do documento de importação com zeros à esquerda até completar 9 dígitos. D -> Digito Verificador. Para dar certo na validação do ACBR tive que retirar os zeros à esquerda do nº do documento, ficando no formato TAANNNNNNND, onde: T -> Tipo de documento = 2 - Documento de Importação (DI) AA -> Ano com 2 posições = 18 NNNNNNN -> nº do documento com zeros a esquerda até completar 7 dígitos D -> dígito verificador.

A empresa vai emitir uma nota com finalidade 3 (Ajuste) para ela mesmo, no item, vai lançar um item com a referencia CFOP1604, na descrição pode sair como lançamento de credito de ativo imobilizado ou coisa parecida, e vai colocar o valor do icms no campo próprio do icms no item e somá-lo no total do icms da nota.

Olá pessoal. Estou com uma situação/problema em relação ao uso do estadoSimuladoECF. Não é nada errado no ACBr apenas dúvida de como implementar. Estudei o demo do ACBrNFC-e + TEF e consigo realizar o procedimento normalmente, já me situei quanto à necessidade do "estadoSimuladoECF". Mas estou com a seguinte situação agora: Cenário: - Transação com 2 cartões + NFC-e. - Seq. 44 (Sequência 44) do roteiro de pré-homologação. Nela é solicitado que eu passe o 1° cartão normalmente, e assim que solicitar para inserir o 2°, eu devo desligar o PC e impressora. No retorno a transação TEF deveria ser Cancelada. Situação/Problema: Ao religar o computador e inicializar o meu PDV (e o ACbrTEFD), é acionado o método VerificarTransacoesPendentes da classe ACBrTEFDClass e executado este código: // Cupom Ficou aberto?? ...Se SIM, Cancele tudo... // if (wEstadoECF in ['V', 'P', 'N', 'O']) then CancelarTransacoesPendentesClass else // NAO, Cupom Fechado, Pode confirmar e Mandar aviso para re-imprimir // ConfirmarESolicitarImpressaoTransacoesPendentes; O problema é que, diferente de uma impressora ECF, aqui eu não sou forçado a comunicar novamente com a impressora (para recuperar o cupom ECF) e nem tenho como recuperar o ultimo valor atribuido à variável "estadoSimuladoECF". Sendo assim, ao invés de Cancelar a transação, ela é aprovada. Obs: Meu ACbrTEFD com NFC-e sempre inicia com o estado "tpsLivre". Tenho uma solução em mente: A cada alteração, armazenar o valor da variável "estadoSimuladoECF" em um arquivo INI (ou BD local do PDV), e quando houver alguma queda bruta de energia, eu recupero esta informação e se o valor for "tpsPagamento" (EstadoECF='P') então faria o cancelamento normalmente tal como está no Roteiro. Eu não queria implementar sem postar aqui para ver se alguém tem uma sugestão melhor e também para ficar registra a solução, a fim de ajudar outros membros. Obs: Não se se fui bem claro. De qualquer forma segue abaixo a desrição do roteiro: Desde já agradeço.

Depois de muito insistir, recebi o retorno da SEFAZ: " Já solicitamos a correção do erro apontado. A mesma será realizada no decorrer da próxima semana." agora é aguardar.

Pelo que estou vendo o seu leitor não é serial e sim de teclado. Não tem a necessidade de utilizar o ACBrLCB e nem o ACBrMonitor. Nesse caso funciona como se alguém digitasse o código diretamente no campo. Como funciona no notepad e no seu programa não, acredito que o seu programa é que esteja com problema. Esse programa de leitura de crachás é você mesmo que desenvolve? Se sim você deve depurar pra tentar achar o problema. Se não for você sugiro entrar em contato com que desenvolve pra verificar.

Boa tarde, Fiz uma alteração visando resolver esse problema, se você utiliza o ACBrMonitor aguarde a nova versão.

Olá Andre, Realizei as alterações aqui e consegui enviar corretamente. As tags vProd (uma preenchida e outra vazia) acabou me confundindo rsrs. Muito obrigado pela ajuda!! Tenha um ótimo dia!! Abraços

Capicom

Bom dia, Ivo Silva. Tópico antigo. Sugiro que crie um novo.

Bom dia, Dbs Brasil. Tente executar o método DistribuicaoDFePormaxNSU, verifique qual o maior NSU existente no Ambiente Nacional. Assim da próxima vez que você executar o DistribuicaoDFePorUltNSU, informe o valor correspondente ao período desejado, lembrando que a cada pesquisa é retornado 50 documentos.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Muito obrigado pela informação. Muito obrigado pela informação. Um abraço.

Novamente vc não informou o total no campo vNF. O campo vProd não deve ser informado no total, mas deve ser informado no item. E o campo cEAN/cEANTrib deve ser informado com a literal 'SEM GTIN'

Obrigado pela informação... vamos promover algumas melhorias no Instalador... para tentar mitigar esse problema...

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum. https://www.projetoacbr.com.br/forum/topic/46756-acbr-para-tokyo-1023-não-tem-ainda/?tab=comments#comment-308587

Bom dia Vagner, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia João, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

No caso de comunicação direta por USB dependemos de DLL do fabricante, que deve ter um método generico de entrada e saída de dados.. Use a força, leia os fontes... Abra a Unit ACBrECFEpson.pas e veja um exemplo de implementação de "Hook" da ACBrDevice

Bom dia, Sim, já fiz a correção e ainda hoje vou enviar para o repositório.

Bom dia, Pelo que pude ver o problema não é o envio do BP-e e sim o seu cancelamento, correto? Sendo assim necessito dos XMLs referente ao envio do evento de cancelamento bem como o seu retorno. Favor anexar os XML de envio do evento e seu retorno para que possamos analisar.

O campo <vNF>0.00</vNF> deve ser preenchido com a soma dos produtos e serviços.

Certo amigo, muito obrigado pela resposta. Porém quero aproveitar para entender um pouco melhor o ACBR. Como esse comunicação é feita? Via DLL ? Eu sempre achei que era feita diretamente enviando comandos binários para a portal serial.

Tem algumas situações onde o NCM passa com "00". Att Ricardo

Ok Amigo. Fiz o seguinte agora. Retirei as dll das pastas onde eu tinha colocado, apaguei tudo que era de acbr do Delphi, baixei novamente o acbr usando o Tortoise, instalei novamente com as configurações que vc me enviou. Resultado: dando o mesmo erro. Desinstalei tudo novamente fui no ACBrInstall_Trunk2.exe e mudei as propriedade coloquei para executar em compatibilidade com win7 e com administrador. Resultado: Delphi abriu sem erros. Muito obrigado pela ajuda.

Boa noite, Gabriel Lazarin. Uma sugestão: A CAPICOM está obsoleta, sugiro que leia o tópico abaixo: Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Problema resolvido. Fiz as seguintes alterações: Estava dessa forma: Configuracoes.Geral.SSLLib = libCustom Configuracoes.Geral.SSLCryptLib = cryCapicom Configuracoes.Geral.SSLHttpLib = httpNone Configuracoes.Geral.SSLXmlSignLib = xsNone Alterei para: Configuracoes.Geral.SSLLib = libCapicomDelphiSoap Configuracoes.Geral.SSLCryptLib = cryCapicom Configuracoes.Geral.SSLHttpLib = httpIndy Configuracoes.Geral.SSLXmlSignLib = xsMsXmlCapicom Deu certo, obrigado pela atenção Felipe. Abraço

Boa noite, Dio. Tópico antigo. Sugiro que crie um novo.

Não há suporte de Túnel USB por DLL para essa marca de ECF....

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Desculpe , não tinha percebido !!! Colocarei o arquivo do log da próxima vez. Mas o problema acima foi resolvido, solução : Liguei para plantão fiscal, e o suporte do integrador falou que já tinha sido reportando esse erros por outras softhouse e que em algumas máquina isso estava ocorrendo, então ele passou uma atualização das dll do integrador que ainda não consta no site da sefaz. Substitui e resolveu o problema. Realmente depois de várias instalações eu ainda não tinha me deparado com esse problema. Fica a dica se alguém passar pelo mesmo problema.

Bom dia @Joao Paulo Pires Quando a gente diz enviar novamente o XML é pelo comando consultar e não pelo EnviarNFe. Procedimento: - Quando ocorre o problema que você comentou, tipo ficou em processamento ou caiu a conexão, ou os servidores da SEFAZ estava lento e deu timeout, o próximo passo será uma consulta com o envio do XML. (Veja que diante do processo que já falamos aqui, você tem a chave da nota gravada, você tem o XML sem a autorização. Agora basta só a consulta. Quando você informa o caminho e o arquivo XML, nesta consulta o XML é enviado e se a nota estiver lá na SEFAZ, ao voltar o protocolo de autorização já vai estar acrescentado ao XML que você enviou. - Caso você receba o status 217 - NFe não consta na base de dados da SEFAZ, neste caso você envia pelo NFe.EnviarNFe() ou NFe.CriarEnvairNFe(), pois mesmo que venha ser gerado outro XML, não existirá nada lá para ser confrontado, como está ocorrendo hoje que você já tinha e com um DigestValue diferente do último arquivo que você envia.

Bom dia @elixandre Evite colocar trechos de log tão longos em sua postagem, sempre prefira anexar os arquivos. Att.

Boa tarde! Será bom você fazer uma consulta sobre o tema DigestValue para você entender o que isto significa. Vou tentar de forma rápida e simples explicar, maiores informações procure por este tema no google. Você gera um XML, assina e com base em todo o conteúdo "dados" informado no arquivo, é calculado uma chave que permitirá a verificação posterior do arquivo para saber se o arquivo foi ou não alterado. Esta chave no XML estará em DigestValue. Ao ser processada e autorizada esta chave (deste XML) retorna no protocolo da autorização na tag DigVal. Se você teve um problema e tentou enviar outra vez o XML e qualquer alteração ocorrer neste XML (Digamos você, está montando novamente, ao invés de usar o primeiro XML gerado) e ele já se encontra autorizado. Você tem agora o problema que está te ocorrendo. Foi gerado outra chave que estará no teu último XML em DigestValue e a SEFAZ vai te retornar o protocolo de autorização do primeiro XML que foi autorizado aonde a chave DigVal estará diferente deste último. (Por isto a importância de você ter o XML gerado arquivado). (Respondi como obter o XML mesmo sem autorização em outro tópico que você questionou a respeito.) Respondendo a tua pergunta: Deve. É obrigatório? Não. Pois isto é uma opção a mais desenvolvida pelo ACBr para dar confiabilidade nos XML que você está arquivando. Alguem pode recusar receber um XML aonde DigestValue não é o mesmo que Digval do protocolo? Sim. Pois está indicando que algo foi alterado ou modificado do XML que recebeu. Porém hoje em dia muitas empresas utilizam a ciência da operação e após fazem o Download pelo servidor, nem dando importância ao XML que você enviou para o destinatário. Neste caso o teu cliente estaria baixando o XML correto, mesmo o teu estando com este problema. Portanto a decisão será sua em manter ou não, mas que você está fornecendo um XML errado, isto sem dúvida.

Boa tarde Liliane, O idCSRT é um numero sequencial: 001, 002, .... Por outro lado o CSRT - Código de Segurança do Responsável Técnico que eles chamam de forma errada de token, será fornecido pelo Fisco, conforme consta na Nota Técnica. Nesse primeiro momento você não precisa se preocupar, pois o grupo <infRespTec> é opcional, podendo ser obrigatório se a UF do emitente do CT-e assim desejar. Se isso vir a ocorrer, que acredito que venha, os campos idCSRT e hashCSRT são opcionais e depende de uma implementação futura, ou seja, primeiro o Fisco tem que estar pronto para fornecer o CSRT do Responsável Técnico, caso contrario não tem como incluir essas informações no XML. Quero chamar a atenção referente a palavra token, pois ela nos remete ao certificado digital A3 em formato de pen-drive, chamado pelas certificadoras de token. O token que a Nota Técnica se refere neste caso é o CSRT, ou seja, trata-se de um código alfanumérico que será fornecido pelo Fisco. Quando for publicado a Nota Técnica sobre o idCSRT e CSRT bem como o calculo do hashCSRT, com certeza vamos fazer uma alteração no componente visando atender essa NT.

no evento OnInfoECF, No evento normal é passado dessa forma ineEstadoECF: RetornoECF := sEstadoECF; //Variavel Global Para NFC-e segue abaixo o codigo procedure TF_Relatorio_Fiscal_ECF.ACBrTEFD_NFCeInfoECF(Operacao: TACBrTEFDInfoECF; var RetornoECF: string); begin case Operacao of ineSubTotal: begin RetornoECF := '0'; end; ineTotalAPagar: RetornoECF := '0'; //Como informo Pagamento a Pagamento para o TEF não existe valor a pagar no meu programa. ineEstadoECF: RetornoECF := 'L'; end; end;

Efetuei a validação desse XML aqui usando o demo do ACBrNFe e ela validou normalmente, tem certeza que os seus schemas estão todos atualizados?

Régys, a NT2011/004 alterou o tamanho deste campo para 12. (Manual_de_Orientacao_Contribuinte_v_5.00) E o emissor gratuito transmite normal. Qualquer outra dica será bem vinda. Obrigada pela atenção.

O número da DI está com 12 caracteres, quando o correto seriam apenas 10 caracteres.