Italo Giurizzato Junior

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Lucas, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5547

Boa noite Diego, Muito obrigado pela colaboração, já inclui na lista de tarefas para o pessoal que cuida do Fast Report avaliar. TK-5545

Boa tarde Marcio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5543

Boa tarde Diego, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5536

Filipe, Já esta no SVN.

João, Já esta no SVN.

Boa tarde Michael, Já esta no SVN. A alteração só foi feita para o novo componente.

Boa tarde Filipe, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5534

Boa tarde João, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5533

Bom dia @Nelson Santos, Já esta no SVN.

Olá Pessoal, As dicas abaixo são validas para todos os os modelos de DF-e (Documentos Fiscais Eletrônicos). 1. A chave de um DF-e é composta por diversas informações e todas elas estão presentes no XML. A chave é composta pelo Código da UF (2 dígitos), Ano (2 dígitos) e Mês (2 dígitos) de emissão, CNPJ do emitente (14 dígitos), modelo do DF-e (2 dígitos), série (3 dígitos) e numero do documento (9 dígitos), tipo de emissão (1 dígito), código aleatório do documento (8 dígitos) e digito verificador (1 dígito). Devemos guardar no banco de dados, juntamente com os demais dados do DF-e as seguintes informações: Data/Hora de emissão e Código aleatório que deve conter somente 8 dígitos. Jamais use como código aleatório o próprio numero do documento, pois isso você deixa a chave vulnerável. O código aleatório deve ser gerado pela sua aplicação e armazenado no banco de dados conforme orientado acima, jamais deixe o componente gerar o código para você, pois desta forma você perde o controle dessa informação. A Data/Hora deve ser definida e também armazenada no banco de dados, jamais devemos usar a função Now na rotina que alimenta o componente, pois isso faz com que você também perca o controle dessa informação. Ao alimentar o componente com os dados do DF-e todas as informações devem ser lidas do banco de dados, com exceção do Digito Verificado da chave que é o próprio componente que o calcula. 2. De preferencia de guardar o XML do DF-e no banco de dados em vez de salvar em disco, pois alguns usuários desavisados resolvem excluir arquivos do HD da maquina por achar que tem muito arquivo salvo. Se isso ocorrer, ou seja, o usuário acabar deletando o XML de um DF-e, tendo todos os dados salvos no banco de dados basta fazer o seguinte: Alimente o componente com os dados do documento que estão no banco de dados, execute os métodos Assinar, Validar e Consultar. Desta forma você vai ter o XML de volta, mas lembre-se que esse processo só pode ser executado caso o DF-e tenha sido emitido dentro do prazo de 180 dias, passou de prazo não tem como recuperar. 3. Se ocorrer erro de internet (timeout por exemplo) como devo proceder? A resposta é muito simples: Não devemos enviar o documento novamente, pois o documento pode ser rejeitado por duplicidade. Não devemos gerar, assinar, validar o XML novamente, pois essa atitude pode mudar o código aleatório do documento e a data/hora de emissão caso você não seguir as orientações da primeira dica. Com isso ao enviar novamente o documento pode ser rejeitado por duplicidade com diferença chave, situação mais grave. Devemos sim carregar o XML que foi enviado através do método LoadFromFile (se esta salvo em disco) ou LoadFromString (se esta salvo no banco de dados) e em seguida executar o método Consultar. Antes de enviar o DF-e para a SEFAZ atualize o banco de dados mudando o status do documento como "Enviado", depois devemos executar o método Enviar. Se ocorrer o erro de internet a aplicação não deve permitir que o usuário envie novamente o mesmo documento uma vez que ele esta marcado como Enviado, mas a aplicação libera o documento para que o mesmo seja carregado e consultado conforme dito acima. Caso o retorno for uma rejeição acusando que o documento não se encontra na base de dados da SEFAZ, a aplicação pode tomar uma atitude automática de enviar novamente o documento, visto que ele não se encontra na base de dados da SEFAZ. Por outro lado se retornar o protocolo de autorização, como o componente esta com o documento "carregado" o XML será automaticamente atualizado e salvo em disco ou disponibilizado para que o mesmo possa ser salvo no banco de dados. A aplicação em seguida pode imprimir o documento auxiliar do DF-e. Seguindo essas dicas, muitos problemas com a emissão de DF-e são sanadas.

Bom dia Michael, Se tratando do novo componente ACBrNFSeX, leia o tópico abaixo.

