Kiko Fernandes

Bom, é sua opinião vou respeita-la. Porém de igual forma a sua nota seria rejeitada e as schemas NÃO SÃO GERADAS pelo ACBr ele apenas segue a instrução. Esta composição de CRT e CST/CSOSN foi incluída na geração 2.0 da NFe algo pelos meados de 2010, já foi assunto muito discutido no passado.

Bom dia @ALA A questão deste procedimento é justamente garantir uma segurança maior a informação gerada. Já ocorreram muitas fraudes devido a este erro. Só que quando acontecem todos gritam e ninguém quer assumir a responsabilidade. Inclusive já culparam até a SEFAZ dizendo que os servidores da SEFAZ foram invadidos, outros disseram que os servidores de email foram invadidos e por ai se vai a imaginação fértil do povo. (Inclusive há vídeos aonde a SEFAZ explica a situação. Isto já é antigo, mas muitos tem dificuldades de entender o risco e ficam insistindo, até então que a SEFAZ se posiciona criando a rejeição. Se você ver os números não permitidos vai perceber que eles tentaram imaginar o que alguns colocariam e não duvido que se tivessem acesso ao teu texto antes tentassem bloquear códigos de possíveis composição de data Mas tirando a brincadeira de lado o caso é sério. Muitas empresas foram fraudadas, (como está citado nos links acima, que nossos colegas postaram sobre boletos falsos), pois já tiveram casos de que com posse da chave da nota, acessam o portal nacional e com informação de uma nota por exemplo a crédito (duplicatas, boletos) enviaram no do email do cliente (que está no xml) um novo boleto oferecendo descontos vantajosos se o pagamento fosse antecipado, algo assim e no boleto ou no email informavam dados da nota, data e as vezes até produtos fazendo com que isto desse credibilidade ao golpe. Muitos por sua vez vê a vantagem, nem se importam com o email recebido e pagam, depois a empresa não recebeu e as vezes acionam na justiça o cliente que terá que pagar novamente a dívida. Isto é muito sério e no google está cheio de relatos assim. Aqui no forum, há um relato de alguém que diz que o fraudador chegou a ligar para eles (empresa que desenvolve) e por telefone ia falando as notas que estavam sendo emitidas, os produtos e valores e ainda oferecendo serviço de proteção contra esta "fragilidade de segurança" e o rapaz da software house, pensando em vulnerabilidade do servidor de empresa, firewall, invasão de email etc, sendo que o fraudulento apenas tinha condição de criar as chaves (como ele criaria) e consultar na sefaz. Simples assim. Então não brinque com isto, se alguém pegar duas notas suas e entender que você usa a data para compor o código aleatorio (cNF) ficará o mesmo caso de usar o numero da nota para cNF, ou seja não resolve nada. Todos que sabem como se compõe uma chave logo conseguirá compor a proxima. O cara faz uma tentativa de um novo número com a mesma data, digamos que deu não encontrada ele acrescenta a próxima data e vai na tentativa novamente até dar o próximo erro, sendo necessário outra vez acrescentar a nota data. Quanto aos teus questionamento: - Sim seria bom vc gerar um número aleatório e guardar no banco de dados. (este é o ideal) - Quando vc diz "Nunca mais consigo gerar a chave". Em ultimo caso, se você tentar enviar novamente o mesmo numero de nota com chave diferente ele vai te retornar a informação de duplicação e vem o retorno da chave que está registrada na sefaz. E isto só é possível com o uso do certificado e emitindo a nota, logo outros não saberão, mas o emitente tem sim a condição de saber, não estará perdido para sempre - Porém se mesmo assim você tem pouco domínio em gerar um código randômico e grava-lo no banco, você pode criar uma rotina sua para gerar este código aonde só você saiba como ele é composto. Exemplo: 2 ultimos dígitos do cpf/cnpj do cliente; 2 últimos dig. do minuto da emissao ou do orçamento; 2 ult. dig. do número da nota; 1 dig. da forma de pagto, 1 do prim. digito do valor da nota. Algo assim: você teria o código de 8 dígitos em mãos, uma vez que sabe a fórmula que usou para criar uma função: gerateucodigoaleatorio() e estaria dificultando para alguém que não sabe o código. Se for criar invente uma, isto é apenas um exemplo Portanto tem N formas de fazer, porém fuja do óbvio.

Bom dia! O ACBrMonitorPLUS segue "rigorosamente" o cumprimento das Notas Técnicas e Manuais. CRT - CÓDIGO DO REGIME TRIBUTÁRIO 1 = SIMPLES NACIONAL 2 = SIMPLES NACIONAL – EXCESSO DE SUBLIMITE DE RECEITA BRUTA 3 = REGIME NORMAL CST – Código situação tributária informada no grupo de tributação do produto para empresas que estão no regime normal (CRT=3) CSOSN – Código de Situação da Operação no Simples Nacional informado no grupo de tributação do produto, para empresas que estão operando no SIMPLES NACIONAL - (CRT=1) Logo se CRT=1 a tag formada no XML será CSOSN e não CST. Se a empresa está no Regime Normal o CRT deve "obrigatoriamente" ser = 3.

Fechando o tópico. Obrigado por reportar e para nova dúvida, abra novo tópico.

Obrigado por reportar. Fechando o tópico e para nova dúvida abra novo tópico.

Boa tarde! R: Você pode criar no seu sistema um recurso que ao receber o retorno do status 109 - Serviço paralisado sem previsão ou 108 - Serviço paralisado momentaneamente (curto prazo) ou ainda sem comunicação e nestes casos aplicar a ativação do modo contingência. R: Pode enviar o comando status e ao receber a resposta no arquivo de retorno, exibir as linhas que interessam para o operador. Estude o arquivo e você verá como é composto o retorno. Porém vale ressaltar o cuidado com o status, não fique enviando comando de status antes de cada emissão de NF que você pode se enquadrar no "Consumo indevido", pois ao enviar um comando para emissão de um documento, deve ser analisado o retorno deste comando. Para mim continua confuso o que você está tentando expor. - O arquivo TXT é deve ser criado pela sua aplicação, o ACBrMonitorPLUS apenas lê o arquivo e gera o XML e prossegue com os comandos de envio ou criarenviar que após gerar o XML já envia. - Pode ainda você gerar o XML e apenas validar e transmitir pelo ACBrMonitorPLUS. - Quando você diz "componente" para nós significa usar os módulos do ACBr incorporado em seu sistema se você programa na linguagem Delphi e não usar o aplicativo ACBrMonitorPLUS que permite então que seja utilizado em qualquer linguagem. Lembrando ainda que está em desenvolvimento uma DLL que também poderá ser aplicada em outras linguagens sem haver a necessidade do programa ACBrMonitorPLUS.

Bom dia! O correto é você se informar em cada UF em que desejar usar o seu sistema. Muitas exigem sim que exista o cadastramento da Software House como fornecedor de software para emissão de documentos fiscais eletrônicos. É o caso por exemplo do Para, Paraná, Santa Catarina, São Paulo para SAT etc. Em alguns vão te disponibilizar link e você faz online, outros como o caso do Paraná, mesmo fazendo o preenchimento online, será necessário assinar e encaminhar um termo de responsabilidade técnica pelo correio a Curitiba e após análise, vão liberar e cadastrar o teu software com um código, que será usado quando estiver preenchendo a ficha do emissor do documento fiscal (teu cliente). Após isto, você terá que reconhecer (eletronicamente) cada cliente que preencher a ficha de "Pedido de emissor de documentos fiscais eletrônicos") que usarem o código do teu sistema como fornecedor. Não sei os outros estados como funciona, mas tem características particulares, por isto é bom se informar na Unidade da Federação que você deseja operar.

