Painel de líderes

Referente ao tópico em questão, para quem tiver interesse saiu a publicação referente ao assunto. http://legislacao.sef.sc.gov.br/html/Atos_Diat/2016/AtoDiat_16_018.htm

Resposta de BH Prezado contribuinte, Informamos que o problema no processamento de NFS-e em lote foi detectado e já estão sendo tomadas as providências para a sua correção. O sistema de emissão de NFS-e on line não foi afetado e está funcionando normalmente. Atenciosamente, Gerência de Controle e Acompanhamento das Declarações Eletrônicas de Serviços - GEDEL

[email protected] Prezado contribuinte, Informamos que o problema no processamento de NFS-e em lote foi detectado e já estão sendo tomadas as providências para a sua correção. O sistema de emissão de NFS-e on line não foi afetado e está funcionando normalmente. Atenciosamente, Gerência de Controle e Acompanhamento das Declarações Eletrônicas de Serviços - GEDEL Gerência de Tributos Mobiliários - GETM Secretaria Municipal Adjunta de Arrecadações - SMAAR Secretaria Municipal de Finanças - SMF Rua Espírito Santo, 605 - 2º andar, sala 201, Centro, Belo Horizonte.

Bom dia a todos Para quem estiver passando por esse problema (tela ficando branca,lentidao),segui as orientacoes desse link e resolveu: http://thundaxsoftware.blogspot.com.br/2011/04/signing-your-delphi-applications-with.html assinar o aplicativo,esses plugins de banco da GAS Tecnologia, mata a maquina em alguns momentos coisa boa e chegar aqui no forum mais show do Brasil e encontrar solucoes,

Eu retirei os segmentos Q, R e S do arquivo e coloquei uma condição para que quando o houver uma alteração de dados ele envie somente o segmento P. Parece que o banco aceitou o arquivo agora vou aguardar o retorno para verificar se o titulo foi realmente alterado. Amanhã digo se tudo deu certo.

Por que não dá uma ajudinha para o seu cliente, fazendo o seu aplicativo avisar que existe MDF-e pendente de encerramento quando você executar o aplicativo na primeira vez do dia? Você pode se basear até por uma data de previsão de encerramento, chegou na data, cliente não encerrou, aplicativo avisa. Só sugestão.

Bom dia! Mesmo problema por aqui. Deve ser alguma falha na prefeitura.

Estamos com o mesmo problema Obteve algum retorno.?

Geovane, Primeiramente faça uma correção, você esta informando somente a data de emissão sendo que o correto é data e hora, veja como esta ficando o XML: <DataEmissao>2016-09-01T00:00:00</DataEmissao> Você deve estar usando a função Date passe a usar Now para alimentar o campo DataEmissao. Quanto ao erro que você postou, se é uma mensagem retornada pelo provedor isso significa que o problema é com eles. O Danilo, comprova o que estou dizendo, pois diz que no ambiente de homologação esta funcionando, somente no de produção. Sendo assim, concluo que o problema é no provedor, a solução é simples, entrar em contato com eles, expor o problema e aguardar a solução.

Bom dia a todos, Vocês estão se referindo a Belo Horizonto, correto? Se sim o provedor é BHISS e o schema que é usado para validar o lote a ser enviado encontra-se em: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\BHISS Abram o arquivo nfse.xsd usando o bloco de notas e vão encontrar o seguinte: (...) <xsd:complexType name="tcInfNfse"> <xsd:sequence> <xsd:element name="Numero" type="tsNumeroNfse" minOccurs="1" maxOccurs="1"/> <xsd:element name="CodigoVerificacao" type="tsCodigoVerificacao" minOccurs="1" maxOccurs="1"/> <xsd:element name="DataEmissao" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/> <xsd:element name="IdentificacaoRps" minOccurs="0" type="tcIdentificacaoRps" maxOccurs="1"/> <xsd:element name="DataEmissaoRps" type="xsd:date" minOccurs="0" maxOccurs="1"/> <xsd:element name="NaturezaOperacao" type="tsNaturezaOperacao" minOccurs="1" maxOccurs="1"/> (...) Notem que a definição do elemento IdentificacaoRps é do tipo complexo (tcIdentificacaoRps) e em sua definição temos os elementos: Numero, Serie e Tipo. Notem também que a estrutura apresentada acima se refere as informações da NFS-e (tcinfNfse). Se antes o grupo IdentificacaoRps e o campo DataEmissaoRps não constavam no XML da NFS-e e agora consta o motivo é simples, vejam que são opcionais, antes o provedor gerava o XML da NFS-e sem essas informações e agora resolveu gerar.

