EMBarbosa

Antes de tudo, veja o seguinte tópico sobre o assunto: Seria bom procurar um contador confiável que poderá te orientar em quais valores exatos você deve preencher esses campos.

Numa outra mensagem o @Celso Marigo Junior mencionou que estamos trabalhando no novo Mapa Fiscal do ACBr e essas informações constam nele. Acessem em: https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico

Você pode usar qualquer uma que o leitor aceite. Como a Juliana mencionou depende de sua informação e intenção com ela. Cada código de barras foi criado com um objetivo.

Estou usando o 2.0 desde quando ele ainda estava em testes. Não sei se precisa. Mas, se você quiser apagar a pasta do Lazarus só pra garantir pode.

Esses arquivos não fazem parte do ACBr. É provável que tenha algum problema na sua instalação do Lazarus.

Ou um revert, caso já tenha feito o update.

Moderação: Tópico Dividido

Sim. Esse código já foi corrigido para: else begin if not ForceDirectories(ADir) then raise Exception.Create('Erro ao gerar PDF. Diretório: ' + ADir + ' não pode ser criado'); end;

Se não me engano, isso (definir se é Débito ou Crédito), está na documentação como diz no tópico que mencionei. Então não vejo o motivo pra não implementar. Mas as outras coisas que você mencionou (bandeira, parcelado/à vista, etc...) já não tenho certeza.

Se não me engano, no SiTEF, você pode definir se é débito ou crédito antes. Veja esse tópico:

Estava lendo o decreto e notei que o usuário do sistema vai ter que emitir NF-e para fins de restituição (artigos 27 a 30 da Parte 1 do Anexo XV do RICMS). Não tenho certeza, mas talvez você esteja querendo saber como fazer os cálculos para preencher essa nota. Isso é difícil de orientarmos. Você precisa mesmo de um contador que te informe os processos e como devem ser os cálculos. Mesmo porque, alguns detalhes podem diferir em situações de seus usuários. Por exemplo, veja que cada um dos artigos mencionados falam sobre uma forma diferente de restituição de ICMS ST.

Para estas perguntas: Veja seu outro tópico: Agora você entrou numa questão que envolve mais a regra de negócios e do que a lei especificamente. A lei permite as duas coisas e, por isso, não é tão importante para a homologação. Note os itens 8 e 9 do requisito XLVIII que é mencionado nos requisitos sobre a tabela em questão. Eles abrangem uma situação diferente da padrão. Voltando a questão, talvez você atenda uma marcenaria que fabrique cadeiras e mesas, mas também venda o conjunto de sala de jantar (1 Mesa e 4 cadeiras). Eles talvez só montem o kit na hora de vender e desmontem o kit caso ele não seja vendido. Então a baixa no estoque precisa ser feita só na hora da venda. Por outro lado, você pode ter uma padaria que faz venda de por exemplo coxinhas. Na cozinha, alguém pega os ingredientes (insumos) e transformam ele num novo produto "a coxinha". Esse ato de produção pode ser ou não controlado pelo seu sistema. Talvez a padaria queira que seja. Então depende da regra de negócios. Seu sistema pode ter que atender a todas as duas situações ou apenas uma. Mas como isso vai ser verificado na homologação, depende muito dos homologadores. Mais uma vez, verifique o que foi dito no tópico mencionado antes.

Independente de você trabalhar com ou sem GTIN, você precisa seguir o layout do xml validado pelo schema. O erro aponta que o elemento 'Codigo' não é válido para o xml. Verifique se está seguindo o layout do schema.

Já usei muitas vezes transações "AutoStarted" por questão de simplicidade. Mas sinceramente recomendo não utilizar. Quando você não controla o fluxo das transações é muito comum acontecerem vários erros.

