Italo Giurizzato Junior

Bom dia brsamn, Por favor atualize os fontes e teste novamente. Ao alimentar o componente continue utilizando o ";" para informar a quebra de linha no campo Discriminação. Verifique se ao gerar o XML do RPS o mesmo foi trocado por "\s\n". Envie o lote contendo esse RPS e verifique o conteúdo da TAG Discriminação do XML na NFS-e. Visualize tanto pelo componente quanto pelo site essa NFS-e e veja como fica essa informação.

Cesar, Post como anexo o XML cujo DANFE você deseja imprimir.

Boa tarde, O mais estranho é o Registro de Passagem da NF-e, protocolado no dia 6. A mercadoria circulou, ou seja, foi enviada para o destinatário?

Anselmo, Se o CST = 60 é o que eu postei. Favor consultar o Manual versão 2.00a do CT-e nele você vai encontrar quais são as TAGs que devem ser geradas dependendo do CST.

Boa tarde Cesar, Que seja uma mensagem, pelo tamanho dela você não concorda que ficaria muito melhor ter salvo em um arquivo TXT do bloco de notas e anexado a postagem? E outra coisa, mesmo sendo uma mensagem ela esta incompleta, pois diz que não foi possível carregar o arquivo, sem seguida tem o conteúdo do mesmo. Esta faltando o final desse arquivo e o motivo pelo qual não foi possível carregar. Qual é o comando ou sequencia de comandos que você esta executando que esta gerando esse erro? Mais uma coisa o meu nome não tem a letra n no final.

Boa tarde brsamn, Qual é o provedor que se utiliza da sequencia \s\n para forçar a quebra de linha?

Boa tarde, A mensagem que é retornada ao tentar cancelar, trata-se de uma rejeição da SEFAZ-Autorizadora? Ou é uma mensagem da sua aplicação? A minha sugestão é solicitar ao destinatário que faça uma nota de devolução como se ele tivesse recebido a mercadoria e agora esta devolvendo. E o seu cliente se utiliza dessa nota de devolução para registrar a entrada da mercadoria no estoque só que a titulo de entrada por devolução.

Boa tarde Cesar, Por favor não post o conteúdo de arquivos, anexo o mesmo fica muito mais fácil de alguém poder lhe ajudar. Outra coisa o conteúdo desse arquivo esta incompleto não é a toa que não é possível visualiza-lo utilizando um navegar, por exemplo.

Boa tarde Anselmo, Você não informou se esta usando o componente ou o ACBrNFeMonitor. Se tratando do componente, você deve alimenta-lo da seguinte forma: Imp.ICMS.SituTrib := cst60; Imp.ICMS.ICMS60.CST := cst60; Imp.ICMS.ICMS60.vBCSTRet := RoundTo(DM_CNT.ConhecimentoBaseCalc.AsFloat, -2); Imp.ICMS.ICMS60.pICMSSTRet := RoundTo(DM_CNT.ConhecimentoAliqICMS.AsFloat, -2); Imp.ICMS.ICMS60.vICMSSTRet := RoundTo(DM_CNT.ConhecimentoValorICMS.AsFloat, -2); Imp.ICMS.ICMS60.vCred := RoundTo(DM_CNT.ConhecimentoCreditoICMS.AsFloat, -2); // Recalcula o valor a receber quando existe ICMS/ST retido vPrest.vRec := RoundTo(vPrest.vTPrest - Imp.ICMS.ICMS60.vCred, -2);

Boa tarde a todos, A ideia é incluir uma parametrização nas Units referentes aos provedores. A principio esse parâmetro que pode se chamar QuebradeLinha terá o valor ";". Quando você for alimentar o componente deve-se sempre utilizar o carácter ";" para identificar que naquele ponto deve ocorrer uma quebra de linha. Vamos supor que o provedor XYZ se utiliza do carácter "|", o que vai ocorrer? Ao gerar o XML para ser enviado para o Web Services o componente vai substituir o ";" pelo "|". Por outro lado ao imprimir o DANFSE, o componente vai saber qual é o carácter ou sequencia de caracteres que ele deve utilizar para realizar a quebra de linha em função do provedor.