Boa tarde! Eu penso que o sinal de = não esteja atrapalhando, pois conforme pode ser visto na figura em anexo a carta está registrada e o sinal de "=" bem interpretado. Porém não conseguir detectar o erro. Talvez seja interessante preencher os parâmetros (pelo menos para teste) como impressora e colocar o sinal delimitador (aspas) entre as opções do comando. Ex.: NFE.ImprimirEventoPDF("D:\NFe\EVENTOS\57270480000128\NFe\..." , "D:\NFe\Transm\57270480000128\NFe\...") Outro detalhe que observei que parece não localizar seus arquivos. Dê uma revisada nos patch´s (caminhos) dos arquivos.

Bom dia! Exato até no texto tem a citação das madeireiras: Obg. por reportar. Estou fechando o tópico. Para nova dúvida, crie novo tópico.

Bom dia! Penso ser a reclassificação a forma mais adequada, mas seria ideal realmente ter um parecer de um bom escritório contábil. Fonte: http://audisoft.com.br/cms/index.php/manuais/14-faturamento/98-reclassificacao-de-mercadorias

Sem separação das esferas (Federal/Estadual e Municial) e nem a fonte do valor: IBPT. Pesquisei muito na internet mas ainda não encontrei nenhum site que informa se é legal a informação ser passada dessa forma. Olhei aqui no fórum, e por alto, alguns usuários dizem que emite, até mesmo essa informação no campo de complemento. Mas já que o ACBr possui esta tag vTotTrib, acredito que exista alguma forma de não recorrer à gambiarras rsss Por favor, gostaria de saber o que vocês fazem para emitir a NFCe com essas informações, pois não encontrei nenhuma resposta correta Boa noite! Veja que o campo no manual diz o seguinte: Não tem como especificar os três em apenas um campo aonde pede o total. Para atender a lei e que saia de forma separada a impressão, você terá que controlar isto e imprimir em informações complementares.