Olá, Estou movendo sua postagem para um novo tópico. Por mais que o tópico anterior seja semelhante, preferimos que dúvidas específicas sejam em tópicos separados. Assim facilita na hora de encontrar as informações. Vamos as suas perguntas: Infelizmente, (ou felizmente sei lá), o CONFAZ e assim também cada SEFAZ descontinuou aquele roteiro de testes que existia no início do PAF-ECF. Por isso, cada homologadora faz os testes da forma que acha mais apropriado. Então o melhor conselho que posso dar é vocês definirem onde vão fazer a homologação e daí entrar em contato com eles para esclarecer todas suas dúvidas. Detalhes específicos são difíceis de prever. Por isso qualquer coisa que vocês achem que pode gerar uma confusão deve ser questionada. Às vezes é bom até questionar coisas só pra obter uma confirmação. Bom, em teoria ele deve cumprir os requisitos exigidos pela UF que você vai homologar. A propósito, você não disse qual era. Lembre-se que o PAF-ECF tem Perfil de Requisitos exigidos em cada UF. Isso quer dizer que ele deve: ter no menu fiscal o item “Tab. Índice Técnico Produção” e gerar o arquivo eletrônico assinado. Veja o item 14 do requisito VII. Possuir a tabela de índice técnico de produção para ser consultada, alterada ou inserida pelo usuário por meio da sua tela de operação normal. Veja o item 4 do requisito XXVII Mas vejamos, Quando fiz homologação pela última vez, eles me deram a seguinte explicação: E faz sentido. Se você ler o item 4 do requisito XXVII, verá que ele menciona um menu para inserção e consulta dos índices técnicos de produção devem existir na aplicação no menu da tela de operação do usuário. Não diz no MENU FISCAL. Contudo, mais uma vez, é melhor você questionar a homologadora. Eles costumam divergir em pensamento nesses pontos. Não existe um layout específico. Mas as homologadoras costumam mandar um caso você questione. É basicamente um espelho da tela: Item principal x |insumos|qtds|UN| Esse arquivo deve ser assinado como os outros arquivos do Menu Fiscal, adicionando um registro EAD no fim. (Veja o item 14 do requisito VII) Não. Essa tabela não precisa ser impressa.

Acredito que não sejam códigos de vocês, senão seria bem fácil migrar pro Lazarus ou pro Delphi 7. Sugiro vocês criarem um tópico na área de Delphi falando sobre esse assunto pra cada framework. É bem provável que isso seja mais fácil do que pensam.

Olá Leandro, O problema é que o componente foi contribuído assim. O certo mesmo seria substituir essa parte por um leitor de JSON. Nós temos o componente json4delphi na pasta ACBr\Fontes\Terceiros. Se você quiser dar uma olhada e tentar implementar, tem algum exemplo no ACbrCEP, no ACBRIBGE e no ACBrIBPTax. O que acha?

Talvez seja algum conflito na seleção da impressora. Eu tentaria remover o drive da impressora Argox e imprimir. Daí você pode verificar se a impressão ocorreu corretamente ou não. Isso pode dar alguma ideia do motivo.

Para informações sobre o SAT, procure o site oficial: https://portal.fazenda.sp.gov.br/servicos/sat/Paginas/Sobre.aspx Fique atento também ao nosso fórum. Além das áreas específicas sobre o SAT, tanto a área de notícias como o calendário trazem informações importantes.

Sugiro você procurar um componente que permita essa alteração. Talvez da TMS, Devart, etc... Lembro de já ter me deparado com algo parecido e era muito complicado mexer com isso na VCL.

É possível que seus arquivos estejam desatualizados apenas em parte. Veja: Não está assim no SVN. Na revisão 16530 foi subida a atualização para essa função alterando para: function CalcularTamMaximoNossoNumero(const Carteira : String; const NossoNumero : String = ''; const Convenio: String = ''): Integer; override;

Isso é basicamente propaganda dos componentes que eles cobram pra você usar.

Você utiliza o FastMM no seu projeto? Em caso negativo, passe a utilizar.

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, foi relatado que um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes! Ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já deveria saber que seria rejeitado. Isso é na verdade um ataque de DDOS, nos servidores do SEFAZ. Talvez um ataque sem intenção, mas não deixa de ser um... Mas nesse caso, quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós do ACBr não sabemos como seu sistema funciona, muito menos conhecemos os seus clientes. Ainda mais, qualquer solução do ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe que o item "2.1 Código de Segurança do Responsável Técnico - CSRT" nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

Eles são templates do Fast Report. Como você tinha mencionado um deles, achamos que estava utilizando o Fast Report.