bnobre

Leia o tópico até o final.

Daruma e Bematech

Só uma retificação... NÃO é necessário usar o MinGW com OpenSSL. O vídeo que citei em outro tópico é o citado acima pelo Daniel, ele vai elucidar essas e outras muitas dúvidas que surgirão.

Show... Alguma previsão para os outros?

Olá meu amigo... Eu recebo esse erro quando o Windows não está atualizado... E tem que atualizar TUDO... Até não restar mais nenhuma atualização. Como você usa A1 eu recomendo fortemente o uso da OpenSSL, dessa maneira não dependerá de atualizações do Windows. Para maiores detalhes:

Olá a todos... Prorrogado NT 1.51

Agradeço a ambos suas explicações , realmente eu não me recordava sobre os tipos de passagens de parâmetros, a quem interessar: http://blog.tecsystem.com.br/index.php/boas-praticas-de-programacao-em-delphi-2-parametros-de-metodos/ Só AGORA eu observei que nessa procedure do GerarNFe, onde uso as funções citadas no início do tópico, existe uma variável Boolean chamada ok... E realmente ela é usada na passagem de referência. Eu não tinha observado a presença dela no código. procedure GerarNFe(NumNFe : String); var ok:Boolean; MeminfCpl, MeminfAdFisco:String; begin with ACBrNFe1.NotasFiscais.Add.NFe do begin ... Ide.indPres := StrToPresencaComprador(ok, z_nfeide_indpres.AsString); ... end Pois bem... Esclarecido o que significa passagem por referência e localizado a variável ok em minha procedure, surgiu só mais uma dúvida: Porque optaram em usar o out ok nessas funções citadas do pcnConversao? Por tudo que li eu suponho que o objetivo foi de permitir algum tratamento posterior no caso do valor não ter sido achado (ok = False), estou correto?

Oi André... Tudo bom? Perfeito, mas como pode reparar eu não escrevo nem True e nem False, eu escrevo "ok".

Olá BigWings, tudo bom? Obrigado pelo esclarecimento. Com sua explicação eu entendi a lógica do código, mas sinceramente não entendi "o porque" de ter que escrever sempre a mesma palavra ok no primeiro parâmetro para que tudo isso que me explicou aconteça, tecnicamente falando. Todas as funções que crio recebem parâmetros variáveis, por isso me causou estranheza esse parâmetro receber sempre o mesmo valor (a palavra ok). É algo novo pra mim e me chamou a atenção. Porque criar um parâmetro que sempre receberá o mesmo valor??? Postei aqui nessa seção do fórum inicialmente pelo fato de ter tomado conhecimento de tais funções no ACBrNFe_demo, mas vejo que minha dúvida é mais de programação do que relacionada ao componente, portanto se achar devido peço que mova meu tópico. Desde já agradeço sua atenção.

Olá a todos, Há tempos eu uso alguns comandos que funcionam muito bem, por exemplo: Observem que em comum eu informo a palavra ok como valor no primeiro parâmetro de todas as funções e então no segundo parâmetro informo o valor que realmente me interessa. Funciona normalmente, mas eu só uso a palavra ok pois copiei do exemplo no ACBrNFe_demo, coloquei e deu certo... Não sei a lógica disso e gostaria de entender. Porque é necessário colocar esse valor ok como primeiro parâmetro? Desde já agradeço a atenção de todos

Olá a todos, Sou do Rio, portanto utilizo a SVRS para envio de NFe/NFCe... Até o presente momento a NT 1.50 ainda não entrou em vigor e já estamos próximos da desativação do ambiente 3.10 (caso não ocorra outra prorrogação). Alguém teve notícias sobre o que ocorreu com essa NT OU tem o e-mail de contato com a SVRS para que eu possa perguntar? Desde já agradeço a atenção de todos

Bom dia... Aqui normalizou também... Doideira isso.

