Painel de líderes

Você já conhece o ACBrMTer ? Ele é um componente do pacote ACBrTCP, que permite construir de maneira fácil, rápida e segura, uma aplicação comercial para gerenciar uma rede de Micros Terminais. Mas afinal, o que são os Micro Terminais ? São equipamentos de baixo custo, e muito robustos.. Eles não são um computador, e não permitem a instalação de software em sua memória. Eles atuam na verdade como "coletores de dados", e transmitem por TCP/IP, as informações coletadas a um Servidor, que as processa, e se necessário, envia comandos de volta ao Micro Terminal. Os Micro terminais, são ótimos para aplicações que implementam um atendimento no balcão, geralmente com auxílio de uma comanda. Os Micro Terminais, normalmente possuem duas portas Seriais, para ligação de equipamentos externos, como: Leitores de Código de Barras Impressoras Balanças Como funciona o componente ACBrMTer ? O componente ACBrMTer, é um Servidor TCP/IP. Ele abre uma porta TCP, normalmente 6550 ou outra, conforme a sua configuração. Após ativado, o ACBrMTer aguarda as conexões dos Micro Terminais, e dispara eventos para a sua aplicação, sempre que um novo Micro Terminal se conectar ou desconectar a ele. O ACBrMTer mantém de forma automática, uma lista de Micro Terminais conectados, e você pode se referenciar a cada um deles, pelo numero do IP da conexão. Todas as informações que o Micro Terminal transmitir, serão recepcionadas pelo componente ACBrMTer, que após tratá-las de acordo com o Protocolo do Micro Terminal, as transmitirá para a sua aplicação, através do evento OnRecebeDados. Como você provavelmente terá vários Micro Terminais na sua rede, o ACBrMTER envia no evento OnRecebeDados, o IP do Micro Terminal que as transmitiu... Um Micro Terminal irá transmitir dados, quando o usuário teclar algo no Equipamento, ou ainda quando o mesmo receber informações pela serial, como por exemplo de um Leitor de Código de Barras, ou Balança. Através do ACBrMTer, você pode enviar Comandos para o Micro Terminal, para realizar tarefas como por exemplo: Apagar ou Definir o texto no Display Movimentar o cursor Emitir Beep Comandar equipamentos, ligados a ele, como: Impressoras ou Balanças O ACBrMTer suporta os seguintes protocolos: mtrVT100: Protocolo simples, e usado em equipamentos antigos, esse protocolo não prevê respostas do Micro Terminal aos comandos a ele enviados. Esse protocolo é geralmente aceito por vários modelos de Micro Terminais, (por motivos de compatibilidade) mtrStxEtx: Mais completo que o VT100, e com controle de Recepção (ACK) de alguns comandos, esse protocolo é provavelmente o mais usado nos diversos Micro Terminais disponíveis no mercado. mtrPMTG: Protocolo bastante completo, e proprietário da Gertec mtrSB100: Protocolo nativo dos Micro Terminais da Bematech, e criado como uma melhoria do protocolo StxEtx Assim como os demais componentes do ACBr, o ACBrMTer irá abstrair a diferença entre os diversos protocolos suportados, de maneira que você não precise se preocupar com eles. É comum os Micro Terminais suportarem mais de um protocolo, o que pode ser definido em sua configuração Você poderá encontrar a documentação que usamos para o desenvolvimento do componente, em: http://svn.code.sf.net/p/acbr/code/tools/MicroTeminal/ Para que o ACBrMTer saiba se comunicar com as Balanças, e enviar comandos para leitura de Peso, e interpretar a resposta da Balança, é necessário conectar o componente ACBrMter em um componente ACBrBAL, e configurar no ACBrBAL, o Modelo ou protocolo, da Balança Como posso ver na prática ? Alguns fabricantes, como a Gertec e WillTech, fornecem emuladores, o que pode ser muito útil para conhecer o conceito desses equipamentos... Mas penso que é fundamental um equipamento real, se você deseja realmente construir aplicações para esse tipo de equipamento. Demo do ACBrMTer rodando em conjunto com o Emulador da Gertec Use a Força, leia os Fontes... Estude os fontes do Demo, que estão na pasta: \ACBr\Exemplos\ACBrTCP\ACBrMTer, essa é a melhor maneira de compreender o funcionamento do componente... Observe que fizemos uma "mini aplicação", que simula o Fluxo de uma Venda com comandas Para dúvidas e suporte ao ACBrMTer, por favor crie um Novo Tópico no sub-fórum do ACBrTCP https://www.projetoacbr.com.br/forum/forum/11-acbrtcp/