Boa tarde Junior, Não realizei nenhum teste, apenas implementei as rotinas no componente.

Bom dia Rodrigo, No seu XML consta que a UF de inicio é MG e de Fim é AL, até ai sem problemas. Mas no percurso você coloca os Estados na seguinte ordem: PR-SP-MG-BA-SE Muito bem se o caminhão parte de MG, primeiro ele tem que passar por SP e depois chegar ao PR, e ao voltar para poder chegar até BA tem que passar por SP, depois MG. O correto é: SP-PR-SP-MG-BA-SE (esta faltando o que esta em negrito).

Bom dia Luis, Segundo a Nota Técnica 2013/004 versão 1.00a - Outubro/2013, página 96, campo #45 diz que o grupo <infMunDescarga> tem um numero de ocorrências: 1-100 Portanto um caminhão pode realizar no máximo 100 Descargas, lembrando que cada descarga se refere a uma cidade diferente, e em cada cidade pode ocorrer até 2000 entregas, note que o campo #49 diz que o grupo <infCTe> tem um numero de ocorrências: 0-2000.

Bom dia Junior, Sendo assim, chego a conclusão que o problema pode ser na SEFAZ. Entre em contato com eles.

Bom dia Junior, A estrutura dos resumos de eventos do CT-e e MDF-e ainda não foram publicados, assim que forem publicados os schemas referentes ao Resumo de Eventos desses documentos teremos como saber a sua estrutura. Mas acredito que será semelhante a do NF-e que encontra-se na página 10 da NT.

Bom dia Leandro, Manual versão 2.00a do CT-e: Página 80 - diz que você não pode cancelar um evento EPEC Página 82 - regras de validação do evento de cancelamento Página 88 até 95 - Lista de rejeições, procure por cancela você vai encontrar as rejeições ao tentar cancelar um CT-e Nota Técnica 2014/001 Página 2 - itens 3 e 4 Como você pode ver, uma apostila não tem, o que temos são os Manuais e Nota Técnicas. A dica que dou e as vez pareço ser chato, é sempre pedir para que leem os Manuais e NT. Eu todo dia visito os Portais da NF-e, CT-e e MDF-e em busca de algo novo, uma Nota Técnica, Schemas, etc. Se todos passarem a ter esse tipo de atitude, muitas duvidas são sanadas só lendo esses documentos. Ficando apenas esclarecer algumas coisas, uma vez que a interpretação de um não é a mesma de outro. Hoje tenho: CT-e: 40 documentos (Manuais e NT) NF-e: 69 documentos MDF-e: 18 documentos Todos baixados dos Portais: http://www.nfe.fazenda.gov.br/portal/principal.aspx http://www.cte.fazenda.gov.br/ https://mdfe-portal.sefaz.rs.gov.br/

Bom dia Mauricio, Se o usuário lança as os RPS e os mesmos são armazenados no banco de dados, depois em um segundo form lhe é apresentado uma lista de RPS lançados mas não enviados e ao clicar no botão Enviar todo o processo é realizado simplifica a vida do usuário. Eu sei que você quer que a aplicação vai mostrando o que esta sendo feito. Mas os passos: gerar os XMLs de cada RPS, assinar os RPS (depende do provedor), gerar o Lote, assinar o Lote (depende do provedor) e validar o Lote é tão rápido que não vejo o porque. E como você pode ver, dependendo do provedor você não vai poder imprimir a mensagem informando ao usuário que o XML do RPS ou o Lote foi assinado, pelo simples fato de que para o provedor em questão a assinatura não é feita. Quem monta o Lote a ser enviado é o comando Enviar e logo após a montagem do mesmo, a assinatura é realizada ou não dependendo do provedor, se na Unit referente ao provedor constar que o Lote tem que ser assinado, a mesma será feita, caso contrario não. Como você pode ver o componente foi feito de uma forma que determinados passos não foram separados para garantir os requisitos dos provedores.

