Painel de líderes

Olá Pessoal, A resposta para o título do tópico é muito simples: Sim e Não. Hoje temos provedores que seguem a versão 1 ou 2 do layout da ABRASF, provedores que tem o seu próprio layout e o layout do Padrão Nacional. Segundo os manuais da ABRASF (Versão 1 ou 2) bem como do Padrão Nacional não existe a possibilidade de informar 2 ou mais itens, só é possível informar somente um item, portanto não existe uma lista de serviços. Já os provedores que tem layout próprio alguns permitem outros não. Como saber se o provedor permite informar mais de um item de serviço? É muito simples, através do programa exemplo, você o configura para a cidade deseja na aba Emitente, salve a configuração, clique no botão [Informações sobre o Provedor] que esta na aba Geral. Do lado direito temos uma aba chamada Log, vai ser apresentado as informações sobre o provedor que atende a cidade que foi configurada, informações estas como Autenticação, Serviços Disponibilizados e Particularidades. Em Particularidades se aparecer escrito: Permite mais de um serviço, isso significa que o provedor permite que você informe um ou mais itens de serviços. Como faço para informar mais de um item caso o provedor permita? with Servico.ItemServico.New do begin Descricao := 'Desc. do Serv. 1'; ItemListaServico := '09.01'; Quantidade := 10; ValorUnitario := 5; (...) end; with Servico.ItemServico.New do begin Descricao := 'Desc. do Serv. 2'; ItemListaServico := '09.01'; Quantidade := 1; ValorUnitario := 15; (...) end; Vide o programa exemplo do componente ACBrNFSeX para ver os demais campos que podem ser informados além dos 4 mostrados nesse exemplo acima. Mais precisamente procure pela procedure: Alimentar_Componente_layout_Proprio. Então quer dizer que se o provedor que atende a cidade para o qual a NFS-e vai ser emitida não permite não tem como? A resposta é: a principio não tem como, mas o componente ACBrNFSeX vai dar uma mãozinha para você. Como eu faço para enviar uma lista de itens de serviço se o provedor não permite? 1. Você vai informar todos os itens conforme mostrado acima; 2. Configure a propriedade de configuração FormatoDiscriminacao com um dos valores: fdJson ou fdTabulado (vide figura abaixo) Essa propriedade tem os seguintes valores: fdNenhum = Valor padrão da propriedade e faz com que o componente não execute nenhuma ação referente a lista de itens. fdConsolidado = o componente vai totalizar os valores e quantidades e concatenar as descrições dos itens e popular os campos padrões usados pelo provedor para as informações tais como Discriminacao, valor, etc. fdJson = o componente vai montar um Json com as informações (Descrição, Valor Unitário, Quantidade e Valor do Serviço) dos itens e popular o campos padrões usados pelo provedor. fdTabulado = o componente vai montar uma Tabela com as informações (Descrição, Código do Item, Quantidade, Valor Unitário, Valor do Serviço, Base de Calculo e Alíquota) dos itens e popular o campos padrões usados pelo provedor. Desta forma ao imprimir o DANFSE no quadro: Discriminação do Serviço em vez de aparecer um texto, vai aparecer a lista dos itens. Espero que tenham gostado dessa dica.

duas situações, primeiro seu código está desatualizado. segundo tu não pensou em sua implementação no delphi 7 e lazarus pois não tem funções que usou ali nos mesmos

o problema geral é que tu tá usando Openssl e passando o numero de serie do certificado te que passar o arquivo pfx físico no disco

A TK foi alocada para a Sprint desta semana, deve estar disponível na próxima compilação da lib. Assim que for concluída, reportaremos aqui no tópico.

-10 quer dizer que houve erro ao executar o método.. Por estar utilizando ACBrLib versão Demonstração, pode ser questão do timeout de uso, você consegue usar por 30min, após isso, precisa reiniciar a aplicação. Outro detalhe também é que o ambiente é somente homologação, então os envios dos DFes (NFe/NFCe), somente para ambiente de homologação.. Caso persistir, anexe um log atualizado, por favor. Configure o Log para nivel 4 -> Paranoico https://acbr.sourceforge.io/ACBrLib/Geral.html

Boa Tarde a todos. Renato e Diego mudei para VersaoCTe.ve400 e deu certo, muito obrigado pela ajuda.