Penso que foi solucionado, por isto vou fechar o tópico. Para nova dúvida, crie um novo tópico.

Boa tarde! Quando for CRT=1 (Simples) você precisa preencher o campo CSOSN. Teu arquivo INI: Exemplo: [ICMSXXX] Orig= CST= CSOSN= pICMS= http://anfm.blogspot.com/2015/05/campos-do-ini-usado-no-acbrmonitorplus.html?m=1

Boa tarde! Enquanto aguardamos o teu arquivo, aproveito para alerta-lo sobre o CST do IPI. No XML que você postou a operação é de saída e você colocou código CST de IPI como de entrada. Aproveite e corrija isto também, pois poderá ter alguma complicação mais tarde ou receber um email da SEFAZ, já que agora eles estão solicitando as informações do grupo técnico Teu XML: A partir de 01/04/2010 os contribuintes do IPI deverão utilizar a seguinte Tabela de CST/IPI: SAÍDAS 50 – Saída Tributada 51 – Saída Tributável com Alíquota Zero 52 – Saída Isenta 53 – Saída Não Tributada 54 – Saída Imune 55 – Saída com Suspensão 99 – Outras Saídas ENTRADAS 00 – Entrada com Recuperação de Crédito 01 – Entrada Tributada com Alíquota Zero 02 – Entrada Isenta 03 – Entrada Não Tributada 04 – Entrada Imune 05 – Entrada com Suspensão 49 – Outras Entradas

Obrigado por reportar. Fechando o tópico e para nova dúvida crie um novo tópico.

Bom dia! No teu arquivo INI, você não informou o codigo CST, nem origem da mercadoria. Como não tem esta informação o ACBrMonitorPLUS está setando a padrão CST=00. Parte do conteúdo do teu arquivo: Falta o campo CST. Isto em primeiro momento. Corrija e depois se não der certo, continue informando neste tópico.

Boa noite. Tem caracteres estranhos no teu arquivo TXT. Obs.: Não é possível notar com o editor de texto notepad, porém percebi o erro no log do ACBrMonitorPLUS e então abri com o Notepad++ aonde é possível perceber que tem alguns caracteres (parecido com CHR13) mas não sei o que é, pois o CHR13 seria notado no notepad. Em anexo seguem as telas com a comparação do arquivo aberto no notepad++ e notepad, assim como o resultado do arquivo sem a correção e após a correção. (Para corrigir eu apaguei as tuas linhas e reescrevi)

Obrigado por reportar. Fechando este tópico. Para novas dúvidas, crie novo tópico.

Este arquivo que você postou que mostra o retorno de autorizada não foi via socket? O erro acontece antes de gerar o XML? Se conseguiu gerar anexe ele.

Boa tarde! Experimente fazer um teste: Passe o campo cUF=28 para o grupo [Identificacao] ou então retire o campo do grupo [Emitente] e reenvie.

Parece ser na SEFAZ. Vamos aguardar. Algumas notas que estavam com este erro ao repetir a operação, após algum tempo a nota foi enviada. (Obs. Cuidado para não ficar fazendo várias tentativas de envio, recebendo a mesma rejeição, pois isto pode causar um bloqueio por consumo indevido).

Bom dia! Acesso o link e tente ver se passa pelo botão [ Acessar credenciamento Online ] http://www.dfe.ms.gov.br/nfce-credenciamento/index.jsf

Boa noite! Se não me engano a opção de configuração do certificado digital está em OPENSSL. Neste caso a unidade do produto deve ter no mínimo 3 caracteres. Use "UND" ao invés de "UN" Obs. Existe como alterar a schema, mas você teria que distribuir em seus clientes e ao atualizar as schemas outra vez teria que refazer a operação. Porém estes schemas deveriam estar funcionando sem problemas, pois na própria documentação no portal nacional existe uma padronização de unidades e lá consta M para metro e K para Quilate, além de M2, ML, PC. (Ou seja deveria ser aceito 1 ou 2 caracteres) Este problema está acontecendo só com MG? Você tentou enviar com as mesmas schemas para outra SEFAZ? http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=RY8TPoGpyMY=

Obrigado por reportar. Fechando o tópico. Nova dúvida novo tópico.

Bom dia! Não tive tempo para testar, mas vale dar uma olhada se não é esta opção no config do ACBrMonitorPLUS. Obs. digo, não tive tempo para testar com a versão que foi citada: 1.2.0.49