Eduardo Muller

Warley tive a necessidade de usar esta balança e funcionou com o modelo Toledo. Porém recordo que foi necessário fazer algumas configurações na própria balança, como já faz algum tempo não recordo ao certo o que foi feito, era algo com velocidade da porta, algo assim, não tenho mais a balança para te dar um retorno exato.

No servidor de Chapecó com estes arquivos está funcionando. Chegou testar com eles?

Verificado os fontes e efetuado os testes, está correto. Eu quem agradeço, peço desculpas pela demora para o retorno!

Segue as units com as implementações dos eventos faltantes do registro 0000. ACBrEFDBloco_0_Class.pas ACBrEFDBloco_0_Events.pas

Farei isso então, muito obrigado!

O arquivo de SPED do software contábil JB faz a implementação de campos específicos para ele, nesse contexto eu teria a necessidade de gerar essas informações no Registro 0000, para os demais registros estou utilizando os eventos (OnWriteRegistro....), porém para este registro não há a implementação dos eventos. A minha dúvida é se há outra forma de fazer ou o melhor seria eu implementar os eventos para esse registro e submeter os fontes?

Rejane, entrei em contato com o suporte deles também e foi o mesmo que me passaram. Um provável erro na assinatura e que não era possível informar exatamente o que é...

Estou com o mesmo problema para o servidor de Chapecó. Conseguiu alguma solução?

Cancelamento da NFS-e alguém está conseguindo fazer?

Exato, esqueci essa parte da assinatura.

Eu adicionei em um arquivo de teste o município de Chapecó em duplicidade, porém com códigos diferentes, pois este servidor em homologação somente está aceitando o código do município 1234567. Seguem as duas alterações feitas. Publica.ini = [URL_H] ; Chapecó RecepcaoLoteRPS_1234567=http://nfse-teste.publica.inf.br/homologa_nfse_integracao/Services Cidades.ini = [1234567] Nome=Chapecó UF=SC Provedor=Publica NomeURL_H=chapeco NomeURL_P=chapeco

Estou tendo este mesmo problema. Conforme o suporte do servidor, este erro ocorre devido algum erro na assinatura do XML. Porém não se sabe exatamente qual o erro... Estou fazendo alguns testes, mas não sei o que pode ser.

O servidor de homologação só está aceitando município com código 1234567. Altere essa informação e reenvie

Boa tarde, realizei alguns testes aqui e consegui transmitir no ambiente de homologação. Único detalhe que tive que alterar é em relação ao código do município de prestação e do tomador que para este ambiente deve ser 1234567. Segue os meus arquivos Cidades.ini e Publica.ini com o ajuste para transmissão em homologação: Cidades.ini Publica.ini

Procurei de cada um destes estados as portarias e segue: Resolução do estado de Minas revogando a obrigatoriedade: http://www.fazenda.mg.gov.br/empresas/legislacao_tributaria/resolucoes/2018/rr5151_2018.htm Portaria do estado de Santa Catarina: http://legislacao.sef.sc.gov.br/html/portarias/2017/port_17_441.htm Portaria do estado de São Paulo: http://info.fazenda.sp.gov.br/NXT/gateway.dll/legislacao_tributaria/portaria_cat/pcat1472009.htm?f=templates&fn=default.htm&vid=sefaz_tributaria:vtribut Portaria do estado do Rio de Janeiro: http://www.fazenda.rj.gov.br/sefaz/faces/oracle/webcenter/portalapp/pages/navigation-renderer.jspx?_afrLoop=2989964940854492&datasource=UCMServer%23dDocName%3AWCC203858&_adf.ctrl-state=8jwmncjku_36

No site não encontrei nenhuma informação. Apenas tem a informação que fica a critério de cada UF exigir ou não essa informação. Achei a resolução do estado de Minas revogando a obrigatoriedade: Resolução que obrigava o envio: http://www.fazenda.mg.gov.br/empresas/legislacao_tributaria/resolucoes/2017/rr5071_2017.htm Resolução que revoga o envio: http://www.fazenda.mg.gov.br/empresas/legislacao_tributaria/resolucoes/2018/rr5151_2018.htm Os demais estados ainda não localizei, mas acredito ser verídica a informação...