faça um teste por favor... no uses adicione ACBrUtil.Strings na linha 111 e 290 antes dela adicione esse RetWS := UTF8..... RetWS := UTF8ToNativeString(RetWS); if RetWS <> '' then veja se resolve a situação

Olá Tudo Bem! Obrigado Daniel e Italo por me responderem! Então Daniel fiz a alteração e informei além do código = 50 no Valor='09/04/2024' (segue em anexo o xml no modo produção) mas deu exatamente a mesma rejeição! O complicado é que no ambiente de teste não existe esse código 50 e nenhum que pedi data(segue a imagem em anexo) e o mais estranho não tem a receita 100102 que segundo contador do cliente tem que usar o código da receita 100102. No ambiente de teste usei o código 68 com chave da nf-e e autoriza e gera a gnre. Como pode fazerem ambiente de teste e produção com configurações tão diferentes, o pior que mando as dúvidas para esse caso a sefaz do CE e falam que tem que direcionar para sefaz de PE pois usam o serviço da sefaz de PE mas o problema que a sefaz de PE nunca me respondeu uma dúvida. Estou enviando as dúvidas para ambas as UFs mas sem esperança de obter uma resposta. Italo vou fazer isso agora pois só informando a data deu a mesma rejeição. O problema que o código da receita 100102 exige o código 50, ae vou tentar o 104 mas só que com a chave de uma nf-e e ver o que acontece. Nos schemas deveria ter um campo especifico para essa data já que eles exigem, mas se o ambiente de teste é diferente do de produção isso já complica demais as coisas. Muito Obrigado pelas Ajuda de vocês! 4341-gnre.xml

Ótima notícia comunidade ACBr ! Para quem não está sabendo o banco Sicoob disponibilizou uma nova API denominada V3, segundo eles a versão anterior produção vai ser descontinuada, mas sem data prevista. O ambiente de teste da versão anterior V2 foi descontinuado segundo suporte: "Maria Eduarda: Prezado, bom dia. O ambiente de Sandbox da API Cobrança Bancária V2 foi descontinuado. Orientamos que os cooperados utilizem o novo Sandbox adequado a versão 3. A API Cobrança Bancária V2 ainda estará disponível em produção." Fizemos a implementação desta nova API V3 e está já disponível em nossos repositórios para que vocês possam realizar os testes. Todos os nossos testes foram realizados em ambiente SandBox. Como configurar:

Bom dia @Juliomar Marchetti, tudo bem? Sim eu li, assim que possível eu repasso aqui as units atualizadas, pois realmente meu ACBrBoletoWS.pas estava bem desatualizado. Quanto ao seu outro questionamento: "parece que tu usou códigos seus e não pensou na questão de usuários delphi 7 ou lazarus" O que implica no código para usuários Delphi 7 e Lazarus? Pode me explicar para eu ajustar? Obrigado. Sobre o outro questionamento "não entendi o txt segundo?" Se está se referindo ao "GeraçãoTokenInternamente.txt" é como fiz a geração do token em meu sistema, gero o token e armazeno na property do ACBr FToken e no momento das execuções dos processos eu sempre tenho o token guardado pois uso os ACBrBoleto.OnAntesAutenticar/ACBrBoleto.OnDepoisAutenticar realmente pode ser confuso, não sei como seria para o ACBr gerar esse token pois não poderá ser feito diretamente como hoje é nos outros modelos e nesse meu eu usei Rest do Delphi, caso queira algo mais similar a como hoje é trabalhado no ACBr tem que usar como exemplo o código do @Lucio Bittes e @HelioNeto disponível aqui neste fórum, ou segue aqui: https://files.fm/u/r4t5whcqvx Tem que ver como será feito, pois como é hoje utilizado para os demais bancos com o GerarTokenAutenticacao não irá servir, pois a geração de Token desse banco é algo específico e com etapas e processos que não é feito no ACBr.

