Painel de líderes

Enviei correção para o repositório. Favor atualizar novamente os fontes e reinstalar.

Na minha opinião, só se o fisco exigir que seja feita alguma alteração, o que deverá constar em NT´s. A priori o que se sabe é que Organizações públicas e privadas só poderão coletar dados pessoais se tiverem consentimento do titular. A solicitação deverá ser feita de maneira clara para que o cidadão saiba exatamente o que vai ser coletado, para quais fins e se haverá compartilhamento. Como os documentos eletrônicos exigem a informação dos dados pessoais do destinatário não há como fugir a regra, a não ser que o Fisco mude as normas. Isso tem que ficar claro ao destinatário, quem são as pessoas que terão acesso aos dados dos documentos eletrônicos. Isso já está previsto na tag AutXML + envolvidos no documento (destinatrio,remetente,transportadora,...) O cuidado que a empresa tem que ter é como ela utiliza os dados coletados dos clientes e fornecedores, se é usado para outros fins como marketing ou envio dos dados a outros para fins não informados ao cidadão.

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

Boa tarde Italo. Farei a atualização dos fontes, novos testes e ao finalizar irei te posicionar.

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

Muito obrigado pela ajuda Daniel Simões . ai pessoall resolvido o problema ... era problema nosso aqui mesmo, por não atualizar o nosso certificado digital no site COMSAT Desenvolvedor. Certificado gerado Base64 e atualizado no COMSAT , problema resolvido, Assinatura Vinculado normal. Certificado tem q ser atualizado aqui também

É possível sim escolher direto o tipo de cartão no SiTEF. Eu fiz da maneira abaixo e homologuei sem problemas: if tipo_cartaoTEF='C' then ACBrTEFD1.TEFCliSiTef.OperacaoCRT := 3 // iniciar operação TEF direto no crédito else if tipo_cartaoTEF='D' then ACBrTEFD1.TEFCliSiTef.OperacaoCRT := 2 // iniciar operação TEF direto no débito else ACBrTEFD1.TEFCliSiTef.OperacaoCRT := 0; // deixa o operador escolher o tipo de cartão via tela do próprio gerenciador TEF

Boa tarde, Eu capturo no evento DepoisConfirmarTransacoes. Basta tratar pelo tipo de transação que está sendo feita. ... if RespostasPendentes[i].Header = 'CNC' then ...

Realizei o teste das alterações a pedido do @EMBarbosa e funcionou perfeitamente setando a propriedade NumCopias = 0. Portanto isso resolve também o tópico original mencionado na primeira mensagem. Obrigado a todos.