Luis, 107,47 % ??? Como não tem nenhuma orientação na Nota Técnica a respeito não só desse percentual e sim de vários outros como é o caso do pICMS que também pode ter 2 ou 4 casas decimais, chego a seguinte conclusão: Para percentuais menores que 10 % podemos informar com 4 casas, exemplo 3 % => 3.0000 temos um total de 5 dígitos. Para percentuais maiores ou iguais a 10 % devemos informar com 2 casas, exemplo 107,47 % => 107.47 temos um total de 5 dígitos.

Junior, Lhe devolvo uma outra pergunta: Porque o contador esta realizando essa consulta, uma vez que ela foi criada para o destinatário e não para o contador. O contador não pode em hipótese nenhuma realizar essa consulta e muito menos realizar a manifestação. Pelo simples fato que ele não sabe se o destinatário realmente comprou ou não daquele fornecedor e se a a mercadoria foi entregue ou não.

Boa tarde Mauricio, Se você esta se referindo a NFS-e, os passos são: 1. Alimentar o componente; 2. Enviar. O Enviar se encarrega de assinar gerar o lote e validar. No caso da NFS-e ou melhor o RPS uma vez que o componente gera o RPS e monta o lote com RPS e envia para que o Web Service processa o lote e se tudo estiver correto nos devolve a NFS-e. A validação é feita em cima do lote em não no RPS.

Boa tarde Luis, Veja a besteira que você esta fazendo: Estou passando o valor de 107.47 para a tag pMVAST, o valor passado e o valor de retorno da tag estão corretos só que no xml ele coloca 107.4700 A TAG pMVAST é uma TAG que contem Percentual da margem de valor Adicionado do ICMS ST. Inclusive na sua postagem que contem a imagem tem essa informação. Sendo assim, você tem que passar o percentual e não o valor.

Helio, Sim, todos os comandos que hoje você utiliza para a NF-e vai continuar usando os mesmos inclusive a sintaxe é a mesma, não muda nada. Como dito o que muda é algumas informações como por exemplo, em vez de você informar modelo=55 vai informar modelo=65. Na NF-e é obrigado a informar os dados do destinatário, por outro lado na NFC-e o destinatário pode ser omitido. Como já dito na postagem #4, a estrutura do XML apresentada na Nota Técnica é a mesma para os dois modelos de documentos fiscais. Você vai ter que ficar atendo a coluna de observações, que dependendo do modelo o valor atribuído a um determinado campo pode ter restrições, por exemplo para na NF-e pode-se utilizar os valores de 1 a 4 já para a NFC-e pode-se utilizar os valore 1, 3, 5 e 6 (o 2 e 4 não pode).

Boa tarde Junior, Ao fazer a primeira consulta com sucesso, foi retornado o valor de ultNSU, esse valor foi utilizado na consulta seguinte? Se você sempre utilizar o valor Zero com certeza vai aparecer essa mensagem. Inclusive a mensagem te orienta a utilizar o ultNSU nas próximas consultas.

Boa tarde, É muito estranho o seu cliente ter conseguido realizar a manifestação em uma nota que foi cancelada. Como você mesmo disse, a nota foi cancelada antes de ser manifestada. O emitente da nota é do mesmo Estado do destinatário? Qual foi o intervalo de tempo entre o cancelamento e a manifestação? Respondendo a sua pergunta se a nota foi cancelada primeiro não vejo problemas principalmente se a manifestação não foi de Operação concluída.

Boa tarde, A nota de numero 200 foi emitida hoje dia 16 mas a de numero 196 foi emitida no dia 13, e você agora quer emitir a de numero 195. Na Nota Técnica mais atualizada da NF-e não encontrei nenhuma regra que faz com que uma determinada nota seja rejeitada pelo fato de estar enviando um numero inferior ao último enviado. E também não tem nenhuma regra com relação da Data/Hora de Emissão, a única regra que existe refere a data de emissão é com relação a data de saída que se for informada tem que ser no mínimo igual a de emissão jamais inferior.