Wess

Membros
  • Total de ítens

    32
  • Registro em

  • Última visita

Reputação

9 Neutral

1 Seguidor

Sobre Wess

  • Rank
    Membro
  • Data de Nascimento

Profile Information

  • Sexo
    Masculino
  • Localização
    Concórdia

Últimos Visitantes

94 visualizações
  1. No meu entendimento Simples Nacional nunca utiliza as tags de vBC, pICMS e vICMS, salvos os casos em que se utiliza o CSOSN 900 para devoluções e outras operações que necessitem destes. De forma que em todas as outras operações essas tags vão sempre vazias tanto no item como no totalizador. Já para Lucro Real/Presumido depende bastante da operação(já vi enviarem NF-e com as tags zeradas em algumas operações mesmo não sendo CST 90), mas normalmente as tags vão preenchidas sim e as mesmas devem ser iguais ao valor totalizado no final do arquivo, caso contrário irá ocorrer rejeição na hora de autorizar. Nunca vi destacar o ICMS nos itens e zerar o totalizador e a nota passar normal... Lembrando que tratei tanto de NFC-e como NF-e, tirando o fato de que não existe devolução em modelo 65, apenas referenciando um modelo 65, mas a regra de totalizar os valores e o resto seria igual para ambos.
  2. Obrigado pela informação.
  3. A princípio esse processo é todo automático, tenta entrar em contato com a SEFAZ para verificar se tem algo anormal lá. Aqui em SC sempre vai na hora pro ambiente nacional, nunca passei por isso..
  4. Tenta assim : NodeBase.ChildNodes['Estoque'].Attributes['Versao'] := '1.0'; Não conheço a estrutura do teu XML até porque nem desenvolvi a questão do bloco X ainda, mas o NodeBase vai corresponder à tag pai da tag Estoque(se houver)
  5. Só se deve gerar o C170(quando aplicado ao perfil) para notas emitidas por terceiros ou que ensejam ressarcimento de ST, ocasião que requer o registro C176 junto com o C170, de forma que, caso a nota a ser incluída no registro não seja emitida por terceiros e não é alvo de ressarcimento, não precisa gerar o C170 nem filhos, vide exceção 2 do registro C100. Ainda vale lembrar que nem todos os estados permitem o pedido de ressarcimento, então o registro C176 se torna ainda menos presente. Provavelmente você está lançando o registro desnecessariamente.
  6. Bom dia, essa parte não tem segredo, dá uma olhadinha no exemplo do ACBrNFe, mais especificamente no botão 'Consultar pela Chave', são poucas linhas mas irá servir para o que você precisa, não tem segredo no processo pois por mais que sua nota seja rejeitada, antes mesmo de enviá-la você já tem a chave de acesso da mesma, então é só gravar junto ao teu registro no bd e executar uma consulta utilizando-na posteriormente.
  7. No ACBrNFe, através de: ACBrNFe1.DANFE.Sistema := 'Nome software house'; ou direto em ACBrNFeDANFCeFortes1.Sistema := 'Nome software house'; Lembrando que também pode informar o Site da software house... e a parte de ler o ini acredito que você não terá problemas, né? E no ACBrMonitor como o Kiko informou, apenas lendo/escrevendo no Ini diretamente
  8. Boa tarde, primeiramente, o código 100 não é código de erro, ele é usado para indicar que a NF-e foi autorizada corretamente. Algo simples que pode ser feito nesses casos de duplicidade é realizar a consulta da NF-e após o envio em casos que a resposta não tenha sido retornada corretamente na primeira vez entendendo como nota duplicada(ocorre bastante em lugares com conexão ruim), e se coincidir com a NF-e q está tentando enviar, você pode apenas pegar as informações de protocolo, chave de autorização e etc e montar o XML corretamente com a autorização, alimentando também os devidos campos no banco de dados, tudo isso baseado no retorno da consulta dessa chave de acesso. E em casos como o que você citou, de uma máquina tentar enviar a nota ao mesmo tempo e gerar duplicidade com diferença da chave de acesso, pode criar uma rotina para tentar reenviar a NF-e com a próxima numeração, mas pra esse segundo caso tem que ter um cuidado muito grande pra não criar problemas desnecessários, como o armazenamento dos arquivos de cada nota corretamente e etc.
  9. @UEMERSON NEGREIRO DA SILVA infelizmente não temos muito o que fazer além do que passei no post anterior sobre a solução paliativa que adotei, já é uma briga de tempos com a Betha, em 2015 já ocorria esse tipo de problema.
  10. Boa tarde amigo, na verdade esse problema ocorre até mesmo com 1 lote, vai bastante da "sorte" na hora de emitir, infelizmente o servidor Betha(ao menos é o único que ocorre esses problemas pros meus clientes) é bem instável, há momentos que chega demorar mais de 45 minutos para processar um RPS, dessa forma, quando o sistema tenta consultar a situação do lote após a emissão e não retorna nada pelo fato de não ter sido processado ainda, ele retorna essa rejeição sem valor. No meu sistema fiz uma opção pro contribuinte selecionar se deseja que o lote seja consultado após emissão, especificamente pra esses provedores que tem alto tempo de resposta, então fica a responsabilidade do usuário verificar na prefeitura quando a nota foi processada, para então consultar no sistema o lote e retornar as informações corretas, é uma verdadeira gambiarra que esses provedores nos obrigam a fazer...
  11. @rafiwks posta os xmls da NF-e e do envio e retorno do evento
  12. @rafiwks Só por perguntar mesmo, mas está setando o ambiente do evento corretamente? Por exemplo, no meu sistema verifico em que ambiente a nota foi enviada e faço: ACBrNFe1.Configuracoes.WebServices.Ambiente := taProducao; infEvento.tpAmb := taProducao; ou ACBrNFe1.Configuracoes.WebServices.Ambiente := taHomologacao; infEvento.tpAmb := taHomologacao; Isso na hora de alimentar a chave da NF-e e todas as outras propriedades usadas pra enviar o evento.
  13. Até onde eu saiba eles nem cogitam a possibilidade, deve ser porque todos os outros estados estão errados ao adotar NFC-e (rsrs), realmente acho que só a partir de 2018 para ser pensado nisso, e ainda vai ser uma grande briga pra de fato acontecer isso
  14. Bom dia, analisando o código e comparando com o exemplo e até mesmo o código da minha aplicação, acredito estar faltando alimentar as propriedades: infEvento.chNFe, infEvento.CNPJ, infEvento.detEvento.nProt, de forma que o WS não consegue ler o XML enviado e consequentemente retorna uma resposta negativa em relação ao seu pedido de cancelamento, aí entra também o problema que você citou, de que no seu sistema cancela a nota normalmente, isso se deve ao fato de que você envia o evento e não verifica o protocolo do retorno, apenas se der exception, mas a nota não está gerando erro na criação e envio, apenas não retorna a resposta esperada, então o exception se faz inútil nessa situação, sugiro um tratamento similar: ACBrNFe1.EnviarEvento(StrToInt(nNota)); <- aqui entra com o DataSet já em edição pra receber as informações do retorno(se estiver vazio não tem problema, pois ele cancelará caso não tiver protocolo) -> ProtCancelamento := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt; CodStatusCancelamento := IntToStr(ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat); DHCancelamento := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.dhRegEvento; MotivoCancelamento := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.xMotivo; if ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt = '' then <- se está vazio joga a rejeição e cancela as alterações feitas acima -> begin Application.MessageBox(pchar(ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.xMotivo), '', MB_ICONINFORMATION); DataM.ADQUsado.Cancel; abort; end; if ProtCancelamento <> '' then begin <- caso tenha dado certo o cancelamento, você joga aqui o bloco que faz estorno financeiro e o que mais desejar -> .. .. end; Favor nos informar dos resultados.
  15. Boa tarde amigo, se puder postar o código em questão e também o XML de envio e retorno do evento ficará mais fácil lhe ajudar.