rodrigo4t

Bom dia pessoal, Estou ressuscitando o tópico porque estou apanhando com o bendito do SmaraPD. Vocês também tiveram problema com o envio da senha ? Estou tentando transmitir pela propriedade Geral.SenhaWeb a senha de acesso do meu usuário criptografada com SHA1 conforme orientação do manual, mas recebo a mensagem "senha inválida" no momento da transmissão. O suporte da SmaraPD não tem sido de grande ajuda, eles só falam que eu devo ler o manual e mais nada. Eu criei uma função para encriptação da senha utilizando o Turbopower LockBox 3: function HashSenhaSHA1(sSenha: WideString): WideString; var bytes : TBytes; i, P, Sz: integer; aByte: byte; s: string; SHA1 : THash; Lib : TCryptographicLibrary; begin Lib := TCryptographicLibrary.Create(nil); SHA1 := THash.Create(nil); SHA1.CryptoLibrary := Lib; SHA1.HashId := 'native.hash.SHA-1'; SHA1.Begin_Hash; SHA1.HashString(sSenha); if not assigned(SHA1.HashOutputValue) then result := 'nil' else begin SetLength(Bytes, 20); Sz := SHA1.HashOutputValue.Size; if Sz <> 20 then result := Format('wrong size: %d', [Sz]) else begin P := 0; SHA1.HashOutputValue.Position := 0; while SHA1.HashOutputValue.Read(aByte, 1) = 1 do begin bytes[P] := aByte; Inc(P); end; result := TNetEncoding.Base64.EncodeBytesToString(bytes); end; end; SHA1.Destroy; Lib.Destroy; end;

Bom dia pessoal, Fazendo os testes junto do cliente, eu vi que foi necessário uma mudança mais profunda no mesmo campo: eu passei o QUALIF_REP_LEGAL de integer para String, porque de acordo com o guia prático, o campo não deve ser informado caso não exista um representante legal. Assim, o QUALIF_REP_LEGAL passa a ter o mesmo comportamento do campo QUALIF no mesmo registro. ACBrECFBloco_Y.pas ACBrECFBloco_Y_Class.pas

Boa tarde, Fiz uma correção no registro Y600, na unit ACBrECFBloco_Y_Class. No método WriteRegistroY600, eu mudei a linha: LFill(QUALIF_REP_LEG) + Para LFill(QUALIF_REP_LEG, 2) + O método default de uma das chamadas da LFill acabava formatando como data o campo QUALIF_REP_LEG. ACBrECFBloco_Y_Class.pas

Boa tarde Pessoal, Após atualizar o ACBR com a mudança pra depreciação da Capicom, também tive o mesmo problema enfrentado pelo Marcos Maceno e pelo Ricardo Lopes utitlizando a libCapicom. Fiz a mesma modificação, este erro parou, mas agora estou recebendo um "arquivo de schema não informado". Vocês podem compartilhar comigo quais foram as mudanças que vocês fizeram no seus sistemas pra continuar transmitindo NF-e via Capicom ?

Bom dia pessoal, Fiz a atualização do ACBR pra trabalhar com a ECD deste ano e fui supreendido com as modificações pra depreciação da CAPICOM... Eu sei que o ideal é já passar pra WynCript, mas estou absolutamente sem condições de tempo de fazer isso agora. Eu preciso apenas manter a emissão funcionando via capicom como era; Defini a propriedade Geral.SSLib pra libCapicom, mas aí tive essa mensagem "parâmetro inválido". Como o colega acima falou, preenchi a propriedade SSL.NumeroSerie com o número de série do certificado, mas na sequencia aparece o erro "arquivo de schema inválido". Não basta mais apenas informar o path pros schemas da NF-e ? Se eu mudo a biblioteca pra WynCript, o erro "arquivo de schema inválido" também é disparado.