Infelizmente, meu caso continua com o mesmo erro.. Ao cadastrar pela 1a vez a Software House, tenho o erro ainda. Porém, como foi postado em outro fórum (acredito que pelo mesmo Geórgenes Geo), existe um macete para quem já possui o cadastro e recebe o erro na hora de atualizar o certificado no SGR.. Coloco aqui para referência, pois a pesquisa do google retorna este tópico como mais relevante, então, acho importante colocar aqui. Segue: " Entra no SGR S@T cancela o cadastro da softHouse, sai do Portal, entra novamente vai aparecer uma que o cadastro esta cancelado, vai em empresa e cadastrar, ai cadastra a empresa novamente com os dados corretos. No meu caso, dava o Mesmo erro quanto tentava atualizar o Certificado. fiz dessa forma e funcionou." Postagem feita por MFLAVIO no fórum vbmania, página 80 do tópico Projeto S@T Fiscal.. Espero que ajude pessoas que estão em situação parecida.. .. (Peço desculpas a moderação se postar nomes de outros fóruns infringe as regras. Não encontrei nada relacionado a isso. Então, deve estar tudo bem!!)

Marcos pode ser resolvido da seguintes configurações. Componentes usados: ACBrECF, ACBrECFVirtualNFCe, ACBrPosPrinter, (ACBrNFeDANFeESCPOS ou ACBrNFeDANFCeFortes), ACBrNFe #ACBrECF - propriedade Modelo = ecfECFVirtual - propriedade ECFVirtual = ACBrECFVirtualNFce #ACBrECFVirtualNFCe - propriedade ACBrNFCe = ACBrNFe - propriedade PosPrinter = ACBrPosPrinter #ACBrNFe - propriedade Danfe = (ACBrNFeDANFeESCPOS ou ACBrNFeDANFCeFortes) #ACBrPosPrinter - propriedade Modelo = (ppTexto, ppEscPosEpson, ppEscBematech, ppEscDaruma, ppEscElgin ou ppEscDiebold); - propriedade Porta = COM1, COM2 ou Nome do Caminha/compartilhamento da impresso Nesse modo não haverá impressão na abertura ou no registro do item, ficando a cargo da impressão somente no final de todo processo

Estou enviando xml de venda e outro de cancelmento... Perdoe-me a demora!!! AD23160712211750000191590000008830000067496396.xml ADC23160712211750000191590000008830000075450774.xml

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.

A Quem possa interessar: CaminhoCompletoArquivoEvento := ACBrNFe1.Configuracoes.Arquivos.GetPathEvento( ACBrNFe1.EventoNFe.Evento[0].InfEvento.tpEvento, ACBrNFe1.EventoNFe.Evento[0].InfEvento.CNPJ, ACBrNFe1.EventoNFe.Evento[0].InfEvento.dhevento ) + '\' + OnlyNumber(ACBrNFe1.EventoNFe.Evento[0].InfEvento.Id) + '-procEventoNFe.xml';

Bom dia Marcello, Os arquivos: -env-lot.xml, -rec.xml, -ped-rec.xml e -proc-rec.xml, entre outros são arquivos de envio e de retorno da SEFAZ e conforme a minha postagem anterior não os considero como arquivos com validade jurídica. Para mim, os XMLs: *-nfe.xml (assinado e protocolado), *-procEventoNFe.xml e *-procInutNFe.xml são os únicos com validade jurídica, os demais não. É por isso que deveríamos mudar o conceito das propriedades Salvar para: Configuracoes.Geral.Salvar <== Salva ou não os arquivos sem validade jurídica Configuracoes.Arquivos.Salvar <== Salva ou não os arquivos com validade jurídica Essa alteração é simples de ser feita e seria realizada em apenas uma unit. Fazendo essa alteração os componentes ACBrNFe, ACBrCTe e ACBrMDFe por herança passariam a ter o mesmo comportamento no que diz respeito a essas propriedades.