Boa tarde a todos, Alguns já devem ter visto na estrutura do XML um grupo chamado autXML. O que vem a ser esse grupo? Trata-se de um grupo opcional que permite informar até 10 CNPJ ou CPF de pessoas que estão autorizadas a baixar o XML completo, pessoas estas que não figuram com atores do documento fiscal eletrônico em questão. Por exemplo: em uma NF-e temos os seguintes atores: Emitente, Destinatário e Transportador. O Emitente por ser o responsável por emitir a NF-e, tem por obrigação possuir o XML do documento e disponibilizar o mesmo para os outros dois. O Destinatário por sua vez poderá baixar o XML da NF-e através do DistribuicaoDFe já explicado nesse tópico, mas se faz necessário enviar o evento de Manifestação do Destinatário. O Transportador poderá baixar o XML da NF-e através do DistribuicaoDFe e não precisa enviar nenhum evento. Mas eu gostaria que o contador da minha empresa pudesse também baixar o XML, isso é possível? Sim, basta incluir o CNPJ ou CPF do seu contador no grupo autXML. Desta forma o Contador poderá baixar o XML da NF-e através do DistribuicaoDFe e não precisa enviar nenhum evento. Lembre-se o único que não consegue baixar o XML é o Emitente do próprio documento, os demais conseguem baixar o XML completo (assinado e com o protocolo de autorização) desde de que seja um dos atores ou faça parte da lista do grupo autXML. Até o momento somente o Destinatário da mercadoria se faz necessário enviar o evento de Manifestação do Destinatário para poder baixar o XML completo, caso contrario terá somente um XML contendo um resumo da nota. O grupo autXML esta presente nos seguintes documentos fiscais eletrônicos: NF-e / NFC-e, CT-e / CT-e OS, MDF-e e BP-e. No caso do BP-e ainda não foi disponibilizado o DistribuicaoDFe para que seja possível baixar o XML. E também não esta disponível a baixa do XML da NFC-e pelo DistribuicaoDFe. Em caso de dúvidas, favor criar um novo tópico em: https://www.projetoacbr.com.br/forum/forum/3-dúvidas-gerais-sobre-o-acbr/