O que é a Manifestação do Destinatário? Este conjunto de eventos, como o próprio nome já sugere, permite que o destinatário da NF-e possa se manifestar sobre a sua participação comercial descrita na NF-e, confirmando as informações prestadas pelo seu fornecedor e emissor do respectivo documento fiscal. Este processo é composto de quatro eventos: 1. Ciência da Emissão 2. Confirmação da Operação 3. Registro de Operação não Realizada 4. Desconhecimento da Operação Como funciona o evento Desconhecimento da Operação? Este evento tem como finalidade possibilitar ao destinatário se manifestar quando da utilização indevida de sua Inscrição Estadual, por parte do emitente da NF-e, para acobertar operações fraudulentas de remessas de mercadorias para destinatário diverso. Este evento protege o destinatário de passivos tributários envolvendo o uso indevido de sua Inscrição Estadual/CNPJ. Como funciona o evento Operação não Realizada? Este evento será informado pelo destinatário quando, por algum motivo, a operação legalmente acordada entre as partes não se realizou (devolução sem entrada física da mercadoria no estabelecimento do destinatário, sinistro da carga durante seu transporte, etc.). Como funciona o evento Confirmação da Operação? O evento será registrado após a realização da operação, e significa que a operação ocorreu conforme informado na NF-e. Quando a NF-e trata de uma circulação de mercadorias, o momento de registro do evento deve ser posterior à entrada física da mercadoria no estabelecimento do destinatário. Este evento também deve ser registrado para NF-e onde não existem movimentações de mercadorias, mas foram objeto de ciência por parte do destinatário, por isso é denominado de Confirmação da Operação e não Confirmação de Recebimento. Importante registrar, que após a Confirmação da Operação pelo destinatário, a empresa emitente fica impedida de cancelar a NF-e. Apenas o evento Ciência da Emissão não inibe a autorização para o pedido de cancelamento da NF-e, conforme o prazo definido na legislação vigente. Como funciona o evento Ciência da Emissão? O evento de "Ciência da Emissão" registra na NF-e a solicitação do destinatário para a obtenção do arquivo XML. Após o registro deste evento, é permitido que o destinatário efetue o download do arquivo XML. O Evento da "Ciência da Emissão" não representa a manifestação do destinatário sobre a operação, mas unicamente dá condições para que o destinatário obtenha o arquivo XML; este evento registra na NF-e que o destinatário da operação, constante nesta NF-e, tem conhecimento que o documento foi emitido, mas ainda não expressou uma manifestação conclusiva para a operação. Todas as operações com o evento de solicitação de "Ciência da Emissão" deverão ter na sequência o registro do evento com a manifestação conclusiva do destinatário sobre a operação (eventos descritos nos itens 5.2, ou 5.3, ou 5.4). É possível reconsiderar o registro de um destes eventos? O destinatário poderá enviar uma única mensagem de Confirmação da Operação, Desconhecimento da Operação ou Operação não Realizada, valendo apenas a última mensagem registrada. Exemplo: o destinatário pode desconhecer uma operação que havia confirmado inicialmente ou confirmar uma operação que havia desconhecido inicialmente. O evento de "Ciência da Emissão" não configura a manifestação final do destinatário, portanto não cabe o registro deste evento após a manifestação final do destinatário. O que fazer quando a operação se realizou de forma diferente do descrito na NF-e, porém a mercadoria já foi recebida pelo destinatário? Caso a operação tenha se realizado, mas o conteúdo da NF-e não descreva corretamente da operação, o destinatário deverá se manifestar utilizando o evento "Confirmação da Operação", e adotar os procedimentos fiscais cabíveis de acordo com a legislação da unidade federada onde estiver estabelecido. Os eventos "Registro de Operação não Realizada" e "Desconhecimento da Operação" não devem ser utilizados nesta hipótese. Onde podemos consultar os eventos de Manifestação do Destinatário? A consulta pública na Internet foi alterada para exibir os eventos registrados na NF-e e pode ser realizada diretamente no Portal da NF-e (www.nfe.fazenda.gov.br) ou portais das Secretarias de Fazenda da circunscrição do emitente, a partir da informação da chave de acesso da NF-e. Os arquivos XML dos eventos também serão disponibilizados para os emitentes/destinatários constantes no documento fiscal. Uma vez que o destinatário tomou Ciência da Emissão é obrigatória a sua manifestação? Sim. Toda nota informada ao contribuinte tem que ter registrada a sua respectiva manifestação até um prazo máximo de 180 dias, contados da data da ciência. Este prazo máximo será reduzido gradativamente, conforme o interesse das Administrações Tributárias. O destinatário deve apresentar uma manifestação conclusiva dentro de um prazo máximo definido, contados a partir da data de autorização da NF-e, conforme tabela abaixo: A distribuição ocorrerá para os atores que desempenham papéis de emitente, destinatário, transportador e terceiros (informado na tag autXML), e englobará os documentos que estiverem com “SIM” na linha correspondente, conforme tabela abaixo: A geração de NSU, a partir da versão 1.10 da Nota Técnica 2014.002, irá considerar somente os usuários do serviço nos últimos 60 dias. É importante ressaltar que: a) para os usuários do serviço dos últimos 60 dias, a geração de NSU continuará normalmente; b) no caso de novos usuários desse serviço (distNSU), a geração de NSU ocorrerá a partir do primeiro acesso. Não haverá geração de NSU retroativo; c) qualquer usuário que deixar de utilizar o serviço (distNSU) por mais de 60 dias, terá a geração de NSU interrompida e retomada a partir da próxima consulta com este método. Não haverá geração de NSU retroativo ao período de interrupção. OBS: A partir da versão 1.13 da Nota Técnica 2014.002, os eventos gerados pelo Fisco, que forem passíveis de distribuição conforme a tabela acima, serão distribuídos ao emitente independente de manifestação do destinatário, ainda que emitente e destinatário sejam iguais.

