Wess

Boa tarde Carlos, complementando a resposta do nosso colega: Caso não consiga utilizar o ambiente de homologação(muita gente não consegue, inclusive eu), pode usar o ambiente de produção sem problemas, todas as guias geradas que não são pagas até seu vencimento são canceladas automaticamente, então pode testar sem problemas.

Boa tarde, verifique se no próprio código de geração não há nenhuma função bloqueando os mesmos, já passei por questão similar ao usar funções de terceiros antigamente, não era relacionado a boletos mas ocorreu esse problema, cuide também com os caracteres especiais pois não sei se são aceitos, procure usar algo para em vez de retirar o caractere, substituir por sua forma comum, de Ç para C.

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.

Obrigado pela informação.

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..

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)

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.

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.

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

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.

@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.

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...

@rafiwks posta os xmls da NF-e e do envio e retorno do evento

@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.

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

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.

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.

Comigo está ocorrendo a mesma coisa, como solução paliativa, o cliente está enviando a NFS-e normalmente, porém sem consultar após o envio, de tempos em tempos o cliente está tendo que olhar no site da prefeitura para saber se foi processada corretamente a nota ou não, o que é, honestamente, um pé no saco, bem que a Betha podia disponibilizar um servidor que cumprisse seu trabalho adequadamente, mas é isso aí, por enquanto temos que arrumar alternativas para compensar essas falhas.

Bom dia amigo, acho que não tem outra resposta se não: Estudar os exemplos. Há exemplos pro Sintegra, pro SPED Fiscal, SPED Contribuições e outros... Se for fazer de maneira bem simples, basta ir varrendo o banco de dados buscando os registros e usar os métodos de inclusão do componente, por exemplo "Registro0000New", aí passando os valores de cada propriedade, por fim as somas dos registros e etc são feitas automaticamente, por isso digo, o exemplo que vai junto com o componente já tem tudo que você precisa para iniciar o desenvolvimento, e pra entender a forma de funcionamento do SPED em si, só lendo os manuais da receita mesmo.

Imagina, quando eu puder ajudar, será uma satisfação. Abraço.

Bom dia amigo, aqui eu emito normalmente todos os DF-e's com as configurações em anexo, já em relação ao motivo, não sei dizer ao certo, mas acredito que deve estar relacionado à forma com que o WS é estruturado mesmo, acredito que fuja um pouco de nosso controle, posso estar enganado, mas é minha opinião.

Verifique se está alimentando o atributo "nItem" corretamente no produto, de acordo que siga a sequência 1..N, que de resto se o modelo for 65 e estiver configurado pra homologação, o componente informará essa descrição automaticamente. Por exemplo: <det nItem="1"> - <prod> .. </prod> - <imposto> .. </imposto> </det>

Acredito que seja apenas esse o problema realmente, já ocorreu comigo a situação apenas por selecionar a opção de Consumidor Final sem querer, deve estar se perdendo em alguma rotina sua e entendendo como venda interestadual ou algo assim, ou talvez falte melhorar um pouco a rotina para gerar a tag apenas em casos bem específicos, evitando essa rejeição.