Ficaria mais fácil se tivéssemos como reproduzir... Assumindo que eu entendi como você fez o debug... O retorno 503 é um erro. Na verdade erro de sequência de comandos (veja a RFC). O protocolo SMTP precisa ser seguido na ordem de comunicação estabelecida. Isso também é o que quer dizer o "Status Code" 5.5.1 (nessa outra RFC) Pelo meu entendimento, o servidor deles está aguardando um comando MAIL antes (https://tools.ietf.org/html/rfc5321#section-4.3). Isso pode explicar o motivo de TSMTPSend.MailData estar retornando false e gerando o exception. Se na comunicação está detectando essa situação, então está correto em informar que houve erro. Talvez algum comando anterior não está sendo feito de maneira correta como o login. Talvez exista mais de um e-mail, ou talvez mais de um endereço na lista CC/BCC e um deles está dando erro. Não sei se você já tentou, mas pra estabelecer que não é o ambiente: tente com outra conta; Tente com a mesma conta, mas em outra máquina e rede; simplifique o e-mail; Você consegue reproduzir o problema no DEMO? Ou ele só acontece em sua aplicação?

Bom dia Eliezer, Muito obrigado pela colaboração, já enviei para o repositório. Detalhe, os seus fontes estão desatualizados.

Obrigado, vou seguir sua dica Dercide. Problema resolvido.

Bom dia, Atendemos vários clientes de vários provedores diferentes, e eu nunca vi essa tag em nenhum dos provedores. Acredito que se houver a necessidade dessa informação na Danfe, o ideal seria inclui-la junto a descrição, assim como fazemos com as parcelas e outras informações. Dercide

Consegui resolver. O Problema é que quando eu informava a chave, no campo CNPJ vinha '00000419209107' que é o CPF acrescido de 000 no inicio, por isso estava dando erro. Coloquei somente o CPF sem os 000 e deu certo.

Boa tarde. Este documento me parece indicar um arquivo de remessa totalmente a parte, conforme citado pelo Italo, o ACBrBoleto não atende o mesmo. Att.

Problema resolvido.... Abri as units ACBrNFSeDANFSeRLRetrato e ACBrNFSeDANFSeRL alterei conteúdo gravei e compilei, deu certo. Obrigado.

Inicio do post estava pedindo qual os modelos das DATAREGIS IF 375-ep e if 4000 - ep que funciona perfeitamente no acbr usava ele para testes antes de entrar as MFD

Ok, Funcionou, Problema resolvido. Obrigado.

Boa tarde Adilson, A principio pode, desde que outras informações não sejam suprimidas e cujo o conteúdo do código de barras esteja presente no XML da NFS-e. Notei que ele é composto pela concatenação de 3 informações, sendo que a primeira é o numero da NFS-e, a segunda é o código de verificação e depois temos o que parece ser o CNPJ do emitente (segundo a imagem). A principio a maioria dos provedores se utilizam apenas o código de verificação para que o tomador possa checar se realmente a nota foi emitida. Vejo que esse código de barras é algo especifico de Catanduva/SP.

Boa tarde Gumercino, Essa sua alteração pode gerar efeito colateral em outros provedores. Favor atualizar os fontes e faça novos testes.

Boa tarde, Esse pessoal da Tinus é uma piada. Se você comparar esse XML (de exemplo) com o WSDL (já que eles não disponibilizam os arquivos XSD - Schemas) vai notar logo de inicio duas contradições: No XML exemplo temos a tag <EnviarLoteRpsEnvio> com o namespace, mas essa tag não existe no WSDL, o que existe no lugar dela é a tag <Arg>. No XML o atributo da tag <LoteRps> é "Id", mas no WSDL esse atributo é "id", ou seja tudo minúsculo. No XML a tag <CodigoTributacaoMunicipio> esta antes da tag <CodigoCnae>, mas no WSDL esta o contrario. Resumindo, se seguir esse XML de exemplo com certeza o RPS será rejeitado, por conta dessas diferenças. A evolução que tive foi de que agora não ocorre mais o erro 400 e sim 500. Em anexo o XML que o componente esta gerando para o envio do lote completo com a tag <Envelope> Favor enviar esse XML a eles, quem sabe alguém mais capacitado dessa empresa possa indicar o que esta errado ou o que esteja faltado ou o que esteja a mais. 1-env-lot-soap.xml

Boa tarde Veja no tópico abaixo a homologação realizada como esse equipamento utilizando ACBr, pode também encontrar os dados para configuração e drivers.

Boa tarde João, Já passei para o pessoal analisar a sua alteração no que diz respeito a unit. Deste já muito obrigado pela colaboração. Uma pergunta: porque você ainda usa o XsXmlSeg em vez de XsLibXml2?

Evento AntesFinalizarRequisicao do componente ACBrTEFD. Esse é para Pay&Go (NTK) procedure TDMACBr.TEFAntesFinalizarRequisicao(Req: TACBrTEFDReq); begin if (Req.Header = 'CRT') and (TransTEF[tef_nTransacao].tpTransacao <> '') and (Sistema.TEF_TEFDial) then begin Req.GravaInformacao(011,000, TransTEF[tef_nTransacao].tpTransacao); { TIPO DE TRANSACAO NTK: 10: Cartão de crédito – à vista 11: Cartão de crédito – parcelado pelo Estabelecimento 12: Cartão de crédito – parcelado pelo Emissor 20: Cartão de débito – à vista 22: Cartão de débito – parcelado pelo Estabelecimento 21: Cartão de débito – pré-datado 24: Cartão de débito – pré-datado forçada 40: CDC / débito parcelado pelo Emissor 60: Voucher / PAT 30: Outro tipo de cartão 99: Não definido (a operação não foi concluída) } Req.GravaInformacao(010,000, TransTEF[tef_nTransacao].rede); { REDE ADQUIRENTE NTK: 000 VISANET Cielo 001 REDECARD Rede 004 BANRISUL Banrisul / Vero 006 CSHOP Credi-shop 008 TRIBANCO Tricard 009 POLICARD Policard 011 FANCARD Fancard 012 BANCRED Bancredcard 013 BCARD Banesecard 014 ACCORD Accord 015 COOPERCR Coopercred 016 ORGCARD Orgcard 017 GETNET Getnet / Santander 018 REPOM Rede Estrada 019 VLCARD Valecard 020 MUXX Pay&Go Net 021 TKTCAR Ticket 022 PREMMIA FTC 023 NEUS Neus 025 ALGORIX Algorix 026 SENFF Senff 027 VERYCARD Verycard 043 FILLIP Fillip 044 VISANET Cielo - Pay&Go Web 045 ELAVON Elavon 046 LIBCARD Libercard 047 RV RV 048 FSTDATA FirstaData / Bin 049 FDCORBAN Correspondente bancário FirstData 050 CONDUCT Conductor 052 REDECARD Rede – Pay&Go Web 053 CREDSYST CredSystem 054 ICARDS Infocards 056 NDDCARGO NDDCargo 057 BANRISUL Banrisul – Pay&Go Web 058 GLOBAL Global Payments 059 GAX Gax/3ia 060 STONE Stone 061 DMCARD DM Card 062 CTF CTF } Req.GravaInformacao(018,000,IntToStr(TransTEF[tef_nTransacao].parcelas)); { QUANTIDADE DE PARCELAS } Req.GravaInformacao(731,000,TransTEF[tef_nTransacao].tpCartao); { TIPO DE CARTÃO NTK: 0: qualquer / não definido (padrão) 1: crédito 2: débito 3: voucher } Req.GravaInformacao(732,000,TransTEF[tef_nTransacao].tpParcelamento); { TIPO DE FINANCIAMENTO NTK: 0: qualquer / não definido (padrão); 1: à vista; 2: parcelado pelo Emissor; 3: parcelado pelo Estabelecimento; 4: pré-datado 5: pré-datado forçado } end; end;

Mas que bênção! Agora só resta aquele câncer que é Santa Catarina!

Obrigado! Vou atualizar

Bom dia, Tente este outro: https://dfe-portal.svrs.rs.gov.br/Mdfe

o site do MDF-e portal ja faz algum tempo q esta fora , não sei o pq. https://dfe-portal.sefazvirtual.rs.gov.br/MDFe só estao consultando através das rotinas de sistema mesmo. O Acbr tem essa rotina de consulta, verifique nos exemplos do componente.

Putz !!! Salvou meu dia, tinha esquecido completamente do método ValidarRegrasdeNegocios. Obrigado @EMBarbosa.

Bom dia, A única diferença que notei entre o XML de pedido de cancelamento gerado pelo componente e o de exemplo é que a tag <CodigoMunicipio> esta diferente. Gerada pelo componente o conteúdo é: 2611606 já o do exemplo o conteúdo é: 261160. Ou seja, o XML gerado pelo componente esta sendo informado o código IBGE completo do código do município, já no XML de exemplo esta faltando o ultimo digito que se não me falha a memória é um digito verificador. Como os webservices dos provedores costumam retornar mensagens de rejeição que não condiz com o problema, experimente informar o código do município se o ultimo digito.

Bom dia Guto, Muito obrigado pela colaboração, já enviei para o repositório. Um detalhe importante, os seus fontes estão desatualizados.

Os dados de lote e validade foram migrados para o grupo "Rastro" no XML a partir da versão 4.00 da NFe. Então configure na propriedade DetRastro em vez de DetMedicamentos.

Bom dia , a validação da chave no COMSAT deu chave inválida. Vou verificar sobre Base64 e já retorno aqui. Obr por eqto

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

Vou montar um novo servidor com o Leap 15.1 e criar o mesmo ambiente com os mesmos problemas e fazer o que voce esta me orientando, e ver se irá dar tudo certo.... e retorno aqui no forum como fiz outras vezes com o resultado..... por enquanto mais uma vez obrigado.

É a configuração dos dados da porta serial. Geralmente esta balança a configuração é : BAUD=9600 DATA=7 PARITY=E STOP=2 Arquivo de Log: -------------------------------------------------------------------------------- ATIVAR - 11/07/19 15:29:45:566 - Modelo: Toledo 9091 - Porta: COM1 Device: BAUD=9600 DATA=7 PARITY=E STOP=2 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- - 15:29:45:775 RX <- [STX]+p`000068000000[CR] UltimoPesoLido: 6,8 - Resposta: [STX]+p`000068000000[CR]

Não existe nenhum evento específico para validação de schemas porque ele é desnecessário. Imagine que houvesse, a mensagem de erro seria a mesma. EDIT: Você pode tratar com Try..Except o método validar da NFe que vai pegar os erros dos schemas. Ou utilizar o método ValidarRegrasdeNegocios que retorna se validou e uma string com a mensagem de erro. Estamos trabalhando internamente num novo sistema de regras de negócios. Mas no momento nem cabe especular muito sobre ele porque nosso foco principal é a ACBrLib.

Bom dia Italo Entrei em contato com a Tinus, os mesmo me solicitou que fosse enviado um e-mail. Enviei o e-mail, estou aguardando a reporta. Werley Silva Analista Sistemas

Bom dia Marcos, as tags de retornos são geradas de forma automatizada, realmente pode haver diferenciação de maiúsculas e minúsculas, nos campos e chaves, mas o nome em si é idêntico... o que não deve causar problemas. O ideal ao realizar a leitura é converter tudo para minusculo por exemplo, se a sua linguagem for case sensitive.

Obrigado, Italo. Vou entrar em contato com eles. Fico mais tranquilo em ver que não é uma besteira q eu tenha feito aqui. rs Vou falar com eles e posto a resposta aqui. Vlw

Boa tarde Heto Andrade, Isso esta previsto no manual da Febrabam - Custodia de Cheques as informações ficam no Segmento D. O componente ACBrBoleto, se utiliza somente dos Segmentos específicos para o registro de Boletos. No repositório Branches temos um componente chamado ACBrCNAB que tem por objetivo gerar os Segmentos para o pagamento. Não me recordo se ele contempla o Segmento D. Outra coisa importante esse componente não esta 100% funcional, caso deseje colaborar com correções e melhorias ficaremos gratos.

Boa tarde. Eu ainda não havia visto nada sobre este tipo de remessa, você tem algum documento com o layout? Att.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Eita acabei de entrar em contato com a SEFAZ de TO, depois de mil anos tentando falar kkk (acho que acabei me equivocando um pouco) Venho informar que o CDF não está sendo mais utilizado, tendo em vista a obrigatoriedade da utilização da Nota Fiscal de Consumidor Eletrônica pelas empresas usuárias de ECF, conforme previsto na Portaria Sefaz nº 510/2018.

Boa tarde, vc já verificou a propriedade "DetRastros" ? 06/06/2019 -- ACBrNFeDANFEClass -- [+] Inclusão da propriedade "DetRastros" para configurar impressão individualizada das tags do detalhamento específico "rastro" no DANFE. Att Ricardo

Olá a todos, Para quem não sabe nas configurações do componente ACBrNFe, temos dentro do grupo Arquivos um subgrupo chamado DownloadNFe, que contem as propriedades PathDownload e SepararPorNome. Através dessas duas propriedades definimos o caminho onde os XML retornados pelo método DistribuicaoDFe vão ser salvos e se desejamos separar por nome ou não. A primeira alteração realizada foi a migração da definição dessas propriedades de configuração da unit ACBrNFeConfiguracoes para ACBrDFeConfiguracoes. A motivação para essa mudança é que a definição dessas propriedades também se encontravam nas units ACBrCTeConfiguracoes, ACBrMDFeConfiguracores e ACBrBPeConfiguracoes, agora temos em apenas um lugar, ou seja, na unit ACBrDFeConfiguracoes. Com essa mudança temos uma redução de código e caso futuramente tenhamos alguma correção ou melhoria, elas serão feitas em apenas um lugar, desta forma agilizando o tempo de manutenção do código. Como nem tudo são flores, quem tem em seu código as linhas para configurar o Download deverá fazer a seguinte alteração para que a aplicação seja compilada com sucesso (exemplo no caso da NF-e): Antes: ACBrNFe.Configuracoes.Arquivos.DownloadNFe.PathDownload Alteração: ACBrNFe.Configuracoes.Arquivos.DownloadDFe.PathDownload Falando em melhoria, antes tínhamos uma função chamada GetPathDownload que tem como finalidade gerar o Path final onde será gravado os XML referentes aos Resumos de Notas e Notas Completas. Agora além da função citada acima temos também a função GetPathDownloadEvento que tem como finalidade gerar o Path final onde será gravado os XML referentes aos Resumos de Eventos e Eventos Completos. O que motivou a criar essa nova função é que antes o DistribuicaoDFe ao salvar os XML referentes aos eventos estava usando o mesmo Path dos eventos enviados, ou seja, estava misturando os eventos enviados com os eventos baixados pelo DistribuicaoDFe. Resumindo, a primeira alteração visou a redução de código nos componentes ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe e a segunda visou organização dos XML baixados pelo método DistribuicaoDFe. Qualquer duvida ou problemas, favor postar no fórum.

Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.

Acabei de realizar os testes e a NFC-e foi autorizada, portanto todas as respostas dos colegas acima estão corretas: -Ambiente = homologação -Emitente da NFC-e = Maranhão -Destinatario da NFC-e = MG (coloquei os dados reais do endereço) -Ide.idDest = doInterna -CFOP = 5405 para as mercadorias com ST/5102 para mercadorias normais -Venda = presencial

Galera bom dia!! depois de me bater com o problema do ACBRInstall, consegui corrigir da seguinte forma: Retirei essa parte do código do ACBrInstall_Trunk2 compilei o projeto e fiz a instalação... deu tudo certinho!! 100% funcional. SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, wParam, lParam, SMTO_NORMAL, 4000, aResult); if aResult <> 0 then raise Exception.create('Ocorreu um erro ao tentar configurar o path: ' + SysErrorMessage(aResult)) Se voltar esse código não instala nem à pau!! hehehe... mas é isso ai, fica a dica pra quem estiver enfrentando o mesmo problema. Obrigado pela atenção de todos.