Boa tarde Pessoal, Primeiro foi o CT-e e o MDF-e a ter o seu layout alterado para contemplar um novo grupo: <infRespTec> Informações do Responsável Técnico, agora esta chegando a vez da NF-e. Os 3 componentes já estão preparados para gerar esse grupo. Alguns desenvolvedores já estão gerando o grupo <infRespTec> para o CT-e e MDF-e, tanto em homologação quanto em produção. No caso da NF-e as datas previstas são: para o ambiente de homologação é 25/02/2019 e para produção é 29/04/2019 alterado para 03/06/2019 (conforme consta na versão 1.30 da NT 2018/005). Quero deixar claro que essas datas se referem ao prazo para que as SEFAZ finalizem a implementação em seus webservices, portanto somente a partir dessas datas é que poderemos enviar o XML da NF-e com esse grupo. Portanto, a partir do dia 25/02/2019 teremos um prazo de 3 meses para realizar os testes em ambiente de homologação. Outra coisa importante a ser dita é que esse grupo é opcional, mas vai ficar a critério de cada UF torna-lo obrigatório ou não. Quais são as informações que compõe esse grupo? O grupo <infRespTec> é composto pelos campos: CNPJ da empresa que desenvolveu o software, xContato é o nome da pessoa responsável pelo software, email e fone dessa pessoa ou da empresa. Caso você opte por gerar esse grupo independente da UF exigir ou não, as 4 informações acima deveram constar. Como dito acima os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec>, para que isso ocorra basta acrescentar na sua rotina que alimenta o componente com os dados que vão fazer parte do XML as seguintes linhas... O exemplo abaixo é para a NF-e: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) infRespTec.CNPJ := xCNPJ_RespTec; // CNPJ da Empresa infRespTec.xContato := xContato_RespTec; // Nome do Contato infRespTec.email := xEmail_RespTec; // email do Contato ou Empresa infRespTec.fone := xFone_RespTec; // fone do Contato ou Empresa end; As linhas em negrito acima são exatamente iguais para o CT-e e MDF-e. Nas Notas Técnicas da NF-e, CT-e e MDF-e que se refere a esse grupo tempos ainda mais dois campos: idCSRT e hashCSRT que vão ficar para uma segunda etapa. O CSRT - Código de Segurança do Responsável Técnico, trata-se de um código alfa numérico que será fornecido pela SEFAZ através de uma página própria ou por um webservice, conforme consta na Nota Técnica. Sendo assim, enquanto a SEFAZ não criar essa página ou webservice não temos como solicitar o CSRT e portanto não podemos incluir no XML o idCSRT que é um numero sequencial e o hashCSRT que é o resultado do hash (SHA1 - Base64) da concatenação do CSRT mais a chave do documento. Os componentes já possuem no rol de configurações, as propriedades idCSRT (Integer) e CSRT (String), nessa primeira etapa devemos atribuir o valor zero a idCSRT e uma string vazia para o CSRT, para que os campos: idCSRT e hashCSRT não sejam gerados. Os valores padrões estabelecidos pelo componente são: idCSRT = 0 e CSRT = '' (string vazia). Reforço que o preenchimento dessas propriedades só devem ser feitas a partir do momento que a SEFAZ lhe fornecer o idCSRT e o CSRT. Vamos supor que as UF: x, y e z venham a exigir o grupo <infRespTec> e criem uma pagina ou webservice para fornecer o CSRT, caso você tenha clientes usando ou seu software para emitir NF-e ou CT-e ou MDF-e será necessário solicitar o CSRT em cada uma das UF. Resumindo o CSRT fornecido pela UF x só é valida para os seus clientes dessa UF que usam o seu software. Quais são as UF que vão exigir o grupo <infRespTec> não sabemos, logo devemos ficar atentos. A minha sugestão é que o seu software gere esse grupo independente da UF exigir ou não, pois o dia que ela resolver exigir você não vai precisar fazer nada, pois já consta no XML o grupo. A questão agora é quanto ao CSRT, como dito anteriormente, vai ficar para uma segunda etapa visto que, se faz necessário a SEFAZ criar a página ou webservice. O meu conselho é que no seu software na tela de configuração tenha os campos: idCSRT e CSRT para que você possa informa-los assim que obter. Detalhe importante, os campos idCSRT e hashCSRT só serão gerados no XML e de forma automática dentro do grupo <infRespTec> a partir do momento que as propriedades de configuração: idCSRT e CSRT passarem a ter valores validos. O texto ficou longo, mas espero ter passado todas as informações necessárias para que vocês possam fazer as alterações em seus softwares e desta forma ficarem em conformidade com as nas Notas Técnicas. Para quem não leu as NT, por favor leiam. NT 2018/005 versão 1.20 - Alteração do layout da NF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/NFe/NT/2018/ NT 2018/002 versão 1.01 - Alteração do layout do CT-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/CTe/NT/2018/ NT 2018/002 versão 1.02 - Alteração do layout do MDF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/MDFe/NT/2018/

