Italo Giurizzato Junior

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

Boa tarde @Weber de Paula, Já esta no SVN.

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 @Weber de Paula, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5522

@Fabio Fredianelli, Mas a sua aplicação pode trocar o #10#13 pelo ";"

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Boa tarde @JOÃO FREDERICO DE SOUZA, Notei que o método Imprimir que permite visualizar o DANFSE e imprimir no papel o texto do campo Discriminacao aparece corretamente. O problema esta no método ImprimirPDF, ou seja, ao gerar o PDF do DANFSE que o texto aparentemente fica maior e não é apresentado corretamente. Já inclui na lista de tarefas para que a Equipe ACBr possa analisar o problema. TK-5521

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.

Boa tarde @Fabio Fredianelli, A regra é muito simples. 1. Ao alimentar o campo discriminação você sempre vai usar o caractere ";" (ponto e virgula) no texto como quebra de linha, conforme consta no programa exemplo. 2. O componente ao gerar o XML do RPS faz a substituição do ponto e virgula pelo caractere ou sequencia de caracteres que esta configurado para o provedor em questão na unit Provider do mesmo. caso não conste nenhuma configuração referente a quebra de linha é utilizado o ponto e virgula mesmo. 3. O componente ao ler o XML da NFS-e faz a substituição do caractere ou sequencia de caracteres que esta na configuração pelo ponto e virgula. 4. O componente ao imprimir o DANFSE faz a substituição do ponto e virgula pela sequencia #10#13. Observação: Só podemos usar a sequencia #10#13 no XML do RPS se o mesmo não for assinado e nem o lote, caso contrario na devemos usar e caso seja incluído o componente os remove antes de assinar o XML, isso é feito por questões de normas.

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

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

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" ?

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

Boa tarde @dna.automacao, Os schemas pouco importa, veja isso: ; No grupo abaixo é definido os nomes dos arquivos XSD ; usados para realizar a validação do XML a ser enviado ; ao webservice ; 0 = False / 1 = True (Se True então valida) [Schemas] Validar=0 DefTipos= Cabecalho=nfse.xsd ServicoEnviar=nfse.xsd ServicoConSit=nfse.xsd ServicoConLot=nfse.xsd ServicoConRps=nfse.xsd ServicoConNfse=nfse.xsd ServicoCancelar=nfse.xsd ServicoGerar=nfse.xsd ServicoEnviarSincrono=nfse.xsd ServicoSubstituir=nfse.xsd Isso se encontra no arquivo SystemPro.ini, observe que o valor de Validar é zero, isso significa que o componente não vai validar o XML do RPS gerado. Como eu disse, com essa condição nem sequer precisa dos schemas. E os schemas que você anexou são os mesmos utilizados pelo componente novo.

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

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

Boa tarde Bruno, Quando você diz que a emissão ocorreu perfeitamente isso significa que ao visualizar ou imprimir o DANFSE através do portal da prefeitura a quebra de linha ocorreu como o esperado? A ideia da quebra de linha é informar o caracter ou sequencia de caracteres utilizados pelo provedor.

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