Olá pessoal, Como vou precisar enviar as informações do Bloco Q (livro caixa, obrigatório para empresas do lucro presumido desobrigadas a enviar a ECD), fiz a implementação do mesmo. Fiz todas as alterações sobre a versão atualizada do ACBR de hoje, por volta de 11 da manhã. EDIT: Fiz uma correção no TRegistroQ100 às 16:09, arquivo atualizado ACBrECFBloco_Q_Class.pas ACBrSpedECF.pas ACBrECFBloco_Q.pas

Boa noite! Esta semana comecei a tentar gerar os arquivos da ECF para este ano. De cara peguei dois problemas nos blocos Y e X que já corrigi: 1) Registro Y600: O guia prático deste ano eliminou o registro filho Y611, onde eram informados os rendimentos dos sócios e fundiu estes campos ao próprio Y600 2) Bloco X, registros diversos: Em vários registros onde era informado o código de país, a função LFill era passada sem parâmetro e o valor no arquivo texto acabava sendo formatado como data. Mudei a declaração de LFill(PAIS) para LFill(PAIS, 3). Todas as alterações foram feitas em cima dos fontes atualizados hoje de manhã pelo SVN. ACBrSPEDECF.zip

Bom dia Michel, Esse "aval contábil" é que está difícil. Não há nenhuma instrução oficial por parte da RFB ou dos SEFAZ orientando o envio da tag ICMSUFDest nos produtos isentos; no entanto, a NF-e não consegue ser emitida sem a TAG. Eu tenho um cliente que entrou em conferência com contadores de três estados diferentes (ES, DF e GO) mais um grupo de trabalho de um curso sobre a EC 87 e após horas de analíse e confabulação, a decisão deles é que os campos da partilha devem ser enviados zerados, apenas com a alíquota de ICMS interestadual e o percentual de partilha preenchidos, que são os campos obrigatorios. Eu modifiquei a unit pcnNFeW.pas para que o teste da obrigatoriedade da tag seja feito pela alíquota interestadual e não pela base de cálculo da UF de destino, assim não tenho que preenchê-la como o Igor Moura fez. não vou sugerir que esta mudança seja incorporada permanentemente nos fontes do ACBr até porque não há nenhuma atualização da NT que regulamente esta opção, mas até que saia, vou ter de sempre manter minha modificação aplicada.

Eu solicitei a um contador de um cliente que fizesse uma consulta no IOB quanto ao preenchimento das tags no caso de mercadorias isentas ou não tributadas, vamos ver o que eles retornam.

DOCFABIO e 3Soft, eu fiz o teste com a mercardoria isenta (CST 40 e 41) e sem a tag ICMSUFDest, não consegui transmitir a NF. Recebi a rejeição "Grupo de ICMS interestadual para a UF de destino deve ser informado na operação interestadual com consumidor final". Na sequencia, eu forcei o componente a gerar a TAG mesmo não havendo informação preenchida. Aí, ao transmitir, os próprios schemas rejeitam a nota pois a alíquota de ICMS interestadual não está preenchida. Em seguida, tentei fazer mais um teste: enviar a nota com o cliente marcado como não contribuinte, mas indicando operação normal na tag Ide.indFinal; A NF-e foi transmitida! E agora ? - Devo manter a identificação de operação com consumidor final e calcular o diferencial de aliquota para produtos não tributados ? - Mercadorias destinadas a consumidor final não contribuinte não poderão ser vendidos com isenção, devendo nesse caso a operação não ser definida como venda normal, não a consumidor final ?

SIm, estou passando as propriedades zeradas, mas o componente ACBRNFe não gera a tag dentro do XML.

Cantu, estou na mesma situação. Até sexta-feira, eu achava que as empresas do simples nacional não seriam obrigadas a destacar e pagar o DIFAL, mas agora de manhã recebi a confirmação de um contador de um cliente que diz que sim, estas empresas deverão calcular e pagar o DIFAL. Estou tentando ver com o contador como fica o cálculo. Tenho ainda outra situação: um cliente que tem mercadorias isentas de ICMS (CST 41), mas que ao testar a NF, recebe a rejeição de que o grupo ICMSUFDest é obrigatório. E aí ? Alguém já passou por esta situação ? Temos de calcular o DIFAL e pagar a GNRE mesmo para produtos isentos ?