Bom dia Daniel, No ACBrNFe a propriedade SalvarEvento antes se chamava SalvarCCeCanEvento e tinha como finalidade definir se os XMLs referente a eventos: CCe e Cancelamento seriam salvos na pasta definida por GetPathEvento ou salvos na pasta definida por GetPathCCe / GetPathCan. Sendo assim ela não tinha a função de informar se os XMLs seriam salvos ou não e sim definir o local de gravação, quem realmente defini se será salvo ou não é a propriedade Salvar (Configuracoes.Arquivos.Salvar). Se você abrir a unit ACBrNFeWebServices (repositório Trunk) e procurar pela propriedade SalvarCCeCanEvento vai encontra-la apenas em: function TNFeEnvEvento.GerarPathEvento: String; e vai poder confirmar o que escrevi acima. Se tratando de Eventos, o componente ACBrNFe gera 3 XMLs, são eles: *-ped-eve.xml <=== XML que contem o pedido do evento, ou seja, é a solicitação enviada a SEFAZ *-eve.xml <=== XML que contem o retorno da SEFAZ informando que o evento foi registrado ou não. *-procEventoNFe.xml <=== esse XML contem o pedido e o retorno, ou seja, o conteúdo dos dois acima e é o XML que devemos encaminhar para o destinatário e é este que usamos para imprimir ou gerar o PDF do Evento. Lembre-se que o XML da NF-e, ou seja, *-nfe.xml é a nota e esse arquivo para ter validade jurídica tem que estar assinado e com o protocolo de autorização. Caso esta nota venha ser cancelada, o XML da NF-e não deve ser alterado (em nenhum manual ou nota técnica diz que devemos substituir o protocolo de autorização pelo de cancelamento). Sendo assim ao efetuar o cancelamento (evento) teremos o *-procEventoNFe.xml, este é um documento com validade jurídica pois esta assinado e possui o protocolo da SEFAZ que diz que o evento foi registrado e vinculado a NF-e. De forma semelhante os componentes ACBrCTe e ACBrMDFe geram os 3 XMLs acima citados e com os mesmos propósitos sendo que o último tem o seu nome diferente: *-procEventoCTe.xml / *-procEventoMDFe.xml No meu entendimento e pela legislação devemos armazenar em disco ou no banco de dados os arquivos que tem validade jurídica, os demais podemos com o passar do tempo excluir ou até mesmo não salvar. Sendo assim concluo que a propriedade: Configuracoes.Arquivos.Salvar tem que ser usada para definir se os arquivos com validade jurídica serão salvos em disco ou não, se eu optar por não salvar tenho que ler a propriedade que contem o XML em questão para poder armazena-lo no banco de dados. Por outro lado a propriedade: Configuracoes.Geral.Salvar tem que ser usada para definir se os demais arquivos (sem validade jurídica) serão salvos em disco ou não.

Daniel, Caso opte pela minha sugestão, vai sim ter quebra de código como se trata de um Refactoring isso foi discutindo entre nós que isso iria acontecer e não vejo essa alteração como traumática. Da forma que hoje esta implementado o PathEvento e o GetPathEvento já prevê todos os eventos: %MeuPath% \CNPJ \YYYYMM \Evento \CCe \Cancelamento \EPEC \Confirmacao \Ciencia \Desconhecimento \NaoRealizada Acredito que o problema que o Ricardo se refere é: no momento de gravar o XML do evento o componente se baseia no PathCCe ou PathCan dependendo do evento. E ao tentar ler o XML o componente se baseia no PathEvento. Se eliminarmos as propriedades PathCCe e PathCan e consequentemente o GetPathCCe e GetPathCan, teremos que realizar as correções a fim de no momento de salvar a solicitação, o retorno e o XML de compartilhamento do evento levando em conta o PathEvento. Os componentes ACBrCTe e ACBrMDFe já trabalham desta forma.

Bom dia. A emissão da NF-e é igual a de saída, mudando o tpNF para Saida Ide.tpNF := tnEntrada; // Entrada Ide.tpNF := tnSaida; // Saida Atenciosamente. Jéter Rabelo Ferreira