Boa tarde @netsoftclaudio, Os tamanhos você pode conferir de 2 formas: 1. Pelos fontes do componente, se tratando do Padrão Nacional temos a unit PadraoNacional.GravarXml onde você encontra: function TNFSeW_PadraoNacional.GerarCodigoServico: TACBrXmlNode; begin Result := CreateElement('cServ'); Result.AppendChild(AddNode(tcStr, '#1', 'cTribNac', 6, 6, 1, NFSe.Servico.ItemListaServico, '')); Result.AppendChild(AddNode(tcStr, '#1', 'cTribMun', 3, 3, 0, NFSe.Servico.CodigoTributacaoMunicipio, '')); Result.AppendChild(AddNode(tcStr, '#1', 'xDescServ', 1, 2000, 1, NFSe.Servico.Discriminacao, '')); Result.AppendChild(AddNode(tcStr, '#1', 'cNBS', 9, 9, 0, NFSe.Servico.CodigoNBS, '')); Result.AppendChild(AddNode(tcStr, '#1', 'cIntContrib', 1, 20, 0, NFSe.Servico.CodigoInterContr, '')); end; Note que a tag cTribNac tem um tamanho fixo de 6 caracteres e a tag cNBS tem um tamanho fixo de 9, sendo que esta é opcional. 2. Pelos Schemas, se tratando do Padrão Naciona temos o arquivo tiposSimpls_v1.00 que esta na pasta: ...\Exemplos\ACBrDFe\Schemas\NFSe\PadraoNacional\1.00 Temos a seguinte definição: <xs:simpleType name="TSCodTribNac"> <xs:annotation> <xs:documentation> Código de tributação nacional do ISSQN: Regra de formação - 6 dígitos numéricos sendo: 2 para Item (LC 116/2003), 2 para Subitem (LC 116/2003) e 2 para Desdobro Nacional </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="[0-9]{6}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="TSCodNBS"> <xs:annotation> <xs:documentation> Código da lista de Nomenclatura Brasileira de Serviços (NBS) </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="[0-9]{9}"/> </xs:restriction> </xs:simpleType> Note que o tipo simples: TSCodTribNac tem um tamanho fixo de 6 caracteres sendo que todos tem que ser dígitos. Tempos também o tipo simples: TSCodNBS cujo tamanho é fixo de 9 caracteres sendo que todos tem que ser dígitos. Já os provedores que seguem o layout da ABRASF (versão 1 ou 2) segundo o manual a tag ItemListaServicos tem um tamanho de 5 caracteres com a seguinte formatação xx.yy, mas tem provedores que esse código não deve ser formatado ou não deve conter o zero a esquerda, sendo assim temos provedores cuja definição de campo o seu tamanho é variável, ou seja, vai de 1 até 5 caracteres. Por fim de posse dos fontes do componente ou dos schemas do provedor em questão você fica sabendo se uma tag é obrigatória ou não, o tipo de informação que ela aceita e seu tamanho.

Bom dia Bruno, Já esta no SVN.

Boa tarde @Ldelphigoias, Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Boa tarde Milton, O componente ACBrNFSeX segue a risca essas instruções. Me diz uma coisa em ambos os ambientes não se deve assinar? Pois para algumas cidades não devemos assinar em ambiente de homologação, mas devemos assinar em ambiente de produção.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia João, Já esta no SVN.

Bom dia @lemuel, Já esta no SVN.

Bom dia Bruno, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5519

Boa tarde @rose_asano, No XML da NFS-e onde aparece a série cujo valor é "E" ?

@bfbraz, Neste caso não vejo outra saída você entrar em contato com a SEFAZ-RS e expor o problema desses MDF-e que estão encerrados mas ainda acusa como não encerrados.

Boa tarde @bfbraz, Vamos ver se eu entendi o que esta ocorrendo: 1. O MDF-e é enviado e autorizado; 2. O MDF-e é encerrado quando a mercadoria é descarregada; 3. Ao consultar o MDF-e consta como encerrado; 4. Ao consultar os MDF-e não encerrados o MDF-e que foi encerrado aparece; 5. Se tentar encerrar novamente consta como encerrado; Se enviar outro MDF-e constando a placa do caminhão (cujo MDF-e foi encerrado mas consta como não encerrado) o MDF-e é autorizado?

Boa tarde @SISBLU Software, Neste caso não vejo outra alternativa entrar em contato com o provedor e questionar o motivo de funcionar via site e não funcionar via webservice.