Sempre acreditei que a informação deve ser algo democrático e acessível... Pensando nisso, tornei pública a nossa área de Base de Conhecimentos Nela você encontrará excelentes artigos, escritos pelos nossos experientes Consultores, e que tornarão o uso dos os componentes ACBr algo mais simples e funcional... Espero que gostem... e fiquem a vontade para sugerir novos artigos...

Parabéns pela iniciativa @Daniel Simoes. Sucesso!

Boa tarde Para quem utiliza o ACBrMonitorPLUS, está disponível nas últimas versões as tags referente ao Resp. Técnico, para NFe, CTe e MDFe. Os campos estão exemplificados no Manual que acompanha o ACBrMonitorPlus. Segue o modelo abaixo : [infRespTec] CNPJ= xContato= email= fone= https://acbr.sourceforge.io/ACBrMonitor/ModeloNFeINICompleto.html As configurações de CSRT e idCSRT devem ser preenchidas (quando disponibilizados pela SEFAZ da UF) em: Menu: DFe / Resp. Técnico https://acbr.sourceforge.io/ACBrMonitor/RespTecnico.html

Pessoal, Nessa segunda postagem sobre o grupo de Informações do Responsável Técnico, vou colocar o posicionamento de cada SEFAZ se vão exigir ou não, a medida que eu tomar conhecimento. SEFAZ-SP nesse primeiro momento não vai exigir. SEFAZ-RS nesse primeiro momento não vai exigir. SEFAZ-MS vai exigir o grupo.

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, foi relatado que um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes! Ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já deveria saber que seria rejeitado. Isso é na verdade um ataque de DDOS, nos servidores do SEFAZ. Talvez um ataque sem intenção, mas não deixa de ser um... Mas nesse caso, quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós do ACBr não sabemos como seu sistema funciona, muito menos conhecemos os seus clientes. Ainda mais, qualquer solução do ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe que o item "2.1 Código de Segurança do Responsável Técnico - CSRT" nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

???, Isso nem é novidade, partindo do ACBR. []s,

Boa tarde Exatamente assim que eu entendi !

Consegui algum erro de copiar e colar fui pela listagem selecionei e esta baixando Obg

Discordo do Secretário sobre "não ter aumento de arrecadação". Um restaurante que compra bebidas por um valor e revende por algo 3, 4 x maior com certeza irá pagar. Outra coisa o MVA é calculado em cima do custo inicial até chegar a para revendedor esse preço já está maior e o último da cadeia irá colocar seu 50% ou 100% em cima e irá pagar tranquilamente ter um aumento de 5% a 10%.

Boa tarde Não existe parâmetro para isso, houve uma reestruturação nos fontes, onde a resposta é gerada de forma dinâmica, baseado no nome das tags. Pode haver alterações em campos com Caixa Alta e na posição, mas os nomes permanecem os mesmos.

Segundo essa entrevista, esta mantido para o 01/03 no Rio Grande do Sul

ok vou ficar tentando, qualquer coisa aviso.

Parabéns Daniel... conhecimento ao alcance de todos...

Verifiquei que estava parametrizado para modo Assíncrono. Mudei para síncrono e está funcionando. Acredito ser algo relativo ao modo Assíncrono.

Acho que não há componente nativo para isso... a TMS parece ter um ótimo... https://www.tmssoftware.com/site/tmspack.asp?s=grid#features

Parabéns Daniel. Excelente iniciativa. Muito sucesso pra você e toda a equipe.

boa tarde.. Mandei dois xmls de exemplo para voce estudar com Nfe e outro Nfc-e. xml_pag.xml cupom_xml_17092018.xml

Pessoal, a Sefaz do Mato Grosso do Sul, já se manifestou. Segue mensagem encaminhada por um cliente do estado:

