Painel de líderes

Boa tarde... Na verdade é muito simples.. é só informar o CFOP 5949 e o CST de icms igual a 90 (Se não for simples nacional), ou CSOSN=900 (caso for simples nacional) com alíquota e base de cálculo zeradas... Isso fará com que esses documentos não debitem imposto na apuração do icms

Prezados, tivemos algumas ocorrências de clientes ligando devido algumas partes cortadas da observação na DANFSe do arquivo "DANFSeNovo.fr3". Conforme pode ser observado abaixo O Problema Nós identificamos que esse problema já foi tratado em algum momento dentro do próprio arquivo "DANFSeNovo.fr3", porém o tratamento pode funcionar diferente a depender do versão do FastReport (assim nós imaginamos). No AfterPrint da do componente imgQrCode, foi adicionado um código que fixa o width do campo Memo34 para 16. O problema de fazer dessa forma, é que isso não garante que a observação já não tenha sido "processada" antes pelo relatório, fazendo que o código do AfterPrint do imgQrCode não altere a observação, além de dificultar o teste porque hora o Fast pode processar o imgQrCode depois do Memo34, gerando aquele problema que uma hora da certo, e outra hora da errado. Como resolvemos O evento foi removido do AfterPrint de imgQrCode, e adicionado no BeforePrint da banda PageFooter1, e o código ajustado para funcionar no novo local. // Código anterior dentro do relatório if imgQrCode.Visible then memo34.Width := 16; Depois: // Código depois da alteração if imgQrCode.Visible then memo34.Width := memo34.Width - imgQrCode.Width; Resultado: DANFSeNovo.fr3

Já fiz tudo isso, mas acredito que o problema seja a rede do cliente. Fazendo testes eu consigo enviar normalmente, estou aguardando eles me passarem o certificado para ter certeza.

também tive que revisar alguns relatórios e telas para tirar estas notas, para não dobrar informação de recebimento, faturamento, etc.

O que dificultou muito mesmo foi para essas empresas que tem prestação de serviço e mercadorias, como por exemplo, oficinas mecânicas.. Para atender o decreto, o cliente vai ter que passar duas vezes o cartão para fazer o pagamento, pois para pagar as peças vai ter que fazer uma NFce (de forma integrada) e para pagar a mão de obra vai fazer uma NFSe (de forma não integrada)

Sim. Realmente essas situações são bem chatas. Eu fui em evento com o delegado regional da receita estadual sobre o sistema de integração de pagamento da NFC-e e tive a mesma impressão que a sua. Eles estão numa realidade muito distante do dia-a-dia.

Boa tarde @DIGITEC SISTEMAS, Uma coisa é o XML da NFS-e gerado pelo Site da prefeitura que normalmente não contem assinatura digital. Outra coisa é gerar o XML do RPS assinado e enviar para o webservice do provedor. É possível incluir a sequencia CRLF na discriminação para gerar quebra de linha, mas a rotina que faz a assinatura digital remove essa sequencia, pois pelas normas um XML não pode conter quebra de linhas principalmente quando ele vai ser assinado.

Esse link descreve bem o problema de incompatibilidade do OpenSSL 3.x com os antigos certificados https://www.practicalnetworking.net/practical-tls/openssl-3-and-legacy-providers/

Entendi. Recebi solicitações semelhantes. A liberação do CFOP 5949 abriu esse precedente, permitindo uma abordagem específica para transações como essa. Vamos ao exemplo prático: uma loja de relógios vende uma pilha e também oferece o serviço de troca da pilha. Nesse caso, é necessário emitir uma NFC-e para a venda da pilha, que é um produto, e uma NFSe para o serviço de troca de pilha. Se o cliente optar por pagar com cartão, serão necessárias duas transações: uma para pagar pela pilha e outra para pagar pelo serviço. A solicitação da contabilidade é que na NFC-e conste a pilha e um item com o CFOP 5949, referente ao serviço de troca. Isso permitirá que tudo seja cobrado em uma única transação e NFC-e, simplificando o processo de pagamento do cliente. Posteriormente, a empresa emitiria a NFSe para o serviço prestado. Essa é a situação que tenho recebido.

Agora vou ter que ver se o schema é do provedor ou do ACBR, creio que se for do provedor pode estar ai o problema.

Bom dia Italo, era isso mesmo. Eu não passava nenhum parametro e o default era o assincrono. Informei agora todos os parametros e deu certo ! Muito Obrigado e bom fim de semana !!

Exemplificando: Voce emitiu a NFSe ou uma NFe com a condição de pagamento prazo. Caso o cliente vá ate o estabelecimento quitar essa parcela, e seja pago com meio eletronico, ai sim voce emite a NFCe com 5949 e etc...

Bom dia, python, depois de muito tentar e pesquisar encontrei um modelo de XML que funciona aqui. Uma pena a API não responder o erro que aconteceu e em certas situações só mandar "erro": [] e não emitir/cancelar a NFSE.

Isso se refere a pagamentos diversos.. Exemplo.. Recebimento de carnê, prestações, Contas recargas de celulares, etc...

Bom dia @BYTE INFO, O teu problema é que você esta enviando no modo assíncrono, sendo que agora o modo de envio é síncrono. Ou esta tentando consultar o CT-e pelo numero de recibo. Na versão 4 do CT-e o envio é síncrono e não temos mais o numero do recibo, visto que no retorno do envio do CT-e já temos o resultado do processamento.

Já descobri o problema, e já resolvi. Estava sendo enviado em Boleto.NossoNumero o nosso numero completo. Mudei para enviar apenas o sequencial, ai deu tudo certo. Obrigado.

Foi disponibilizado uma nova versão Revision: 33195 .. por favor atualize e veja se consegue utilizar a versão com net 8..

@Italo Giurizzato JuniorOk, vou implementar e repasso aqui as units e alterações necessárias. Já vou repassar algumas informações que consegui: A autenticação da NFSe se faz a partir de um Token, não sendo necessário Certificado digital, login e senha da prefeitura nem nada do tipo, apenas o token. *Para conseguir esse Token, precisa pedir para o servidor do município alterar o credenciamento alterando a opção "DESEJA EMITIR RPS? para sim aí vai gerar o token e te repassam no caso, para que possa configurar. Pois com esse TOKEN conseguimos emitir as NFSe via Web Service. *O token é enviado no JSON da NFSe no campo "tokenRPS". * o campo do JSON tomador > id = Nesse basta informar o cpf ou cnpj do tomador. > Demais campos do JSON o manual explica, tem alguns como bairroId, logradouroId, paisLocalPrestacaoServico > id, localPrestacaoServico > id, servico > id, e outros que você precisa realizar uma requisição GET no WebService da Aspec que irão te retornar o id que eles possuem cadastrado. Isso da para entender bem através do manual que anexei aqui, Caso eu consiga mais alguma informação útil ou collections ou algo que ajude eu repasso aqui.

Bom dia @Data Lider, Muito obrigado pela contribuição, já incluir na lista de tarefas para analise. TK-5275