Obrigado @Fernando Pasqueto e @MuriloS.A, enviei ao SVN, com as revisões que informei algumas otimizações no código, indentação ajustes para compilação no D7 ... Commit [r33705]

@Fernando Pasqueto e @MuriloS.A Muito obrigado por sua ótima contribuição... Apliquei uma ampla revisão nos fontes... Efetuei algumas otimizações no código, indentação e ajustes para compilação no D7 Poderiam por favor testar com a versão em anexo ? A quem devo creditar a autoria dos fontes ? TEFAPIElgin.zip

@Daniel Simoes @Juliomar Marchetti Boa tarde. Executei algumas correções nos arquivos ACBrTEFAPIElgin.pas e ACBrTEFAPIElginComum.pas, executei transacoes de multiplos cartões e operações admisnitrstrativas com exito. * Corrigido erro na exbição das operações administrativas. * Corrigido erro no retorno de pagamento, quando efetuado um pagamento de 10,00 o retorno era lido como 1,00, sendo assim a operacao era finalizada na elgin e permanecia em aberto no componente que recebia uma valor errado de pagamento efetuado. * Corrigido erro na rotina de tratamento de retorno do comprovante. ACBrTEFAPI.rar

Não sei se está relacionado com a rejeição que está recebendo, mas você alimentou o campo receita com o valor 100102. No portal do GNRe, na lista de campos Extras, ele indica a receita 100099.

Bom dia Pessoal, tudo bem? Um membro do fórum me mandou uma mensgem privada esses dias perguntando se eu desenvolvi a fila, já que eu comecei a discussão rsrsr, vou copiar para vocês o que respondi pra ele: Eu implementei o compartilhamento sim, tem funcionado muito bem nos clientes. Fizemos um controle bem simples: 1) O SAT fica instalado num servidor. 2) Na estação, onde está o ERP instalado, quando o usuário na tela de vendas clica em "Emitir SAT", o sistema grava numa tabela do banco de dados chamada "FILA DO SAT" uma requisição de autorização (que contém um id único), e fica esperando a resposta (controlo isso num campo na tabela FILA, 0 = aguardando 1 = processado). 3) No servidor, onde está instalado o SAT, eu criei um programa que monitora essa tabela "FILA DO SAT", buscando registros do tipo "0 = aguardando". O programa pega esse registro (que contém o número da venda), gera o xml, envia ao aparelho, se aprovado, grava o xml de retorno. O próximo passo é gravar na tabela FILA, o resultado da operação "0 = reprovado e a mensagem de retorno/1 = aprovado" e seta "1 = processado". 4) A aplicação (que ficou num repeat until por até 20 segundos esperando o registro ser alterado para "1 = processado", ao receber a resposta, se aprovado, imprime o recibo, se reprovado envia a mensagem de retorno. Se em 20 segundos não recebeu retorno algum, retorna ao usuário a mensagem "SAT remoto não respondeu." Basicamente é isso. O controle desenvolvido é bem simples, mas tem funcionado bem em nossos clientes, já temos mais de 300 CNPJS vinculados à nossa empresa.