Olá a todos, Ao longo do dia de hoje diversos clientes diferentes tem relatado esse retorno Rejeição: Assinatura difere do calculado, ao tentarem emitirem suas NFCes... Olhei a disponibilidade dos servidores (sou do RJ) e está tudo verde, exceto pelo de GO. Mas alguém está tendo esse problema???

Só corrigindo, ativa em Homologação dia 02/05/2018.

Galera... Minha sugestão é aguardar AO MENOS essa NT 1.50 entrar em vigor no modo Homologação para debatermos qualquer outra coisa sobre a mesma. Estamos debatendo sobre uma NT que nem cumpriu seu propósito de estar ativa em Homologação dia 02/07/2018, até o momento está tudo como antes.

O jeito é esperar, falou tudo meu amigo.

Olá... Você tem algum XML autorizado assim? Pois conforme o BigWings falou, sempre foi obrigatório na 4.00. Observe que só dá essa rejeição na 4.00 e quando você preenche itens do Grupo Duplicata, os boletos no seu caso.

Não é obrigatório... Inclusive, ao meu ver, seria burocrático para o operador do caixa fazer isso em sistemas não integrados.

https://pt.slideshare.net/regys_silveira/mudanas-da-nfe-40-e-implementao-com-acbr Isso SOMADO ao que estamos comentando sobre a NT 1.50 Bem... A questão é a seguinte, eu uso os comandos abaixo para enviar a NFe: GerarNFe(cupom); ACBrNFe1.NotasFiscais.GerarNFe; ACBrNFe1.NotasFiscais.Assinar; ACBrNFe1.NotasFiscais.Validar; ACBrNFe1.Enviar(cupom, False); A rejeição Rejeição: Grupo duplicata informado e forma de pagamento não é Duplicata Mercantil está acontecendo aqui para mim na última linha, portanto é um retorno do WebService e nada tem haver com os Schemas, não é um erro de validação local. De acordo com a NT 1.50, tal rejeição seria descartada, como ainda existe ficamos obrigados a informar Duplicata Mercantil como forma de pagamento. Outro ponto ponto é que apesar da exclusão da forma de pagamento Duplicata Mercantil, não consta na NT 1.50 nenhuma validação/rejeição sobre a mesma, portanto não sei como ficará quando o usuário tentar enviar tal forma de pagamento. O que sei é que até o presente momento está aceitando normalmente.

Cara, olha seu XML, você está gerando na versão 3.10. E como eu disse está funcionando normal a emissão na 4.00 em Homologação.

Você está certo, a grande mudança foi a inclusão da tag indPag e exclusão da Duplicata Mercantil. De qualquer forma sou do RJ, portanto uso o mesmo WebService que você e não estou tendo problemas nenhum em enviar notas em Homologação/Produção com a opção 15 ou 90. Na verdade estou enviando normalmente até com a 14, conforme disse acima, pois a validação da mesma ainda está ativa, obrigando assim seu preenchimento. Mas conforme o carlos lembrou, as alterações dessa NT só valerão a partir de 02/05/18 - Homologação e 16/05/18 - Produção, página 10.

Você diz essa caixa na imagem abaixo? Se sim, observe a function FormaPagamentoToStr em pcnConversao.

Olá Daniel, Vi no Change-log que no dia 14-04-18 foram realizados Ajustes para funcionamento da Consulta por CNPJ no SEFAZ, conforme você havia citado acima. Você havia informado que os ajustes que fez foram somente para melhorar o controle do timeout, entretanto após essa atualização a consulta voltou a funcionar. Foi mera coincidência ou corrigiu alguma outra coisa?

Cara... Não entendi a afirmação que "no componente acbr 02 é cartão de débito". Aqui pra mim o valor 02 = Cheque, e todos os outros estão batendo normalmente. Onde está escrito isso? Como você especifica as formas de pagamento?

Outro detalhe... Ainda estou conseguindo emitir normalmente como forma de pagamento Duplicata Mercantil e as validações da mesma estão ativas (ex.: Rejeição: Grupo duplicata informado e forma de pagamento não é Duplicata Mercantil.) Melhor aguardar.