Pode ser que o problema esteja em alguma rotina de rateio do seu sistema, por exemplo, se a nota possui desconto na nota, obrigatoriamente você deve ratear esse valor proporcionalmente entre os itens para validar o xml, talvez nessa hora por questões de arredondamento, jogando um centavo a mais em um produto ou outro, logo, ao tentar enviar ele irá rejeitar a nota, ou também o caso contrário inclui desconto no item, e ao totalizar no total da venda esse desconto, centavos de divergência causados por esse problema de arredondamento, pra resolver uma questão dessas muita gente faz o seguinte: vê a diferença q totalizou em comparação com o total que deveria ser, e joga no último item como acréscimo ou desconto, dependendo da situação. Mas o que realmente acho que pode ser o causador principal do problema após ter visto o xml que você enviou, é que esteja se perdendo na hora de calcular impostos, pois, até onde eu saiba, Simples Nacional nem pode destacar ICMS, salvos os casos em que está fazendo uma devolução que possua tal destaque, poderia apenas estar incluindo o aproveitamento de crédito, mas de qualquer forma, nem com o CSOSN 102 seria, somente com 101 ou 201, e além disso, como pode ver no código do ACBr, nem gera as tags de ICMS com o 102: //Grupo do Simples Nacional sTagTemp := CSOSNTOStrTagPos(nfe.Det[i].Imposto.ICMS.CSOSN); Gerador.wGrupo('ICMSSN' + sTagTemp, 'N' + CSOSNToStrID(nfe.Det[i].Imposto.ICMS.CSOSN)); Gerador.wCampo(tcStr, 'N11' , 'orig ', 01, 01, 1, OrigTOStr(nfe.Det[i].Imposto.ICMS.orig), DSC_ORIG); Gerador.wCampo(tcStr, 'N12a', 'CSOSN', 03, 03, 1, CSOSNIcmsToStr(nfe.Det[i].Imposto.ICMS.CSOSN), DSC_CSOSN); case nfe.Det[i].Imposto.ICMS.CSOSN of . . csosn102, csosn103, csosn300, csosn400: begin //Tags ORIG e CSON já criadas antes do case <-------- aqui end; . . csosn900: // < ------------ aqui o caso que falei da devolução, pode ver que gera normalmente begin //10h if (nfe.Det[i].Imposto.ICMS.vBC > 0) or (nfe.Det[i].Imposto.ICMS.vICMS > 0) then begin Gerador.wCampo(tcStr, 'N13', 'modBC ', 01, 01, 1, modBCToStr(nfe.Det[i].Imposto.ICMS.modBC), DSC_MODBC); Gerador.wCampo(tcDe2, 'N15', 'vBC ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vBC, DSC_VBC); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N14', 'pRedBC ', 01, IIf(Usar_tcDe4,07,05), 0, nfe.Det[i].Imposto.ICMS.pRedBC, DSC_PREDBC); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N16', 'pICMS ', 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pICMS, DSC_PICMS); Gerador.wCampo(tcDe2, 'N17', 'vICMS ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vICMS, DSC_VICMS); end; if (nfe.Det[i].Imposto.ICMS.vBCST > 0) or (nfe.Det[i].Imposto.ICMS.vICMSST > 0) then begin Gerador.wCampo(tcStr, 'N18', 'modBCST ', 01, 01, 1, modBCSTToStr(nfe.Det[i].Imposto.ICMS.modBCST), DSC_MODBCST); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N19', 'pMVAST ', 01, IIf(Usar_tcDe4,07,05), 0, nfe.Det[i].Imposto.ICMS.pMVAST, DSC_PMVAST); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N20', 'pRedBCST', 01, IIf(Usar_tcDe4,07,05), 0, nfe.Det[i].Imposto.ICMS.pRedBCST, DSC_PREDBCST); Gerador.wCampo(tcDe2, 'N21', 'vBCST ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vBCST, DSC_VBCST); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N22', 'pICMSST ', 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pICMSST, DSC_PICMSST); Gerador.wCampo(tcDe2, 'N23', 'vICMSST ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vICMSST, DSC_VICMSST); end; if nfe.Det[i].Imposto.ICMS.pCredSN > 0 then begin Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N29', 'pCredSN ', 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pCredSN, DSC_PCREDSN); Gerador.wCampo(tcDe2, 'N30', 'vCredICMSSN', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vCredICMSSN, DSC_VCREDICMSSN); end; end; end; Gerador.wGrupo('/ICMSSN' + sTagTemp ); Na minha opinião é só você mudar a totalização de ICMS apenas pras operações com CSOSN 900 que os problemas estarão resolvidos. Abraço.

Boa tarde, fiz uma rápida pesquisa no Sintegra-SP, esse CNPJ está vinculado à IE 288.055.615.111 , tente informar com esse valor e veja se passa.