Olá pessoal, Eu tive de fazer uma correção na unit ACBrNFeDANFEFRDM.pas, depois de tentar emitir uma NF-e de serviços prestados. Eu não vou postar a Unit toda, pois há modificações decorrentes da minha versão do fastreport, mas o erro foi corrigido no método TACBrNFeFRClass.Create. No trecho onde eram definidos os campos da cdsDadosProdutos, os campos de valos do ISS e vase de cálculo do ISS eram criados como Float. O problema é que todos os outros campos de totais são definidos como String, e convertidos de String para Float posteriormente, no momento da impressão. Quanto um destes dois campos fosse preenchido, a impressão dispararia um erro de conversão. Onde antes era: FieldDefs.Add('vISSQN' , ftFloat); FieldDefs.Add('vBcISSQN' , ftFloat); Eu modifiquei para: FieldDefs.Add('vISSQN' , ftString, 18); FieldDefs.Add('vBcISSQN' , ftString, 18); Assim seguindo o mesmo padrão dos outros campos de valor, como ICMS, IPI, frete, seguro, etc. EDIT: Lembrando que estou me referindo ao compontente da Trunk2.

Digibyte, Eu tenho um cliente que importou os blocos J, K, P e Y (ou o que dá pra extrair do meu sistema para estes blocos) e está fazendo todas as modificações restantes manualmente. O que acontece é que, algumas informações só serão desbloqueadas no validador se você informar algumas coisas corretamente no registro 0020 a importar. Exemplo: os registros X430 e X450 só são liberados para preenchimento se você marcar como "S" os campos IND_REND_SERV e IND_PGTO_REM no registro 0020. O duro é que o manual não explica isso, e é tudo na base da tentativa e erro. Além disso, o validador não deixa você modificar os parâmetros do bloco 0000 depois de importado; então, você acaba tendo que ir brincando com os parâmetros e gerando novos arquivos até descobrir qual campo desbloqueia o que no validador.

Carlos, Eu curiosamente tive isso após tentar utilizar o ACBr numa máquina com Windows 10, sendo que nunca tive problemas antes assim: no meu caso, eu só precisei colocar todas as DLLs vinculadas (OpenSSL, Capicom, etc.) que estão disponíveis na pasta DLL para dentro da pasta Windows\System32 ou Windows\SysWow64. Depois disso não tive mais problemas.

Digibyte, eu peguei os fontes iniciais que você liberou com o bloco 0 e o começo do bloco J, adaptei para gerar um componente no Trunk original porque eu ainda não poderia mudar meus componentes pro trunk2 e gerei os métodos restantes para todos os blocos com exceção do T e do V que não precisarei. Os arquivos foram no entanto, todos comitados para o Trunk2. O componente está funcional, eu tenho clientes que até começaram a transmitir as declarações.

Olá pessoal, Estou fiz duas alterações no bloco P nos métodos WriteRegistroP100 e WriteRegistroP150 com problemas que peguei ao alimentar os registros; Existe uma propriedade integer chamada NIVEL nos dois registros (P100 e P150). Ao passa-la no método que montava a linha, em ambos a implementação delas estava assim: LFill(NIVEL) + Isto fazia com que na hora de gerar o arquivo, a função LFill utilizada acabava sendo a que tratava campos TDateTime, o que convertia o conteúdo de NÍVEL com um formato DDMMYYYY. Eu mudei para LFill(NIVEL, 1) + Especificando o tamanho do campo, a função utilizada passou a ser a correta e consegui importar os arquivos sem problemas. ACBrECFBloco_P_Class.pas

Anderson, Acho que você não adicionou o caminho dos fontes do ACBrSPEDECF (não apenas o local onde está o .DPK) no seu library path.

Tenório, se você estiver na mesma situação que eu e não puder usar os componentes diretamente do Trunk2, faça o seguinte: - Baixe os fontes do repositório atual do Trunk2 e copie-os para o diretório Fontes\ACBrSPED\ACBrSPEDECF. da sua instalação do ACBr. - Em seguida baixe o DPK que eu coloquei no meu primeiro post e reinstale o componente, é como eu resolvi o problema aqui até poder recompilar meu projeto todo.

