Danny

Bom dia pessoal. Apesar do manual de Orientações de Preenchimento de Campos do Leiaute do CF-e-SAT indicar que o uso do subgrupo PISSN/COFINSSN são para contribuintes do Simples Nacional há uma necessidade de contribuintes do simples utilizarem os subgrupos PISNT/COFINSNT, conforme orientações da contabilidade de um cliente. Por este motivo necessitei fazer uma alteração na pcnCFeW.pas (GerarDetImpostoPIS e GerarDetImpostoCOFINS) de modo que não force a sempre utilizar os sugbrupos PISSN/COFINSSN quando o regime de tributação é do simples nacional. Gostaria de propor esta alteração ou discutir a situação com os colegas. Segue unit em anexo. Obrigado. pcnCFeW.pas

Italo e pessoal da lista, boa tarde. Mais uma informação. O provedor do município de Cerquilho/SP foi mudado do SimplISS para 4R. http://cerquilho.sp.gov.br/produto.php?idp=MzYwNQ.. Fiz os ajustes nos fontes (Trunk1) e funcionou perfeitamente. As NFS-e foram transferidas de um provedor para o outro e a orientação da prefeitura é dar continuidade à numeração do RPS. Até breve!

Bom dia pessoal. Somente para informar que a URL do município de Cerquilho/SP foi modificada de http://187.45.245.217/ws_cerquilho/nfseservice.svc para http://wscerquilho.simplissweb.com.br/nfseservice.svc Obrigado.

Bom dia. Fiz a correção de um bug na impressão do DANFE, onde não saia o Complemento dos endereços de Retirada e Entrega. Seguem arquivos corrigidos. Obrigado. ACBrNFeDANFeRLPaisagem.dfm ACBrNFeDANFeRLPaisagem.pas ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.pas

Boa tarde a todos. Fiz uma alteração na unit anexa necessária para gerar corretamente a GNRE. Obrigado. ACBrGNRE2.pas

Desculpe Daniel, Posso ter me equivocado nos testes, mas agora, com os fontes atuais, não encontrei problemas. Muito obrigado!

Daniel, voltei o FormatFloat somente nos campos que não aceitam decimais. Ao gerar o cálculo pelo site dos correios (http://www2.correios.com.br/sistemas/precosPrazos) esses campos não permitem entrada de decimais. Utilizando também a máscara #0 no FormaFloat gera o mesmo efeito que #,000. Deixando com FormaFloat se o componente receber por exemplo 31,25 será enviado 031 para o WS com a máscara #,000 O FloatToString proposto por você resolveu o problema do campo Valor Declarado, pois este é o único que aceita decimais. Obrigado.

Daniel, bom dia. Fiz novos testes com as alterações que você aplicou e resolveu parcialmente, mas gerou outro problema porque os campos de Peso, Comprimento, Altura, Largura e Diâmetro não podem conter casas decimais. No campo de valor declarado está correto o que você fez, enviando a casa decimal com o ponto. Fiz uma nova alteração e realizei novos testes (só não com o Diâmetro) e, acredito, ter resolvido definitivamente o problema. Segue em anexo a unit. ACBrSedex.pas

Boa tarde! Juliomar, considerando a máscara, neste caso o sistema envia o valor sem os decimais, pois o resultado é de 1 centavo considerando o centavo 04 e 99. Ou seja é enviado: &nVlValorDeclarado=1245& EMBarbosa, testei com o maior valor que o WS permite, no caso R$ 10.000,00. Mas esta máscara ignora os centavos. Obrigado pelo retorno.

Boa tarde pessoal. Encontrei um problema no valor declarado e fiz uma alteração na ACBrSedex: De '&nVlValorDeclarado=' + FormatFloat('#0.00', fnVlValorDeclarado) + para '&nVlValorDeclarado=' + FormatFloat('#0', fnVlValorDeclarado) + Estava tendo problema com valores acima de mil reais, onde estava sendo enviado por exemplo R$ 1.245,04 era enviado 1.245 e o WS entende isso como sendo um real (R$ 1.245). Segue anexo o arquivo alterado. Obrigado. ACBrSedex.pas

Pessoal, Consegui resolver segundo a recomendação do site: https://support.microsoft.com/pt-br/kb/884804 Foi somente corrigir o fuso horário do desktop que gerou a NF-e. De qualquer forma muito obrigado.

Boa tarde pessoal. O campo dhEmi no XML de uma NF-e ficou desta forma: <dhEmi>2015-12-23T00:00:01+04:30</dhEmi>, que gera o erro de validação em anexo. Utilizando o validador da SEFAZ-RS só consegui validar zerando o minuto dos "04:30". Tentando qualquer hora, seja positiva ou negativa, passa no validador, porém somente se não tiver os minutos. Estou certo que o componente está gerando corretamente na função TimeZone da unit synautil.pas. Acredito que o problema esteja no Schema da SEFAZ, porém não consegui fazer uma leitura de modo que eu tenha certeza que é no Schema (tiposBasico_v3.10.xsd): <xs:simpleType name="TDateTimeUTC"> <xs:annotation> <xs:documentation>Data e Hora, formato UTC (AAAA-MM-DDThh:mm:ssTZD, onde TZD = +hh:mm ou -hh:mm)</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((0[1,3-9])|(1[0-2]))-(29|30)))))T(20|21|22|23|[0-1]\d):[0-5]\d:[0-5]\d([\-,\+](0[0-9]|10|11):00|([\+](12):00))"/> </xs:restriction> </xs:simpleType> Provavelmente se alterar esta função no componente de modo que gere sempre "00" no minuto irá resolver o problema. Alguém já passou por isso e poderia me ajudar? Obrigado.