Opa.... Bom dia Felipe!!!! Então basicamente é de 65 da NFC-e para 55 na NF-e e informar no caso da NF-e o campo <natOp>5.101 Venda de producao do estabelecimento</natOp> por exemplo?

Algumas propriedades importantes, para o ACBrMter Modelo: permite definir qual será o protocolo dos terminais usados em sua rede, podendo ser: mtrVT100, mtrStxEtx, mtrPMTG, mtrSB100 Port: Define a Porta TCP que o ACBrMter deve abrir, para aguardar a conexão dos Micro Terminais da sua rede. Lembre-se de liberar essa Porta em seu Firewall EchoMode: Define o comportamento padrão das teclas recebidas pelos Micro Terminais, mdNormal irá exibir Tecla no Display do Micro Terminal: mdeNormal, mdeNone, mdePassword Terminador: Código em ASC do Terminador padrão, para o recebimento de dados... Normalmente vazio, pois dessa maneira os dados serão transmitidos a aplicação, assim que recebidos, independente do Terminador TerminadorBalanca: Define o Terminador do Protocolo de resposta da Balança, geralmente ETX (#3)... Isso ajudará o ACBrMter a identificar que os dados fora m recebidos de uma Balança TimeOut: Tempo máximo que o ACBrMTer, deve aguarda por uma resposta. Nem todos os comandos retornam dados, e isso depende muito do protocolo. Também é utilizado como TimeOut para leitura de Peso de Balanças WaitInterval: Permite causar uma espera de alguns milisegundos, após o inicio da recepção de algum dado pela Serial. Isso pode prevenir recebimento de dados truncados ou quebrados em várias segmentos. O Valor 0 desativa o atraso.

Bom dia Pessoal!!!! Muito obrigado pela ajuda. está sendo muito util. Pelo o que pude observar, os comandos para a geração da NFC-e é praticamente os mesmos da NF-e. Sendo assim, posso usar a mesma rotina da NFC-e para gerar a NF-e. Minha dúvida: Sendo que eu quero gerar uma NF-e simples. Sem os dados do transportador e outras informações que são específicas para a NF-e. O que exatamente identifica no arquivo XML gerado que é uma NF-e e não uma NFC-e?

Bom dia Italo, Sim, havia atualizado a pasta Schemas, mas havia esquecido de substituir o ISSDSF.INI Deu super certo, muito obrigada pela sua atenção!

Tranquilo pessoal. A intenção do tópico é mais de aviso do que de cobrança. Se eu fazer alguma alteração posto para vocês analisarem.

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

Bem , agora a sua vez de usar a força negra . usando nas danfe´s paisagem e retrato .

Pelo que entendi o manual pede pra preencher apenas com zeros. Sendo assim não é necessário criar uma nova propriedade.

Essa forma só funciona nos DANFE em Fast e Fortes. Em EscPos é preciso carregar a imagem do logo para a memória da impressora. Para o PosPrinter, para modelos compatíveis com o ppEscPosEpson, você pode usar o componente para fazer o carregamento do logo:

Vou iniciar o desenvolvimento de um novo componente ACbrGRFGTS. Será da mesma forma que fiz o ACBrReinf e concluir o ACBreSocial! Assim que tiver os fontes funcionais eu compartilho com todos.. Aguardem!

Boa tarde Tathiana, Favor atualizar os fontes e faça novos testes.

Boa tarde Alguém tem alguma notícia se vai ser prorrogado novamente ?

Na opção "Mostrar original" do gmail, veja a parte de anexos:

Veja:

Na verdade, na nota tecnica não explica direito pra que serviriam esses campos... pelo menos pra mim... agora dá pra ter uma ideia do que eles estão bolando... Att Ricardo

Se seu XML estiver correto, a chave será impressa no local. http://www.devmedia.com.br/como-funcionam-os-modos-de-contingencia-da-nfe/15914