Juliomar, Como eu disse ontem, eu não posso usar o ACBrSped mais recente porque tive inúmeros erros ao tentar compilar meu projeto com o ACBr do Trunk2. Como eu não tenho tempo de resolver esses problemas agora, optei por portar o componente do ACBrSPEDECF para que ele funcionasse na versão que eu tenho aqui, que ainda é baseada nos arquivos que estão no Trunk.

Pessoal, eu estou subindo alguns ajustes que fiz nos componentes. Há várias correçõezinhas além de eu ter colocado os métodos Create e Destroy dos blocos padronizados como no bloco 0, utilizando os métodos CriaRegistros / LiberaRegistros. Nesta versão que estou enviando, estou gerando um arquivo com os blocos 0, J e K e os mesmos estão sendo importados no PVA. Akai, eu percebi agora no fim da tarde a ausência dos métodos RegistroXXXXNew e iria implementá-los amanhã; como você já fez o do bloco J e está fazendo os outros, vou deixar a tarefa a seu cargo. Juliomar e Isaque, vocês poderiam fazer o merge dos arquivos ajustados pelo Akai com as correções que eu coloquei hoje ? Muito obrigado a todos! ACBrSPEDECF.zip

Bom dia Isaque, Eu realmente troquei pra Currency, depois que comparei com os fontes do ACBrSPEDEcd da minha máquina e vi que lá os campos de valor estavam declarados assim. Bom saber, nas próximas modificações eu me atento à isso.

Boa noite Pessoal! Foi uma pauleira lascada, mas hoje conseguimos fechar todos os blocos restantes, com exceção do T e U, que não iremos fazer pois não temos necessidade e o prazo está apertadíssimo. Eu aproveitei e corrigi a geração dos registros dos blocos L, M, N, P, X e Y para que fique no padrão do componente, de acordo com o implementado no bloco 0 e nas mudanças feitas pelo Arielguareschi (obrigado, amigo!) nos blocos J e K. Acredito que agora o componente está funcional e com a geração do arquivo OK. Quem puder agora adicionar as validações básicas a fim de melhorar o componente, esteja a vontade. Amanhã eu começo a montar meu programa para alimentar o componente e vou tentar gerar um primeiro arquivo que seja validado no PVA. Conforme for efetuando correções nos fontes do componente, vou atualizando aqui. ACBrECFBloco_Y_Class.pas ACBrECFBloco_X_Class.pas ACBrECFBloco_P_Class.pas ACBrECFBloco_N_Class.pas ACBrECFBloco_M_Class.pas ACBrECFBloco_L_Class.pas ACBrECFBloco_X.pas ACBrECFBloco_Y.pas ACBrECFBloco_L.pas ACBrSpedEcf.pas