Bom dia Edson. Eu também tive problemas no ambiente de homologação e o contador da empresa não conseguiu junto à prefeitura. Isso me forçou a utilizar o ambiente de produção. Depois dos testes cancelei as NFS-e geradas. Até mais.

Desculpa Edson, Segue em anexo a unit que estava faltando. O manual especifica as rotinas disponibilizadas pelo provador. As que desenvolvi já descrevi acima, as demais eu não iria utilizar no momento. Obrigado. pnfsNFSeG.pas

Bom dia, Claro que sim Edson. Segue em anexo. pnfsNFSeR.pas ACBrNFSeWebServices.pas ACBrNFSeNotasFiscais.pas ACBrProvedorCONAM.pas pnfsNFSeW.pas

Pessoal, bom dia. Consegui implementar no Trunk1 e, apesar do número reduzido de métodos que o provedor oferece, está funcionando 100%. Realmente tive que fazer diversas alterações nos fontes. Obrigado.

Bom dia pessoal. Acabei de implementar com sucesso, para o Trunk1, os seguintes métodos para o provedor CONAM. - Envio de Lote; - Consulta de Lote; - Cancelamento de NFS-e. Pretendo colaborar, logo que possível, para implementar no Trunk2. Caso necessite posso enviar os fontes dos métodos que alterei. Obrigado. Danny

Bom dia. Direcionado para o tópico:

Bom dia pessoal. Alguém já tentou implementar nota de serviço para o município de Boituva/SP? Iniciei a implementação, porém estou tendo problemas de retorno do WebService. O suporte não me ofereceu respostas contundentes, dando a impressão de não ser eficiente. Obrigado Danny

Bom dia pessoal. Estou participando de outra discussão sobre o provedor DSF, mas para o município de Campinas: Fiz algumas alterações nos fontes e está funcionando normalmente para este município. Qualquer novidade vamos nos falando. Obrigado.

Ok Italo, muito obrigado.

Olá Zottis, boa tarde. Qual a mensagem que é retornada quando você envia o lote? Os problemas que identifiquei foram os seguintes: - No LoadFromFile do ACBrNFSeNotasFiscais não estava realizando a importação do RPS e NFS-e para o provedor DSF. Não era possível Imprimir ou Consultar por RPS por exemplo. - Na ConsultarNFSeporRPS não incluia a tag RPSConsulta que é obrigatória para este fim. - Para CancelarNFSe o CodigoMunicipio e o Cnpj do Prestador ficavam vazios e também são obrigatórios para este fim. - Ao LerRPS_IssDSF para uma ConsultarNFSeporRPS por exemplo, ocorria erro no retorno se a Serie não fosse igual a '99'. Para Enviar a Serie está indo como 'NF', que é o que fica gravado no RPS. - Ao LerRPS_IssDSF a leitura de alguns campos foi passado pra cima da leitura dos Itens, pois ficavam em branco. - Ao LerNFSe_IssDSF o PrestadorServico.IdentificacaoPrestador.InscricaoMunicipal foi alimentado com InscricaoMunicipal do XML da NFS-e. - Ao LerNFSe_IssDSF o Servico.Valores.ValorIss foi alimentado com ((FNfse.Servico.Valores.BaseCalculo * NFSe.Servico.Valores.Aliquota) / 100) para poder sair na impressão. Procurei detalhar e caso não tenha ficado claro estou disposto a ajudar. Obrigado. Danny

Boa tarde pessoal. Consegui emitir a primeira NFS-e para o município de Ubatuba/SP em ambiente de Produção para o provedor GINFES. Segue anexada a unit que adaptei. Só um "pequeno" problema está ocorrendo. Na minha aplicação, ao finalizar o Envio e imprimir pelo QR, ocorre da aplicação fechar completamente na hora de criar a impressão em fqrDANFSeQRRetrato := TfqrDANFSeQRRetrato.Create(Self), linha 78 da unit ACBrNFSeDANFSeQRClass. Não tenho como debugar e em outros provedores isso não está ocorrendo. Depois que entro novamente na aplicação a NFS-e é impressa normalmente. Já fiz teste tentando não imprimir depois do envio, mas a primeira impressão depois do Envio ocorre o mesmo problema. Obrigado. Danny pnfsConversao.pas

Boa tarde pessoal. Tive que fazer algumas adaptações para DSF Campinas. Somente mediante a estas alterações é que foi possível Enviar, Consultar por RPS e Cancelar NFS-e. Se necessitar detalhes de quais alterações que fiz posso estar passando aqui. Não sei dizer se essas alterações interferem para DSF de outros municípios. Em anexo seguem os arquivos que alterei. Obrigado. Danny ACBrNFSeWebServices.pas ACBrNFSeNotasFiscais.pas pnfsNFSeR.pas ACBrNFSeWebServices.pas ACBrNFSeNotasFiscais.pas pnfsNFSeR.pas

Régys, No sistema esta propriedade está setada como True. Não seria para sempre sair grande? Por que será que alguns itens saem pequenos? De qualquer forma sua dica foi excelente e vou deixar ela como False para ver o que ocorre. Muito obrigado! Danny