Estive participando de um curso do Bloco K do SPED Fiscal e o instrutor informou que nos estados de Santa Catarina, São Paulo, Minas e Rio de Janeiro a apresentação do registro 0210 (ficha técnica dos produtos) está dispensada sua informação. Procurei o embasamento legal dessa informação e não encontrei. Única informação foi desta fonte: http://blog.bluetax.com.br/profiles/blogs/sp-bloco-k-fisco-dispensa-apresentacao-do-registro-0210-da-efd-ic Alguém sabe dizer se é verídico?

Em Santa Catarina ao utilizar os boletos do Unicred cedente Bradesco é necessário que seja informado, além do endereço do cedente, os dados do endereço do Sacador/Avalista. As informações de nome e Cnpj/Cpf já existem na impressão do boleto, porém os dados do endereço não. Adicionei essas informações e disponibilizo a unit para avaliação e uma possível utilização nos fontes do ACBr. Qualquer dúvida e/ou sugestão será bem vinda! ACBrBoletoFCFR.pas

Utilizo o componente do AcBR para os boletos do Bancoob/Sicoob (ACBrBancoBancoob) e ao homologar os boletos com o banco, está ocorrendo rejeição devido ao Dígito Verificador (DV) estar indo incorreto. Na função MontarCampoCodigoCedente está utilizando o último dígito do cedente como DV. Porém, caso eu coloque o DV junto ao cedente, ocorre erro na linha digitável. Como solução passei utilizar a função dessa forma: function TACBrBancoob.MontarCampoCodigoCedente ( const ACBrTitulo: TACBrTitulo ) : String; begin Result := ACBrTitulo.ACBrBoleto.Cedente.Agencia + '/'+ ACBrTitulo.ACBrBoleto.Cedente.CodigoCedente + '-' + ACBrTitulo.ACBrBoleto.Cedente.ConvenioDigito; end; Mais alguém passou por esse caso?

Era isso mesmo pessoal! Desculpe pela desatenção! Está validando o arquivo aqui também! Muito obrigado, abraço!

Elias, efetuei os testes com as alterações feitas e continua a rejeição. Fiz alteração manualmente no arquivo para teste e reenviei, sendo assim validou. Deixo aqui como enviei e como está gerando: * Xml gerado pelo Acbr (Não validado): <CRZ>1</CRZ> <COO>8</COO> <CRO>1</CRO> <VendaBrutaDiaria>539,60</VendaBrutaDiaria> <GT>539,60</GT> * Xml ajustado manualmente (Validado): <CRZ>0001</CRZ> <COO>000008</COO> <CRO>001</CRO> <VendaBrutaDiaria>00000000035960</VendaBrutaDiaria> <GT>000000000000035960</GT>

Boa tarde, também estou tendo problemas ao validar o xml da Redução Z com a seguinte mensagem: XML inválido: Schema inválido: O elemento 'CRZ' é inválido - O valor '1' é inválido dependendo do tipo de dados 'Numero4Type' - Falha na restrição Pattern. O elemento 'COO' é inválido - O valor '7' é inválido dependendo do tipo de dados 'Numero6ou9Type' - Falha na restrição Pattern. O elemento 'CRO' é inválido - O valor '1' é inválido dependendo do tipo de dados 'Numero3Type' - Falha na restrição Pattern. O elemento 'VendaBrutaDiaria' é inválido - O valor '539,40' é inválido dependendo do tipo de dados 'Numero14Type' - Falha na restrição Pattern. O elemento 'GT' é inválido - O valor '539,40' é inválido dependendo do tipo de dados 'Numero18Type' - Falha na restrição Pattern. Ao que pude observar, segundo o último documento de requisitos do SAT SC (https://docs.google.com/document/d/1yez14gry9Mi4rTpwDRDf--bR-SLzijD81OPeJzh9FqE/edit) esses campos tem um valor definido e este se não estiver preenchido, deve ser completado com zeros. Alguém está passando ou já passou por essa dificuldade também? Segue o arquivo xml gerado para validação (ReducaoZ.xml). Att. ReducaoZ.xml

Segundo informações que tive, estes são os links mais recentes que poderão ser alterados ainda até a conclusão: Xsd Redução Z (https://tributario.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/xsd/reducaoz.xsd) Xsd Estoque (https://tributario.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/xsd/estoque.xsd) Página para validação dos XMLs (https://sathomologa.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/validacao.aspx) Webservice para validação dos XMLs (http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx) Bloco X atualizado (Texto que provavelmente será publicado: https://docs.google.com/document/d/1yez14gry9Mi4rTpwDRDf–bR-SLzijD81OPeJzh9FqE/edit?usp=sharing)