Olá Pessoal, Fizemos um esforço aqui na minha empresa e estou enviando um arquivo zip contendo os seguintes blocos: - Bloco J - Bloco K - Bloco L - Bloco M - Bloco N - Bloco P (eu só vi agora que o Digibyte subiu e não olhei o que ele fez) - Mudanças na ACBrSPEDEcf.pas para que o componente gere todos os registros. Agora vamos aos comentários e ressalvas, e peço que leiam com atenção , já que gostaria da ajuda de vocês para melhorarmos o resultado final: 1) Todos os blocos acima estão devidamente implementados, com as classes gerando os registros e suas chamadas feitas no componente. 2) Como eu estou MUITO atrasado com o SPED ECF com meus clientes, eu não coloquei validação nenhuma nos dados gerados; as classes estão simplesmente gerando os dados sempre que elas forem alimentadas. Eu também não usei nenhum tipo enumerado, mantive a declaração dos campos como no esqueleto original da classe de cada registro que já havia no SVN. Quem tiver tempo de implementar as validações base nas classes, eu ficarei imensamente agradecido. 3) IMPORTANTE, MUITO IMPORTANTE: AS UNITS FORAM RECOMPILADAS EM UM COMPONENTE QUE FUNCIONASSE NO PROJETO ANTIGO, DO TRUNK ORIGINAL. Eu tive muitos problemas com a NF-e ao tentar migrar meu sistema pra versão nova no Trunk2 que, com o tempo disponível que temos, optamos por recompilar apenas o componente do ECF. Acredito que as modificações para que o mesmo recompile no Trunk2 não sejam muito complicadas. 4) Como eu vi que os registros do bloco J eram exatamente iguais aos do Bloco I da ECD, eu copiei o codigo existente das classes dos registros relacionados no ACBrSPEDEcd, fiz as modificações necessárias e gerei inicialmente o Bloco J; daí em diante, usei esta mesma estrutura como base para criar os blocos seguintes, já que me economizou um bom tempo. Por isso, vocês irão reparar que algumas funções declaradas previamente nas units que existiam no repositório não foram utilizadas. LEMBRETE: O Bloco J e K podem ser recuperados no PVA à partir de uma ECD assinada, mas existe também a hipótese de, como em alguns de meus clientes, o mesmo não tenha sido obrigado a enviar a ECD, mas tenha de enviar a ECF; neste caso, estes dois blocos DEVEM ser preenchidos no arquivo. 5) MAIS IMPORTANTE AINDA: Eu NÃO TESTEI a alimentação destas classes e a consequente geração e validação do arquivo; só vou começar isso quando terminar todo o componente. Amanhã nós devemos terminar os blocos X e Y; como nenhum dos meus clientes trabalha com o Lucro Arbitrado, só devemos escrever o código pros blocos T e V se eles forem bem simples. Assim que os últimos blocos estiverem prontos, eu subo as modificações. Esperamos que estas modificações ajudem vocês de alguma forma e que vocês possam também colaborar colocando as validações necessárias e ajustando os fontes para que funcionem dentro dos padrões estabelecidos para o Trunk2. PS: Estou enviando também a DPK do ACBrSPED adptada para o projeto disponível no Trunk, caso alguém esteja na mesma situação que eu e prefira trabalhar com o pacote ACBr dele. ACBrSPEDECF.zip ACBr_SPED (trunk).dpk

Pessoal, estou com um problema esquisito: Eu tenho um cliente que emite NFS-e da prefeitura de Guarapari/ES, com o provedor GovBR. A versão anterior do sistema, que estava com os fontes do ACBr datados de maio/2014, se não me engano, está emitindo as notas fiscais sem problema. Depois que fiz uma atualização nos fontes na sexta-feira passada, ele não consegue mais emitir as notas; eu recebo um erro que é como se os schemas XSD utilizados pelo GovBR estivessem errados: Código Erro : E160 Mensagem... : Linha: 1 - Coluna: 40 - Could not find schema information for the element 'http://tempuri.org/servico_enviar_lote_rps_envio.xsd:EnviarLoteRpsEnvio'. Correção... : Envie um arquivo dentro do schema do arquivo XML de entrada. Provedor... : GovBR Código Erro : E160 Mensagem... : Linha: 1 - Coluna: 171 - Could not find schema information for the element 'http://tempuri.org/servico_enviar_lote_rps_envio.xsd:LoteRps'. Correção... : Envie um arquivo dentro do schema do arquivo XML de entrada. Provedor... : GovBR Código Erro : E160 Mensagem... : Linha: 1 - Coluna: 180 - Could not find schema information for the element 'http://tempuri.org/tipos_complexos.xsd:NumeroLote'. Correção... : Envie um arquivo dentro do schema do arquivo XML de entrada. Provedor... : GovBR Este é só um pedaço da mensagem, porque os erros são gerados para todos os campos. Além disso, se eu comparar o RPS gerado nas duas versões (a da compilação de maio e a atual do ACBr), a estrutura do XML também está diferente. Estou encaminhando ambas em anexo. Alguém tem uma luz pra me dar ? rps_versão_atual.xml rps_versão_maio.xml